* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC
@ 2020-05-07 18:36 Jan Kiszka
2020-05-20 12:22 ` Tom Rini
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2020-05-07 18:36 UTC (permalink / raw)
To: u-boot
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>
---
Changes in v2:
- patch the file I actually meant to patch
(was papered over by a local queue)
drivers/crypto/rsa_mod_exp/mod_exp_sw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
index c9b571a461..46b9f1825c 100644
--- a/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
+++ b/drivers/crypto/rsa_mod_exp/mod_exp_sw.c
@@ -31,6 +31,7 @@ U_BOOT_DRIVER(mod_exp_sw) = {
.name = "mod_exp_sw",
.id = UCLASS_MOD_EXP,
.ops = &mod_exp_ops_sw,
+ .flags = DM_FLAG_PRE_RELOC,
};
U_BOOT_DEVICE(mod_exp_sw) = {
--
2.26.1
^ permalink raw reply related [flat|nested] 11+ messages in thread* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-07 18:36 [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC Jan Kiszka @ 2020-05-20 12:22 ` Tom Rini 2020-05-22 10:42 ` Heinrich Schuchardt 0 siblings, 1 reply; 11+ messages in thread From: Tom Rini @ 2020-05-20 12:22 UTC (permalink / raw) To: u-boot 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! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200520/ca1c54c2/attachment.sig> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-20 12:22 ` Tom Rini @ 2020-05-22 10:42 ` Heinrich Schuchardt 2020-05-22 10:50 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Heinrich Schuchardt @ 2020-05-22 10:42 UTC (permalink / raw) To: u-boot 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. Best regards Heinrich U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 NOTICE: BL31: Built : 05:50:47, Apr 7 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP803 on RSB INFO: PMIC: dcdc1 voltage: 3.300V INFO: PMIC: dcdc5 voltage: 1.200V INFO: PMIC: dcdc6 voltage: 1.100V INFO: PMIC: dldo1 voltage: 3.300V INFO: PMIC: Enabling DC SW INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 843419 was applied INFO: BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 NOTICE: BL31: Built : 05:50:47, Apr 7 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP803 on RSB INFO: PMIC: dcdc1 voltage: 3.300V INFO: PMIC: dcdc5 voltage: 1.200V INFO: PMIC: dcdc6 voltage: 1.100V INFO: PMIC: dldo1 voltage: 3.300V INFO: PMIC: Enabling DC SW INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 843419 was applied INFO: BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) DRAM: 2048 MiB Trying to boot from MMC1 NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 NOTICE: BL31: Built : 05:50:47, Apr 7 2020 NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS INFO: ARM GICv2 driver initialized INFO: Configuring SPC Controller INFO: PMIC: Probing AXP803 on RSB INFO: PMIC: dcdc1 voltage: 3.300V INFO: PMIC: dcdc5 voltage: 1.200V INFO: PMIC: dcdc6 voltage: 1.100V INFO: PMIC: dldo1 voltage: 3.300V INFO: PMIC: Enabling DC SW INFO: BL31: Platform setup done INFO: BL31: Initializing runtime services INFO: BL31: cortex_a53: CPU workaround for 843419 was applied INFO: BL31: cortex_a53: CPU workaround for 855873 was applied NOTICE: PSCI: System suspend is unavailable INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x4a000000 INFO: SPSR = 0x3c9 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 10:42 ` Heinrich Schuchardt @ 2020-05-22 10:50 ` Jan Kiszka 2020-05-22 11:38 ` Heinrich Schuchardt 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2020-05-22 10:50 UTC (permalink / raw) To: u-boot 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? Jan > > Best regards > > Heinrich > > > > U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 > NOTICE: BL31: Built : 05:50:47, Apr 7 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS > INFO: ARM GICv2 driver initialized > INFO: Configuring SPC Controller > INFO: PMIC: Probing AXP803 on RSB > INFO: PMIC: dcdc1 voltage: 3.300V > INFO: PMIC: dcdc5 voltage: 1.200V > INFO: PMIC: dcdc6 voltage: 1.100V > INFO: PMIC: dldo1 voltage: 3.300V > INFO: PMIC: Enabling DC SW > INFO: BL31: Platform setup done > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 843419 was applied > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > NOTICE: PSCI: System suspend is unavailable > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x4a000000 > INFO: SPSR = 0x3c9 > > U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 > NOTICE: BL31: Built : 05:50:47, Apr 7 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS > INFO: ARM GICv2 driver initialized > INFO: Configuring SPC Controller > INFO: PMIC: Probing AXP803 on RSB > INFO: PMIC: dcdc1 voltage: 3.300V > INFO: PMIC: dcdc5 voltage: 1.200V > INFO: PMIC: dcdc6 voltage: 1.100V > INFO: PMIC: dldo1 voltage: 3.300V > INFO: PMIC: Enabling DC SW > INFO: BL31: Platform setup done > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 843419 was applied > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > NOTICE: PSCI: System suspend is unavailable > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x4a000000 > INFO: SPSR = 0x3c9 > > U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 +0000) > DRAM: 2048 MiB > Trying to boot from MMC1 > NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 > NOTICE: BL31: Built : 05:50:47, Apr 7 2020 > NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) > NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS > INFO: ARM GICv2 driver initialized > INFO: Configuring SPC Controller > INFO: PMIC: Probing AXP803 on RSB > INFO: PMIC: dcdc1 voltage: 3.300V > INFO: PMIC: dcdc5 voltage: 1.200V > INFO: PMIC: dcdc6 voltage: 1.100V > INFO: PMIC: dldo1 voltage: 3.300V > INFO: PMIC: Enabling DC SW > INFO: BL31: Platform setup done > INFO: BL31: Initializing runtime services > INFO: BL31: cortex_a53: CPU workaround for 843419 was applied > INFO: BL31: cortex_a53: CPU workaround for 855873 was applied > NOTICE: PSCI: System suspend is unavailable > INFO: BL31: Preparing for EL3 exit to normal world > INFO: Entry point address = 0x4a000000 > INFO: SPSR = 0x3c9 > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 10:50 ` Jan Kiszka @ 2020-05-22 11:38 ` Heinrich Schuchardt 2020-05-22 12:21 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Heinrich Schuchardt @ 2020-05-22 11:38 UTC (permalink / raw) To: u-boot 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 Best regards Heinrich >Jan > >> >> Best regards >> >> Heinrich >> >> >> >> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 >+0000) >> DRAM: 2048 MiB >> Trying to boot from MMC1 >> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 >> NOTICE: BL31: Built : 05:50:47, Apr 7 2020 >> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) >> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS >> INFO: ARM GICv2 driver initialized >> INFO: Configuring SPC Controller >> INFO: PMIC: Probing AXP803 on RSB >> INFO: PMIC: dcdc1 voltage: 3.300V >> INFO: PMIC: dcdc5 voltage: 1.200V >> INFO: PMIC: dcdc6 voltage: 1.100V >> INFO: PMIC: dldo1 voltage: 3.300V >> INFO: PMIC: Enabling DC SW >> INFO: BL31: Platform setup done >> INFO: BL31: Initializing runtime services >> INFO: BL31: cortex_a53: CPU workaround for 843419 was applied >> INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >> NOTICE: PSCI: System suspend is unavailable >> INFO: BL31: Preparing for EL3 exit to normal world >> INFO: Entry point address = 0x4a000000 >> INFO: SPSR = 0x3c9 >> >> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 >+0000) >> DRAM: 2048 MiB >> Trying to boot from MMC1 >> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 >> NOTICE: BL31: Built : 05:50:47, Apr 7 2020 >> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) >> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS >> INFO: ARM GICv2 driver initialized >> INFO: Configuring SPC Controller >> INFO: PMIC: Probing AXP803 on RSB >> INFO: PMIC: dcdc1 voltage: 3.300V >> INFO: PMIC: dcdc5 voltage: 1.200V >> INFO: PMIC: dcdc6 voltage: 1.100V >> INFO: PMIC: dldo1 voltage: 3.300V >> INFO: PMIC: Enabling DC SW >> INFO: BL31: Platform setup done >> INFO: BL31: Initializing runtime services >> INFO: BL31: cortex_a53: CPU workaround for 843419 was applied >> INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >> NOTICE: PSCI: System suspend is unavailable >> INFO: BL31: Preparing for EL3 exit to normal world >> INFO: Entry point address = 0x4a000000 >> INFO: SPSR = 0x3c9 >> >> U-Boot SPL 2020.07-rc2-00070-g2fa581ba91 (May 22 2020 - 10:29:30 >+0000) >> DRAM: 2048 MiB >> Trying to boot from MMC1 >> NOTICE: BL31: v2.2():v2.2-1138-g78460ced4 >> NOTICE: BL31: Built : 05:50:47, Apr 7 2020 >> NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689) >> NOTICE: BL31: Found U-Boot DTB at 0x4091998, model: Pine64 LTS >> INFO: ARM GICv2 driver initialized >> INFO: Configuring SPC Controller >> INFO: PMIC: Probing AXP803 on RSB >> INFO: PMIC: dcdc1 voltage: 3.300V >> INFO: PMIC: dcdc5 voltage: 1.200V >> INFO: PMIC: dcdc6 voltage: 1.100V >> INFO: PMIC: dldo1 voltage: 3.300V >> INFO: PMIC: Enabling DC SW >> INFO: BL31: Platform setup done >> INFO: BL31: Initializing runtime services >> INFO: BL31: cortex_a53: CPU workaround for 843419 was applied >> INFO: BL31: cortex_a53: CPU workaround for 855873 was applied >> NOTICE: PSCI: System suspend is unavailable >> INFO: BL31: Preparing for EL3 exit to normal world >> INFO: Entry point address = 0x4a000000 >> INFO: SPSR = 0x3c9 >> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 11:38 ` Heinrich Schuchardt @ 2020-05-22 12:21 ` Jan Kiszka 2020-05-22 14:55 ` Heinrich Schuchardt 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2020-05-22 12:21 UTC (permalink / raw) To: u-boot 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 -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 12:21 ` Jan Kiszka @ 2020-05-22 14:55 ` Heinrich Schuchardt 2020-05-22 15:21 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Heinrich Schuchardt @ 2020-05-22 14:55 UTC (permalink / raw) To: u-boot On 22.05.20 14:21, Jan Kiszka wrote: > 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 > As I described above I did *not* select RSA_SPL. The breakage is in main U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But during driver initialization U-Boot does not even reach the point where we have a console due to something wrong with DM_FLAG_PRE_RELOC. Best regards Heinrich ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 14:55 ` Heinrich Schuchardt @ 2020-05-22 15:21 ` Jan Kiszka 2020-05-22 18:12 ` Heinrich Schuchardt 0 siblings, 1 reply; 11+ messages in thread From: Jan Kiszka @ 2020-05-22 15:21 UTC (permalink / raw) To: u-boot On 22.05.20 16:55, Heinrich Schuchardt wrote: > On 22.05.20 14:21, Jan Kiszka wrote: >> 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 >> > As I described above I did *not* select RSA_SPL. The breakage is in main > U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But > during driver initialization U-Boot does not even reach the point where > we have a console due to something wrong with DM_FLAG_PRE_RELOC. > Sorry, missed that detail. But that is indeed weird because - to my understanding - this driver should be totally passive until someone calls rsa_mod_exp() (which should only happen late, when UEFI comes into play). Can you validate that this function is not involved by emptying its body? Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC to BUILD_SPL. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 15:21 ` Jan Kiszka @ 2020-05-22 18:12 ` Heinrich Schuchardt 2020-05-31 15:34 ` Heinrich Schuchardt 0 siblings, 1 reply; 11+ messages in thread From: Heinrich Schuchardt @ 2020-05-22 18:12 UTC (permalink / raw) To: u-boot On 5/22/20 5:21 PM, Jan Kiszka wrote: > On 22.05.20 16:55, Heinrich Schuchardt wrote: >> On 22.05.20 14:21, Jan Kiszka wrote: >>> 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 >>> >> As I described above I did *not* select RSA_SPL. The breakage is in main >> U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But >> during driver initialization U-Boot does not even reach the point where >> we have a console due to something wrong with DM_FLAG_PRE_RELOC. >> > > Sorry, missed that detail. But that is indeed weird because - to my > understanding - this driver should be totally passive until someone > calls rsa_mod_exp() (which should only happen late, when UEFI comes into > play). > > Can you validate that this function is not involved by emptying its body? > > Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC > to BUILD_SPL. > > Jan > Disabling the only consumer of UCLASS_MOD_EXP does not help. diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index 1d55b997e3..89a08274f2 100644 --- a/lib/rsa/rsa-verify.c +++ b/lib/rsa/rsa-verify.c @@ -334,7 +334,8 @@ static int rsa_verify_key(struct image_sign_info *info, hash_len = checksum->checksum_len; #if !defined(USE_HOSTCC) - ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); + //ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); + ret = 1; Emptying function mod_exp_sw() does not help. The board boots if I rename the driver: U_BOOT_DRIVER(mod_exp_sw) = { - .name = "mod_exp_sw", + .name = "mod_exp_sw1", So it seems the very act of loading the driver before relocation is enough to cause the problem. To be more specific, if ??????? ret = uclass_get(drv->id, &uc); is called in device_bind_common() - drivers/core/device.c for name = "mod_exp_sw" booting fails. This does not boot: ret = uclass_get(drv->id, &uc); + if (!strcmp(name, "mod_exp_sw")) + return -ENOENT; This does boot: + if (!strcmp(name, "mod_exp_sw")) + return -ENOENT; ret = uclass_get(drv->id, &uc); So I tried to look into uclass_get(): If uc = calloc(1, sizeof(*uc)); is executed in uclass_add() for UCLASS_MOD_EXP booting fails. This does not boot: uc = calloc(1, sizeof(*uc)); if (!uc) return -ENOMEM; + if (id == UCLASS_MOD_EXP) + return -ENOENT; This boots: + if (id == UCLASS_MOD_EXP) + return -ENOENT; uc = calloc(1, sizeof(*uc)); Enlarging CONFIG_SYS_MALLOC_F_LEN from 0x400 to 0x8000 does not help. Best regards Heinrich ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-22 18:12 ` Heinrich Schuchardt @ 2020-05-31 15:34 ` Heinrich Schuchardt 2020-06-01 14:16 ` Jan Kiszka 0 siblings, 1 reply; 11+ messages in thread From: Heinrich Schuchardt @ 2020-05-31 15:34 UTC (permalink / raw) To: u-boot On 5/22/20 8:12 PM, Heinrich Schuchardt wrote: > On 5/22/20 5:21 PM, Jan Kiszka wrote: >> On 22.05.20 16:55, Heinrich Schuchardt wrote: >>> On 22.05.20 14:21, Jan Kiszka wrote: >>>> 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 >>>> >>> As I described above I did *not* select RSA_SPL. The breakage is in main >>> U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But >>> during driver initialization U-Boot does not even reach the point where >>> we have a console due to something wrong with DM_FLAG_PRE_RELOC. >>> >> >> Sorry, missed that detail. But that is indeed weird because - to my >> understanding - this driver should be totally passive until someone >> calls rsa_mod_exp() (which should only happen late, when UEFI comes into >> play). >> >> Can you validate that this function is not involved by emptying its body? >> >> Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC >> to BUILD_SPL. >> >> Jan >> > > Disabling the only consumer of UCLASS_MOD_EXP does not help. > > diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c > index 1d55b997e3..89a08274f2 100644 > --- a/lib/rsa/rsa-verify.c > +++ b/lib/rsa/rsa-verify.c > @@ -334,7 +334,8 @@ static int rsa_verify_key(struct image_sign_info *info, > hash_len = checksum->checksum_len; > > #if !defined(USE_HOSTCC) > - ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); > + //ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); > + ret = 1; > > Emptying function mod_exp_sw() does not help. > > The board boots if I rename the driver: > > U_BOOT_DRIVER(mod_exp_sw) = { > - .name = "mod_exp_sw", > + .name = "mod_exp_sw1", > > So it seems the very act of loading the driver before relocation is > enough to cause the problem. > > To be more specific, if > > ??????? ret = uclass_get(drv->id, &uc); > > is called in device_bind_common() - drivers/core/device.c for name = > "mod_exp_sw" booting fails. > > This does not boot: > > ret = uclass_get(drv->id, &uc); > + if (!strcmp(name, "mod_exp_sw")) > + return -ENOENT; > > This does boot: > > + if (!strcmp(name, "mod_exp_sw")) > + return -ENOENT; > ret = uclass_get(drv->id, &uc); > > So I tried to look into uclass_get(): > > If > > uc = calloc(1, sizeof(*uc)); > > is executed in uclass_add() for UCLASS_MOD_EXP booting fails. > > This does not boot: > > uc = calloc(1, sizeof(*uc)); > if (!uc) > return -ENOMEM; > + if (id == UCLASS_MOD_EXP) > + return -ENOENT; > > This boots: > > + if (id == UCLASS_MOD_EXP) > + return -ENOENT; > uc = calloc(1, sizeof(*uc)); > > Enlarging CONFIG_SYS_MALLOC_F_LEN from 0x400 to 0x8000 does not help. > > Best regards > > Heinrich > What finally helps is CONFIG_INIT_SP_RELATIVE=y. diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig index ef108a1a31..b03bef01b1 100644 --- a/configs/pine64-lts_defconfig +++ b/configs/pine64-lts_defconfig @@ -1,5 +1,8 @@ CONFIG_ARM=y +CONFIG_INIT_SP_RELATIVE=y CONFIG_ARCH_SUNXI=y +CONFIG_SYS_MALLOC_F_LEN=0x8000 +CONSPL_SYS_MALLOC_F_LEN=FIG_0x400 CONFIG_SPL=y CONFIG_MACH_SUN50I=y CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y Best regards Heinrich ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC 2020-05-31 15:34 ` Heinrich Schuchardt @ 2020-06-01 14:16 ` Jan Kiszka 0 siblings, 0 replies; 11+ messages in thread From: Jan Kiszka @ 2020-06-01 14:16 UTC (permalink / raw) To: u-boot On 31.05.20 17:34, Heinrich Schuchardt wrote: > On 5/22/20 8:12 PM, Heinrich Schuchardt wrote: >> On 5/22/20 5:21 PM, Jan Kiszka wrote: >>> On 22.05.20 16:55, Heinrich Schuchardt wrote: >>>> On 22.05.20 14:21, Jan Kiszka wrote: >>>>> 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 >>>>> >>>> As I described above I did *not* select RSA_SPL. The breakage is in main >>>> U-boot. SPL works fine loading TF-A BL31 which in turn loads U-Boot. But >>>> during driver initialization U-Boot does not even reach the point where >>>> we have a console due to something wrong with DM_FLAG_PRE_RELOC. >>>> >>> >>> Sorry, missed that detail. But that is indeed weird because - to my >>> understanding - this driver should be totally passive until someone >>> calls rsa_mod_exp() (which should only happen late, when UEFI comes into >>> play). >>> >>> Can you validate that this function is not involved by emptying its body? >>> >>> Also, until everything is understood, we could limit DM_FLAG_PRE_RELOC >>> to BUILD_SPL. >>> >>> Jan >>> >> >> Disabling the only consumer of UCLASS_MOD_EXP does not help. >> >> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c >> index 1d55b997e3..89a08274f2 100644 >> --- a/lib/rsa/rsa-verify.c >> +++ b/lib/rsa/rsa-verify.c >> @@ -334,7 +334,8 @@ static int rsa_verify_key(struct image_sign_info *info, >> hash_len = checksum->checksum_len; >> >> #if !defined(USE_HOSTCC) >> - ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); >> + //ret = uclass_get_device(UCLASS_MOD_EXP, 0, &mod_exp_dev); >> + ret = 1; >> >> Emptying function mod_exp_sw() does not help. >> >> The board boots if I rename the driver: >> >> U_BOOT_DRIVER(mod_exp_sw) = { >> - .name = "mod_exp_sw", >> + .name = "mod_exp_sw1", >> >> So it seems the very act of loading the driver before relocation is >> enough to cause the problem. >> >> To be more specific, if >> >> ??????? ret = uclass_get(drv->id, &uc); >> >> is called in device_bind_common() - drivers/core/device.c for name = >> "mod_exp_sw" booting fails. >> >> This does not boot: >> >> ret = uclass_get(drv->id, &uc); >> + if (!strcmp(name, "mod_exp_sw")) >> + return -ENOENT; >> >> This does boot: >> >> + if (!strcmp(name, "mod_exp_sw")) >> + return -ENOENT; >> ret = uclass_get(drv->id, &uc); >> >> So I tried to look into uclass_get(): >> >> If >> >> uc = calloc(1, sizeof(*uc)); >> >> is executed in uclass_add() for UCLASS_MOD_EXP booting fails. >> >> This does not boot: >> >> uc = calloc(1, sizeof(*uc)); >> if (!uc) >> return -ENOMEM; >> + if (id == UCLASS_MOD_EXP) >> + return -ENOENT; >> >> This boots: >> >> + if (id == UCLASS_MOD_EXP) >> + return -ENOENT; >> uc = calloc(1, sizeof(*uc)); >> >> Enlarging CONFIG_SYS_MALLOC_F_LEN from 0x400 to 0x8000 does not help. >> >> Best regards >> >> Heinrich >> > > What finally helps is CONFIG_INIT_SP_RELATIVE=y. > > diff --git a/configs/pine64-lts_defconfig b/configs/pine64-lts_defconfig > index ef108a1a31..b03bef01b1 100644 > --- a/configs/pine64-lts_defconfig > +++ b/configs/pine64-lts_defconfig > @@ -1,5 +1,8 @@ > CONFIG_ARM=y > +CONFIG_INIT_SP_RELATIVE=y > CONFIG_ARCH_SUNXI=y > +CONFIG_SYS_MALLOC_F_LEN=0x8000 > +CONSPL_SYS_MALLOC_F_LEN=FIG_0x400 > CONFIG_SPL=y > CONFIG_MACH_SUN50I=y > CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y > Good that this is resolved. Is it a dependency that should be selected by the target or some other option? Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-06-01 14:16 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-05-07 18:36 [PATCH v2] drivers: crypto: mod_exp_sw: Re-add DM_FLAG_PRE_RELOC Jan Kiszka 2020-05-20 12:22 ` Tom Rini 2020-05-22 10:42 ` Heinrich Schuchardt 2020-05-22 10:50 ` Jan Kiszka 2020-05-22 11:38 ` Heinrich Schuchardt 2020-05-22 12:21 ` Jan Kiszka 2020-05-22 14:55 ` Heinrich Schuchardt 2020-05-22 15:21 ` Jan Kiszka 2020-05-22 18:12 ` Heinrich Schuchardt 2020-05-31 15:34 ` Heinrich Schuchardt 2020-06-01 14:16 ` Jan Kiszka
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.