• State
  • Replies 50 replies
  • Subscribers 57 subscribers
  • Views 1817 views
  • Users 0 members are here
Support feedback
Options
Options
Related

AM3357: CCS UniFlash v3.4.1 Compatibility Issue with U-Boot

Pooja Nagda
Prodigy 180 points

Part Number: AM3357
Other Parts Discussed in Thread: UNIFLASH,

Hello,

We are currently using CCS UniFlash v3.4.1 for flashing AM3357.

After upgrading to a newer U-Boot version (u-boot-restore v2025.01), an issue has been observed where the RNDIS interface initializes successfully, but the BOOTP handshake does not complete. As a result, the flashing process does not start. The BOOTP handshake occurs after the ROM bootloader (ROM BL) has executed SPL.

A minimal U-Boot defconfig is being used, based on the new Driver Model (DM), replacing the legacy USB/ETH stack which is being phased out in U-Boot.

Here is the full defconfig:
CONFIG_ARM=y
CONFIG_ARCH_CPU_INIT=y
CONFIG_ARCH_OMAP2PLUS=y
CONFIG_TI_COMMON_CMD_OPTIONS=y
CONFIG_DEFAULT_DEVICE_TREE="am335x-sml-factory"
CONFIG_AM33XX=y
CONFIG_TARGET_AM335X_IEC61850_MODULE=y
# CONFIG_SPL_MMC is not set
CONFIG_SPL_DRIVERS_MISC=y
CONFIG_SYS_BOOTCOUNT_ADDR=0x80001000
CONFIG_SPL=y
CONFIG_TIMESTAMP=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_OF_BOARD_SETUP=y
CONFIG_BOOTCOMMAND="run findfdt; run init_console; setenv autoload no; bootp; if tftp ${scriptaddr} debrick.scr; then source ${scriptaddr}; fi"
CONFIG_LOGLEVEL=7
# CONFIG_SYS_CONSOLE_INFO_QUIET is not set
CONFIG_ARCH_MISC_INIT=y
CONFIG_SPL_SHOW_ERRORS=y
CONFIG_SPL_SYS_MALLOC=y
CONFIG_SPL_SYS_MALLOC_SIZE=0x800000
CONFIG_SPL_DISPLAY_PRINT=y
CONFIG_SPL_ETH=y
# CONFIG_SPL_FS_EXT4 is not set
# CONFIG_SPL_I2C is not set
CONFIG_SPL_MUSB_NEW=y
# CONFIG_SPL_NAND_SUPPORT is not set
CONFIG_SPL_NET=y
CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL"
# CONFIG_SPL_AM33XX_ENABLE_RTC32K_OSC is not set
CONFIG_CMD_SPL=y
# CONFIG_CMD_I2C is not set
# CONFIG_CMD_SETEXPR is not set
CONFIG_BOOTP_DNS2=y
CONFIG_CMD_MTDPARTS=y
# CONFIG_SPL_EFI_PARTITION is not set
CONFIG_OF_CONTROL=y
CONFIG_SPL_OF_CONTROL=y
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
CONFIG_VERSION_VARIABLE=y
CONFIG_NET_RETRY_COUNT=10
CONFIG_BOOTP_SEND_HOSTNAME=y
CONFIG_SPL_OF_TRANSLATE=y
CONFIG_SPL_TI_SYSC=y
CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_BOOTCOUNT_GENERIC=y
CONFIG_CLK=y
CONFIG_SPL_CLK=y
CONFIG_CLK_TI_CTRL=y
CONFIG_DFU_TFTP=y
CONFIG_DFU_RAM=y
CONFIG_USB_FUNCTION_FASTBOOT=y
# CONFIG_I2C is not set
CONFIG_MISC=y
# CONFIG_MMC_HW_PARTITIONING is not set
CONFIG_MTD=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
CONFIG_MII=y
CONFIG_DRIVER_TI_CPSW=y
CONFIG_TIMER=y
CONFIG_OMAP_TIMER=y
CONFIG_USB=y
CONFIG_DM_USB_GADGET=y
CONFIG_SPL_DM_USB_GADGET=y
CONFIG_USB_MUSB_HOST=y
CONFIG_USB_MUSB_GADGET=y
CONFIG_USB_MUSB_TI=y
CONFIG_USB_GADGET=y
CONFIG_SPL_USB_GADGET=y
CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
CONFIG_USB_GADGET_VENDOR_NUM=0x0451
CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
CONFIG_USB_ETHER=y
CONFIG_SPL_USB_ETHER=y
CONFIG_WDT=y
# CONFIG_SPL_WDT is not set
CONFIG_DYNAMIC_CRC_TABLE=y
CONFIG_RSA=y
CONFIG_LZO=y
It works with our own Linux only manufactory script. But the Windows CCS Uniflash does not work anymore.

For reference, Linux manufacturing logs, kernel dmesg output, and a full tcpdump network capture have been attached for comparison.

SML-MFG-Linux.dmesg.log

SML-MFG-Linux.log 

ROM_SPL_UBOOT_LINUX_Capture.zip 

Regards,

Pooja Nagda

  • 0
    TI__Guru**** 180346 points

    Hi Pooja,

    Can you please help me understand how to interpret the log files you provided to understand the problem?

    I checked the 3 network dump files in wireshark but I don't see any obvious problem in the dumps, they all show the network traffic with BOOTP and/or ARP, then ended with TFTP.

  • 0 in reply to Bin Liu
    Prodigy 150 points

    Hi Bin,

    I provided the log files to Pooja which are showing working handshakes between AM335x and our Linux program during flashing of binaries. The logs are just for reference how it behaves well in Linux without involving Uniflash. The flashing program is written based on Snagboot:

    https://bootlin.com/blog/snagboot-designing-a-usb-recovery-process-for-am335x-socs/

    However, I don't have a Windows setup so I don't know why Uniflash does not work anymore when we develop the new u-boot based on TI u-boot v2025.01.

    From Pooja's side the project requires the Uniflash in Windows to be working with the new u-boot v2025.01 so that production can flash the bare metal with the new binaries which I developed.

    BR/Chencheng

  • 0 in reply to Chencheng Zhang
    TI__Guru**** 180346 points

    Hi Chencheng,

    Thanks for the clarification.

    Please note that the development of Uniflash supporting AM335x has been discontinued. So there won't be any update for Uniflash for AM335x.

    I recommend you debug the Uniflash problem with U-Boot v2025.01, for example by analyzing the network traffic, to see if it is a trivial issue which can be fixed by changing the U-Boot code on AM335x. if not, I would recommend to use the Snagboot based tool on Windows to flash the image.

  • 0 in reply to Bin Liu
    Prodigy 150 points

    Hi Bin,

    Thanks for your reply. Just to inform you, Snagboot does not support AM335x on Windows:

    https://github.com/bootlin/snagboot/blob/3740b6f7d0cb0a2ddea5ac096e196afcec3cf52c/docs/installing.md?plain=1#L58

      Please discuss within the project that TI had discontinued their support in Uniflash for AM335x.

    BR/Chencheng

  • 0 in reply to Chencheng Zhang
    TI__Guru**** 180346 points
    Chencheng Zhang said:
    Thanks for your reply. Just to inform you, Snagboot does not support AM335x on Windows:

    Thanks for the information.

    Now the only option I can think of is to debug the network protocol failure with U-Boot v2025.01 to see if this can be fixed by modifying the new U-Boot, if updating the Windows host is not an option.

  • 0 in reply to Bin Liu
    Prodigy 150 points

    Hi Bin,

    I think right now the CCS Uniflash 3 is completely a black box and it is hard to guess why it does not reply SPL 2025.01 BOOTP request.

    I think it would be much easier if we can debug CCS Uniflash 3 as well to see the debug log from its DHCP/TFTP side.

    I will be on parental leave soon. So  please follow this up to see if TI can let you turn on debugging on CCS Uniflash 3.

    BR/Chencheng

  • 0 in reply to Chencheng Zhang
    TI__Mastermind 23345 points

    Hi Chencheng,

    Bin is out of office until April 29th. Please expect a delayed response. Thanks.

  • 0 in reply to Anshu Madwesh
    TI__Guru* 85935 points

    Hello 
    Can you please see if following suggestions help you 

    ---

    BOOTP Handshake Failure with CCS UniFlash v3.4.1 After U-Boot v2025.01 Upgrade

    This is a well-documented Windows-specific issue. Your U-Boot DM-based defconfig is likely correct—the root cause is almost certainly a USB PID mismatch between the ROM bootloader and SPL stages that causes Windows to drop the RNDIS driver during the handoff, preventing UniFlash's BOOTP server from responding.

    Why It Fails on Windows but Works on Linux

    The AM335x USB boot process involves two separate USB enumerations:

    1. ROM stage — enumerates with PID 0x6141 (hardcoded in ROM) [1]
    2. SPL stage — re-enumerates with your configured PID 0xD022 (from CONFIG_USB_GADGET_PRODUCT_NUM) [2]

    When SPL re-enumerates with a different PID, Windows 10 fails to load the RNDIS driver for the new device, causing the USB Ethernet connection to drop entirely. UniFlash's internal BOOTP/DHCP server never sees the SPL's BOOTP request because there's no active network interface. Linux handles this transition gracefully, which is why your manufacturing script works [3][4].

    Recommended Fixes (in order of likelihood to resolve)

    1. Align the USB Product ID with the ROM Bootloader

    Change your defconfig so SPL uses the same PID as the ROM:

    CONFIG_USB_GADGET_PRODUCT_NUM=0x6141

    This was the confirmed fix for an identical symptom — ROM uses VID_0451&PID_6141, SPL defaults to VID_0451&PID_D022, and Windows refuses to bind the RNDIS driver to the second PID [2].

    2. Increase the USB Connection Timeout

    The DM USB gadget stack may initialize faster than Windows can enumerate the new RNDIS device. In drivers/usb/gadget/ether.c, increase USB_CONNECT_TIMEOUT from 3 to 20 seconds:

    #define USB_CONNECT_TIMEOUT 20

    This resolved BOOTP timeout failures for multiple users with identical symptoms [5].

    3. Reinstall the Windows RNDIS Driver

    Even with correct PIDs, Windows 10 sometimes has a non-functional RNDIS driver installed. Reinstalling the Microsoft-provided RNDIS driver (not a third-party one) resolved cases where the device enumerated but BOOTP timed out [3]. Specific Windows 10 builds (1709, 1809) have known RNDIS issues [2].

    4. Verify the VCI String

    Your CONFIG_SPL_NET_VCI_STRING is set to "AM335x U-Boot SPL". UniFlash's internal BOOTP server (opendhcp.cfg) uses the vendor-class-identifier (DHCP option 60) to determine which bootfile to serve [6]. The ROM sends "AM335x ROM" [1], and UniFlash expects SPL to send "AM335x U-Boot SPL". Confirm this string matches exactly what UniFlash expects—any deviation (including the (Spl) suffix visible in your defconfig) will cause UniFlash to ignore the BOOTP request.

    Note: Your defconfig shows CONFIG_SPL_NET_VCI_STRING="AM335x U-Boot SPL (Spl)" — if the (Spl) suffix is actually present in your real config (not just formatting in your post), this will break UniFlash's VCI matching. It must be exactly "AM335x U-Boot SPL".

    Verification Steps

    Check
    How
    USB PID during SPL
    Open Windows Device Manager → look for USB\VID_0451&PID_xxxx when SPL runs
    RNDIS driver binding
    Confirm "Linux USB Ethernet/RNDIS Gadget" appears (not "USB Serial Port" or "Unknown device") for both ROM and SPL stages
    BOOTP packets
    Run Wireshark on the Windows RNDIS interface to see if SPL's BOOTP broadcast arrives at all
    VCI string
    In the Wireshark capture, inspect DHCP option 60 in the BOOTP request from SPL

    Your Defconfig Assessment

    Your DM-based USB configuration is structurally sound. The key options are all present:

    • CONFIG_DM_USB_GADGET=y / CONFIG_SPL_DM_USB_GADGET=y ✓
    • CONFIG_USB_MUSB_GADGET=y / CONFIG_USB_MUSB_TI=y ✓
    • CONFIG_USB_ETHER=y / CONFIG_SPL_USB_ETHER=y ✓
    • CONFIG_SPL_ETH=y / CONFIG_SPL_NET=y ✓

    The issue is not your DM migration—it's the Windows host-side interaction with the USB enumeration sequence.

    To help refine this recommendation, it would be helpful to know:

    • What Windows 10 build version is being used (builds 1709 and 1809 have documented RNDIS issues)
    • Whether both RNDIS network interfaces appear in Windows Device Manager during the ROM→SPL transition
    • Whether you can capture a Wireshark trace on the Windows host during the failed attempt to confirm whether BOOTP packets are reaching the host at all
    • The contents of your am335x-sml-factory device tree, specifically whether USB nodes (usb, usb0_phy, usb_ctrl_mod) are enabled—certain device tree configurations can disable USB modules entirely [7]
    • Whether the previous U-Boot version that worked with UniFlash used the legacy USB stack, and what PID it presented
    1. AM335x Technical Reference Manual - BOOTP Protocol
    2. TI E2E: AM3358 USB Boot - RNDIS/Ethernet over USB (PID fix)
    3. TI E2E: BeagleBone Black U-Boot USB Ethernet Boot Issue
    4. TI E2E: AM3358 UniFlash and SPL
    5. TI E2E: AM3358 Flashing U-Boot to Empty eMMC
    6. TI Processor SDK - Flash Tools Documentation
    7. TI Application Note SPRAC74A - Power Consumption
  • 0 in reply to Mukul Bhatnagar
    Prodigy 180 points

    Hello Mukul,

    1. Host PC: Windows 11 Pro, Version 25H2 (OS Build 26200.7922).

    2. With the new U-boot v2025 the RNDIS network didn't appear after ROM --> SPL transition. It appeared only one time when I power ON the module, the VID/PID of that instance is USB\VID_0451&PID_6141&REV_0000. 

    3. Please find the attached wireshark capture. 

    Uboot_2025_wireshark_trace.zip

    4. The legacy Uboot version presented PID version after ROM --> SPL transition is USB\VID_0525&PID_A4A2&REV_0315.

    Could you please confirm whether the U-Boot changes you mentioned have been verified on your side? If they are working successfully for AM335x flashing, I would appreciate it if you could share the corresponding patch or details of the modifications.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi, I will review your update once I am back in office.

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Pooja Nagda said:

    3. Please find the attached wireshark capture. 

    Uboot_2025_wireshark_trace.zip

    Thanks for sharing the wireshark trace. It shows no any network activity after ROM downloaded the bootloader u-boot-spl-restore.bin. It seems the bootloader is not running at all?

    Did you use this same bootloader binary (u-boot-spl-restore.bin) when testing with Linux host as Chencheng reported?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    Yes, it is the same bootloader binary.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    It is interesting that the same bootloader binary runs when downloaded from a Linux host but it doesn't if downloaded from a Windows host.

    Let me try something on the evm to decide how to debug next.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    Is there any update from your side on this?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    When the first bootloader binary (u-boot-spl-restore.bin) is downloaded by ROM and runs, the board UART console should print a message similar to

    U-Boot SPL 2025.01-......

    Do you see any message on your board UART console after u-boot-spl-restore.bin is transferred from the Windows PC?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    Yes, the logs are visible on the UART console. When the module is powered on for the first time, the RNDIS network gets created and the logs appear on the UART console. However, it is not recreated again.

    Flashing_logs.txt 

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Thanks for sharing the board console log. It has the following error messages:

       eth0: usb_etherAll UDCs in use (1 available), use the unbind command

        musb-hdrc: peripheral reset irq lost!
        ...
        The remote end did not respond in time.All UDCs in use (1 available), use the unbind command

    The first line is printed from usb_gadget_probe_driver(), while the last line is printed from usb_eth_start(). Before we dig into it, can you please

    - what is the old U-Boot version before you move to 2025.01? what is the console log when the old version of u-boot-spl-restore.bin was transferred to the board and running?

    - do you have a Beaglebone Black board or any of AM335x EVM so that you can test with your 2025.01 U-Boot to see if u-boot-spl-restore.bin has the same issue?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    Sorry for the late reply. I was on leave yesterday.

    The old U-Boot version is 2013.10, and the logs are attached.

    Flashing_logs_old_Uboot.txt

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Thanks for sharing the console log with u-boot 2013.10.

    Do you have a Beaglebone Black board or any of AM335x EVM so that you can test with your 2025.01 U-Boot to see if u-boot-spl-restore.bin has the same issue?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    I have an AM335x ICEv2 board with me, and I’ll try to verify the issue on it. Could you please let me know if this has already been verified at your end as well? Also, have you come across anything that might explain the difference in behavior between Linux and Windows?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    I haven't tried to verify the issue on my side yet because I didn't even know the symptom until received your log file "Flashing_logs.txt" on May 5th, which shows the USB controller driver behaves abnormally.

    Now I am waiting for your test result on AM335x ICE board, it would determine different debug direction going forward.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi Bin,

    Could you please share the steps to flash the AM335x ICEv2 board so that the debugging process can be sped up?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    I never used the ICE board, but now I just checked the board schematics and found the ICE board doesn't bring out the AM335x USB0 port, so we cannot test Uniflash on the USB interface on the ICE board.

    Can you please get a Beaglebone Black board to test?

    Meanwhile I will talk to our IT department to get Uniflash installed on my Windows laptop so that I can test it on my BBB board as well.

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    I looked at the U-Boot defconfig you provided in your initial issue report above, it has CONFIG_USB_FUNCTION_FASTBOOT=y.

    Can you please disable this CONFIG option to see if Uniflash still fails with the Windows host?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi Bin,

    I checked the legacy OS u-bootv2013 defconfig, and CONFIG_USB_FUNCTION_FASTBOOT=y is already enabled. Flashing is still successful, so I don’t think this is causing the issue. Still, I’ll verify it once from my end.

    Did you get any chance to check the same on BBB board.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Both CONFIG options enable 2 USB gadget drivers, which possibly could cause the "All UDCs in use (1 available)" issue.

    I thought it would be a quick test from your end so I haven't started checking on BBB board yet.

    (Due to TI cooperate IT policy, I would have to request our IT department to get the Uniflash tool installed on my Windows computer, which I would try not to if the CONFIG_USB_FUNCTION_FASTBOOT was the issue. But I will start the request today.)

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi Bin,

    I have disabled this config in U-Boot, but I am still getting the same result.

    CONFIG_USB_FUNCTION_FASTBOOT_flashing_logs.txt

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    I have been trying to replicate the issue on AM335x EVM today, but until now Uniflash on Windows doesn't transmit u-boot-spl-restore.bin yet.

    I will keep you posted on my progress.

  • 0 in reply to Bin Liu
    TI__Guru**** 180346 points

    Hi Pooja,

    I am able to see the problem on AM335x GPEVM with U-Boot 2025.01. The symptom is slightly different from what you reported, but at the end of u-boot-spl-restore.bin, it doesn't generate the USB/RNDIS interface in Windows PC Device Manager, then of cause, u-boot-restore.img is not transmitted by Uniflash.

    I will start to debug the issue, but at the moment I don't know when I will find the root cause.

    I have a thought to unblock your project, since Uniflash only uses u-boot-spl-restore.bin and u-boot-restore.img in USB/RNDIS boot, and both images are only needed for preparing the firmware flashing, they don't go with the AM335x products, can you still use U-Boot 2013.10 to build these two restore binaries and do not update to U-Boot 2025.01? You only update U-Boot 2025.01 in the firmware to be flashed.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    Could you please provide a working setup for this?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Pooja Nagda said:
    Could you please provide a working setup for this?

    Can you please elaborate?

    Since you mentioned the issue doesn't exist in U-Boot 2013.10, I assumed you already have a working Uniflash setup with U-Boot 2013.10.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi Bin,

    When we flash the New OS using the legacy u-boot-spl-restore.bin and u-boot-restore.img, the board crashes with a kernel panic.

    From the flashing logs, we observed that the debrick.scr file is not getting transferred to the module via TFTP. As a result, the recovery flow does not proceed further, and the kernel eventually panics due to the missing initramfs/recovery environment.

    The legacy OS uses an older flashing framework based on:

    • rootfs.tar

    • flasher.sh

    whereas the New OS uses a newer flashing framework based on:

    • debrick.scr

    • initramfs.cpio.gz

    It appears that the legacy u-boot-restore.img does not support this newer flashing framework used in the New OS.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Pooja Nagda said:
    It appears that the legacy u-boot-restore.img does not support this newer flashing framework used in the New OS.

    Can you please explain why would it be?

    The U-Boot restore binaries (u-boot-spl-restore.bin and u-boot-restore.img) just to be downloaded from Uniflash then run BOOTCMD, which does whatever it is programmed to do, I don't see there should be any difference from U-Boot 2013.x and 2025.x.

    I also don't understand why the flashing framework gets changed, it seems to be your development team's decision, not something tied to the U-Boot versions.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    With the latest restore binaries, the RNDIS network is detected successfully during the initial ROM stage (PID_6141), and Windows correctly binds it to the RNDIS network driver. However, once the device transitions to SPL (PID_D022), Windows detects it as a USB Serial Device instead of an RNDIS network adapter because the PID_D022 interface is not automatically recognized or bound to the RNDIS driver.

    While the current flashing flow may still work using legacy restore binaries and temporary host-side workarounds, this approach is not ideal for long-term maintenance. The legacy binaries are based on older infrastructure and do not include many of the modern updates introduced in newer software stacks, including improvements related to 64-bit timestamp handling, file descriptor support, and future security-related enhancements such as secure boot and cryptographic signature verification.

    Additionally, relying on legacy USB gadget behavior and Windows-specific driver binding behavior introduces the risk that future Windows updates may again break the flashing workflow.

    We are therefore looking for a more robust and future-proof recovery/flashing solution instead of continuing to depend on legacy recovery binaries and temporary compatibility workarounds.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Pooja Nagda said:
    However, once the device transitions to SPL (PID_D022), Windows detects it as a USB Serial Device instead of an RNDIS network adapter because the PID_D022 interface is not automatically recognized or bound to the RNDIS driver.

    The response from Mukul on April 24 should fix this problem.

    Mukul Bhatnagar said:

    1. Align the USB Product ID with the ROM Bootloader

    Change your defconfig so SPL uses the same PID as the ROM:

    CONFIG_USB_GADGET_PRODUCT_NUM=0x6141

    This was the confirmed fix for an identical symptom — ROM uses VID_0451&PID_6141, SPL defaults to VID_0451&PID_D022, and Windows refuses to bind the RNDIS driver to the second PID [2].

    Here is the patch:

    diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
    index dc22b1595406..b010affb9d23 100644
    --- a/configs/am335x_evm_defconfig
    +++ b/configs/am335x_evm_defconfig
    @@ -114,7 +114,7 @@ CONFIG_USB_GADGET=y
     CONFIG_SPL_USB_GADGET=y
     CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
     CONFIG_USB_GADGET_VENDOR_NUM=0x0451
    -CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
    +CONFIG_USB_GADGET_PRODUCT_NUM=0x6141
     CONFIG_USB_ETHER=y
     CONFIG_SPL_USB_ETHER=y

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hi Bin,

    Could you please confirm whether the above solution has been verified at your end?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Yes, this patch solves the issue on AM335x GPEVM that Windows enumerates u-boot-spl-restore.bin as a USB serial device.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    There are some findings regarding this workaround from my end. After applying this patch, u-boot-spl-restore.bin gets correctly enumerated as a Linux USB Ethernet/RNDIS Gadget. However, after the SPL stage (initramfs), the PID changes to PID_A4A2_Rev_0612. At this stage, the device is detected as a USB RNDIS Network Device, due to which the flashing process gets stuck.

    To make the flashing process work, I had to manually update the driver so that this revision could bind to the Linux USB Ethernet/RNDIS driver.

    Could you please suggest a final and permanent solution for this issue? Since the current workaround still requires manual driver intervention during the flashing flow, it would be helpful to have a solution where the complete flashing process works seamlessly without requiring any manual configuration or driver updates from the user side.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Pooja Nagda said:
    However, after the SPL stage (initramfs), the PID changes to PID_A4A2_Rev_0612. At this stage,

    Can you please explain when exactly this PID gets changed? for example, which binary is downloaded through Uniflash and executed? SPL should have anything to do with Linux initramfs...

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    This is the flashing flow:

    1. ROM try to establish RNDIS interface
    2. ROM asks for SPL-restore through RNDIS/TFTP and load it
    3. SPL-restore boots and try to establish RNDIS interface
    4. SPL-restore asks for debrick.scr through RNDIS/TFTP and load it
    5. debrick.scr asks for DTB, kernel zImage, initramfs through RNDIS/TFTP and boot them
    6. Once initramfs starts, it does HW formatting, as well as ask for SWU (which includes new u-boot and RFS) through RNDIS/TFTP, and then do the main process of programming the entire board.

    At stage 6, the USB PID changes to A4A2_Rev_0612. At this point, the device is detected as a generic USB RNDIS Network Device, causing the flashing process to get stuck because the correct driver is not automatically bound. To continue the flashing process, the driver had to be manually updated so that this revision could bind to the Linux USB Ethernet/RNDIS driver.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Thanks for the details. Now I understand the behavior.

    The USB PID change of A4A2 is caused by the kernel driver drivers/usb/gadget/legacy/ether.c:

    #define RNDIS_PRODUCT_NUM        0Xa4a2  /* Ethernet/RNDIS Gadget */

    Please change its value to 0x6141 to resolve the issue.

    Pooja Nagda said:
    • SPL-restore boots and try to establish RNDIS interface
    • SPL-restore asks for debrick.scr through RNDIS/TFTP and load it

    By the way, in the procedure you described, did you miss downloading and running u-boot-restore.img after step 3 - running u-boot-spl-restore.bin?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    The USB PID change to A4A2 is not causing the issue; the problem is due to the Rev_0612 value. Because of this revision value, the device is detected as a generic USB RNDIS Network Device, preventing the correct driver from binding automatically and causing the flashing process to get stuck. To proceed with flashing, the driver had to be manually updated so that this revision could bind to the Linux USB Ethernet/RNDIS driver.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    I just realized only changing PID in the kernel ether.c is not sufficient, the VID should be changed to the same value as that in ROM too.

    #define RNDIS_VENDOR_NUM 0x0525 /* NetChip */
    #define RNDIS_PRODUCT_NUM 0xa4a2 /* Ethernet/RNDIS Gadget */

    Please change the code above, PID 0xa4a2 to 0x6141, VID 0x0525 to 0x0451.

    Reference:

    Bin Liu said:
    +++ b/configs/am335x_evm_defconfig
    @@ -114,7 +114,7 @@ CONFIG_USB_GADGET=y
     CONFIG_SPL_USB_GADGET=y
     CONFIG_USB_GADGET_MANUFACTURER="Texas Instruments"
     CONFIG_USB_GADGET_VENDOR_NUM=0x0451
    -CONFIG_USB_GADGET_PRODUCT_NUM=0xd022
    +CONFIG_USB_GADGET_PRODUCT_NUM=0x6141
  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    I compared the ether.c files from the legacy OS and the new OS. In both versions, the RNDIS Vendor ID and Product ID are defined as:

    #define RNDIS_VENDOR_NUM   0x0525
