mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <trent.piepho@igorinstitute.com>
To: Sascha Hauer <sha@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 3/3] state: support backend-diskuuid / backend-offset
Date: Thu, 27 Jan 2022 10:53:33 -0800	[thread overview]
Message-ID: <CAMHeXxMCGpq4+jkhU0hOHy6x6sn9a2=gUW_rfhfF9UtSZZNpDQ@mail.gmail.com> (raw)
In-Reply-To: <20220127123924.GQ23490@pengutronix.de>

Could a linux dtb fixup be done in barebox?  This way userspace will
only have existing properties: storage devices with partitions
node(s), and barebox-state backend that points to a partition.  In
this case, the partition node was added by Barebox.

In fact, Barebox already does partition fixups exactly like this.  So
I think this would probably already happen.  It won't work if Linux
dtb does not have the storage device at all, as the partition fixup
considers that an error.  But maybe the Linux dtb will have the
storage device node?  Or if it doesn't have it because the storage is
"too dynamic" to put into the dts, then another fixup can make the
node.

On Thu, Jan 27, 2022 at 4:39 AM Sascha Hauer <sha@pengutronix.de> wrote:
>
> On Wed, Jan 26, 2022 at 04:18:51PM -0800, Trent Piepho wrote:
> > DTS ranges are usually specified as <offset> <length> in one property.
> > The sizes of offset and length fields are done with the #address-cells
> > and #size-cells of the bus the node is on.  I.e., barebox state
> > shouldn't be defining if offsets or lengths are 32 or 64 bits, it
> > should/is done by the device the offset or length refers to.
> >
> > Like the normal 'reg' property in most nodes for register banks, or
> > the various "ranges" properties map an address space in the current
> > node to one in another node.
> >
> > This backend-diskuuid, backend-offset, and backend-length seems like a
> > custom alternative version of a range that is specific to barebox
> > state.  Also, if the backend is a partition defined in the dts, then
> > the node of the partition specifies its size.  But if the partition is
> > found by uuid, then the barebox state device specifies the size of the
> > partition.  Seems inconsistent.
> >
> > It seems like there should be a better and more consistent way to do this.
> >
> > Here's an idea.  Identify the device by uuid and use existing
> > fixed-partitions.  Example:
> >
> > {
> >     compatible = "storage-by-uuid";
> >     uuid = "abcd-1234";
> >     // Everything below here already exists and is unchanged
> >     partitions {
> >         compatible = "fixed-partitions";
> >         barebox_state: state@1000 {
> >             label = "barebox-state";
> >             reg = <0x1000 0x200>;
> >         };
> >         barebox_env: env@1200 {
> >             label = "barebox-env";
> >             reg = <0x1200 0x1000>;
> >         };
> >     };
> > };
> >
> > When the top level node here is found, the matching device is located
> > by uuid and contents of the node are added to that device.  Adding
> > fixed partitions is done the same way it's already done.  The
> > difference is we can specify the device by uuid instead of needing to
> > locate the path of the exact hardware device.
>
> We discussed this approach internally as well and decided for the way
> Michael has implemented it for two reasons. First it is easier to
> implement, if not in barebox, but in Linux userspace where we need to
> parse that binding as well. Second we don't need another barebox custom
> binding when we extend the existing custom binding.
>
> The fact that with the current approach we have to know that an
> arbitrary property contains a 64bit value rather than the default 32bit
> made me think if the approach of having a compatible =
> "storage-by-uuid" driver is really the better one. I know that Ahmad
> agrees here as well :)
>
> Sascha
>
> --
> 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 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


  reply	other threads:[~2022-01-27 18:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-24 10:04 [PATCH 0/3] state: find backend with UUID but without a partition Michael Olbrich
2022-01-24 10:04 ` [PATCH 1/3] cdev: rename partuuid to uuid Michael Olbrich
2022-01-24 10:04 ` [PATCH 2/3] cdev: add diskuuid support Michael Olbrich
2022-01-24 10:04 ` [PATCH 3/3] state: support backend-diskuuid / backend-offset Michael Olbrich
2022-01-26  7:57   ` Sascha Hauer
2022-01-26  9:35     ` Michael Olbrich
2022-01-26 10:15       ` Sascha Hauer
2022-01-26 11:16         ` Michael Olbrich
2022-01-27  0:18           ` Trent Piepho
2022-01-27 12:39             ` Sascha Hauer
2022-01-27 18:53               ` Trent Piepho [this message]
2022-01-28  7:48                 ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMHeXxMCGpq4+jkhU0hOHy6x6sn9a2=gUW_rfhfF9UtSZZNpDQ@mail.gmail.com' \
    --to=trent.piepho@igorinstitute.com \
    --cc=barebox@lists.infradead.org \
    --cc=sha@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox