Maxime, > On 21 Feb 2017, at 18:45, Maxime Ripard <maxime.rip...@free-electrons.com> > wrote: > > Hi Philipp, > > On Fri, Feb 17, 2017 at 06:31:29PM +0100, Philipp Tomsich wrote: >> Motivated by the the SPL layout for SD/MMC devices on Allwinner SoCs >> (the SPL code needs to reside an 8K offset into the device), we add >> support for leaving a gap between the MBR (LBA#0), GPT header (LBA#1) >> and GPT partition entries (linked from field in the GPT header). >> >> Note that this affects the creation of partition from U-Boot only and >> has no effect on reading existing partition tables. >> >> If defined, EFI_PARTITION_ENTRIES_OFF specifies a byte-offset into >> a device and the parititon entries will be located starting at the >> next LBA folling this offset. >> >> In the latest incarnation of this change, we also allow the byte >> offset to be read from the 'u-boot,efi-partition-entries-offset' >> property of the '/config' node in the device-tree. >> >> There's a similar change for gparted floating around the internet: >> >> http://lists.alioth.debian.org/pipermail/parted-devel/2016-March/004826.html >> >> This change has been in production use on our modules for a while >> (over a year) both with a Linux and Android userspace. > > Nice patch. We came up with the same need, but had to restrict the > number of partitions in order to achieve the same goel. This is > obviously a much better solution. > > However, I'm a bit skeptical on the /config node. First, this node > doesn't exist at all, and needs to be documented and acked by the DT > maintainers. And why would one need to change that per device?
We are currently using the #define for production deployments, but we have gotten the feedback that it would be nice to change this setting easily without recompiling. We also use different settings for the sun6i/sun9i and sun50i modules, as code-size increases with AArch64 code... > Also, and this is something that affects all your patches, you > generated them with way too many context, which makes review more > difficults, and make them more conflicts prone. git format-patch > should just do the right thing. Yes, I noticed that too, but apparently had my setup misconfigured on Friday—you can probably imagine that pushing all these out on one day was a bit hectic. > Threading is also kind of broken (even though that's not really a big > deal). git send-email with --no-chain-reply-to will just work too. > > Thanks! > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux and Kernel engineering > http://free-electrons.com <http://free-electrons.com/> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
