11:35 <baltazar> hi! can u-boot elaborate on `failed on fdt_overlay_apply(): FDT_ERR_NOTFOUND`? what exactly is that supposed to mean?

11:45 <baltazar> oh wait I think I figured it out

13:26 <j`ey> CONFIG_BOOTCOMMAND is what gets run automatically, right?

13:36 <Tartarus> yes

13:37 <j`ey> ta, I've been copy/pasting a command line over serial, and it's getting annoying!

14:31 <marex> baltazar: it means FDT is not found, i.e. you passed invalid input to the function

17:14 <kabel> j`ey: why not just 'setenv bootcmd xyz; saveenv'

17:14 <j`ey> kabel: there's no way to save environment on this platform currently

17:17 <kabel> ok

17:51 <marex> j`ey: echo "do random stuff" > /dev/ttyUSBx ... is what I do

17:52 <j`ey> that could work too, but for now I'll keep the BOOTCOMMAND, only takes a few seconds to rebuild uboot if I need to change them

18:08 <river> i have some code in bootcommand that loads uenv.txt and runs stuff frmo that

18:10 <j`ey> that's also a good idea, but not for my case. it's easier for me to load a new u-boot than to edit files on the drive in my case

18:11 <river> :)

18:14 <marex> river: look at distro bootcommand, that's the standardized version of it

18:15 <river> oh the boot.scr thing?

18:16 <river> or is that just having code in a header file

18:19 <marex> see include/config_distro_bootcmd.h

18:19 <marex> it's common set of scripts

18:19 <river> thanks!

18:19 <marex> the idea is to prevent everyone from hand-rolling their own scripts with various incompatible bugs and quirks

18:20 <marex> instead, this is something which even distros (like debian) support

18:20 <river> haha I see everyone hand rolling uEnv

18:20 <river> so i just copied

18:20 <marex> see also doc/develop/distro.rst

18:20 <river> this is much cleaner cheers

18:20 <j`ey> river: are you using upstream uboot?

18:21 <river> not sure, there's some custom code

18:24 <marex> j`ey: there is any other option ?

18:24 <j`ey> marex: some crappy vendor fork from 2002? :P

18:25 <marex> how about no ...

18:28 <j`ey> it's not option you want, but it does seem to be what some people end up with

19:17 <river> is there a way to error if an env var is not defined? it currently just silently replaces it with empty string and continues

19:25 <marex> river: just like bourne shell -- test "x${foo}" = "x" && echo empty

19:30 <river> i mean a way for all uses of any variables like set -u but that will be useful for individual cases

19:40 <marex> I dont think u-boot hush shell derivative implements 'set' command at all, although the code is there, so you should be able to add it and send patch

19:41 <river> ok :)

20:13 <h_ro[m]> Hello, I am writing adhoc/POC omap4_dss UCLASS_VIDEO driver, but I am failing to understand how devices would get bounded before video_reserve is called (as stated in the theory of operation in drivers/video/video-uclass.c). From my limited testing, I see that video_reserve fail to find video devices and see that... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/fa6166b2f2c49d98e9d6d332dd6a3d243f55e506)

20:49 <marex> h_ro[m]: I think some part of your message is missing

20:49 <marex> h_ro[m]: why bother with video driver in u-boot, just boot Linux quickly enough and let it bring up the video pipeline

20:59 <h_ro[m]> <marex> "h_ro: I think some part of..." <- minimal dummy driver + output on Pandaboard ES: https://pastebin.com/rbzRtmqD

21:11 <marex> "We value your privacy" ...

21:12 <marex> h_ro[m]: why bother with video driver in u-boot, just boot Linux quickly enough and let it bring up the video pipeline

21:14 <h_ro[m]> <marex> "h_ro: why bother with video..." <- This is valid. I was just looking to maintain u-boot support for Kindle Fire (kc1 which got removed last year) which offers somewhat of a legitimate use-case for video driver at bootloader stage.

21:15 <marex> h_ro[m]: ah, because of some DM conversion deadline ?

21:16 <h_ro[m]> yup

21:16 <marex> ahhh

21:17 <marex> h_ro[m]: try marking the device with u-boot,dm-pre-reloc in DT, that _might_ help

21:17 <marex> sjg1: ^

21:17 <marex> Tartarus: I think we really do need better documentation for the DM conversion ?

21:19 <h_ro[m]> marex: Ahh, I have not tried this

21:19 <marex> h_ro[m]: I am not entirely sure it will help, it _might_

21:20 <marex> h_ro[m]: I recall running into similar issue before, but it has been a while

21:28 <h_ro[m]> video_reserve allocating correctly now. Thanks!