P2 bootload from Flash (and optional SD)
Peter Jakacki
Posts: 10,193
Hi Chip, I've mentioned this before but I'm at that stage where I have quite a few modules such as the SD FAT32 filesystem and WIZnet drivers and servers being tested and I would like to have them locked into the SPI Flash which I can do very easily but I would also like the bootloader to check this device at boot time and load it if some condition is met, even if that is just a simple I/O jumper at present.
So the bootloader can be very simple in that it only has to be able to read the device as it is very easy to write to it from Tachyon.
Once I have bootloaded from SPI Flash the system can pretty much depend upon itself instead of PNut all the time as I also have my assembler and preprocessor working nicely.
So the bootloader can be very simple in that it only has to be able to read the device as it is very easy to write to it from Tachyon.
Once I have bootloaded from SPI Flash the system can pretty much depend upon itself instead of PNut all the time as I also have my assembler and preprocessor working nicely.
Comments
Is there a specific flash part code and pin-mapping in mind ?
The pins in TF2 are:
#P61 == sfcs
#P60 == sfck
#P59 == sfdi
#P58 == sfdo
I see Winbond & Microchip have some 'gotcha' modes..
eg Sending cmd 0xAB on either W25Q or SST25WF does Release from Deep PowerDown
Also W25Q has a continuous read mode reset of 0ffffH
Looks like a couple of housekeeping commands are needed, thereafter the 0x03,00,00,00 should start read, no matter what state the FLASH was in, at P2 RESET.
Some designs use a header & tail tag longs, & read clocks until it reads the expected preamble, then extracts data.
I've seen other forums, where this detail has bitten designers, who wonder why sometimes their flash does not load...
Winbond also mention a Quad Enable (QE) bit, but as best I can tell. that is needed for Quad, but does not disable 1 bit mode.
ie if someone sets that, it should still work in 1 bit mode.
Chip, I'm only a hop skip and a VGA jump away from a self-hosting development system but the Flash bootloader would be really appreciated.
Seems to me too that a simple SD card bootloader mode should be possible if you simply read from a fixed sector as there is a lot of wasted space (not in SD memory terms) before the root directory. The basic SD routines aren't much more complicated than the serial Flash but probably a lot more standard.
Here's a quick map I did that maps 32K bytes/char where each dot is 32k of zeros. and I have printed the sectors for the FATs etc.
BTW, each line is 2M bytes
It's likely you are just viewing some of the first partition there anyway.
That said, there will usually be some space between the boot-block and the next used block. This can be from a few blocks to as much as 1 MiB.
I'll also reiterate what I've said in the past - There is three levels of complications with SD cards:
- Data protocols for SPI and SD parameters for QuadSPI and what not - getting the reading and writing of data blocks right.
- The above partitioning baggage.
- And finally, filesystem handling. This part isn't of concern here, I know.
I spend a lot of time going thru the specifications and both used drivers for spin. One is the Fat_Engine made by Kye and one is FSRW.
Both do a big try on using different card types and support FAT16 and FAT32, SD, MMC and whatever cards are out there.
But now, you can basically not get any SD card smaller then 4 GB. So it is all FAT32 and SDHC(?) or so.
There are two (three?) different ways the 'boot sector' and the File system can be organized in Fat32, but still (in all versions) there is a lot of unused space, usable to boot a cog image. Actually there is even a designated area for a boot loader in all Master Boot Record / Partition variations.
The main problem is to get some bootable image there. In Linux you can use dd or such, in windows you will need to open the sd card as raw device, not as easy.
Accessing the SD as block device (alike flash memory) is easy from the propeller side, but not so easy for development tools on some PCs.
I personally would LOVE to have the ability to boot from SD, but I do not now if it is worth the amount of ROM it would need to archive that. Flash memory is way easier to handle then SD. Less variations.
And I am pretty sure someone will write a SD-Boot Loader fitting into some small flash thing to boot the P2.
I personally would be fine with EEPROM as on the P1, but it does not really matter. I guess I used as much P1s in the last 6 years as you sell in a couple of days.
Like Slartibartfast said: Oh, my name is not important.
Enjoy!
Mike
None of that discussion has changed at all. This current design doesn't offer us anything the older one didn't.
Would be good to get the SPI booter done though. That can facillitate an SD card loader any of us can work on.
Frankly, I would love being able to update that to be filesystem aware, and offer some basic facility to make partitions, etc... Being filesystem aware is nice, but partition aware is really good, and can be insulated from other devices nicely.
We found it handy to make a partition for the boot image last time. One read from the FAT, offset into the partition, and then sequential block read from there. No brainer.
All of this can be found on the "hot" thread.
My code is usually very small and simple, gets the job done and some more. Even in Tachyon with the virtual memory layer and some of the multiple file support it is under 1.8K but coded as an assembly language bootloader it would be much less than 1K especially since we don't need to write data. Perhaps that would even amount to just a few hundred bytes (shared with Serial Flash). The basic routines that you need are:
SPIRD
SPIWR
BLKRD
SD INIT
SD COMMAND (and response processing)
The first three are common to the serial Flash.
The bootloader inits the SD card, doesn't really need to check for a valid partition but can start scanning for a boot sector and finding a valid signature can load sector by sector as it needs straight into hub.
I'm telling you that this is quite doable but I'm not insisting upon it although it is also a good marketing feature for the P2 to have.
What happens at this point can be difficult to program for if I'm getting the gist of the concern.
It has low cost overhead on standard SPI, and allows most clean/new SD card to operate with some rules, but avoids the minefield of higher level information handling in ROM.
Simple, works 100% for SPI, and gives a test vehicle for real SD cards, where reports of when it works (or does not) can come back from field tests.
It could also do a checksum/CRC test before the launch ?
Just avoid any common FAT info as the key-string
Another detail is if that match-test is done every byte, or every long. I guess every byte ?
PS: Another way to put this is: It's important that SD not be the primary cold boot device.
The boot ROM in P2 was always compact, and not intended as a full image loader.
If it uses a constant string as a trigger preamble, and then a {length [bytes] Chsum/crc} format, it can load any small sized image in a very short time,
That image can then launch a QuadSPI, or higher (QuadSPI-DDR or HyperBUS etc) loader.
Chip, yes, scanning up through the sectors for a signature would be fine especially if you use a CRC to validate whether to proceed and execute it. Perhaps the first 512 byte sector could simply be a header in which we can store any kind of metadata including firmware version etc. So boot signature...data size....crc....metadata which is of course ignored by the bootloader. Nice and simple. This is also a very nice way to update firmware in the field without the use of any special programmer even if we still use Serial Flash as the main boot.
I think you're underestimating the potential for confusion and poor system design choices. By "we", I suspect you mean the people organising educational material and the few that are keeping up with the issues. That doesn't account for very many of the potential developers that could end up designing bootable Prop2 systems. Also, using another valuable Prop pin to switch another extra external component or two isn't exactly going to be greeted by all as a positive workaround.
Chip, I was just playing around with backing up 512k (mirrored) to the SD card and it occurred to me that the first sector on the card is mainly used for the partition table info but there is no reason why we can't use the largely unused "bootstrap area" and write a signature, crc, and a pointer to the boot sector in this first sector. Isn't that much much easier and that way we could even have the firmware in an actual file with the MBR updated accordingly.
For sure, people will try to switch on QuadSPI on boards that weren't intending to use it ... So, all the first demo boards out need to have the SD power control as a reference design. And maybe it could even be done as part of the circuit providing the Prop2 RST input. So, any push button or USB reset trigger or whatever pulls the RST pin can also drop the SD card power at the same time. One issue with this idea is the number of components needed to ensure power is removed for long enough.