12:16 <xypron_> narmstrong: a user cottsay asked for help on #u-boot concerning trouble he has with U-Boot on Odroid-N2, Odroid-C4 due to the RNG driver. I think you discussed this yesterday on this channel.

12:17 <narmstrong> xypron_: exact

12:17 <xypron_> narmstrong: has there any more analysis been done? How can I reach cottsay?

12:17 <narmstrong> xypron_: no idea where this could come from, seems to be related to the rng driver

12:18 <xypron_> narmstrong: in U-Boot we added patches to enable the RNG driver for all meson boards.

12:18 <narmstrong> xypron_: he’s on this channel, he doesn’t seen to be available right now

12:18 <narmstrong> ˋ6:35 PM <cottsay> narmstrong: Sorry for the delay. The error comes just after GRUB tries to boot the kernel: `EFI stub: ERROR: Unable to construct new device tree.`

12:20 <narmstrong> ’10:11 AM <cottsay> Hi again. In reference to the u-boot issue I brought up a couple of hours ago with the ODROID-N2, I pulled out my ODROID-C4 and I can see the same problem. Same workaround: reverting 6da749d8b3 allows the system to boot, so it's likely the same regression is affecting both systems.´

12:25 <xypron_> narmstrong: cottsay: I would need the a dump of the device tree from U-Boot (command 'fdt print' and the full kernel output per email to xypron.glpk@gmx.de.

12:28 <rtp> fwiw, 2020.10-rc4 is working fine on my potato (uboot->grub-efi->linux). I've checked the uboot tree I used. looks like I've ported linux commit 95ca6f06dd4827ff63be5154120c7a8511cd9a41 to uboot, but I don't remember why ...

12:28 <rtp> uboot 2020.10-rc4 has 6da749d8b3 I guess

12:29 <rtp> oh, and I'm running mainline atf, in case it matters

16:58 <cottsay> xypron_: I'll get you that device tree dump. I'm using kernel 5.8.10, but 5.6.6 acts the same way. I haven't tried any others.

17:15 <xypron_> cottsay: the message comes from a part of the Linux EFI stub that updates the device tree by adding new nodes.

17:15 <xypron_> The maintainer for this code is Ard Biesheuvel.

17:16 <xypron_> What was the last message before EFI stub: ERROR: Unable to construct new device tree

17:17 <cottsay> xypron_: FWIW, I also get this message unless I disable KASLR: `EFI stub: ERROR: efi_get_random_bytes() failed`

17:17 <xypron_> cottsay: In U-Boot we have have a rng command (see CONFIG_CMD_RNG) to test the random number generator.

17:18 <xypron_> cottsay: let's start there. Does it output random output?

17:19 <cottsay> xypron_: Ooh, interesting, I'll give that a shot.

17:19 <xypron_> cottsay: We also have command 'bootefi selftest' (CONFIG_EFI_SELFTEST) which will emulate an EFI payload a do a few tests.

17:21 <xypron_> cottsay: the kernel code I mentioned is in drivers/firmware/efi/libstub/fdt.c.

17:22 <xypron_> cottsay: but I would really want to see the whole kernel output.

17:22 <cottsay> xypron_: I'll get all of this to you. Just re-compiling now.

17:36 <rtp> cottsay: maybe it has nothing to do with your problem, and I'm only producing noise, but maybe you can try this linux change (https://paste.debian.net/1164566/) in uboot ?

18:01 <cottsay> rtp: xypron_: Not noise, that fixed the problem for me. I applied that patch to arch/arm/dts/meson-sm1.dtsi and the C4 could boot - no nasty messages about the RNG coming from the stub, either.

18:01 <cottsay> xypron_: I can still send you the selftest and fdt print if you like.

18:03 <cottsay> So I'd suppose that the RNG was present in the device tree, but wasn't properly configured, and when u-boot tried to use it, it failed.

18:05 <cottsay> rtp: xypron_: Thanks for your help! I'm not familiar with u-boot's development model - what is the next step to getting this fixed? Does the change need to land in the kernel first?

18:32 <xypron_> cottsay: Did I read you right: U-Boot origin/master does not show random output using the RNG command. Applying the Debian patch to U-Boot fixes the problem?

18:36 <cottsay> xypron_: Correct. The `rng` command reports that there is no RNG without applying that patch to meson-sm1.dtsi.

18:37 <cottsay> It is interesting that u-boot knows that the rng isn't working, and yet fails to boot correctly because of it unless it is either fixed or specifically disabled.

18:39 <xypron_> cottsay: git commit ; git format-patch; scripts/get_maintainer.pl; git send-email

18:39 <xypron_> cottsay: use subject prefix as in the history of the file

18:39 <xypron_> when committing

18:40 <cottsay> This process is new to me. Can you clarify "use subject prefix as in the history of the file"?

18:41 <xypron_> cottsay: git log arch/arm/dts/amlogic/meson-gxl.dtsi

18:42 <xypron_> cottsay: shows that all patches start with something like: arm: dts:

18:42 <xypron_> cottsay: just do the same

18:43 <xypron_> cottsay: scripts/get_maintainer.pl arch/arm/dts/meson-gxl.dtsi shows you who should receive the email.

18:44 <rtp> cottsay: this commit is coming from mainline kernel, so no need to apply it there first. Just send a patch the way xypron_ told you

18:44 <xypron_> cottsay: rtp: the kernel patch was applied in the 5.7 cycle to Linux

18:46 <xypron_> cottsay: for sending the command will look like git send-email --to="Neil Armstrong <narmstrong@baylibre.com>" --cc="..." 0001-arm...patch Just add all the CCs indicated by the script.

18:47 <xypron_> cottsay: the commit message should describe from where you took the change and what it fixes.

19:02 <narmstrong> cottsay: xypron_: rtp: ok but how a gxl.dtsi change can fix the Odroid-C4 and Odroid-N2 not using this dtsi at all ?

19:02 <narmstrong> The rng may be broken on recent SoCs, I honestly haven’t tested

19:03 <narmstrong> For sure https://github.com/torvalds/linux/blob/171d4ff79f965c1f164705ef0aaea102a6ad238b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi#L282 clock is missing here

19:06 <cottsay> narmstrong: I applied that gxl change to meson-sm1.dtsi to get things to work.

19:06 <cottsay> So the patch to meson-sm1.dtsi isn't in mainline, which is why I asked if I should submit it there first.

19:07 <narmstrong> cottsay: ok, so yes fix meson-g12-common.dtsi in Linux the I will backport it to u-boot

19:07 <cottsay> Sounds good.

19:09 <xypron_> narmstrong: odroid-n2_defconfig does not build without meson-gxl.dtsi

19:09 <narmstrong> ?

19:10 <narmstrong> Yes, because we build all the meson dt for all amlogic boards

19:10 <xypron_> narmstrong: you said the dtsi is not involved

19:10 <narmstrong> It’s not, it’s not included in the odroid c4/n2 dts

19:23 <rtp> narmstrong: oh, I didnt notice that c4 and n2 were not using gxl dtsi /o\

19:23 <xypron_> narmstrong: cottsay: in the thread two different observations were reported: RNG failing on some boards in U-Boot, Linux EFI stub having some problem. Both may need a fix.

19:24 <rtp> narmstrong: still, the change is needed on gxl. Can you please backport to uboot the commit I mentionned please ?

19:24 <narmstrong> xypron_: i didn’t test efi for a long time, do you have a usual test flow ?

19:24 <narmstrong> rtp: I’ll have a look

19:25 <rtp> thanks :)

19:26 <xypron_> narmstrong: load mmc 0:2 $fdt_addr_r dtb; load mmc 0:1 $kernel_addr_r EFI/debian/grubaa64.efi; bootefi $kernel_addr_r $fdt_addr_r

19:26 <xypron_> narmstrong: assuming that you installed GRUB on your system.

19:27 <xypron_> narmstrong: cf. ps://u-boot.readthedocs.io/en/latest/uefi/uefi.html

19:27 <xypron_> narmstrong: cf. https://u-boot.readthedocs.io/en/latest/uefi/uefi.html

19:33 <rtp> distro_bootcmd stuff should be able to boot it too

19:35 <narmstrong> xypron_: thx for the pointers

19:36 <xypron_> narmstrong: rtp: cottsay: One thing I should change in U-Boot is that we should only install the EFI_RNG_PROTOCOL if we find a RNG device.

19:37 <xypron_> cottsay: If you provide me an email address I will put you on copy once the patch is ready.

19:39 <cottsay> xypron_: logans@cottsay.net