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.

Linux/PROCESSOR-SDK-AM65X: UART boot halts when using MAIN_UART1 as serial console

Part Number: PROCESSOR-SDK-AM65X
Other Parts Discussed in Thread: AM6548

Tool/software: Linux

Hello,

I am currently working on bringing up a board designed around the AM6548 processor. When using TI's device tree configuration, I can boot into U-Boot through MCU_UART0 and MAIN_UART0. When I attempt to use MAIN_UART1 as the serial console, the UART boot process fails after ATF is loaded.

I added the following to k3-am654-base-board.dts:

&main_uart1 {
	pinctrl-names = "default";
	pinctrl-0 = <&main_uart1_pins_default>;
	status = "okay";
};

/* under &main_pmx0 */
main_uart1_pins_default: main_uart1_pins_default {                                                                                                                                                          
        pinctrl-single,pins = <                                                                                                                                                                             
                AM65X_IOPAD(0x014c, PIN_OUTPUT | MUX_MODE6)     /* (AD23) PRG1_PRU1GPO7.UART1_TXD */                                                                                                        
                AM65X_IOPAD(0x0174, PIN_INPUT | MUX_MODE6)      /* (AE23) PRG1_PRU1GPO17.UART1_RXD */                                                                                                       
                AM65X_IOPAD(0x0178, PIN_INPUT | MUX_MODE6)      /* (AD22) PRG1_PRU1GPO18.UART1_CTS */                                                                                                       
                AM65X_IOPAD(0x017c, PIN_OUTPUT | MUX_MODE6)     /* (AC21) PRG1_PRU1GPO19.UART1_RTS */                                                                                                       
        >;                                                                                                                                                                                                  
};                    

I also added the same entries to k3-am654-r5-base-board.dts with the addition of u-boot,dm-spl; lines in each.

In all of the device tree files, references to serial2 were changed to serial3, and references to the MAIN_UART0 base address of 0x0280000 were changed to the MAIN_UART1 base address of 0x02810000. I get console output on MAIN_UART1 when the device tree files are configured this way but, again, the boot process fails.

Is there another non-obvious location to configure the UART and/or serial console to allow boot to succeed? Possibly in the TI SCI configuration files? Any suggestions will be greatly appreciated.

Thanks,

