Hi Alex, On 10 August 2016 at 01:29, Alexander Graf <ag...@suse.de> wrote: > >> On 09 Aug 2016, at 16:35, Simon Glass <s...@chromium.org> wrote: >> >> Hi Alexander, >> >> On 9 August 2016 at 08:11, Alexander Graf <ag...@suse.de> wrote: >>> >>> On 08/09/2016 03:57 PM, Simon Glass wrote: >>>> >>>> Hi Alexander, >>>> >>>> On 9 August 2016 at 00:48, Alexander Graf <ag...@suse.de> wrote: >>>>> >>>>> >>>>>> Am 08.08.2016 um 23:44 schrieb Simon Glass <s...@chromium.org>: >>>>>> >>>>>> Hi Alexander, >>>>>> >>>>>>> On 8 August 2016 at 08:06, Alexander Graf <ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
