Date: Mon, 18 Dec 2017 17:49:18 +0100 From: Emmanuel Vadot <manu@bidouilliste.com> To: Ian Lepore <ian@freebsd.org> Cc: Daniel Braniss <danny@cs.huji.ac.il>, freebsd-arm@freebsd.org Subject: Re: ubldr question Message-ID: <20171218174918.c6aa89984174ce41d500b5b7@bidouilliste.com> In-Reply-To: <1513611489.95072.45.camel@freebsd.org> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <1513611489.95072.45.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Dec 2017 08:38:09 -0700 Ian Lepore <ian@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@freebsd.org> wrote: > >=20 > > >=20 > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > >=20 > > > > 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. > > > >=20 > > > > So, apart from stoping the loader, and typing ?env set fdtfile > > > > xxx.dtb? > > > > is there another way? > > > >=20 > > > > cheers, > > > > danny > > > >=20 > > > You should be able to "saveenv" after making your change. > > >=20 > > > The uEnv.txt that used to be supported was to make it possible to > > > programatically change the boot behavior from freebsd userland. =A0Th= at > > > 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. =A0It's a lot less work for t= he > > > port maintainers, but we lost some functionality along the way. > > >=20 > > > -- Ian > > =A0We 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. > > =A0One 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). > > =A0As 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). > >=20 >=20 > The uEnv.txt file never had anything to do with=A0ENV_IS_IN_FAT or > anything else related uboot's builtin features for saving/loading the > environment. =A0It 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. =A0On some systems, especially if loader(8) is in use, > that can be controlled through the MBR or GPT. =A0On other systems, those > things may not be an option, and uEnv.txt was the always-available > mechanism. >=20 > So yeah, we definitely lost something. =A0It wasn't well-documented, and > from the lack of complaints up until now, I guess it wasn't something > that was widely used. =A0But it's just one of several important (IMO) > features of the old uboot ports that we lost. =A0The 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. > =A0"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. >=20 > -- 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@freebsd with my finding and the pro/con of using each solution. Cheers, --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171218174918.c6aa89984174ce41d500b5b7>