Hi,
On 2/11/26 1:53 PM, Sascha Hauer wrote:
> 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.
Worth noting that we already have a way out: If someone's bisecting,
they can set global.env.autoprobe=0 (or disable CONFIG_INSECURE..) to
restore the old behavior.
>
>>
>>>> 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/[email protected]/
>>
>> 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 |
