AM3358: USB boot fails

Part Number: AM3358

I've been trying to set up my Ubuntu 16.04 machine with the appropriate servers to allow AM335x devices to boot of of the USB interface. I'm working off of the configuration that Bin Liu posted here:

https://e2e.ti.com/support/arm/sitara_arm/f/791/p/284639/992880#992880

I've gotten the BeagleBone Black to work, but have had issues with the BeagleBone Green Wireless and some custom hardware using the AM3352/AM3358. I can successfully boot all of the boards of of the USB interface using a different machine, but am unable to run wiretrace or netcat on that system. If I load the SPL image using another protocol then there is no problem - U-Boot is able to read the BOOTP server and pull images through TFTP with no problem.

Board BeagleBone Black BeagleBone Green Wireless Custom Board 1 Custom Board 2
Processor AM3359A AM3358B AM3352B AM3358B
Able to boot off of ? Yes No No No

I ran some wireshark captures, and I see no difference in the packets that are sent to the working/non-working devices. I don't have any more hardware using the rev 2.1 silicon in order to test with, but am wondering if there may be some change in the required BOOTP parameters.

As far as I can tell, I'm sending all the required parameters in the BOOTP reply that is recieved. From section 26.1.9.4.2 of the TRM:

  • Device IP address from “yiaddr” field
  • Subnetmask from extended option 1 (RFC 1497, RFC 1533)
  • Gateway IP from extended option number 3 (RFC 1497, RFC 1533) or from “giaddr” field of BOOTP response.
  • Boot image filename from “file” field • TFTP server IP address from the “siaddr” field

Here are some .pcapng files that show the relevant traffic. The device makes a BOOTP request and receives a reply in both cases, but with the Rev2.1 silicon it seems like we don't see a reply. You will need Wireshark or similar to open these files.

pcaps.zip

Thanks!

--Keegan

  • Please post the USB part of your schematic. FYI BeagleBone Green Wireless is a third-party product and is not supported by TI.
    Best Regards
    Biser

    Note:  If this answer solves your question please click the "Verify Answer"  button.

  • In reply to Biser Gatchev-XID:

    Thanks Biser,

    Unfortunately I can't post any of our schematic, but I've attached some screenshots comparing the BeagleBone Black and BeagleBone Green schematics.

    There are some minor differences: A capacitor voltage changes, and the ESD diodes are discreet diodes on the Green, but nothing that I would expect to cause this issue.

    BeagleBone Black processor connections:

     

    BeagleBone Green Wireless Processor Connections:

    BeagleBone Black USB connector:

    BeagleBone Green USB connector:

    To give you at least some idea of what our design looks like: it is very much like that of the BeagleBone Black, with the addition of a switch to provide a voltage to VBUS for USB OTG support.

    I am aware of usage note 3.1.3 "Boot: USB Boot ROM Code Uses Default DATAPOLARITY".

    I don't believe that there should be anything wrong with our physical USB connections based on the following:

    • The devices are all enumerating as RNDIS devices without problems. We can see all of the devices send a BOOTP request using the Wireshark.
    • We've done extensive testing using the Linux RNDIS drivers to copy files to/from our devices using our design
    • We've been using this USB boot mode to program devices using for quite some time.

    It seems to me that the problem we are seeing is that the ROM code isn't liking the response from the BOOTP server for some reason. I'm not sure if there is something missing in the packet that the ROM code expects v2.1 ROM code expects (and the v2.0 does not), or if the packet contents aren't quite right (in some subtle way that I wasn't able to spot). 

  • In reply to kmorrow:

    I have notified the USB experts. They will respond here.
    Best Regards
    Biser

    Note:  If this answer solves your question please click the "Verify Answer"  button.

  • Keegan,

    Look at the wireshark trace for the Green, the Dst address of BOOTP Reply is not the Src of BOOTP Request from the Green, but the Black, so the server doesn't reply to the Green board but to the Black board, so the Green board keeps sending the BOOTP Requests. I am not sure why this happens though.

    kmorrow

    I've been trying to set up my Ubuntu 16.04 machine with the appropriate servers to allow AM335x devices to boot of of the USB interface. 

    [...]

    I've gotten the BeagleBone Black to work, but have had issues with the BeagleBone Green Wireless and some custom hardware using the AM3352/AM3358. I can successfully boot all of the boards of of the USB interface using a different machine, but am unable to run wiretrace or netcat on that system.

    Do you mean you can get the USB Boot working with a different machine but not with the Ubuntu 16.04?

  • In reply to Bin Liu:

    Bin Liu

    Keegan,

    Look at the wireshark trace for the Green, the Dst address of BOOTP Reply is not the Src of BOOTP Request from the Green, but the Black, so the server doesn't reply to the Green board but to the Black board, so the Green board keeps sending the BOOTP Requests. I am not sure why this happens though.

    Yes, I have booted the same hardware off of an OpenSUSE 13.1 machine in the past and did not experience this issue. I'm not sure the version of the isc dhcp server that machine was using, but I am using isc-dhcpd-4.3.3 on the Ubuntu machine.

    Thanks for the help!

    --Keegan