But that ties the P2's use of SD cards to FAT, which is a disgusting file system on which many operations are unsafe in a system likely to lose power at any time, since FAT doesn't have journaling or isn't log-structured. If some other filesystem is used, it might not be practical to stick a PASM bootloader to boot off of that filesystem in the small MBR boot area, but it would be much more practical to load the MBR boot area with a PASM stub that has TAQOZ run the rest of the MBR boot area as TAQOZ bytecode, which is much denser than PASM. Could you add a feature to TAQOZ that facilitates writing such a PASM stub and user-defined TAQOZ commands (including word definitions) into the MBR boot are?
Wait a minute. How can you get an old SD card in microSD format?
I have a bunch of SD cards but there all full sized. I have a 128Mb card that I use to load my 3D printer with but it's full sized.
Mike
PS my 3D printer with an Arduino controller running Marlin can read long file names just fine.
They made them.I had a phone that came with a 32mb micro sd. They called it transflash. I bought a (very expensive) 128mb card for it to put my music on. They come up to 2gb. (supposedly the standard actually goes up to 4gb and they exist but are rare) I just purchased four 2gb cards for my old Nikon SLR that requires standard SD cards. All I could find at a reasonable price were the micro SD cards, so I use them in an adapter.
TransFlash is simply the old name for microSD IIRC (Some old Samsung datasheet I believe is where I first saw
the term). I believe the interface is/was mainly compatible.
But it'd be nice if a flash chip weren't necessary, for BOM cost and boot time and complexity. It could probably be done without external flash if there were a way to run TAQOZ bytecode out of the MBR, since TAQOZ bytecode is denser than PASM. It should be possible to do it without the tools for doing this being part of TAQOZ, but it'd be nice, especially for Windows users where it's harder to do custom disk formatting, if TAQOZ could do this itself.
The way I see it, boot media, journaled or not, is still at risk, until full file support is online and working. At that time, there is less risk, but still risk.
One could partition the card, use the existing boot methods, and put the robust file system into remaining card space, which could be substantial. I don't think that eliminates too much of the risk. I have had a lot of silly Smile happen to SD cards. I think there is significant risk, in some cases. It really depends on where the product is running and under what conditions. I've got people's hands on products, and they do an amazing number of unexpected and or dumb things. In one case, where there was constant corruption, I found out they were just connecting a monitor when they needed it. That connect, disconnect, on a Raspi, would glitch SD cards pretty consistently. Of course, reimage and redeploy works fine, mostly. I have a couple cards that were done on the first failure. (midnight special cards too, known risk!)
A best case is to only bring up what is needed to only touch the card when best support is up and running. This is what I would do personally. Ideally, that means not even powering the card, until it's time.
When SD cards are active, transients in the power, ejects, mechanical vibration, even thermal things can all glitch the card.
The nice thing is filesystem tools and or some other nice boot options can all be presented in case of trouble with the card. Frankly, with any filesystem, I'm inclined to setup future P2 systems with good stuff in flash. Some boot, and operation will be possible, sans a card.
For the sake of repeating again, you can place whatever P2ASM code you want into the MBR/VOL/TAT32/anywhere on the SD card. It will just boot the P2 with whatever you place there. So, you can put an extended TAQOZ there if you want.
For the sake of repeating again, you can place whatever P2ASM code you want into the MBR/VOL/TAT32/anywhere on the SD card. It will just boot the P2 with whatever you place there. So, you can put an extended TAQOZ there if you want.
But an extended TAQOZ would never fit in the MBR, and there's nowhere else to put it that's as safe that would be easy for a PC with a custom filesystem driver to understand (e.g. no boot image partition and no unpartitioned region that really has the boot image). The TAQOZ in ROM is perfectly fine; it just has to be started in a nonstandard way to do what I want. A small PASM stub at the beginning of the MBR boot code that starts the ROM copy of TAQOZ in such a way that it runs TAQOZ bytecode found in the rest of the MBR boot code area would be a more practical way to make a bootloader that boots a non-FAT filesystem that potentially takes up the whole SD card except for the MBR, without relying on an initial FAT partition just for booting off of.
It doesn't have to be that hard to boot off of a log-structured file system. Consider a theoretical log-structured file system that stored a pointer to the boot file in a special place in the root directory every time it saved the root directory. It would be easy to boot off of this: read the superblock, read the last saved root directory pointed to by the superblock, read the boot file inode pointed to by the root directory, and then read into RAM all the blocks pointed to in the block indirection table in the boot file's inode into RAM. If power failed while an online update of the boot file was being performed, the unmodified old boot file would be used, because the last written copy of the root directory still had the old boot file; the new root directory would not be written until the new copy of the boot file was flushed. It's not much harder than loading a file from FAT, with the benefit that its impossible to have a corrupt or missing boot file as a result of the P2 rewriting its own boot file.
EDIT: I'm talking about log-structured filesystems and not journalled filesystems, because log-structured filesystems are always consistent on-disk, the cost being that when writing, lots of metadata caching needs to be done since the metadata needs to be written back in a particular order to maintain this consistency invariant, and that garbage collection, which is tricky because it also has to maintain the consistency invariant, has to happen every so often because you can almost never rewrite blocks in-place, so you have to leave old data lying around for some time after it's not needed. However, this doesn't affect booting; no writing will occur until after the bootloader is finished, and nothing fancy needs to be done just to read the FS.
For the sake of repeating again, you can place whatever P2ASM code you want into the MBR/VOL/TAT32/anywhere on the SD card. It will just boot the P2 with whatever you place there. So, you can put an extended TAQOZ there if you want.
But an extended TAQOZ would never fit in the MBR, and there's nowhere else to put it that's as safe that would be easy for a PC with a custom filesystem driver to understand (e.g. no boot image partition and no unpartitioned region that really has the boot image). The TAQOZ in ROM is perfectly fine; it just has to be started in a nonstandard way to do what I want. A small PASM stub at the beginning of the MBR boot code that starts the ROM copy of TAQOZ in such a way that it runs TAQOZ bytecode found in the rest of the MBR boot code area would be a more practical way to make a bootloader that boots a non-FAT filesystem that potentially takes up the whole SD card except for the MBR, without relying on an initial FAT partition just for booting off of.
Stop over-complicating it. Re-read the info on how the SD Boot works.
You can have a short stub of code in the MBR (if you want) that will load more code. Or you can place a sector address and length in the MBR and it will load this code and run it. You don't need FAT32 if you don't want it. It works just fine with exFAT using the MBR instead.
It doesn't have to be that hard to boot off of a log-structured file system. Consider a theoretical log-structured file system that stored a pointer to the boot file in a special place in the root directory every time it saved the root directory. It would be easy to boot off of this: read the superblock, read the last saved root directory pointed to by the superblock, read the boot file inode pointed to by the root directory, and then read into RAM all the blocks pointed to in the block indirection table in the boot file's inode into RAM. If power failed while an online update of the boot file was being performed, the unmodified old boot file would be used, because the last written copy of the root directory still had the old boot file; the new root directory would not be written until the new copy of the boot file was flushed. It's not much harder than loading a file from FAT, with the benefit that its impossible to have a corrupt or missing boot file as a result of the P2 rewriting its own boot file.
Re-read the info.
The FAT32 boot supports two filenames. If you want to write a new file, name it the second one, and when done, delete the first.
Why complicate things further. You have total control in a number of ways.
EDIT: I'm talking about log-structured filesystems and not journalled filesystems, because log-structured filesystems are always consistent on-disk, the cost being that when writing, lots of metadata caching needs to be done since the metadata needs to be written back in a particular order to maintain this consistency invariant, and that garbage collection, which is tricky because it also has to maintain the consistency invariant, has to happen every so often because you can almost never rewrite blocks in-place, so you have to leave old data lying around for some time after it's not needed. However, this doesn't affect booting; no writing will occur until after the bootloader is finished, and nothing fancy needs to be done just to read the FS.
This is a micro, not a PC Server.
BTW you can write a very simple MBR bootloader that will jump straight to TAQOZ. You just need to set the serial up followed by a "JMP absolute to TAQOZ" (1 long) and the "Prop" Identifier in the MBR.
BTW(2) You can even patch the BOOT ROM code (in HUB) and then execute it. What you do in the MBR/VOL/etc is up to you! We have given you the method.
Complaining that a microcontroller doesn't support a journaling FS out of the box is a bit over the top. What microcontroller does? Not even the PI does, at boot. It uses the UEFI boot process which, uses FAT.
Can we put this to bed? We have a *GREAT* boot process off of SD.
I could imagine that a journaling FS is great for O/S's like Linux where there are tens or hundreds of thousands of files and with many being created and updated many times a second. But the JFS would end up wearing out poor ol SD Flash and why would we need it anyway? This is an embedded control system with maybe only a handful of files and I like to preallocate all the sectors that I need for say a log file so that when it becomes full I move onto a new file, but what I don't do is update the directory constantly with time stamps and file size, since that is easy enough to do on startup and read the file and update it once etc. Anyway, there are lots of techniques that suit embedded systems and SD Flash.
I spoke to Cluso99 about the next ROM in that if information about the system is stored in fixed locations in SPI Flash and/or SD, then we can switch to high speed crystal/osc mode. This also obviates any need for a secondary boot loader, because if you were able to write a secondary boot loader that knew what clock rate it could run at, then you already know the details to switch clock. Therefore if that config info is available then on SPI/SD then both the SPI Flash loader and the SD loader can load at high speed rather than RCFAST.
Comments
They made them.I had a phone that came with a 32mb micro sd. They called it transflash. I bought a (very expensive) 128mb card for it to put my music on. They come up to 2gb. (supposedly the standard actually goes up to 4gb and they exist but are rare) I just purchased four 2gb cards for my old Nikon SLR that requires standard SD cards. All I could find at a reasonable price were the micro SD cards, so I use them in an adapter.
the term). I believe the interface is/was mainly compatible.
Wikipedia seems to back this up somewhat: https://en.wikipedia.org/wiki/Secure_Digital#Micro-cards
But it'd be nice if a flash chip weren't necessary, for BOM cost and boot time and complexity. It could probably be done without external flash if there were a way to run TAQOZ bytecode out of the MBR, since TAQOZ bytecode is denser than PASM. It should be possible to do it without the tools for doing this being part of TAQOZ, but it'd be nice, especially for Windows users where it's harder to do custom disk formatting, if TAQOZ could do this itself.
One could partition the card, use the existing boot methods, and put the robust file system into remaining card space, which could be substantial. I don't think that eliminates too much of the risk. I have had a lot of silly Smile happen to SD cards. I think there is significant risk, in some cases. It really depends on where the product is running and under what conditions. I've got people's hands on products, and they do an amazing number of unexpected and or dumb things. In one case, where there was constant corruption, I found out they were just connecting a monitor when they needed it. That connect, disconnect, on a Raspi, would glitch SD cards pretty consistently. Of course, reimage and redeploy works fine, mostly. I have a couple cards that were done on the first failure. (midnight special cards too, known risk!)
A best case is to only bring up what is needed to only touch the card when best support is up and running. This is what I would do personally. Ideally, that means not even powering the card, until it's time.
When SD cards are active, transients in the power, ejects, mechanical vibration, even thermal things can all glitch the card.
The nice thing is filesystem tools and or some other nice boot options can all be presented in case of trouble with the card. Frankly, with any filesystem, I'm inclined to setup future P2 systems with good stuff in flash. Some boot, and operation will be possible, sans a card.
But an extended TAQOZ would never fit in the MBR, and there's nowhere else to put it that's as safe that would be easy for a PC with a custom filesystem driver to understand (e.g. no boot image partition and no unpartitioned region that really has the boot image). The TAQOZ in ROM is perfectly fine; it just has to be started in a nonstandard way to do what I want. A small PASM stub at the beginning of the MBR boot code that starts the ROM copy of TAQOZ in such a way that it runs TAQOZ bytecode found in the rest of the MBR boot code area would be a more practical way to make a bootloader that boots a non-FAT filesystem that potentially takes up the whole SD card except for the MBR, without relying on an initial FAT partition just for booting off of.
It doesn't have to be that hard to boot off of a log-structured file system. Consider a theoretical log-structured file system that stored a pointer to the boot file in a special place in the root directory every time it saved the root directory. It would be easy to boot off of this: read the superblock, read the last saved root directory pointed to by the superblock, read the boot file inode pointed to by the root directory, and then read into RAM all the blocks pointed to in the block indirection table in the boot file's inode into RAM. If power failed while an online update of the boot file was being performed, the unmodified old boot file would be used, because the last written copy of the root directory still had the old boot file; the new root directory would not be written until the new copy of the boot file was flushed. It's not much harder than loading a file from FAT, with the benefit that its impossible to have a corrupt or missing boot file as a result of the P2 rewriting its own boot file.
EDIT: I'm talking about log-structured filesystems and not journalled filesystems, because log-structured filesystems are always consistent on-disk, the cost being that when writing, lots of metadata caching needs to be done since the metadata needs to be written back in a particular order to maintain this consistency invariant, and that garbage collection, which is tricky because it also has to maintain the consistency invariant, has to happen every so often because you can almost never rewrite blocks in-place, so you have to leave old data lying around for some time after it's not needed. However, this doesn't affect booting; no writing will occur until after the bootloader is finished, and nothing fancy needs to be done just to read the FS.
You can have a short stub of code in the MBR (if you want) that will load more code. Or you can place a sector address and length in the MBR and it will load this code and run it. You don't need FAT32 if you don't want it. It works just fine with exFAT using the MBR instead. Re-read the info.
The FAT32 boot supports two filenames. If you want to write a new file, name it the second one, and when done, delete the first.
Why complicate things further. You have total control in a number of ways. This is a micro, not a PC Server.
BTW you can write a very simple MBR bootloader that will jump straight to TAQOZ. You just need to set the serial up followed by a "JMP absolute to TAQOZ" (1 long) and the "Prop" Identifier in the MBR.
BTW(2) You can even patch the BOOT ROM code (in HUB) and then execute it. What you do in the MBR/VOL/etc is up to you! We have given you the method.
Can we put this to bed? We have a *GREAT* boot process off of SD.
I spoke to Cluso99 about the next ROM in that if information about the system is stored in fixed locations in SPI Flash and/or SD, then we can switch to high speed crystal/osc mode. This also obviates any need for a secondary boot loader, because if you were able to write a secondary boot loader that knew what clock rate it could run at, then you already know the details to switch clock. Therefore if that config info is available then on SPI/SD then both the SPI Flash loader and the SD loader can load at high speed rather than RCFAST.
Mike