On 26 August 2014 11:39, Laszlo Ersek <ler...@redhat.com> wrote: > On 08/25/14 21:19, Ard Biesheuvel wrote: >> This adds the possibility to include a DTB blob into the firmware image, and >> have it installed as a configuration under the correct GUID at UEFI init >> time. >> >> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> >> --- [...] > > I'm trying to familiarize myself with the structure of this series. > > Before I get to the real meat (or what I consider to be the "real > meat"), I'd like to ask why we need this patch. I searched the other > patches for "FdtTableDxe", and I got no hits. >
This patch does two things: - declare a GUID for a device tree configuration table - implement a driver that takes an embedded FV containing a device tree blob and install it as a configuration table under the declared GUID The latter part is not used in this series, but the GUID /is/ used by VirtFdtDxe.c to install the device tree as a config table. This is what allows the kernel to boot straight from UEFI without having to pass -dtb arguments and have the EFI stub perform the load. Granted, this is somewhat of a bonus, and the EFI stub does support dtb=, but we disable it for secure boot because loading unauthenticated data and install it right into the heart of the kernel is considered a security hazard. So i could split it up and move the part we need under ArmPkg, and drop the other half, I suppose. I know Olivier is also working on device tree integration, so perhaps he could chime in as well? @Olivier:? > As far as I understand, this functionality is useful for the linaro > tree, and some of the physical hardware platforms. In a virtual machine > though, the DTB will always come from QEMU, so for aarch64 VM support, > this patch doesn't appear to be necessary. > The point is not where the device tree came from, but where it goes to ... > Can you drop it from this series? (Along with 02/10, using the FDF > change you described before.) I'd like to reduce the things I must > understand to a minimum. > > Additionally, adding anything at all to MdePkg and MdeModulePkg is > pretty hard in upstream edk2, so if we don't have to, let's not try. :) > If you drop the first two patches, then your series remains in the > confines of ArmPkg and ArmPlatformPkg. I can't stress enough how much > easier that makes it for your series to get applied. > Agreed. -- Ard. ------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
