Date: Sat, 6 Mar 2021 21:30:33 -0800 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: RPi4 Status and sysutils/rpi-firmware (and rng) Message-ID: <AAA4E495-4E9E-4C55-A07E-74D9737EC15B@yahoo.com> In-Reply-To: <20210307021628.GA99890@www.zefox.net> References: <BDF8C846-1CB3-421E-A8D5-25E0075C7106.ref@yahoo.com> <BDF8C846-1CB3-421E-A8D5-25E0075C7106@yahoo.com> <20210307021628.GA99890@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 : >>=20 >>> On Sat, Mar 06, 2021 at 11:42:06AM +0000, Mark Murray wrote: >>>>=20 >>>>=20 >>>>> On 6 Mar 2021, at 11:37, Gordon Bergling <gbe at FreeBSD.org> = wrote: >>>>> Done in e797dc58bd29c5bc0873fc620fc11d5332f90e7f. Thanks for the = approval. >>>>=20 >>>> You are welcome. Thanks for doing the work! >>>>=20 >>>> M >>>> -- >>>=20 >>> 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. >>=20 >> Are you picky about debug-builds ( main [so 14] ) vs. non-debug >> builds ( stable/13 or releng/13.0 based )? >>=20 > 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? >>=20 > Not at all.=20 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=3Dmain-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. >>=20 > The git versioning scheme does seem to leave us with a raging > case of chicken-vs-egg syndrome. An imperfect solution would=20 > 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-) >=20 > 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=20 > 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. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AAA4E495-4E9E-4C55-A07E-74D9737EC15B>