From nobody Thu Dec 29 20:51:17 2022 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NjgXn5Xh2z2lDqM for ; Thu, 29 Dec 2022 20:51:21 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4NjgXn3Q0cz3k2Q for ; Thu, 29 Dec 2022 20:51:21 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.16.1/8.16.1) with ESMTP id 2BTKpKbJ072678; Thu, 29 Dec 2022 14:51:20 -0600 (CST) (envelope-from mike@karels.net) Received: from [10.0.2.10] ([10.0.1.1]) by mail.karels.net with ESMTPSA id nj34DMj9rWPkGwEA4+wvSQ (envelope-from ); Thu, 29 Dec 2022 14:51:20 -0600 From: "Mike Karels" To: "Mark Millard" Cc: "Bjoern A. Zeeb" , freebsd-arm Subject: Re: rpi3b+ ue0 too late to be configured on boot? Date: Thu, 29 Dec 2022 14:51:17 -0600 X-Mailer: MailMate (1.13.2r5673) Message-ID: 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> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.karels.net id 2BTKpKbJ072678 X-Rspamd-Queue-Id: 4NjgXn3Q0cz3k2Q X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 29 Dec 2022, at 14:38, Mark Millard wrote: > On Dec 29, 2022, at 11:39, Mike Karels 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=20 >>> at >>> least it looks like)? >> >> 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=20 >> 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=3Doff". > END QUOTE > >> I did have problems with the HDMI console, some of which are new; I=20 >> will >> follow up on that separately. Specifically, USB keyboard input=20 >> 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. >> >> Mike >> >>> While during boot USB seems to need a wait-delay now, which it=20 >>> hadn't in >>> the last years for me? >>> >>> ---------------------------------------------------------------------= --- >>> ... >>> Feeding entropy: . >>> ELF ldconfig path: /lib /usr/lib >>> ugen1.2: at usbus1 >>> uhub1 on uhub0 >>> uhub1: >> 2> on usbus1 >>> uhub1: MTT enabled >>> lo0: link state changed to UP >>> uhub1: 5 ports with 4 removable, self powered >>> ugen1.3: at usbus1 >>> smsc0 on uhub1 >>> smsc0: on=20 >>> usbus1 >>> smsc0: chip 0xec00, rev. 0002 >>> miibus0: on smsc0 >>> smscphy0: PHY 1 on miibus0 >>> smscphy0: OUI 0x00800f, model 0x000c, rev. 3 >>> smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>> ue0: on smsc0 >>> ue0: bpf attached >>> ue0: Ethernet address: xx:xx:xx:xx:xx:xx >>> Starting Network: lo0. >>> lo0: flags=3D8049 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=3D8843 metric 0 mt= u=20 >>> 1500 >>> ... >>> >>> >>> >>> Not that it should matter - this is with=20 >>> https://github.com/pftf/RPi3/releases/tag/v1.38 >>> >>> /bz >>> >>> --=20 >>> Bjoern A. Zeeb =20 >>> r15:7 >> > > =3D=3D=3D > Mark Millard > marklmi at yahoo.com