Date: Sun, 6 Oct 2024 21:39:12 +0200 From: Stefan Hegnauer <stefan.hegnauer@gmx.ch> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-stable@freebsd.org Subject: Re: APU1 bricked on stable/14 - solved Message-ID: <d5d49760-35a1-45db-940b-5e4cda33a206@gmx.ch> In-Reply-To: <f12072f3-3b4e-4e63-a91b-802d59a0e873@gmx.ch> References: <feaff803-ae93-4e9b-a8e6-1498d7b07b69@gmx.ch> <CANCZdfqZ_byx5aQsybVDriitWezTL43ix7Vajh-i1DKPRtg_7g@mail.gmail.com> <f12072f3-3b4e-4e63-a91b-802d59a0e873@gmx.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM 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=C2=A0 direct COM port connectio= n. >> 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=3D1 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=C2=A0is from ~August 2022 (APU1). And yes, it uses coreb= oot: > =C2=A0=C2=A0=C2=A0 PC Engines apu1 > =C2=A0=C2=A0=C2=A0 coreboot build 20220822 > =C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3 > =C2=A0=C2=A0=C2=A0 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.tx= t > - 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 =C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-STAB= LE stable/14-n269015-013d817b5393 STRATUM amd64 and APU2: =C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a =C2=A0=C2=A0=C2=A0 14.1-STABLE =C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STABLE stable/14-n269015-013d817b5393 APUPF amd64 --------------7T2SWUvVFJJ1WVFzx0ond7Se Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-= 8"> </head> <body> On 06.10.2024 21:14, Stefan Hegnauer wrote:<br> <blockquote type=3D"cite" cite=3D"mid:f12072f3-3b4e-4e63-a91b-802d59a0e873@gmx.ch"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUT= F-8"> <font face=3D"monospace">On 06.10.2024 15:47, Warner Losh wrote:<br> </font> <blockquote type=3D"cite" cite=3D"mid:CANCZdfqZ_byx5aQsybVDriitWezTL43ix7Vajh-i1DKPRtg_7g@mail.gmail= .com"> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8"> <div dir=3D"ltr"> <div dir=3D"ltr"><font face=3D"monospace"><br> </font></div> <font face=3D"monospace"><br> </font> <div class=3D"gmail_quote"> <div dir=3D"ltr" class=3D"gmail_attr"><font face=3D"monospace"= >On Sun, Oct 6, 2024 at 6:35=E2=80=AFAM Stefan Hegnauer <<a href=3D"mailto:stefan.hegnauer@gmx.ch" moz-do-not-send=3D"true" class=3D"moz-txt-link-freetext"= >stefan.hegnauer@gmx.ch</a>> wrote:<br> </font></div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><font face=3D"monospace">I have a few pc-engines APU1 appliances running in headless mode under<br> Nanobsd. Maintenance is by means of=C2=A0 direct COM port connection.<br> After a recent update a few weeks back I was not able to connect by COM<br> port anymore - console output and input went away after booting and<br> before single- or multi-user mode would start. Even re-flashing the<br> SDcard with a fresh image did not help.<br> </font> <font face=3D"monospace"><br> After some longish trials and errors it turned out that both<br> - commit 74b9fc7a 'amd64 GENERIC: Switch uart hints from "isa" to<br> "acpi"' as well as<br> - commit 4ba4cfaf 'acpi: Narrow workaround for broken interrupt settings<br> on x86'<br> broke things for me. Restoring hints and setting<br> hw.acpi.override_isa_irq_polarity=3D1 in /boot/loader.conf.local restored<br> working order.<br> </font> <font face=3D"monospace"><br> I agree that APU1 is EOL, however I would have expected an entry to<br> UPDATING for such a POLA violation.<br> </font></blockquote> <div><font face=3D"monospace"><br> </font></div> <div><font face=3D"monospace">Likely, but really really old gear like this is going to hit edge cases that</font></div= > <div><font face=3D"monospace">developers haven't seen. The hint thing wasn't though to actually negatively</font></di= v> <div><font face=3D"monospace">affect any deployed hardware since it dealt with details that changed 15 or</font></div= > <div><font face=3D"monospace">20 years ago...</font></div> <div><font face=3D"monospace"><br> </font></div> <div><font face=3D"monospace">Looks like the APU1 used coreboot which at the time was trailing adaptation</font><= /div> <div><font face=3D"monospace">of ACPI, so it makes sense... I knew that Soekris boxes had issues, but they</font></div> <div><font face=3D"monospace">are another 5 or 10 years older than the APUs and mine sadly isn't operational.</font></di= v> <div><font face=3D"monospace"><br> </font></div> <div><font face=3D"monospace">So I can write a better UPDATING entry, can you share with me the dmesg</font></div> <div><font face=3D"monospace">from both APU1 and APU2?</font><= /div> <div><font face=3D"monospace"><br> </font></div> <div><font face=3D"monospace">Warner</font></div> <div><font face=3D"monospace">=C2=A0</font></div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><font face=3D"monospace"> Note that pc-engines APU2 models are not affected as the BIOS ACPI<br> tables contain correct UART descriptions.<br> </font> <font face=3D"monospace"><br> - Stefan<br> </font> <font face=3D"monospace"><br> </font> </blockquote> </div> </div> </blockquote> <font face=3D"monospace">Warner: thanks for the quick reply. Not so really, really old in my view - the BIOS=C2=A0is from ~August 2022 (APU1). And yes, it uses coreboot:<br> =C2=A0=C2=A0=C2=A0 PC Engines apu1<br> =C2=A0=C2=A0=C2=A0 coreboot build 20220822<br> =C2=A0=C2=A0=C2=A0 BIOS version v4.17.0.3<br> =C2=A0=C2=A0=C2=A0 SeaBIOS (version rel-1.16.0.1-0-g77603a32)<br> <br> From verbose boot, dmesg -a:<br> - APU1, original/faulty from today:=C2=A0<a moz-do-not-send=3D"tru= e" href=3D"https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_= std.txt" class=3D"moz-txt-link-freetext">https://hegnauer.selfhost.eu/web= /computing/apu1c4_3mdeb_v4_17_0_3_std.txt</a><br> - APU1, fixed in loader.conf.local:=C2=A0<a moz-do-not-send=3D"tru= e" href=3D"https://hegnauer.selfhost.eu/web/computing/apu1c4_3mdeb_v4_17_0_3_= fixed.txt" class=3D"moz-txt-link-freetext">https://hegnauer.selfhost.eu/web= /computing/apu1c4_3mdeb_v4_17_0_3_fixed.txt</a><br> - APU2 (has no problems): <a moz-do-not-send=3D"true" href=3D"https://hegnauer.selfhost.eu/web/computing/apu2d4_3mdeb_v4_19_0_1.= txt" class=3D"moz-txt-link-freetext">https://hegnauer.selfhost.eu/web= /computing/apu2d4_3mdeb_v4_19_0_1.txt</a><br> <br> Let me know if you need additional information.<br> <br> - Stefan<br> </font> </blockquote> <br> For the record, APU1 is<br> =C2=A0=C2=A0=C2=A0 root@stratum:~ # freebsd-version ; uname -a<br> =C2=A0=C2=A0=C2=A0 14.1-STABLE<br> =C2=A0=C2=A0=C2=A0 FreeBSD stratum.localnet 14.1-STABLE FreeBSD 14.1-S= TABLE stable/14-n269015-013d817b5393 STRATUM amd64<br> <br> and APU2:<br> =C2=A0=C2=A0=C2=A0 root@apupf:~ # freebsd-version ; uname -a<br> =C2=A0=C2=A0=C2=A0 14.1-STABLE<br> =C2=A0=C2=A0=C2=A0 FreeBSD apupf.localnet 14.1-STABLE FreeBSD 14.1-STA= BLE stable/14-n269015-013d817b5393 APUPF amd64<br> <br> <br> <br> </body> </html> --------------7T2SWUvVFJJ1WVFzx0ond7Se--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d5d49760-35a1-45db-940b-5e4cda33a206>