• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 453 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Progress on SPI booting? or pointers as to manual method...

Jon Nicoll
Intellectual 320 points

Hello there

    Has there been any progress on the  utility for booting from SPI memory? This was asked about on the forum around the middle of last year (1009) but I haven't seen anything since then.

 

As an alternative, I have been trying to understand what Constantin's SD flash utility suite does - reading in conjunction with the description of boot modes in the DM365 SoC datasheet. I'm new to this system do forgive me if my understanding is incorrect.

As a result of running the SD flash program, I have an SD card which has two partitions - a FAT32 partition and a linux partition. There is a proper filesystem on the FAT32 partition, with a single file 'DM3xx.dat'. I think there is no filesystem on the Linux partition.

This SDcard successfully boots to u-boot etc. What I don't understand is how exactly it gets there.

  • The DM365 starts off in a boot mode and determines which memory 'subsystem' to look for the UBL describer
  • it starts at memory 0 within this subsystem and searches for the UBL describer
  • if the UBL describer is found, its contents are used to load the UBL ad jump to the starting address...
  • etc.

 

What puzzles me is the early stage of this process. I would expect the UBL describer to be at or near address 0 of the D card, ie. the Master Boot Record (MBR). But If I look there (with dd) I only see bytes with value 0x00, followed by by the partition table.

I actually only see the UBL at offset 0x1000, which corresponds to the 'seek=8' parameter used by dd in part of the process. Is it the case that the RBL looks for (and fails to find) the UBL describer from 0x0000 to 0x0ffff, skipping over the partition table (and rest of the first 'cylinder'???), until it finds it at 0x1000? Why not put it in the MBR?

Also, what is contained in DM3XX.dat? Is it the totality of the UBL (itself), u-boot, and the kernel. This seems to be what dm3xx_sd.config says.

I am wondering what needs to be done in order to boot from SPI. It seems to me the issues are:

  • u-boot as supplied by Ti does not have SPI support - ait will have to be re-built with this
  • I might have to use part of the SD flash utilities to create an image similar to dm3xx.dat
  • I would then have to create a UBL describer with the correct information, and burn this, together with 'my' DM3xx.dat', to the SPI memory. Note that I don't (yet) need a filesystem on my SPI memory.

 

Thanks for any comments or pointers

    Jon N

 

 

 

 

 

 

  • 0
    TI__Genius 17355 points

    TI does not officially support this tool, so I would recommend trying to get in contact with the author who wrote it.

    Regards, Daniel

  • 0 in reply to Daniel Allred
    Expert 1055 points

    SPI boot does work. For initial programming of the SPI EEPROM I used the modified Spectrum Digital utility spi_load (came with the EVM) which I ran through the emulator. There are some errors in it, but it's a good starting point. One advise: uncomment the verification code and make sure what is read back is what you wanted to program.

    As for the boot itself, I created the header as described in  SPRUFG5A, p.189, and everything worked.

  • 0 in reply to Daniel Allred
    Intellectual 320 points

    Hi Daniel

    Daniel Allred said:

    TI does not officially support this tool, so I would recommend trying to get in contact with the author who wrote it.

    Regards, Daniel

    I understand Ti is not responsible for the SD boot utility, my explanation was to illustrate what I understood of the process.

     

    TI has indicated that there is an SPI boot tool, eg. see this thread:

        http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/100/t/7752.aspx

    I would like to know where this is in the 'productisation' process, for instance.

     

    Thanks

    Jon N

     

  • 0 in reply to Alexander Khvilivitzky
    Intellectual 320 points

    Hi Alexander

    alexander said:

    SPI boot does work. For initial programming of the SPI EEPROM I used the modified Spectrum Digital utility spi_load (came with the EVM) which I ran through the emulator. There are some errors in it, but it's a good starting point. One advise: uncomment the verification code and make sure what is read back is what you wanted to program.

    As for the boot itself, I created the header as described in  SPRUFG5A, p.189, and everything worked.

    That's good to know, thanks. But I haven't seen spi_load in the EVM and I'm wondering if we're referring to different things.I'm looking within the folder evmdm365_v1 (created from zip file EVMDM365_BSL_RevA.zip) and I can't see any spi_load. There is an spitest program which I could modify... Are you referring to some different EVM code?

    (Note: I'm very new to this board, having just started helping out some colleagues. So it's possible I've missed something, although they haven't heard of spi_load either)

    Thanks

    Jon N

     

  • 0 in reply to Jon Nicoll
    Expert 1055 points

    Hi Jon,

    sorry, I gave you the wrong project name of the copy I made and renamed. The original project I started with was evmdm365_v1\tests\spirom.

    Good luck!

  • 0 in reply to Alexander Khvilivitzky
    Intellectual 320 points

    Hi Alexander

    alexander said:

    Hi Jon,

    sorry, I gave you the wrong project name of the copy I made and renamed. The original project I started with was evmdm365_v1\tests\spirom.

    Good luck!

    I wondered if that was the case - thanks, that makes sense...

    But now, a followon question. How did you create the UBL image that you used to burn into SPI memory? I can add the describer, but I would imagine that the UBL has to be tailored to the target memory, and the only UBLs I can find are binaries for NAND or NOR Flash.

    Thanks for any pointers

    Jon N

  • 0 in reply to Jon Nicoll
    Expert 1055 points

    Jon,

    a UBL  performs the functions that are dependent on the specifics of your design. For example, it can load and start the Linux image via USB, or Ethernet, or some other interface. Or if your complete application fits in the SPI EEPROM, the UBL becomes your application. In any case it is a program you can create using the CCS. Once you have it built, you convert the .out file to binary using TI's hex470.exe utility. Then you might need some additional manipulations with the resulting .bin file (at the very least you'll need to add a bootloader descriptor). After that you can load it into the SPI EEPROM.

    That's one way of doing it. Another is using uboot, which has a lot of supported features. In my understanding  one can build a UBL based on uboot code using CCS just as any other app. My concern is that the result may not fit into an SPI EEPROM, unless one starts removing features. I have not tried this approach.

    Regards,

    A.