Date: Sat, 6 Apr 2019 11:39:16 -0700 From: Marcel Flores <marcel@brickporch.com> To: freebsd-arm@freebsd.org Subject: Re: Restore broken ThunderX support in 12 by MFCing r343764? Message-ID: <EB19C46F-AE1D-44A0-B93A-8DD42C591B26@brickporch.com> In-Reply-To: <AEF036AB-D81E-4D46-BE04-E470A2B350D1@brickporch.com> References: <20190218022911.72261m7v5l6g1i7b@webmail.omc.net> <CAPyFy2CB0T6GpR5=Am_CYnrbD5KehX3YjCtnT6gd0tHP0VPcow@mail.gmail.com> <3996B352-ABFB-4CA5-A897-6C6CD1D2A132@brickporch.com> <AEF036AB-D81E-4D46-BE04-E470A2B350D1@brickporch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 5, 2019, at 7:15 AM, Marcel Flores <marcel@brickporch.com> = wrote: >=20 >>=20 >> On Apr 3, 2019, at 10:16 PM, Marcel Flores <marcel@brickporch.com = <mailto:marcel@brickporch.com>> wrote: >>=20 >>=20 >>=20 >>> On Apr 3, 2019, at 6:55 AM, Ed Maste <emaste@freebsd.org> wrote: >>>=20 >>> On Sun, 17 Feb 2019 at 20:29, <kraileth@elderlinux.org> wrote: >>>>=20 >>>> Not being a developer though, I cannot judge if [r343764] cannot be = MFC'd >>>> into 12-STABLE due to making invasive changes or if it simply never >>>> was because it was thought to be an improvement for 13 only and not = an >>>> actually pretty vital fix for 12. >>>=20 >>> I suspect jchandra@ just didn't realize it's needed also on = ThunderX, >>> and I did not encounter any trouble with the ThunderX systems I = have. >>> It could just be that our (older) ThunderX reference firmware has >>> fewer regions in its ACPI info and so works fine without r343764. >>> Anyhow I've now merged the change to stable/12. >>>=20 >>> With respect to vt_efifb the tunable is a simple workaround, but we >>> really need this to work out-of-the-box. Do you have any further >>> details on the failure when vt_efifb is enabled? >>>=20 >>> Also, if you're aware of any other ThunderX issues please let me = know.] >>=20 >> stable/12 now works. In fact, the hw.syscons.disable tuneable is no = longer needed either =E2=80=94 a fresh build stable/12 appears to be = working with GENERIC out of the box. Based on this thread, that = doesn=E2=80=99t totally make sense to me, but I=E2=80=99m not sure what = all else has made it into stable/12. >>=20 >> The same can=E2=80=99t be said for 13, which, as of about 2 weeks ago = (I can confirm later this week if that would be worthwhile), behaves as = described here without it: >> = https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html= ><https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.htm= l = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html= >><https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.ht= ml = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html= ><https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.htm= l = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html= >>> >>=20 >> Since the serial console essentially hangs, I=E2=80=99m not sure how = to get any additional information, but happy to try any suggestions. >>=20 >>=20 >> The only other issues I=E2=80=99ve had with the ThunderX Gigabyte = board I have is getting the onboard NIC to work (Seems to be about like = this, looking at dmesg: = https://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html><h= ttps://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html = <https://lists.freebsd.org/pipermail/freebsd-arm/2018-April/017865.html>>)= , but I imagine this is a driver question for the Gigabyte portions, = rather than an issue with the ThunderX itself. >>=20 >=20 > Correction to the above =E2=80=94 just tried to boot current/13 = r345863 via USB > installer, it actually gets further, sans tuneable, but gets stuck = somewhere.=20 > Boot output attached. >=20 > https://hastebin.com/xeteyuhome <https://hastebin.com/xeteyuhome>; >=20 > -m Fresh build on the box itself booted no trouble (GENERIC, no tuneable), = not=20 sure what the issue with the USB was: [marcel 02:40]% uname -v = = =20 FreeBSD 13.0-CURRENT r345978 GENERIC=20 -m > _______________________________________________ > freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org> mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>; > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = <mailto:freebsd-arm-unsubscribe@freebsd.org>"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EB19C46F-AE1D-44A0-B93A-8DD42C591B26>