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.

AM335x: USB boot problems

We have a new AM335x board that we are trying to get up and running via a USB boot. It is very closely based on another board we have produced that works fine with USB boot.

Symptoms are:

1. Board sends the DHCP request to the host over the USB RNDIS interface fine (wireshark).

2. DHCP server returns what looks to be a valid DHCP reply.

3. No further IP packets from board untill it retries the DHCP. Our older board does an ARP request followed by TFTP.

4. Older board works fine on this identical setup.

5. The new board can be booted over its Ethernet interface and runs fine.

6. Once the board is up and running Linux we can load the g_ether driver and ping over the USB RNDIS interface fine, and all works fine with no packet errors.

7. No error messages from the Linux kernels on the host or AM335x systems.

Seems very strange, any ideas ?

I guess there could be some funny USB link issue so the AM335x is not receiving the DHCP reply properly or has there been some change in the BOOT ROM code ?

  • Terry,

    No...no changes to the ROM. Any chance you could get a USB protocol analyzer trace of the boot process?

  • Also, please try longer/shorter/different cables to see if perhaps this impacts the test result.
  • Unfortunately we don't have a USB protocol analyser available. I could put a digital scope on it and do a rough compare between the two boards. Will try that tomorrow.
  • Thanks for the replies.
    I will try different cables tomorrow as well. It is using a very short cable at the moment...
  • Hi, I have found the problem.
    Our older AM335x based board uses 1c:ba:8c:a8:38:24 as its USB RNDIS MAC address.
    Our new AM335x based board uses 1c:ba:8c:90:5c:53 as its USB RNDIS MAC address.
    I assume these are hard coded and the difference is due to a ROM code change ?

    Now there appears to be a problem with our DHCP server config or a bug in the DHCP server we are using.
    On the BOOTREQUEST's from 1c:ba:8c:90:5c:53 it returns the BOOTREPLY to 1c:ba:8c:a8:38:24 incorrectly.
    There is a DHCP lease for 1c:ba:8c:a8:38:24 as we booted the older board first, why this is being chosen for the new board is a question. It does have "vendor-class-identifier = "AM335x ROM";" set. Clearing the entries in the leases file (/var/lib/dhcp/dhcpd.leases) temporarily fixes the problem.
    Now I have to find out why the DHCP server is doing this. It is the default DHCP server used in Fedora 23 and is version 4.3.3.
  • Hi Terry,

    What are the revisions of the old/news chips you are referring to?

  • I'm referring to our old design and new design boards not chips. The CPU's should be the same, the ones used are marked:
    Our old designed board has CPU's marked: AM3358BZCZ100, 36APYGW G1, 962B ZCZ.
    Our new designed board has CPU's marked: AM3358BZCZ100, 35C6QEW G1, 962B ZCZ.
    Only difference we can see is the allocated USB RNDIS MAC address. I don't know where this comes from, I assume it is hard coded in the ROM code.
    As stated this should not be a problem, but is in our case at the moment due to an incorrect DHCP config or a bug in the DHCP server which I have to track down.