01:52 <Tartarus> pbrobinson: Am I reading the DTS files right, and the Pi 3 does not have an RNG (no brcm,bcm2711-rng200 compatible RNG, only on the 4) ?

01:52 <Tartarus> xypron: A funny but maybe good / intentional is that if you run EFI SelfTest on a platform that has DM_RNG and RNG drivers, but no RNGs found, the RNG test fails

09:03 <pbrobinson> Tartarus: correct, no RNG on the rpi3

09:25 <Kwiboo> Tartarus, sjg1: with recent lwip and mbedtls merge there are some new $(SPL_) in a few Makefile in master, are these expected to work or must they be changed to $(XPL_) or $(PHASE_) ?

14:05 <Tartarus> pbrobinson: thanks

14:06 <Tartarus> Kwiboo: I think it's correct? SPL_ isn't dead? I find the new arrangement more confusing than before, but I'm probably the minority

14:12 <pbrobinson> Tartarus: I don't think you are, I am confused by it too, but I've put it on the back burner while dealing with other things like LEDs/ACPI

15:23 <Tartarus> calebccff: Well hunh, I think I found a UUID problem by running the suite on HW

15:24 <Tartarus> Note this is on rpi_3_32b https://www.irccloud.com/pastebin/A8fYHT80/

15:24 <Tartarus> You can probably make it fail in sandbox even, if you use the normal linux userspace trick to force 32bit mode?

15:25 <Tartarus> (... we should try and do that in general I bet)

15:35 <sjg1> Kwiboo: Yes it could be correct. XPL_BUILD means any xPL build; SPL_BUILD means just SPL; PHASE_ means it uses Kconfig to select

15:55 <Tartarus> ... setarch

16:02 <Tartarus> And whew, there, I have test_ut.py going on real hardware now. And it showed the next mistake in my "tell me if I don't have expected pass/fail numbers", heh

16:33 <mrkiko> I am seeing an issue in mt7981, when I enabled console multiplexing and did set "stderr", "stdin" and "stdout" to "serial,nc". I can observe correct operation, but only setting these variables once u-boot is already in the CLI. If I do set those variables and save them in the env, then u-boot crashes

17:14 <xypron> Tartarus: At ExitBootServices all dm devices are removed. So returning to U-Boot makes no sense. We must reboot in our EFI boot tests.

19:27 <calebccff> Tartarus: nooo not a bug! I hate those :L uhh that's super weird just the last 2 bytes is cut off

19:28 <Tartarus> calebccff: Yeah, it's weird but I think I reproduced it twice. And with https://patchwork.ozlabs.org/project/uboot/list/?series=430170 you can run it on a Pi 3 or 4 in 32b mode as well

21:25 <Tartarus> calebccff: Oh, with your snapdragon hat on, did you see Janne's email just now re the apple iommu and how lmb was wrong to change there?

21:29 <calebccff> Tartarus: hmm, no do you have a link?

21:33 <Tartarus> oh moment, moderator queue

21:35 <Tartarus> https://lore.kernel.org/u-boot/ZyAAJsnV4uz2Btwy@robin/T/#u

21:36 <Tartarus> So my question, once you can digest the email is, what's snapdragon doing here?

21:39 <calebccff> Tartarus: qualcomm platforms don't need any virtual addressing. The SMMU driver is only needed when we're booting in EL1 with Qualcomm's hypervisor because it emulates some SMMU registers, meaning unless we "configure the SMMU" DMA from peripherals trips some secure watchdog

21:39 <calebccff> if we run U-Boot on qualcomm platforms in EL2 or EL3 the SMMU driver is entirely unnecessary

21:40 <calebccff> for DART though based on my (quite) limited understanding I'd be inclined to agree that this was a perfectly valid use of LMB

21:42 <calebccff> i bet it would be doable to refactor LMB to provide the new default global state interface and expose a secondary API which allows for using some custom state

21:43 <Tartarus> Ah, OK, I was hoping you had solved this problem with something private to the snapdragon code :(

21:44 <calebccff> alas, I haven't yet found a chance to be cool and use virtual addressing in U-Boot :P

21:45 <calebccff> not even with PCIe!! Qualcomm just allocate a bunch of physical address space in the 32-bit region

21:50 <calebccff> Tartarus: I thihnk Patrick tracked down the UUID issue... https://lore.kernel.org/u-boot/4b60130d-030f-405c-a753-eeb52a5e7b1d@foss.st.com

21:53 <Tartarus> Ah, good timing then