Re: When will FreeBSD support RPI5?

Mark Millard <[email protected]>
Newsgroups gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
On Jan 11, 2024, at 08:56, Mark Millard <[email protected]> wrote:

> On Jan 11, 2024, at 08:20, Doug Rabson <[email protected]> wrote:
> 
>>> On Thu, 11 Jan 2024 at 01:30, Mark Millard <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.