slobodan_ has quit [Read error: Connection reset by peer]
slobodan_ has joined #u-boot
runcom has joined #u-boot
stefanro has quit [Quit: Leaving.]
stefanro has joined #u-boot
rfs613- is now known as rf613
camus has quit [Read error: Connection reset by peer]
camus1 has joined #u-boot
camus1 is now known as camus
d-s-e has quit [Ping timeout: 265 seconds]
runcom has quit [Ping timeout: 252 seconds]
runcom has joined #u-boot
vagrantc has joined #u-boot
naoki has quit [Quit: naoki]
runcom has quit [Ping timeout: 250 seconds]
runcom has joined #u-boot
slobodan_ has quit [Quit: Leaving]
mcfrisk has joined #u-boot
<mcfrisk>
hi, trying to update from 2023.01 to 2023.04 and on qemu_arm64 I get "Error: "distro_bootcmd" not defined". Not sure how to proceed here. Is this because CONFIG_BOOTSTD_FULL should be used instead now?
<mcfrisk>
instead of CONFIG_DISTRO_DEFAULTS I mean
<vagrantc>
probably...
<vagrantc>
there have been a handful of patches related to this migration from distro_bootcmd to ... standard boot ...
d-s-e has joined #u-boot
<mcfrisk>
bugger, "fatal: no kernel available". Is there some nice changelog or similar entry to explain distro vs standard boot?
ikarso has quit [Quit: Connection closed for inactivity]
<macromorgan>
so what are the differences/restrictions of kaslr-seed versus rng-seed? I'd like to add something basically identical to the existing rng-seed (CONFIG_BOARD_RNG_SEED) to also do kaslr-seed.
<macromorgan>
in a perfect world I can use the exact same board_rng_seed, but kaslr-seed says it needs to be a u64 and rng-seed says it needs to be a byte array
<macromorgan>
I guess I'm wondering if it's fair to put a restriction on the board_rng_seed to a u64 size to let it be reused there, before someone starts implementing that function in mainline
runcom has quit [Ping timeout: 256 seconds]
runcom has joined #u-boot
ikarso has joined #u-boot
<sjg1>
mcfrisk: For me, the bootcommand for 2023.04 is "bootflow scan -lb". Did you change it, by any chance?
<mcfrisk>
sjg1: no, that doesn't find the kernel with our defconfig. we use efi secure boot and qemu to test. the diff between our config and qemu_arm64_defconfig is very minimal
<sjg1>
mcfrisk: For the boot error, is kernel_addr_r set ?
<mcfrisk>
sjg1: no, maybe that's the one
<sjg1>
Do you have a patch against mainline 2023.04 ?
<mcfrisk>
yocto poky master patches plus few of our own, but for qemu arm64 there is not much, except board/emulation/qemu-arm/qemu-arm.env is cleared for some reason and kernel_addr_r isn't set. maybe that's the bug
<sjg1>
It should be set in qemu-arm.env unless you deleted/changed it
<mcfrisk>
yes, I'm inspecting the build tree and git diff shows that something emptied the file for some reason. Either a patch or some other logic which was needed at some point. I'll check this. Thanks for the hint!
<sjg1>
mcfrisk: OK good luck
<mcfrisk>
I guess qemu-arm.env wasn't really required for distro boot, before 2023.04?
goliath has quit [Quit: SIGSEGV]
<mcfrisk>
a configure snippet was overwriting it instead of appending "silent=1" to it
<mcfrisk>
this was harmless before, now fatal :)
runcom has quit [Ping timeout: 260 seconds]
d-s-e has quit [Quit: Konversation terminated!]
guillaume_g has quit [Quit: Konversation terminated!]
frieder has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
apritzel_ has joined #u-boot
Laurence_b has joined #u-boot
<Laurence_b>
hi, is it possible to return from a binary image called using "go" back to u-boot?
<Laurence_b>
I want to load a binary image that sets custom config on a bare metal target board
<Laurence_b>
so 1) go used to call image, 2) linux ( or other os) booted
sakman_ has joined #u-boot
sakman has quit [Remote host closed the connection]
<Mis012[m]>
would probably make more sense to use the u-boot api?
<Laurence_b>
ok, I didnt know that existed lol
<Laurence_b>
does that require building my code into the u-boot binary?
ldevulder has quit [Quit: Leaving]
<Mis012[m]>
also, u-boot -> ??? -> Linux seems like a very suspicious usecase
<Laurence_b>
hmm maybe I could run the other code before u-boot
<Mis012[m]>
why can it not be in u-boot
<Laurence_b>
* "Standalone Programs" are directly runnable in the environment
<Laurence_b>
* provided by U-Boot; it is expected that (if they behave
<Laurence_b>
* well) you can continue to work in U-Boot after return from
<Laurence_b>
* the Standalone Program
<Laurence_b>
ah ok that sounds like what I want
<Laurence_b>
yeah using u-boot to run the standalone board config program sounds like the best option as far as configurability goes
<Mis012[m]>
there's a reason u-boot still has board files...
<Laurence_b>
I'm not sure they could handle my weird hardware that doesnt have linux or uboot drivers, but maybe, I'll read about that option
<Mis012[m]>
you're supposed to add the drivers
<Laurence_b>
lol ok as I thought
<Laurence_b>
yeah I'd prefer to just run a binary blob
<Mis012[m]>
well, I sincerely hope you're not planning to sell this as a product, because the users probably would not
<Laurence_b>
lol its embedded in a vehicle
<Laurence_b>
end users shouldnt go near it
<Mis012[m]>
inb4 also using secure boot to make extra sure they won't
<Laurence_b>
main cpu boots u-boot, configures auxiliary cpu to load its firmware from network, then boots linux on main cpu
<Laurence_b>
binary blob runs on main cpu but configures the auxiliary cpu
<Mis012[m]>
sounds like remoteproc
<Laurence_b>
yeah we may use limited functionality from openamp, but only once its all booted
<Laurence_b>
due to the legacy board design it looked hard to just use remoteproc or openamp for initial config
<Mis012[m]>
on most SoCs configuring an auxiliary cpu core and bringing it out of reset makes much more sense to do drom u-boot
<Mis012[m]>
*from
<Mis012[m]>
or is it not on-SoC?
<Laurence_b>
no its physically separate
<Mis012[m]>
I see
<Mis012[m]>
then userspace?
prabhakarlad has joined #u-boot
<Laurence_b>
that is another option we are investigating, but the config involves PMU and clocks, and we might want to lock them before booting linux for added robustness
<Mis012[m]>
if the config involves PMU and clocks then it would clearly be easier to use remoteproc in u-boot or linux with nice apis for clocks etc
<Mis012[m]>
also fwiw not to throw too much shade on u-boot maintainers but from what I've seen you could probably put almost anything in a board file and have it accepted upstream
<Mis012[m]>
unless those examples I've seen are just grandfathered in
Laurence_b has quit [Quit: Client closed]
goliath has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
runcom has joined #u-boot
mmu_man has joined #u-boot
runcom has quit [Ping timeout: 240 seconds]
pgreco has joined #u-boot
pgreco_ has quit [Ping timeout: 255 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
thopiekar_ has quit [Quit: Likely restarting quassel...]
alan_o has quit [Ping timeout: 248 seconds]
alan_o has joined #u-boot
thopiekar has joined #u-boot
mncheck has quit [Ping timeout: 240 seconds]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
slobodan has quit [Ping timeout: 240 seconds]
Laurence_b has joined #u-boot
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]