RPi4 Status and sysutils/rpi-firmware (and rng)

[Mark Millard]

On 2021-Mar-6, at 18:16, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sat, Mar 06, 2021 at 03:14:46PM -0800, Mark Millard via freebsd-arm wrote:
>> bob prohaska fbsd at www.zefox.net wrote on
>> Sat Mar 6 17:38:40 UTC 2021 :
>> 
>>> On Sat, Mar 06, 2021 at 11:42:06AM +0000, Mark Murray wrote:
>>>> 
>>>> 
>>>>> On 6 Mar 2021, at 11:37, Gordon Bergling <gbe at FreeBSD.org> wrote:
>>>>> Done in e797dc58bd29c5bc0873fc620fc11d5332f90e7f. Thanks for the approval.
>>>> 
>>>> You are welcome. Thanks for doing the work!
>>>> 
>>>> M
>>>> --
>>> 
>>> Any hint when a bootable snapshot image might become available?
>>> The target host is an 8GB Pi4 without a serial console, so it's
>>> limited to USB keyboard and HDMI console, no wired ethernet.
>> 
>> Are you picky about debug-builds ( main [so 14] ) vs. non-debug
>> builds ( stable/13 or releng/13.0 based )?
>> 
> Nope.

main based (debug): Thursday/Friday via:

https://lists.freebsd.org/pipermail/freebsd-snapshots/

(stable/13 will likely show up there on that sort of schedule once
13.0-RELEASE is no longer active.)

(Until 13.0-RELEASE is out . . .)
releng/13.0 based (non-debug): Friday/Saturday via
http://ftp3.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/

>> Also, are you picky about sysutils/rpi-firmware already being
>> up to date in what you get vs. your having to replace the files
>> with files from a recent sysutils/rpi-firmware build?
>> 
> Not at all. 

Looks like rpi-firmware-1.20210303.g20210303 is in the built ports
in the on-going p567446_se53138694a build listed at:

http://ampere2.nyi.freebsd.org/jail.html?mastername=main-arm64-default

It indicates 11 ports remaining to build overall. (I've not checked
if any of the 11 are multi-day of themselves.) Then there is the
time for getting copies to various servers.

So it looks like the official rpi-firmware port build will show
up in, say, a few days.

Of course, there is also the option of building
sysutils/rpi-firmware directly and copying from the installed
material.

>> Technically I've no clue how to know what sysutils/rpi-firmware
>> vintage or sysutils/u-boot-rpi4-arm64 vintage would be used in
>> future builds on the FreeBSD build servers. The FreeBSD commit
>> hash/id does not identify that information in any way that I
>> know of. For past builds, as far as I know one must examine the
>> files contained and back trace the vintage that they came from.
>> Nothing reports what it takes to reproduce the context that I
>> know of. Such points seem to be involved for all media-builds
>> that have sysutils/* materials providing some the media content.
>> 
> The git versioning scheme does seem to leave us with a raging
> case of chicken-vs-egg syndrome. An imperfect solution would 
> be an improvement over the status quo.

This problem is not new with git for FreeBSD: same problem before,
same problem once ports is also git based.

The tie between the vintages of parts contributing to the media
for something like *-arm64-aarch64-RPI*.img.xz is not in any
publicly-trackable place(s), so far as I know.

> But, blind optimism triumphed over hard-earned experience,
> at least in this case 8-)
> 
> Herb's advice worked, by combining the most recent Pi4 snapshot
> with the msdos files in the link provided in Manu's post:
> https://github.com/raspberrypi/firmware

That should work. But there have been commits there from
after 1.20210303 was tagged as a release for distribution.
sysutils/rpi-firmware is tied to 1.20210303 now.

This can lead to possibly wanting to instead use:

https://github.com/raspberrypi/firmware/tree/1.20210303/

to get to the materials that have been tagged that
should match sysutils/rpi-firmare will be using for
a while.

https://github.com/raspberrypi/firmware is sort of like
stable/13 (vs. releng/13.0) for FreeBSD (but with binary
files) unless you only reference appropriately tagged
commits. (The closest approximation to FreeBSD's main
seems to not be publicly accessible.) stable/13 and the
like tend to be in working condition for FreeBSD use
more than https://github.com/raspberrypi/firmware
materials are, even when using tagged versions. (Failing
for FreeBSD need not mean failing for raspiOS or
raspiOS64 for most users.)

> I probably wasn't efficient about it, simply overwriting everything
> that looked obviously relevant (and expecting to break something
> like the path to the kernel) but it worked.

Replacing old files is generally the correct procedure, other
than config.txt . The question can be picking a good set of
file vintages to copy. (There can be fairly regular additions
and removals in overlays/ so it is not all just replacement.)

> The HDMI console text is too big, but the keyboard works

Folks with poor eye sight for the context tend to argue for
the default being fairly large, figuring others can more easily
do something explicit to make the display match what they
prefer. (More difficult if you already can not well read what is
displayed by default.)

Of course, the sizing of what is displayed before FreeBSD's
loader is even involved (or, may be, FreeBSD's u-boot choice) is
not up to FreeBSD.

I've not experimented in this area on a RPi* (yet?).

>  and top
> seems to see all 8 GB of RAM. Didn't think to check the mouse 8-(

I've not done the huge-file copy-corruption testing
recently, and never with stable/13 or releng/13.0 or
a 13.0-BETA*/RC* . I probably should try, booting
a 13.0-RC* image as the context (other than the
rpi-firmware replacements). I use a file that is
notably bigger than the RAM.

Historically, if the corruption problems show up
the technique to get a reliable environment was to
restrict it to using 3 GiBytes, possibly via some
text in config.txt . This also applied to the
RPi4B 4 GiByte models.

> Alas, with no wired ethernet at the location I can't do much 
> as-is. However, it does motivate me to consider a second Pi4
> to be placed in my private "data center". Altogether it is a
> large step forward.
> 



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)