Re: Need testers for ALPHA RPi-5 fan control, GE NIC, WiFi drivers for FreeBSD-CURRENT

On 6/5/26 20:49, Mark Millard wrote:
> On 6/5/26 19:34, Jeremy McMillan wrote:
>> Thanks for the attention, but I really must apologize this codebase
>> isn't clean. The INTEGRATION_GUIDE.md is horribly out of date and the
>> actual implementation in the current version hardcodes the PWM
>> addresses. The FDT is provided by the NumberOneGit/rpi5-uefi
>> distribution.
> 
> Years ago I had my nose in the RPi4B support in the FreeBSD kernel. It
> has lots of hard coded addresses and such that are not live-pulled from
> the FDT information. In fact, when the C0 stepping was released that
> fixed what had required bounce buffers to allow > 3 GiBytes of RAM and
> the live FDT no longer used address arrangement tied to the issue,
> FreeBSD continued to work the same old way, with the same addresses,
> still doing bounce buffers as if such was a B0 stepping RPi4B. (That was
> a U-Boot context of official use.) The same was true of the EDK2 for the
> RPI4B: as if it was a B0 stepping.)
> 
> [I never figured out enough to make not having the bounce buffers active
> operate in a reliable way. I had hoped to eliminate the overhead.]
> 
> [Later FreeBSD's kernel got code that detected that that EDK2 was
> providing some device addresses where arm addresses should have been
> provided. The resulting overlapping reserved ranges are rejected and
> lead to a panic as a form of handling the error. So that EDK2 is no
> longer operational for FreeBSD use.]
> 
>>
>> On Thu, 2026-06-04 at 19:39 -0700, Mark Millard wrote:
>>> . . .
>>
>> I will clean up the repo some this weekend and push that to reduce this
>> kind of confusion in the future.
>>
>>
>>
> 
> 

Ultimately, the below is about examples of type of things that you may
run into, not any specific claim about what you need to support.


I'm going to add to the live tracking vs not notes with an example that
U-boot classically tracked and the EDK2's did not. It is something the
RPi* firmware supports that I like to use to set up testing of low
memory environments without needing to actually have a machine with that
limited amount of memory --in a way that can be across operating
systems, some of which may have no hook of their own for such:

https://www.raspberrypi.com/documentation/computers/config_txt.html#memory-options

reports for something to possibly specify in the RPi* config.txt:

QUOTE
total_mem

This parameter can be used to force a Raspberry Pi to limit its memory
capacity: specify the total amount of RAM, in megabytes, you wish the
Raspberry Pi to use. For example, to make a 4 GB Raspberry Pi 4B behave
as though it were a 1 GB model, use the following:

total_mem=1024
This value will be clamped between a minimum of 128 MB, and a maximum of
the total memory installed on the board.
END QUOTE

The setting changes the content of the live FDT handed over to EDK2 or
U-Boot, adjusting addresses used, sizes, etc.

The existing EDK2's set the amount of RAM they provide to the FreeBSD
efi loader ignoring such adjustments: they just use the memory size
information from the revision codes. I do not know what specific
addresses and sizes are tracking the FDT vs. not, given the total used
when total_mem changes the memory layout some.

The EDK2's do not publicly claim to support total_mem having been used
to make changes. (Nor do they hint that such is not supported.) This
sort of matches up with the C0 stepping of the RPi4B being supported in
a form of as-if it was like the B0 stepping.

For all I know, the RPi* firmware and the EDK2 could sometimes be
contradictory in places when total_mem has changed the figure.

I'll note that the FreeBSD kernels for (at least) tier 1 have their own
way of doing such, starting from what the kernel is told and making more
adjustments: hw.physmem in (for example) loader.conf. For at least the
x86 contexts, the usable memory can end up noticeably smaller and so
should be checked for being as desired. I use hw.physmem for low memory
testing at times. That is not to say that you have to support such --but
indicating the status some way would be good.

I do not know if hw.physmem might be constrained for support by your
work: just because EDK2 says some address ranges are available (even
absent total_mem use) does not mean that the FreeBSD kernel will agree
about all of them.

Another point of reference, suggesting memory lay tracking problems, the
RPi4B (using the supported U-Boot style of booting) has had examples of
various total_mem assignments not booting --and others booting and
seeming to allow operation, sometimes for small deltas. Normal RPi4B's
with standard RAM sizes can have boot issues, 2 GiByte has at times been
an example ,if I remember right. I've had folks see if they could find a
total_mem value that got them working.

As you are not in control of the EDK2 memory layout handling vs. the
RPi* firmware's actual layout, you may only be able claim support for
RPi5's memory sizes that end up being tested to be working well. Some
might not even get to the FreeBSD efi loader, for all I know, possibly
preventing your work from even being tested.

-- 
===
Mark Millard
marklmi at yahoo.com