Messages in this thread | | | Subject | Re: [PATCH 0/5] arm64: Survival kit for SCR_EL3.HCE==0 conditions | From | Florian Fainelli <> | Date | Sun, 22 Aug 2021 13:31:38 +0200 |
| |
On 8/15/2021 11:27 AM, Marc Zyngier wrote: > On Sun, 15 Aug 2021 08:28:47 +0100, > Florian Fainelli <f.fainelli@gmail.com> wrote: >> >> >> >> On 8/12/2021 9:02 PM, Marc Zyngier wrote: >>> Anyone vaguely familiar with the ARMv8 architecture would quickly >>> understand that entering the kernel at EL2 without enabling the HVC >>> instruction is... living dangerously. But as it turns out [0], there >>> is a whole range of (*cough*) "high quality" (*cough*) Broadcom >>> systems out there configured exactly like that. >> >> Some Broadcom systems, namely the 4908 and all of those using CFE, >> they later switched to u-boot and ATF and got it right. > > Do we have a list of the affected systems?
That is going to be hard to come up with given that OEMs such as Asus, TP-Link, or Netgear and multiple devices are affected. I would start with this list which is far from exhaustive: Netgear R8000P, TP-Link Archer C2300, Asus GT AC5300.
> >> >>> >>> If you are speechless, I'm right with you. >>> >>> These machines have stopped being able to boot an upstream kernel >>> since 5.12, where we changed the way we switch from nVHE to VHE, as >>> this relies on the HVC instruction being usable... It is also worth >>> noting that these systems have never been able to use KVM. Or kexec. >>> >>> This small series addresses the issue by detecting an UNDEFing HVC in >>> a fairly controlled environment, and in this case pretend that we have >>> booted at EL1. It also documents the requirement for SCR_EL3.HCE to be >>> set to *1* if the kernel is entered at EL2. Turns out that we really >>> have to state the obvious. >>> >>> This has been tested on a FVP model with a hacked-up boot-wrapper. >>> >>> Note that I really don't think any of this is -stable material, except >>> maybe for the documentation. It isn't 5.14 material either. Best case, >>> this is 5.15, or maybe even later. If ever. >> >> While I am very appreciative of the work you have done here to try to >> get the dysfunctional systems to warn and continue to boot, I would >> rather we try to load a minimal shim at EL3 capable of fixing up any >> incorrect EL3 register setting ahead of loading the kernel provided >> this is possible at all on a commercially available system. > > That would be the best thing to do, and would make the machine fully > usable. I still think we need to have something in the kernel to at > least let the user know that their system is misconfigured though. > > If CFE allows a payload to be loaded at EL3 and executed on all CPUs, > that would be absolutely awesome. It would even allow switching over > to ATF...
Supposedly there are GPL tarballs containing an u-boot that is suitable for the 4908, however I have no idea where to find those. In premise you could chainload those to CFE and a get seemingly functional system. -- Florian
| |