On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote:
> > > So we are dealing with a platform that violates the UEFI spec, since
> > > it does not bother to implement variable services at runtime (because
> > > MS let the vendor get away with this).
> >
> > To clarify, the above remark applies to populating the DT from the OS
> > rather than from the firmware.
>
> yeah, it isn't pretty, but there *are* some other similar cases where
> efi-stub is populating DT.. (like update_fdt_memmap() and
> kaslr-seed)..
The problem isn't with the stub updating the DT, the problem is what
it updates it with.
update_fdt_memmap() is the stub filling in the information it
communicates to the main kernel.
kaslr-seed sets a standard property using a standard interface if that
interface is available to it at the point of execution.
Since what we're doing here is dressing up an ACPI platform to make it
look like it was a DT platform, and since we have the ability to tweak
the DT before ever passing it to the kernel, let's just do that.
Yes, I know I said I'd rather not, but it's way nicer than sticking
platform-specific hacks into the EFI stub.
(If adding it as a DT property is indeed the thing to do.)
> > ... but saving variables at boot time for consumption at runtime is
> > something that we will likely see more of in the future.
>
> I think this will be nice, but it also doesn't address the need for a
> quirk to get this into /chosen.. I guess we *could* use a shim or
> something that runs before the kernel to do this. But that just seems
> like a logistical/support nightmare.
>
> There is one kernel, and there
> are N distro's, so debugging a users "I don't get a screen at boot"
> problem because their distro missed some shim patch really just
> doesn't seem like a headache I want to have.
The distros should not need to be aware *at all* of the hacks required
to disguise these platforms as DT platforms.
If they do, they're already device-specific installers and have
already accepted the logistical/support nightmare.
/
Leif
