From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Jones Date: Mon, 7 Aug 2017 13:32:22 -0400 Subject: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions In-Reply-To: <201708042041.v74KfWP6022957@glazunov.sibelius.xs4all.nl> References: <20170804193205.24669-1-robdclark@gmail.com> <20170804193205.24669-14-robdclark@gmail.com> <201708042041.v74KfWP6022957@glazunov.sibelius.xs4all.nl> Message-ID: <20170807173222.zzi4goehjc4ya563@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Aug 04, 2017 at 10:41:32PM +0200, Mark Kettenis wrote: [...] > ..and what you're sketching out here should work with recent enough > versions of our bootloader. > > However, to me having an ACPI Device Path component in there doesn't > make much sense on a board without ACPI. It certainly doesn't help > mapping a boot path back to an actual hardware device. Wouldn't it be > more logical to a Hardware Device Path there instead? In particular a > Memory Mapped Device Path would make a lot of sense as the start > address would make it fairly easy to do the mapping. It was really an arbitrary choice, as Rob said. I don't think there's any big problem with changing it, but I'm not sure Memory Mapped is correct. As I read it, StartingAddress and EndingAddress in that class should be pointing at some window into a memory map entry that is holding the thing described /by/ the node, but there's really nothing here. It's just an arbitrary root node. If we want something other than the ACPI path I made up, we should probably just go with a Vendor Specific Device Path with a constant well-known GUID of our choosing. e61d73b9-a384-4acc-aeab-82e828f3628b, say. -- Peter