[U-Boot] [PATCH 1/1] dwc2 USB controller hangs with lan78xx

[andrew thomas]

On 06/26/2018 05:34 AM, Alexander Graf wrote:
> On 06/21/2018 10:37 AM, Peter Robinson wrote:
>> On Mon, Jun 18, 2018 at 7:56 PM, Andrew Thomas 
>> <andrew.thomas at oracle.com> wrote:
>>> This bug is the combination of dwc2 USB controller and lan78xx
>>> USB ethernet controller, which is the combination in use on
>>> the Raspberry Pi Model 3 B+.
>>>
>>> When the host attempts to receive a packet, but a packet has not
>>> arrived, the lan78xx controller responds by setting BIR
>>> (Bulk-In Empty Response) to NAK. Unfortunately, this hangs
>>> the USB controller and requires the USB controller to
>>> be reset.
>>>
>>> The fix proposed is to have the lan78xx controller respond
>>> by setting BIR to ZLP.
>>>
>>> Signed-off-by: Andrew Thomas <andrew.thomas at oracle.com>
>> Tested-by: Peter Robinson <pbrobinson at gmail.com>
>>
>> Tested on the RPi 3B+ and certainly improves this situation a number
>> of Fedora users have seen.
>
>
> What exactly have you tested?
>
> Even with this patch, I am not reliably to reliably boot into grub.

Can you say which version of grub? I am using the gcdaa64.efi binary in this
RPM:

http://yum.oracle.com/repo/OracleLinux/OL7/latest/aarch64/getPackage/grub2-efi-aa64-cdboot-2.02-0.65.0.8.el7_4.2.aarch64.rpm

The same binary is named EFI/BOOT/grubaa64.efi on the "ISO" CD/DVD
install image -- the point, for me, of getting the lan controller 
"functioning"
is to allow network kickstart install.

I have had a peculiar USB/lan problem with a DVI monitor attached; while 
a different brand
HDMI monitor worked OK.

FWIW: I use fairly recent "firmware":

https://github.com/raspberrypi/firmware
eeaaf5e2b5aee29f31e989c0dddd186fb68b2144

And in the u-boot configuration I have:

CONFIG_OF_BOARD=y
# CONFIG_OF_EMBED is not set

As an aside, I did post [to this list] a related fix ARP for efi 
networking...

> It almost seems as if the packet buffer keeps getting overwritten by 
> newer packets so that by the time we process the old ones, the ones we 
> wanted to see are gone.
>

 From the polling structure of the EFI networking code, it seems
inevitable that some packets would be lost on a busy network??

I have to admit that I had both the Pi and dhcp/tftp server on a
"silent" lan.

I should also mention that while trying to debug this issue, the lan
driver would occasionally receive what appeared to be bogus frames -- 
with packet
sizes which made absolutely no sense as jumbo frames are not enabled
on the switch to which the PI is attached...