AM620-Q1: Security designation

Hong,

Yes, I found this link on Friday.

Using UART Flash Mode, I get the following:

I don't get past command 3.

The log indicates MCU+SDK is used in your testing.
Let me pass it to my colleague for input on MCU+SDK...
Best,
-Hong

Hi Jim,

I assume you are working with a custom board. If so, may I know what flash part you are using on your board?

Hong,

IS22TF32G-JCLA2-TR (NAND FLASH) I believe.

Jim Meyer said:

IS22TF32G-JCLA2-TR (NAND FLASH) I believe.

Then, the failure is expected. Without any modifications, the SBL_UART_UNIFLASH from am62x-sk folder is meant for TI AM62x-SK board which has NOR flash. So, it tries to initialize the same and expectedly fails.

Since, AM620-Q1 is an AMC package, you would need to use any example from the am62x-sk-lp folder. So, you would need to use: sbl_prebuilt/am62x-sk-lp/default_sbl_null_hs_fs.cfg.

Ofcourse, without any modifications to the SBL_UART_UNIFLASH in am62x-sk-lp folder, the procedure is most likely to fail. You would have to integrate the custom DDR configurations in the SBL_UART_UNIFLASH_STAGE1 and custom NAND flash configurations in SBL_UART_UNIFLASH_STAGE2.

Regards,

Prashant

Prashant,

     OK!  Can we change the config files to run out of Internal RAM (initially)?  Also, it looks like the SD Card boot clock starts at 400KHz, transitions to 25MHz and finally changes to 50MHz.  Is there a way to reduce the speed (since our SD access is external to the PCB)?  Like the DDR, is there a flash configuration tool, as well?  And finally, is there a Sysconfig file for the AM62x-sk-lp board I can use as a template?

     Thanks!  

Hi Jim,

Jim Meyer said:

Can we change the config files to run out of Internal RAM (initially)?

This is not possible. The AM62 family of devices have very limited RAM. That's why we have two stages of SBL_UART_UNIFLASH where first stage runs from internal RAM only but the Stage2 then runs from the DDR. On the other hand, the Stage2 also needs to use some buffer to store the received images over UART before flashing them. That buffer is also allocated to DDR only.

So, the first stage to get the UNIFLASH working is to integrate the right custom DDR configurations in the Stage1.

Jim Meyer said:

Is there a way to reduce the speed (since our SD access is external to the PCB)?  Like the DDR, is there a flash configuration tool, as well?

I believe this is already being discussed here

ttps://e2e.ti.com/support/processors-group/processors/f/processors-forum/1367587/am620-q1-i-wanted-to-quickly-test-the-sd-boot-feature-on-our-custom-board-however-though-i-know-the-image-is-not-customized-i-expected-the-boot-process-to-proceed-further

Jim Meyer said:

And finally, is there a Sysconfig file for the AM62x-sk-lp board I can use as a template?

All the examples in the MCU+ SDK uses Sysconfig for different configurations.

Like for DDR, you would open the Stage1 Sysconfig and choose the DDR module to give path to your custom DDR config file

For NAND configuration, you would do that in Stage2 Sysconfig

Regards,

Prashant

Prashant,

                OK!  After reviewing our custom board hardware, I realized we have no OSPI Flash.  It appears as thought the OSPI Flash is used in the boot process (on the development boards).

                Also, I’ve reviewed the Build U-Boot instructions and can successfully build U-Boot on my native Linux machine (SDK top level only at this point).  I used the “defconfig” file that was provided but see the “am62x_evem_r5_defconfig” and “am62x_evm_a53_defconfig” located in another folder.  I’ve also located the *.dts files.  I believe I found the ddr file, as well – “k3-am62x-ddr-lp4-50-800-800.dtsi’.

                Integrating the Sysconfig files is my question…  There are three options in the Sysconfig tool for “context” (m4fss0-0, r5fss0-0 and a53ss0-0).  Can you outline the process I should follow once I create a “board_ddrRegInit.h” file (if I want to integrate the new DDR with a “minimal” configuration).   I’m using my Windows machine for debugging.

