OMAP137 HPI boot problem

PS.  You'll need to configure CFGCHIP1 through the HPI...  My suggestion is to change that bit before you load any code.  The CFGCHIP1 is located at byte address 0x01C14184 (i.e. 0x01C14184>>2 = 0x00705061 in word address).  So before you start loading the code your host should do a write to word address 0x00705061.  For example *0x00705061 = 0x00010000 would do the job.  Once you've set that bit you can do "normal" byte addressing.

  I appreciate your reply, but I had already configured the register that you mentioned. Could you send me a typical project for example? My email is guowei7225@yahoo.com.cn, thanks very much~~

Can you describe what's happening during/after boot?  I'm guessing that you connect via the JTAG and check that your program data is correctly loaded (i.e. using a memory window in CCS).  Where is the program counter at this time?

Here are some general pointers for HPI boot:

1. Make sure that you're writing your program entry point to address 0x11800000 during boot.  (Also, make sure this isn't overwriting part of your application; link the app so that no sections occupy 0x11800000.)
2. The image you're loading via HPI should be raw binary data extracted from a *.out file (not an AIS file).  For most programs, you'll have multiple "sections" of data.  It's important to load each to the correct memory location.
   • There are multiple ways to extract binary data from a *.out file.  One way that works well for small images (in the first 16 KB of L2RAM) is described in this wiki article: http://wiki.davincidsp.com/index.php/Secondary_Bootloaders_on_OMAP-L1x#Extracting_the_Binary_Image
     
     
3. Start with an extremely simple application (i.e. void main() { while(1); } ) to make sure that your problem is really happening during boot.  Sometimes, application errors can cause the DSP to reset and/or jump back into the ROM.

Hope this helps.

  Joe,
     thanks a lot for your detailed advises, I checked that the program counter pointed to 0x117F8408 in ROM , I still can't figure out what's wrong. what could I do next, please give me some hint.

The most likely problem is that your HPI host is not properly signaling the OMAP-L137 bootloader with HINT.  Per the bootloader app note, the appropriate sequence is as follows:

1. Host reads HINT bit in HPIC register (must read as 1)
2. Host clears HINT by writing 1 to that bit
3. Host loads program data to appropriate location(s) in memory (and writes program entrypoint to 0x11800000)
4. Host sets HINT by writing 1 to that bit
5. Bootloader jumps to program entrypoint

Note that HINT is a bit in the HPI peripheral's HPIC register, not the HPI_HINT pin.  To check whether you're successfully clearing HINT, try to read HINT again after step 2.  It should go to 0.  If it doesn't, the bootloader will probably wait forever for HINT instead of jumping to your program.

 we  used  6713  before   and followed  those steps as you said ,   and  6713 runned correctly.  Is there any deferences in  HPI  bootload  between 6713 and  omap137?

The bootmodes are different.  You need to follow the instructions for the OMAP-L137.

1.  You need to wait for HINT (was not part of the 6713 process)

2.  You need to specify an entry point (6713 simply began execution from address 0).

3.  BE CAREFUL -- INTERNAL MEMORY IS DUAL MAPPED!  You must make absolutely certain that your code that is linked to internal memory defines that memory using the globally accessible address.  If you look in the OMAP-L137 datasheet at Section 3.5 "Memory Map Summary" then for example you will see 2 address corresponding to the DSP's L2 RAM.  One address is at 0x00800000 and that address is accessible ONLY by the DSP.  The other address is 0x11800000 and that address is accessible by all masters (e.g. HPI).  So make sure your linker command file defines the DSP's internal memory as being in the 0x11800000 range or else it will not work!

Joe has already covered this stuff.  Please try implementing a very simple program.  You should be able to open a memory window and see if the code actually made it to the appropriate address in memory.

Hi Brad,

