>
> Hi,
>
> sorry for not writing sooner. I only noticed this now.
>
> On 03.10.24 00:11, Christian Marangi wrote:
> > Add support for partition table defined in Device Tree. Similar to how
> > it's done with MTD, add support for defining a fixed partition table in
> > device tree.
> >
> > A common scenario for this is fixed block (eMMC) embedded devices that
> > have no MBR or GPT partition table to save storage space. Bootloader
> > access the block device with absolute address of data.
>
> How common are these? I never worked with a system that didn't use MBR
> or GPT for the user partition.
>
On router devices this is the approach for Mediatek and Airoha and also
other vendor for anything that have an eMMC.
Other device have a mixed nor/nand + eMMC but the eMMC
is used entirely for rootfs and not foor bootloader or other special partition.
> > This is to complete the functionality with an equivalent implementation
> > with providing partition table with bootargs, for case where the booargs
> > can't be modified and tweaking the Device Tree is the only solution to
> > have an usabe partition table.
> >
> > The implementation follow the fixed-partitions parser used on MTD
> > devices where a "partitions" node is expected to be declared with
> > "fixed-partitions" compatible in the OF node of the disk device
> > (mmc-card for eMMC for example) and each child node declare a label
> > and a reg with offset and size. If label is not declared, the node name
> > is used as fallback. Eventually is also possible to declare the read-only
> > property to flag the partition as read-only.
>
> barebox has for many years supported defining fixed partitions on SD/MMC
> nodes and it's used heavily to define e.g. the location of the barebox
> environment. Many who do so, do this either before the first partition
> of the MBR/GPT or overlay the fixed partition to be identical to
> an existing MBR/GPT partition.
>
> barebox also by default copies all fixed partitions it is aware of
> into the kernel DT, so if the kernel now stops parsing GPT/MBR when
> a fixed partition node is defined, this would break compatibility of
> existing barebox-booting systems with new kernels.
>
I'm not following... is that a downstream thing? Also fixed-partition
in DT for SD/MMC were never supported, why the partition was
copied in DT? Userspace tools made use of them?
> > +config OF_PARTITION
> > + bool "Device Tree partition support" if PARTITION_ADVANCED
> > + depends on OF
> > + help
> > + Say Y here if you want to enable support for partition table
> > + defined in Device Tree. (mainly for eMMC)
> > + The format for the device tree node is just like MTD fixed-partition
> > + schema.
>
> Thanks for making this configurable and disabled by default, so users
> won't experience breakage if they just do a make olddefconfig.
>
> > diff --git a/block/partitions/core.c b/block/partitions/core.c
> > index abad6c83db8f..dc21734b00ec 100644
> > --- a/block/partitions/core.c
> > +++ b/block/partitions/core.c
> > @@ -43,6 +43,9 @@ static int (*const check_part[])(struct parsed_partitions *) = {
> > #ifdef CONFIG_CMDLINE_PARTITION
> > cmdline_partition,
> > #endif
> > +#ifdef CONFIG_OF_PARTITION
> > + of_partition, /* cmdline have priority to OF */
> > +#endif
> > #ifdef CONFIG_EFI_PARTITION
> > efi_partition, /* this must come before msdos */
> > #endif
>
> If I understand correctly, it's possible to have both partitions-boot1 and
> a GPT on the user area with your patch, right?
>
No, this array works by, first is found WIN. If OF_PARTITION is enabled
and an OF partition is declared in DT, then efi partition parse is skipped.
> So this only leaves the matter of dealing with both fixed-partitions and
> GPT for the same device node.
>
The logic is applied to skip exactly this scenario. GPT partition can
be edited at
runtime and change, DT is more deterministic. It's one or the other.
If downstream someone have GPT then OF_PARTITION should not
be used at all... Eventually downstream for this special approach, an additional
downstream patch can be added that define a special property in the node to
disable OF parsing. (it's a 3 line patch and since everything is downstream it
really doesn't matter)
> What are the thoughts on this? An easy way out would be to make of_partition
> come later than efi_partition/mbr_partition, but I think it would be
> nice if the kernel could consume partition info out of both of_partition
> and efi_partition as long they don't collide.
>
The 2 thing would conflicts and would introduce so much complexity it might
be not worth at all. Also you would have situation where someone declare
OF partition in the space where the GPT partition table is located, adding
the possibility of corrupting it.
Again would love more explanation of your case because by the looks of it,
you use GPT for partition parsing and just overload the DT with the additional
info maybe for userspace usage. (and that case can be handled by just keeping
OF_PARTITION disabled or adding a little downstream patch)
Or you are telling me you had a downstream patch that declares additional
partition in addition to a disk with a GPT partition table?
If that's the case, I'm confused of why the additional partition can't
be declared
directly in GPT.
