Re: APU1 bricked on stable/14 - solved

From: Stefan Hegnauer <stefan.hegnauer_at_gmx.ch>
Date: Sun, 06 Oct 2024 19:14:24 UTC
On 06.10.2024 15:47, Warner Losh wrote:
>
>
> On Sun, Oct 6, 2024 at 6:35 AM Stefan Hegnauer
> <stefan.hegnauer@gmx.ch> wrote:
>
>     I have a few pc-engines APU1 appliances running in headless mode under
>     Nanobsd. Maintenance is by means of  direct COM port connection.
>     After a recent update a few weeks back I was not able to connect
>     by COM
>     port anymore - console output and input went away after booting and
>     before single- or multi-user mode would start. Even re-flashing the
>     SDcard with a fresh image did not help.
>
>     After some longish trials and errors it turned out that both
>     - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to
>     "acpi"' as well as
>     - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt
>     settings
>     on x86'
>     broke things for me. Restoring hints and setting
>     hw.acpi.override_isa_irq_polarity=1 in /boot/loader.conf.local
>     restored
>     working order.
>
>     I agree that APU1 is EOL, however I would have expected an entry to
>     UPDATING for such a POLA violation.
>
>
> Likely, but really really old gear like this is going to hit edge
> cases that
> developers haven't seen. The hint thing wasn't though to actually
> negatively
> affect any deployed hardware since it dealt with details that changed
> 15 or
> 20 years ago...
>
> Looks like the APU1 used coreboot which at the time was trailing
> adaptation
> of ACPI, so it makes sense... I knew that Soekris boxes had issues,
> but they
> are another 5 or 10 years older than the APUs and mine sadly isn't
> operational.
>
> So I can write a better UPDATING entry, can you share with me the dmesg
> from both APU1 and APU2?
>
> Warner
>
>     Note that pc-engines APU2 models are not affected as the BIOS ACPI
>     tables contain correct UART descriptions.
>
>     - Stefan
>
Warner: thanks for the quick reply. Not so really, really old in my view
- the BIOS is from ~August 2022 (APU1). And yes, it uses coreboot:
     PC Engines apu1
     coreboot build 20220822
     BIOS version v4.17.0.3
     SeaBIOS (version rel-1.16.0.1-0-g77603a32)

 From verbose boot, dmesg -a:
- APU1, original/faulty from today:
https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_std.txt
- APU1, fixed in loader.conf.local:
https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_fixed.txt
- APU2 (has no problems):
https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.txt

Let me know if you need additional information.

- Stefan