• State Resolved
  • Locked Locked
  • Replies 18 replies
  • Subscribers 99 subscribers
  • Views 2353 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM6442: SBL Boot with AppImage and Linux RootFs

Ben Schroeder
Prodigy 250 points

Part Number: AM6442
Other Parts Discussed in Thread: UNIFLASH

We are using the SBL library to boot Linux on A53 core and RTOS/NORTOS application on R5 (from eMMC)

Using the guide here:
https://dev.ti.com/tirex/content/mcu_plus_sdk_am64x_08_03_00_18/docs/api_guide_am64x/BOOTFLOW_GUIDE.html

We have flashed the SBL to eMMC (offset 0 if I recall correctly)
We have successfully booted firmware on R5 core. (R5 firmwares have a hardcoded offset in eMMC)
We have also created the Linux AppImage with the relevant addresses, and flashed it to offset 0xA00000 (as specified in the guide section SBL EMMC LINUX)

The Linux AppImage binaries (u-boot) also seem to load successfully. 

The issue is this:

We see the u-boot from the Linux AppImage loading, however it cannot boot Linux.
This is because we have not written the linux kernel, dtb, rootfs, or other related files to the eMMC.

I have looked over the guide, and could not find the details of where I am supposed to write these files.

Do we need to create a partition table? GPT or MBR?
Where do we place the Linux Files to boot correctly from eMMC using the SBL?
If we need partitions - is there a tool to create a partitioned image using our SBL, the R5 firmwares, and the Linux AppImage and RootFS files?

Thank you,
Ben S.

  • 0
    Prodigy 250 points

    Hi Prashant,

    From the guide, I understand that to boot from eMMC using SBL, and to reach Linux, i will need to make an ext4 partition in eMMC.
    And I will need to copy the RootFs to the ext4 partition in eMMC (which includes Kernel and DTB in /boot)

    I have a follow up question regarding SBL and Yocto.
    I have our SBL image: AM64x_SBL.tiimage

    I would like to use this custom SBL image when building a system image for am64x with Yocto.
    What is the correct way to build the TI AM64x image (Using Yocto and Bitbake), but use our custom SBL in the final image.

    So ultimately we would want a .wic image generated by yocto, which includes our SBL.
    So we could flash this image to eMMC and boot from it.

    Thank you,
    Ben S.

  • 0 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    Please allow me time to ask Yocto expert for any points on this requirement.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 250 points

    Hi Prashant,

    I need to clarify my question.
    I have still not been able to boot linux from SBL eMMC.

    I want to clarify the question and give more information:

    1. We are using the SBL library to boot Linux on A53 core and RTOS/NORTOS application on R5 (from eMMC)
    2. We have flashed the SBL to eMMC
    3. We have flashed LinuxApp image to eMMC

    python.exe uart_uniflash.py -p com5 --cfg=C:\ti\default_sbl_emmc_linux.cfg

    The config file i used is:

    # First point to sbl_uart_uniflash binary, which function's as a server to flash one or more files to eMMC
--flash-writer=sbl_prebuilt/am64x-evm/sbl_uart_uniflash.release.tiimage

# Now send one or more files to flash or flashverify as needed. The order of sending files does not matter

# When sending bootloader make sure to flash at offset 0x0. ROM expects bootloader at offset 0x0 of eMMC
--file=../../../AM64x_SBL.tiimage --operation=flash-emmc --flash-offset=0x0

# When sending application image, make sure to flash at offset 0x800000 (default) or to whatever offset your bootloader is configured for
# --file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am64x-evm/system_freertos/ipc_rpmsg_echo_linux_system.release.appimage --operation=flash-emmc --flash-offset=0x800000

# Linux image is flashed at 0xA00000 or to whatever offset your bootloader is configured for
--file=../../../linux.appimage --operation=flash-emmc --flash-offset=0xA00000

    (The R5 firmware was intentionally not flashed)

    When I try to boot AM64x GP evm (using eMMC boot pins) I get this message:

    AM64x_SBL Starting ...


----------------------------------------------

SolarEdge AM64x_SBL  version 0.0.1.Compiled on Aug 17 2022 17:56:27.

----------------------------------------------

Boot-mode enabled, Entering Bootloading process...

R5_0_0 Validation
Failed to boot application. No valid Firmware exist.

