On Tue, May 21, 2019 at 10:14 AM Eugeniu Rosca <ero...@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 <lu...@denx.de> wrote: > > > > > > Hi Alex, > > > > > > > On Mon, May 20, 2019 at 8:23 AM Eugeniu Rosca <ero...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot