[U-Boot] [PATCH v2 2/2] cmd: Add 'bcb' command to read/modify/write BCB fields

[Alex Kiernan]

On Tue, May 21, 2019 at 10:14 AM Eugeniu Rosca <erosca at de.adit-jv.com> wrote:
>
> Hi Lukasz,
>
> On Tue, May 21, 2019 at 10:02:34AM +0100, Alex Kiernan wrote:
> > On Tue, May 21, 2019 at 9:37 AM Lukasz Majewski <lukma at denx.de> wrote:
> > >
> > > Hi Alex,
> > >
> > > > On Mon, May 20, 2019 at 8:23 AM Eugeniu Rosca <erosca at de.adit-jv.com>
> > > > wrote:
> > > > >
> > > > > >
> > > > > > Should it default to enabled if avb is used?
> > > > >
> > > > > I think at this specific moment in time, 'bcb' is orthogonal
> > > > > (meaning it is neither a direct, nor a reverse dependency) to any
> > > > > other Android feature in U-Boot. This could be re-assessed, if
> > > > > platform maintainers start to rely on 'bcb' in their U-Boot
> > > > > environments on regular basis.
> > > >
> > > > 'bcb' looks like something I'd be interested in, not running Android
> > > > at all... currently I (ab)use the bootcounter to communicate between
> > > > the kernel and U-Boot when I want to force a board through recovery,
> > >
> > > I don't know your exact use case, but wouldn't it be better to use envs
> > > (with redundancy) and fw_setenv / fw_printenv from Linux user space?
> > >
> > > Now those envs even support setting default values for u-boot (as there
> > > is now separate library used for it). Moreover there is OE/Yocto's
> > > recipe 'u-boot-fw-utils' which can be easily used and installed.
>
> That's a truly constructive suggestion. Nevertheless, I believe this
> would not work in case of CONFIG_ENV_IS_NOWHERE=y, which is how U-Boot
> is built and used by the developers in our organization.
>

That's how we build/run too, but with with hackery like this in a boot
script to pick pieces out of the legacy world:

        mmc dev ${mmcdev}
        mmc read ${loadaddr} 1300 100
        env import -c ${loadaddr} 20000 ethaddr

Yes, it's ugly...

-- 
Alex Kiernan