Question abou running DM355 without Flash

I am afraid that IRAM is too small to accomodate u-boot, uImage or Linux file System.  It can only feasibly accomodate UBL and UBL loads the rest of the code to external RAM.  In addition, internal IRAM is volatile, unlike flash memory which can preserve its contents.  Same case with DM365.

From Looking at the datasheet of the DM365, it seems that it has 16 K of ROM.  Is it possible then to store the UBL there, or is that volatile as well?  I have the DM355 EVM Board currently, is there any way I can test loading the UBL to the internal memory of DM355?  Will that be the same for the DM365?

The ROM in the DM365 is truly ROM, there is no way to write to it, so it is not possible to store the UBL in there, this also applies to the DM355 you have now. The ROM contains the ROM boot loader code that allows the device to boot from NAND and such, but is not modifyable.

Ah ok, makes sense!

So there is no way other then volatile memory to load the UBL and UBoot into the internal memory of the DM355 or DM365?  So a flash chip will be required?  If in our design if we choose a SPI interface Flash Memory what changes will need to be done to have the DM355/DM365 to communicate with each other?

Thanks

DM355 can boot from NAND, oneNAND, MMC/SD or UART (see boot modes section of ARM Subsystem UG for more details: http://focus.ti.com/lit/ug/sprufb3/sprufb3.pdf )

DM365 supports booting from NAND,  oneNAND, NOR, MMC/SD, UART, USB, SPI, EMAC or HPI (per datasheet)

NeeravPatel said:

So there is no way other then volatile memory to load the UBL and UBoot into the internal memory of the DM355 or DM365?

Yes, the DM3xx has no non-volatile internal memory, for the initial boot load you have to use the internal RAM.

NeeravPatel said:

So a flash chip will be required?

Typically yes, though it is possible to load boot code over other interfaces as well, such as MMC or UART.

NeeravPatel said:

If in our design if we choose a SPI interface Flash Memory what changes will need to be done to have the DM355/DM365 to communicate with each other?

In the case of SPI flash you would still have to have another method of booting the device (for DM355), as the ROM boot loader does not support an SPI boot mode.

After glancing over the DM365 chip it seems as if we can boot from SPI0, will this allow me a way to send the ubl and the u-boot to the serial flash and then allow the chip to boot from there?

If this works, I would have to change the ubl to support that particular flash part, is this correct?

Are there any app notes or documentation in writing a ubl or u-boot, along with compiling it?

NeeravPatel said:

After glancing over the DM365 chip it seems as if we can boot from SPI0, will this allow me a way to send the ubl and the u-boot to the serial flash and then allow the chip to boot from there?

Yes, this is available in the DM365.

NeeravPatel said:

If this works, I would have to change the ubl to support that particular flash part, is this correct?

This is correct, the UBL would have to be able to load your U-Boot out of the serial flash so it would have some modification.

NeeravPatel said:

Are there any app notes or documentation in writing a ubl or u-boot, along with compiling it?

I have not come across any application notes or documentation regarding making UBL modifications, however the UBL and U-boot source is included with the software package and there is also typically a readme of some sort for basic rebuilding instructions. For the actual modification  you need to take a look at the actual source and work from there.

Once I have a modified UBL to download, how would I go about downloading it on the DM365?  Will there be a serial utility for this, or does JTAG work with the DM365, to download the code?

I do not know of a SPI flash burning utility for the DM365, this is probably something you would have to write, the only burning software for DM365 I know of currently is a simple NAND flash burning CCS project, though there will likely be a serial boot burner eventually (for NAND). Chances are that you would have to write a SPI flash burning application that would be loaded either serially or via JTAG.