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

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

On Wed, Feb 11, 2026 at 10:37:18AM +0100, 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.
> > 
> > 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/
> 
> I am interested to hear thoughts on it.
> Compared to our suggestion, there will be no eventual removal of the node.

Seems to match mostly what I said, only that instead of a
warn-deprecated-env property you suggest a different compatible which
I think better matches what we are doing. Whether or not we remove the
fallback nodes in future is something our future-selves can discuss.

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 |