If we are gonna do this, I very strongly recommend a partition.
Mere block support sort of works, until it doesn't. Depending on "first file" copied to fresh SD card to insure contiguous space works, until it doesn't too.
All that is needed is to make a propeller partition, and make it's type empty, or just not FAT or something recognizable. I did this last time, and the data is in the hot threads. I can find it, but the gist of it was:
1. Make partition. Under Linux, this is dead simple.
2. Prop reads MBR, sees partition, collects block offset
3. Prop reads blocks from block offset to obtain whatever it's boot image is going to be.
User copies image into partition using "dd" or similar. We could make a little exe for windows that adds a partition without too much trouble. And a P2, once running, could very easily prep additional SD cards, as can a P1 right now!
It's not hard to do this, and if we do, we've added the minimum device support to get along with the rest of the world with no hassles.
Partition support is the working minimum when there isn't a filesystem, and the storage device isn't single purpose. If that SD ends up in a PC at any time, it's not single purpose.
I submit the SD card will rarely be single purpose. The compelling idea of SD card boot is we get a boot device, but we also get a filesystem, and or assets, data, code, whatever we want on that filesystem that is very easily manipulated by an average user on a PC of some kind. A really common use case is going to be to provide signed booter, for a prop with fuses set, an unsigned one for a prop with open fuses. That booter will boot, be filesystem aware, and run whatever things a user has copied over with a PC. Partition support will insure this works well.
When we pick a partition ID well, windows ignores it, and that keeps the boot blocks out of harm's way. They can use the exe, or a P1, or a P2, or Linux to prep the card, and put their boot image on it. Once this is done, refreshing the boot image is dead simple.
From there, that boot image can be filesystem aware. If it is, they then can drop their own files onto a FAT partition, and that's dead simple too.
Doing this will save people a lot of grief and it would make using an SD card with P2 simple, robust and powerful.
I did grab a whole pile of SD cards at the time we were discussing this and all of that allowed for a partition. I booted Ubuntu at the time and just ran a few commands to get it all done. Again, a small script, exe file, or P1 / P2 prepped to do this isn't hard.
I'll go track down the work done last time, just for reference in this discussion.
Again, if we are gonna do this, it's attractive from a "shiny thing" feature standpoint, but I would really prefer it not be a hack. A handful of instructions will read the MBR, correctly identify the partition block offset. That's real support, best practice. IMHO, that is what the chip should do, if we decide to put SD into the booter of the chip.
Yes. I'm actually on the fence with the concerns Kye expressed. They are valid, but they can be designed for too. My preference is to boot with something else that then handles the SD, but if we go with SD, let's do it best practice so that the SD works as expected for people. Partitions are how we do that when we aren't providing real filesystem support.
Here is a link to my final solution for the SD card booter in an old thread. It works with a second partition, or with a pointer in sector 0, or will search a file with a signature if no partition or pointer found. Always only do a search is way too slow - it can take 20 seconds to search through the first 1 MB.
The size of the bootcode is under 200 longs as far as I remember.
PS: Another way to put this is: It's important that SD not be the primary cold boot device.
Agreed, but I don't think the plan was for SD to be the primary cold boot device?
A more formal SD boot should always be after the simplest SPI boot.
A header tagged system is simple, and allows varying reply delays.
A quick look finds 15c/1k 25C16 devices in small packages, with 03H read command and 16b Addr (SO on 24th clk)
Larger parts are not much more expensive, 23c/1k for 4MBit, with 24b address (SO on 32nd CLK)
(that's cheaper than a 24C256 i2c device)
Even larger parts move to 32b address (SO on 40th clk)
The header tag would wait for the start on all cases, and a simple offset of a few bytes would allow the same image (small) to be placed into any SPI candidate. An upgrade from 24b Adr to 32b Adr SPI would still work.
MISO pin would likely have a pullup resistor enabled.
I don't think booting from removable media is a very good idea.
But, I could see someone wanting that to reduce costs...
Shouldn't take too much rom space for code to mount sd and then scan root directory for a certain filename
This was all discussed in a long thread a couple of years ago.
IMHO it was derailed by scaremongering.
IMHO a simple SD boot should be possible that does not require a Flash device to be present. It only adds unnecessary cost and space if a SD device will always be present.
There are boot sectors present on an SD card which can be used to start a full loader in whatever format the user requires.
Either consider SD as the optional primary boot device (check Flash first, then SD), or stop this discussion now! The solution is simple but I am not going to waste my time until it's agreed to make SD a bootable device without flash, if flash is not found.
For reference, I have shipped prop boards that have a simple SD boot loader in EEPROM. I have not had any problems although I do recommend using SanDisk SD cards.
Heck, as long as SD is the second or third boot option, flash and serial will work just fine right?
Those of us who want to go the SD route do, and if it goes bad, others of us get "told 'ya" rights and everyone has a solid fall back.
If there is a partition aware scheme, great: otherwise, I know I'll be using a flash loader that then uses the SD in a file system aware way. And if there is a partition, I'll just do the same, so that the experience from there is just files and names.
I don't know why there wouldn't be room in ROM to try a couple different brands of SPI flash... You just go through a list and try to read the device ID and then you know what you have...
I think the original proposal was for SPI EEPROM, I note JMG has just listed one, rather than SPI Flash. So, it was just a bit of confusion there. SPI Flash is not an option.
I haven't looked at this in a long time, but I have to think that if there were a 512kB SPI eeprom, it would be very expensive and compared to SPI flash.
Just checked Digikey and there is one option there, but it is out of stock and MOQ is 3000 pieces... Was less than a dollar at that qty. though.
The READ command seems universal at 03H and if a simple start string is used (as Chip mentions) as begin-key, then the 2/3/4 byte address fields are supported by that.
That represents a very wide range of possible valid boot devices, from small Eeproms to medium-size minimum cost SPI FLASH, to larger FLASH Serial parts with 32b address fields.
Primary boot (ROM) can be quite small, (1 bit SPI) and from there user code can invoke fancier secondary boot, like QuadSPI-DDR for example. (or fast MODE SD or smarter SD boot... )
I haven't looked at this in a long time, but I have to think that if there were a 512kB SPI eeprom, it would be very expensive and compared to SPI flash.
Just checked Digikey and there is one option there, but it is out of stock and MOQ is 3000 pieces... Was less than a dollar at that qty. though.
Yes EEPROM have poor price/bit compared to Flash, but I listed one above because it comes in small packages, for a lower price than small package FLASH.. thus it may make sense for primary boot, then advanced SD boot.
I think there is way to much confusion regarding what is being asked for. Let me reiterate:
1. Update the P2 bootloader to handle th 25Q80 SPI Flash that I have on my DE2-115 adaptor
2. If possible also allow for boot from standard SD SDHC cards from fixed sectors, no filesystem/partition checking.
So I need #1 to be able to really exercise my system as a stand-alone development system rather than being reliant upon PNut to boot the P2.
Now SD is very very easy to interface, just SPI mode only, I don't know what QSPI has to do with this at all other than the fact that there is a licensed 4-bit SD mode which us unlicensed users don't use. Use SECTOR ZERO which has plenty of free space either for a second-stage SD bootloader or for the pointer/crc/metadata to a fixed absolute sector. Since SECTOR ZERO is always the same with an MBR format then it doesn't matter what partition or FAT method etc is used, as long as we have access to SECTOR ZERO then the boot image sector it points to can be the start sector of a file or anything. EASY.
In reference to something that Cluso99 mentioned please don't let this option be "derailed by scaremongering". It's simple, quick, easy, and an OPTION.
EDIT: Just specify genuine SANDISK and if anyone wants to take a chance with other less compliant brands then that's their worry.
Here I threw some P2 code into the first 256 bytes of sector 0 and had it write a header and absolute sector and crc in the first 32 bytes. No problems.
BTW. $1581C0 at 00.0010 is actually the start sector of the file "P2BOOT.IMG".
So I need #1 to be able to really exercise my system as a stand-alone development system rather than being reliant upon PNut to boot the P2.
So you mean SPI boot is tried first, then SD load ?
I think actual Boot order is
1) Serial ( timeout = ??, skip-UART load pin ? )
2) SPI (1 bur using 0x03 READ ) ( what MHz SCK ?)
3) Possible Other (here SD) ?
There is also the problem I see of varying specs for SPI Flash including the rather large and variables "sectors" whereas SD is very easy to handle with nice little even 512 byte sectors and a standardized protocol and command even from brand to brand etc.
To be clear on the SD support: Any SD card functionality in the Prop2 mask ROM puts a burden of commitment to implementing a power control circuit to the SD card on at least all early reference designs.
I interpret Peter's #1 as only needed temporarily just for FPGA based testing.
The finished Prop2 will support SPI EEPROM instead.
That's not my understanding.
Primary device Boot BOM will focus on the price sweet-spot of SPI Flash, not EEPROM.
Present sweet-spot looks around 4-8Mb & before P2 is real, that will likely move upwards.
8Mb+ is a natural P2 size, as that matches the ~2x Memory headroom of P1 products.
SO-8 is cheapest, but largish, and if I focus on smallest-package parts, eg 3x3mm gives 32Mbit
N25Q032A13EF440E Micron 39c/3k
Addit: Digikey search missed a few :
Winbond 2x3mm package
W25Q40CLUXIG 4Mb 31c/4k
W25Q80BLUXIG 8Mb 35c/4k
There is also the problem I see of varying specs for SPI Flash including the rather large and variables "sectors" whereas SD is very easy to handle with nice little even 512 byte sectors and a standardized protocol and command even from brand to brand etc.
? SPI Sector size does not affect boot ?
All you need to SPI boot, is to be able to start streaming data, from a fixed location, and that just needs a 0x03 READ command and then 32b of 0x000000 sent.
That can address all SPI parts with 16/24/32b address fields. (covers 2k bytes to > 1GB)
The mixed sector size may not be a problem and certainly has nothing to do with just reading from it but the P2 bootloader will have to write to it at some point and so the device will have to be one that can be supported, such as the WInbond 25Q80 but these chips change every season too. By way of contrast SDHC sectors are small, fixed and easy and the protocol is standard. However I would still expect the P2 bootloader to support SPI "FLASH".
512KB load from SPI only SD I can read in around 2 seconds on the current P1 but well under a second on the P2. However let's be realistic, who will load 512KB of code? I expect to have no more than maybe 64 to 128K at the very most but need room for buffers and video etc. So the typical load will be under 128KB I would expect.
Please separate any talk of booted vs booting. Talking about writing back to these is not part of the first stage boot process. Unless it somehow impacts the first stage booter, like the SD reset problem, please keep the talk to what the Prop2 mask ROM will be able to handle directly itself.
So we are now saying that there is no distinction between SPI Flash and SPI EEPROM, right? They can both be used on the simplest of first stage booting then?
512KB load from SPI only SD I can read in around 2 seconds on the current P1 but well under a second on the P2. However let's be realistic, who will load 512KB of code? I expect to have no more than maybe 64 to 128K at the very most but need room for buffers and video etc. So the typical load will be under 128KB I would expect.
Those numbers do raise an interesting question of volume production config.
The bottle-neck is likely to be Serial Speeds - now the ROM is a little larger, can the Default serial loader have broader Auto-Baud support ?
12 MBd would be a natural target - what is the spec for P2 RC boot osc speed & expected Precision ?
So we are now saying that there is no distinction between SPI Flash and SPI EEPROM, right? They can both be used on the simplest of first stage booting then?
Yes, from what I read, they have the same 0x03 vanilla READ command, and if a simple header string is used, (as per Chip's comment) that then should tolerate the varying delays to start emitting data from the 16/24/32b Address length in a wide range of SPI memories.
Yep, that's all that's really being discussed here. It's a just a question of how many options there are for the first stage.
- The Prop1 has two options: UART and I2C.
- It's looking like the Prop2 could end up having three options: UART, SPI and possibly also SD card.
If a non-quad SD can be supported as easily as it sounds, I don't see the issue. If a board is built to use simple SD, then it isn't wired to support Quad SD. If it is wired to support Quad SD and the developer pays for it, then the developer takes on the responsibility to make sure all the Quad SD corners are covered. Not a P2 boot issue, it supports the 3 primary boot options and that's it.
We have always had removable boot memory for the P1, it's called a EEPROM socket. Having removable boot memory in the way of an SD card is not at all any different except better plus you can access the card on your PC. There's also no sense in arguing for QSPI Flash only as a minimal boot configuration would need to be supported and SPI is the way to go. If SPI is supported then SPI SD sector zero is just as easily supported too. Having the basic boot configuration allows the user to boot a QSPI bootloader if that's what they really want etc.
The plan I favor for SD boot is to use the bootstrap code area from address 0 in sector 0 which has at least 218 bytes available.
$00: P2BL (boot signature)
$04: Starting sector of image (non-zero)
$08: Number of sectors to read
$0A: Header CRC (CRC16)
$0C: Image CRC
$10: Metadata
It's even quite possible to put the actual image in sector 1 onwards too.
We could have it as per the common boot-block method - load the first block and execute it, The End. What happens next is totally up to what got loaded in those 512 bytes.
We could have it as per the common boot-block method - load the first block and execute it, The End. What happens next is totally up to what got loaded in those 512 bytes.
That would be the most common use, but the P2 has a variable length boot choice, so that 512 is no longer locked in stone.
With a simple [preamble-key + length + Data + Check], users can load from almost anything, in one or two stages.
A different preamble could be used for two stage loading, and the PC side tools could have a small set of two stage loaders they prefix to user code.
All the ROM has to be able to do, is load the first, vanilla SPI image (of any user define length).
Executing the first block as a boot block is about just the following of MBR boot process is all. Second stage then gets defined by the code in the boot block.
Another MBR compliant boot process would be what Potato outlined - read the partition table in the first block to extract the location of the Prop's boot partition. Then perform a more lengthy read of that partition to load the boot image. This boot image could have framing around it for extra checks. No second stage needed in this case.
Comments
Mere block support sort of works, until it doesn't. Depending on "first file" copied to fresh SD card to insure contiguous space works, until it doesn't too.
All that is needed is to make a propeller partition, and make it's type empty, or just not FAT or something recognizable. I did this last time, and the data is in the hot threads. I can find it, but the gist of it was:
1. Make partition. Under Linux, this is dead simple.
2. Prop reads MBR, sees partition, collects block offset
3. Prop reads blocks from block offset to obtain whatever it's boot image is going to be.
User copies image into partition using "dd" or similar. We could make a little exe for windows that adds a partition without too much trouble. And a P2, once running, could very easily prep additional SD cards, as can a P1 right now!
It's not hard to do this, and if we do, we've added the minimum device support to get along with the rest of the world with no hassles.
Partition support is the working minimum when there isn't a filesystem, and the storage device isn't single purpose. If that SD ends up in a PC at any time, it's not single purpose.
I submit the SD card will rarely be single purpose. The compelling idea of SD card boot is we get a boot device, but we also get a filesystem, and or assets, data, code, whatever we want on that filesystem that is very easily manipulated by an average user on a PC of some kind. A really common use case is going to be to provide signed booter, for a prop with fuses set, an unsigned one for a prop with open fuses. That booter will boot, be filesystem aware, and run whatever things a user has copied over with a PC. Partition support will insure this works well.
When we pick a partition ID well, windows ignores it, and that keeps the boot blocks out of harm's way. They can use the exe, or a P1, or a P2, or Linux to prep the card, and put their boot image on it. Once this is done, refreshing the boot image is dead simple.
From there, that boot image can be filesystem aware. If it is, they then can drop their own files onto a FAT partition, and that's dead simple too.
Doing this will save people a lot of grief and it would make using an SD card with P2 simple, robust and powerful.
I did grab a whole pile of SD cards at the time we were discussing this and all of that allowed for a partition. I booted Ubuntu at the time and just ran a few commands to get it all done. Again, a small script, exe file, or P1 / P2 prepped to do this isn't hard.
I'll go track down the work done last time, just for reference in this discussion.
Again, if we are gonna do this, it's attractive from a "shiny thing" feature standpoint, but I would really prefer it not be a hack. A handful of instructions will read the MBR, correctly identify the partition block offset. That's real support, best practice. IMHO, that is what the chip should do, if we decide to put SD into the booter of the chip.
The size of the bootcode is under 200 longs as far as I remember.
forums.parallax.com/discussion/comment/1122184/#Comment_1122184
I will not participate if the same discussion starts again - it was very tedious.
Andy
A more formal SD boot should always be after the simplest SPI boot.
A header tagged system is simple, and allows varying reply delays.
A quick look finds 15c/1k 25C16 devices in small packages, with 03H read command and 16b Addr (SO on 24th clk)
Larger parts are not much more expensive, 23c/1k for 4MBit, with 24b address (SO on 32nd CLK)
(that's cheaper than a 24C256 i2c device)
Even larger parts move to 32b address (SO on 40th clk)
The header tag would wait for the start on all cases, and a simple offset of a few bytes would allow the same image (small) to be placed into any SPI candidate. An upgrade from 24b Adr to 32b Adr SPI would still work.
MISO pin would likely have a pullup resistor enabled.
Cool. That should be easy to try, as a last-tier loader ?
I think the ROM-size is less of an issue than it used to be, as P2 now uses a standard cell.
But, I could see someone wanting that to reduce costs...
Shouldn't take too much rom space for code to mount sd and then scan root directory for a certain filename
IMHO it was derailed by scaremongering.
IMHO a simple SD boot should be possible that does not require a Flash device to be present. It only adds unnecessary cost and space if a SD device will always be present.
There are boot sectors present on an SD card which can be used to start a full loader in whatever format the user requires.
Either consider SD as the optional primary boot device (check Flash first, then SD), or stop this discussion now! The solution is simple but I am not going to waste my time until it's agreed to make SD a bootable device without flash, if flash is not found.
For reference, I have shipped prop boards that have a simple SD boot loader in EEPROM. I have not had any problems although I do recommend using SanDisk SD cards.
Those of us who want to go the SD route do, and if it goes bad, others of us get "told 'ya" rights and everyone has a solid fall back.
If there is a partition aware scheme, great: otherwise, I know I'll be using a flash loader that then uses the SD in a file system aware way. And if there is a partition, I'll just do the same, so that the experience from there is just files and names.
So I guess I don't care.
Just checked Digikey and there is one option there, but it is out of stock and MOQ is 3000 pieces... Was less than a dollar at that qty. though.
That's not what I see in the data, nor in this link I gave in another thread.
http://www.spansion.com/Support/Application Notes/High_Density_SPI_Core_Command_Sets_AN.pdf
The READ command seems universal at 03H and if a simple start string is used (as Chip mentions) as begin-key, then the 2/3/4 byte address fields are supported by that.
That represents a very wide range of possible valid boot devices, from small Eeproms to medium-size minimum cost SPI FLASH, to larger FLASH Serial parts with 32b address fields.
Primary boot (ROM) can be quite small, (1 bit SPI) and from there user code can invoke fancier secondary boot, like QuadSPI-DDR for example. (or fast MODE SD or smarter SD boot... )
Yes EEPROM have poor price/bit compared to Flash, but I listed one above because it comes in small packages, for a lower price than small package FLASH.. thus it may make sense for primary boot, then advanced SD boot.
1. Update the P2 bootloader to handle th 25Q80 SPI Flash that I have on my DE2-115 adaptor
2. If possible also allow for boot from standard SD SDHC cards from fixed sectors, no filesystem/partition checking.
So I need #1 to be able to really exercise my system as a stand-alone development system rather than being reliant upon PNut to boot the P2.
Now SD is very very easy to interface, just SPI mode only, I don't know what QSPI has to do with this at all other than the fact that there is a licensed 4-bit SD mode which us unlicensed users don't use. Use SECTOR ZERO which has plenty of free space either for a second-stage SD bootloader or for the pointer/crc/metadata to a fixed absolute sector. Since SECTOR ZERO is always the same with an MBR format then it doesn't matter what partition or FAT method etc is used, as long as we have access to SECTOR ZERO then the boot image sector it points to can be the start sector of a file or anything. EASY.
In reference to something that Cluso99 mentioned please don't let this option be "derailed by scaremongering". It's simple, quick, easy, and an OPTION.
EDIT: Just specify genuine SANDISK and if anyone wants to take a chance with other less compliant brands then that's their worry.
Here I threw some P2 code into the first 256 bytes of sector 0 and had it write a header and absolute sector and crc in the first 32 bytes. No problems.
BTW. $1581C0 at 00.0010 is actually the start sector of the file "P2BOOT.IMG".
So you mean SPI boot is tried first, then SD load ?
I think actual Boot order is
1) Serial ( timeout = ??, skip-UART load pin ? )
2) SPI (1 bur using 0x03 READ ) ( what MHz SCK ?)
3) Possible Other (here SD) ?
If the primary SPI boot can be very compact, I don't think QuadSPI or QuadSPI-DDR etc need to be in ROM - they can be part of the tertiary loader.
I would expect anyone loading 512k files to be using QuadSPI, or better.
The finished Prop2 will support SPI EEPROM instead.
Here's Peter's earlier comment on SPI Flash ...
Primary device Boot BOM will focus on the price sweet-spot of SPI Flash, not EEPROM.
Present sweet-spot looks around 4-8Mb & before P2 is real, that will likely move upwards.
8Mb+ is a natural P2 size, as that matches the ~2x Memory headroom of P1 products.
SO-8 is cheapest, but largish, and if I focus on smallest-package parts, eg 3x3mm gives 32Mbit
N25Q032A13EF440E Micron 39c/3k
Addit: Digikey search missed a few :
Winbond 2x3mm package
W25Q40CLUXIG 4Mb 31c/4k
W25Q80BLUXIG 8Mb 35c/4k
? SPI Sector size does not affect boot ?
All you need to SPI boot, is to be able to start streaming data, from a fixed location, and that just needs a 0x03 READ command and then 32b of 0x000000 sent.
That can address all SPI parts with 16/24/32b address fields. (covers 2k bytes to > 1GB)
512KB load from SPI only SD I can read in around 2 seconds on the current P1 but well under a second on the P2. However let's be realistic, who will load 512KB of code? I expect to have no more than maybe 64 to 128K at the very most but need room for buffers and video etc. So the typical load will be under 128KB I would expect.
So we are now saying that there is no distinction between SPI Flash and SPI EEPROM, right? They can both be used on the simplest of first stage booting then?
Those numbers do raise an interesting question of volume production config.
The bottle-neck is likely to be Serial Speeds - now the ROM is a little larger, can the Default serial loader have broader Auto-Baud support ?
12 MBd would be a natural target - what is the spec for P2 RC boot osc speed & expected Precision ?
It's simple, cheap and fast...
- The Prop1 has two options: UART and I2C.
- It's looking like the Prop2 could end up having three options: UART, SPI and possibly also SD card.
The plan I favor for SD boot is to use the bootstrap code area from address 0 in sector 0 which has at least 218 bytes available.
$00: P2BL (boot signature)
$04: Starting sector of image (non-zero)
$08: Number of sectors to read
$0A: Header CRC (CRC16)
$0C: Image CRC
$10: Metadata
It's even quite possible to put the actual image in sector 1 onwards too.
With a simple [preamble-key + length + Data + Check], users can load from almost anything, in one or two stages.
A different preamble could be used for two stage loading, and the PC side tools could have a small set of two stage loaders they prefix to user code.
All the ROM has to be able to do, is load the first, vanilla SPI image (of any user define length).
Another MBR compliant boot process would be what Potato outlined - read the partition table in the first block to extract the location of the Prop's boot partition. Then perform a more lengthy read of that partition to load the boot image. This boot image could have framing around it for extra checks. No second stage needed in this case.