Co-existence of GPT and fixed partitions (Was: Re: [PATCH v6 5/6] block: add support for partition table defined in OF)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

> +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?

So this only leaves the matter of dealing with both fixed-partitions and
GPT for the same device node.

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.

Thanks,
Ahmad



-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux