flyback has quit [Remote host closed the connection]
flyback has joined #u-boot
qschulz has quit [Read error: Connection reset by peer]
zibolo has quit [Ping timeout: 252 seconds]
zibolo has joined #u-boot
qschulz has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 252 seconds]
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
persmule has quit [Ping timeout: 252 seconds]
jclsn has quit [Ping timeout: 264 seconds]
jclsn has joined #u-boot
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
camus has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 255 seconds]
camus1 is now known as camus
flyback has quit [K-Lined]
ikarso has joined #u-boot
camus has quit [Ping timeout: 240 seconds]
stipa has joined #u-boot
apteryx has quit [Ping timeout: 255 seconds]
apteryx has joined #u-boot
pgreco_ has joined #u-boot
pgreco has quit [Ping timeout: 258 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
apritzel has joined #u-boot
apritzel has quit [Ping timeout: 258 seconds]
prabhakarlad has joined #u-boot
f_ has joined #u-boot
slobodan has joined #u-boot
gsz has joined #u-boot
Leopold has quit [Quit: No Ping reply in 180 seconds.]
Leopold has joined #u-boot
jclsn has quit [Ping timeout: 245 seconds]
jclsn has joined #u-boot
mmu_man has joined #u-boot
Net147 has quit [Quit: Quit]
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
Net147 has quit [Client Quit]
dsimic has quit [Ping timeout: 255 seconds]
dsimic has joined #u-boot
goliath has joined #u-boot
Net147 has joined #u-boot
Net147 has quit [Changing host]
Net147 has joined #u-boot
stefanro has joined #u-boot
mmu_man has quit [Quit: reboot]
mmu_man has joined #u-boot
persmule has joined #u-boot
qqq has quit [Quit: leaving]
qqq has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
Perflosopher has joined #u-boot
apritzel has joined #u-boot
monstr has joined #u-boot
qqq has quit [Remote host closed the connection]
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #u-boot
monstr has quit [Remote host closed the connection]
stefanro has quit [Quit: Leaving.]
apritzel has quit [Ping timeout: 264 seconds]
pgreco_ has quit [Read error: Connection reset by peer]
pgreco has joined #u-boot
ukky has quit [Ping timeout: 255 seconds]
<Xogium>
hmm so might be a bit of a dummy question but I'm trying to use the same config of u-boot to boot an image from either micro sd or eMMC. I was thinking of using extlinux.conf but then realized that I can't share this between the images, as micro sd rootfs is on the 5th partition but eMMC is on the 2nd. Is my only way forward to script this and check if boot_device=mmc AND boot_instance=0 or 1 and setting
<Xogium>
different kernel cmdline based on this ?
ukky has joined #u-boot
vagrantc has joined #u-boot
monstr has joined #u-boot
monstr has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
f_|bnc has joined #u-boot
f_|bnc has quit [Remote host closed the connection]
f_|bnc has joined #u-boot
f_ has quit [Quit: zzz]
<marex>
Xogium: PARTUUID doesnt help ?
<Xogium>
marex: how could I specify the partuuid in extlinux config ? All the examples I've ever seen just use basic mmcblk0p4 for example
<Xogium>
I don't know how to tell it to find the partuuid of the device it booted from
f_|bnc is now known as f_
ldevulder has quit [Ping timeout: 240 seconds]
<marex>
Xogium: hum, maybe it is the other way around, i.e. extlinux passes partuuid to Linux
<Xogium>
well... In this case that won't help me given partuuid will also be different
<Xogium>
I mean I could define it, but the that brings its own set of problems, such as booting an image written on eMMC when you try to boot from micro sd and not realizing that you in fact didn't
<Xogium>
if they share the same partuuid/label
<Xogium>
in fact even the basic dev node like mmcblk0p3 won,t work because mmcblk0 is sd and mmcblk1 is eMMC
<marex>
Xogium: hum
<marex>
Xogium: can you plug a script into the extlinux stuff ?
<Xogium>
I don't know. I mean, I'm open to other ways besides extlinux, if you got them
<ukky>
Xogium: what is the idea behind such dual boot? Recovery? Test temporary rootfs?
<Xogium>
ukky: generic support for a board, including booting from all possible storage medium
<ukky>
How would you like to select active boot media, i.e. eMMC vs SD?
<Xogium>
the u-boot env from vendor already can figure out which medium u-boot was started from
<Xogium>
that is, it populate boot_device with mmc, and boot_instance with either 0 or 1
<Xogium>
then attempts to boot over mmc0 or mmc1
<ukky>
So, you have u-boot on both, mmc0 and mmc1?
<Xogium>
that could be a possibility. Or there could be only mmc0. Or only mmc1
<Xogium>
I don't know what people will choose to do, hence the generic aspect I aim for
<ukky>
What SW/FW loads your u-boot?
<Xogium>
tf-a+optee
<Xogium>
or well
<Xogium>
tf-a loads optee which is bl32 which then loads u-boot as bl33
<Xogium>
the biggest problem is identifying the device from which to boot linux from, basically
<Xogium>
it seems extlinux config is too basic for this as it expect a fixed root= cmdline easily usable across all devices, but this is simply not the case here
<Xogium>
and if it were, then you could launch u-boot from micro sd and accidentally select the rootfs on eMMC you put in there instead of the one on your micro sd
<Xogium>
so the only option I thought of would be a boot script rather than extlinux, which would do everything manually depeding on the value of boot_instance=0 or boot_instance=1
<Xogium>
depending
<ukky>
I have not done it yet for my device, but I plan to test grub2 as u-boot payload. Maybe you can try this too.
<Xogium>
still the same kind of issue then
<Xogium>
I'd still have to have different kernel command line for grub
<Xogium>
this is also all over serial console so I don't know how well the grub menu would even do over serial. I'm also not a fan of adding one more complex level to the boot chain which is already 3 softwares deep
<ukky>
What if you use per-media u-boot which root=PARTUUID specific to that media
<ukky>
s/which/with/
<Xogium>
that still won't work. You still have to specify 2 different partuuid in extlinux, which you can't do with a single config
<Xogium>
I'd need something able to determine the partuuid and dynamically assign it to the bootargs / cmdline when booting, I think
<marex>
Xogium: extlinux configures your kernel command line, right ?
<Xogium>
I can't rely on static things
<marex>
Xogium: cant you have variables in that kernel command line , which are passed through from U-Boot environment ?
<Xogium>
marex: well that was the plan here, but I suppose I could do it another way
<marex>
I mean, if U-Boot already knows where to load extlinux from, cant you pass it through ?
<Xogium>
I don't believe so. Tbf, I don't know. I haven't seen that much doc on extlinux.conf support in u-boot and if it lets you pass env variables
<marex>
Xogium: looking at doc/develop/distro.rst
<Xogium>
all I ever saw were hardcoded paths, for everything, even kernel and initramfs
<Xogium>
but maybe I didn't check the right kind of doc
<marex>
Xogium: hmmm, I really might be wrong about it, I vaguely recall seeing something, but it might've been something else
<ukky>
maybe using u-boot.scr to conditionally append root= parameter to kernel cmdline depending on state of boot_device and boot_instance?
<marex>
Xogium: well you can always try and add foo=${version} into 'append' assuming your U-Boot env contains $version variable , and see what happens
<marex>
ukky: indeed
<Xogium>
right that doesn't seem to work
<Xogium>
well I guess I'll have to fall back to boot.scr
<Xogium>
it's a very good thing linux now makes it possible to alias mmc devices, and that makes the dev nodes stable
<Xogium>
since I can neither rely on any uuid nor label
<Xogium>
labels would be identical and uuids will change at every build unless I hardcode them
mmu_man has quit [Ping timeout: 264 seconds]
<marex>
Xogium: indeed
<marex>
Xogium: PARTUUIDs work if you generate them in U-Boot for each boot and then pass them to Linux, then the stable mmc device assignment is not needed
<marex>
U-Boot has the stable assignment, but that's all that is needed
<Xogium>
right, makes sense
GNUtoo has quit [Remote host closed the connection]
<Xogium>
though in my case the partuuid and such is generated by genimage when putting the disk image together
GNUtoo has joined #u-boot
<Xogium>
the one thing I wonder about though is, once u-boot used boot.scr, will it attempt to use extlinux ?
<Xogium>
because I wonder if I might as well load kernel and dt in the script, and entirely get rid of extlinux config
<marex>
doc/develop/distro.rst search for 'script'
<marex>
It does go into some detail
<Xogium>
yep but that doesn't explain the relation between boot.scr and extlinux.conf, if there's any to be had
<marex>
Xogium: and include/config_distro_bootcmd.h ?
<marex>
Xogium: that's where the distro boot command scripts resize
<Xogium>
lets see
<marex>
search boot.scr
<marex>
its closer to the end
<Xogium>
basically what I wonder about here is if I were to use a boot script that would set different bootargs based on the mmc device being used, could I then send boot command and have linux booting because u-boot would still search for a extlinux config ? Based on what I'm reading here, it doesn't seem likely
<Xogium>
I think what would happen is the boot.scr would be executed in a loop because it would be found by distrocmd and such, before extlinux
<marex>
vagrantc: ^
<marex>
Xogium: I can imagine you can run bootm/booti directly from the script, or trigger extlinux which would trigger I think what is in cmd/pxe ?
<Xogium>
hmm yes, that may be possible
<Xogium>
env already has a nice boot_syslinux
<Xogium>
so I could run that, presumably
<marex>
I think boot/pxe_utils.c pxe_process() is what ultimatelly handles the extlinux.conf
<marex>
Xogium: interesting, look at 'localcmd' (git grep for it in the source tree)
<Xogium>
oh
<Xogium>
both boot.scr an extlinux are set up to load at the very same memory address
<Xogium>
they both would ultimately use scriptaddr
<Xogium>
something tells me that running sysboot with the same scriptaddr as the script which is trying to use sysboot = bad idea, but what do I know ;)
<Xogium>
I checked that localcmd thing, but I don,t quite get what it does
mmu_man has joined #u-boot
<marex>
Xogium: I think it runs a script from U-Boot environment just before boot
<marex>
Xogium: try 'setenv localboot "echo hello ; printenv ; reset"' , then boot as usual and see what happens
<Xogium>
marex: hmm that seems to do nothing for me
mmu_man has quit [Quit: leaving]
<marex>
Xogium: could be PXE specific ?
<Xogium>
possibly
Mis012 has quit [Remote host closed the connection]
Mis012 has joined #u-boot
<marex>
doc/README.pxe:localboot <flag> - Run the command defined by "localcmd" in the environment.
<marex>
so the var is 'localcmd' apparently
<Xogium>
so it's like a boot.scr without a boot.scr ? :D
<Xogium>
hmm yep that doesn't execute here
<marex>
Xogium: you can probably tweak the bootargs there to pass in the right root=
<Xogium>
seems pxe only indeed
apritzel has joined #u-boot
<vagrantc>
Xogium: i head someone adding ${bootargs} to an extlinux.conf append commandline recently with success ... have not tried myself
<vagrantc>
Xogium: i have sometimes done tricks where i put boot.scr on a high-priority device and then fall back to extlinux on a lower-priority device once the script has set some things up
<vagrantc>
Xogium: for a similar use-case, i could see adding a preboot.scr that loads before extlinux ... or something. :)
<vagrantc>
also not sure how bootstd plays with all this ... it is the shiny new thing but i have only mostly used it in ways compatible with older behavior
<Xogium>
vagrantc: hmm. I see
<Xogium>
fwiw I'm on a older u-boot version, not insanely old, but still. 2022.10
<vagrantc>
Xogium: you want a single image that can be installed on different devices?
<Xogium>
well, same board, but different boot medium
<Xogium>
so generic image that you can boot from either micro sd or eMMC
<vagrantc>
depending on the rom boot order?
<vagrantc>
weather it boots from eMMC or microsd?
<Xogium>
hmm well, u-boot already can find where that booted from, i.e: mmc1 or mmc0, and it's already able to try and run the distro boot thing on mmc0 or mmc1
<Xogium>
the only part that bugs me is the bootargs because mmc1 has not the same partition layout as mmc0
<vagrantc>
you could also handle that in initramfs ... if the initramfs knows where it should load as rootfs
<Xogium>
yeah there's no initramfs here. It's a minimal rootfs which only has busybox
<Xogium>
this is meant as a generic buildroot starting point
<vagrantc>
ah well, i wash my hands of it then :)
<vagrantc>
but it does seem like most of the pieces are there to make this possible ...
<vagrantc>
just ... maybe not glued together very easily
<Xogium>
yeah
<Xogium>
barebox has this neat thing where it detects which device it booted from and already grabs the partuuid for you generated in a dynamically made bootargs variable. You don't actually override this at all if you use append in boot spec file
<Xogium>
I was hoping u-boot had something similar
<vagrantc>
i think that is possible with u-boot as well ... swear i recall seeing it.
<Xogium>
so you could literally share the same image usingbarebox since the partuuid would change, provided your image for micro sd is actually different
<Xogium>
otherwise you could fall back to aliased mmc dev nodes
<Xogium>
I just have no idea how to make u-boot do this
<Xogium>
if that is actually possible then that would really reduce the problem down to nothing :D
___nick___ has quit [Ping timeout: 240 seconds]
<marex>
Xogium: did you consider looking into the code yet ?
<marex>
you can also roll your own boot.scr and just start that, implement whatever logic you need in the script, and be done with it (assuming you dont need extlinux)