OMAP-L138 SecureAISGen, it seems to adding a path string into the middle of the generated binary

Hi,

Team is working on and will get back to you at the earliest.

Thanks & regards,
Sivaraj K

Dear Matt,

A second question I have now that the DSP has to passing in the ARM's entry point is, How to define the entry point for the ARM core in the SYS-BIOS app.cfg file?

I have no problem explicitly defining this on the DSP firmware by adding the following lines of code to its app.cfg script

Program.sectMap[".text:_c_int00"] = new Program.SectionSpec();

Program.sectMap[".text:_c_int00"].loadAddress = 0xc9000000;

However doing the exact same thing in the ARM's app.cfg file (with the its correct address) seems to do nothing, as the ".map" file does not seem to change.

Note: I have even tried doing a clean first, to make sure.

And I have read through the link: processors.wiki.ti.com/.../Accessing_c_int00, but I'm not keen on the idea of "adding a custom linker command (.cmd) file to your project"

You have to define like below.

Program.sectMap[".c_int00 { boot.ae64P<boot.oe64P> (.text) }"] = new Program.SectionSpec();
Program.sectMap[".c_int00 { boot.ae64P<boot.oe64P> (.text) }"].loadAddress = 0x80012000;

Please refer to the following TI wiki page.

processors.wiki.ti.com/.../BIOS_FAQs

So I know that I have secure ".ini" file all correctly configured and now I have come to point where I want to generate the binary which combines the DSP and ARM images which both have SYS-BIOS, for the secure OMAP

So essentially taking the same ".out" files used in the non-secure AISGen tool and pass them in via the command line to SecureHexAIS_OMAP-L138.exe.

This all work fine, but the image will not boot over UART, it seems to hang at the end (AIS Parse): Waiting for DONE... and never get the Boot completed successfully.

Now investigating the problem further I can something funny going on in the middle of the generated secure binary file.

For some reason when I do a HEX diff between the non-Secure Binary and the Secure Binary using the exact same .out files

I can see that there is additional 0x58535901 command that should not be there, and in fact it is a drive path + strings being inserted and I can not figure out how or why?

I've not tried to boot secure board with SYS/BIOS code, let me check with internal team on this porblem.

Also please refer to this TI wiki page.

processors.wiki.ti.com/.../Basic_Secure_Boot_for_OMAP-L138_C6748

Thanks Titus for the FAQ link.

And after seeing your example I have been able to deduce that for my build of SYS-BIOS the command should be:

Program.sectMap[".c_int00 { boot.ae9<boot.oe9> (.text) }"] = new Program.SectionSpec();

Program.sectMap[".c_int00 { boot.ae9<boot.oe9> (.text) }"].loadAddress = 0xc3000000;

Hi,

I working with Matt on this issue from our end.

I have seen binaries with an additional 0x58535901 to either 0xC300000000 (base of ARM image) or 0xC9000000 (base of DSP image).

I had a look at the ARM's .out file and DSP's .out file that are being used to create the binary(ies).



ARM:
One of the section headers stood out:

1E 01 00 00 01 00 00 00 00 00 00 00 00 00 00 C3 68 CF 02 00 3B 01 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00

According to an ELF Format PDF:
- sh_name of 0x0000011E translates to a string of: "xdc.meta" in the string table.
- sh_type of 1 (SHT_PROGBITS): The section holds information defined by the program, whose format and meaning are determined solely by the program.
- sh_flags of 0
- sh_addr of 0xC3000000: This is the address that the additional 0x58535901 loads data into
- sh_offset of 0x0002CF68: This location in the .out file contains the same string that the additional 0x58535901 contains
- sh_size of 0x0000013B: This matches the size of additional 0x58535901
- sh_link of 0
- sh_info of 0
- sh_addralign of 1 - no alignment constraints
- sh_entsize of 0 - no fixed size entry table

So it appears that this is causing that extra load command in the secure binary, even though I don't think it should be...

