[U-Boot] [PATCH 0/7] efi_loader: Expose SMBIOS table

[Alexander Graf]

On 12.08.16 19:20, Simon Glass wrote:
> Hi Alex,
> 
> On 10 August 2016 at 01:29, Alexander Graf <agraf at suse.de> wrote:
>>
>>> On 09 Aug 2016, at 16:35, Simon Glass <sjg at chromium.org> wrote:
>>>
>>> Hi Alexander,
>>>
>>> On 9 August 2016 at 08:11, Alexander Graf <agraf at suse.de> wrote:
>>>>
>>>> On 08/09/2016 03:57 PM, Simon Glass wrote:
>>>>>
>>>>> Hi Alexander,
>>>>>
>>>>> On 9 August 2016 at 00:48, Alexander Graf <agraf at suse.de> wrote:
>>>>>>
>>>>>>
>>>>>>> Am 08.08.2016 um 23:44 schrieb Simon Glass <sjg at chromium.org>:
>>>>>>>
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>>> On 8 August 2016 at 08:06, Alexander Graf <agraf at suse.de> wrote:
>>>>>>>> We generate a few tables on x86 today that really can be used on ARM just
>>>>>>>> the same. One such example is the SMBIOS table, which people use with tools
>>>>>>>> like "dmidecode" to identify which hardware they are running on.
>>>>>>>>
>>>>>>>> We're slowly growing needs to collect serial numbers from various devices
>>>>>>>> on ARM and SMBIOS seems the natural choice. So this patch set moves the
>>>>>>>> current SMBIOS generation into generic code and adds serial number exposure
>>>>>>>> to it.
>>>>>>>
>>>>>>> Shouldn't we use device tree? Why would an ARM device use SMBIOS?
>>>>>>
>>>>>> Mostly because SBBR dictates it and every ARM server platform out there provides SMBIOS tables ;).
>>>>>>
>>>>>> Also, both describe very different things. At least I have never seen things like "The chassy of this server has 2 power connectors and is blue" in device tree.
>>>>>
>>>>> So there is no DT binding for this information? Does this mean that
>>>>> U-Boot on ARM needs to pass information through just 'sitting in RAM
>>>>> somewhere' like x86?
>>>>
>>>>
>>>> I don't think there's a non-EFI way on ARM to pass this through at all, correct. That's nothing new though - things like KASLR also depend on EFI.
>>>
>>> That feels like it could just be done in U-Boot. The proliferation of
>>> bootloader stuff in Linux bugs me. It's the lowest-common-denominator
>>> problem. To me it seems that UEFI and U-Boot should implement these
>>> features, and then Linux doesn't need to.
>>>
>>> Anyway I do understand where you are going. Is it possible to provide
>>> EFI tables to Linux but not EFI boot/run-time services?
>>
>> I’m not aware of any way to do that today unfortunately. I don’t see why you couldn’t add a device tree property that points to random memory locations for tables though.
> 
> I was more thinking of whether this is defined in the device tree,  or
> only exists as a binary table in SMBIOS? I probably know the answer
> :-)
> 
>>
>> As a more fundamental question though, will we really care about the non-EFI boot path 5 or 10 years from now? It doesn’t add much complexity and allows for less divergence between classic embedded and server systems. Since Linux itself is a uEFI binary, you can simply replace “booti” with “bootefi” in most boot cases and shouldn’t even see much of a difference.
> 
> Linux can certainly be built as an EFI binary. I can't predict the

It does get built as EFI binary by default, no?

> future, but I'm not sure that 'classic embedded' (i.e. most devices in
> the world) want to become more like server systems. We'll see.

The nice thing about the EFI_LOADER support is that they really don't
have to. They can stay embedded in pretty much every aspect they are today.

> 
>>
>> I don’t think that the non-EFI boot path will disappear, but turns more and more into a second class citizen because a lot of work is happening in the server space which requires EFI.
> 
> OK, well let's see. Most of my objection to EFI is the
> complexity/size.obfuscation of the code. Maybe someone should work on
> that, or are you suggesting that UEFI dies and people use U-Boot with
> the EFI interface?

To get the naming right, uEFI is the specification as provided here:

  http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_6.pdf

while the main pain point that people (including me) have, is the edk2
code base which is Intel's reference implementation of the uEFI spec:

  https://github.com/tianocore/edk2

I don't think either of them will die. But I do believe that there is no
real disadvantage of running U-Boot + uEFI Linux entry point over U-Boot
+ native booti entry point.

Since some work (like kASLR) depends on the uEFI entry point, I don't
think there's much need for the booti in the future. But I like to be
proven wrong :).

> 
>>
>> But yes, please be my guest and suggest device tree properties to the Linux device tree list that allow exposure of tables (I’m not sure whether anything beyond SMBIOS makes sense for a dt based system) to Linux on non-EFI boot.
> 
> If I get a server system one day I might do that. I don't have one yet.

The easiest way to get one is to run QEMU! :)


Alex