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

[Simon Glass]

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
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.

>
> 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?

>
> 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.

Regards,
Simon