[OE-core] [PATCH V3] u-boot-fw-utils: Add support for libubootenv

Stefano Babic sbabic at denx.de
Fri Jan 3 11:05:49 UTC 2020

Hi Richard,

On 03/01/20 11:40, Richard Purdie wrote:
> On Fri, 2020-01-03 at 11:15 +0100, Stefano Babic wrote:
>> libubootenv is a replacement for u-boot-fw-utils. It is
>> hardware-independent and provides fw_printenv and fw_setenv tools
>> that
>> are full compatible with the ones provided by U-Boot. A library is
>> provided to access the environment from an own application.
>> License is LGPL-2.1 and this allow to link the library to proprietary
>> code. The user of the tools should install the configuration file
>> "fw_env.config", as he is already used to with u-boot-fw-utils. The
>> configuration file is compatible with u-boot-fw-utils.
>> +PROVIDES += "u-boot-fw-utils"
>> +RPROVIDES_${PN} += "u-boot-fw-utils"
> What is the ultimate intention/end goal here? Does this replace u-boot-
> fw-utils? 

Frankly speaking, yes. The topic was discussed more as a year ago on
U-Boot's ML, and libubootenv is the result of this (long) discussion:


One of the major goal is to solve the fragile connection between u-boot
and u-boot-fw-utils. The need to syncronize u-boot with u-boot-fw-utils
has always been a pitfall, specially when projects sets a custom BSP
layer replacing U-Boot with a custom recipe, and then people wonder why
board is bricked. Licensing (LGPL2.1 instead of GPLv2) is another major
goal, too, that libubootenv solves.

> Should we remove the other recipe?

libubootenv is thought to be full compatible with u-boot-fw-utils, and
it was already pushed in many projects. So yes, my proposal and final
goal is then to drop u-boot-fw-utils.

Anyway, I do not know if you prefer to have a "transition" time with
both recipes or it is fine for you to drop soon u-boot-fw-utils.

Best regards,

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de

More information about the Openembedded-core mailing list