PROCESSOR-SDK-AM64X: Bootloader image parsing issue

Ajay Kumar

Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: AM6442, UNIFLASH

Tool/software:

Hi,

I am using AM6442 Starter kit board with sdk 10.01.00.32 and currently using default bootloader. for appimage i am using hello world appimage.hf_fs file. here is my flow, i am getting issue at Bootloader_parseMultiCoreAppImage() function. Here is my ospi.cfg:

# First point to sbl_uart_uniflash binary, which function's as a server to flash one or more files

--flash-writer=sbl_prebuilt/am64x-sk/sbl_uart_uniflash.release.hs_fs.tiimage

# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter

# Program the OSPI PHY tuning attack vector

--operation=flash-phy-tuning-data

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0

--file=sbl_prebuilt/sbl_ospi.Release.hs_fs.tiimage --operation=flash --flash-offset=0x0

# When sending application image, make sure to flash at offset 0x80000 (default) or to whatever offset your bootloader is configured for

--file=../../examples/hello_world/am64x-sk/hello_world_am64x-sk_r5fss0-0_nortos_ti-arm-clang.appimage.hs_fs --operation=flash --flash-offset=0x80000

consider path as correct. i am using booloader debugging (adding loop_forever() in main()) then getting it to Bootloader_parseMultiCoreAppImage(), after this few things, i have observed:

if i use "Application Image Is X509 Signed" my bootloader moves to:

but if i dont use "Application Image Is X509 Signed" its going to flash read:

i want to understand how changing this make bootloader this callback from mem read to flash read:

Currently i am using without signed and getting status of above config->fxns->imgReadFxn status as 0 (when i was using app signed image my control flow getting stuck inside mem_read function) but after this "mHdrStr.magicStr != BOOTLOADER_META_HDR_MAGIC_STR" making status as -1 and leaving the function making flow of bootloader wrong after this. I need help in resolving this issue:

first want to understand all file format in ospi.cfg is correct ?

second how memread to flashread is change is happening ?

this do i have to use another format file in cfg for appimage as current image magic header is getting wrong?

can you share your cfg and bootloader tiimage and hello world image which is working?

6 months ago

0 Meet Thakar 6 months ago

TI__Genius 12355 points

Hi Ajay,

Ajay Kumar said:
first want to understand all file format in ospi.cfg is correct ?

I don't see any issues in the config file.

Ajay Kumar said:
second how memread to flashread is change is happening ?

Mem_imgRead is usually used in the case when you are reading the image from SoC memory like DDR. I am also observing this at my end, I think it should be Flash_imgRead for SBL_OSPI, not sure why it goes to Mem_imgRead, let me try to check internally on this.

Ajay Kumar said:
this do i have to use another format file in cfg for appimage as current image magic header is getting wrong?

So when you disable "Application Image Is X509 Signed" option, SBL expects an unsigned image meaning a .appimage not an hs_fs one, hence leading to this failure. If you just want to bypass the image authentication, I suggest you choose Disable Auth For Application Image option instead:

After enabling this option, I think you would be able to boot the application image.

Ajay Kumar said:
can you share your cfg and bootloader tiimage and hello world image which is working?

I am using the default images available in the MCU+SDK, I assume you are using the same. If not, I suggest you try to boot with the default image without making any changes and see if that works or not.

Best Regards,

Meet.

0 Meet Thakar 6 months ago in reply to Meet Thakar

TI__Genius 12355 points

Hi Ajay,

Here's the reason why Mem_imgRead is being used if you use "Application Image Is X509 Signed" option. If you have enabled this option then Bootloader_parseMultiCoreAppImage calls Bootloader_verifyMulticoreImage API. This API copies the appimage to the RAM:

As the image is already in the RAM, this same function changes the boot media from OSPI to Memory at a later point:

That's why config->fxns->imgReadFxn points Mem_imgRead. Bootloader_verifyMulticoreImage API gets skipped if you have disabled the authentication of the Appimage, so in this case the bootmedia is not changes to Mem and config->fxns->imgReadFxn points to Flash_imgRead.

0 Ajay Kumar 6 months ago in reply to Meet Thakar

Prodigy 50 points

Hi Meet,

Thanks for the reply. I tried with enable as well as Disable "Auth For Application Image", with both its going to Mem_read and then getting aborted. attached here is screenshot before aborted.

I am attaching my cfg, hello world as well as ospi bootloader folder(i am trying with default only now) pls verify from your end its working for AM6442 board with sdk 10.01.sbl_ospi_am64x-sk_r5fss0-0_nortos_ti-arm-clang.zip hello_world_am64x-sk_r5fss0-0_nortos_ti-arm-clang.zip

custom_sbl_ospi.cfg

Pls verify from your end can you see Hello world on your terminal. here is the output on my terminal:

0 Meet Thakar 6 months ago in reply to Ajay Kumar

TI__Genius 12355 points

HI Ajay,

Could you please let me know the following details:

When you enter Mem_imgRead what are the values of these variables: dst, memArgs->appImageBaseAddr, memArgs->curOffset and len

Please open the address stored in dst and appImageBaseAddr in the Memory browser and share the screenshot of the same here like this:

You mentioned that you encounter an abort error as soon as you step over memcpy function, could you check what values you observe in the memory browser for these 2 address after you step over memcpy.

Best Regards,

Meet.