Re: [RFC PATCH] ARM: dts: i.MX8MP: remove barebox environment handling

[Sascha Hauer <s.hauer@pengutronix.de>]

On Wed, Feb 11, 2026 at 11:14:51AM +0100, Marco Felsch wrote:
> Hi Sascha, Ahmad,
> 
> On 26-02-11, Ahmad Fatoum wrote:
> > Hi,
> > 
> > On 2/11/26 8:53 AM, Sascha Hauer wrote:
> > > On Tue, Feb 10, 2026 at 11:13:40PM +0100, Marco Felsch wrote:
> > >> While specifying the barebox environment within the barebox dts is very
> > >> helpful for standalone barebox development it's difficult for BSPs which
> > >> use this development platform and want to use the GPT mechanism.
> > >> As a result BSPs had to manually delete the nodes via a external
> > >> provided dts, because we wanted to keep the comfort for the standalone
> > >> development flow.
> > >>
> > >> Lucky commit 86531d4bf7aa ("commands: create createnv command")
> > >> introduced a convenient helper to create a barebox environemnt on
> > >> demand exactly for this purpose:
> > >>
> > >> | "We want to move away from describing the barebox environment explicitly
> > >> | in the device tree and instead motivate usage of GPT partitions.."
> > >>
> > >> So start with the i.MX8MP-EVK to encourage the use of GPT partitions and
> > >> to make the BSP integration for these development platforms easier.
> > > 
> > > Generally I like this idea, but it breaks the existing users
> > > environment and doing this sharp cut might be annoying for the phase
> > > where you switch between different barebox versions which could be quite
> > > common for development boards.
> 
> Good point, albeit commit 86531d4bf7aa is part of v2025.08.0, so it's
> ~6months old. I also don't know how often i.MX8MP-EVK barebox features
> are implemented which require to jump between barebox versions.

Jumping between versions is something that just happens, be it for
bisecting or you have a development and stable branch for a BSP with
different barebox versions.

> 
> > > Would be great to have a grace period in which we prefer the UUID
> > > environment over the device tree environment (we might do this already)
> > > and warn in case we still use the latter. We could stick the warning to
> > > a device tree property like "warn-deprecated-env" and remove the
> > > environment once they carry this property for a year or so.
> > > 
> > > Just the ideas from the top of my head. Thoughts?
> > 
> > Here's my opinion from a year back:
> > https://lore.barebox.org/barebox/1ff0f545-effa-4b87-81b7-524919333777@pengutronix.de/
> 
> Thanks for the link, I fogot that I've send somthing similar already ^^
> 
> > I am interested to hear thoughts on it.
> > Compared to our suggestion, there will be no eventual removal of the node.
> 
> Both your suggestions are very similar and provide a smother transistion
> though. I would like to get rid of the old OF-env handling completely
> and therefore prefer Sascha's approach a bit more. Having a fallback is
> good, but fallbacks tend to crumble over time since they aren't tested.

I like Ahmads approach with a different compatible better as it makes
clear that it's only used as a fallback. Whether we
remove the device tree nodes from the repository or not doesn't matter
now, we can decide that later with both approaches.

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 |