Re: https://github.com/pftf/RPi4 unusable for FreeBSD since at least Sept 2023

On Jan 20, 2024, at 06:30, void <void@f-m.fm> wrote:

> Hi Mark,
> 
> On Fri, 19 Jan 2024, at 18:34, Mark Millard wrote:
> 
>> I gather this was during the bsdinstall run, not
>> during a RPi* boot attempt.
> 
> yes
> 
>>> 2. I tried latest 14-stable
>> 
>> Do you mean an official snapshot of 14-stable dd'd to media?
>> Otherwise what was done is unclear: unable to know what to
>> do to try replicating the problem.
> 
> Yes. All images used were official ones either -release or -snapshot.
> 
>> FreeBSD does not handle the bounce buffers correctly when
>> UEFI/ACPI is used. Only U-Boot is officially supported.
>> Ignoring other currently existing problems with booting
>> UEFI/ACPI, even if/when it boots, the file system I/O is
>> subject to random corruptions from the mishandling.
>> (Sufficiently large file use can make the existence of
>> some corruptions reliable, but where varies.)
>> 
>> To have a reliable RPi* system that is unpatched, avoid any
>> form of UEFI with ACPI, including EDK2.
> 
> I didn't realise at the time EDK2 was explicitly UEFI. I was sure to select
> FDT from its TUI. I also didn't know if ACPI is being used. How would I tell?

Sorry. I made the assumption that you were using the
default, which was just UEFI/ACPI as I remember.

I use EDK2 in order to also test using UEFI/APCI so
I've not tried the other selection(s), using FreeBSD's
normal U-Boot for UEFI/fdt style. (In part because
FreeBSD is implemented to match the RasPiOS device
tree that results. EDK2's fdt need not match --and so
the kernel support status is not obvious.)

> I want the system to always run headless and reliably, and am not concerned
> or knowledgable enough to differentiate 'legacy' or 'uefi', as long as 
> the system works and is accessible via serial console. 
> 
>> I suggest checking on bootability via official snapshots
>> dd'd to media. If that works, then smeothing more specific
>> is going on for the other forms of producing media that are
>> being tried.
> 
> I suspect my complete failure to boot is down to a layer 8 problem.
> 
> The initial problem I sought to address was why, on a current snapshot, the
> boot went to tftp first, see 
> https://lists.freebsd.org/archives/freebsd-arm/2024-January/003487.html

My update to the new 2024.01 U-Boot no longer gets
that behavior (so far?).

> The situation I now have is 14-stable booting with 13.1-R msdos materials [1]
> which is reliable so far and doesn't try tftp first.

My stable/14 based boot media is using U-Boot 2023.10 and
is not getting the TFTP problem. I expect that stable/14
snapshots will switch to 2024.01 but main [so: 15] just
happened to complete the port->package builds first.

> It uses config.txt
> for overclocking. I don't know if this is uefi or legacy but i suspect it's
> legacy. The serial console works.
> 
> [1] Is it ok or optimal to use 13.1 msdos materials with 14-stable ?

The FreeBSD's loader that is used is in the msdosfs and
should be updated.

Avoiding ZFS creates less dependence on FreeBSD loader
updates. The loader has to know about some new ZFS/zpool
features in order to allow booting with them.

I suspect that normal stable/14 with the 2024.01 U-Boot
will work just fine relative to TFTP.

I would not want to hold at 13.1's msdosfs content
indefinitely. But I'm not aware of problems for
never-ZFS contexts for now.


I do not  know if you noticed main's UPDATING entry:

20231120:
        If you have an arm64 system that uses ACPI, you will need to update your
        loader.efi in the ESP when you update past this point.  Detection of ACPI
        was moved earlier in the binary so the scripts could use it, but old
        binaries don't have this, so we default to 'no ACPI' in this case. You can
        undisable ACPI by doing
                OK unset hint.acpi.0.disabled
        This can also be used to recover any other system that was updated in the
        small window where amd64 was also broken.

It would not matter for non-ACPI. (But ACPI support has other issues
in FreeBSD.)

===
Mark Millard
marklmi at yahoo.com