I'm trying to boot the OMAP 137 through the host port. I have done this before with the 54xx family and my .coff file parser and loader work fine. I intend to port this code to drive the OMAPbut I'm have problems just getting the HPI to play. I'm using a Coldfire 54455 as the host. I think i have a hardware problem. Can you direct me to a document that defines OMAP HPI BOOT hardware and software requirments? As I've said, I can't get valid data (the default HPIC config) and cannot set theHWOB. I have the logic analyzer connected and all signals are with in spec. (are these signals connected to balls? good question) Anyway, IF you could point me to point to OMAP HPI documantation that defines the HPIC hardware control for byte mode and word mode I be happy. I'd like to run in byte mode but i need to get something happing in either moide at this point. Thanks, Paul

Thanks Brad and Joe.  I followed Joe's  steps,  but  refered to OMAP137's  technical  documents,  in Step 4-----Host sets HINT by  writing 1 to that bit----- I think we should write the DSPINT bit.  But after I did so,  the PC jumped to DSP L2 ROM in 0x117F8408 , and the data in 0x11800000 was 0 (before writing DSPINT , it was correct  instruct  jumping to the program entry). What was wrong?   I've been confused for a long while.  Waiting for your help.

All the OMAP-L137 documentation can be found in the product folder.  There's an app note on the bootloader.  There's also the HPI User's Guide if you need more details specific to the HPI itself (e.g. definition of HPIC register).

 Before host writing DSPINT:

 After host writing DSPINT:

So did you write 0x0015802A to address 0x11800000 (where did that come from)?  I just looked in the memory map and that's not even a valid address.  Try giving it the address of your entry point (c_int00) and maybe it will work.

And thanks for your note -- yes, that should have been DSPINT that you write, not HINT.

Thanks for your help. My problem has finally been solved. Thanks a lot again. I have learned a lot from you.

Are you sure about that?  Does your code actually work properly aside from the fact that the location gets cleared to zero?  Here's a quote from the bootloader app note:

"Bootloader reads application entry point (written by host) from address 0x11800000 and branches to it."

So assuming the document is correct, you do not want to place a branch INSTRUCTION at address 0x11800000.  Rather you want to actually place the address of c_int00 at this location.

  Hi, Brad,
   I have another problem. My procedure is more than 400KB, and that couldn't be written into L2RAM totally. I have an extra SDRAM but I don't know how to write the code into it and I'm worried about its speed. How could I do? still use HPI BOOT mode.

What is the correct default (e.g. reset) value for the HPIC regsiter?  According to the C6747 HPI User's Guide (SPRUFM7A), the value ix 0x0000000C.  But when I examine the HPIC address on the L-137 EVM via CCS, the value is 0x000000C0.  Is there a mistake in the documentation?

Wiky,

Writing program data to an EMIF space (i.e. SDRAM or DDR2) in HPI boot mode is difficult.  You will need to enable and configure the appropriate EMIF controller, and we don't have a simple step-by-step procedure for doing this via HPI (though it should be possible).

A better approach may be to create a secondary bootloader, which would basically be an application that turned on the EMIF and then duplicated the normal HPI bootloader behavior.  Then, your overall boot process would look like this:

1. Use ROM bootloader to load secondary bootloader to L2RAM
2. Secondary bootloader enables and configures PLL/EMIF for SDRAM access
3. Use secondary bootloader to load application to SDRAM

If you need help setting up the PLL and EMIF, take a look at the GEL file for your platform.

Hi, I'm just diving into the HPI BOOT for this OMAP device. It was my impression that all registers are accessible through the HPI. It would seem that EMIF could be configured through the HPI. At this point is external memory accessible through the HPI (DMA) ?  (probably not huh?)

Hi to all, this post was very useful to me. I was able to load an image on my C6747 custom board from a STR912FA host through HPI. The only drawback is, after DSPINT interrupts bootloader to inform that loading of application image is complete, program counter starts at 0x007F4770 instead 0x11800000. If I modify the PC with the right value, the application runs well. What could be wrong at this point?

• CCS 4.2.1
• DSP/BIOS 5.41.9.34
• CGT 6.1.18
• boot image created with BOOTIMAGE Cgxml tools

I'll appreciate any help from your side.

gaston

Gaston said:

The only drawback is, after DSPINT interrupts bootloader to inform that loading of application image is complete, program counter starts at 0x007F4770 instead 0x11800000.

