Re: https://github.com/pftf/RPi4 unusable for FreeBSD since at least Sept 2023

On Jan 19, 2024, at 06:33, void <void@f-m.fm> wrote:

> Booting stops with the error "armv8crypto0: CPU lacks AES instructions"
> 
> see https://github.com/pftf/RPi4/issues/242
> 
> I can confirm v1.35 throws this error but haven't tested either earlier
> or non-release versions. This version was released on the 5th June 2023
> and is the latest -release version. The PR was generated in September.
> 
> When the arm64-rpi image is generated, what content does it source for
> the efi part? When does it get sourced?
> 
> Is it a pftf/RPi4 problem or a freebsd one?
> 
> (possibly related - i was unable to get 14-stable installed via the usual method:
> 
> 1. install to usb3 then leave the mmcsd in and reboot
> 2. it fails to boot to usb. log in and mount the usb3 msdos    partition on /mnt and cp -a /boot/efi [?] to /mnt then reboot
> [?] i forget the actual path - it's whatevr gets mounted as the msdos
> partition on the mmcsd).
> 

"armv8crypto0: CPU lacks AES instructions" is not a fatal error
but just informational. Here is part of a "dmesg -a" from  an
RPi3B boot using the normal U-Boot style:

gpioled0: <GPIO LEDs> on ofwbus0
gpioled0: <ACT> failed to map pin
armv8crypto0: CPU lacks AES instructions
Timecounters tick every 1.000 msec
usbus1: 480Mbps High Speed USB v2.0
ugen1.1: <DWCOTG OTG Root HUB> at usbus1
uhub0 on usbus1

The message is not special to RPi4B's or to EDK2 use at all.
Nor does what it reports lead to stopping the boot sequence.

The actual problem is a FreeBSD kernel mishandling of reserving
memory: a rejection/panic of a valid ACPI set up (valid as far
as I can tell).


===
Mark Millard
marklmi at yahoo.com