Bootstrapping the DM6437

Bandeg said:

Why do I see other’s converting to an AIS file format (using a perl genAIS program)?

Are there pro’s and con’s for each. 

What you are doing now is just fine, if you are booting over HPI there is not much if any advantage to using the AIS format, particularly if what you have now is working.

The AIS (application image script) format is essentially a form of processor initialization script, including the code and data sections for the processor and where they need to go at run time, it is important in regards to the DM6437 because the ROM boot loader (RBL) contains an AIS interpreter, which is used for various boot modes, primarily non volatile memory (i.e. flash) boot modes. The idea behind AIS is to simplify some of the boot modes so that you can bring up the device almost entirely by ROM code without the need for secondary boot loaders, so instead of writing your own initialization code you can generate an AIS file that tells the RBL how to initialize the processor. It also lends itself to handy AIS conversion tools so it is easier to create flash images from a CCS .out file.

Essentially there are advantages to the AIS for the boot modes that use the RBL's AIS interpreter, however when you boot in HPI mode you are not using any RBL based AIS interpreter, the processor initialization is entirely up to the host processor. This being said, the only way that there would be an advantage to using AIS for your case of HPI boot mode would be if you wanted to write a host processor side AIS interpreter instead of the hex file format interpreter you are currently using, but in the end they will both be doing the same things.

Hi Bernie, 

I am able to boot DM6437 through HPI boot mode when my code resiedes in the processor's internal memory. But, when i try running it from DDR2, the boot fails.

Also, I tried to palce only the boot section (cint_00) in the internal memory and other sections in external memory, but DM6437 is not able to boot. I have configured the DDR2 controller by host successfully as I am able to perform DDR2 read write from my bootcode which is in internal memory. When I connect CCS through JTAG the PC is at 0x0010594c, address o f ROM bootloader.

The conclusion I derived  is if I load any of the program sections into DDR2, HPi boot fails. I am able to boot from processor's internal memory otherwise.

Can you please help me on this?

Thanks,

Amit

(amitkumar.solanki@einfochips.com) 

Amitkumar Solanki said:

Also, I tried to palce only the boot section (cint_00) in the internal memory and other sections in external memory, but DM6437 is not able to boot. I have configured the DDR2 controller by host successfully as I am able to perform DDR2 read write from my bootcode which is in internal memory. When I connect CCS through JTAG the PC is at 0x0010594c, address o f ROM bootloader.

You may also want to verify the integrity of the code that you loaded into DDR from the HPI boot to be certain that there is no issue with the DDR or its configuration. Essentially if you can verify that what you loaded into DDR is stable for the long term, than we can look at other potential issues.

The only other issue that comes to mind on this would be some sort of cache coherency problem, though if you are loading everything from HPI before releasing the CPU from the boot loader than I don't believe you should have issues (nothing should be cached from DDR since nothing has been accessed in DDR). If this was the issue, with your initialization code in internal memory you could add an extra final cache write back statement before branching to the code in DDR.

Beyond all this, you can use the 'load symbols' functionality of CCS to bring up the debugger without having CCS load anything to the target board, making it easier to step through and try to find where things are breaking down in DDR when you load from HPI.