AISgen for OMAP-L138

Hi Frank,

The easiest way to modify the entry point would be to simply rebuild the ARM project and change the linker.cmd file to specify a new entry point. When using COFF .out files, AISGen automatically sets the correct entrypoint so you shouldn't normally have to set this manually.

If you want to set a different entry point in AISGen, you should select the checkbox before you generate the first AIS file. You should only be generating the AIS file once. To create a .h header, when selecting the file output, choose *.h in the dropdown menu and hit Generate AIS file again. They should be identical.

Jeff

Hi Jeff,

in later application software for the ARM9 of the OMAP-L138 I want to have a different entry point for the ARM9, i.e. not pointing to "_c_int00".

For the current application SW on the OMAP-L137 I have implemented already something similar: via linker.cmd file an "armBoot" section is placed to a fixed address and when the DSP has loaded the ARM image from Flash to RAM, the DSP sets the entry point to this armBoot address.
The first thing when the ARM now starts is to copy the exception/vector tables to the ARM's local RAM and then jumps to the reset vector, which will lead to execute "_c_int00".
For the OMAP-L138 I like to have soemthing similar and my thought is to accomplish this via the AISgen. That was the reason why I played a little bit around with AISgen and need to know if my described sequence is the right one.
With this handling the DSP does not need to know the ARM reset vector table and copy it via the PRU in ARM's local RAM as describeld in Advisory 2.0.20 "Intermittent Boot Failures" of the OMAP-L138 Errata (sprz301e).
By the way, how do I have to understand sentence of the Errata in 2.0.20:
"For affected silicon revisions, the DSP initiates the system boot sequence when the device is released from reset."?
I thought the OMAP-L138 is an ARM boot device and the ARM has to "start" the DSP as described under the "Boot Images for OMAP-L138" link.

You wrote: "If you want to set a different entry point in AISGen, you should select the checkbox before you generate the first AIS file."
This is NOT possible, AISgen requires a bin file as input.
When I use the two out files as input I get the following error message:
" Cannot specify an entrypoint without at least one binary file."

Would be great if you could answer my questions from the original post and the new one above.

The used versions on ARM9 for OMAP-L137 resp. OMAP-L138 are/will be:
- SYS/BIOS 6.30.03.46 (eabi) ELF
- CCS Version 4.2.1.00004

Thanks,
Frank

Q1: You are correct, you can only specify entry points to binary files. In order to change the entry point for a .out, you must rebuild it with the modified linker.cmd file.

Q2: You should not give an AIS binary as one of the application files. You should use only .out files, which contain the entry points already.

Q3: The bootloader will not execute any AIS commands if they are part of a section load. They are just treated as data and copied to the specified location.

Q4: See Q3

Q5: See Q3

Qnew: For OMAP-L138,the DSP still wakes up first, but it immediately turns on the ARM which does the boot loading. The DSP goes to sleep after it wakes up the ARM, so it has to be reinitialized if DSP code needs to be run.

It looks like your goal is to run SYS/BIOS on the ARM, so the DSP will not be used correct? If that is the case you will only need to create an AIS binary from a single ARM .out file. If you are trying to run on the DSP, the wiki given earlier has been updated with more information on how to do this.

Jeff

Hi Jeff,

thanks. Already saw yesterday that the page was updated and that new code examples (OMAPL138-DSP-LED-v2.zip) are available.
My questions/statements are still based on the older examples (OMAPL138-DSP-LED-v1.zip)

Both, ARM and DSP will run on the OMAP-L138, both with SYS/BIOS.

Let's assume Boot Mode Selection would be SPI0 Flash and we want to generate from the OMAPL138-DSP-LED-ARM.out and the OMAPL138-DSP-LED-DSP.out one *.bin and one *.h file.
Within this generated files I want to set the ARM entry point to soemthing different than the "_c_int00" (as described yesterday).

Coming back to my questions/your answers:
Q6: (Q1:/Q2:) For my case above I'll need then an AIS binary as input of the application file, correct?
Q7: (Q3:/Q4:/Q5:) If this is just a copy of data, then there will be 0x00000CD0 bytes be copied to address 0x80000000, correct?
Q8: From where are they copied?
Q9: Next Section load command will then overwrite the data (0x58535901, 0x80000800, 0x00000464, ...). Does this make sense?

Q10: (Qnew:) When the DSP wakes up first, which DSP code is then executed (is this something from the DSP L2 ROM)?

Frank

You cannot set the entry point for either .out file. That information is embedded in the COFF format, and to change it the .out file would need to be recompiled.

In order to perform what you want to do, follow the same instructions in the wiki but edit the ARM .cmd file to manually set a different entry point. After that, combine the two .out files to one AIS .bin file. Is there a reason why this won't work for you?

Q10: The DSP will execute from its internal ROM, correct.

Jeff

Hi Jeff,

thanks.

I'll try to change the current OMAPL137 ARM code, that I do not need to specify an entry point for AISgen for the L138.

Could you give me some answers to my question Q7, Q8 and Q9?

I'll close then the ticket.

Frank

Q7: You should not select the "Specify Entrypoint" checkbox, so that command won't be added into the AIS file generated. In general, the Section Load command would copy 0xCD0 bytes to 0x80000000.

Q8: The data copied by the Section Load command is in the AIS file, following the Section Load header

Q9: If the .out COFF file has overlapping sections, then an AIS file with overlapping sections will be created. Again, you should not choose "Specify Entrypoint", and a vaild COFF file shouldn't have overlapping sections.

Jeff