Hi Alexander,
On 9 August 2016 at 08:11, Alexander Graf agraf@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@suse.de wrote:
Am 08.08.2016 um 23:44 schrieb Simon Glass sjg@chromium.org:
Hi Alexander,
On 8 August 2016 at 08:06, Alexander Graf agraf@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