00:43 <Manouchehri> https://gist.github.com/Manouchehri/771c1d4f58d72e359f98fbfa8e3c3696#file-gistfile1-txt-L280

00:44 <Manouchehri> oops sorry I already posted basically the same thing

00:44 <Manouchehri> yeah so I have the rng driver loaded

00:44 <Manouchehri> yet `rng` doesn't work

01:57 <macromorgan> is the driver bound? what does dm tree show?

02:10 <Manouchehri> macromorgan: it's not bound/probed. https://gist.github.com/Manouchehri/9716e520cef34b1703ab41833b507a21#file-gistfile1-txt-L83

02:11 <Manouchehri> actually I don't know what bound means

02:14 <macromorgan> driver might not have probed, meaning even though the driver is there it's like it's not (meaning the rng can't be used). Honestly I don't know, as I can only speak for the PX30 or the rk3566 I've tested it on (both work though they are v2 rngs for what it's worth)

02:15 <Manouchehri> macromorgan: How does one probe things?

02:17 <Manouchehri> I'm recompiling with CONFIG_CMD_BIND now. https://u-boot.readthedocs.io/en/latest/develop/driver-model/bind.html

02:18 <Manouchehri> hmmm actually isn't the driver already bound?

02:18 <Manouchehri> just not probed?

02:47 <macromorgan> you can enable debugging in your build and see if it fails or anything. The kaslrseed should probe and bind the driver if it's not already probed, so worst case with debug info enabled you can see the output of that and find out what the hitch is

02:48 <Manouchehri> macromorgan: CONFIG_DM_DEBUG?

03:07 <Manouchehri> ah ha!

03:08 <Manouchehri> rockchip-rng rng@ff8b8000: failed to set rate on clock index 0 (134) (error = -2)

04:10 <Manouchehri> YES I GOT IT WORKING

04:11 <Manouchehri> I removed the clocks

06:18 <jagan> anyone booted rockchip psci SoCs's in linux-next

12:48 <hays> kabel: Any idea what might be going on here with building atf-marvell? https://h0c.us/v/QOSG gcc-12

12:49 <hays> bl2.elf doesn't seem to be getting made

12:51 <hays> /usr/bin/aarch64-linux-gnu-ld: warning: /home/hays/Projects/chroots/bionic/espressobin/src/trustedfirmware/trusted-firmware-a/build/a3700/release/bl2/bl2.elf has a LOAD segment with RWX permissions

13:23 <marex> hays: make E=0

13:24 <marex> hays: ATF has many such weird bugs ... I don't trust that development process of theirs

13:24 <marex> or edit Makefile and add +TF_LDFLAGS += --fatal-warnings -O1 --no-warn-rwx-segments

13:26 <hays> heh... yeah i ended up stumbling across the same fix.. now the build is not producing flash_image.bin so I am adding targets to my build script to see if that works

13:27 <hays> was going make all fip

13:27 <hays> now doing all fip mrvl_bootimage mrvl_flash mrvl_uart

13:28 <hays> which pulled in a cryptopp dependency which ... is interesting

13:48 <hays> wow i think i got it.

16:41 <hays> Now I need to figure out how to write the rng function and access it from uboot

17:34 <hays> "CZ.NIC as part of Turris project released free and open source WTMI application firmware wtmi_app.bin for all Armada 3720 devices. This firmware includes additional features like access to Hardware Random Number Generator of Armada 3720 SoC which original Marvell’s fuse.bin image does not have."

17:35 <hays> Im trying to figure out how this statement connects to CONFIG_RNG_SMCCC_TRNG

17:54 <macromorgan> <Manouchehri>: Slap a printf function in the kaslrseed to make sure you're actually returning random stuff... I know the clocks are important to getting randomness for that driver.

17:55 <macromorgan> but otherwise glad to hear it

17:56 <Manouchehri> macromorgan: honestly as long as it’s sorta random, good enough. ASLR isn’t super super effective anyway.

17:56 <macromorgan> well hell you can do kaslrseed then with pseudo random if that's what you want, no driver needed :-)

17:57 <macromorgan> setenv randomaddress ${loadaddr};random ${randomaddress} 8;setexpr.w seedvalue1 *${randomaddress};setexpr randomaddress ${randomaddress} + 2;setexpr.w seedvalue2 *${randomaddress};setexpr randomaddress ${randomaddress} + 2;setexpr.w seedvalue3 *${randomaddress};setexpr randomaddress ${randomaddress} + 2;setexpr.w seedvalue4 *${randomaddress};setenv kaslr-seed "<0x${seedvalue1}${seedvalue2} 0x${seedvalue3}${seedvalue4}>";seten

17:57 <macromorgan> v seedvalue1;setenv seedvalue2;setenv seedvalue3;setenv seedvalue4;setenv randomaddress

17:57 <macromorgan> fdt set /chosen kaslr-seed "${kaslr-seed};"

19:53 <marex> hays: it probably means your Turris firewall^WCM4 can be used to bypass some protection and access the RNG

19:53 <marex> hays: so the call is likely going through rpmsg to the CM4, with no SMC calls inbetween

21:02 <hays> Marex: as far as I can tell, the firmware seems to be independent of the kernel, although there is a specific Linux kernel driver for the Turris Mox

21:05 <marex> hays: the firmware is running on some cortexM companion core built into the armada

21:05 <hays> The mox_sp.c file implements a call but it’s just to the e data function and it’s board specific . I think there might be a way to write a function for the RNG.. but what attaches to it I do not know

21:08 <hays> Practically I also am not sure if I flash this with bubt or need the special mox-imager tool

21:25 <hays> here is the line defining an interface to the rng https://github.com/u-boot/u-boot/blob/2996b6405e9522082b53ded0392438830ad6c43a/arch/arm/mach-mvebu/include/mach/mbox.h#L11

21:33 <hays> I think a function like this might work to access the RNG https://h0c.us/v/BSOX

21:34 <marex> hays: isnt there already some rng rpmsg glue in drivers/crypto ?

21:41 <hays> marex: i don't think so

21:44 <hays> the get random shows up one place -- https://github.com/u-boot/u-boot/blob/2996b6405e9522082b53ded0392438830ad6c43a/arch/arm/mach-mvebu/include/mach/mbox.h

21:47 <hays> I think that calls this function? https://gitlab.nic.cz/turris/mox-boot-builder/-/blob/master/wtmi/main.c#L99

21:57 <marex> hays: drivers/crypto/virtio

21:57 <marex> that might be it

22:01 <hays> are you looking somewhere other than here https://github.com/u-boot/u-boot/tree/master/drivers/crypto

22:02 <hays> found this -- https://github.com/u-boot/u-boot/blob/357fa8bb4d40abf411a6cca70f5a2dd6413028ea/drivers/virtio/virtio_rng.c