Matt McKee

  • Hi, Matt,

    We'll take a look at the issue and get back to you.

    Rex
  • Matt,

    Could you elaborate on "boot process fails", and if possible, please provide logs.
    Do you have stdout-path= updated to proper value in both r5-base-board and base-board dts files?

    Rex
  • Matt,

    Also, please take a look at the attached powerdomain patch to uart to see if it helps.

    Rex

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/uart_5F00_powerdomain.patch

  • Hi Rex,

    Thank you for the response. When I say the boot process fails, I mean that output stops and no further interaction is possible with the board. The following log is from stdout-path= being updated in both the r5-base-board and base-board dts files:

    U-Boot SPL 2018.01-00465-gb864b20-dirty (Dec 12 2018 - 12:27:33)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from UART
    CCCCxyzModem - CRC mode, 1(SOH)/493(STX)/0(CAN) packets, 6 retries
    Loaded 503912 bytes
    Starting ATF on ARM64 core...
    
    <HALTS HERE>

    Just to reiterate, this is with a known-working configuration with only references to serial2 being changed to serial3 in stdout-path= in all of the files where it exists, UART1 being muxed and enabled, as well as the UART0 base address being changed to the UART1 base address of 0x02810000.

    I did attempt to change the UART configurations in both ATF and OP-TEE, but the "U-Boot for AM65x Family of SoCs" document as well as the board/ti/am65x/README file points users to branches of both ATF and OP-TEE that do not reflect the pre-compiled versions of these components that are included with the latest Linux SDK. Binaries compiled from these sources fail to boot regardless of how they are configured. Can you point me to the exact branches and commits and/or tags used to compile the versions of ATF and OP-TEE included with the latest Linux SDK?

    Thanks,

    Matt McKee

  • Rex,

    No change with this patch being adapted for U-Boot.
  • Hi, Matt,

    The yocto recipes have the commit ID it uses to build the optee and atf. You can follow the build steps in software-dl.ti.com/.../Overview_Building_the_SDK.html to populate the yocto project, and check the recipes for both components. I haven't set it up yet, but will do it at the same time.

    Rex
  • Rex,

    I want to be absolutely certain that I'm using the correct, supported versions of ATF and OP-TEE for testing. The reason I ask for the commit IDs is that the meta-ti layer listed in processor-sdk-05.01.00.11-config.txt, from the oe-layersetup repo, points to the incorrect versions of both U-Boot and Linux.
    Meta-ti U-Boot SRCREV is 8b2f1df4b55bc0797399a21d42ac191d44f99227 which does not correspond to any of the latest ten commits in ti-processor-sdk-linux-am65xx-evm-05.01.00.11/board-support/u-boot-2018.01+gitAUTOINC+cdb1cc0a9e-gcdb1cc0a9e.
    Meta-ti Linux SRCREV is 735eec74130568dfb16bd986b59f7a2cf2549724 which does not correspond to any of the latest ten commits in ti-processor-sdk-linux-am65xx-evm-05.01.00.11/board-support/linux-4.14.67+gitAUTOINC+d315a9bb00-gd315a9bb00

    Can you please confirm that the commit IDs listed in Yocto for both ATF and OP-TEE are the exact versions bundled with the latest SDK release?

    Thanks,
    Matt McKee
  • HI, Matt,

    I see the differences between release note and that from git log of u-boot and kernel. The difference for u-boot seems ok. It is one commit away caused by building process for labelling the local branch. We'll fix the release note for kernel commit id. Thanks for pointing it out. I am verifying the meta-ti. It is hard to believe because the release is built using yocto, and the commit ids should align with the those of u-boot and kernel in SDK. Besides, I can't find the commit id you indicated in the kernel git log. Your meta-ti u-boot commit id is one version older than SDK. I'll get back to you once I verify them.

    Rex
  • Hi, Matt,

    You are looking at the wrong recipes. The meta-ti commit ids you pointed are TI core sdk commit ids which Processor SDk takes them and applies platform patches on top of them for particular release. You should look at the recipes under meta-processor-sdk/recipe-kernel/linux and meta-processor-sdk/recipe-bsp/u-boot.

    We do find Kernel commit id in the release note doesn't reflect the one used. We'll have it fixed.

    Rex
  • Hi Rex,

    You are correct. I didn't look at the entire Processor SDK layer configuration, but only at meta-ti. I will try using UART1 on the EVM, using the ATF and OPTEE versions pointed to in the full SDK layer, and get back to you with my results.

    Thanks,
    Matt McKee
  • Hi, Matt,

    Let me know how it goes. If it is still not working, please provide the new boot logs. I'll discuss internally to see what could be causing it.

    Rex
  • Hi Rex,

    We reworked the AM65x EVM to send the UART1 signals to the FTDI chip without having to worry about software support of the GPIO expander in U-Boot SPL. In software, we modified the following:

    ATF, using commit 516abc5fb4826e28be0acdbe6e22fd1b1b476c59,

    diff --git a/plat/ti/k3/include/platform_def.h b/plat/ti/k3/include/platform_def.h
    index ab0739e..92c0921 100644
    --- a/plat/ti/k3/include/platform_def.h
    +++ b/plat/ti/k3/include/platform_def.h
    @@ -125,7 +125,7 @@
     
     /* Platform default console definitions */
     #ifndef K3_USART_BASE_ADDRESS
    -#define K3_USART_BASE_ADDRESS 0x02800000
    +#define K3_USART_BASE_ADDRESS 0x02810000
     #endif
     
     /* USART has a default size for address space */

    OP-TEE, using the commit 48952f9f76d885df4cb65f8479a4cf7dedf0ee54,

    diff --git a/core/arch/arm/plat-k3/platform_config.h b/core/arch/arm/plat-k3/platform_config.h
    index b6f0997..700b743 100644
    --- a/core/arch/arm/plat-k3/platform_config.h
    +++ b/core/arch/arm/plat-k3/platform_config.h
    @@ -14,7 +14,7 @@
     #define UART2_BASE      0x02820000
     
     /* UART0 */
    -#define CONSOLE_UART_BASE       UART0_BASE
    +#define CONSOLE_UART_BASE       UART1_BASE
     #define CONSOLE_BAUDRATE        115200
     #define CONSOLE_UART_CLK_IN_HZ  48000000

    U-Boot, using the version included with the SDK,

    diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
    index 3211b86..26b1129 100644
    --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
    +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
    @@ -5,7 +5,7 @@
     
     / {
            chosen {
    -               stdout-path = "serial2:115200n8";
    +               stdout-path = "serial3:115200n8";
                    tick-timer = &timer1;
            };
    diff --git a/arch/arm/dts/k3-am654-base-board.dts b/arch/arm/dts/k3-am654-base-board.dts
    index 01c7b5e..88595e3 100644
    --- a/arch/arm/dts/k3-am654-base-board.dts
    +++ b/arch/arm/dts/k3-am654-base-board.dts
    @@ -14,8 +14,8 @@
            model = "Texas Instruments AM654 Base Board";
     
            chosen {
    -               stdout-path = "serial2:115200n8";
    -               bootargs = "earlycon=ns16550a,mmio32,0x02800000";
    +               stdout-path = "serial3:115200n8";
    +               bootargs = "earlycon=ns16550a,mmio32,0x02810000";
            };
     
            memory@80000000 {
    @@ -116,6 +116,12 @@
            status = "okay";
     };
     
    +&main_uart1 {
    +       pinctrl-names = "default";
    +       pinctrl-0 = <&main_uart1_pins_default>;
    +       status = "okay";
    +};
    +
     &main_pmx0 {
            main_uart0_pins_default: main_uart0_pins_default {
                    pinctrl-single,pins = <
    @@ -126,6 +132,15 @@
                    >;
            };
     
    +       main_uart1_pins_default: main_uart1_pins_default {
    +               pinctrl-single,pins = <
    +                       AM65X_IOPAD(0x014c, PIN_OUTPUT | MUX_MODE6)     /* (AD23) PRG1_PRU1GPO7.UART1_TXD */
    +                       AM65X_IOPAD(0x0174, PIN_INPUT | MUX_MODE6)      /* (AE23) PRG1_PRU1GPO17.UART1_RXD */
    +                       AM65X_IOPAD(0x0178, PIN_INPUT | MUX_MODE6)      /* (AD22) PRG1_PRU1GPO18.UART1_CTS */
    +                       AM65X_IOPAD(0x017c, PIN_OUTPUT | MUX_MODE6)     /* (AC21) PRG1_PRU1GPO19.UART1_RTS */
    +               >;
    +       };
    +
            main_i2c2_pins_default: main_i2c2_pins_default {
                    pinctrl-single,pins = <
                            AM65X_IOPAD(0x0074, PIN_INPUT | MUX_MODE5) /* (T27) GPMC0_CSn3.I2C2_SCL */
    diff --git a/arch/arm/dts/k3-am654-r5-base-board.dts b/arch/arm/dts/k3-am654-r5-base-board.dts
    index 859fef3..e011494 100644
    --- a/arch/arm/dts/k3-am654-r5-base-board.dts
    +++ b/arch/arm/dts/k3-am654-r5-base-board.dts
    @@ -80,6 +80,13 @@
            status = "okay";
     };
     
    +&main_uart1 {
    +       u-boot,dm-spl;
    +       pinctrl-names = "default";
    +       pinctrl-0 = <&main_uart1_pins_default>;
    +       status = "okay";
    +};
    +
     &wkup_uart0 {
            u-boot,dm-spl;
            pinctrl-names = "default";
    @@ -99,6 +106,16 @@
                    u-boot,dm-spl;
            };
     
    +       main_uart1_pins_default: main_uart1_pins_default {
    +               pinctrl-single,pins = <
    +                       AM65X_IOPAD(0x014c, PIN_OUTPUT | MUX_MODE6)     /* (AD23) PRG1_PRU1GPO7.UART1_TXD */
    +                       AM65X_IOPAD(0x0174, PIN_INPUT | MUX_MODE6)      /* (AE23) PRG1_PRU1GPO17.UART1_RXD */
    +                       AM65X_IOPAD(0x0178, PIN_INPUT | MUX_MODE6)      /* (AD22) PRG1_PRU1GPO18.UART1_CTS */
    +                       AM65X_IOPAD(0x017c, PIN_OUTPUT | MUX_MODE6)     /* (AC21) PRG1_PRU1GPO19.UART1_RTS */
    +               >;
    +               u-boot,dm-spl;
    +       };
    +
            main_mmc0_pins_default: main_mmc0_pins_default {
                    u-boot,dm-pre-reloc;
                    pinctrl-single,pins = <
    diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
    index 960e08a..b83ec6f 100644
    --- a/include/configs/am65x_evm.h
    +++ b/include/configs/am65x_evm.h
    @@ -67,7 +67,7 @@
            "overlayaddr=0x83000000\0"                                      \
            "name_kern=Image\0"                                             \
            "console=ttyS2,115200n8\0"                                      \
    -       "args_all=setenv optargs earlycon=ns16550a,mmio32,0x02800000 "  \
    +       "args_all=setenv optargs earlycon=ns16550a,mmio32,0x02810000 "  \
                    "${mtdparts}\0"                                         \
            "run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}\0"

    We then compiled U-Boot, pointing to the correct ATF and OP-TEE binaries. With this configuration, we do get initial output on UART1 on boot but the boot process fails when loading OP-TEE in the same way that it fails on our hardware:

    U-Boot SPL 2018.01-00465-gb864b20-dirty (Dec 17 2018 - 08:29:45)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v1.5(release):ti2018.03-rc1-dirty
    NOTICE:  BL31: Built : 08:21:36, Dec 17 2018
    

    No further output. Any suggestions?

    Thanks,

    Matt McKee

  • Hi, Matt,

    Could you try skipping OP-TEE loading and test by building ATF without the SPD=opteed in the build line?
    Just to exclude OP-TEE from the picture.

    Rex
  • Hi Rex,

    Tried it without OP-TEE as you suggested. Built ATF with the following command after a distclean:

    make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic

    Re-built U-Boot pointing to the new ATF and with and without the TEE variable specified. This is the result:

    U-Boot SPL 2018.01-00468-g1f974c6-dirty (Dec 21 2018 - 10:58:50)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v1.5(release):ti2018.03-rc1-dirty
    NOTICE:  BL31: Built : 10:41:45, Dec 21 2018
    ti_sci_get_response: Message receive failed. ret = -110
    Mbox send fail -110
    Failed to put device 159 (-110)
    ### ERROR ### Please RESET the board ###
    ▒
    U-Boot SPL 2018.01-00468-g1f974c6-dirty (Dec 21 2018 - 11:02:28)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v1.5(release):ti2018.03-rc1-dirty
    NOTICE:  BL31: Built : 10:41:45, Dec 21 2018
    ti_sci_get_response: Message receive failed. ret = -110
    Mbox send fail -110
    Failed to put device 159 (-110)
    ### ERROR ### Please RESET the board ###
    

    So it looks like building ATF without SPD=opteed in the build line isn't sufficient for skipping OP-TEE.

    Thanks,

    Matt McKee

  • Hi, Matt,

    I removed the optee from the ATF and u-boot was able to boot. I am just trying to verify it's not the build issue. However, after I finished typing this post, I just noticed that I was using the latest ATF, so I'll re-do it with the release commit. The following is what I did:

    I cloned ATF repository and rebuilt it without optee. Then rebuilt PLSDK 5.1 u-boot using the new ATF bl31.bin. I am able to boot the AM65x EVM.

    The ATF is cloned using the following commands. The optee was cloned but not used.
    git clone git://git.ti.com/atf/arm-trusted-firmware.git
    cd arm-trusted-firmware/
    git checkout ti-atf

    ATF and u-boot are built with the following commands:

    cd arm-trusted-firmware/
    make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic

    cd u-boot-2018.01+gitAUTOINC+cdb1cc0a9e-gcdb1cc0a9e/
    make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- am65x_evm_a53_defconfig O=a53
    make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- ATF=~/work/ti-processor-sdk-linux-am65xx-evm-05.01.00.11/board-support/arm-trusted-firmware/build/k3/generic/release/bl31.bin O=a53

    Since only ATF is changed and built without optee, I copied tispl.bin and u-boot.img under u-boot/a53 directory to the boot partition of the SD card. tiboot3 remains unchanged.

    The boot logs for the u-boot part:

    U-Boot SPL 2018.01-gcdb1cc0a9e (Oct 06 2018 - 03:46:53)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...

    NOTICE: BL31: v2.0(release):ti2018.05
    NOTICE: BL31: Built : 14:19:06, Dec 26 2018

    U-Boot SPL 2018.01-00444-g9abed97491-dirty (Dec 26 2018 - 14:25:15)
    Trying to boot from MMC2


    U-Boot 2018.01-00444-g9abed97491-dirty (Dec 26 2018 - 14:25:15 -0500)

    Model: Texas Instruments AM654 Base Board
    I2C: Error, wrong i2c adapter 0 max 0 possible
    ready
    DRAM: 4 GiB
    MMC: sdhci@0: 0, sdhci@0: 1
    *** Warning - bad CRC, using default environment

    Error, wrong i2c adapter 0 max 0 possible
    In: serial@2800000
    Out: serial@2800000
    Err: serial@2800000
    Net:
    Warning: cpsw_nuss@046000000 using MAC address from ROM
    eth0: cpsw_nuss@046000000
    Hit any key to stop autoboot: 0
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    ** Unable to read file boot.scr **
    1013 bytes read in 18 ms (54.7 KiB/s)
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    Running uenvcmd ...
    12490760 bytes read in 1223 ms (9.7 MiB/s)
    54359 bytes read in 149 ms (355.5 KiB/s)
    1963 bytes read in 109 ms (17.6 KiB/s)
    7007 bytes read in 99 ms (68.4 KiB/s)
    ## Flattened Device Tree blob at 82000000
    Booting using the fdt blob at 0x82000000
    reserving fdt memory region: addr=82000000 size=10e000
    Loading Device Tree to 00000000fddd2000, end 00000000fdee2fff ... OK

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.67-gd315a9bb00 (oe-user@oe-host) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #1 SMP PREEMPT Sat Oct 6 02:18:07 UTC 2018
    [ 0.000000] Boot CPU: AArch64 Processor [410fd034]
  • Hi, Matt,

    Yes, using the release commit, it makes no difference. The BL31 shows the same version as yours, v1.5. The u-boot is able to boot without optee.

    U-Boot SPL 2018.01-gcdb1cc0a9e (Oct 06 2018 - 03:46:53)
    SYSFW ABI: 2.4 (firmware rev 0x0012 '18.8.2-v2018.08b (Curious Crow)')
    Trying to boot from MMC2
    Starting ATF on ARM64 core...

    NOTICE: BL31: v1.5(release):ti2018.03-rc1
    NOTICE: BL31: Built : 15:51:13, Dec 26 2018

    U-Boot SPL 2018.01-00444-g9abed97491-dirty (Dec 26 2018 - 15:54:13)
    Trying to boot from MMC2


    U-Boot 2018.01-00444-g9abed97491-dirty (Dec 26 2018 - 15:54:13 -0500)

    Model: Texas Instruments AM654 Base Board
    I2C: Error, wrong i2c adapter 0 max 0 possible
    ready
    DRAM: 4 GiB
    MMC: sdhci@0: 0, sdhci@0: 1
    *** Warning - bad CRC, using default environment

    Error, wrong i2c adapter 0 max 0 possible
    In: serial@2800000
    Out: serial@2800000
    Err: serial@2800000
    Net:
    Warning: cpsw_nuss@046000000 using MAC address from ROM
    eth0: cpsw_nuss@046000000
    Hit any key to stop autoboot: 0
    switch to partitions #0, OK
    mmc1 is current device
    SD/MMC found on device 1
    ** Unable to read file boot.scr **
    1013 bytes read in 18 ms (54.7 KiB/s)
    Loaded env from uEnv.txt
    Importing environment from mmc1 ...
    Running uenvcmd ...
    12490760 bytes read in 1224 ms (9.7 MiB/s)
    54359 bytes read in 151 ms (350.6 KiB/s)
    1963 bytes read in 110 ms (16.6 KiB/s)
    7007 bytes read in 100 ms (68.4 KiB/s)
    ## Flattened Device Tree blob at 82000000
    Booting using the fdt blob at 0x82000000
    reserving fdt memory region: addr=82000000 size=10e000
    Loading Device Tree to 00000000fddd2000, end 00000000fdee2fff ... OK

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 4.14.67-gd315a9bb00 (oe-user@oe-host) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #1 SMP PREEMPT Sat Oct 6 02:18:07 UTC 2018
    [ 0.000000] Boot CPU: AArch64 Processor [410fd034]
  • Hi, Matt,

    I looked at your logs and the error you get "ti_sci_get_response: Message receive failed. ret = -110" is timeout from mbox_recv() inside of ti_sci_get_response(). ti_sck_get_response() is called only in ti_sci_do_xfer() which is called in multiple places. I am not sure which step it failed nor the relationship of the UART1 with the communication of sci firmware. I'll need to run it with firmware expert. This may take a while due to holidays.

    Rex
  • Hi Rex,

    Happy New Year. I ran a boot test without OP-TEE on the EVM with the same ATF and U-Boot code configured for UART0 and I was able to boot into Linux as expected. However, with ATF and U-Boot configured for UART1, the boot process fails with the error message you noted above.

    Thanks,
    Matt
  • Hi, Matt,

    Happy New Year and wish you had a good one. We suspect the u-boot has started but isn't outputing on UART1. Have you tried to attach a debugger and looked at the address execution is stuck at? What is the address?

    Rex
  • Hi, Matt,

    Have you had any chance to give it a try on what was suggested in the last post?

    Rex
  • Hi Rex,

    I just tested UART1 with the latest SDK (not available when I first created this post) and the boot process now works as it should and outputs to the configured serial console in all stages of U-Boot. I also tested with and without the UART power domains patch that you offered in an earlier post and it seems that UART1 works whether that patch is applied or not. I haven't tried to modify ATF or OP-TEE to get UART1 output but that doesn't seem necessary right now.

    Thanks again for your help,
    Matt McKee
  • Sorry for the follow-up, but I made a mistake in implying that UART boot works with the latest SDK with my last post. I meant that configuring the default serial console to UART1 no longer causes issues with boot over MMC/SD as it did for us on our board and on the EVM. We transitioned to MMC/SD after I initially wrote this post. We still have one hardware configuration that is having trouble with MMC/SD and tried UART boot on it with the latest SDK.

    UART boot now seems to not work at all with the change to the packaging of sysfw.bin. With sysfw.bin now located in sysfw.itb, uploading tiboot3.bin or sysfw.itb as the initial image over UART does not allow the boot to proceed to the next stage. Any suggestions?

    Thanks,
    Matt McKee
  • Hi, Matt,

    Ok. I checked the release notes and git log history, but couldn't find anything related to UART1 changes in 5.2. I was puzzling about it and tried to dig further to see what could be the changes. Now, it makes sense.

    I'll need to spend some time on this sysfw myselft first. Let me see what I run into.

    Rex
  • Hi, Matt,

    Do you mind that I close this thread for now? However, I would like you to create a new thread for uart boot issue with sysfw on AM65x and let's work on the new thread.

    Rex

  • That's fine. I'll make a new thread with some more detail when I get a chance. Thanks.