I think you've misunderstood how it works.  It doesn't start executing code from 0x11800000.  It does a 32- bit read from address 0x11800000 and then starts executing from that address.  So I would guess in this case that you have the value 0x007F4770 located at address 0x11800000.

Brad Griffis said:

So I would guess in this case that you have the value 0x007F4770 located at address 0x11800000.

Yes, I probably have a misunderstanding. Let me explain you what I am doing step by step:

1. I write a simple blink led application DSP/BIOS based.
2. I set the c_int00 address to a fixed location by following these guidelines.
3. Generate a BOOTIMAGE for a STR912FA host using Cgxml tools. Generated image has these sections: _sysinit, _hwi_vec, _bios, _text, _cinit, _gblinit, _trcdata, _args, _log and boot at 0x11800000.
4. Launch a TI debugger (target does not connected)
5. Run host application that loads the image to C6747 device through HPI.
6. After perform a host DSPINT I connect the target in CCS debug view. This is the screenshot at this point:

However, if I load the built program from target options everything goes well:

At the end I don't know what is happen. Any suggestion?

gaston

Brad, now this is clear to me. Thank you! I had though that Boot Requeriments were related to AIS utility. Well, I'd like to verify your answer but I can't see the green button in my browser.

gaston

Only the originator of a thread has the ability to click "verify answer".  I went ahead and clicked a couple of them since I'm a moderator.  Hopefully I picked the right answers!  :)

So were you able to get your device to boot now?

Yes, my device is booting now with no problems. In the host I've only had to add a little delay, just few clock cycles,  before it interrupts bootloader by setting DSPINT. On the contrary, If I load the image and set DSPINT immediately the device program does not start. I wonder why is this.

gaston

Gaston said:

Yes, my device is booting now with no problems. In the host I've only had to add a little delay, just few clock cycles,  before it interrupts bootloader by setting DSPINT. On the contrary, If I load the image and set DSPINT immediately the device program does not start. I wonder why is this.

Instead of a delay try reading back the final word written to memory and then setting DSPINT.  That should guarantee the code/data has landed in memory before execution begins.

Good suggestion, but strange behavior... I've tried to read back the memory before setting DSPINT and I get only the least-significant 32-bit value (0x00004000 instead 0x11804000). I went to my code to verify read hpi routines but these seems okay. Then I tried to read more than 4 bytes so I set the host to read 8 bytes at the same address. The outcome was 0x00004000 0xA6963005 and I checked C6747 memory with approval except for the first halfword.

The strangest thing is when I run a C6747 application with a complete HPI initialization and I try to read the memory from this interface. The read value by the host is correct even if I read a single 32-bit word. It works fine in this scenario but not during boot before setting DSPINT. What could be wrong?

Just to be clear -- if you put in some amount of delay and perform that same read then do you see the complete expected data (0x11804000) in memory?  Also, is this data the very first or very last data written?  I'm assuming it is the very last thing based on your symptoms but please verify.

Are you using auto-increment mode for these writes?  The auto-increment write mode allows the FIFO to get half full (4 words) before initiating any transfers.  So my current theory is that perhaps due to the exact number of words you're writing perhaps that particular address write is less than 4 words and so the data sits in the write FIFO until the timeout expires.  Performing another write to HPIAW will cause the FIFO to be emptied immediately.  Perhaps try that and then poll for the write to complete, i.e. multiple reads if necessary.  

Brad Griffis said:

if you put in some amount of delay and perform that same read then do you see the complete expected data (0x11804000) in memory?

Regardless of the amount of delay introduced, the first 2 bytes are always zero.

Brad Griffis said:

Also, is this data the very first or very last data written?

Yes, as you assumed this is the very last data written before setting DSPINT.

Brad Griffis said:

Are you using auto-increment mode for these writes?

Yes

Brad Griffis said:

So my current theory is that perhaps due to the exact number of words you're writing perhaps that particular address write is less than 4 words and so the data sits in the write FIFO until the timeout expires.

Good point. In fact, my entry point have less than 4 words (only 4 bytes) so It could be a FIFO issue. However I've been doing some tests with no success. Brad, I think I'll be back later to this point due to my customer's deadline. Thank you for all, anyway

gaston