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

On 29 Dec 2022, at 14:38, Mark Millard wrote:

> On Dec 29, 2022, at 11:39, Mike Karels <[email protected]> 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.

No, this was the unmodified snapshot with the standard boot files
(and thus not UEFI).

		Mike

> 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