[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zv5q90Dc_VzA4xs3@smile.fi.intel.com>
Date: Thu, 3 Oct 2024 12:59:19 +0300
From: Andy Shevchenko <andy@...nel.org>
To: Rasmus Villemoes <linux@...musvillemoes.dk>
Cc: Christian Marangi <ansuelsmth@...il.com>, Jens Axboe <axboe@...nel.dk>,
Jonathan Corbet <corbet@....net>,
Ulf Hansson <ulf.hansson@...aro.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Kees Cook <kees@...nel.org>,
Daniel Golle <daniel@...rotopia.org>,
INAGAKI Hiroshi <musashino.open@...il.com>,
Christian Brauner <brauner@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Li Lingfeng <lilingfeng3@...wei.com>,
Ming Lei <ming.lei@...hat.com>,
Christian Heusel <christian@...sel.eu>, linux-block@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
linux-hardening@...r.kernel.org,
Miquel Raynal <miquel.raynal@...tlin.com>,
Lorenzo Bianconi <lorenzo@...nel.org>, upstream@...oha.com
Subject: Re: [PATCH v4 0/5] block: partition table OF support
On Wed, Oct 02, 2024 at 11:20:37AM +0200, Rasmus Villemoes wrote:
> Andy Shevchenko <andy@...nel.org> 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
Powered by blists - more mailing lists