Re: When will FreeBSD support RPI5?

From: Mark Millard <marklmi_at_yahoo.com>
Date: Thu, 11 Jan 2024 18:09:11 UTC
On Jan 11, 2024, at 08:56, Mark Millard <marklmi@yahoo.com> wrote:

> On Jan 11, 2024, at 08:20, Doug Rabson <dfr@rabson.org> wrote:
> 
>>> On Thu, 11 Jan 2024 at 01:30, Mark Millard <marklmi@yahoo.com> wrote:
>>> (While I normally use FreeBSD's U-Boot type of context,
>>> My builds do have patches to allow RPi4B EDK2 use to
>>> avoid the problems that I know to test for.)
>> 
>> I'm curious how you were able to boot FreeBSD on rpi4 with EDK2 - I tried with both the FreeBSD package as well as the latest release from github. FreeBSD-14.0 stalled trying to initialise xhci while FreeBSD-15 gets a little further but also hangs before reaching single user mode. I'm wondering if perhaps I should use the dtbs from sysutils/rpi-firmware rather than the ones from sysutils/edk2@rpi4.
> 
> It has been a while since I last tested booting based on
> a EDK2-based release from https://github.com/pftf/RPi4/ .
> It looks like v1.35 is from 2023-Jun-05. At some point
> I'll (re?-)try it.
> 
> I used the same style of having EDK2 on a microsd card and
> booting my normal USB3 media. The RPi4B is configured to
> first try the microsd card slot (usually empty for me) and
> then to try USB. I do set things up in EDK2 for serial
> console use as primary. (I only rarely connect video to
> the RPi*'s that I have access to. Mostly I ssh to them over
> ethernet and otherwise use the serial console.)
> 
> I've access to RPi4B Rev 1.1, 1.4, and 1.5 examples,
> a mix of 4 GiByte and 8 GiByte.
> 
> I've never used sysutils/edk2@rpi4 to boot as far as I
> remember. My EDK2 activity started long before that
> existed and I did not switch.
> 
> The RPPi4B EDK2-based releases that I've used were from:
> 
> https://github.com/pftf/RPi4/releases/
> 
> But there are many releases that I've never tried.
> 
> I do use patches to avoid some reliability
> problems with USB file I/O . The reliability
> problems never interfered with booting and were
> only systematically reproducible via generating huge
> files. But the problems were originally notice via
> buildworld/buildkernel oddities that involved
> randomly corrupted files, but not many. The problems
> are FreeBSD bugs/incompletenesses in an area not used
> with most UEFI/ACPI contexts that FreeBSD supports.
> 

I found my v1.35 microsd card from the last time I tried.

I had forgotten that the boot attempts now get a FreeBSD
panic (seen via serial console use):

panic: ram_attach: resource 5 failed to attach
cpuid = 0
time = 1
KDB: stack backtrace:
#0 0xffff00000050f450 at kdb_backtrace+0x58
#1 0xffff0000004ba930 at vpanic+0x19c
#2 0xffff0000004ba790 at panic+0x44
#3 0xffff00000086e7c0 at ram_attach+0x1ac
#4 0xffff0000004fba88 at device_attach+0x3f8
#5 0xffff0000004fdce8 at bus_generic_new_pass+0x120
#6 0xffff0000004fdc78 at bus_generic_new_pass+0xb0
#7 0xffff000000500450 at root_bus_configure+0x40
#8 0xffff00000042b600 at mi_startup+0xdc
#9 0xffff0000000008ac at virtdone+0x70

It is a FreeBSD problem, not an EDK2 problem. My old
notes on the lists about the FreeBSD problem are at:

https://lists.freebsd.org/archives/freebsd-current/2023-September/004775.html

I do not know if v1.34 might sidestep the mishandling
in FreeBSD or not.

===
Mark Millard
marklmi at yahoo.com