On 07/19/16 12:48, Gerd Hoffmann wrote:
> Hi,
>
>>> (2) ia32 ovmf too? Will anybody use it?
>>
>> Then the next question is, what's the status of 32-bit UEFI OSes? Simple:
>
>> [ summary: bad ]
>
> Yep, that matches the impression I have.
> Guess we don't want bother then.
>
>> Enabling Secure Boot in the OVMF binary is orthogonal to all of the
>> above, but it has a licensing impact. It embeds (a subset of) OpenSSL in
>> the binary, and changes the terms from "2-clause BSDL" to "2-clause BSDL
>> and OpenSSL license" ("and" in the restrictive, not permissive, sense).
>> I'm unsure if QEMU is willing and able to distribute such binaries.
>>
>> For the widest and simplest usability, X64 (without the SMM driver stack
>> and without Secure Boot) is likely the best.
>
> Yes (also note the smm-enabled one doesn't run on i440fx).
>
> So the options I see are (a) build without smm or (b) build two
> variants.
I think people who just want to run "UEFI payloads" are served well
enough by SMM-less. There are some developers who would benefit from a
-D SMM_REQUIRE build as well, but that would be because they actually
focus on SMM, I believe, so they can build their own firmware.
If this is about the convenience of QEMU end-users, then I vote (a). I'd
certainly like to avoid fielding bug reports that boil down to "I booted
the -D SMM_REQUIRE build on i440fx".
>> Anyway, I digress. Point is, GRUB is already UEFI capable (I don't know
>> uboot), so GRUB should be able to look up the DTB sysconfig table, and
>> use that. The sysconfig table in question is identified by the GUID
>>
>> B1B621D5-F19C-41A5-830B-D9152C69AAE0
>
> grub already does that on aarch64,
Huh, indeed. I see "grub-core/loader/arm64/fdt.c". What does UEFI grub
need the DTB for in the first place?
Hm... looks like it pokes initrd information into it. Interesting.
> but not on arm.
> So that should be fixable without too much effort.
I guess so.
I'll mention though that "just" for passing in the initrd, the DTB
shouldn't be necessary, at least if the kernel is built with the EFI
stub. Then "initrd=filename" can be passed on the kernel command line,
and the EFI stub should load it, using UEFI services, from the same
directory that the vmlinuz binary (= itself) came from.
... I can never keep the 37 ways to boot the linux kernel in my mind for
longer than 2 minutes. :/
Thanks
Laszlo
