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

[Simon Glass]

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?

Regards,
Simon