On some machines, the ACPI check (`has_acpi = (acpi_find_table(ACPI_SIG_SPCR) != 0)` in sys/arm64/arm64/machdep.c) seems to fail — the kernel refuses to use ACPI even with kern.cfg.order=acpi, and hardcoding `has_acpi = true` helps. Confirmed on two devices now: - Raspberry Pi 4 https://github.com/pftf/RPi4 (by me) - SolidRun HoneyComb LX2K / CEX7 module (NXP Layerscape LX2160A) https://github.com/SolidRun/edk2-platforms (by Dan Kotowski on freebsd-arm@) They *do* have the SPCR table of course.
(In reply to Greg V from comment #0) Have you tried a verbose boot for the RPi4 to see if you get messages like in the code below? vm_paddr_t acpi_find_table(const char *sig) { . . . rsdp = pmap_mapbios(rsdp_ptr, sizeof(ACPI_TABLE_RSDP)); if (rsdp == NULL) { if (bootverbose) printf("ACPI: Failed to map RSDP\n"); return (0); } . . . (There are other messages possible. It is just an example.) The same sort of point would go for Dan K. for the LX2K/CEX7 context. If such messages are produced, it might help give more of a hint what is going on. If none are produced, that may have implications for what the code sequence was that might also help identifying the issue(s).
For some reason those printfs never run but I'm not entirely sure why. But I was able to dump the ACPI table from the lx2160a from the EFI shell if that helps: https://gist.github.com/agrajag9/d60be44d84a3148043d87a64f8af5652
(In reply to Dan Kotowski from comment #2) Does boot -v at the loader prompt print any extra messages during the boot? Or is it just the ACPI messages for which none of the printf happen? If there are extra messages generally, but just no ACPI ones, then the execution sequence would not be failing the checks associated with the ACPI printf's about the failures.
(In reply to Mark Millard from comment #3) Layer 8 strikes again (forgot to use -v) https://gist.github.com/agrajag9/bbb49048447510a128cb3304546e174b Not sure if worth noting, but there's a warning about not finding the device tree blob right before dmesg begins: ``` Loading kernel... /boot/kernel/kernel text=0xa96d1c data=0x191d58 data=0x0+0x302736 syms=[0x8+0x10fe60+0x8+0x135ba9] Loading configured modules... can't find '/boot/entropy' No valid device tree blob found! WARNING! Trying to fire up the kernel, but no device tree blob found! ``` I think this is probably acceptable though as we'd prefer to rely on ACPI. That said, SolidRun does provide all the sources for the DTB, which may be handy.
(In reply to Dan Kotowski from comment #4) Yes, "No valid device tree blob found" is *good*. The loader probably should not scream so angrily about this when ACPI is found.. I'll remove the hardcoded has_acpi in my next build. Maybe this was *not* the issue on the lx2160, maybe this was just something in older firmware.
(In reply to Greg V from comment #0) I've tried https://github.com/pftf/RPi4 v1.13 and v1.7 materials and have never gotten any output from the FreeBSD loader (serial console or HDMI display). If I leave it that way the UEFI watchdog eventually reboots the RPi4 so it tries again. So I do not get close to testing how the kernel behaves. No combination of UEFI settings and RPi4 config.txt settings that I've tried has behaved differently. (My context is based on FreeBSD head -r360311 via a non-debug build.) For reference: I've had no trouble with booting NetBSD and see its loader output just fine. (Same https://github.com/pftf/RPi4 v1.13 materials used.) (I've not tried the new hybrid gpt/mbr based content for NetBSD current's Generic 64-bit download from armbsd.org yet. It was still just MBR-based when I tried it.) Separately, if I understand what has happened in LX2K testing, it turned out that the LX2K did not need the "has_acpi = true" change and is not an example context for ACPI detection failure. (Comment 5's result, if I understand right.)
(In reply to Mark Millard from comment #6) Side note: Looks like armbsd.org's builds have not caught up with Jared's tweets about the switch to GPT/MBR hybrid yet: Looks to still be MBR based.
(In reply to Mark Millard from comment #6) > I've tried https://github.com/pftf/RPi4 v1.13 and v1.7 materials and have never gotten any output from the FreeBSD loader (serial console or HDMI display) I used the official touchscreen, but HDMI should work too. If you see the UEFI splashscreen/setup menu, you should be able to see FreeBSD. Does HDMI video disappear after jumping to the loader? If that's the case, try changing the video mode in the setup menu..
(In reply to Greg V from comment #8) I do not intend on using this defect to explore working around what I reported. It was more to give you some extra context indicating that others folks might have trouble replicating your results on RPi4's. Still, for reference, . . . The UEFI display material set shows on both the serial port and the HDMI monitor as I look around or change settings. Both get a clear screen before what should then be loader output, at least a binary recording of the serial port output ends with 2 escape sequences. (ESC's not included below to avoid the sequences doing something). This is from when I tried using the debug RPI_EFI.fd and is from capturing the serial console output: InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 35FC5298 ProtectUefiImageCommon - 0x359EA040 - 0x0000000033829000 - 0x00000000000A8060 [2J[47D After that both the serial output display and the HDMI display are blank and stay that way (until the watchdog activity). The watchdog from RPI_EFI.fd does lead to more output: Watchdog Timer resetting system Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200 Loading recovery.elf hnd: 0x00000000 Failed to read recovery.elf error: 6 Loading start4.elf hnd: 0x000001a7 Loading fixup4.dat hnd: 0x000001a5 MEM GPU: 76 ARM: 948 TOTAL: 1024 FIXUP src: 128 256 dst: 948 1024 Starting start4.elf @ 0xfec00200 NOTICE: BL31: v2.3():v2.3 NOTICE: BL31: Built : 10:40:51, Apr 21 2020 UEFI firmware (version UEFI Firmware v1.13 (DEBUG) built at 10:36:03 on May 13 2020) . . . I expect that the watchdog activity means that things were hung up --rather than just not showing output but otherwise operating normally for FreeBSD's loader and FreeBSD itself. So far, fiddling with the video modes and the like have made no difference. But this does not seem like the right place to deal with any more explorations for trying to find a combination that works.
Doesn't seem to be an issue anymore..