Re: APU1 bricked on stable/14 - solved

From: Stefan Hegnauer <stefan.hegnauer_at_gmx.ch>
Date: Sun, 06 Oct 2024 19:39:12 UTC
On 06.10.2024 21:14, Stefan Hegnauer wrote:
> 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

For the record, APU1 is
     root@stratum:~ # freebsd-version ; uname -a
     14.1-STABLE
     FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-STABLE
stable/14-n269015-013d817b5393 STRATUM amd64

and APU2:
     root@apupf:~ # freebsd-version ; uname -a
     14.1-STABLE
     FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STABLE
stable/14-n269015-013d817b5393 APUPF amd64