Re: rpi3b+ ue0 too late to be configured on boot?

On Dec 29, 2022, at 11:39, Mike Karels <mike@karels.net> wrote:

> On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote:
> 
>> Hi,
>> 
>> does anyone else have the problem on latest main that the ue0 on an
>> rpi3b+ doesn't show up in time for the rc netif to configure it (or at
>> least it looks like)?
> 
> I don’t see that problem.  I tried the 12/24 snapshot of main on an
> RPi3B+, and ue0 configured via DHCP on the initial boot, and on a reboot.

Are you also using EDK2's UEFI via the boot materials from:

https://github.com/pftf/RPi3/releases/tag/v1.38

instead of the using the normal FreeBSD ports used in official
builds (the RPi firmware and a U-Boot)? The "pfpt" RPi3 materials
include both RPi* firmware and the EDK2 based material.

Bjoern did not report enough information for the configuration
of that EDK2 based context to replicate his boot context in a
test.

I'll note that the intructions for that EDK2 variant indicate
that linux should not use ACPI but instead should use the
Device Tree. As I remember, the ACPI is documented somewhere
to follow some non-standard Microsoft specifics. (The RPi4
"pfpt" does not have the same issue.) Some related quotes
from https://github.com/pftf/RPi3 are:

QUOTE
With recent Linux installs, please assure that the
firmware is running in DT mode, either via
"Device Manager"->"Raspberry Pi Configuration"
->"Advanced Configuration"->"System Table Selection"
or the Linux/Grub command line with "acpi=off".
END QUOTE

> I did have problems with the HDMI console, some of which are new; I will
> follow up on that separately.  Specifically, USB keyboard input didn’t
> work to the loader, and I didn’t see console output from user-level
> startup until I disabled boot_multicons and boot_serial.  The second
> problem is relatively new.
> 
> Mike
> 
>> While during boot USB seems to need a wait-delay now, which it hadn't in
>> the last years for me?
>> 
>> ------------------------------------------------------------------------
>> ...
>> Feeding entropy: .
>> ELF ldconfig path: /lib /usr/lib
>> ugen1.2: <vendor 0x0424 product 0x9514> at usbus1
>> uhub1 on uhub0
>> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr 2> on usbus1
>> uhub1: MTT enabled
>> lo0: link state changed to UP
>> uhub1: 5 ports with 4 removable, self powered
>> ugen1.3: <vendor 0x0424 product 0xec00> at usbus1
>> smsc0 on uhub1
>> smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus1
>> smsc0: chip 0xec00, rev. 0002
>> miibus0: <MII bus> on smsc0
>> smscphy0: <SMC LAN8700 10/100 interface> PHY 1 on miibus0
>> smscphy0: OUI 0x00800f, model 0x000c, rev. 3
>> smscphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>> ue0: <USB Ethernet> on smsc0
>> ue0: bpf attached
>> ue0: Ethernet address: xx:xx:xx:xx:xx:xx
>> Starting Network: lo0.
>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>> ...
>> ------------------------------------------------------------------------
>> 
>> If running manually after boot (again) it all works fine?
>> 
>> # sh /etc/rc.d/netif start ue0
>> smsc0: chip 0xec00, rev. 0002
>> Starting Network: ue0.
>> ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>> ...
>> 
>> 
>> 
>> Not that it should matter - this is with https://github.com/pftf/RPi3/releases/tag/v1.38
>> 
>> /bz
>> 
>> -- 
>> Bjoern A. Zeeb                                                     r15:7
> 

===
Mark Millard
marklmi at yahoo.com