Booting SYSBIOS application on OMAPL137

Eduard,

Details of this topic are covered in this wiki:

http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L137#Booting_ARM_Binaries

Please let us know if you have any follow up questions on this.

Regards,

Rahul

Hi Rahul,

thanks for your reply. I have already read that wiki. I also tried the LED example previously. It was working and booting from Flash properly. I tried to do the same in my SYSBIOS project by including the device.c and and calling DEVICE_enable_ARM() .So the top of my main() function looks like this:

Int main(Int argc, Char* argv[])
{
    // Open Permissions to SYSCFG Registers
    CSL_FINS(sysRegs->KICK0R, SYSCFG_KICK0R_KICK0, KICK0_KEY);
    CSL_FINS(sysRegs->KICK1R, SYSCFG_KICK1R_KICK1, KICK1_KEY);
    DEVICE_enable_ARM();
...
} 

But in contrast to the LED example I can observe that the pointer to the ARM boot address does not get set correctly by PRUSS0. After the DSP takes the ARM out of reset the disassembly content of the memeory at address 0xFFFF0000 on the ARM looks like this:

ffff0004:   EAFFFFFE B              0xFFFF0004
ffff0008:   EAFFFFFE B              0xFFFF0008
ffff000c:   EAFFFFFE B              0xFFFF000C
ffff0010:   EAFFFFFE B              0xFFFF0010
ffff0014:   EAFFFFFE B              0xFFFF0014
ffff0018:   EAFFFFFE B              0xFFFF0018
ffff001c:   EAFFFFFE B              0xFFFF001C
ffff0020:   00000000 ANDEQ         R0, R0, R0
ffff0024:   E51F000C LDR           R0, 0xFFFF0020
ffff0028:   E1A0F000 MOV           PC, R0

So at 0xFFFF0020 where the DEVICE_ARM_UBL_LOAD_ADDR (which I defined to 0xC1000000) should be located, it looks like the PRUSS0 has not loaded the ARM boot address to that location. What am I missing here?

Apart from that I would be glad if you could explain me one more thing.  In http://processors.wiki.ti.com/index.php/OMAP-L137_Bootloader it says: "

For a typical Linux application, the old flow looked something like this:

• DSP UBL (sets the ARM reset vector and takes it out of reset)
• ARM UBL (sets up DDR, PSC, and copies U-Boot to memory)
• U-Boot (loads Linux and file system)
• Linux

The flow for the OMAP-L137 would look like this:

• AIS-signed DSP UBL (sets ARM reset vector, sets up DDR and PSCs, copies U-Boot to memory, and takes ARM out of reset)
• U-boot (loads Linux and file system)
• Linux

"

So as I am using AISgen for D800K003 (which matches my ROM version) I would expect that the bootloader would take care of setting the reset vectors. But thi was not the case, which was the reason why I included device.c into my project and load the reset vectors manually. I tried to check the created .bin file to see if the ARM boot address was copied in there. I found the following section in the .bin file

0003ff3bh: EA FE FF FF EA FE FF FF EA FE FF FF EA FE FF FF ; êþÿÿêþÿÿêþÿÿêþÿÿ
0003ff4bh: EA FE FF FF EA FE FF FF EA FE FF FF EA 00 00 00 ; êþÿÿêþÿÿêþÿÿê...
0003ff5bh: 00 0C 00 1F E5                                  ; ....å

which looks the code that is copied to the ARM reset vector table. It looks like the bootloader also doesn't initialize the boot address to 0xC1000000 but uses 0x00000000 instead. So how can I make use of the bootloader capability to load the ARM boot address into the vector table?

I tried adding a custom Linker file to the ARM project with the following section:

SECTIONS
{
     boot > 0xc1000000
     {
          -l"D:\ti\xdctools_3_23_03_53\packages\ti\targets\arm\rtsarm\lib\boot.ae9"<boot.oe9>(.text)
     }*/
}

But this did not help neither. So should I rather use the bootloader or device.c to load the boot ARM address? And what am I doing wrong in both variants? 

Regards
Eduard

Today I used aisparse.exe provided by TI to parse my ais file. And I found this:

/* 0x0006A5C0 */ 0x58535901, // Section Load
/* 0x0006A5C4 */ 0xFFFF0000, //   Address (ARM RAM, Local)
/* 0x0006A5C8 */ 0x00000040, //   Size
/* 0x0006A5CC */             //   Data
/* 0x0006A5CC */ 0xE59FF018,
/* 0x0006A5D0 */ 0xE59FF018,
/* 0x0006A5D4 */ 0xE59FF018,
/* 0x0006A5D8 */ 0xE59FF018,
/* 0x0006A5DC */ 0xE59FF018,
/* 0x0006A5E0 */ 0xE59FF018,
/* 0x0006A5E4 */ 0xE51FFA1C,
/* 0x0006A5E8 */ 0xE51FFA24,
/* 0x0006A5EC */ 0xC1000000,
/* 0x0006A5F0 */ 0xC0020FC4,
/* 0x0006A5F4 */ 0xC0020FC4,
/* 0x0006A5F8 */ 0xC0020FC4,
/* 0x0006A5FC */ 0xC0021000,
/* 0x0006A600 */ 0xC0020FC4,
/* 0x0006A604 */ 0xC0020A60,
/* 0x0006A608 */ 0xC001B088,

So it looks like the AISgen tool correctly identifies the entry point for the ARM code (0xC1000000 marked yellow). But when I copy the binary to flash and boot it from there the reset vector is set to 0x00000000 as stated in my previous post. So just to make sure I am understadning it right:

1. Is he bootloader able to access the ARM local RAM and copy the reset vectors on location 0xFFFF0000? I am asking because in the OAMPL137 memory map it says that only ARM and PRUSS0 are allowed to access ARM local RAM.

2. If the bootloader should be able to write ARMs reset vectors, what might be the reason why it is not loaded correctly in my case?

3 If the bootloader can not access ARM local RAM, then I am responsible to load the reset vectors to ARM locoal RAM during startup through PRUSS0?

Help is highly appreciated

Thanks and regards
Eduard