MCU-PLUS-SDK-AM243X: RBL boot from flash

Jun Tu

Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: UNIFLASH, SYSCONFIG

Tool/software:

Hi,

I am running am243 without os.

I run the example sbl_null.release.hs_fs.tiimage on my board, my board is using this S28HL01GTFPBHI030

However, after I successfully upload the default image, I switch to ospi boot mode.

Nothing came out of uart0.

What is the default setting for flash in sbl_null, Should I config my flash to that settings?

How can I debug out of it?

Thanks.

8 months ago

0 Jun Tu 8 months ago

Expert 1520 points

I switch back to dev boot mode, and dump my flash, so sbl_null.release.hs_fs.tiimage is right at offset 0x60000000 all the contents is exactly the same.

1. what could be the issues? 2. How to debug RBL unable to boot problem?
3. what default flash config is RBL expected, eg: besides 1s-1s-1s, what is else?

sbl_null.release.hs_fs.tiimage is under C:\ti\mcu_plus_sdk_am243x_09_02_00_50\tools\boot\sbl_prebuilt\am243x-evm

0 Vaibhav Kumar 8 months ago in reply to Jun Tu

TI__Mastermind 44246 points

Hi Jun,

Jun Tu said:
However, after I successfully upload the default image,

Do you mean to say you were successfully able to flash the sbl null(bootloader) using uart uniflash?

If yes, then sbl null has no OSPI comfiguration, but uart uniflasher will have OSPI configuration, so on that note, can you tell me in which mode you are operating OSPI Controller/Flash in uart uniflasher?

Did you updated the flash configuration values in the Flash tab in SysConfig? As different flash parts have different flash configurations.

Jun Tu said:
sbl_null,

SBL Null in my previous debugs, does not have the OSPI settings at all.

Regards,

Vaibhav

0 Jun Tu 8 months ago in reply to Vaibhav Kumar

Expert 1520 points

Hi, Vaibhav, I have solved my problem, Now I understand everything. You are right, but this is not the answer I expected.

"SBL Null" does not configure OSPI settings, as this responsibility lies with the RBL. After booting from SBL Null, the flash contents can be directly accessed through memory mapping. For example, if we put below code at the beginning of "SBL NULL":

<code>
uint32_t *mem = (uint32_t *)(0x60000000);
printf("%x", *mem);
</code>

This will print the contents of the flash-mapped memory. we can keep printing and dump everything. "printf("%x", mem[n])" you will find it is "SBL NULL "

1. Potential Issues

If the RBL fails to boot, initial troubleshooting steps include:

Verifying the clock signals using an oscilloscope.
Checking the OSPI data lines for proper connectivity and functionality.

2. Debugging an RBL Boot Failure

If hardware components, such as the clock and data lines, are functioning correctly, focus on the flash configuration. Specifically, verify the flash mode. Many flash devices support SFDP (Serial Flash Discoverable Parameters) mode, as described in the flash device user manual. For instance, some flash devices operate exclusively in SFDP mode.

3. Default Flash Configuration Expected by the RBL

In SFDP mode, the RBL initially operates in 1S-1S-1S mode before reconfiguring to 8D-8D-8D mode. The RBL then reads the TIImage starting from address 0x0 and boots from it.

At the beginning of the main function of the booted TIImage, dumping the memory will reveal the contents of the flash, regardless of the specific image being booted.

Thanks, please review and give me some ti points.

+1 Vaibhav Kumar 7 months ago in reply to Jun Tu

TI__Mastermind 44246 points

Hi Jun,

Jun Tu said:
"SBL Null" does not configure OSPI settings, as this responsibility lies with the RBL. After booting from SBL Null, the flash contents can be directly accessed through memory mapping. For example, if we put below code at the beginning of "SBL NULL":

<code>
uint32_t *mem = (uint32_t *)(0x60000000);
printf("%x", *mem);
</code>

This will print the contents of the flash-mapped memory. we can keep printing and dump everything. "printf("%x", mem[n])" you will find it is "SBL NULL "

That is correct understanding.

Make sure to keep in mind, that whenever you are able to see the flash contents in SoC memory space starting from 0x60000000, it is because DAC is enabled, if DAC was disabled you would not be able to do so.

The rest of the points are correct as well.

I am marking it as TI Thinks resolved, thanks for writing a detailed explanation.