ubldr question

[Ian Lepore]

On Mon, 2017-12-18 at 10:48 +0100, Emmanuel Vadot wrote:
> On Sun, 17 Dec 2017 10:02:05 -0700
> Ian Lepore <ian at freebsd.org> wrote:
> 
> > 
> > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote:
> > > 
> > > Hi,
> > > in the past there was CONFIG.TXT and/or UENV.TXT where I could
> > > override the
> > > default .dtb file set by uboot, but now it seems these files are
> > > either not read, or the
> > > command has changed.
> > > 
> > > So, apart from stoping the loader, and typing ?env set fdtfile
> > > xxx.dtb?
> > > is there another way?
> > > 
> > > cheers,
> > > 	danny
> > > 
> > You should be able to "saveenv" after making your change.
> > 
> > The uEnv.txt that used to be supported was to make it possible to
> > programatically change the boot behavior from freebsd userland.  That
> > feature got lost when the uboot ports were all rewritten to use a
> > default environment (boot scripts and all) for freebsd that is
> > basically identical to what linux uses.  It's a lot less work for the
> > port maintainers, but we lost some functionality along the way.
> > 
> > -- Ian
>  We currently use the default for the boards for the env, the default
> value for most of the board is to put the env in the mmc (in the space
> reserved for u-boot) and not in the fat. There is some discussion to
> move the env in the fat by default for allwinner boards as u-boot is
> getting too big now.
>  One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot
> port is currently lacking of a proper way to customize the defconfigs
> (I'm currently working on this part) and I don't want to have too many
> patches (one for each board/soc).
>  As of functionality, I'm not sure we lost something, one can still
> create a u-boot script (u-boot.scr) and do everything he needs for a
> custom boot. (Also setenv/saveenv works as Ian said).
> 

The uEnv.txt file never had anything to do with ENV_IS_IN_FAT or
anything else related uboot's builtin features for saving/loading the
environment.  It was something we added as part of freebsd boot
support, to provide a way for userland software to control the boot
process without knowing anything about how uboot stores its env (which
can be completely inaccessible to running freebsd apps in some cases).

It was there specifically to support pingpong update schemes where
updates are applied to an inactive slice/partition/device, then some
persistant data is written that switches which slice/part/dev is used
for the next boot.  On some systems, especially if loader(8) is in use,
that can be controlled through the MBR or GPT.  On other systems, those
things may not be an option, and uEnv.txt was the always-available
mechanism.

So yeah, we definitely lost something.  It wasn't well-documented, and
from the lack of complaints up until now, I guess it wasn't something
that was widely used.  But it's just one of several important (IMO)
features of the old uboot ports that we lost.  The other major loss was
some standard env script vars that made it easy for a user to hook into
the boot process and customize it using just a 'setenv' command.
 "Write your own boot.scr" is nowhere near an adequate replacement for
the lost functionality of being able to set a variable or two in plain
text.

-- Ian