TMDSSK3358: Failed to USB boot

Hi Xitong,

The UBoot image I use is the prebuilt from the AM335x Processor SDK for Linux release v7.3.

https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-AM335X/07.03.00.005

You can either download ti-processor-sdk-linux-am335x-evm-07.03.00.005-Linux-x86-Install.bin or am335x-evm-linux-sdk-bin-07.03.00.005.tar.xz (the latter package size is smaller).

The prebuilt U-Boot binaries are under board-support/prebuilt-images/.

xitong zhang said:

By the way, my ROM requires SPL file named "u-boot-spl-restore.bin". Is this difference important?

Actually the SPL filename is NOT hardcoded in ROM, instead it is specified in the dhcpd config file on the host PC (/etc/dhcp/dhcpd.conf on Ubuntu). For example, here is my config, which uses different filenames.

subnet 192.168.3.0 netmask 255.255.255.0 {                                      
  range dynamic-bootp 192.168.3.100 192.168.3.200;                              
                                                                                
  if substring (option vendor-class-identifier, 0, 10) = "AM335x ROM" {         
    filename "u-boot-spl.bin-am335x-evm";                                       
  } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
    filename "u-boot-am335x-evm.img";                                           
  } elsif substring (option vendor-class-identifier, 0, 10) = "AM43xx ROM" {       
    filename "u-boot-spl.bin-am437x-evm";                                       
  } elsif substring (option vendor-class-identifier, 0, 10) = "AM43xx U-B" {       
    filename "u-boot-am437x-evm.img";                                           
  } else {                                                                      
    filename "zImage";                                                          
  }                                                                             
} 

Hi, Mr. Liu

Thank you for your reply. I confirmed that SPL file name is transferred by DHCP Ack message. 

For the config setting above, do you mean you are using a DHCP server from Linux.

But I used CCS Uniflash from Windows10. May be this is the real difference between us?

If a Linux DHCP works, could you tell me some detailed information about what you are using?

For example, is the Linux installed in a PC or a Virtual Machine? version etc. 

Regards.

Hi Xitong,

Yes, my Linux PC provides all the services: dhcp, tftp. This is a dedicated Linux PC (Ubuntu 18.04), not a Linux running in virtual machine.

But I don't think the issue you have is related to the setup on the Windows host. As I recall, your issue is that SPL has been downloaded to the board through Uniflash, but SPL is not enumerated as an USB RNDIS device on Windows host (no new device showing up in Windows Device Manager). If the SPL you used is the prebuilt image from the Processor SDK package or you complied it with am335x_evm_config defconfig, I am not sure what causes the issue.

Hi, Mr. Liu

Thank you for your reply. 

I have got the reason of the problem starting my u-boot-spl.bin and u-boot.bin.

I have two questions.

When I turned on the power, the ROM loader started USB with VID=0x0451, PID=0x6141.

The windows enumerated that USB port as an USB RNDIS device, and the u-boot-spl.bin can be downloaded from CCS Uniflash. (though the name is u-boot-spl-restore.bin) 

But, when u-boot-spl.bin ran, it started a USB with VID=0x0451, PID=0xd022, and the windows can not enumerated that USB port as an USB RNDIS device,
and considered it as only a serial device port. Then I modified the PID from 0xd022 to 0x6141, and rebuilded the SDK.
Then it worked. The u-boot.bin was downloaded through USB port.
I found the definition of PID in an auto generated header, and some original configures. It seems to be defined as 0xd022.

My first question is:

Is my modification (USB PID: 0xd022 -> 0x6141) OK? Why the SDK default configuration for USB PID is different with the ROM loader?

Then the downloaded u-boot.bin is supposed to be run, but nothing happend. it was dead.
The reason is that, the download address is defined as 0x82000000, but the u-boot.bin start address is defined as 0x80800000 in SDK.
Then I modified load address setting to 0x80800000, and it worked OK. I came to the console. 

My second question is:

Is my modification (load addr: 0x82000000 -> 0x80800000) OK? Why the SDK default configuration for u-boot.bin load address is different with start address?

By the way, I realized that your load address is showed as 0x82000000, how can your u-boot.bin run correctly?

Hi Mr. Liu
For the second question, I have got the point that (load addr: 0x82000000 -> 0x80800000) modification is not good.
Thank you for your help.

Regards.