Hi Jim,

Jim Meyer said:

Can you outline the process I should follow once I create a “board_ddrRegInit.h” file (if I want to integrate the new DDR with a “minimal” configuration).   I’m using my Windows machine for debugging.

Assuming LPDDR, please refer the following section

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/09_02_01_06/exports/docs/api_guide_am62x/DRIVERS_DDR_PAGE.html#autotoc_md540

Regards,

Prashant

OK!  Thanks!  Any feedback on the first two questions?  Please disregard the generic "deconfig" file question.

Hi Jim,

Jim Meyer said:

Any feedback on the first two questions?

Could you please reiterate these queries as I do not see if I left any unanswered.

Prashant,

     Yes, will the absence of OSPI in our design affect the booting process (we don't have that on our custom board)?

Prashant,

Can you detail exactly how I should do the following:

Ofcourse, without any modifications to the SBL_UART_UNIFLASH in am62x-sk-lp folder, the procedure is most likely to fail. You would have to integrate the custom DDR configurations in the SBL_UART_UNIFLASH_STAGE1 and custom NAND flash configurations in SBL_UART_UNIFLASH_STAGE2.

And can we do this without OSPI Flash in our custom design?

Jim Meyer said:

Yes, will the absence of OSPI in our design affect the booting process (we don't have that on our custom board)?

Not at all. You can have a NAND flash on your custom board. You would just need to get it working with the MCU+ SDK.

Jim Meyer said:

Can you detail exactly how I should do the following:

Have you already integrated the DDR configurations in the `sbl_uart_uniflash_stage1` of `am62x-sk-lp`? If you have, could you please share the UART flashing logs?

Prashant,

OK!  Here's the output with our custom DDR

The logs suggest that the DDR is not yet correctly integrated.

You would need to open the Sysconfig of `sbl_uart_uniflash_stage1` from `am62x-sk-lp` and modify the path to the config file of your custom DDR.

Prashant,

     The NAND Flash was updated and we get this far, however, after trying to update the null sysconfig file I'm not able to build the project.  It indicates there is insufficient memory.  Here's the output with the second phase with the updated Nand Flash info:

I've attached the sysconfig we have for sbl_null project:

/**
 * These arguments were used when this file was generated. They will be automatically applied on subsequent loads
 * via the GUI or CLI. Run CLI with '--help' for additional information on how to override these arguments.
 * @cliArgs --device "AM62x" --package "AMC" --part "Default" --context "r5fss0-0" --product "MCU_PLUS_SDK_AM62x@09.02.01"
 * @versions {"tool":"1.20.0+3587"}
 */

/**
 * Import the modules used in this configuration.
 */
const flash       = scripting.addModule("/board/flash/flash", {}, false);
const flash1      = flash.addInstance();
const bootloader  = scripting.addModule("/drivers/bootloader/bootloader", {}, false);
const bootloader1 = bootloader.addInstance();
const bootloader2 = bootloader.addInstance();
const ddr         = scripting.addModule("/drivers/ddr/ddr", {}, false);
const ddr1        = ddr.addInstance();
const gtc         = scripting.addModule("/drivers/gtc/gtc");
const clock       = scripting.addModule("/kernel/dpl/clock");
const debug_log   = scripting.addModule("/kernel/dpl/debug_log");
const mpu_armv7   = scripting.addModule("/kernel/dpl/mpu_armv7", {}, false);
const mpu_armv71  = mpu_armv7.addInstance();
const mpu_armv72  = mpu_armv7.addInstance();
const mpu_armv73  = mpu_armv7.addInstance();
const mpu_armv74  = mpu_armv7.addInstance();
const mpu_armv75  = mpu_armv7.addInstance();
const mpu_armv76  = mpu_armv7.addInstance();
const mpu_armv77  = mpu_armv7.addInstance();
const mpu_armv78  = mpu_armv7.addInstance();
const mpu_armv79  = mpu_armv7.addInstance();
const mpu_armv710 = mpu_armv7.addInstance();

/**
 * Write custom configuration values to the imported modules.
 */
bootloader1.$name          = "CONFIG_BOOTLOADER_FLASH_DM";
bootloader1.appImageOffset = "0xA00000";

flash1.$name                                                    = "CONFIG_FLASH0";
bootloader1.flashDriver                                         = flash1;
flash1.flashTopology                                            = "parallelFlash";
flash1.parallelFlashDriver.$name                                = "board_flash_parallelFlash_parallelflash0";
flash1.parallelFlashDriver.device                               = "CUSTOM_FLASH";
flash1.parallelFlashDriver.flashSize                            = 31268536320;
flash1.parallelFlashDriver.fname                                = "IS22TF32G_JCLA2";
flash1.parallelFlashDriver.flashPageSize                        = 16384;
flash1.parallelFlashDriver.flashSpareAreaSize                   = 1280;
flash1.parallelFlashDriver.flashManfId                          = "0x9D";
flash1.parallelFlashDriver.flashDeviceId                        = "0x00D7";
flash1.parallelFlashDriver.flashBlockSize                       = 4194304;
flash1.parallelFlashDriver.peripheralDriver.$name               = "CONFIG_GPMC0";
flash1.parallelFlashDriver.peripheralDriver.GPMC.OEn_REn.$used  = false;
flash1.parallelFlashDriver.peripheralDriver.GPMC.ADVn_ALE.$used = false;
flash1.parallelFlashDriver.peripheralDriver.GPMC.WEn.$used      = false;
flash1.parallelFlashDriver.peripheralDriver.GPMC.BE0n_CLE.$used = false;
flash1.parallelFlashDriver.peripheralDriver.GPMC.CSn0.$used     = false;
flash1.parallelFlashDriver.peripheralDriver.GPMC.WAIT0.$used    = false;

bootloader2.$name     = "CONFIG_BOOTLOADER0";
bootloader2.bootMedia = "MEM";

ddr1.$name = "CONFIG_DDR0";

const udma                                             = scripting.addModule("/drivers/udma/udma", {}, false);
const udma1                                            = udma.addInstance({}, false);
udma1.$name                                            = "CONFIG_UDMA0";
flash1.parallelFlashDriver.peripheralDriver.udmaDriver = udma1;

const udma_blkcopy_channel                                     = scripting.addModule("/drivers/udma/udma_blkcopy_channel", {}, false);
const udma_blkcopy_channel1                                    = udma_blkcopy_channel.addInstance({}, false);
udma_blkcopy_channel1.$name                                    = "CONFIG_UDMA_BLKCOPY_CH0";
flash1.parallelFlashDriver.peripheralDriver.udmaBlkCopyChannel = udma_blkcopy_channel1;

debug_log.enableLogZoneInfo                  = true;
debug_log.enableCssLog                       = false;
debug_log.enableUartLog                      = true;
debug_log.uartLog.$name                      = "CONFIG_UART0";
debug_log.uartLog.useWakeupDomainPeripherals = false;
debug_log.uartLog.intrEnable                 = "DISABLE";

mpu_armv71.$name             = "CONFIG_MPU_REGION0";
mpu_armv71.accessPermissions = "Supervisor RD+WR, User RD";
mpu_armv71.attributes        = "NonCached";
mpu_armv71.allowExecute      = false;

mpu_armv72.$name             = "CONFIG_MPU_REGION1";
mpu_armv72.size              = 7;
mpu_armv72.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv73.$name             = "CONFIG_MPU_REGION2";
mpu_armv73.baseAddr          = 0x41C00000;
mpu_armv73.size              = 19;
mpu_armv73.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv74.$name             = "CONFIG_MPU_REGION3";
mpu_armv74.size              = 16;
mpu_armv74.baseAddr          = 0x70000000;
mpu_armv74.accessPermissions = "Supervisor RD+WR, User RD";

mpu_armv75.$name    = "CONFIG_MPU_REGION4";
mpu_armv75.size     = 31;
mpu_armv75.baseAddr = 0x80000000;

mpu_armv76.$name      = "CONFIG_MPU_REGION5";
mpu_armv76.size       = 15;
mpu_armv76.baseAddr   = 0x41010000;
mpu_armv76.attributes = "NonCached";

mpu_armv77.$name      = "CONFIG_MPU_REGION6";
mpu_armv77.size       = 15;
mpu_armv77.attributes = "NonCached";

mpu_armv78.$name        = "CONFIG_MPU_REGION7";
mpu_armv78.baseAddr     = 0xFC40000;
mpu_armv78.size         = 8;
mpu_armv78.attributes   = "Device";
mpu_armv78.allowExecute = false;

mpu_armv79.$name    = "CONFIG_MPU_REGION8";
mpu_armv79.size     = 18;
mpu_armv79.baseAddr = 0x43C00000;

mpu_armv710.$name        = "CONFIG_MPU_REGION9";
mpu_armv710.baseAddr     = 0x60000000;
mpu_armv710.size         = 7;
mpu_armv710.attributes   = "Device";
mpu_armv710.allowExecute = false;

/**
 * Pinmux solution for unlocked pins/peripherals. This ensures that minor changes to the automatic solver in a future
 * version of the tool will not impact the pinmux you originally saw.  These lines can be completely deleted in order to
 * re-solve from scratch.
 */
flash1.parallelFlashDriver.peripheralDriver.GPMC.$suggestSolution     = "GPMC0";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD0.$suggestSolution = "GPMC0_AD0";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD1.$suggestSolution = "GPMC0_AD1";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD2.$suggestSolution = "GPMC0_AD2";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD3.$suggestSolution = "GPMC0_AD3";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD4.$suggestSolution = "GPMC0_AD4";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD5.$suggestSolution = "GPMC0_AD5";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD6.$suggestSolution = "GPMC0_AD6";
flash1.parallelFlashDriver.peripheralDriver.GPMC.AD7.$suggestSolution = "GPMC0_AD7";
debug_log.uartLog.UART.$suggestSolution                               = "USART0";
debug_log.uartLog.UART.RXD.$suggestSolution                           = "UART0_RXD";
debug_log.uartLog.UART.TXD.$suggestSolution                           = "UART0_TXD";

Prashant,

     As a parallel activity (since we have no OSPI Flash), I tired running the "sbl_emmc_linux_stage1" example and I am able to load it onto r5 but it "hangs" almost immediately here:

I configured the debugger to "am62" which has no ddr.gel file.  Should we point to our customized ddr.gel file (from TI's DDR tool)?  It is formatted differently.

Prashant,

     If I run the "sbl_uart_uniflash_state1", it "hangs" in the same place (we've included our custom DDR in this sysconfig):

Hi Jim,

The latest flashing logs suggest that the DDR is correctly integrated in the `sbl_uart_uniflash_stage1`. However, the flashing still fails because of the incompatible NAND flash configurations in the `sbl_uart_uniflash_stage2`.

So, you would need to open the Sysconfig of `sbl_uart_uniflash_stage2` and do necessary changes in the NAND flash configurations. Once the configurations are correct, you should see flashing procedure finish successfully.

About the `sbl_emmc_linux_stage1` and `sbl_uart_uniflash_stage1` getting stuck, it is expected. These are SBLs which cannot be run directly from the CCS. These are booted over interfaces like UART, eMMC, NAND, etc. Once booted, the SBLs initializes the SoC among other things. Afterwards, you could use CCS to run general applications on different cores.

Regards,

Prashant

Prashant,

     OK!  It's good to hear that our DDR seems correct now.  To clarify, what we would like to do is to flash the small boot code that is flashed to the OSPI NAND on the "lp" development board to the eMMC parallel flash on or custom board.  It seems the eMMC is defined in the bootloader section (not the flash section).  Can you offer any guidance?  

Prashant,

     I went to the TI repository for the defconfig files and downloaded the attached files.  These are the am62x-sk-lp files correct?am62x_lpsk_r5_defconfig_h=09.02.00.010.pdfam62x_lpsk_a53_defconfig_h=09.02.00.010.pdf

Is there a tool available to generate these?

Prashant,

                Running the “sbl_uart_uniflash_stage1” example on r5 does not actually configure our DDR, correct?  I shouldn’t be surprised if I can’t write to RAM (0x80000000 – 0x100000000)?

                Also, is there any way I could flash the boot code for the OSPI Nand (flashed with the uart uniflash) to an SD Card and then boot from there?

Hi Jim,

Jim Meyer said:

Also, is there any way I could flash the boot code for the OSPI Nand (flashed with the uart uniflash) to an SD Card and then boot from there?

There is a different bootloader for SD card. It is named SBL_SD as described here

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/09_02_01_06/exports/docs/api_guide_am62x/EXAMPLES_DRIVERS_SBL_SD.html

On another note, I am sensing here that you want to see your board boot as soon as possible. If that's the case, I would highly recommend to once try out the SBL_UART bootloader as described here

https://software-dl.ti.com/mcu-plus-sdk/esd/AM62X/09_02_01_06/exports/docs/api_guide_am62x/EXAMPLES_DRIVERS_SBL_UART.html

This SBL_UART bootloader boots all the images over UART only and just requires working DDR. It's great as a starting point for custom boards.

Regards,

Prashant

Prashant,

For the SBL_UART I got the following:

Jim,

You would need to modify the DDR config file path in the Sysconfig of SBL_UART just like you did for Uniflash Stage1 previously.

Once done, you should see SUCCESS for all three commands. You should keep all the three ports except COM9 here connected so that you could see the boot logs from DM and MCU image.

Prashant,

     Here's the config file with the modification for the updated DDR in the sbl uart project:

Here's the UART output:

Prashant,

     One other thing...  I don't think I have the SBL_SD example in my SDK.  --Oh, I found it in "mcu_plus_sdk_am62x_09_02_01_06"

Prashant,

     One other thing...  I don't think I have the SBL_SD example in my SDK.  --Oh, I found it in "mcu_plus_sdk_am62x_09_02_01_06"

Prashant,

     How do I set up the SD Card for the SBL_SD.  I have the balenaEtcher tool.

Prashant,

     In the SBL_SD, the sysconfig file lists serial flash (OSPI?) so this may not work for us.

Prashant,

                So with the sbl uart bootloader, we set up a server in the SOC memory to flash the receive the application images that are the latter part of the script.

                What would the possible causes of the flash fail be?

Hi Jim,

Yes, the SBL_SD support for AM62x was added in MCU+ SDK v9.2.1.6 only.

Jim Meyer said:

How do I set up the SD Card for the SBL_SD.  I have the balenaEtcher tool.

The ROM only supports booting from a FAT partition for SD card boot. So, the simplest way is to flash one WIC image from PSDK to SD card using Balena Etcher. We do this just for partitioning the SD card. Then, in the first partition (FAT)

• Replace the existing `tiboot3.bin` with the `tiboot3.bin` from the SBL_SD folder.
• Take hsfs appimages of, let's say, hello world example of M4F, R5F, A53. Rename them to `app`, `dm`, `app_a53` respectively and copy to the partition. This is described on the SBL_SD documentation page as well.

Jim Meyer said:

What would the possible causes of the flash fail be?

It looks like SBL_UART got stuck into some error after receiving the M4F appimage.

I guess you can try the SBL_SD for now.

Regards,

Prashant

Prashant,

                OK!  According to the script for the sbl uart example, a server is uploaded and used to load the other two examples listed in the script.  Can you detail the process for me? 

Prashant,

I made those changes you described in above using an SD Card with the "tisdk-default-image-am62xx-lp-evm.wic.xz" image on it.  I don't see any output on the UART0 port (that all your examples use).  Here's the boot folder on the SD Card after my additions.  I couldn't find a "Hellow World" example for the A53 so I didn't include it.

Jim Meyer said:

According to the script for the sbl uart example, a server is uploaded and used to load the other two examples listed in the script.  Can you detail the process for me? 

You are correct. The SBL_UART image itself is booted by ROM. Once booted, it acts as a server listening for the appimages over UART. It receives the appimages, stores in DDR, parses, and finally load them onto the respective cores.

About SBL_SD, I checked and it seems the tiboot3.bin image generated is a copy of the GP tiimage instead of HSFS one.

Could you please take the `sbl_sd.*.hs_fs.tiimage, rename to tiboot3.bin and copy to SD card? If it still does not boot, are you able to boot the original tiboot3.bin from the WIC image?

Prashanr,

OK!  Rename "sbl_sd.Release.hs_fs.tiimage" (that was just generated) to tiboot3.bin?  UBoot starts with the original WIC image.

Jim Meyer said:

Rename "sbl_sd.Release.hs_fs.tiimage" (that was just generated) to tiboot3.bin? 

Yes, that is correct. Rename to tiboot3.bin and copy to the SD card.

No output on the UART with those changes.

Jim Meyer said:

No output on the UART with those changes.

Do you have the means to establish JTAG connection to your board?

If you do, could you please connect to the R5F core and note down the address at which the core is suspended at? If the address is somewhat 0x41xxxxxx then the execution control in still in ROM stage otherwise if you see 0x43xxxxxx then the ROM could boot the image successfully but it got stuck somewhere even before dumping any logs on the UART.

Prashant,

OK!  We're getting another emulator tomorrow so I may not be able to check that today.  There's two of us working on this and we're sharing an emulator until tomorrow.  I'll check it out when I can.

Is there a way to check the correctness of our DDR file.  From your explanation of the server (above), it's possible we need to tweak that.

Jim Meyer said:

Is there a way to check the correctness of our DDR file.  From your explanation of the server (above), it's possible we need to tweak that.

There is CCS GEL files based DDR testing that will require JTAG connection. But, this is not at all straightforward for HS devices. If you want, you could go through the following thread that discusses this

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1303533/sk-am62b-am62b-evm-jtag-testing-is-mul-function

Coming to booting your board, let's resort to one final method: Booting SBL NULL directly over UART using Teraterm in UART Bootmode.

I happen to have the recording of this. If everything goes right, you should at least see the initial logs.

Prashant,

     Great!  I downloaded TeraTerm and gave it a shot!  Here's the output:

So far with my builds, I've only set up the new *.ddr*.h file:

I'm not sure where the *.gel file comes in.

Prashant,

It looks like it's including OSPI and we do not have OSPI

Jim,

The OSPI relates to the SPI controller we have on the SoC to communicate with the flash memories. This will be same for NOR/NAND. If you see the Flash module in Sysconfig of SBL NULL from am62x-sk-lp, it is for NAND flash only we have on the TI EVMs

The SBL NULL probably fails because of the incompatible NAND configurations. You would need to modify these configurations according to your NAND flash part to move forward in the boot flow.

Regards,

Prashant

Prashant,

     Our custom board does not have OSPI.  The hardware design was done before I arrived on the project.

Prashant,

     Are the pre-built folder *tiimage" files generated from the examples? 

Prashant,

Can I use this method to send the two images in the config file for sbl_uart?  I get the following output.  What is meant by "Failed to authenticate Image"

Hi Jim,

Jim Meyer said:

Our custom board does not have OSPI.  The hardware design was done before I arrived on the project.

That's okay. What I meant was the SBL NULL from lp folder uses the NAND flash only.

Jim Meyer said:

Are the pre-built folder *tiimage" files generated from the examples? 

Yes, indeed.

Jim Meyer said:

Can I use this method to send the two images in the config file for sbl_uart? 

I think you can. Send them all one by one in their order. Did you get the "Failed to authenticate image" when you did so?