[PATCH] ARM: imx: Enable kaslrseed command on DH i.MX8M Plus DHCOM

[Marek Vasut]

On 4/29/24 10:52 PM, Tim Harvey wrote:
> On Mon, Apr 29, 2024 at 1:51 PM Marek Vasut <marex at denx.de> wrote:
>>
>> On 4/29/24 9:10 PM, Tim Harvey wrote:
>>> On Tue, Apr 23, 2024 at 4:18 PM Marek Vasut <marex at denx.de> wrote:
>>>>
>>>> On 4/19/24 5:24 PM, Tim Harvey wrote:
>>>>> On Thu, Apr 18, 2024 at 11:42 AM Marek Vasut <marex at 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 <tharvey at 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 at 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 at 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 at 30be0000, eth0: ethernet at 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.

Thank you, much appreciated.