On 22.05.20 13:38, Heinrich Schuchardt wrote:
Am May 22, 2020 10:50:29 AM UTC schrieb Jan Kiszka jan.kiszka@siemens.com:
On 22.05.20 12:42, Heinrich Schuchardt wrote:
On 5/20/20 2:22 PM, Tom Rini wrote:
On Thu, May 07, 2020 at 08:36:03PM +0200, Jan Kiszka wrote:
From: Jan Kiszka jan.kiszka@siemens.com
This driver is safe to use in SPL without relocation. Denying DM_FLAG_PRE_RELOC prevents its usability for verifying the main
U-Boot
or other artifacts from the SPL unless needless enabling the full
driver
set (SPL_OF_PLATDATA).
Fixes: 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
DM_FLAG_PRE_RELOC")
CC: Heinrich Schuchardt xypron.glpk@gmx.de CC: Marek Vasut marex@denx.de Signed-off-by: Jan Kiszka jan.kiszka@siemens.com
Applied to u-boot/master, thanks!
With this patch applied pine64-lts_defconfig with CONFIG_RSA=y does
not
boot anymore. See the output below. So something is wrong with this
driver.
Do you have an idea how to analyze what is wrong? Unfortunately there
is
no DEBUG_UART available on the Pine A64 LTS board.
I would start crippling it down until things start to boot again. Are you using it (for image verification e.g.), or is this just the registration that breaks already?
RSA is needed in the UEFI subsystem for verifying variables and images. But there is no need in SPL for it at all.
In my configuration RSA is not used at all. Something breaks before even the console becomes available.
The pine64-lts_defconfig board boots via SPL->BL31->U-Boot
But then a workaround for you would be to turn this driver off in SPL. UEFI is main U-Boot only, isn't it?
That said, understanding the reason for the breakage would still be nice for the case someone needs to validate what SPL loads with the help of RSA (which is the case for us on an AM65x board).
Jan