Restore broken ThunderX support in 12 by MFCing r343764?

[Marcel Flores]

> On Apr 5, 2019, at 7:15 AM, Marcel Flores <marcel at brickporch.com> wrote:
> 
>> 
>> On Apr 3, 2019, at 10:16 PM, Marcel Flores <marcel at brickporch.com <mailto:marcel at brickporch.com>> wrote:
>> 
>> 
>> 
>>> On Apr 3, 2019, at 6:55 AM, Ed Maste <emaste at freebsd.org> wrote:
>>> 
>>> On Sun, 17 Feb 2019 at 20:29, <kraileth at elderlinux.org> wrote:
>>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>> 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?
>>> 
>>> Also, if you're aware of any other ThunderX issues please let me know.]
>> 
>> stable/12 now works. In fact, the hw.syscons.disable tuneable is no longer needed either — a fresh build stable/12 appears to be working with GENERIC out of the box. Based on this thread, that doesn’t totally make sense to me, but I’m not sure what all else has made it into stable/12.
>> 
>> The same can’t 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.html <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.html><https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html <https://lists.freebsd.org/pipermail/freebsd-arm/2018-December/019130.html>>>
>> 
>> Since the serial console essentially hangs, I’m not sure how to get any additional information, but happy to try any suggestions.
>> 
>> 
>> The only other issues I’ve 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><https://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.
>> 
> 
> Correction to the above — just tried to boot current/13 r345863 via USB
> installer, it actually gets further, sans tuneable, but gets stuck somewhere. 
> Boot output attached.
> 
> https://hastebin.com/xeteyuhome <https://hastebin.com/xeteyuhome>
> 
> -m

Fresh build on the box itself booted no trouble (GENERIC, no tuneable), not 
sure what the issue with the USB was:

[marcel 02:40]% uname -v                                                                                                                                                                                
FreeBSD 13.0-CURRENT r345978 GENERIC 

-m

> _______________________________________________
> freebsd-arm at freebsd.org <mailto:freebsd-arm at 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 at freebsd.org <mailto:freebsd-arm-unsubscribe at freebsd.org>"