FreeBSD on Layerscape/QorIQ LX2160X

[greg at unrelenting.technology]

May 18, 2020 10:22 PM, "Dan Kotowski" <dan.kotowski at a9development.com> wrote:

>> Same as in it still says "using DTB"?
>> 
>> I wonder if that's the same weirdness I saw on the RPi4,
>> FreeBSD failing acpi_find_table(ACPI_SIG_SPCR) even though the SPCR table
>> is present and deciding we don't have ACPI..
>> 
>> You could try my current kernel which has has_acpi hardcoded to true
>> (extract into the root of the memstick's ufs partition):
>> 
>> https://send.firefox.com/download/c3d69444ce92d3cf/#AuYrYtDvJWNYbEeJWRX4fA
> 
> Yes, it does still say "using DTB"
> 
> Also, your kernel works! Or at least I'm into the installer. It doesn't see the onboard eMMC in the
> Partition Editor, but once I have the NVMe gumstick in hand I'll pick back this back up.

Cool, please please please post a dmesg to https://dmesgd.nycbug.org :)

Created a bug for the ACPI detection issue:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246552

> Is there a reason that we can't use on the DTBs compiled from SolidRun and NXP's sources?

The devicetree uses NXP specific device descriptions (for USB, SATA, PCIe, all the things)
and FreeBSD doesn't understand them.

ACPI tables mostly use generic devices descriptions that all operating systems support
out of the box.

It is technically possible to make a DTB that mostly uses generic nodes and ACPI tables
full of custom vendor nodes, but almost nobody does this.
(Okay, actually, Qualcomm does ACPI with almost all vendor nodes on the Windows aarch64 laptops :D)

Generic descriptions are good. ARM systems that work in the "boring" plug&play way (with standardized
generic devices) are the ideal we all should strive for, so ACPI should always be preferred.
If you're using any DTB on a server/workstation-class system, something has gone wrong :)