Re: keyboard doesn't work at Boot Menu

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.
> 
> 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:
> 
> $ mount | grep msdosfs
> $ /dev/gpt/efiboot0 on /boot/efi (msdosfs, local)
> 
> $ 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 - )
> 
> (./: Can't restore time: Invalid argument
> tar: Error exit delayed from previous errors.
> 
> <cp my config.txt to /boot/efi>
> 
> $ ls -Tld /boot/efi/EFI/*/*
> $ -rwxr-xr-x  1 root  wheel  1182604 Jun 15 04:47:12 2023 /boot/efi/EFI/BOOT/bootaa64.efi
> 
> my config.txt:
> ---
> [all]
> arm_64bit=1
> #dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=disable-bt
> device_tree_address=0x4000
> kernel=u-boot.bin
> 
> [pi4]
> hdmi_safe=0
> armstub=armstub8-gic.bin
> max_framebuffers=2
> hdmi_force_hotplug=1
> hdmi_group=2
> hdmi_drive=2
> hdmi_mode=82
> disable_overscan=1
> # overclock 20210303
> over_voltage=6
> arm_freq=2000
> sdram_freq_min=3200
> force_turbo=1
> ---
> 
> Mark Millard <marklmi@yahoo.com> escreveu no dia sábado, 17/06/2023 à(s) 18:12:
> On Jun 17, 2023, at 08:52, Nuno Teixeira <eduardo@freebsd.org> wrote:
> 
> > Hello Mark!
> 
> Hello  Nuno.
> 
> 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.
> 
> >> It is unclear what the context is here: Serial console? No serial console?
> >> 
> >> What is in /boot/loader.conf ? I've a serial console context and have:
> >> 
> >> boot_multicons="YES"
> >> boot_serial="YES"
> >> 
> > rpi4 connected to monitor via hdmi
> > 
> > /boot/loader.conf:
> > 
> > kern.geom.label.disk_ident.enable="0"
> > kern.geom.label.gptid.enable="0"
> > cryptodev_load="YES"
> > zfs_load="YES"
> >  
> >> Is the stable/13 from a specific *.img* file from the likes of:
> >> 
> >> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/?C=M&O=D
> >> 
> >> ? If yes, which one? If self built, what commit was the build based on?
> >> 
> >> Has this worked for you before? If yes, based on what commit back when
> >> it last worked?
> >> 
> > Instalation is from 13.2-RELEASE and firmware copied from it.
> 
> [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.]
> 
> 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.)
> 
> # ls -Tld /boot/efi/EFI/*/*
> -rwxr-xr-x  1 root  wheel  870956 Jun 13 18:24:42 2023 /boot/efi/EFI/BOOT/bootaa64.efi
> 
> Is your bootaa64.efi the old ones from a 13.2-RELEASE ?
> From a recent stable/13 snapshot? I'll note that:
> 
> loader: comconsole: don't unconditionally wipe out hw.uart.console Kyle Evans 2023-04-26
> 
> would not be in the old 13.2-RELEASE msdosfs file system
> contents.
> 
> 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):
> 
> http://ftp3.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.2/FreeBSD-13.2-STABLE-arm64-aarch64-RPI-20230615-894492f5bf4e-255597.img.xz
> 
> 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.
> 
> > I'm tracking STABLE for some time and I'm at stable/13-n255602-e6c1e181ba7f 
> 
> 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?
> 
> > Since first instalation that keyboard doesn't work in Boot menu.
> 
> Another file that could have relevant content is
> config.txt in the msdosfs.
> 
> >> 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:
> >> 
> >> loader: comconsole: don't unconditionally wipe out hw.uart.console Kyle Evans 2023-04-26
> >> 

===
Mark Millard
marklmi at yahoo.com