On Mon, 2018-07-16 at 22:28 +0000, Henry Beberman wrote: > Hi Trent, > > > -----Original Message----- > > From: Trent Piepho <tpie...@impinj.com> > > Sent: Monday, July 16, 2018 10:17 AM > > To: Henry Beberman <henry.beber...@microsoft.com>; u- > > b...@lists.denx.de > > Cc: tr...@konsulko.com; fabio.este...@nxp.com > > Subject: Re: [U-Boot] [PATCH 01/11] imx: Add bootcmd to load and run UEFI > > from mmc > > > > On Sat, 2018-07-14 at 00:11 +0000, Henry Beberman wrote: > > > From: Henry Beberman <henry.beber...@microsoft.com> > > > > > > This patch enables i.MX platforms to easily add a boot script to their > > > U-Boot Proper environment to automatically load and execute an EFI > > > firmware from the first FAT partition of an MMC device. > > > > Is there a reason to force the first partition instead of using the EFI > > partition > > code to select which partition to boot? > > > > I also wonder, on a Linux system, is there a reason the EFI partition must > > use > > FAT? > > I need to revise the commit message for this patch. The script is not fixed > to the first partition of the selected MMC, it scans the disk for partitions > marked bootable, then checks each one of those until it finds the > imxboard_efi.fd binary.
That is indeed very different from first FAT partition. Does bootable only apply legacy MBR partition tables? I didn't think bootable was typically used with GPT tables. There is a bit, but it's not used to mark EFI partitions. Which brings me back to the partition type. Isn't that the right way to find the EFI? > We could switch over to using the generic load from CONFIG_CMD_FS_GENERIC if > there's demand for non-FAT filesystems. We're currently using fatload because > the EFI partitions in our Windows images are always FAT formatted. You're original search method required the partition be FAT. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