#define RNDIS_PRODUCT_NUM  0xa4a2

    However, when I enumerate the device, I see that the USB device revision differs between the two OS versions.

    Since the VID and PID values are identical in both files, I am trying to understand why the device revision value is changing between the two versions. Could please explain what determines the revision number and why it differs even when the VID and PID remain the same?

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Can you first please confirm if changing the VID:PID in ether.c resolves the boot issue in your project or not?

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    I'll share an update either today or tomorrow.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    Prodigy 180 points

    Hello Bin, 

    Apologies for the delayed response. I was out of office.

    After further investigation, I found that the revision-related issue was specific to my laptop. It was caused by another driver on my system that was interfering with the flashing process and causing it to stall.

    Therefore, there is no need to change the Linux gadget USB VID from 0x0525 to 0x0451 or the PID from 0xA4A2 to 0x6141. Those changes are not required to resolve the flashing issue.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Hi Pooja,

    Glad the issue is finally resolved. Thanks for the update.

    Do you mean only the change VID:PID change in Linux is not required, but the PID change in U-Boot is still required?

    In this entire time debugging the issue, did you test the old version of U-Boot on this same laptop or on a different Windows computer? I am trying to understand why the issue only happened after migrated to the new U-Boot version.

  • 0 in reply to Bin Liu
    Prodigy 180 points

    Hello Bin,

    The U-Boot PID change from CONFIG_USB_GADGET_PRODUCT_NUM=0xD022 to 0x6141 is still required for flashing to work.

    Regards,

    Pooja Nagda

  • 0 in reply to Pooja Nagda
    TI__Guru**** 180346 points

    Thanks for confirming.