ubldr question

[Emmanuel Vadot]

On Mon, 18 Dec 2017 08:38:09 -0700
Ian Lepore <ian at freebsd.org> wrote:

> 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).

 Yes sorry, I always (don't know why, maybe the name ...) mix up thoses
two.

> 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

 I agree that we lost something then, I'll see what I can do.

 As you said it was done for pingpong support, which release image do
not provide, I try to provide something that work for 99% of the users
(which either download a snapshot/release or build their own with
crochet or similar tool. I expect users that want something
better/different as what we provide in the image to be able to come
up with a solution that fix their needs.

 As a general rule for u-boot : we have almost catched upstream and all
the modification should go there (but we can cherry-pick commits for
our ports).
 Also I'm currently looking at what to do for loading ubldr.bin, the
u-boot guys told me to use scripts (u-boot.scr) but they will be
deprecated in the near future and u-boot will only use EFI or
syslinux.conf, I'll start a thread soon on uboot at freebsd with my
finding and the pro/con of using each solution.

 Cheers,

-- 
Emmanuel Vadot <manu at bidouilliste.com> <manu at freebsd.org>