• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 102 subscribers
  • Views 438 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

spi boot blocks / sectors question

abadobid
Intellectual 300 points

Our device uses a DM8165 and uses SPI boot mode from a M25P20 spi flash device.  We are only programming uboot to the spi flash (kernel and filesystem are loaded via. PCI).  Our uboot is ~50kB in size.

All of this works fine.

I am now looking at the possibility of field upgrades to uboot.  The ideal would be if I could have two uboot images stored in the spi flash at the same time (the existing uboot, and the new one that is being programmed to upgrade).  This way, the uboot being programmed could be programmed and verified, and as a last step, the previous uboot signature could be erased to switch to the new one.  With this arrangement there would be much less risk of corrupting uboot during the upgrade process.

The DM816x TRM section 25.7.5.5 table 25.23 lists the number of blocks and sectors that are tested by the boot rom for non XIP memories.  It lists the number of blocks for SPI memory as 4 and the number of sectors as 1.  From this I read that the boot rom will read the first sector of up to 4 blocks to look for the image header.  Section 25.7.5.3 defines the sector as 512B, but I cannot find the definition of the block size for an SPI device.  Since there is no way for the boot rom to know the erase block size for the spi device, I assume this value must be fixed in size?

Does the boot rom really look at up to 4 blocks in SPI boot mode or is this a documentation error?

Is there any way to have the uboot image located at some offset in the spi flash, or does the image header have to be located at address 0x000000 in the spi device?

Thanks,

  • 0
    Intellectual 300 points
    Can anyone from T.I. tell me if this is a documentation error or should the boot ROM really be looking at up to 4 blocks for a valid image as shown in the TRM?
  • 0 in reply to abadobid
    TI__Guru**** 170625 points
    DM816x TRM is correct. See AM335x TRM, section 26.1.7.6.3 for more info regarding SPI Read Sector Procedure.

    BR
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 300 points
    Thanks for directing me to the AM335x. I would have never thought to go there for the DM816x.

    Actually, it does look like the DM816x TRM is wrong after all. It states that only 1 sector is searched and four blocks (not sure what a block is in the case of the SPI device)

    The AM335x TRM section 26.1.7.6.3 you call out states that four sectors are searched (and makes not reference to blocks), but in table 26.7 it has the same mistake as the DM816x TRM.

    Thanks for the information. Unfortunately, it doesn't allow me to accomplish what I wanted since our image size is far larger than 512B, but it answers the confusion I had with the TRM.

    Thanks,
  • 0 in reply to abadobid
    TI__Guru**** 170625 points
    Some info regarding this in the below e2e thread:

    e2e.ti.com/.../126503

    BR
    Pavel
  • 0 in reply to Pavel Botev
    Intellectual 300 points

    Thanks Pavel,


    I am curious about the selection of 512B for the search size used by the bootrom.  You may not know the history behind it, but was this intended to allow something like I describe early in this thread?  I just don't see how I can use it with the 512B sector being so small.

    It's too bad the image header did not also have an offset that could be specified into the eeprom from which to load the image.  I think if that were the case, I could actually use it to accomplish what I was originally looking for.  I could load two uboot images at different offsets and just use the 512B sectors to hold the image headers with an offset to the uboot image.

    Thanks,