R5_0_1 Validation
Failed to boot application. No valid Firmware exist.

R5_1_0 Validation
Failed to boot application. No valid Firmware exist.

R5_1_1 Validation
Failed to boot application. No valid Firmware exist.

Cortex M4 Validation
Failed to boot application. No valid Firmware exist.

SBL image Validation
Loading images.......
Image loading done, switching to application ...
Starting linux and RTOS/Baremetal applications

NOTICE:  BL31: v2.5(release):08.03.00.002-dirty
NOTICE:  BL31: Built : 10:19:09, Aug 22 2022

U-Boot SPL 2021.01-g15769936a5 (Aug 22 2022 - 10:33:48 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Trying to boot from MMC1


    It seems the SBL is executed successfully, and continues to the LinuxAppImage which also loads successfully.
    The next step is to boot Linux. This is where i am stuck.

    I have tried to follow the guide here:
    https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/08_05_00_21/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html

    From what i understand, i need to boot linux (from sd card), create an ext4 user partition in eMMC, and copy the RootFS to that partition.
    That is what i have tried to do, but i am still unable to boot:
    I used "parted" program to create an MBR and made a primary partition in the 1024mb start - 2048 end. (1gb size total)

    SD card partitions:

    Model: SD SC128 (sd/mmc)
Disk /dev/mmcblk1: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system  Flags
 1      4096B   21.8MB  21.8MB  primary   fat16        boot, lba
 2      21.8MB  1201MB  1179MB  primary   ext4
 3      1201MB  1620MB  419MB   primary   ext4
 4      1620MB  3508MB  1887MB  extended               lba
 5      1620MB  2249MB  629MB   logical   ext4
 6      2249MB  2879MB  629MB   logical   ext4
 7      2879MB  3508MB  629MB   logical   ext4


    eMMC partitions:

    GNU Parted 3.3
Using /dev/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: MMC S0J56X (sd/mmc)
Disk /dev/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1024MB  2048MB  1023MB  primary  ext4

    And we can see the RootFS i have on /dev/mmcblk0:

    mount /dev/mmcblk1p1 /mnt/bla

sh-5.0# ls -al /mnt/bla
drwxr-xr-x   18 root     root          4096 Jan 16 12:43 .
drwxr-xr-x    3 root     root          4096 Jan  5 21:28 ..
drwxr-xr-x    2 root     root          4096 Jan 16 12:43 bin
drwxr-xr-x    2 root     root          4096 Jan 16 12:42 boot
drwxr-xr-x    2 root     root          4096 Jan  4 11:44 dev
drwxr-xr-x   38 root     root          4096 Jan 16 12:43 etc
drwxr-xr-x    3 root     root          4096 Jan 16 12:42 home
lrwxrwxrwx    1 root     root            20 Jan 16 12:43 init -> /lib/systemd/systemd
drwxr-xr-x    8 root     root          4096 Jan 16 12:43 lib
lrwxrwxrwx    1 root     root            19 Jan 16 12:43 linuxrc -> /bin/busybox.nosuid
drwx------    2 root     root         16384 Jan 16 12:34 lost+found
drwxr-xr-x    2 root     root          4096 Jan  4 11:44 media
drwxr-xr-x    2 root     root          4096 Jan  4 11:44 mnt
dr-xr-xr-x    2 root     root          4096 Jan  4 11:44 proc
drwxr-xr-x    2 root     root          4096 Jan  4 14:05 run
drwxr-xr-x    2 root     root          4096 Jan 16 12:43 sbin
dr-xr-xr-x    2 root     root          4096 Jan  4 11:44 sys
drwxrwxrwt    2 root     root          4096 Jan  4 11:44 tmp
drwxr-xr-x   10 root     root          4096 Jan 16 12:43 usr
drwxr-xr-x    8 root     root          4096 Jan 16 12:43 var

    And also output of fdisk -l

    isk /dev/mmcblk1: 119.9 GiB, 127865454592 bytes, 249737216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb0349158

Device         Boot   Start     End Sectors  Size Id Type
/dev/mmcblk1p1 *          8   42605   42598 20.8M  c W95 FAT32 (LBA)
/dev/mmcblk1p2        42608 2345387 2302780  1.1G 83 Linux
/dev/mmcblk1p3      2345392 3164591  819200  400M 83 Linux
/dev/mmcblk1p4      3164598 6851015 3686418  1.8G  f W95 Ext'd (LBA)
/dev/mmcblk1p5      3164600 4393399 1228800  600M 83 Linux
/dev/mmcblk1p6      4393408 5622207 1228800  600M 83 Linux
/dev/mmcblk1p7      5622216 6851015 1228800  600M 83 Linux


Disk /dev/mmcblk0: 14.84 GiB, 15913189376 bytes, 31080448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x83c3424e

Device         Boot   Start     End Sectors  Size Id Type
/dev/mmcblk0p1      2000896 3999743 1998848  976M 83 Linux

    Here is the dmesg output with grep on eMMC

    dmesg | grep mmc
[    2.514979] mmc0: CQHCI version 5.10
[    2.533958] vdd_mmc1: supplied by vsys_3v3
[    2.546034] mmc1: CQHCI version 5.10
[    2.553617] mmc0: SDHCI controller on fa10000.mmc [fa10000.mmc] using ADMA 64-bit
[    2.595447] mmc1: SDHCI controller on fa00000.mmc [fa00000.mmc] using ADMA 64-bit
[    2.656035] mmc1: new ultra high speed SDR104 SDXC card at address aaaa
[    2.663571] mmc0: Command Queue Engine enabled
[    2.668078] mmc0: new HS200 MMC card at address 0001
[    2.673801] mmcblk1: mmc1:aaaa SC128 119 GiB
[    2.678488] mmcblk0: mmc0:0001 S0J56X 14.8 GiB
[    2.683246] mmcblk0boot0: mmc0:0001 S0J56X partition 1 31.5 MiB
[    2.690569] mmcblk0boot1: mmc0:0001 S0J56X partition 2 31.5 MiB
[    2.697014] mmcblk0rpmb: mmc0:0001 S0J56X partition 3 4.00 MiB, chardev (237:0)
[    2.705623]  mmcblk1: p1 p2 p3 p4 < p5 p6 p7 >
[    2.710830]  mmcblk0: p1
[    2.752815] EXT4-fs (mmcblk1p2): recovery complete
[    2.758753] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)
[    4.333029] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null)
[    9.994769] FAT-fs (mmcblk0p1): bogus number of reserved sectors
[   10.002477] FAT-fs (mmcblk0p1): Can't find a valid FAT filesystem
[   11.398979] EXT4-fs (mmcblk1p7): mounted filesystem with ordered data mode. Opts: (null)
[   11.710907] EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. Opts: (null)
[   11.798910] EXT4-fs (mmcblk1p6): mounted filesystem with ordered data mode. Opts: (null)
[   11.842905] EXT4-fs (mmcblk1p5): mounted filesystem with ordered data mode. Opts: (null)
[  211.146405]  mmcblk0: p1
[  347.578100]  mmcblk0: p1
[  376.583294] EXT4-fs (mmcblk0p1): recovery complete
[  376.588168] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

    I am unsure why the boot fails.
    I made an ext4 partition that has a RootFS in eMMC (the offset is 1gb should not interfere with SBL and LinuxAppImage)
    I have flashed SBL and LinuxAppImage using the uart_uniflash.py tool.

    Maybe i am missing a step, or maybe i am not creating the ext4 user partition correctly.

    Please advise the correct way to flash SBL and LinuxAppImage, and boot into a Linux system.

  • 0 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    Apologies for the delay in response.

    Please note linux.appimage itself does not contain uboot. It looks for uboot, which then looks for Linux. So, along with rootfs, uboot must also be present on the storage medium.


    Also, I understand what the requirement is. However, I would like to know if you have tried the following:

    • Boot Linux directly from eMMC instead of SBL booting Linux just like we boot Linux directly from sdcard.
    • Boot with SBL on OSPI & rootfs on eMMC.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 250 points

    Hi Prashant,

    I have managed to make an ext4 partition on eMMC and boot from that RootFS without using SBL and LinuxAppImage.

    However i am still unable to boot from eMMC when using SBL.

    SolarEdge AM64x_SBL  version 0.0.1.Compiled on Aug 17 2022 17:56:27.