DSP:
Similar section header:
FC 00 00 00 01 00 00 00 00 00 00 00 00 00 00 C9 0C 36 04 00 48 01 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00

-sh_name is also "xdc.meta"
- sh_type, sh_flags, sh_link, sh_info, sh_addralign and sh_entsize are all the same as the section header in the arm .out file
- sh_addr is 0xC9000000, the address that the additional 0x58535901 loads data into when using the DSP .out
- sh_offset of 0x0004360C once again corresponds to the data in the extra 0x58535901
- sh_size of 0x00000148 matches the extra 0x58535901

Matt and I tried removing the section headers described above (as well as decrementing the e_shnum (number of entries in the section header table) and e_shstrndx (index of section header table entry that contains the section names) values.


After this, the extra 0x58535901 were gone from the binary as expected.
However, we are still stuck with the "Waiting for DONE..." when trying to boot an image over UART.

Dear Jonathan,
Sorry for the delayed response on this.
I've not tried SYSBIOS boot in secure OMAP. (let me try)
Also I'm checking with internal team on this.
Thanks for your patience.

Dear Titus,

 

I have tried an number of different combinations and variations the purist to understand what is going on with the secure OMAP.

Allow me to start at the beginning and elaborate on my findings:

Note: bootExitType = NONSECURE and encryptSections=NONE

 

1. Yes I can successful create a non-SYS bios program complied for the DSP core which toggles an LED.

From this .out file I create secure binary and boot the secure OMAP processor and see that it works. (easy)

That to say I can see in GenericSecureUartHost.exe tool Boot completed successfully but also see the LED toggle.

It also now allows me to J-TAG on the secure OMAP (TAPSCFG = 0x0000FFFF) which is step in the right direction.

Note: This program loads into the shared internal RAM.

Side note: I also made this image preform a memory test on the DDR (which passed)

Note: In order to get my mDDR to work I needed to add another command into the “.ini” file, where I could specify the DDR_SLEW which is inside SYSCONFIG1

 

[AIS_Set]
TYPE=Type field for AIS SET/BOOT_TABLE command
ADDRESS=Address field for AIS SET/BOOT_TABLE command
DATA=Data field for AIS SET/BOOT_TABLE command
SLEEP=Sleep field for AIS SET/BOOT_TABLE command

[AIS_Set]
TYPE= 0x050404
ADDRESS=0x01E2C004
DATA=0x3
SLEEP=0x0

 

 

2. In extension to that I changed the DSP image so now it only enables the ARM core and set the ARM’s reset vector using the bit assembly code found on the E2E post https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/361119 using the PRUSS as the DSP does not have direct access to the memory location. Note: The DSP core does pipe some debug strings out a UART for readability at the start. E.g. “about to enable ARM”, “enabled ARM core”.

Then I have written a non-SYS bios ARM image which toggles the LED and prints out some debug string.

Then using SecureHexAIS_OMAP-L138.exe to combine this two files I can see that this too also works.

I can also even combine these two image and make an SPI boot binary, which also works too.

 

So I’m stratified that I have an understanding of what is required of the SecureHexAIS_OMAP-L138.exe and its .ini file to get program up an Secure OMAP.

The tricky part comes when I try to build a SYS-BIOS image to run of a secure device.

Note: I have also worked out how to specify the DSP entry point (i.e. _c_init00) , which is done at the command line level with the following option e.g. “-entry point 0xC9000000”

This of importance because before, using a non-secure OMAP, where the ARM core boot first. The DSP entry point was simply specified using the register SYSCONFIG->HOST1CFG = 0xc9000000; as part of my ARM firmware, which enable the DSP core

 

3. Now to build things up again, making as little changes possible I kept the non-sysbios DSP firmware, but started a fresh/new ARM SYSBIOS firmware which will only flash an LED.

Taking this SYSBIOS image, which employs a custom RTSC platform for my custom board, I could build a secure binary as before but it would simply get suck again in GenericSecureUartHost.exe waiting for DONE…

Now, after some research as to why, which is the point of this post. It would appear that we are getting a path name added to our generated binary file using SecureHexAIS_OMAP-L138.exe, which we do not get using the same .outs with AISgen_d800k008.exe which is highly frustrating.

 

So using the new found knowledge of the ELF file format, Jonathan had worked out that if we remove 40bytes near the end of the .out file, which is a pointer to the erroneous string location in the section table and adjusted the e_shnum (@ 0x00000030) and @ (0x00000032) e_shstrndx I was able to reproduce a more identical binary (.bin) file.

 

However this still did not work for the combined image. I was still getting suck again in GenericSecureUartHost.exe waiting for DONE…

 

 4. So going on a tangent first, I thought it best to just apply this new found knowledge about the ELF file and apply it to the our SYS-BIOS firmware for the DSP. So with a couple of tweak to get this firmware to flash an LED.

Whereby taking this DSP.out file I produce a binary with AISgen_d800k008.exe (for non-secure OMAPs) and with the deletion of the 40bytes and adjustment to e_shnum and e_shstrndx

I was able to produce more or less the exact same binary (excluding the addition of the SHA bytes) using SecureHexAIS_OMAP-L138.exe. Lo and behold this binary image worked on the a secure OMAP, as it no longer tying to load into the start address (0xc9000000) the character for path of “…\configPkg.TI” over the top of the executable code.

Hence there is a systemic problem with the SecureHexAIS_OMAP-L138.exe that needs be fixed.

 

5. Now that I have confidence in my ability to generate binary files by the modification of the .out files using SYS-BIOS for both the ARM core and DSP core, I put my focus back into why GenericSecureUartHost.exe is getting stuck when I combine it only with the SYS-BIOS ARM firmware (even a simply version flashing led SYS-BIOS). Then it dawned on me, I could see in the dialogue box for GenericSecureUartHost.exe that it was try to load the ARM resect vectors in the address 0xFFFF0000 and 0xFFFF0040. Which in my understanding this is not possible on a secure OMAP device because the DSP does not have access to this area of memory.

 

So doing the same thing again by modify the ARM’s core .out file and deleting another section near the end of the file (this time an additional 80bytes) in order remove the load command for the reset vector memory at 0xFFFF0000 and 0xFFFF0040, i.e. delete the following and readjust the e_shnum (@ 0x00000030) and @ (0x00000032)

 

 

I was able to build a binary file using SecureHexAIS_OMAP-L138.exe for both the DSP and ARM firmware that no longer got stuck up in GenericSecureUartHost.exe waiting for DONE…

Which meant that I was able to then J-TAG into the secure processor again.

Note: The ARM core still does not run because it no longer has the correct re-direction for the HWI at 0xFFFF0000 and 0xFFFF0040

 

6. Hence now for the ARM firmware I have written code so that right at the beginning of the function main() it now write directly to the PRUSS registers 0xFFFF0000 to 0xFFFF3C (inclusive) (hardcoded).

Note: in order to achieve this I have specified the exact memory location of the following:

".c_int00 { boot.ae9<boot.oe9> (.text) }"

".text:ti_sysbios_family_arm_da830_Hwi_dispatchFIQC__I"

".text:_ti_sysbios_family_arm_da830_Hwi_dispatchIRQ__I"

".text:ti_sysbios_family_arm_exc_Exception_excHandlerAsm__I"

In app.cfg so that the linker can only use this area of memory in the generation of it .map file.

 

So again with the laborious task of modifying the “.out” file for the ARM core, each time I make a change, I was successful in using GenericSecureUartHost.exe and see that my code run on both the DSP core and ARM, as it had been on the non-secure version.

 7. However that is not the end of the story, it would appear that my celebration was premature and short lived. It would appear that this secure image would only run successfully after the I had already J-TAG onto the processor.

After a fresh power cycle the same image would no longer work. This is a bit of a problem when I want the program to load from SPI flash when it turns on.

Note: GenericSecureUartHost.exe will complete successfully. And I know the DSP core is loading and running fine, and I suspect that the ARM core is too, but it is ASSERTING for some reason, and therefore hanging/non-responsive.

However, I can then load the same firmware over J-TAG on the secure processor and it will run fine.

My suspicion is that by J-TAGing onto the OMAP using CCS, it is loading something (I guess into the PRUSS) which is no longer configured after a power cycle, but is retain on a hardware reset.

 

This is my last hurdle and if I can work out why the ARM SYS-BIOS is ASSERTING that will be most helpful. Again my suspicion is that the PRUSS HWI vector table is not being setup correctly as part of SecureHexAIS_OMAP-L138.exe (because I have removed it from the ARM’s .out file) because if I don’t GenericSecureUartHost.exe gets stuck in “waiting for DONE…”

So I thought I had solved this by specify this using this chuck of code in main() on the ARM core.

 

   PRUSS1->REGISTER0 = 0xE59FF018;

   PRUSS1->REGISTER1 = 0xE59FF018;

   PRUSS1->REGISTER2 = 0xE59FF018;

   PRUSS1->REGISTER3 = 0xE59FF018;

   PRUSS1->REGISTER4 = 0xE59FF018;

   PRUSS1->REGISTER5 = 0xE59FF018;

   PRUSS1->REGISTER6 = 0xE51FFA1C;

   PRUSS1->REGISTER7 = 0xE51FFA24;

   PRUSS1->REGISTER8 = address_c_init00;           // = _c_init00_

   PRUSS1->REGISTER9 = address_excHandlerAsm;     // = SYS-BIOS_Exception_HandlerAsm

   PRUSS1->REGISTER10 = address_excHandlerAsm;     // = SYS-BIOS_Exception_HandlerAsm

   PRUSS1->REGISTER11 = address_excHandlerAsm;     // = SYS-BIOS_Exception_HandlerAsm

   PRUSS1->REGISTER12 = address_excHandlerDataAsm; // = SYS-BIOS_Exception_HandlerDataAsm

   PRUSS1->REGISTER13 = address_excHandlerAsm;     // = SYS-BIOS_Exception_HandlerAsm

   PRUSS1->REGISTER14 = address_DipatchIRQ;       // = SYS-BIOS_HWI_DispatchIRQ

   PRUSS1->REGISTER15 = address_DipatchFIQ;       // = SYS-BIOS_HWI_DispatchFIQ

 

   //reset PRUSS HWI Vector table

   PRUSS_HWI->HWI15_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI20_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI21_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI22_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI23_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI25_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI48_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI53_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI56_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI61_PC_ADDRESS = address_DipatchIRQ;

   PRUSS_HWI->HWI68_PC_ADDRESS = address_DipatchIRQ;

 

Note: I can see in the memory map that HWI96 is also specified to address_DipatchIRQ as well, which I’m currently not doing. Because I according the OMAP Technical Reference Manual pg 258 was reserved.

Upon writing this I can see that this was for the OMAPL137 and that for the OMAPL138 HWI96 is for Timer64P3 Combined Interrupt (TINT12 and TINT34), which I’m in fact using.

I will see if that fixes, I’m not sure if it will or not.

 

Because I feel that the arm core is just getting stuck here: 0xFFFF0010 and ti_sysbios_family_arm_exc_Exception_excHandlerDataAsm__I

 

If you are able to provide any further assistance that will be wonderful and request that TI fix up SecureHexAIS_OMAP-L138.exe so I no longer need to modify the “.out” file each I want to build a new binary.

I’m not sure how it will fix loading PRUSS with the ARM's SYS-BIOS HWI vector table as apart of SecureHexAIS_OMAP-L138.exe and GenericSecureUartHost.exe

 

Thanks,

Matt

Hi Titus,

Did you and the internal team get any further with this issue in generating binary outputs using SecureAISGen?

Thanks

Matt

Hi Titus,

It has been another month which has passed. Have you and you team got any closer to finding a solution?

Thanks

Matt