Re: RPI 4/5 u-boot new port, is there any interest?

Hi,

If anyone is interested in working on this, I've gathered up some notes/links which could be helpful:

- Work by dfr enabling pcie/sd interface: https://github.com/dfr/freebsd-src/tree/rpi-5-pcie (requires a few more if statements to work with 15.0)
- OpenBSD commit enabling rp1 child enumeration over device tree: https://github.com/openbsd/src/commit/2ee472d028ecbaf1d25a179e46dc4a0f63034131 (there is also a gpio driver for the rp1)

- rp1 interrupt handling (GPL code): https://github.com/rsta2/circle/blob/master/lib/southbridge.cpp (there is also code for eth/usb/spi...)
- Zephyr also appears to have some primitive support for the rpi5: https://docs.zephyrproject.org/latest/boards/raspberrypi/rpi_5/doc/index.html

- pinctrl for rp1 gpio control via userspace in Linux (BSD license): https://github.com/raspberrypi/utils/blob/master/pinctrl/gpiochip_rp1.c
- rpi4 baremetal gpu (MIT?): [https://github.com/Random06457/rpi4-gpu-bare-metal-example](https://github.com/Random06457/rpi4-gpu-bare-metal-examples)s

So far I've only managed to get the rp1 stub driver to enumerate over the child devices and attach them (causing a kernel panic...). I just grabbed mainline u-boot and compiled for rpi arm64, using the device tree blob from rpi-firmware repo.
On Wednesday, 4 June 2025 at 22:06, Klaus Küchemann <maciphone2@googlemail.com> wrote:

> Hi Bob, Hi Paul F. , Hi all again
>
> Thanks for all your interest …
> I have contacted someone who has made experience in testing kernel patches for the Pi5
> And asked him to report here …
> I also can report about the u-boot details if someone wants…
>
> Regards
> K.
>
>> Am 04.06.2025 um 20:32 schrieb bob prohaska <fbsd@www.zefox.net>:
>>
>> On Wed, Jun 04, 2025 at 08:49:19AM -0700, Warner Losh wrote:
>>
>>> On Wed, Jun 4, 2025 at 5:33 AM Klaus Küchemann
>>> <maciphone2@googlemail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> a while ago, I spoke in more detail with bz@ about u-boot for the Pi5. There are ways to create a new port...
>>>> Now I had a longer conversation with Hugo Kirnbichler on Discord. Hugo managed to patch u-boot for the RPI CM4 to make it NVMe bootable (compiled under FreeBSD).
>>>> Details would go beyond the scope here for the first.
>>>>
>>>> What I would like to know:
>>>> Is FreeBSD still interested in supporting the RPI4/5?
>>>> Goodbye Pi in FreeBSD or Hello Pi , especially now ? :-)
>>>>
>>>> Then Hugo and I might be willing to create a new port.
>>>> There's no other way to proceed... the u-boot mailing lists are aware of the problems, but nothing is happening because they don't need it for Linux. All the patches we know of are GPL’d from 3rd party companies or OS-projects afaik.
>>>>
>>>> Because it’s not really fun :-) , I don't want to continue this work if there is no official interest from FreeBSD.
>>>> If you are interested, we would be happy to discuss the details here.
>>>
>>> I'd say there's a lot of interest in running on RPi-5. That's
>>> undeniable. There are many peole
>>> that have this hardware and want to run it. As I indicated in other
>>> email, from a developer
>>> perspective, it's harder hardware to work on due to difficulties in
>>> getting good docs at times
>>> that are sufficient to write a good driver and/or having some resource
>>> to contact when things
>>> go wrong.
>>>
>>> So, there's an imbalance. There were efforts to get it going that
>>> stalled due to the death of
>>> the person who was de-facto leading the charge who was senior enough to make it
>>> successful. I've seen interest in people working on it that are less
>>> junior so can't connect
>>> all the dots, and go away because that's frustrating w/o better
>>> support from the vendor.
>>> Plus there's a long history with the RPi foundation that plays into
>>> this as well since several
>>> people have tried, but failed, to work with them and switched to
>>> easier hardware /
>>> hardware vendors to work with. On the other hand, these devices remain
>>> super popular
>>> and people in the community run them despite the support being not quite what
>>> you'd want from the platform since the platform is adequate for a wide
>>> range of things
>>> that don't need that extra support.
>>>
>>> So it's tricky. Nobody will be interested if there isn't a u-boot
>>> foundation since FreeBSD
>>
>> When you say "foundation" do you mean a code base, or an administrative one?
>> There seems to be a huge code base for u-boot, if not much readable user
>> documentation. FreeBSD doesn't even have a man page for it....
>>
>>> can't boot directly from the RPi firmware. On the other hand, it can
>>> be tricky to get
>>> people interested right away once that's available because the
>>> learning curve is a bit
>>> steep.
>>>
>>> So it's unfair to say there's no official interest from FreeBSD. It's
>>> just that there's a
>>> lot of churn and choppiness that makes the experience difficult and
>>> hard to judge.
>>>
>>> Warner
>>
>> Would it be better to approach the question via
>> https://freebsdfoundation.org/wp-content/uploads/2017/06/FreeBSDProposalSubmission.pdf
>> perhaps as a port development proposal?
>>
>> It isn't hard to understand why the Raspberry Pi foundation is hard to deal with:
>> https://register-of-charities.charitycommission.gov.uk/en/charity-search/-/charity-details/5002372
>>
>> Compare that to
>> https://freebsdfoundation.org/wp-content/uploads/2025/05/2024-YE-PL-Final.pdf
>>
>> Thanks to everybody, especially Klaus, for touching on this issue.
>>
>> bob prohaska