07:46 <michalkotyla_> Hello, I have a problem with booting from SD card on u-boot v2021-11. Is a chance that u-boot interprets the device tree in a different way than the kernel? Kernel is bootable when I try to run it on u-boot version from 2018 without a new driver model and this same device tree works well for kernel. Should I focus on searching problems inside device tree, or it must be good if it works for kernel?

08:01 <coldspark29> rfs613: Morning, yes there is a bootscript, but it contains nothing regarding the setting of the mmcroot

08:06 <coldspark29> But actually that bootscript is from Android and not used for this case as it is Yocto

12:40 <rfs613> coldspark29__: coldspark29: howdy, morning is just rolling around here ;-)

12:41 <rfs613> I'd suggest you try executing the commands in "bootcmd" one step at a time.

12:41 <rfs613> eg. first do 'env default -a' and confirm your mmcroot is correct.

12:42 <rfs613> then do mmc rescan... should not affect mmcroot

12:42 <rfs613> then run loadbootscript ... check mmcroo

12:42 <rfs613> then "run bootscript"... check mmcroot again

12:43 <rfs613> I'm around only intermittently today, will check back with you later.

14:16 <ccf> Is it possible to "stream"-download a file by network (say tftp) into an e.g. emmc? My RAM is smaller than the image.

16:10 <any1> Is there a way to do an early return from a sourced script? "exit" doesn't seem to do anything

16:11 <any1> I'd like to keep my nesting level to a minimum

16:19 <marex> ccf: there is dfu ethernet, paging lukma

16:20 <marex> any1: uh ... that is a good and valid question and I have to admit, as surprising as it looks, exit doesn't do what one might expect

16:20 <marex> crud

16:20 <marex> any1: so yes, some degree of debugging/fixing is needed around the exit command

16:22 <any1> marex: Thanks. Looking at the implementation of the command, it looks like a noop

16:23 <marex> it does set return value of the script, look at examples in ...

16:23 <marex> 8c4e3b79bd0bb76eea16869e9666e19047c0d005

16:27 <any1> Ah, so it's only purpose is to set the return value..

16:29 <any1> its

16:30 <any1> I'll just tack a stack of annotated "fi"s at the end. :)

16:44 <marex> any1: no, I would expect e.g. this

16:44 <marex> setenv foo 'echo foo ; exit 1 ; echo bar' ; run foo ; echo $?

16:44 <marex> would print 'foo' and '1'

16:44 <marex> this is NOT what happens right now

16:44 <marex> this is flawed

16:53 <any1> Hmm, guess I might try to fix it then. We'll see..

16:55 <any1> Anyhow, I'm trying to apply a device tree overlay, but "fdt apply" returns FDT_ERR_NOTFOUND. Any ideas what might have gone wrong?

16:57 <any1> This is vc4-kms-v3d-pi4 on for the raspberry pi 4. Maybe those overlays don't really work with u-boot?

17:22 <any1> wtf... maybe this is my problem: https://github.com/raspberrypi/utils/blob/master/ovmerge/ovmerge#L240-L255

20:19 <coldspark29> rfs613: Thanks, will try on Monday. I did not really get that far earlier. I read a bit about how U-Boot environment works etc. and it just doesn't make sense

20:22 <coldspark29> Hoping to get this done before Christmas. It is all that is left on me todo list. I will keep in mind now that you are based in the US. I am in Germany and am in the urgent need of a beer now.

20:22 <coldspark29> Have a nice weekend!

22:52 <any1> It appears that applying an overlay which starts at fragment@1 rather than fragment@0 fails

22:55 <any1> I put a printout here: https://github.com/u-boot/u-boot/blob/master/scripts/dtc/libfdt/fdt_overlay.c#L783

22:56 <any1> it showed me the path of the failed fragment and it was "fragment@0" which doesn't exist in the dtbo