[raspberrypi-bootloader 20190904] Rpi3 broken ethernet interface

[cody-rocker]

Describe the bug
raspberrypi-bootloader 20190904 (commit: e2e17cd)
Sets ethernet adapter MAC address to 00:00:00:00:00:00. eth0 interface cannot be brought up without manually setting a valid MAC.

To reproduce
Install/update raspberrypi-bootloader 20190904.

Expected behaviour
Working network devices.

Actual behaviour
Broken ethernet device.

System
Pi3B+ (aarch64 5.2.11-1-ARCH)

Logs
Output of ip link:
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Context
https://archlinuxarm.org/forum/viewtopic.php?t=13953&p=62093

[lilyanatia]

I got that at first with 20190904 on my Pi3 running Arch, but when I started trying to narrow down which commit broke it, it started working and I haven't had any ethernet problems since then on 20190904 or the current 20190909.

[pelwell]

20190904 does modify the loading logic - the order of file loading and some addresses have changed. Can someone post the content of config.txt from a broken Arch system (or a working one if it is the same?

[ilyxa]

Confirmed, boot broken (set MAC to zero values).

[ilyxa]

nothing specific (ArchLinuxArm):
enable_uart=1
gpu_mem=16

[pelwell]

What does "sudo vcdbg log msg" report?

[ilyxa]

While booting, normal boot:
[ 0.000000] Kernel command line: console=ttyS1,115200 console=tty0 root=PARTUUID=372fff38-02 rw rootwait smsc95xx.macaddr=b8:27:eb:b5:b6:a2
Wrong boot:
[ 0.000000] Kernel command line: console=ttyS1,115200 console=tty0 root=PARTUUID=372fff38-02 rw rootwait smsc95xx.macaddr=00:00:00:00:00:00

There is no complete vc userspace on aarch64, only part of it, sorry...

[cody-rocker]

default /boot/config.txt
enable_uart=1

The config does not change between working/broken versions on my system.

Also, tried 20190909 (kernel aarch64 5.2.13-1-ARCH), problem still persists (for me) on that revision as well. Downgrading to 20190828 (most recent working package in my cache), or running a post-boot shell script to manually configure the eth0 interface resolves the issues.

[ilyxa]

post-boot shell script to manually configure the eth0 interface resolves the issues

which one? I'll can do some kind of mac spoofing, it's not a problem.

[cody-rocker]

which one? I'll can do some kind of mac spoofing, it's not a problem.

#!/bin/sh

HW_ADDR=b8:27:eb:ce:cb:c6

ip link set eth0 down
ip link set eth0 address $HW_ADDR
ip link set eth0 up

is the script I'm using (with sudo) to get the network up while testing these packages.

[pelwell]

If you have a serial port connected, try with dtoverlay=disable-bt and uart_2ndstage=1.

[ilyxa]

#!/bin/sh

got it, i'll did with systemd-networkd via link file.

[ilyxa]

dtoverlay=disable-bt
unavail on aarch64

uart_2ndstage=1
same result:
[ 0.000000] Kernel command line: console=ttyS1,115200 console=tty0 root=PARTUUID=372fff38-02 rw rootwait smsc95xx.macaddr=00:00:00:00:00:00

${usbethaddr} lost somewhere...

[pelwell]

dtoverlay=disable-bt
unavail on aarch64

You should have pi3-disable-bt instead.

same result:

You've missed the point, which is to learn more about the failure before trying to fix it. If you had a serial port connected then the commands I mentioned would output messages from the firmware to any connected terminal app.

[ilyxa]

Only hdmi console right now...

[ilyxa]

What I try:

• stop u-boot (press any key...)
• printenv on "normal" firmware - usbethaddr was filled;
• printenv on commit 3bba190 - usbethaddr zeroed;

I'll try to get console access to rpi, but there is zero information before u-boot started (as I expect).

[ilyxa]

Adding

setenv usbethaddr B8:27:EB:B5:B6:A2

into /boot/boot.txt also work (this distro specific, not the root cause).

[hayatofujii]

If you have a serial port connected, try with dtoverlay=disable-bt and uart_2ndstage=1.
You should have pi3-disable-bt instead.

https://gist.github.com/hayatofujii/a17bf0401e7d15565cb76bdcb98f7c06
Lemme know if you need of anything else.

$ uname -a
Linux raspberry 5.2.14-1-ARCH #1 SMP Thu Sep 12 16:03:57 UTC 2019 aarch64 GNU/Linux

Using raspberrypi-bootloader-20190909 on a Raspberry Pi 3B.

[pelwell]

Thanks - that confirms a suspicion I had. Can you see if this test firmware (just start.elf and fixup.dat) fixes the issue?

https://drive.google.com/file/d/1c979p43rBjC8hZe8d0-WNp1iwzsk1-s8/view?usp=sharing

[pelwell]

A firmware containing this fix is now in this repo and available via rpi-update.

[hayatofujii]

Thanks - that confirms a suspicion I had. Can you see if this test firmware (just start.elf and fixup.dat) fixes the issue?

https://drive.google.com/file/d/1c979p43rBjC8hZe8d0-WNp1iwzsk1-s8/view?usp=sharing

Just for sake of completeness, yes, the test firmware works, albeit I can't see why based only on the bootlog.
https://gist.github.com/hayatofujii/3b6bb37c38575895eed69d72d408d152

Edit: Ok, DT wasn't being loaded.

[pelwell]

The clue was the line Failed to load Device Tree file '?' - something you would never see on Raspbian unless you hacked it about. I found a bug in the command line processing in the event that no DTB was loaded, which was then fixed by firmware: arm_loader: Fix no-DT and upstream handling.

[cody-rocker]

A firmware containing this fix is now in this repo and available via rpi-update.

raspberrypi-bootloader 20190914 resolves these issues. Everything is now working as expected.

[somini]

raspberrypi-bootloader 20190914 resolves these issues. Everything is now working as expected.

Many thanks, can confirm.