----------------------------------------------

Boot-mode enabled, Entering Bootloading process...

R5_0_0 Validation
Failed to boot application. No valid Firmware exist.

R5_0_1 Validation
Failed to boot application. No valid Firmware exist.

R5_1_0 Validation
Failed to boot application. No valid Firmware exist.

R5_1_1 Validation
Failed to boot application. No valid Firmware exist.

Cortex M4 Validation
Failed to boot application. No valid Firmware exist.

SBL image Validation
Loading images.......
Image loading done, switching to application ...
Starting linux and RTOS/Baremetal applications

NOTICE:  BL31: v2.5(release):08.03.00.002-dirty
NOTICE:  BL31: Built : 10:19:09, Aug 22 2022

U-Boot SPL 2021.01-g15769936a5 (Aug 22 2022 - 10:33:48 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Trying to boot from MMC1

    I am still unsure why it fails.

    Is it an issue with LinuxAppImage? (I do not see any OPTEE prints i would usually see)
    This is taken from SD-Card boot:

    OTICE:  BL31: v2.7(release):v2.7.0-359-g1309c6c805-dirty
NOTICE:  BL31: Built : 20:50:32, Jan  5 2023
I/TC:
I/TC: OP-TEE version: 3.19.0-15-gd6c5d0037 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Archite                                                                                                                              cture 9.2-2019.12 (arm-9.10))) #1 Thu Jan  5 21:08:33 UTC 2023 aarch64
I/TC: WARNING: This OP-TEE configuration might be insecure!
I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
I/TC: Primary CPU initializing
I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.5.3--v08.05.03 (Chill Capybar')
I/TC: HUK Initialized
I/TC: Activated SA2UL device
I/TC: Fixing SA2UL firewall owner for GP device
I/TC: Enabled firewalls for SA2UL TRNG device
I/TC: SA2UL TRNG initialized
I/TC: SA2UL Drivers initialized
I/TC: Primary CPU switching to normal world boot

    I tried to generate the LinuxAppImage with my own binaries, and also with pre-built binaries from:
    am64xx-evm-linux-sdk-bin-08_05_00_21/board-support/prebuilt-images/

    Another thing to note is the LinuxAppImage config.mak

    #Linux image load address
ATF_LOAD_ADDR=0x0701a0000
OPTEE_LOAD_ADDR=0x9e800000
SPL_LOAD_ADDR=0x80080000

    I noticed our DTS has an ATF load address that is 0x0701c0000, I think this is something that has recently changed and perhaps is not updated in the documents yet. I tried updating the ATF_LOAD_ADDR but still not able to boot.

    However i think i am stuck before the RootFs partition which contains the kernel, dtb, and other files is even loaded.

    I am trying to follow this guide:
    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/SBL_BOOTING_LINUX_EMMC.html

    And also the guide here:
    https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html
    (this mainly explains booting eMMC without SBL so it is not helpful)

    Can you advise if you think the error is with LinuxAppImage or with RootFS,
    And what steps exactly need to be taken to support booting Linux with SBL on eMMC.

  • 0 in reply to Ben Schroeder
    Prodigy 250 points

    Hi Prashant,

    As a follow up to my previous question, i also wanted to verify the eMMC is supported with SBL.
    I am reading this page here:

    https://software-dl.ti.com/processor-sdk-sitara/esd/am64x/latest/exports/docs/rtos/pdk_am64x/docs/userguide/am64x/boot/boot_am64x.html#boot-modes

    It says supported modes are: 
    MMCSD, OSPI, and UART Boot modes

    Is eMMC (flash) supported like MMC SDcard?
    They should behave the same, correct?

  • 0 in reply to Ben Schroeder
    Prodigy 250 points

    This page discusses booting Linux using SBL in eMMC, so i assume it is supported.

    https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_31/exports/docs/api_guide_am64x/EXAMPLES_DRIVERS_SBL_EMMC_LINUX.html

    The guide doesn't show the full steps, which is why i am having problems.
    When i try to follow the steps from different guides, to create the LinuxAppImage, RootFs, and flash the RootFs in ext4 partition, i am not able to boot.

  • 0 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    Please boot from sdcard to get uboot prompt and then run only the following commands also available at https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Memory.html#booting-tiboot3-bin-tispl-bin-and-u-boot-img-from-emmc-boot-partition-for-k3-class-of-socs :

    => mmc dev 0 1
=> fatload mmc 1 ${loadaddr} u-boot.img
=> mmc write ${loadaddr} 0x1800 0x2000

    After writing the u-boot.img, boot from eMMC. You should now be able to get UBoot prompt. Once you confirm this, we can move forward.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru* 81821 points

    Hi Ben,

    You may check my screen recording of booting Linux from eMMC. I have tested with sbl_emmc_linux from mcu_plus_sdk_am64x_08_04_00_17 with the default linux.appimage generated using prebuilt binaries from ti-processor-sdk-linux-am64xx-evm-08.02.00.23 used in the config.mak

    At the end of video, you can also find the layout of eMMC. The same is pasted below:

    Disk /dev/mmcblk0: 14.84 GiB, 15913189376 bytes, 31080448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0886490a

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1        2048   264191   262144  128M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      264192 31080447 30816256 14.7G 83 Linux

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 250 points

    Can you provide the steps you took to write the sbl_emmc_linux and linux.appimage to flash?

    Are you using the: mcu_plus_sdk_am64x_08_05_00_24\tools\boot\uart_uniflash.py tool?
    Or are you copying all the files from the u-boot menu?

    => mmc dev 0 1
=> fatload mmc 1 ${loadaddr} u-boot.img
=> mmc write ${loadaddr} 0x1800 0x2000

    I have done this, and I have not been able to get a u-boot prompt on eMMC.
    The eMMC needs a boot loader before it can reach the u-boot prompt.

    When I used the uart_uniflash.py it will probably overwrite the fat32 boot partition, and the original boot loader, with my custom SBL.
    So i think we do not have the same starting point on our systems.

    I have also tried to partition eMMC in the manner you suggested (FAT32 primary, and ext4 Linux for the other partition), still i have problem.
    Can you provide the complete steps to copy the required files and create the necessary partitions?

    Thank you.

  • +1 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    An eMMC is somewhat different from SD card. A SD card offers a large single pool of memory however the same does not apply for eMMC. An eMMC is divided into the following hardware partitions:

    +---------+---------+--------+----------------------------------+
|  boot0  |  boot1  |  rpmb  |          User Data Area          |
+---------+---------+--------+----------------------------------+

    Knowing the above partition is important in booting Linux from eMMC. You can confirm these partitions if you boot into Linux via SD card and list the contents of /dev directory. You will find at least the following block files:

    mmcblk0 -> User Data Area
mmcblk0boot0 -> boot0 partition
mmcblk0boot1 -> boot1 partition
mmcblk0rpmb -> rpmb partition

    If your UDA has n partitions, then you will also additionally find the following files:

    mmcblk0p1
mmcblk0p2
.
.
.
mmcblk0pn

    Writing Images

    Now, when we flash images using uart_uniflash.py script, we are actually writing images to boot0 partition of eMMC. The same applies for the previously shared commands to write u-boot.img. Those commands write the image to boot0 partition selected by mmc dev 0 1. We also tell ROM to boot from boot0 partition by the following commands in U-Boot.

    => mmc partconf 0 1 1 1
=> mmc bootbus 0 2 0 0

    At this point images have been written to boot0 partition & UDA is still unaffected. Now, booting from eMMC at this point should get you to the U-Boot prompt. You still can't boot Linux from eMMC since rootfs is still not there.

    Writing rootfs

    To write rootfs to eMMC, we create partitions on UDA. The whole UDA can be partitioned to have one partition of type Linux. After creating partition, we then format it with ext4 formatting. At this point, UDA has a empty ext4 filesystem. We then boot into Linux via SD card & copy the contents of rootfs parition on SD card to eMMC.

    The above setup bring the required components on eMMC to be able to fully boot Linux from eMMC only.

    Regards,

    Prashant

  • +1 in reply to Prashant Shivhare
    TI__Guru* 81821 points

    With the above understanding, the exact steps followed by me to boot Linux from eMMC via SBL are as follows:

    • Build the linux.appimage with the default config.mak in mcu_plus_sdk_am64x_08_04_00_17.
    • Flash the below configuration file with uart_uniflash.py script.
      default_sbl_emmc_linux.cfg
    • After the above flashing is successful, boot into U-Boot prompt via SD card then write u-boot.img with the below commands
      => mmc dev 0 1
=> fatload mmc 1 ${loadaddr} u-boot.img
=> mmc write ${loadaddr} 0x1800 0x2000
    • After u-boot.img is written successfully, boot into Linux via SD card & partition the UDA partition of eMMC. UDA does not need to have a FAT32 partition. So, the whole UDA can be partitioned into one partition of type Linux. After formatting the partition with ext4, copy the rootfs partition from SD card to this UDA partition.

    After following the above setup, boot into eMMC and stop the autoboot to get U-Boot prompt & run the following commands to direct UBoot to boot rootfs from eMMC.

    => setenv mmcdev 0
// If rootfs on UDA is on partition 1 then below command otherwise change the partition number accordingly.
=> setenv bootpart 0:1
=> boot

    After this, I boot into Linux successfully.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    TI__Guru* 81821 points

    Hi Ben,

    Here are the screen recording of formatting eMMC & copyting rootfs from SD card.

    After this, following is the screen recording of booting linux from emmc with only one partition on UDA.

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 250 points

    Hi Prashant,

    I also tried with the process with the same SDK you are using without success.
    Are you also using the AM64 GP EVM board?
    Can you attach the files you are using?

    1. SBL emmc tiimage
    2. bl31.bin, bl32.bin, u-boot-spl.bin-am64xx-evm
    3. linux.appimage (which is composed from the files in section 2)
    4. u-boot.img (which you wrote to flash in the SD-card boot menu)

    Thank you,
    Ben S.

  • +1 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    Please note I am using mcu_plus_sdk_am64x_08_04_00_17 and the default processor SDK version it depends on which is ti-processor-sdk-linux-am64xx-evm-08.02.00.23.

    Ben Schroeder said:
    Are you also using the AM64 GP EVM board?

    I am also using AM64x GP EVM only.

    Attached below zip file contains images I used. These images are default images only.

    0068.Images.zip

    Also, to simplify things, you can use UART_UNIFLASH only to flash your u-boot.img file instead of writing it from SD card. Assuming u-boot.img at stored at the location of linux.appimage, the below attached configuration file has the commands to flash all images including u-boot.img.

    6457.default_sbl_emmc_linux.cfg

    Regards,

    Prashant

  • 0 in reply to Prashant Shivhare
    Prodigy 250 points

    Thank you for your help Prashant.
    Your detailed replies solved the issue for me.

    Since this was a long thread, I will summarize the issues for everyone, and how they were resolved.

    Task:
    Boot SBL from eMMC into Linux OS.

    Issues:
    The boot process would stop before loading uboot

    -Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:43:41 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
SPL initial stack usage: 13392 bytes
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.5(release):08.03.00.002-dirty
NOTICE:  BL31: Built : 17:38:37, May  5 2022

U-Boot SPL 2021.01-g44a87e3ab8 (May 05 2022 - 17:42:22 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0016 '22.1.1--v2022.01 (Terrific Llam')
Trying to boot from MMC2

    On some SBL images i tried, it would hang before even printing anything.

    Solutions:

    1. Create a linux.appimage using mcu_plus_sdk_am64x_08_04_00_17 and the default processor SDK version it depends on which is ti-processor-sdk-linux-am64xx-evm-08.02.00.23

    2. Flash u-boot.img to the mmc. (either by booting from sd-card, or by using the uart_uniflash.py script from the mcu+ sdk)

    3. Create an ext4 partition on eMMC which contains Linux (In the 'user data area' described above by Prashant).

    Notes:

    This was hard for me to solve because the board i am working with AM64x GP EVM (TMDS64GPEVM) does not boot with some newer SBL, and does not work with the new linux.appimage generated from SDK. I think because they are either signed or encrypted to work with the new high security board.

    Also if i got the correct SBL / linux.appimage version combination, i did not have the u-boot.img flashed, or vice versa.

    And lastly, I did not follow the guidelines carefully with the versions specified in the PSDK and MCU+ and the online guide.

  • 0 in reply to Ben Schroeder
    TI__Guru* 81821 points

    Hi Ben,

    Glad to know you got it worked. And also thank you for summarizing the thread. This concise explanation will help future readers.

    Regards,

    Prashant