I still don't see any reason not to use a file for booting...
I think this is what Android does.
The Docs call for a 16kB ROM. That's plenty of space for FAT reading code.
I think FSRW can be as small as 2kB and probably smaller when converted to P2 code...
Reading of files using a filesystem will always be after the first stage boot. There is too much chance for going out of date or just flawed. Not to mention it's also FAT only then.
If a SPI_Flash part was included then there is no need for any SD based reserved boot image.
I would not try to make a bootloader that had to know the filesystem or variation involved, it is good enough to give it a sector to start with even if that sector were previously provided by the runtime filesystem. The other use for SD boot is simply to upgrade firmware in the field quickly and easily. No need for programming cables, the right software and drivers etc, just download the file onto the card and the initial SD boot code can then locate and load that new file, otherwise it's the hidden SD boot code, or else the SPI Flash, or else serial boot.
Many of my systems would have an SPI Flash anyway so the SD boot is a way of getting code on there in the first place during production but as mentioned also a good way to upgrade the existing firmware.
I would not try to make a bootloader that had to know the filesystem or variation involved, it is good enough to give it a sector to start with even if that sector were previously provided by the runtime filesystem. The other use for SD boot is simply to upgrade firmware in the field quickly and easily. No need for programming cables, the right software and drivers etc, just download the file onto the card and the initial SD boot code can then locate and load that new file, otherwise it's the hidden SD boot code, or else the SPI Flash, or else serial boot.
Many of my systems would have an SPI Flash anyway so the SD boot is a way of getting code on there in the first place during production but as mentioned also a good way to upgrade the existing firmware.
I agree with Peter that a bootloader should know nothing about the filesystem.
Just short boot code in the MBR sector(s) of the SD will suffice to get the system booting. It should be CRCC checked and a pointer to a sector containing the remaining boot code is all that is wanted/needed. Those sectors would most likely be the data in a file, but it does not have to be so.
FWIW I have not had any problems reading any of the SD and microSD cards I have here and many of them are not SanDisk because they came from Phones and Cameras. I do however always recommend SanDisk because they seem to just work.
I don't think booting from removable media is a very good idea.
But, I could see someone wanting that to reduce costs...
Thinking some more about the ways someone may want to boot, it could make sense to add check for i2c device on the SPI pins, before doing a SPI load ? (and boot if one is found?)
The time overhead is very small :
i2c parts spec 1MHz even at 1.8V, and even at a conservative 400kHz roughly 32us is needed to Test/Skip.
i2c memory is cheap in smaller sizes, and I see even 256k comes in 2x3mm QFN and 3x3MSOP8
It also some in smaller packages than smaller-sized SPI memory.
ie if Size/price is the important target, i2c has more choices at the smaller end.
My preference is to follow MBR compliant boot process. There is two reasonable options here:
- Either load and execute just block 0 as a boot-block. Everything else is up to that small code.
- Or, read the partition table at block 0 to locate a Prop boot partition then load a full boot image from that partition.
Is MBR with partition table? If not, goto block boot.
Is there a Propeller partition? (specify with partition type, and we tested this idea earlier and can either go with that type, or just pick one now, doesn't matter) If so, get block offset to beginning of partition, go to block boot.
Is there a FAT partition? If so, get block offset to beginning of first file, go to block boot.
Block boot:
By default, reads blocks sequentially, starting from block 1, until end of boot image marker is encountered, or image size specified. Boot image is contained in block 0 to 0+xxx however long that image is.
Optionally, it will read blocks sequentially, starting at block offset captured in the test cases, until end boot image marker encountered, or image size specified. Boot image is contained in [block offset] to [block offset]+xxx, however long the boot image is.
When done, it proceeds with the rest of the chip boot process.
Any other SD card support needs to be supplied in the boot image.
To me, that's the ideal. People can just put an image on the SD card in block form, no partitions, no filesystem, nothing. And this will work, and it's single purpose. They own the whole SD card. I think a few people will do this.
People can also do the FAT first file hack too. Format the SD card with a FAT partition, and then copy their boot image to a file, and just make sure it's the very first file. That file will be sequential, and it will work. They don't own the whole SD card, but additional files copied via PC or other environment are easy to do, and their boot code can offer full filesystem support, if desired. I think a larger number of people will do this because it's easy and can be done on any OS with standard tools, or maybe some SD card format tool worst case. Good for Windows users in particular. This is sort of, if you are careful, multi-purpose. P2 + something else that understands files.
People can optionally make a Propeller partition. On Linux, this can be done with standard tools. I didn't test FDISK on Windows, but I'll bet it works too. I will test it, if we go there. Either way, people make a partition and they copy their boot image to it. They own the whole partition. If they desire PC data support, they also add a FAT partition. Their boot code offers filesystem support, if desired. They do whatever they want with the FAT partition on a PC, or P1/P2 or other environment, without having to worry about potentially corrupting a boot file, because the boot file is in it's own partition. I think some people will do this. I want to do this, because I prefer partitions when we aren't really offering full filesystem support and because it's robust, and I think a best practice when not providing full filesystem support. This is multi-purpose. P2 + something else that understands files.
All that said, I don't care. Just an, "If I were king..." suggestion.
If we decide a simpler SD card system makes sense, the more advanced functionality I put here can simply be done with one of the other boot methods, and that is just fine with me.
I think the consensus was to make it read-only (in ROM), and it needs some mode-reset house-keeping as mentioned earlier in this thread, and a preamble (as you mentioned) will allow 2/3/4 byte address lengths to be tolerated.
I think a link was given to a SD loader, so it comes down to how much ROM is available
If the load-image length is read from the header, then a fast load of a second stage loader is supported, and anyone who wants to branch from default can do that there.
It may be worth looking at i2c-present boot check, as that allows smallest/cheapest user memories (eg someone could do i2c and SD for example)
For above-moderate code sizes, SPI flash wins, and for large designs, and initial-loading, SD boot allows PC-less updates.
Please don't talk about what processes take place in any second stage booting. It just confuses things.
Hardly - it serves to clarify what is NOT being done in the ROM loader.
What is NOT done, is perhaps more important to be very clear on, as everyone has varying ideas on what 'boot' means.
All we need to do is read some boot code out of an SD card.
Yes. I was getting a bit annoyed at the excessive extended descriptions being offered up that are going well beyond what you are asking for in this first stage boot.
I would like to get a consensus that MBR compliance is a valuable guide to work to before even deciding on any particular ID/preamble/checksumming/whatever.
Simplicity does not mean unnecessary restrictions which would be an annoyance, if you can read sector 0 then it is just as easy to have a pointer to the start of the actual image in another sector. Different formatting schemes may use some areas of the MBR and we may only have 218 bytes in some. I do not wish to become DOS "compliant", we just need a signature, a pointer, size, and a CRC (or checksum) for the image and perhaps the header. I am actively using SD FAT32 virtual memory now with the P2, it would be good to be able to create a file with the current image which I can point to from the boot sector.
If the SD mode doesn't work with a regularly formatted SD card, I personally wouldn't use it.
Sounds like boot from SPI is what I'd use. How much is going to be loaded?
The full 512kB? That would be simplest. Would take about 1/2 a second, right?
Where does all this confusion come from? A "regularly formatted" card will have an MBR but depending upon which O/S this is done on most will have 446 bytes available while some may only have 218 bytes available. No need to make a tiny cramped little corner for us to work out of when the same ROM code that was used to read sector 0 can just as easily detect a P2 bootloader header with the sector number to load an image from.
When we are talking about SD cards we are also talking about SPI mode as 4-bit SD mode is NDA and $$$$ license fees. So we boot from SD in SPI mode of course, read P2BL signature in sector 0, read pointer to image sector and size, then just sit there reading sectors into RAM, check CRC and run. No need ever to load in a full 512k memory as I can't see that much memory being used just for code when we need bIg buffers for video and many other things. I'm reading a byte per microsecond even with the 50MHz clock so at 160Mhz and 128k code size it should read in around 50ms but quite possibly even faster once we get smartpins working.
It's not clear to me that even 1-bit mode doesn't require you pay fees to use...
Looks to me that if you sell a product with a port labelled "SD", you have to pay.
I know HDMI is that way. You can use an HDMI jack for free. But, as soon as you label it "HDMI" or advertise it as having "HDMI", then you have to pay.
I could be wrong, but I think the same license terms apply for both 1-bit and 4-bit mode...
Actually, wikipedia says no license needed for SPI mode.
But, the P1 forum has a reply from SD association saying you do need to sign their license to use SPI mode with SD card. And, I think you have to join (I.e., pay money) to do that...
But, if you say you're using MMC (and don't say SD), then it looks free...
Would it be possible to check for all options for booting by sensing a pin as analog input with very weak pull down and even weaker pull up. The ratio of the divider selects SPI boot device:
1. SPI chip
2. SD card with out file system
3. SD card with file system.
If not, I would opt for the SD card with MBR and file system support.
The Raspi uses a FAT a partition for boot information, and a tool is available for reading and writing images under Windows. It is also very easy to use. Perhaps that tool, if open source, could be modified to support Propeller SD boot modes if necessary.
SD cards can be detected using the pullup present on the "SPI chip select" line internal to the SD card AS LONG as a pullup is not used externally. In fact I don't any pullups at all on my SD lines. But I would not expect the ROM bootloader to wrangle with a filesystem, just the raw card however a partition is another possibility except any file placed there would still need to be found. All good and well for a well-heeled RPi but an RPi the P2 is not.
Sounds like boot from SPI is what I'd use. How much is going to be loaded?
The full 512kB? That would be simplest. Would take about 1/2 a second, right?
I believe there is a length param now in the loaded image, so you load as many bytes as the image says to.
That allows small stub loaders, and 1/2 second is a very long time for some systems.
The Raspi uses a FAT a partition for boot information, and a tool is available for reading and writing images under Windows. It is also very easy to use. Perhaps that tool, if open source, could be modified to support Propeller SD boot modes if necessary.
That sounds like a great place to start, and as a good number of users will be mixing the two, it makes sense to ensure there are no clashes - ie a Prop SD should co-exist with a Raspi one.
Simplicity does not mean unnecessary restrictions which would be an annoyance, if you can read sector 0 then it is just as easy to have a pointer to the start of the actual image in another sector. Different formatting schemes may use some areas of the MBR and we may only have 218 bytes in some. I do not wish to become DOS "compliant", we just need a signature, a pointer, size, and a CRC (or checksum) for the image and perhaps the header. I am actively using SD FAT32 virtual memory now with the P2, it would be good to be able to create a file with the current image which I can point to from the boot sector.
Come on guys, this is getting hard work, MBR in no way means DOS! It doesn't even mean FAT is a requirement. It just means we are not forcing everyone to rearrange their SD cards to an arbitrary layout that only the Prop tools understands. Complying means we are leaving things more open. Surely that's worth pursuing?
Is it okay if your pointer for the boot image can come from the Prop's partition entry of an ordinary partition table?
I was thinking p1 speed... If p2 can read at 80 MHz, loading full 512 kB might be less than 100 ms
Tier 1 (ROM) loading will have to be at some safe default MHz and 80MHz is a bit high for many SPI memories.
(eg RAM based SPI is 20MHz spec'd)
Loading is also from RC osc, so there will be a margin there too, and likely Pre-PLL defined.
Tier 2 loading, is under user control, so that can flip to Quad modes and whatever MHz the designer knows their memory can support.
The Raspi uses a FAT a partition for boot information, and a tool is available for reading and writing images under Windows. It is also very easy to use. Perhaps that tool, if open source, could be modified to support Propeller SD boot modes if necessary.
I imagine this tool builds a singular boot block encoded with the block numbers of where the file is distributed in the FAT partition. Something like this is also an option for the Prop2 and still happily be MBR compliant. It could be via the executable boot block or it could be a raw block list (excluding partition table).
Comments
I think this is what Android does.
The Docs call for a 16kB ROM. That's plenty of space for FAT reading code.
I think FSRW can be as small as 2kB and probably smaller when converted to P2 code...
If a SPI_Flash part was included then there is no need for any SD based reserved boot image.
Many of my systems would have an SPI Flash anyway so the SD boot is a way of getting code on there in the first place during production but as mentioned also a good way to upgrade the existing firmware.
Just short boot code in the MBR sector(s) of the SD will suffice to get the system booting. It should be CRCC checked and a pointer to a sector containing the remaining boot code is all that is wanted/needed. Those sectors would most likely be the data in a file, but it does not have to be so.
FWIW I have not had any problems reading any of the SD and microSD cards I have here and many of them are not SanDisk because they came from Phones and Cameras. I do however always recommend SanDisk because they seem to just work.
That said, this would be part of second stage booting so doesn't impact the Prop2 mask ROM as it only deals with executing the boot block.
Thinking some more about the ways someone may want to boot, it could make sense to add check for i2c device on the SPI pins, before doing a SPI load ? (and boot if one is found?)
The time overhead is very small :
i2c parts spec 1MHz even at 1.8V, and even at a conservative 400kHz roughly 32us is needed to Test/Skip.
i2c memory is cheap in smaller sizes, and I see even 256k comes in 2x3mm QFN and 3x3MSOP8
It also some in smaller packages than smaller-sized SPI memory.
ie if Size/price is the important target, i2c has more choices at the smaller end.
So, here is the boot order:
1) Serial
2) SPI Flash
3) SPI Flash for SD card
We need to nail down how we do the SD card boot, exactly. We'll use a $03 read command, but then what?
I'm glad you guys have been thinking about this. I avoided reading this thread for a while, because my stack was full, but it's down now.
- Either load and execute just block 0 as a boot-block. Everything else is up to that small code.
- Or, read the partition table at block 0 to locate a Prop boot partition then load a full boot image from that partition.
Check SD:
Read sector 0
Check cases:
Is MBR with partition table? If not, goto block boot.
Is there a Propeller partition? (specify with partition type, and we tested this idea earlier and can either go with that type, or just pick one now, doesn't matter) If so, get block offset to beginning of partition, go to block boot.
Is there a FAT partition? If so, get block offset to beginning of first file, go to block boot.
Block boot:
By default, reads blocks sequentially, starting from block 1, until end of boot image marker is encountered, or image size specified. Boot image is contained in block 0 to 0+xxx however long that image is.
Optionally, it will read blocks sequentially, starting at block offset captured in the test cases, until end boot image marker encountered, or image size specified. Boot image is contained in [block offset] to [block offset]+xxx, however long the boot image is.
When done, it proceeds with the rest of the chip boot process.
Any other SD card support needs to be supplied in the boot image.
To me, that's the ideal. People can just put an image on the SD card in block form, no partitions, no filesystem, nothing. And this will work, and it's single purpose. They own the whole SD card. I think a few people will do this.
People can also do the FAT first file hack too. Format the SD card with a FAT partition, and then copy their boot image to a file, and just make sure it's the very first file. That file will be sequential, and it will work. They don't own the whole SD card, but additional files copied via PC or other environment are easy to do, and their boot code can offer full filesystem support, if desired. I think a larger number of people will do this because it's easy and can be done on any OS with standard tools, or maybe some SD card format tool worst case. Good for Windows users in particular. This is sort of, if you are careful, multi-purpose. P2 + something else that understands files.
People can optionally make a Propeller partition. On Linux, this can be done with standard tools. I didn't test FDISK on Windows, but I'll bet it works too. I will test it, if we go there. Either way, people make a partition and they copy their boot image to it. They own the whole partition. If they desire PC data support, they also add a FAT partition. Their boot code offers filesystem support, if desired. They do whatever they want with the FAT partition on a PC, or P1/P2 or other environment, without having to worry about potentially corrupting a boot file, because the boot file is in it's own partition. I think some people will do this. I want to do this, because I prefer partitions when we aren't really offering full filesystem support and because it's robust, and I think a best practice when not providing full filesystem support. This is multi-purpose. P2 + something else that understands files.
All that said, I don't care.
If we decide a simpler SD card system makes sense, the more advanced functionality I put here can simply be done with one of the other boot methods, and that is just fine with me.
I think the consensus was to make it read-only (in ROM), and it needs some mode-reset house-keeping as mentioned earlier in this thread, and a preamble (as you mentioned) will allow 2/3/4 byte address lengths to be tolerated.
I think a link was given to a SD loader, so it comes down to how much ROM is available
If the load-image length is read from the header, then a fast load of a second stage loader is supported, and anyone who wants to branch from default can do that there.
It may be worth looking at i2c-present boot check, as that allows smallest/cheapest user memories (eg someone could do i2c and SD for example)
For above-moderate code sizes, SPI flash wins, and for large designs, and initial-loading, SD boot allows PC-less updates.
Hardly - it serves to clarify what is NOT being done in the ROM loader.
What is NOT done, is perhaps more important to be very clear on, as everyone has varying ideas on what 'boot' means.
All we need to do is read some boot code out of an SD card.
We just need to determine a reliable and fast way of doing that.
How much code can you allocate to the item 3) SD- ROM area ?
What else is planned for the ROM ?
Yes. I was getting a bit annoyed at the excessive extended descriptions being offered up that are going well beyond what you are asking for in this first stage boot.
I would like to get a consensus that MBR compliance is a valuable guide to work to before even deciding on any particular ID/preamble/checksumming/whatever.
You can do a lot with 100 instructions. How much does it take?
Sounds like boot from SPI is what I'd use. How much is going to be loaded?
The full 512kB? That would be simplest. Would take about 1/2 a second, right?
When we are talking about SD cards we are also talking about SPI mode as 4-bit SD mode is NDA and $$$$ license fees. So we boot from SD in SPI mode of course, read P2BL signature in sector 0, read pointer to image sector and size, then just sit there reading sectors into RAM, check CRC and run. No need ever to load in a full 512k memory as I can't see that much memory being used just for code when we need bIg buffers for video and many other things. I'm reading a byte per microsecond even with the 50MHz clock so at 160Mhz and 128k code size it should read in around 50ms but quite possibly even faster once we get smartpins working.
Looks to me that if you sell a product with a port labelled "SD", you have to pay.
I know HDMI is that way. You can use an HDMI jack for free. But, as soon as you label it "HDMI" or advertise it as having "HDMI", then you have to pay.
I could be wrong, but I think the same license terms apply for both 1-bit and 4-bit mode...
Actually, wikipedia says no license needed for SPI mode.
But, the P1 forum has a reply from SD association saying you do need to sign their license to use SPI mode with SD card. And, I think you have to join (I.e., pay money) to do that...
But, if you say you're using MMC (and don't say SD), then it looks free...
1. SPI chip
2. SD card with out file system
3. SD card with file system.
If not, I would opt for the SD card with MBR and file system support.
The Raspi uses a FAT a partition for boot information, and a tool is available for reading and writing images under Windows. It is also very easy to use. Perhaps that tool, if open source, could be modified to support Propeller SD boot modes if necessary.
That allows small stub loaders, and 1/2 second is a very long time for some systems.
That sounds like a great place to start, and as a good number of users will be mixing the two, it makes sense to ensure there are no clashes - ie a Prop SD should co-exist with a Raspi one.
Even if I did have a huge video buffer, I might want to preload it with a splash screen so that video output starts right away
The length parameter sounds nice
Come on guys, this is getting hard work, MBR in no way means DOS! It doesn't even mean FAT is a requirement. It just means we are not forcing everyone to rearrange their SD cards to an arbitrary layout that only the Prop tools understands. Complying means we are leaving things more open. Surely that's worth pursuing?
Is it okay if your pointer for the boot image can come from the Prop's partition entry of an ordinary partition table?
(eg RAM based SPI is 20MHz spec'd)
Loading is also from RC osc, so there will be a margin there too, and likely Pre-PLL defined.
Tier 2 loading, is under user control, so that can flip to Quad modes and whatever MHz the designer knows their memory can support.
I imagine this tool builds a singular boot block encoded with the block numbers of where the file is distributed in the FAT partition. Something like this is also an option for the Prop2 and still happily be MBR compliant. It could be via the executable boot block or it could be a raw block list (excluding partition table).
1 - Either load and execute just block 0 as a boot-block. this can then proceed to perform options 2 and 3 as a second stage boot.
2 - Or, read the partition table at block 0 to locate a Prop boot partition then load and execute a full boot image from that partition.
3 - Or, read block 0 as a block list of boot image distribution on the drive - Load and execute them as a full boot image.