Date: Thu, 29 Dec 2022 13:01:15 -0800 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Subject: Re: rpi3b+ ue0 too late to be configured on boot? Message-ID: <9254A30E-B974-4DFD-B428-D1037BDDF1AB@yahoo.com> In-Reply-To: <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com> References: <8srop579-r4sq-278-356p-nr7q81n31s4@mnoonqbm.arg> <52FD04A5-27B4-4C61-9C97-795D2D65135E@karels.net> <09EDBF79-75B7-486E-AE85-07E6FFA2FED3@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 29, 2022, at 12:38, Mark Millard <marklmi@yahoo.com> wrote: > On Dec 29, 2022, at 11:39, Mike Karels <mike@karels.net> wrote: >=20 >> On 28 Dec 2022, at 16:42, Bjoern A. Zeeb wrote: >>=20 >>> Hi, >>>=20 >>> 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)? >>=20 >> I don=E2=80=99t 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. >=20 > Are you also using EDK2's UEFI via the boot materials from: >=20 > https://github.com/pftf/RPi3/releases/tag/v1.38 >=20 > 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. >=20 > Bjoern did not report enough information for the configuration > of that EDK2 based context to replicate his boot context in a > test. >=20 > 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: >=20 > 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=3Doff". > END QUOTE >=20 I found the text about not being ACPI compliant: = https://github.com/tianocore/edk2-platforms/tree/master/Platform/Raspberry= Pi/RPi3 reports: QUOTE ACPI . . . Note that the ACPI tables were derived or copied from the MS-IoT one. This means that they are not truly ACPI compliant, especially when it comes to their descriptors, and therefore not suitable for Linux environments. If you want to use a Linux HLOS, you are encouraged tp install a kernel that relies on Device Tree rather than ACPI. 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=E2=80=99t >> work to the loader, and I didn=E2=80=99t see console output from = user-level >> startup until I disabled boot_multicons and boot_serial. The second >> problem is relatively new. >>=20 >> Mike >>=20 >>> While during boot USB seems to need a wait-delay now, which it = hadn't in >>> the last years for me? >>>=20 >>> = ------------------------------------------------------------------------ >>> ... >>> 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=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 >>> ... >>> = ------------------------------------------------------------------------ >>>=20 >>> If running manually after boot (again) it all works fine? >>>=20 >>> # sh /etc/rc.d/netif start ue0 >>> smsc0: chip 0xec00, rev. 0002 >>> Starting Network: ue0. >>> ue0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 = mtu 1500 >>> ... >>>=20 >>>=20 >>>=20 >>> Not that it should matter - this is with = https://github.com/pftf/RPi3/releases/tag/v1.38 >>>=20 >>> /bz >>>=20 >>> --=20 >>> Bjoern A. Zeeb = r15:7 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9254A30E-B974-4DFD-B428-D1037BDDF1AB>