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.

Options for "early" UART access on boot

Part Number: AM6442

Hi TI team,

We are working on a design that uses AM64x and a C2000 DSP on the same board. After Linux boots, we use one of the AM64x UART ports to load firmware to the C2000 DSP. We like this method since it allows the C2000 firmware to be stored on the AM64x eMMC, which is easy to update. However this boot flow takes too long for our application (~15-20 sec for Linux boot on AM64x which delays loading of DSP firmware). We are trying to find a better option that allows us to start loading the C2000 firmware <500ms after POR if possible.

Current method (too slow):

AM64x SPL boot -> U-boot -> Linux boots on A53 -> Linux app reads firmware from eMMC -> Linux app writes firmware to C2000 DSP via UART

Idea for faster DSP load:

Customize SPL to read firmware from eMMC -> SPL loads firmware to C2000 DSP via UART -> SPL branches to U-boot -> Boot Linux on A53s

Questions

1. Is it possible to customize the SPL?

2. Can SPL read the file system on eMMC to find the C2000 firmware (a simple file on eMMC file system)?

3. What is required to enable a UART port in the SPL?

4. If we could create a custom SBL that might be a better option, but as I understand it SBL cannot branch to U-boot SPL as of Processor-SDK v8.00. Is that correct?

5. Is there a better option for "early" access to UART during boot on AM64x?

