Re: https://github.com/pftf/RPi4 unusable for FreeBSD since at least Sept 2023
Date: Fri, 19 Jan 2024 17:10:29 UTC
On Jan 19, 2024, at 08:57, Mark Millard <marklmi@yahoo.com> wrote: > 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). See: https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.html === Mark Millard marklmi at yahoo.com