On Wed, Oct 02, 2024 at 11:20:37AM +0200, Rasmus Villemoes wrote: > Andy Shevchenko <andy@xxxxxxxxxx> writes: > > On Mon, Sep 30, 2024 at 01:30:07PM +0200, Christian Marangi wrote: ... > >> this is an initial proposal to complete support for manually defining > >> partition table. > >> > >> Some block device also implement boot1 and boot2 additional disk. Similar > >> to the cmdline parser, these disk can have OF support using the > >> "partitions-boot0" and "partitions-boot1" additional node. > >> > >> It's also completed support for declaring partition as read-only as this > >> feature was introduced but never finished in the cmdline parser. > > > > I'm not sure I fully understood the problem you are trying to solve. > > I have a device at hand that uses eMMC (and was produced almost ten years ago). > > This device has a regular GPT on eMMC and no kernel needs to be patched for that. > > So, why is it a problem for the mentioned OEMs to use standard GPT approach? > > For the user area (main block device), yes, a GPT can often be used, but > not always. For the boot partitions, the particular SOC/cpu/bootrom may > make it impossible to use a standard partition table, because the > bootrom expects to find a bootloader at offset 0 on the active boot > partition. In such a case, there's no way you can write a regular MBR or > GPT, but it is nevertheless nice to have a machine-readable definition > of which data goes where in the boot partitions. With these patches, one > can do > > partitions-boot0 { > partition@0 { > label = "bootloader"; > reg = <0 0x...>; // 2 MB > } > partition@... { > label = "device-data"; > reg = <...> // 4 MB > } > } > > and describe that layout. I see now, on the device I mentioned the firmware is located on a boot partition, so the user ones are being used for bootloader and the OS. -- With Best Regards, Andy Shevchenko