Thanks!

  • Hi Steven,
    You may refer to the link for eMMC partitions on AM64x GP EVM
    software-dl.ti.com/.../UG-Memory.html
    where for default eMMC booting:
    - boot partition is RAW
    - user partition is EXT4

    Reading eMMC to DDR from boot partition or user partition is possible @u-boot prompt.
    I'm attaching a log file I captured on AM64x GP EVM for your reference, where
    - tiboot3.bin is read to DDR from the boot partition
    - k3-am642-evm.dtb is read to DDR from the user partition

    For your questions:
    1. Yes
    2. For eMMC boot, the first bootloader (tiboot3.bin running on R5) can read the next stage bootloaders (tispl.bin running on A53) from the boot partition (RAW for default eMMC boot). After booting to u-boot prompt, reading eMMC to DDR from boot partition (RAW) and user partition (EXT4) is possible as shown in the attached log file.
    3. In default u-boot, it is possible to output to UART port for serial terminal logging, and also to read from UART port to DDR (ie. loadx/loady etc...u-boot cmds...).
    4. The current plan is to enable SBL booting Linux in SDK 8.1 tentatively targeted towards to the end of Nov-2021.
    5. See #3 above.

    Best,

    -Hong

    U-Boot SPL 2020.01-00016-ge995ed0ec1-dirty (Jul 01 2021 - 17:43:11 -0500)
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
    SPL initial stack usage: 13396 bytes
    Trying to boot from MMC1
    Loading Environment from MMC... OK
    init_env from device 9 not supported!
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v2.4(release):2021.00.003-dirty
    NOTICE:  BL31: Built : 14:41:43, May 28 2021
    
    U-Boot SPL 2020.01-00016-ge995ed0ec1-dirty (Jul 01 2021 - 17:40:32 -0500)
    SYSFW ABI: 3.1 (firmware rev 0x0015 '21.1.1--v2021.01a (Terrific Lla')
    Trying to boot from MMC1
    
    
    U-Boot 2020.01-00016-ge995ed0ec1-dirty (Jul 01 2021 - 17:40:32 -0500)
    
    SoC:   AM64X SR1.0
    Model: Texas Instruments AM642 EVM
    Board: AM64-GPEVM rev E2
    DRAM:  2 GiB
    not found for dev mux
    MMC:   sdhci@fa10000: 0, sdhci@fa00000: 1
    Loading Environment from MMC... OK
    In:    serial@2800000
    Out:   serial@2800000
    Err:   serial@2800000
    Net:   
    Warning: ethernet@8000000 using MAC address from ROM
    eth0: ethernet@8000000
    Hit any key to stop autoboot:  2  0 
    => md.b ${loadaddr} 0x100
    82000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    82000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    820000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    => mmc dev 0 1
    switch to partitions #1, OK
    mmc0(part 1) is current device
    => mmc read ${loadaddr} 0x0 0x100
    
    MMC read: dev # 0, block # 0, count 256 ... 256 blocks read: OK
    => md.b ${loadaddr} 0x100
    82000000: 30 82 04 27 30 82 03 90 a0 03 02 01 02 02 09 00    0..'0...........
    82000010: b1 c2 22 c5 5a ed 28 b3 30 0d 06 09 2a 86 48 86    ..".Z.(.0...*.H.
    82000020: f7 0d 01 01 0d 05 00 30 81 9d 31 0b 30 09 06 03    .......0..1.0...
    82000030: 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08    U....US1.0...U..
    82000040: 0c 02 54 58 31 0f 30 0d 06 03 55 04 07 0c 06 44    ..TX1.0...U....D
    82000050: 61 6c 6c 61 73 31 27 30 25 06 03 55 04 0a 0c 1e    allas1'0%..U....
    82000060: 54 65 78 61 73 20 49 6e 73 74 72 75 6d 65 6e 74    Texas Instrument
    82000070: 73 20 49 6e 63 6f 72 70 6f 72 61 74 65 64 31 13    s Incorporated1.
    82000080: 30 11 06 03 55 04 0b 0c 0a 50 72 6f 63 65 73 73    0...U....Process
    82000090: 6f 72 73 31 13 30 11 06 03 55 04 03 0c 0a 54 49    ors1.0...U....TI
    820000a0: 20 53 75 70 70 6f 72 74 31 1d 30 1b 06 09 2a 86     Support1.0...*.
    820000b0: 48 86 f7 0d 01 09 01 16 0e 73 75 70 70 6f 72 74    H........support
    820000c0: 40 74 69 2e 63 6f 6d 30 1e 17 0d 32 31 30 37 30    @ti.com0...21070
    820000d0: 31 32 32 34 37 33 38 5a 17 0d 32 31 30 37 33 31    1224738Z..210731
    820000e0: 32 32 34 37 33 38 5a 30 81 9d 31 0b 30 09 06 03    224738Z0..1.0...
    820000f0: 55 04 06 13 02 55 53 31 0b 30 09 06 03 55 04 08    U....US1.0...U..
    => ls mmc 0
    <DIR>       4096 .
    <DIR>       4096 ..
    <DIR>      16384 lost+found
    <DIR>       4096 bin
    <DIR>       4096 boot
    <DIR>       4096 dev
    <DIR>       4096 etc
    <DIR>       4096 home
    <SYM>         20 init
    <DIR>       4096 lib
    <SYM>         19 linuxrc
    <DIR>       4096 media
    <DIR>       4096 mnt
    <DIR>       4096 proc
    <DIR>       4096 run
    <DIR>       4096 sbin
    <DIR>       4096 sys
    <DIR>       4096 tmp
    <DIR>       4096 usr
    <DIR>       4096 var
    => ls mmc 0 boot
    <DIR>       4096 .
    <DIR>       4096 ..
    <SYM>         25 Image
            19137024 Image-5.10.41-g4c2eade9f7
                2284 k3-am642-evm-icssg1-dualemac.dtbo
               53223 k3-am642-evm.dtb
               50833 k3-am642-sk.dtb
    <SYM>         30 vmlinux.gz
             8993739 vmlinux.gz-5.10.41-g4c2eade9f7
    => load mmc 0 ${loadaddr} /boot/k3-am642-evm.dtb
    53223 bytes read in 5 ms (10.2 MiB/s)
    => md.b ${loadaddr} 0x100
    82000000: d0 0d fe ed 00 00 cf e7 00 00 00 38 00 00 ba ec    ...........8....
    82000010: 00 00 00 28 00 00 00 11 00 00 00 10 00 00 00 00    ...(............
    82000020: 00 00 14 fb 00 00 ba b4 00 00 00 00 00 00 00 00    ................
    82000030: 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00    ................
    82000040: 00 00 00 03 00 00 00 1c 00 00 00 00 54 65 78 61    ............Texa
    82000050: 73 20 49 6e 73 74 72 75 6d 65 6e 74 73 20 41 4d    s Instruments AM
    82000060: 36 34 32 20 45 56 4d 00 00 00 00 03 00 00 00 16    642 EVM.........
    82000070: 00 00 00 06 74 69 2c 61 6d 36 34 32 2d 65 76 6d    ....ti,am642-evm
    82000080: 00 74 69 2c 61 6d 36 34 32 00 00 00 00 00 00 03    .ti,am642.......
    82000090: 00 00 00 04 00 00 00 11 00 00 00 01 00 00 00 03    ................
    820000a0: 00 00 00 04 00 00 00 22 00 00 00 02 00 00 00 03    ......."........
    820000b0: 00 00 00 04 00 00 00 31 00 00 00 02 00 00 00 01    .......1........
    820000c0: 61 6c 69 61 73 65 73 00 00 00 00 03 00 00 00 26    aliases........&
    820000d0: 00 00 00 3d 2f 62 75 73 40 66 34 30 30 30 2f 62    ...=/bus@f4000/b
    820000e0: 75 73 40 34 30 30 30 30 30 30 2f 73 65 72 69 61    us@4000000/seria
    820000f0: 6c 40 34 61 30 30 30 30 30 00 00 00 00 00 00 03    l@4a00000.......
    => 

  • Hi Hong,

    Thanks for the feedback. I was able to build a customized SPL, but now that I'm familiar with the process I think a better option is to branch the first R5F core to a custom application after the R5F SPL boots the A53. Something like:

    R5F0_0 => ROM => SPL => load SYSFW => boot A53 => branch to R5F application

    Is this possible on AM64x, and if so are there any examples how to set this up?

  • Hi Steven,
    There's a out-of-box benchmark demo in AM64x SDK:
    software-dl.ti.com/.../Benchmark_Demo_User_Guide.html
    software-dl.ti.com/.../EXAMPLE_MOTORCONTROL_BENCHMARKDEMO.html
    Please have a look to see if it helps your design.
    Best,
    -Hong

  • Hi Hong,

    I thought the benchmark demo app uses Linux remoteproc to boot the R5Fs, not SPL or U-boot. Or am I wrong?

    Also, how can I add the benchmark demo to a Yocto build? By default, I only get the Matrixgui app when building tisdk-default-image, the benchmark demo is not included. I am building with coresdk-08.00.00.004.

  • Hi Steven,
    Sorry for delayed response as I was out of office for one week.
    Yes, you're right that the benchmark demo app uses Linux rproc to boot the R5Fs.
    Will you be able to build benchmark demo following the links in my last reply?
    Best,
    -Hong