13:47 <milkylainen> hmm. I have an x86 uefi stubbed u-boot. Made it work in virtualbox. But now that I use real hardware it completely hangs at "autorun(0)" printout. Tested full debug printouts to console. USB generated a whole bunch of crap after which there is no more debug output after the autorun printout. No command, shell or anything execution.

13:48 <milkylainen> I was thinking that the machine (which does not have serial ports) was polling for serial / 8042 input on the kbd in the main loop and got stuck, somehow... But other than that I'm at a loss.

13:50 <milkylainen> To me, it looks like it's hanging somewhere in the main loop looking for input.

14:36 <jordemort> Am I correct in thinking that if I've gotten to `Starting kernel`, that I'm out of u-boot at that point and any subsequent hang isn't necessarily a u-boot problem?

14:37 <jordemort> I got a FIT image booting and then I got an actual hardware sample and the u-boot on there wants uImage, not FIT (which is uh, not what the SDK sources the vendor gave me say but...)

14:38 <vagrantc> yes and no ... u-boot could cause problems for the booting kernel ...

14:38 <jordemort> But if I switch out from fitImage to uImage in Yocto, I end up with "Starting kernel" and then it goes no farther, no more output ; fit still boots fine

14:38 <jordemort> I've flash a u-boot that supports both formats onto it for testing purposes

16:08 <Tartarus> sjg1: Your docker cache thing isn't setup right :(

16:08 <sjg1> Tartarus: What do you mean?

16:09 <Tartarus> sjg1: Jobs are failing because you can't pull from docker hub anymore

16:09 <Tartarus> https://source.denx.de/u-boot/u-boot/-/jobs/289437

16:09 <sjg1> Tartarus: Oh dear So what do I do about it?

16:10 <Tartarus> sjg1: For right now, turn off your runners

16:11 <Tartarus> Then verify that the MachineOptions setting, such as: MachineOptions = [ "engine-registry-mirror=http://192.168.0.3:6000" ] under [runners.docker] is up and connectable

16:23 <sjg1> It is OK on tui, but missing on kaki

16:25 <sjg1> Tartarus: I have updated kaki and restarted both

16:25 <Tartarus> OK. You might need to keep them off for 24h, I don't know how long until Docker times out on your having been timed out. Unless they all turn in to cache hits now

16:26 <Tartarus> Current build is going so maybe it'll be OK

16:26 <Tartarus> Thanks for diggin

16:26 <Tartarus> g

16:28 <sjg1> Tartarus: How can I find the job that each running is currently running?

16:29 <Tartarus> I don't know if that's easily exposed

16:30 <Tartarus> It might be in the admin part that only Rahix can see

16:39 <sjg1> Tartarus: OK never mind. I can just wait for complaints I suppose

16:57 <Tartarus> sjg1: complaint ;) https://source.denx.de/u-boot/u-boot/-/jobs/289468

16:59 <milkylainen_> Tartarus: Do you have an idea? My U-boot halts (or loops) just after the autoboot countdown. I have an embedded x86 without any serial ports. Seems to be disabled in ACPI/BIOS/UEFI. My guess was some code trying to poll keypresses.

17:00 <milkylainen_> I've done full debug, the last printout is the autoboot countdown. No more debug prints after that, whatsoever.

17:00 <sjg1> Tartarus: I don't really understand any of this. The engine-registry points to the local machine. Does that mean that the cache is not working?

17:00 <Tartarus> milkylainen_: sjg1 has done more x86 than I :)

17:01 <sjg1> milkylainen_: What is x86 uefi stubbed u-boot?

17:01 <Tartarus> sjg1: I'm just following the instructions, I'm not a gitlab/docker guru. I guess you need to hit up some stackoverflow on debugging docker registry cache not seeming to work, or at least how to test if it is working

17:01 <milkylainen_> sjg1: u-boot as an uefi payload? Ie, u-boot has an uefi stub?

17:02 <milkylainen_> Maybe I'm using the terminology in a way no one else does. :)

17:03 <milkylainen_> Tartarus: I wouldn't have expected anything interesting to happen in u-boot after the autoboot countdown? I.e, the idle keypress polling loop (together with various other polling tasks).

17:05 <Tartarus> milkylainen_: what happens if you just have bootdelay=-1 in the (default) environment?

17:06 <milkylainen_> As in no autoboot?

17:06 <milkylainen_> Not tried. Will try.

17:07 <sjg1> milkylainen_: OK I see. Are you using the latest mainline?

17:07 <milkylainen_> But how will that help? Disable autoboot means it will always stop in the shell?

17:07 <milkylainen_> sjg1: 2021.04. Could not get 2021.07 to boot on Virtualbox.

17:08 <sjg1> milkylainen_: Did we have this discussion a week or two ago?

17:09 <sjg1> milkylainen_: Oh no that is Christian Melki on the mailing list

17:10 <milkylainen_> sjg1 :)

17:11 <milkylainen_> Run! Hide! :P

17:11 <milkylainen_> (it's me)

17:16 <sjg1> milkylainen_: OK, I can perhaps try to duplicate your setup. Can you send details?

17:18 <milkylainen_> sure. What do you need? compiler-config, uboot-config, default environment?

17:19 <milkylainen_> Whad would be the effect of trying to access a mmc-device with the gpt cmd without initialization?

17:19 <milkylainen_> When I used AHCI I'd do scsi reset first.

17:19 <milkylainen_> Is something like that needed for emmc?

17:19 <milkylainen_> ie mmc init?

17:20 <milkylainen_> the board has emmc as storage.

17:25 <sjg1> Tartarus: I am not an expert on docker either. In fact I'm not even a beginner. I wonder if Harald or someone else can help with this. I had a quick look at the documentation and I don't even know where to start...probably spend a week learning about docker?

17:27 <sjg1> milkylainen_: will send you a doc

17:28 <sjg1> milkylainen_: but please keep the chat here

18:24 <sjg1> milkylainen: I added some comments

18:27 <milkylainen_> hrrmf. Display server or GPU decided that some random PCI error was in order.

22:15 <sjg1> milkylainen_: You mean you fixed it?