Date: Sat, 17 Jun 2023 12:46:31 -0700 From: Mark Millard <marklmi@yahoo.com> To: Nuno Teixeira <eduardo@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: keyboard doesn't work at Boot Menu Message-ID: <C3CF38DD-A4F9-430F-9FD4-8BA6E5FCB2EA@yahoo.com> In-Reply-To: <CAFDf7UKZmZZS6aKf=43-A_2eXDHq3%2BPcC3Hqbp1s7umrcJDA_g@mail.gmail.com> References: <CAFDf7ULWff1YNA675-0ZdSgRM-t6RnCHO9RSTshPS0k8xfc6xw@mail.gmail.com> <99542360-6350-4636-A9EA-CA9BBCC93C60@yahoo.com> <CAFDf7U%2B3NR8ETaxg2W9j%2BXkm-sNaCdFSCXNMLA_GmxnRayeZuQ@mail.gmail.com> <5D8D94E2-781D-4945-B721-EDD0BF56A8F2@yahoo.com> <CAFDf7UKZmZZS6aKf=43-A_2eXDHq3%2BPcC3Hqbp1s7umrcJDA_g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 17, 2023, at 12:19, Nuno Teixeira <eduardo@freebsd.org> wrote: > I've tryed to boot = FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img = but it doesn't boot. > Same error as I replace /boot/efi from stable. >=20 > I sent an photo. It is missing the history needed to see the original problem. But I've a serial console to get teh full text from. I've just tried the snapshot and it shows that the U-Boot it has is from a problematical version for 8 GiByet RPi4B's (a known historical issue): . . . U-Boot 2023.01 (Jun 15 2023 - 02:43:21 +0000) DRAM: 947 MiB (effective 7.9 GiB) RPI 4 Model B (0xd03115) . . . No EFI system partition BootOrder not defined EFI boot manager: Cannot load any image Found EFI removable media binary efi/boot/bootaa64.efi ** Reading file would overwrite reserved memory ** Failed to load 'efi/boot/bootaa64.efi' No UEFI binary known at 0x00080000 . . . The text "Reading file would overwrite reserved memory" is an known misnomer for what is actually happening in that U-Boot. The internal error code need not be indicating what is reported. # strings /mnt/u-boot.bin | grep "U-Boot 20" U-Boot 2023.01 (Jun 15 2023 - 02:43:21 +0000) systutils/u-boot-rpi-arm64 has not progressed to 2023.04 that has this fixed. So the snapshots are still being generated in a messed up state for 8 GiByte RPi4B's. Substituting the 13.2-RELEASE u-boot.bin into the msdosfs should get rid of this problem. I will be doing something analogous to continue my boot test. > Procedure: >=20 > $ mount | grep msdosfs > $ /dev/gpt/efiboot0 on /boot/efi (msdosfs, local) >=20 > $ mdconfig -t vnode -f = FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img > $ mount -t msdosfs /dev/md0s1 /mnt > <backup and clean /boot/efi> > $ cd /mnt > $ tar cf - . | ( cd /boot/efi && tar xvf - ) >=20 > (./: Can't restore time: Invalid argument > tar: Error exit delayed from previous errors. >=20 > <cp my config.txt to /boot/efi> >=20 > $ ls -Tld /boot/efi/EFI/*/* > $ -rwxr-xr-x 1 root wheel 1182604 Jun 15 04:47:12 2023 = /boot/efi/EFI/BOOT/bootaa64.efi >=20 > my config.txt: > --- > [all] > arm_64bit=3D1 > #dtparam=3Daudio=3Don,i2c_arm=3Don,spi=3Don > dtoverlay=3Dmmc > dtoverlay=3Ddisable-bt > device_tree_address=3D0x4000 > kernel=3Du-boot.bin >=20 > [pi4] > hdmi_safe=3D0 > armstub=3Darmstub8-gic.bin > max_framebuffers=3D2 > hdmi_force_hotplug=3D1 > hdmi_group=3D2 > hdmi_drive=3D2 > hdmi_mode=3D82 > disable_overscan=3D1 > # overclock 20210303 > over_voltage=3D6 > arm_freq=3D2000 > sdram_freq_min=3D3200 > force_turbo=3D1 > --- >=20 > Mark Millard <marklmi@yahoo.com> escreveu no dia s=C3=A1bado, = 17/06/2023 =C3=A0(s) 18:12: > On Jun 17, 2023, at 08:52, Nuno Teixeira <eduardo@freebsd.org> wrote: >=20 > > Hello Mark! >=20 > Hello Nuno. >=20 > FYI: My example paths and such are from my main instead of a > stable/13 context. I may set up a stable/13 snapshot to better > match your context at some point, but not yet. >=20 > >> It is unclear what the context is here: Serial console? No serial = console? > >>=20 > >> What is in /boot/loader.conf ? I've a serial console context and = have: > >>=20 > >> boot_multicons=3D"YES" > >> boot_serial=3D"YES" > >>=20 > > rpi4 connected to monitor via hdmi > >=20 > > /boot/loader.conf: > >=20 > > kern.geom.label.disk_ident.enable=3D"0" > > kern.geom.label.gptid.enable=3D"0" > > cryptodev_load=3D"YES" > > zfs_load=3D"YES" > > =20 > >> Is the stable/13 from a specific *.img* file from the likes of: > >>=20 > >> = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/?C=3DM&O=3DD= > >>=20 > >> ? If yes, which one? If self built, what commit was the build based = on? > >>=20 > >> Has this worked for you before? If yes, based on what commit back = when > >> it last worked? > >>=20 > > Instalation is from 13.2-RELEASE and firmware copied from it. >=20 > [Note: main has /boot/efi/ as a mount point for the msdosfs. > Your stable/13 my still have /boot/msdos/ instead. That might > even depend on the details of how and when the configuration > was set up. The efi directory in the msdosfs may be named EFI > or named efi as well. I show/use EFI to make the name distinct > from main's mount point name, making references clear about > which.] >=20 > The following are from in the msdosfs file system but are > not from sysutils/rpi-firmware or from > sysutils/u-boot-rpi-arm64 . (The detailed content, size, > date, and such will not match any stable/13 details here.) >=20 > # ls -Tld /boot/efi/EFI/*/* > -rwxr-xr-x 1 root wheel 870956 Jun 13 18:24:42 2023 = /boot/efi/EFI/BOOT/bootaa64.efi >=20 > Is your bootaa64.efi the old ones from a 13.2-RELEASE ? > =46rom a recent stable/13 snapshot? I'll note that: >=20 > loader: comconsole: don't unconditionally wipe out hw.uart.console = Kyle Evans 2023-04-26 >=20 > would not be in the old 13.2-RELEASE msdosfs file system > contents. >=20 > In general, you may want to update to be using msdosfs > content from, say, the most recent stable/13 snaphot > (preserving any adjustments that you have been making > to config.txt or the like): >=20 > = http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2= -STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img.xz >=20 > But, I'll note that updating BOOT/bootaa64.efi can be > done just by copying /boot/loader.efi to > BOOT/bootaa64.efi in the msdosfs. >=20 > > I'm tracking STABLE for some time and I'm at = stable/13-n255602-e6c1e181ba7f=20 >=20 > The snapshots contain things in final places that are not > in those places just by FreeBSD installation or > installation of ports. Have you been updating bootaa64.efi > by copying /boot/loader.efi to BOOT/bootaa64.efi in the > msdosfs? >=20 > > Since first instalation that keyboard doesn't work in Boot menu. >=20 > Another file that could have relevant content is > config.txt in the msdosfs. >=20 > >> Note: Warner's recent changes to stand/ for the subject area are = only > >> in main [so: 14] so far. So it appears that the only fairly recent > >> change for such for stable/13 has been: > >>=20 > >> loader: comconsole: don't unconditionally wipe out hw.uart.console = Kyle Evans 2023-04-26 > >>=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?C3CF38DD-A4F9-430F-9FD4-8BA6E5FCB2EA>