Re: FreeBSD and CM4: use pftf/RPi4 (the EDK2 implementation)?

Hi Mark,

for the CM4 FreeBSD edkII would be the same as with the firmware-upstream:
you fix one thing and import the next dysfunctionality :-)
Currently in fbsd the CM4 is working like the 4b, 
except that the pcie-driver(which wouldn`t have edkII ACPI-logic inside) 
fails. 
The story is longer and in the end of it I can say:
It would need a dedicated Developer with very deep knowledge 
of very complex things.. and I sometimes saw others temporarily failing on other platforms
 who have that knowledge..
The way to go, as far as I can estimate, is to fix the memory computation in the pcie -driver,
to say it in simple words while that task is not simple ;-)….

Regards

K.
 
> Am 10.01.2023 um 03:15 schrieb Mark Millard <marklmi@yahoo.com>:
> 
> You may have an alternative for the CM4, not that I know the
> details of the status.
> 
> The firmware from https://github.com/pftf/RPi4/releases/tag/v1.34
> 
> includes bcm2711-rpi-cm4.dtb --and they only bother to include
> .dtb files for what they support in EDK2. (But there is still
> the questions of just what the support spans.)
> 
> So, if it turned out that UEFI/ACPI from EDK2 would
> happen to be useful, it might avoid incomplete/inaccurate
> Device Tree handling for the CM4 in teh FreeBSD kernel,
> at least for some issues.
> 
> But there is also the possibility of incomplete/inaccurate
> UEFI/ACPI handling in FreeBSD's kernel in ways that would
> be important to you. But it is separate code in the FreeBSD
> kernel generally so what works vs. not may well be different
> from Device Tree based booting.
> 
> I'll note that the crash that I worked out how to avoid is
> Device Tree boot-style specific. Any crash for UEFI/ACPI
> would be separate, if any exists.
> 
> But if you try UEFI/DeviceTree then the firmware vintage
> issue might be involved in that case.
> 
> Just something to possibly explore for/with your CM4.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
>