DM365 Vendor/Product ID during USB boot

alexander said:

Is there any way of providing some identity to the device in USB boot mode?

Some devices (e.g.Cypress) can read alternative Vendor/Product IDs from an EEPROM, if such is present.

This is not something that was provisioned into the DM365 so there is not such a simple way of doing this. One way you could work around this would be to write a custom USB boot loader and boot that out of an EEPROM in place of the ROM boot loader to get the effect you desire, though this would be a significant effort and would require a larger EEPROM (possibly SPI flash).

That's a shame, because without it USB boot is very problematic. On the other hand, it seemed like a very attractive feature.

I agree it would be handy, since you could have various DM365 based boards booting over USB easily.

Usually most folks seem to use boot modes like USB only as an initial/manufacturing boot mode to load code to write to flash, in which case there is a controlled environment and the vendor/product IDs are fine. In general I see USB boot as rarely used, even for initial flashing, the most common is probably UART, followed by SD card and JTAG for initial flashing, most end use situations seem to use a NAND boot.

What about SPI boot, are there any issues with that? I've came across a post by Juan Gonzales saying: "SPI mode has been tested and is working; however, the software support for SPI boot mode may take some time to become available. " What exactly does that mean? In my understanding, SPI boot, just as USB boot, loads the UBL into ARM's RAM and jumps to the entry point. What software support did Juan mean? Am I missing something here?

Thanks.

alexander said:

What about SPI boot, are there any issues with that?

The SPI boot mode works, but since the typical user is booting Linux you cannot practically do it on the DM365 EVM given the SPI EEPROM on it is too small, it was not easy to collateralize and validate and so is kind of a gray area.

alexander said:

ve came across a post by Juan Gonzales saying: "SPI mode has been tested and is working; however, the software support for SPI boot mode may take some time to become available. " What exactly does that mean?

He says it is tested and working because I modified a DM365 EVM and the flash utils to write an unmodified UBL to a SPI flash device, which all worked, but this has not yet made it into a public PSP/DVSDK release to my knowledge

alexander said:

In my understanding, SPI boot, just as USB boot, loads the UBL into ARM's RAM and jumps to the entry point. What software support did Juan mean?

The SPI boot is fairly straight forward, though in SPI mode the DM365 is the master to a simple SPI memory as opposed to the slave operation of USB, in the end the result of loading something to memory and branching to it is the same. The software support Juan refers to is a SPI flash burning utility like would be in the flash utils package with the PSP and modified UBL/U-boot to work out of a SPI based memory, the former should be in a release eventually (and if you do go down this road I can probably get it for you), and the latter I am not sure will ever be done (but it could be done on your end and I have seen others do so).

Alexander,

One option that can be easily implemented is to package the firmware that needs to be downloaded with a header tha uniquely identifies your product.  When you download the firmware then look for this header and the associated information to validate whether the downloaded firmware is for your product.

The above procedure will definitely work and is far more useful and not to mention much faster as a firmware download process compared to other means if you are indeed looking to use USB for this purpose.

Agreed a VID/PID option would have been the correct approach.

Another approach would be to get the U-Boot loaded from the local flash and use the USB in U-Boot to download the rest of the firmware.  This is far more flexible approach and one that alows you to use the VID/PID feature effectively.  Can you consider this approach for the product?

regards

swami

Swami,

my concern is the first stage of USB boot, where my UBL is loadded by the DM365's USB bootloader running from ROM. This bootloader is looking for a standard header and can not accomodate any unique headers. It's this stage where the confusion may happen if 2 different devices use USB boot: may board may load another board's UBL, and the other way around.

I agree that the local flash or SPI EEPROM are safer alternatives. I'll have to go that route. It was very tempting not to have to program anything on the board.

Thanks for your help,

Alexander.

Bernie Thompson said:

The software support Juan refers to is a SPI flash burning utility like would be in the flash utils package with the PSP and modified UBL/U-boot to work out of a SPI based memory, the former should be in a release eventually

Bernie, if there's anything you could do to help us here, we'd hugely appreciate it.  FAE's in the UK are having no joy getting *ANY* information at all about SPI boot -- I've found more myself just using Google!   We're at a crunch time with our design just now, really needing to use SPI flash boot on a DM365 but being told it's "not supported" and there's nothing useful in datasheets.   This SPI boot issue could really harm or even kill our product - we just don't have the space to fit a parallel flash device.

Ian,

SPI boot seems to be working on DM365. I was able to boot the EVM board using it.

To load my bootloader into an SPI EEPROM I used a slightly modified Spectrum Digital's code that came with the EVM board.  Once the boot option was set to SPI the board booted my secondary bootloader (or User BootLoader, UBL as TI calls it). Same approach could be used to start U-Boot.

