Bug 246552

(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..