Aw: Re: Re: barebox extending boot-scripts
Frank Wunderlich
frank-w at public-files.de
Thu Jan 6 04:41:39 PST 2022
Hi,
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 pengutronix.de>
> 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
arch/arm/boards/rockchip-rk3568-evb/defaultenv-rk3568
with dirs nv (variables) and boot (bootscripts)
and add
bbenv-y += defaultenv-rk3568
in
arch/arm/boards/rockchip-rk3568-evb/Makefile
> > > 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 https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf 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
/mnt/mmc0.4/loader/entries/stm32mp157c-dk2.conf
and then
boot -d mmc0.4
is run...so 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