AM6442: Booting from OSPI without using DDR

yellowhat_engineer

Part Number: AM6442
Other Parts Discussed in Thread: UNIFLASH, TMDS64EVM

We are developing a custom board based on the AM64x EVM however this board will have no on-board DDR4 memory.

The current sbl_uart_uniflash and sbl_ospi bootloader projects (SDK/examples/drivers/boot/) seems to be setup to utilize DDR.

In sbl_uart_uniflash syscfg, DDR is enabled and the Memory Region for "DDR" is set to the DDR 0x80000000 address offset.

In sbl_ospi syscfg, the Memory Region for "APPIMAGE" is also set to DDR.

I am relatively new to memory setup in devices like this.

What do I need to do to make sure DDR is not used and instead the APPIMAGE goes to say MSRAM?
We only need one 256KB section of MSRAM for testing.

The plan is to use the following script to flash our app image to the OSPI.

python uart_uniflash.py -p COMxx --cfg=default_sbl_ospi.cfg

The default_sbl_ospi will be modified to use any updated uniflash/ospi bootloaders, and to include the app image.

Any advice on this would be greatly appreciated.

2 months ago

+1 Meet Thakar 2 months ago

TI__Mastermind 19700 points

Hi Darren,

yellowhat_engineer said:
What do I need to do to make sure DDR is not used and instead the APPIMAGE goes to say MSRAM?
We only need one 256KB section of MSRAM for testing.

You just need to make some changes in the syscfg file to allocate APPIMAGE section to MSRAM instead of DDR, applying following patch for your example.syscfg should do this:

diff --git a/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/example.syscfg b/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/example.syscfg
index 7ea52edd..69bd7184 100644
--- a/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/example.syscfg
+++ b/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/example.syscfg
@@ -128,11 +129,10 @@ region1.memory_region[5].$name              = "MSRAM_1";
 region1.memory_region[5].auto               = false;
 region1.memory_region[5].size               = 0x10000;
 region1.memory_region[5].manualStartAddress = 0x70070000;
-region1.memory_region[6].size               = 0x800000;
-region1.memory_region[6].type               = "CUSTOM_ALL";
 region1.memory_region[6].auto               = false;
-region1.memory_region[6].manualStartAddress = 0x82000000;
-region1.memory_region[6].$name              = "APPIMAGE";
+region1.memory_region[6].size               = 0x40000;
+region1.memory_region[6].$name              = "MSRAM_APPIMAGE";
+region1.memory_region[6].manualStartAddress = 0x70100000;
 
 section1.$name                        = "Vector Table";
 section1.group                        = false;
@@ -202,9 +202,9 @@ section4.output_section[4].input_section.create(1);
 section4.output_section[4].input_section[0].$name = ". = . + __UNDEFINED_STACK_SIZE;";
 
 section5.type                         = "NOLOAD";
-section5.load_memory                  = "APPIMAGE";
-section5.$name                        = "DDR";
 section5.group                        = false;
+section5.$name                        = "MSRAM";
+section5.load_memory                  = "MSRAM_APPIMAGE";
 section5.output_section.create(1);
 section5.output_section[0].$name      = ".bss.app";
 section5.output_section[0].alignment  = 0;

You will also need to reduce the size of gAppimage buffer in main.c, so that it can be allocated in the MSRAM section, currently I have kept it as 256kB due to MSRAM memory space constraint:

diff --git a/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c b/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c
index 54583541..43f5f639 100644
--- a/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c
+++ b/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c
@@ -44,7 +44,7 @@
  * image decryption and authentication
  * The size of the buffer should be large enough to accomodate the appimage
  */
-uint8_t gAppimage[0x800000] __attribute__ ((section (".app"), aligned (4096)));
+uint8_t gAppimage[0x40000] __attribute__ ((section (".bss.app"), aligned (4096)));
 
 void flashFixUpOspiBoot(OSPI_Handle oHandle);

0 yellowhat_engineer 2 months ago in reply to Meet Thakar

Prodigy 120 points

Hi Meet,

With your support I was able to build the OSPI bootloader.

Before testing on my hardware, I tried using the "uart_uniflash.py" script to flash the data to OSPI on the TMDS64EVM, but had some issues.

1. Sent sbl_uart_uniflash.release.hs_fs.tiimage
2. flash-phy-tuning-data (sends some 128bytes to the end of the OSPI flash for tuning later) STATUS:SUCCESS
3. sbl_ospi file built following guide above -> "incorrect magic number in file header!"
4. appimage also had the incorrect magic number error.
5. xip image was STATUS:SUCCESS

From this post (link) and checking the UNIFLASH bootloader project - I see CONFIG_SECTION0 (.bss.filebuf) is using DDR to store the appimage before flashing to OSPI?

