On 12.08.16 19:20, Simon Glass wrote: > 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
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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
