mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Frank Wunderlich <frank-w@public-files.de>
To: Sascha Hauer <sha@pengutronix.de>
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>, barebox@lists.infradead.org
Subject: Aw: Re: Re: barebox extending boot-scripts
Date: Thu, 6 Jan 2022 13:41:39 +0100	[thread overview]
Message-ID: <trinity-7a53a76e-9836-482e-861e-31439f242e2d-1641472899713@3c-app-gmx-bs51> (raw)
In-Reply-To: <20220106080838.GV6003@pengutronix.de>

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@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@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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


  reply	other threads:[~2022-01-06 12:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 15:20 Frank Wunderlich
2022-01-05 16:07 ` Ahmad Fatoum
2022-01-05 18:13   ` Aw: " Frank Wunderlich
2022-01-06  8:08     ` Sascha Hauer
2022-01-06 12:41       ` Frank Wunderlich [this message]
2022-01-07 13:07         ` Sascha Hauer
2022-01-07 16:42           ` Aw: " Frank Wunderlich
2022-01-10  9:42             ` Sascha Hauer
2022-01-15 13:47               ` Aw: " Frank Wunderlich
2022-01-17  8:59                 ` Sascha Hauer
2022-01-29 10:40       ` Aw: " Frank Wunderlich
2022-01-31 11:03         ` Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trinity-7a53a76e-9836-482e-861e-31439f242e2d-1641472899713@3c-app-gmx-bs51 \
    --to=frank-w@public-files.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=sha@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox