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

On Jan 19, 2024, at 08:57, Mark Millard <[email protected]> wrote:

> On Jan 19, 2024, at 06:33, void <[email protected]> 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).

See:

https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.html

===
Mark Millard
marklmi at yahoo.com