P2 bootload from Flash (and optional SD)

Peter JakackiPeter Jakacki Posts: 9,929
edited 2015-11-15 - 02:22:27 in Propeller 2
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.



  • jmgjmg Posts: 14,567
    I think you are asking Chip to include a SPI Flash loader/read check in the next 'rom' area build ?
    Is there a specific flash part code and pin-mapping in mind ?
  • It's the standard Winbond 25Q80 that is loaded on the DE2-115 breadboard adaptor that Parallax kindly supplied.

    The pins in TF2 are:
    #P61 == sfcs
    #P60 == sfck
    #P59 == sfdi
    #P58 == sfdo
  • Okay. I'll get this going soon.
  • jmgjmg Posts: 14,567
    It's the standard Winbond 25Q80

    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.

  • Thanks for the heads-up.
  • jmgjmg Posts: 14,567
    cgracey wrote: »
    Thanks for the heads-up.
    No worries.
    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.
  • Peter JakackiPeter Jakacki Posts: 9,929
    edited 2015-11-13 - 16:27:03
    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
    TF2$ 0 $4000 SDMAP
     $00.0000: *****...........................................................
     $00.1000: ......................................................*****.....
     $00.2000: ................................................................
     $00.3000: ............................................******************** ok
    TF2$ 0 @FAT . 20 ok
    TF2$ 1 @FAT . 1D9D ok
    TF2$ @ROOT 9 SHR . 3B1A ok
  • Umm, yeah, you might want to check a few more cards there Peter. Using just any old SD card with any old partitioning config can be risky. I think you'll get plenty of variation on where the first partition starts. And then there is GPT also, the partitioning info on those drives can be very spaced out.

    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.
  • True, but none of these are my first observations as I have between dealing with all kinds of sd cards for many years. But this is what I mostly see that despite the formatting there is normally a big gap in microcontroller terms before any fat etc. Assuming we use standard sdhc then there is no problem with the spi protocol. It's worth a thought and easy to do. There is no need to worry about the filesystem in this regard either.
  • TF2$ 0 @FAT . 20 ok
    TF2$ 1 @FAT . 1D9D ok
    TF2$ @ROOT 9 SHR . 3B1A ok
    This part is more interesting though. Those are block locations of each partition, right? That makes partition 0 starting at 16kB.
  • As for locating Propeller boot storage in those first few blocks, without it flagged as in use, I presume you are okay with it potentially being overwritten by other equipment?
  • @Peter Jakacki,

    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.


  • That's a good question. Peter, are asking for SD booting to be part of the finished Prop2, or just for the FPGA releases? I wasn't even contemplating hard-wired SD booting in the finished Prop2.
  • Kye seemed to make a pretty great case for avoiding SD card on boot from the chip. Lots of potential issues there.

    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.

  • If we do it that way, from flash, then we have the time to really make it nice and sort out all the card variations. There isn't a consistent, low level protocol available to us. Again, that's from Kye, who did a TON of research on this last go around.

    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.
  • Peter JakackiPeter Jakacki Posts: 9,929
    edited 2015-11-14 - 04:11:52
    Ok, nobody is the final authority surely and anyway contrary to what everyone keeps thinking the SD bootloader is actually not any more complicated than a serial Flash bootloader and in fact share the SPI and block buffering code. I've just done this in Tachyon and that is exactly why I bring this up because i can see and I know that it is much much less complicated than what many may imagine. There always seems to be that megabyte or two that never gets touched in the SD card and I have in the past put special boot routines in there as well as also at the high level under a file name. The huge variety of cards I have played with all have some little quirks but not in this basic area or SPI protocol.

    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:
    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.
  • One of Kye's concerns is a scenario where a user has been operating a "Prop bootable" SD card in QuadSPI mode doing file store stuff and then hits the reset button to reboot it. Power is not removed, so the SD card is still in QuadSPI mode when the Prop is trying to boot from it.

    What happens at this point can be difficult to program for if I'm getting the gist of the concern.
  • Easiest way out of anything like that is to have a 10 cent transistor switch the power to the card although I have never used these cards in QuadSPI mode myself but even with the P1 and without anything special such as a dedicated PASM cog and multi-block read etc I still hit 200kB+ read rates. There are many drivers that have a super-fast transfer mode but slow down because of too much high-level baggage when in fact you only need modest transfer rates and efficient high-level routines.
  • To make the booter simple on me, at this stage, could I just have it read up to 1MB, looking for a constant string that signifies the boot code is next, and if I find it, load $1F8*4 bytes at $00000 and then coginit #0,#00000? That would be simple to do and might cover SD cards, as well. You'd be responsible for loading a program to program the Flash/SD card.
  • jmgjmg Posts: 14,567
    edited 2015-11-14 - 09:01:23
    cgracey wrote: »
    To make the booter simple on me, at this stage, could I just have it read up to 1MB, looking for a constant string that signifies the boot code is next, and if I find it, load $1F8*4 bytes at $00000 and then coginit #0,#00000? That would be simple to do and might cover SD cards, as well. You'd be responsible for loading a program to program the Flash/SD card.
    Yes, that was my earlier suggestion, and I think is also how FPGA readers work.
    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 ?

  • evanhevanh Posts: 10,229
    edited 2015-11-14 - 09:14:17
    That's all fine as long as none of this goes into the finished Prop2. The moment the SPI Flash boot step is skipped then the trap is set for people to add the fatal integrated QuadSPI support at a later date.

    PS: Another way to put this is: It's important that SD not be the primary cold boot device.
  • jmgjmg Posts: 14,567
    evanh wrote: »
    That's all fine as long as none of this goes into the finished Prop2. The moment the SPI Flash boot step is skipped then the trap is set for people to add the fatal integrated QuadSPI support at a later date.
    I'm not following ?
    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.

  • If the cold boot device is the one and only SD card also used for, say, FAT32 file storage then there is a chance it will be set to QuadSPI or similar mode that has a complicated reset process then you're setting up for future problems by not having a simple, or known at least, boot process.
  • evanhevanh Posts: 10,229
    edited 2015-11-14 - 12:09:42
    Switching an SD card back to SPI on hard-reset, without power-down, is potentially problematic.
  • Single handedly designing a radical 16 core microcontroller with the input of dozens of "amateurs" is problematic. If you think QSPI could cause a lock-up problem on the SD card then we will always use a transistor to switch the power or simply operate in SPI mode. There, simple, no problem, next?

    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.
  • evanhevanh Posts: 10,229
    edited 2015-11-14 - 12:57:43
    ... then we will always use a transistor to switch the power or simply operate in SPI mode. There, simple, no problem, next?

    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.
  • I guess the extra pin will be needed anyway for the extra Flash device. :)
  • The other point I'd like to make is if there is a SPI Flash chip as the primary boot device then it can hold an entire filesystem and, from there, handle the secondary boot process as ordinary files. Nothing then has to be written to any special locations on the SD card. The SD card can be treated as it was intended to be - as a file store device.
  • Peter JakackiPeter Jakacki Posts: 9,929
    edited 2015-11-14 - 13:49:10
    When my SPI Flash chip costs the same amount as my microSD card and yet has a mere fraction of the capacity then it may be sensible in some cases to forego the former. 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. The transistor would only be needed if we were running QuadSPI which already takes extra lines anyway. The basic SD card only requires 4 lines which also includes card detect via the chip select.

    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.
  • Maybe Kye was recommending EEPROM then. I've not looked myself.

    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.
Sign In or Register to comment.