AM2431: AM243x EVM boot via FLASH

Hi Prasanna,

Prasanna Raghunathan said:

I programmed the same images to flash via UART UNIFLASH and reset the board to OSPI BOOTMODE and I ran into an issue where the DMSC SYSFW is not starting. I connected to my SBL from CCS and saw that my SBL is forever waiting on Bootloader_socWaitForFWBoot().

This issue mostly occurs when you have already flashed the SBL in OSPI and SBL OSPI had already booted and then you try to load the SBL to R5 in CCS, you have to follow some specific steps if you have to debug SBL, please refer to this FAQ:  [FAQ] AM62X/AM64X : [FAQ] Debugging SBL boot in RTOS SDK 

Prasanna Raghunathan said:

So I realized, I am missing the SoC initialization/SYSFW which was done via the javascript from CCS.

This is not needed in case you have flashed the SBL OSPI and booting in OSPI boot mode, if you don't connect to CCS and just let the board free run, do you observe the expected logs?: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/11_01_00_17/exports/docs/api_guide_am243x/GETTING_STARTED_FLASH.html#autotoc_md63

Prasanna Raghunathan said:

Is it possible to solely boot from the flash in OSPI BOOT MODE ?

Yes

Prasanna Raghunathan said:

How do I create this boot image for both the DMSC - M3 CORE and R5 CORE-0 targets 

Please refer to this guide: https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/11_01_00_17/exports/docs/api_guide_am243x/BOOTFLOW_GUIDE.html#autotoc_md627

You can refer to the linker file for SBL OSPI as well to understand how the final tiboot3.bin is built: https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/boot/sbl_ospi/am243x-evm/r5fss0-0_nortos/ti-arm-clang/makefile

Best Regards,

Meet.

Hi Meet,

Thanks for your detailed response. Yes, I have already debugged my SBL using the loop_forever() method to connect to the core and run it from there. This is how I validated my SBL as well as FW App. 

When I reset the board to OSPI BOOT and reboot, I don't see any logs on the console or a sense of the system actually booting up. I would expect to see the DMSC Firmware logs show up which I saw from CCS debugging and also my firmware application not printing any logs to the console. I am using the same USART0 instance on both my SBL and FW app. 

I added back the loop_forever() to my SBL, flashed it to the EVM and reset the board and waited for SoC to boot and I connected to the core and saw that the SBL is stuck on waiting for Boot from SYSFW. 

When I go back to the pre-built SBL_OSPI.hs.fs.tiimage + SDK Example Helloworld app, I see all the logs on the console.

This is why I am wondering if the DSMC didn't start properly or my SBL blob is missing the SYSFW binary + boardcfg.

Thanks,

Prasanna

Hi Meet,

Here is what's happening..

- Booting from flash, no console logs, no trace of any life in the board. Use JTAG to connect to the target and when checked, the SBL is stuck at Bootloader_socWaitForFWBoot()

- Booting from flash, use the SBL debug method to add the infinite loop to main(). Use JTAG to connect to the target and breakout of infinite loop and step through the SBL code, everything works. Console prints out all the logs. I did notice that due to the CPSW Lockup issue, during a COLD Reboot there is an additional check and reset the SoC again to make a warm reboot before SBL proceeds. 

Without involving CCS, the SBL is stuck at the same point. I am wondering why there is a difference. 

Hi Prasanna,

Thanks for the explanation, could you please share your SBL OSPI image with me.

Best Regards,

Meet.

pr_sbl_ospi_image.zip

I am trying to get this image to boot from OSPI using only the Internal SRAM of 2MB. I have disabled the external DDR on the EVM.

Here is how I partitioned my bootloader and my FW image. Everything is target to run on the R5FSS0_0 core only.

0x70000000 to 0x70110000 - SBL

0x70110000 to 0x70200000 - FW Application Image

I have disabled authentication on the bootloader for my FW Application Image for now. But I have allocated extra space (0x70080000 - 0x70110000) for authenticating the image later when everything is working.

Hi Prasanna,

There is a 128kB of space from 0x701E0000, that is reserved for DMSC operations, it seems like your application might be overlapping with this region, which could be causing this issue.

Please refer to this memory map while allocating space for SBL and application: AM243x MCU+ SDK: Memory Map Layout

Best Regards,

Meet.

Hi Meet,

I will check this out. But how is it working fine when using CCS and stepping through the code ?

So it's impossible to boot from the internal SRAM alone then ? Is there an image size limit ? Do you have any documentation that talks about this ?

Thanks,

Prasanna

Hi Meet,

I tested the version by stripping out the additional buffer allocated for app image authentication. It shows the same behavior. 

I use the internal SRAM from 0x70080000 to 0x70180000 only. This is within the acceptable range of the SBL load area. 

Thanks,

Prasanna

Hi Prasanna,

I can try to test this once at my end, could you let me know which MCU+SDK version you are using?

SDK release : AM243X_10_01_00_32

Hi Prasanna,

I will test this once on my end, and provide an update.

Best Regards,

Meet.