It has been a long time since I did any work on this (I worked on a SPI flash boot shortly after DM365 was released), I was able to get it to work myself but never had a complete solution, the modifications should have made their way into the standard boot utilities release by now, though I am not sure if they are fully tested and validated in all releases because you would need a modified DM365 EVM (or custom board) to really test it.

What I did have working was a simple SPI flash writer, which would put in the appropriate header information for the RBL (ROM Boot Loader) to recognize the SPI flash image as bootable to the point it would try to run something. From there I had the writer put a standard UBL image into the SPI flash, which would then be copied from SPI flash to internal RAM by the RBL and executed. This was as far as I had worked on it, though I worked with a customer who went one step further and got the U-Boot image in the SPI flash as well, which is really just a modification of the UBL to read from SPI instead of NAND.

In general, back then I never had a full SPI booting solution in house, only a proof of concept that it could boot out of SPI and a hacked up SPI flash writer. I believe there is also a newer modified UBL that has been coded to load U-Boot out of SPI that is at least available internally, I suspect your FAE will be getting that to you shortly.

On the positive side of all of this, it is entirely possible to boot from SPI, and I have seen it done, at least to the U-Boot phase. Generally that is as far as you would go out of a SPI storage solution due to space limitations, from there one would generally load the rest of the system (kernel/filesystem) through another interface, like network or HPI. It is possible you could also modify U-Boot to load a kernel out of SPI flash, and use a SPI based filesystem, though it would be impractically small for most DM3xx applications.

Thanks Bernie, and alexander.  Really appreciate the info here - to know that SPI booting does work despite the FAE saying it's "not supported" -- that seems to be really as far as they'll go just now.    It sounds like that I'll have to find the time/cash to run up my own UBL here... and that means, I believe, writing some fairly low level code that knows how to talk SPI to pull in U-boot?   [Can I even do all this with GCC? - We don't have CCS]  It's a shame the RBL wasn't written such that it could haul something as large (small!) as U-Boot directly in to DDR, without this extra layer of repeated SPI driver -- especially if TI aren't going to supply a suitable SPI UBL.   My Linux kernel+apps are bijou (total under 4MB) so the SPI flash is the only storage device I'll have on the board - it's all I need.   We have already swapped the 64K flash on the DM365EVM for a much larger device, so I'll let you know how I get on - may be able to contribute something back.

Thank you both once again for the replies.

Ian Jeffray said:

Really appreciate the info here - to know that SPI booting does work despite the FAE saying it's "not supported" -- that seems to be really as far as they'll go just now.    It sounds like that I'll have to find the time/cash to run up my own UBL here.

The term 'not supported' can mean a wide variety of things, it is not part of the default package and has limited testing since the EVM hardware cannot practically handle it, so if you ask questions there is a possibility of there not being an answer, so it is not supported totally, but it is possible and there is some example code in existence.

Ian Jeffray said:

and that means, I believe, writing some fairly low level code that knows how to talk SPI to pull in U-boot?   [Can I even do all this with GCC? - We don't have CCS]

You will need some sort of SPI flash writer, however you want to do it, implementations I have worked on in the past have been CCS based (as would likely be what your FAE could get for you), since that is easiest to work with, but you could do something else like a modified SD card based boot or uart (on the newer silicon).

If you wanted to use CCS you could use CCSv4 with a XDS100 emulator for free (CCS being free, the emulator being $100 or so at least in the US).

Ian Jeffray said:

It's a shame the RBL wasn't written such that it could haul something as large (small!) as U-Boot directly in to DDR, without this extra layer of repeated SPI driver -- especially if TI aren't going to supply a suitable SPI UBL.

This is because the DDR interface needs to be configured, and to give proper configurations for various DDR modules that may change in the future the code to configure the DDR is not built into the RBL, which is why UBL exists. Essentially, having the RBL load into DDR directly would have limited you to one DDR configuration (or would have required a crazy number of boot mode pins).

Ian Jeffray said:

My Linux kernel+apps are bijou (total under 4MB) so the SPI flash is the only storage device I'll have on the board - it's all I need.   We have already swapped the 64K flash on the DM365EVM for a much larger device, so I'll let you know how I get on - may be able to contribute something back.

Before jumping into this from scratch I would be sure to have your FAE at least get you the code that does exist for doing this, even if you are going to have to rewrite much of it, having something to look at for starters will probably be helpful. I believe you will be on your own from a U-Boot standpoint (modifying it to read the kernel from SPI, and read/write environment variables from SPI), though I believe there is a MTD kernel driver for SPI flash you may be able to leverage at the kernel level.

Thanks once again Bernie - I'll chase our local FAE some more!