[U-Boot] [PATCH v1 0/2] disk: efi: allow gap before partition entries

[Dr. Philipp Tomsich]

Maxime,

> On 21 Feb 2017, at 18:45, Maxime Ripard <maxime.ripard at 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/>