• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 2024 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM3358: USB boot fails

kmorrow
Prodigy 60 points
Part Number: AM3358
Other Parts Discussed in Thread: AM3352

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

  • 0
    TI__Guru**** 393215 points
    Please post the USB part of your schematic. FYI BeagleBone Green Wireless is a third-party product and is not supported by TI.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 60 points

    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). 

  • 0 in reply to kmorrow
    TI__Guru**** 393215 points
    I have notified the USB experts. They will respond here.
  • 0
    TI__Guru*** 125596 points

    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 said:

    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?

  • 0 in reply to Bin Liu
    Prodigy 60 points

    Bin Liu said:

    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.


    Good catch, I had not noticed that. I removed the /var/lib/dhcp/dhcpd.leases file and this allows me to boot off of the other boards. I have to remove the file each time I change boards, or it will continue to send the response to the wrong MAC address. The log from isc-dhcp-server is equally puzzling:
    $ sudo service isc-dhcp-server status
● isc-dhcp-server.service - ISC DHCP IPv4 server
   Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2017-05-19 14:19:13 PDT; 1min 50s ago
     Docs: man:dhcpd(8)
 Main PID: 27985 (dhcpd)
    Tasks: 1
   Memory: 9.8M
      CPU: 10ms
   CGroup: /system.slice/isc-dhcp-server.service
           └─27985 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf

May 19 14:19:43 jeb dhcpd[27985]: BOOTREPLY on 172.16.1.100 to 68:c9:0b:7c:f8:ef via enp0s20u2
May 19 14:20:03 jeb dhcpd[27985]: reuse_lease: lease age 331 (secs) under 25% threshold, reply with unaltered, existing lease
May 19 14:20:03 jeb dhcpd[27985]: BOOTREQUEST from c8:a0:30:b9:a3:4f via enp0s20u2
May 19 14:20:03 jeb dhcpd[27985]: BOOTREPLY on 172.16.1.100 to 68:c9:0b:7c:f8:ef via enp0s20u2
May 19 14:20:26 jeb dhcpd[27985]: reuse_lease: lease age 354 (secs) under 25% threshold, reply with unaltered, existing lease
May 19 14:20:26 jeb dhcpd[27985]: BOOTREQUEST from c8:a0:30:b9:a3:4f via enp0s20u2
May 19 14:20:26 jeb dhcpd[27985]: BOOTREPLY on 172.16.1.100 to 68:c9:0b:7c:f8:ef via enp0s20u2
May 19 14:20:53 jeb dhcpd[27985]: reuse_lease: lease age 381 (secs) under 25% threshold, reply with unaltered, existing lease
May 19 14:20:53 jeb dhcpd[27985]: BOOTREQUEST from c8:a0:30:b9:a3:4f via enp0s20u2
May 19 14:20:53 jeb dhcpd[27985]: BOOTREPLY on 172.16.1.100 to 68:c9:0b:7c:f8:ef via enp0s20u2

    Bin Liu said:

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

    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