I tried similar modifications as with the OSPI example to remove DDR and use MSRAM (including adjusting the BOOTLOADER_UNIFLASH_MAX_FILE_SIZE in "main.c"), but I am still having trouble. Could you provide similar code modifications for UNIFLASH too?

Side Note:
I have successfully used the uart_bootloader.py script to load the UART bootloader and the sample OSPI diagnostic and I/O sample applications, which show r/w to the OSPI are successful - I don't believe there are any hardware/layout issues with the SoC <--> OSPI chip. My trouble seems to be in configuring the boot setups...

0 Meet Thakar 2 months ago in reply to yellowhat_engineer

TI__Mastermind 19700 points

Can you try this for your UART UNIFLASH and check if it works: RE: AM2431: AM2431 – UART Uniflash to OSPI Flashing Failure with HS-FS SBL on Custom Board

0 yellowhat_engineer 2 months ago in reply to Meet Thakar

Prodigy 120 points

Hi Meet, I will try on Tuesday (JST). In the meantime, I have been reviewing the bootloader process from the TRM and supporting E2E posts.
For my goal of using OSPI with no DDR, would the following high-level changes/flow summary be accurate?

1. The UNIFLASH and OSPI bootloader projects are rebuilt to remove DDR and set APPIMAGE file buffer to MSRAM
2. We boot the AM64x board in UART mode and ROM factory code initalizes UART drivers and waits for an image while sending "C" via TX line
3. When running uart_uniflash.py we initially send the UNIFLASH bootloader via Xmodem protocol
The AM64x receives this image, maps required data/variables to MSRAM0/1/2 (DDR->MSRAM2), and runs the UNIFLASH SBL
4. Next a ospi flash configuration command is run, telling the UNIFLASH bootloader to send some tuning data to the OSPI chip
5. Next we send the OSPI SBL image, which the UNIFLASH SBL stores in MSRAM2
6. After storing the image, UNIFLASH SBL passes it to OSPI FLASH at offset 0x000 (where ROM will look for SBL on OSPI boot)
7. The UNIFLASH code will also perform magic number and verification checks on the data
8. Next we send the appimage to offset 0x8... with the Xmodem command, and UNIFLASH receives/passes the file to OSPI

We then power cycle the board and transition to OSPI BOOT mode - in this case the ROM will look at the OSPI offset 0x0 for the SBL, and pull the important variables into MSRAM0/1, then set aside space for the appimage in MSRAM2 (DDR->MSRAM2 changes made)

After loading the SBL, the SBL takes over and pulls the APPIMAGE in MSRAM2, and the program begins to run.

Is the above flow understanding correct? Most changes can be made through SYSCFG but there are some variables/sizes that need to be changed in C code, right?

0 Meet Thakar 1 month ago in reply to yellowhat_engineer

TI__Mastermind 19700 points

yellowhat_engineer said:
Is the above flow understanding correct?

This is mostly correct.

yellowhat_engineer said:
The AM64x receives this image, maps required data/variables to MSRAM0/1/2 (DDR->MSRAM2), and runs the UNIFLASH SBL

So UNIFLASH uses this buffer placed in DDR (MSRAM in your case) to receive the image and then copy it to the flash later, if you are using MSRAM then you need to make sure that your image can fit in this buffer.

yellowhat_engineer said:
After loading the SBL, the SBL takes over and pulls the APPIMAGE in MSRAM2, and the program begins to run.

The SBL uses the gAppimage buffer placed in DDR (MSRAM in your case) to temporarily load the image for authentication, this is already mentioned in the comments: https://github.com/TexasInstruments/mcupsdk-core/blob/next/examples/drivers/boot/sbl_ospi/am64x-evm/r5fss0-0_nortos/main.c#L47

yellowhat_engineer said:
Most changes can be made through SYSCFG but there are some variables/sizes that need to be changed in C code, right?

This is correct.

0 yellowhat_engineer 1 month ago in reply to Meet Thakar

Prodigy 120 points

Hi Meet,

Thanks to your advice I figured out what I needed to do.

OSPI boot is working fine now.

I needed to understand the MSRAM memory map and SBL/App placements better, and the C code changes required for all memory adjustments.

After working through this, I was able to build the example SBL applications without DDR and have my board use the OSPI to pull the image into MSRAM and begin running. My sample application is working fine as well.

Thanks!

0 Meet Thakar 1 month ago in reply to yellowhat_engineer

TI__Mastermind 19700 points

Hi Darren,

Thanks for the update, glad to know you got your application working. Closing this thread.

Thanks,

Meet.

Processors

Processors forum

AM6442: Booting from OSPI without using DDR