Hello Christian, Thanks for the prompt response. On 05.12.24 12:54, Christian Marangi (Ansuel) wrote: >> 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. Good to know. Thanks. >> 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? The kernel isn't modified, but the barebox-state utility can parse the fixed partitions in the DT and map it via udev to a block device partition (if one exists) or to a block device + offset. >> 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. Yes, but Boot partitions and the user area are different block devices, so it should be possible to use OF partition for the boot partitions and GPT for the user area, right? >> 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) As mentioned, the kernel itself isn't patched, but there was an implicit assumption that MBR/GPT parsing would continue to work, even when a fixed partition node is specified... >> 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. If we go this way, the implementation should of course refuse creating partitions that conflict. The barebox implementation allows partitions only in the unpartitioned space or to be identical to an existing GPT partition. But I agree, this needs to be thought through thoroughly to determine how it should interact with runtime repartitioning. > 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) Yes, keeping OF_PARTITION disabled would be required to not break barebox users that made use of the non-upstream binding. I wonder though, if something can be done to reconcile Linux and barebox' view of this and allow in the future enabling both Linux OF_PARTITION and barebox OF partition fixups. > 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. Many of the older boards supported by barebox used to place the barebox image and the environment prior to the first partition in the unpartitioned area. To still be able to access them, fixed partitions were used and the rest of the system was described by MBR/GPT partitions. This was partially made necessary by BootROMs having strange expectations of where the bootloader needs to be placed, which partially overlapped the MBR/GPT itself, making it difficult to define a partition for the bootloader. For newer boards, it's more common to place the bootloader in a GPT partition now. barebox has no DT binding for generically describing such a GPT partition though, so boards may create a fixed-partition "alias" and use that. Cheers, 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 |
