On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <ma...@denx.de> wrote:
>
> On 4/29/24 9:10 PM, Tim Harvey wrote:
> > On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut <ma...@denx.de> wrote:
> >>
> >> On 4/19/24 5:24 PM, Tim Harvey wrote:
> >>> On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut <ma...@denx.de> wrote:
> >>>>
> >>>> On 4/18/24 8:02 PM, Fabio Estevam wrote:
> >>>>> Hi Tim,
> >>>>>
> >>>>> On Thu, Apr 18, 2024 at 2:54 PM Tim Harvey <thar...@gateworks.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Fabio, if you enable CONFIG_DM_RNG on an imx8m{m,p}_evk do you get the
> >>>>>> following in the SPL?
> >>>>>> Couldn't bind rng driver (-96)
> >>>>>> SEC0: RNG instantiated
> >>>>>>
> >>>>>> sec_init failed!
> >>>>>
> >>>>> Yes, if I add CONFIG_DM_RNG=y to imx8mm_evk_defconfig I get:
> >>>>>
> >>>>> U-Boot SPL 2024.04-00793-g3434b88d2c2f-dirty (Apr 18 2024 - 14:58:57
> >>>>> -0300)
> >>>>> No pmic
> >>>>> Couldn't bind rng driver (-96)
> >>>>> SEC0: RNG instantiated
> >>>>>
> >>>>> sec_init failed!
> >>>>
> >>>> Interesting. Which TFA blob version do you use ? I used the mainline
> >>>> 2.10 for my tests.
> >>>
> >>> Marek,
> >>>
> >>> Were you able to reproduce this as well with the board you enabled
> >>> DM_RNG for? If it does work fine what dtb were you using... perhaps
> >>> there is something in its u-boot.dtsi that we need?
> >>
> >> This one arch/arm/dts/imx8mp-dhcom-pdk3.dts , see log below. The build
> >> has a few extra patches in it, but nothing which affects the KASLR:
> >>
> >> $ export SOURCE_DATE_EPOCH=1672531200 ; echo tst > .scmversion
> >> $ make imx8mp_dhcom_pdk3_defconfig ; make
> >>
> >> U-Boot SPL 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +0000)
> >> DDR: 4096 MiB [0x5]
> >> DDR: Inline ECC enabled
> >> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout)
> >> Trying to boot from BOOTROM
> >> Boot Stage: Primary boot
> >> image offset 0x1000, pagesize 0x1, ivt offset 0x0
> >> NOTICE: Do not release JR0 to NS as it can be used by HAB
> >> NOTICE: BL31: v2.10.0 (release):v2.10.0-5-gfb51ca229
> >> NOTICE: BL31: Built : 20:30:36, Apr 23 2024
> >>
> >>
> >> U-Boot 2024.07-rc1tst (Jan 01 2023 - 00:00:00 +0000)
> >>
> >> CPU: Freescale i.MX8MP[8] rev1.1 1600 MHz (running at 1200 MHz)
> >> CPU: Industrial temperature grade (-40C to 105C) at 70C
> >> Reset cause: POR
> >> Model: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3)
> >> DRAM: 3.5 GiB
> >> Core: 183 devices, 34 uclasses, devicetree: separate
> >> WDT: Started watchdog@30280000 with servicing every 1000ms (60s timeout)
> >> MMC: FSL_SDHC: 0, FSL_SDHC: 1
> >> Loading Environment from SPIFlash... SF: Detected w25q128jw with page
> >> size 256 Bytes, erase size 4 KiB, total 16 MiB
> >> OK
> >> In: serial
> >> Out: serial
> >> Err: serial
> >> SEC0: RNG instantiated
> >> Net: eth1: ethernet@30be0000, eth0: ethernet@30bf0000
> >> ...
> >>
> >>> The error -EPFNOSUPPORT is interesting and helps point to the only
> >>> place it can be where the comment says the strange errno is to make
> >>> this easier to find:
> >>> https://elixir.bootlin.com/u-boot/latest/source/drivers/core/uclass.c#L70:
> >>> if (!uc_drv) {
> >>> debug("Cannot find uclass for id %d: please add the
> >>> UCLASS_DRIVER() declaration for this UCLASS_... id\n",
> >>> id);
> >>> /*
> >>> * Use a strange error to make this case easier to
> >>> find. When
> >>> * a uclass is not available it can prevent driver
> >>> model from
> >>> * starting up and this failure is otherwise hard to
> >>> debug.
> >>> */
> >>> return -EPFNOSUPPORT;
> >>> }
> >>>
> >>> I'm not very familiar with the dm driver binding - does the
> >>> U-BOOT_DRIVER usage in drivers/crypto/fsl/rng.c need to be refactored
> >>> to use UCLASS_DRIVER for it to be usable in both SPL and U-Boot?
> >>
> >> I don't think you need the CAAM RNG in SPL in the first place, or do you ?
> >>
> >>> Honestly I don't know why we need DM_RNG in SPL anyway and we could
> >>> just add support for disabling it there to avoid unwanted bloat.
> >>
> >> I think you can disable it , yes.
> >
> > Marek,
> >
> > Would it be advantageous for the kaslr-seed to be added automatically
> > from image_setup_libfdt?
>
> Yes, can you prepare a patch ? (I wanted to do this, just haven't had
> the time)
>
> > I notice arch/arm/cpu/armv8/fsl-layerscape/fdt.c:ft_cpu_setup does
> > this and board/raspberrypi/rpi/rpi.c looks like it copies kaslr-seed
> > from the control fdt which I assume was added by an earlier layer for
> > that target.
>
> Right, exactly, this .
>
> > I'm not clear if there is a disadvantage to automatically adding this
> > node if DM_RNG is enabled.
>
> I would say, add it.
Yes, I'll submit something this week.
Best Regards,
Tim
