00:04 <Tartarus> Do we, really? I'm unsure of the "load via nfs" use cases, honestly

00:04 <Tartarus> Where something else doesn't exist

01:15 <Forty-Bot> the last time I used an nfs rootfs, I just loaded Linux over tftp

02:49 <sjg1> Tartarus: Hmm, OK I see. I think you are right

12:26 <Raito_Bezarius> Hi there, I'm trying to run U-Boot on QEMU x86_64 (with its defconfig, etc.) on a accel=tcg QEMU with a virtio block device serving as a rootfs, U-Boot seems to pick up the kernel & initramfs, run it, but at kernel time, when I try to mount the root disk, it fails and the kernel seems to say it doesn't see any virtio block device

12:26 <Raito_Bezarius> I double checked and I compiled the kernel with virtio support

12:26 <Raito_Bezarius> Does it ring a bell to anyone who used the U-Boot QEMU x86_64 stuff?

12:27 <Raito_Bezarius> I tried also IDE with no avail

12:29 <Raito_Bezarius> I also ensured myself to use the right devicetree for the q35 model I am using

12:30 <Raito_Bezarius> ahem

12:30 <Raito_Bezarius> > machine # Initial RAM disk at linear address 0x04000000, size 0 bytes

12:31 <Raito_Bezarius> I guess this is not good

12:55 <Raito_Bezarius> ah yes

12:55 <Raito_Bezarius> uninitialized memory in pxe_utils.c

13:26 <Raito_Bezarius> I sent a patch on the mailing list

13:28 <Tartarus> re U-Boot NFS, yes, it's the ability for U-Boot to "mount" an NFS share and copy a file to memory, not nfs root in Linux, that's just kernel args :)

14:57 <sjg1> Raito_Bezarius: I think there was a previous patch for that...not sure why it wasn't applied

14:58 <sjg1> I vaguely recall seeing a patch for showing a cursor in U-Boot...does anyone have a link?

15:09 <mps> sjg1: I have link somewhere when apritzel posted it about year and a half ago. but it have to be rebased now

15:09 <mps> will look later at evening when I come to home

15:09 <mps> s/link/url/

15:12 <sjg1> mps: Thanks...that was enough for me to find it. I thought it was more recent: https://patchwork.ozlabs.org/project/uboot/list/?series=280178&state=*

15:13 <mps> sjg1: yes, this. I tested it about month ago on apple silicon and peach pi chromebook, but had to rebase it

15:15 <mps> sjg1: I think this is what I rebased https://tpaste.us/d1RW

15:33 <sjg1> mps: Great. thank you!

15:58 <alpernebbi_> I remember having a problem with that cursor patch, going left over existing text would erase and not recover it

15:58 <alpernebbi_> like not with backspace but with left arrow on an input line

16:03 <alpernebbi_> actually was planning to work on that after the video damage series (after I return home)

16:31 <mps> alpernebbi_: right, it overwrite text with space, but it is better than no visible cursor

16:31 <mps> and also I thought to work on it to make it better

18:18 <Raito_Bezarius> sjg1: if you find it again curious

18:42 <Raito_Bezarius> Is there a known way to store FIT public keys in UEFI security databases or TPM2 ?

18:42 <Raito_Bezarius> Which works "agnostic" of the board if the mean is available

19:03 <xypron> Raito_Bezarius: https://u-boot.readthedocs.io/en/latest/usage/fit/beaglebone_vboot.html has a good description on how the public key for the FIT signature verifications is built into the internal device-tree of U-Boot. There is no support in the EFI sub-system for the verification.

19:29 <sjg1> Raito_Bezarius: It is here: https://patchwork.ozlabs.org/project/uboot/patch/20230504134255.8510-4-thomas.mittelstaedt@de.bosch.com/

21:15 <Raito_Bezarius> xypron: yes I have read that

21:27 <Raito_Bezarius> sjg1: thanks