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@xxxxxxxxxxxxxx> > 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@Rockchip RK3568 EVB:/ echo $global.boot.default > > net > > > > but in /env/boot i have my 2 new scripts > > > > barebox@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@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. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
