This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

PROCESSOR-SDK-AM64X: Custom AM6442-HS-FS Board, OSPI Boot mode doesn't boot u-boot

Part Number: PROCESSOR-SDK-AM64X
Other Parts Discussed in Thread: SYSCONFIG

MCU SDK: mcu_plus_sdk_am64x_08_05_00_24
Linux SDK: ti-processor-sdk-linux-rt-am64xx-evm-08.06.00.42

Ospi Disk Layout

0x0            - sbl_ospi_linux.tiimage-hs_FS
0x100000  - linux.appimage-hs_FS (built with mcu_plus_sdk_am64x_08_05_00_24/linuxAppimageGen & ti-processor-sdk-linux-rt-am64xx-evm-08.06.00.42 prebuilt-images)
0x300000  - u-boot.img

project sbl_ospi_linux.tiimage-hs_FS:

- I removed code that makes transition to eMMC mode from sbl_ospi_linux project.

- I changed Bootloader offsets with sysconfig which flash_mcu: 0x80000 flash_linux: 0x100000

I am unable to boot my custom board with above configuration

My intent is booting linux.appimage_hs-FS and u-boot from OSPI

But it stuck after SBL

How can I find the problem? (It works with non-custom AM64 GPEVM SR1 with SDK version 08.04)

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
DMSC Firmware Version 8.5.3--v08.05.03 (Chill Capybar
DMSC Firmware revision 0x8
DMSC ABI revision 3.1
[BOOTLOADER_PROFILE] Boot Media : undefined
[BOOTLOADER_PROFILE] Boot Image Size : 0 KB
[BOOTLOADER_PROFILE] Cores present : m4f0-0
[BOOTLOADER PROFILE] System_init : 26843us
[BOOTLOADER PROFILE] Drivers_open : 764668us
[BOOTLOADER PROFILE] Board_driversOpen : 0us
[BOOTLOADER PROFILE] App_loadImages : 487016us
[BOOTLOADER_PROFILE] SBL Total Time Taken : 1438589us
Image loading done, switching to application ...
Starting linux and RTOS/Baremetal applications
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello Onur,

    Ospi Disk Layout

    Here, which application .appimage you have flashed at the default offset of 0x80000?


    I removed code that makes transition to eMMC mode from sbl_ospi_linux project.

    Do you face the problem if you do not remove this code?

    Regads,

    Prashant

  • >> Here, which application .appimage you have flashed at the default offset of 0x80000?

    I tried a lot of example app but situation is same (ipc_rpmsg_echo, hello_world (without its a53 parts) uart-echo etc.)

    >> I removed code that makes transition to eMMC mode from sbl_ospi_linux project.

    Yes it doesn't matter if I remove or not. I am facing same problem evey time.

    After Last log message, U-boot spl is not working.

  • Hi Onur,

    I tried a lot of example app but situation is same (ipc_rpmsg_echo, hello_world (without its a53 parts) uart-echo etc.)

    Even these appimages are not booting? That is, you do not see any logs from these applications?

  • These appimages work.

    But the problem I am talking is about u-boot.

    The linux.appimage.hs_FS is not booting u-boot-spl

    I tried both signed (bl31&bl32&u-boot-spl.bin) and unsigned one.

  • Onur,

    Could you please once share the exact changes you have made in the SBL_OSPI_LINUX.

  • 0246.main.c
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /*
    * Copyright (C) 2018-2023 Texas Instruments Incorporated
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the
    * distribution.
    *
    * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    default_sbl_ospi_linux_hs.cfg.txt
    Fullscreen
    1
    2
    3
    4
    5
    --flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.hs.tiimage
    --operation=flash-phy-tuning-data
    --file=my_sbl_ospi_linux.release.hs.tiimage --operation=flash --flash-offset=0x0
    --file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am64x-evm/system_freertos/ipc_rpmsg_echo_linux_system.release.appimage.hs --operation=flash --flash-offset=0x80000
    --file=./linux.appimage.hs --operation=flash --flash-offset=0x100000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • example.syscfg.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    /**
    * 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 "AM64x_beta" --package "ALV" --part "Default" --context "r5fss0-0" --product "MCU_PLUS_SDK@07.03.01"
    * @versions {"tool":"1.10.0+2163"}
    */
    /**
    * 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 debug_log = scripting.addModule("/kernel/dpl/debug_log");
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 08.04

    08.05

    08.06

    All versions are same `linux.appimage.hs_FS` doesn't boot u-boot-spl

  • Hi Onur,

    Could you please share the binaries you are using to build the linux.appimage. I will test it once on my side & get back to you.

    Thanks!

  • Hi Onur,

    I have tested the shared Linux Appimage and it boots fine on my TI AM64x HS-FS EVM board in all the below cases.

    • Using the prebuilt images & default offset of 0x300000
    • Using offset of 0x100000 for linux appimage
    • Integrating your changes for SBL OSPI LINUX

    I would like to know if you have a TI board with you on which you could run the same binaries. And with your custom board, you have to debug the SBL to know where exactly it is failing. My guess is the SBL execution flow is most probably is failing in the function call Bootloader_verifyMulticoreImage which is reached through App_loadLinuxImages -> Bootloader_parseAndLoadLinuxAppImage -> Bootloader_verifyMulticoreImage.

    If you could debug the SBL once, it would greatly help.

    Regards,

    Prashant

  • My TI Board is SR1 TMDS64GPEVM and custom board SR2 HS-FS

    Unfortunately I don't have opportunity to test with default TI board.

    I Debugged SBL but I am unable to continue after below code because there isn't R5-spl (We boot from ospi there isn't sdcard)

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    int32_t Bootloader_runSelfCpuWithLinux(void)
    {
    int32_t status = SystemP_SUCCESS;
    DebugP_logInfo("All done, reseting self ...\r\n\n");
    status = Bootloader_socCpuResetReleaseSelf();
    /* control will not reach here */
    return status;
    }
    int32_t Bootloader_socCpuResetReleaseSelf(void)
    {
    int32_t status = SystemP_SUCCESS;
    uint32_t sciclientCpuProcIdCore0, sciclientCpuDevIdCore0;
    uint32_t sciclientCpuProcIdCore1 = BOOTLOADER_INVALID_ID, sciclientCpuDevIdCore1 = BOOTLOADER_INVALID_ID;
    uint32_t bDualSelfR5F = FALSE;
    sciclientCpuProcIdCore0 = Bootloader_socGetSciclientCpuProcId(CSL_CORE_ID_R5FSS0_0);
    sciclientCpuDevIdCore0 = Bootloader_socGetSciclientCpuDevId(CSL_CORE_ID_R5FSS0_0);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Interestingly, altough my custom board is HS-FS, when I build linux.appimage with the files (bl31 bl32 and u-boot-spl.bin) inside ti-processor-sdk-linux-am64xx-evm-08.00.00.21-Linux-x86-Install.bin It works! But it's not working with 08.06

    I am stuck and don't know what to try.

  • Onur,

    Interestingly, altough my custom board is HS-FS, when I build linux.appimage with the files (bl31 bl32 and u-boot-spl.bin) inside ti-processor-sdk-linux-am64xx-evm-08.00.00.21-Linux-x86-Install.bin It works!

    This is interesting Thinking

    About debugging, you did not need to go this far. The function App_loadLinuxImages that I want you to debug comes early in the execution flow. You may refer to the below screen recording.

    Here, if you see the status becomes 0 after Bootloader_verifyMulticoreImage function call which means the call was successful. I did the debugging with your shared Linux Appimage. Please let me know what do you see on your end?

    Regards,

    Prashant

  • Okay let me try this and I will write results very soon.

  • Hi Prashant,

    I debugged sbl as you suggested.

    The call to bootloader_verifyMulticoreImage was successful and the status variable returned 0.

    Additionally I kept debugging sbl until the end.

    Up to this point, I have never encountered any errors and the status has always returned successful.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    bootloader_soc.c - 959th line:
    ...
    /* after this point you cannot single step in CCS */
    if(status==SystemP_SUCCESS)
    {
    status = Sciclient_pmSetModuleRst_flags(sciclientCpuDevIdCore0, 1, 0, SystemP_WAIT_FOREVER);
    }
    ...
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    But I still get the following logs when I boot the board in ospi_bootmode:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    Image loading done, switching to application ...
    Starting linux RTOS/Baremetal applications
    NOTICE: BL31: v2.8(release):v2.8-226-g2fcd408663-dirty
    NOTICE: BL31: 13:4:23 ,Feb 27 2023
    20.0 (gcc version 9.2.1 20191025 (GNU Toolchain
    for the A-profile Architecture 9.2-2019.12 (arm-9.20)))
    #1 Mar Feb 27 13:47:09 This OP-TEE configuration
    might be insecure!
    I/TC: WARNING: Pleocs.io/en/latest/architecture/porting-guidelines.html
    I/TC: Primary CPU initializing
    I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    I/TC: HUK Initalized
    I/TC: Activated SA2UL device
    I/TC: Enabled firewalls for SA2UL TRNG device
    I/TC: TRNG initalized
    I/TC: Drivers initalized
    I/TC: Primary CPU
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Regards,

  • Hi Onur,

    Are you making sure that you have the boot mode switch set to OSPI boot mode & doing Power-On-Reset everytime?

    Regards,

    Prashant

  • Yes, I'm sure the board is in OSPI bootmode.

    My bootmode switch combination:

    The source of the problem may be u-boot-spl.bin file.

    Because as I mentioned before, u-boot-spl.bin compiled with ti-processor-sdk-linux-am64xx-evm-08.00.00.21 worked.

    There are differences in the am64x_evm_a53_defconfig files between the two sdk(06 and 00).

    Regards,

  • Hi Onur,

    The source of the problem may be u-boot-spl.bin file.

    This is what I also suspect now. The prebuilt SPL may not be suited to your custom board.

    To confirm this, could you try booting the prebuilt images (tiboot3.bin, tispl.bin & u-boot.img) from the PSDK you used to get the bl31, bl32 & u-bool-spl. You can flash these files at the offsets given below in OSPI.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    +-------------+----------+
    | tiboot3.bin | 0x0 |
    +-------------+----------+
    | tispl.bin | 0x100000 |
    +-------------+----------+
    | u-boot.img | 0x300000 |
    +-------------+----------+
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Prashant

  • I tested it.

    This way spl works !!!

    tispl.bin works but linuxappiamge.hs_fs does not.

    What could be the problem with my sbl file?

    So maybe there is a signing mismatch(between sbl and spl).

    Regards,

  • Hi Onur,

    What could be the problem with my sbl file?

    I believe you are getting logs from ATF (bl31) & OPTEE (bl32) so there should not be any problem with SBL. Since if SBL had some problem with the Linux Appimage, those logs from ATF & OPTEE shouldn't have come also. The problem seems to be with A53 SPL somehow.

    I have one more idea that could be tested and should work.

    • Build the U-Boot in PSDK using the below command run from the root directory of PSDK installation

      Fullscreen
      1
      make u-boot sysfw-image
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    • This will create the tispl.bin at the location board-support/u-boot_build/a53/tispl.bin. Test this tispl.bin. If it boots then we can take the A53 SPL that is packaged in tispl.bin and use it to build Linux Appimage. Afterwards, the Linux Appimage should boot fine since it has the same A53 SPL that is inside tispl.bin. The A53 SPL that is packaged in tispl.bin is created at board-support/u-boot_build/a53/spl/u-boot-spl.bin.

    Regards,

    Prashant

  • Hi Prashant,

    I did some tests according to your instructions:

    1- It worked as follows:
    tiboot3.bin(from prebuilt-images) -> 0x0
    tispl.bin(from u-boot_build) -> 0x100000
    u-boot.img(from prebuilt-images) -> 0x300000

    2- It worked as follows:
    tiboot3.bin(from prebuilt-images) -> 0x0
    linuxappimage.hs_fs(compiled from prebuilt-images) -> 0x100000
    u-boot.img(from prebuilt-images) -> 0x300000

    3- It did not work as follows:
    sbl_ospi_linux.Debug.hs_fs.tiimage -> 0x0
    ipc_rpmsg_echo_linux_system.debug.appimage.hs_fs -> 0x80000
    tispl.bin(from u-boot_build) -> 0x100000 (doesn't work if it's an linuxappimage.hs_fs)
    u-boot.img(from prebuilt-images) -> 0x300000

    Regards,

  • Hi Onur,

    I am not understanding clearly what worked for you.

    1/ This is expected.

    2/ The tiboot3.bin from PSDK can't boot Linux Appimage. In this testing, what images were exactly flashed? Is the Linux Apppimage generated using the u-boot-spl.bin from u-boot_build worked for you?

    3/ Here, the SBL from MCU+ SDK can't boot tispl.bin.

  • 2/ I have tested this again, and by working I mean that I can see that spl is working.
    Here Case-2 logs in OSPI bootmode:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    U-Boot SPL 2021.01-g2ee8efd654 (Feb 27 2023 - 13:50:10 +0000)
    EEPROM not available at 80, trying to read at 81
    Reading on-board EEPROM at 0x51 failed 1
    Reseting on cold boot to work around ErrataID::2331
    reseting ...
    U-Boot SPL 2021.01-g2ee8efd654 (Feb 27 2023 - 13:50:10 +0000)
    EEPROM not available at 80, trying to read at 81
    Reading on-board EEPROM at 0x51 failed 1
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill cappybar')
    SPL inital stack usage: 13424 bytes
    Trying to boot from all boot devices
    ### ERROR ### Please RESET the board ###
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    3/ As I explained before, my main goal is to run linuxappimage.hs_fs with sbl.

  • Hi Onur,

    2- It worked as follows:
    tiboot3.bin(from prebuilt-images) -> 0x0
    linuxappimage.hs_fs(compiled from prebuilt-images) -> 0x100000
    u-boot.img(from prebuilt-images) -> 0x300000

    In the 2nd test case, I assume this is tispl.bin instead of linux.appimage.hs_fs. Is it correct?

    Also, you have clicked the "This Resolved My Issue" button. I assume this was by mistake and you are still looking for a solution?

    Thanks!

  • I clicked mistakenly, there isn't a way to undo it.

    ..

    The problem still exists. I am looking a solution.

    My board hangs after printing ATF&Optee&SYSFW messages.

    ```

    Image loading done, switching to application ...
    Starting linux RTOS/Baremetal applications

    NOTICE:  BL31: v2.8(release):v2.8-226-g2fcd408663-dirty
    NOTICE:  BL31: 13:4:23 ,Feb 27 2023
    20.0 (gcc version 9.2.1 20191025 (GNU Toolchain
    for the A-profile Architecture 9.2-2019.12 (arm-9.20)))
    #1 Mar Feb 27 13:47:09 This OP-TEE configuration might be insecure!
    I/TC: WARNING: Pleocs.io/en/latest/architecture/porting-guidelines.html
    I/TC: Primary CPU initializing
    I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.7--v08.04.07 (Jolly Jellyfi')
    I/TC: HUK Initalized
    I/TC: Activated SA2UL device
    I/TC: Enabled firewalls for SA2UL TRNG device
    I/TC: TRNG initalized
    I/TC: Drivers initalized
    I/TC: Primary CPU

    ```

  • Hi Prashant,

    I solved part of the problem.

    I mentioned at the beginning that I have a custom board.

    There isn't TCA9554APWR(Board presence device circuit ) integrated in my custom board.

    I found that part of the u-boot code was hanging because of this integrated.

    The code part I mentioned is in u-boot-2021.01+gitAUTOINC+2ee8efd654-g2ee8efd654/board/ti/am64x/evm.c.

    Deleting the dm_gpio_get_valu() function line(78) from the "evm.c" file below temporarily solves the problem:


    After removing line 78 and the gpio related lines from the code, I recompiled u-boot.

    I created linuxappimage.hs_fs in with recompiled u-boot.

    I created linuxappimage.hs_fs and spl booted without any problem. 

    Apart from the above steps, I found another solution.

    I compile the U-boot by adding CONFIG_OF_EMBED=y to am64x_evm_a53_defconfig.

    I can boot spl without changing anything in u-boot's source code.

    With the linuxappimage.hs_fs file I created from this u-boot, spl boots without any problem.

    How does CONFIG_OF_EMBED make a difference?

    What do you think about the dm_gpio_get_value() part?

    Regards,


  • By the way, could you please undo this post's "This resolved my issue" checkbox?

    We didn't even know this component (TCA9554APWR) can cause error like this. There is neither an error message during spl boot nor a mention about TCA9554APWR in any manual&documentation.

  • Hi Onur,

    For the Linux SBLs boot flow, the final u-boot-spl.bin image is created by taking the U-Boot SPL binary without DTBs & concatenating it with the FIT image containing multiple DTBs. This FIT image contains the DTBs for both SK & EVM board. Then, the right DTB is selected at the runtime by calling the board_fit_config_name_match function. You can read more at the below link

    https://u-boot.readthedocs.io/en/latest/develop/devicetree/control.html#using-several-dtbs-in-the-spl-config-spl-multi-dtb

    However, if CONFIG_OF_EMBED is defined, then the DTB is embedded in the U-Boot SPL binary itself. This ensures the routine, which does the DTB selection at runtime, is not called. That's why, you are not facing issues on enabling CONFIG_OF_EMBED. You can find more info at the below links

    https://u-boot.readthedocs.io/en/latest/develop/devicetree/control.html#configuration

    https://patchwork.ozlabs.org/project/uboot/patch/1319519734-28704-3-git-send-email-sjg@chromium.org/

    Regards,

    Prashant