Aw: Re: Re: barebox extending boot-scripts

Frank Wunderlich frank-w at
Thu Jan 6 04:41:39 PST 2022

thanks for answer. tried to strip mail it a bit down ;)
> Gesendet: Donnerstag, 06. Januar 2022 um 09:08 Uhr
> Von: "Sascha Hauer" <sha at>
> On Wed, Jan 05, 2022 at 07:13:22PM +0100, Frank Wunderlich wrote:

> > > > DEFAULT_ENVIRONMENT_PATH [=arch/arm/boards/rockchip-rk3568-evb/defaultenv]
> > > The config option is meant for use with external build systems, e.g. buildroot
> > > or PTXdist. For boards in-tree, you can add bbenv-y in the Makefile and call
> > >
> > >   // assuming directory is called defaultenv-myboard
> > >   defaultenv_append_directory(defaultenv_myboard);
> > >
> > > in the board code, see e.g. arch/arm/boards/embest-marsboard for an example.

if i understand it right i need to create a dir


with dirs nv (variables) and boot (bootscripts)

and add
bbenv-y += defaultenv-rk3568

> > > Boot scripts for publicly available evaluation kits are often not good candidates
> > > for upstreaming, because everybody using the EVKs has different thoughts on how to
> > > boot. The best way would be to use bootloader spec. It's one or more files you
> > > place at a known location that describe where your kernel and device tree are and
> > > what command line arguments to use and barebox can then automatically generate
> > > boot entries from all available bootloader spec files.

is extlinux (i used in uboot and conf-file is already present) supported here?

> > > See for an example
> > > of how to set this up. This is what I'd recommend instead of writing your own
> > > scripts.

i do not fully understand the bootloader spec in the pdf as config file seems to be


and then
boot -d mmc0.4

is the path (loader/entries) seems to be fixed and all files there will be processed (which order)?
how is root appended (/dev/mmcblkXpY|uuid|...) when linux-appendroot is set to true?

sorry for asking dumb questions but i want to understand how to do it right and not only doing anything ;)

> > > > ./defaultenv/defaultenv-2-menu/menu/10-boot-all/net
> > > >
> > > > seems to be a menu entry, but have not yet figured out how i can define one to add my scripts too
> > > >
> > > > have not found anything for it in the documentation yet
> > >
> > > The default boot menu is populated with the boot entries extracted from
> > > the contents of $global.boot.default.
> >
> > currently only net is listed there
> >
> > barebox at Rockchip RK3568 EVB:/ echo $global.boot.default
> > net
> >
> > but in /env/boot i have my 2 new scripts
> >
> > barebox at Rockchip RK3568 EVB:/ ls /env/boot
> > bnet          mmc-linux     net           tftp-linux
> >
> > > boot -m will display that menu. It will also include all bootloader spec files.
> > > If that suffices, you won't need to create your own menu. If you want though,
> > > check the help text of the menutree command.
> >
> > needed to add this option, and now it prints only "net" and "back",not my own scripts ;(
> >
> > do i need my scripts to ./defaultenv/defaultenv-2-menu/menu/10-boot-all/ too?

do i need to propagate my own scripts somewhere to be listed in the bootmenu?

in cmdline i had tried this:

global.boot.default="net mmc-linux tftp-linux"
boot -m

which works, but how can i set this variable at compile-time?

is the right way creating a file
defaultenv/defaultenv-2-base/nv/boot.default (or arch/arm/boards/rockchip-rk3568-evb/defaultenv-rk3568/nv/boot.default)
with the content i want? so it looks like in the pdf above ("global.variable s, these are initialized from the
correspoding non-volatile nv.variable s")

> > > To boot into the boot menu, set nv autoboot=menu. "Detect bootsources" will
> > > list boot sources known to the barebox boot command.
> >
> > is this stored anywhere so that is persistent on next reboot?
> Variables beginning with 'nv.' are stored in the environment
> automatically.
> >
> > btw. how does saveenv exactly work (which part/filename/offset is
> > used)? sasha told me that device will be enumerated to the current
> > boot device, but where on this device is the env stored?
> Normally it's described in the device tree:
> 	environment-emmc {
> 		compatible = "barebox,environment";
> 		device-path = &environment_emmc;
> 	};
> The device-path property points to a partition on the eMMC:
> &sdhci {
> 	...
> 	partitions {
> 		compatible = "fixed-partitions";
> 		environment_emmc: partition at 408000 {
> 			label = "barebox-environment";
> 			reg = <0x0 0x408000 0x0 0x8000>;
> 		};
> 	};
> };

thx, if i understand it right, then it's an offset/size defined in dts by reg-property. My board uses the same values which is iirc a bit above the 4M position (0x408000,4M=0x400000).
As i don't have a real partition there (first partition is at 8M), so i guess it is directly written (no file, like ENV_OFFSET in uboot). The 0x8000 should be the size (32kByte like ENV_SIZE), right?

> > > See magicvar for a listing of all magic variables, or refer to the documentation.
> > >
> > > > btw. is there a way to use ls with wildcard without printing the path?
> It works for example with:
> for i in /mnt/sd.1/extlinux/Image*; do basename $i b; echo $b; done

nice, that makes it a bit more usable like using numbers to choose

i=0;for f in /mnt/sd.1/extlinux/Image*; do basename $f b; echo "$i:$b";let i++; done

> But anyway, I'm with Ahmad here, you should rather look into bootloader
> spec. The shell is nice to have, but it's even nicer to not have to use
> it.

this is for testing multiple kernels with changing filenames (very dynamic process, e.g. using 1 kernel binary with multiple dtb) and to avoid adding a bootmenu entry everytime....this is not for end-user :)

and here scripting is imho the best way...this allows me to add extra params to cmdline too (like debug level,dumping offsets) without changing a distroboot config

for fixed kernels i have defined an extlinux.conf for uboot, but i'm unsure if barebox can use this file too. have not found anything about extlinux/syslinux in barebox yet.

More information about the barebox mailing list