09:41 <rfried> mwalle: done

09:50 <mwalle> rfried: thanks! :)

10:11 <gcl> xypron: I've got an odd EFI console problem on the RockPro64-rk3399

10:12 <gcl> xypron: when nothing is connected to HDMI, the console is fast, and grub is responsive

10:13 <gcl> xypron: but if I connect a monitor and U-Boot is driving the display it is very slow. I presume because the framebuffer console isn't optimized

10:13 <gcl> have you witnessed this at all?

10:32 <gcl> anyone tried recent U-Boot on the Rockpro64? I'm seeing USB-related hangs when booting via UEFI.

10:32 <gcl> ExitBootServices() doesn't complete. I've bisected it down to the first enabling of USB3: commit 3ae64582fb, "rockchip: rockpro64: Enable USB3.0 Host"

10:34 <gcl> I can work around it by commenting out the ohci_shutdown_phy() and ehci_shutdown_phy()

10:45 <xypron> gcl: is maintained by marex

10:45 <xypron> usb is ...

10:46 <xypron> gcl: I don't have a monitor on my small devices

10:46 <sigmaris> gcl: sounds similar to the issue described in https://lists.denx.de/pipermail/u-boot/2021-April/446439.html maybe

11:36 <gcl> sigmaris: I was just talking to pbrobinson and he pointed me at the same patch

11:37 <gcl> I'm going to give it a spin and see what I see.

12:46 <gcl> sigmaris: yes, that patch works around the problem and I can boot

16:17 <jordemort> back on trying to TFTP boot my imx7 sabre derivative - i've got a FIT image w/ a kernel, initramfs, and dtb bundled together in it, i can load the kernel over TFTP and start it, but it does not run my initramfs. the kernel sees it, and "tries to unpack it as an initramfs" and then immediately frees the associated memory and moves on. the initramfs definitely contains an /init that's executable, and i switched over to trying a "known good"

16:17 <jordemort> initramfs that works when loaded as a legacy image and when it is packed as a FIT image it still doesn't see it

16:18 <jordemort> i'm using yocto to build my FIT image, my best guess is that i've got something wrong and i'm mangling the format of my initramfs somehow and it's not getting unpacked correctly

16:18 <jordemort> full boot log is here, any ideas on how i might be messing this up would be greatly appreciated: https://gist.github.com/jordemort/6c6285fede887692316baf5ae7be630a

16:20 <jordemort> oh i think i might have figured it out, it looks like there's a `root=/dev/ram` that's sneaking in there when i run my netboot command, amazing what a night's sleep will do for you

16:23 <jordemort> nah that doesn't seem to have been it, bummer

16:27 <cambrian_invader> so what is /init ?

16:29 <cambrian_invader> and do you need to set root=/dev/ram0?

16:29 <cambrian_invader> with 5.10, I just needed to set rdinit to something sane

16:30 <cambrian_invader> and have you tried loading the initrd separately?

16:34 <jordemort> i need to bundle it into a single FIT image, because that's all the factory is willing to take

16:35 <jordemort> i don't think i need or want to set root=/dev/ram0, that's leftover from the original firmware and i'm pulling it out but it doesn't seem to make a difference to if the initramfs is recognized (not 100% sure there, rebuilding u-boot now to make sure it's really gone instead of just hand-hacking it( /init is a shell script, which runs fine when loaded separately

16:36 <jordemort> i.e. if i don't do a FIT image, and just load my zImage and my dtb and my initramfs separately and boot, everything works fine

16:37 <jordemort> but i need to provide a single FIT image to the factory, because they're going to change an environment variable in their u-boot build and then boot it, and the intention is for it to download my image from a TFTP server, which will boot into an initramfs that subsequently re-flashes and takes over the device

16:38 <jordemort> none of this would be a problem if the factory was willing to flash my firmware in a reasonable way with a cable, like i've been doing, but they've covered up the debug port at that point in the manufacturing and won't change their process, so i have to figure out how to install it over the network :/

16:40 <jordemort> is there a tool that can be used to pull apart a fit image and examine the contents of it?

16:49 <cambrian_invader> jordemort: do you have USB in your design?

16:49 <jordemort> cambrian_invader: yes, but no longer accessible at the point in manufacturing that the factory wants to do the flashing

16:50 <cambrian_invader> :l

16:50 <jordemort> i know

16:51 <jordemort> they want to put their firmware on the device, fully assemble it, test everything using their firmware, and then flash my firmware over the network

16:52 <cambrian_invader> and you can't get them to load a fit+initramfs separately?

16:52 <jordemort> this isn't really "our" design, we're just whiteboxing/OEMing it

16:53 <jordemort> i might be able to talk them into it but it would require them to change their existing u-boot script from what they use for all their other customers

16:53 <jordemort> i already talked them into changing loadaddr and a couple other things so my giant image would actually load but i don't know how much farther i can push em on that

16:54 <cambrian_invader> can you try running bootm subcommands

16:54 <jordemort> and i should be able to get a fit image w/ everything bundled working in theory

16:54 <cambrian_invader> and going all the way until "go"

16:54 <cambrian_invader> and then verify that everything is extracted to the correct location

16:54 <cambrian_invader> perhaps do a checksum

16:55 <jordemort> ooh ok i'll try that

16:55 <jordemort> that looks promising, thanks

16:56 <jordemort> gonna reflash to my latest u-boot build first

17:15 <jordemort> cambrian_invader: here is a run through bootm subcommands https://gist.github.com/jordemort/7f964db8274ecb0cfc860f6befe89524 - looking at the addresses it's spitting out, i kinda think `bootm prep` overwrote the initramfs?

17:17 <cambrian_invader> did it?

17:17 <cambrian_invader> also: have you tried specificying a load address for the initramfs in your FIT?

17:22 <jordemort> no, doesn't seem to, tried md5summing ${initramfs_start} thru size before and after bootm prep and it's the same

17:23 <jordemort> i have not tried that, i'll need to look into how to do that w/ yocto

17:24 <jordemort> the md5sum in memory doesn't seem to match the md5sum of the separate cpio.gz that yocto built, i'm not sure that's relevant though

18:37 <cambrian_invader> jordemort: you can also try loading the initrd manually

18:37 <cambrian_invader> and doing cmp.l on the one loaded by FIT

19:51 <cambrian_invader> Tartarus: squashfuse?

20:12 <Tartarus> Whatever we would need to be able to make/use our squashfs tests :)

21:16 <lvrp16> stupid question, is there a "break" equivalent for for loops?

21:17 <Pali> break?

21:18 <lvrp16> yeah, like exit out of the for loop

21:20 <lvrp16> sorry, I should be more specific: the u-boot shell, is there a way to break out of a for loop

22:27 <jordemort> success! it seems like INITRAMFS_IMAGE_BUNDLE = "1" in yocto is the Wrong Thing when doing a fitImage

22:27 <jordemort> i think it glued my initramfs into the kernel, and then made another copy of it in the fit, and then when the kernel came up it was like "what is this even"

22:27 <jordemort> i was wondering why my image was so much larger than sizeof(kernel) + sizeof(initramfs) :D

23:09 <cambrian_invader> lvrp16: no

23:10 <lvrp16> cambrian_invader: thanks