* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
@ 2020-05-31 10:43 Heinrich Schuchardt
2020-05-31 15:32 ` Fwd: " Heinrich Schuchardt
2020-06-02 15:51 ` Tom Rini
0 siblings, 2 replies; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-05-31 10:43 UTC (permalink / raw)
To: u-boot
Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
fails if CONFIG_INIT_SP_RELATIVE is not set.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
configs/pine64-lts_defconfig | 3 +++
1 file changed, 3 insertions(+)
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
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
CONFIG_SPL=y
CONFIG_MACH_SUN50I=y
CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
--
2.20.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Fwd: [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-05-31 10:43 [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS Heinrich Schuchardt
@ 2020-05-31 15:32 ` Heinrich Schuchardt
2020-06-02 15:51 ` Tom Rini
1 sibling, 0 replies; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-05-31 15:32 UTC (permalink / raw)
To: u-boot
On 5/31/20 12:43 PM, Heinrich Schuchardt wrote:
> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
> fails if CONFIG_INIT_SP_RELATIVE is not set.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
CC: Jagan Teki <jagan@amarulasolutions.com>
Is this something that should be solved on board config level or on the
SUNXI level?
Where is the stack pointer currently defined for the sunxi boards?
Best regards
Heinrich
> ---
> configs/pine64-lts_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> 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
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
> CONFIG_SPL=y
> CONFIG_MACH_SUN50I=y
> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> --
> 2.20.1
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-05-31 10:43 [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS Heinrich Schuchardt
2020-05-31 15:32 ` Fwd: " Heinrich Schuchardt
@ 2020-06-02 15:51 ` Tom Rini
2020-06-02 19:45 ` Heinrich Schuchardt
1 sibling, 1 reply; 10+ messages in thread
From: Tom Rini @ 2020-06-02 15:51 UTC (permalink / raw)
To: u-boot
On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
> fails if CONFIG_INIT_SP_RELATIVE is not set.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> configs/pine64-lts_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
> 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
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
> CONFIG_SPL=y
> CONFIG_MACH_SUN50I=y
> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
Look at the option however. This is something that all sunxi should be
selecting. And if this is intentional as part of the design, an audit
of the other ARM64 SoCs would be in order to see who else didn't know
they needed to select this. 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/20200602/1fe74f65/attachment.sig>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-02 15:51 ` Tom Rini
@ 2020-06-02 19:45 ` Heinrich Schuchardt
2020-06-02 19:55 ` Tom Rini
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-06-02 19:45 UTC (permalink / raw)
To: u-boot
On 6/2/20 5:51 PM, Tom Rini wrote:
> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>
>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>
>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>> ---
>> configs/pine64-lts_defconfig | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> 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
>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>> CONFIG_SPL=y
>> CONFIG_MACH_SUN50I=y
>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>
> Look at the option however. This is something that all sunxi should be
> selecting.
What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
> And if this is intentional as part of the design, an audit
> of the other ARM64 SoCs would be in order to see who else didn't know
> they needed to select this. Thanks!
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-02 19:45 ` Heinrich Schuchardt
@ 2020-06-02 19:55 ` Tom Rini
2020-06-02 23:46 ` André Przywara
0 siblings, 1 reply; 10+ messages in thread
From: Tom Rini @ 2020-06-02 19:55 UTC (permalink / raw)
To: u-boot
On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
> On 6/2/20 5:51 PM, Tom Rini wrote:
> > On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
> >
> >> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
> >> fails if CONFIG_INIT_SP_RELATIVE is not set.
> >>
> >> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> ---
> >> configs/pine64-lts_defconfig | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> 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
> >> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
> >> CONFIG_SPL=y
> >> CONFIG_MACH_SUN50I=y
> >> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
> >
> > Look at the option however. This is something that all sunxi should be
> > selecting.
>
> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
config INIT_SP_RELATIVE
bool "Specify the early stack pointer relative to the .bss section"
help
U-Boot typically uses a hard-coded value for the stack pointer
before relocation. Enable this option to instead calculate the
initial SP at run-time. This is useful to avoid hard-coding addresses
into U-Boot, so that it can be loaded and executed at arbitrary
addresses and thus avoid using arbitrary addresses at runtime.
If this option is enabled, the early stack pointer is set to
&_bss_start with a offset value added. The offset is specified by
SYS_INIT_SP_BSS_OFFSET.
And that in turn tells me this is something that's done at the SoC
level, especially for sunxi where things have been abstracted such that
everyone (very roughly) shares the same board file, linker file, etc,
and it's just defconfig+dts* files that change from board to board.
So, to put it another way, what about the pine64-lts config is unique
and causing this to be needed, but another arm64 sunxi platform would
not?
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/20200602/ba36b369/attachment.sig>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-02 19:55 ` Tom Rini
@ 2020-06-02 23:46 ` André Przywara
2020-06-03 15:47 ` Heinrich Schuchardt
0 siblings, 1 reply; 10+ messages in thread
From: André Przywara @ 2020-06-02 23:46 UTC (permalink / raw)
To: u-boot
On 02/06/2020 20:55, Tom Rini wrote:
Hi,
> On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
>> On 6/2/20 5:51 PM, Tom Rini wrote:
>>> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>>>
>>>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>>>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>>>
>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> ---
>>>> configs/pine64-lts_defconfig | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> 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
>>>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>>>> CONFIG_SPL=y
>>>> CONFIG_MACH_SUN50I=y
>>>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>>
>>> Look at the option however. This is something that all sunxi should be
>>> selecting.
>>
>> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
>
> config INIT_SP_RELATIVE
> bool "Specify the early stack pointer relative to the .bss section"
> help
> U-Boot typically uses a hard-coded value for the stack pointer
> before relocation. Enable this option to instead calculate the
> initial SP at run-time. This is useful to avoid hard-coding addresses
> into U-Boot, so that it can be loaded and executed at arbitrary
> addresses and thus avoid using arbitrary addresses at runtime.
>
> If this option is enabled, the early stack pointer is set to
> &_bss_start with a offset value added. The offset is specified by
> SYS_INIT_SP_BSS_OFFSET.
>
> And that in turn tells me this is something that's done at the SoC
> level, especially for sunxi where things have been abstracted such that
> everyone (very roughly) shares the same board file, linker file, etc,
> and it's just defconfig+dts* files that change from board to board.
I agree on that, this particular defconfig change is generic to all
sunxi boards and we should fix this properly for the whole platform.
> So, to put it another way, what about the pine64-lts config is unique
> and causing this to be needed, but another arm64 sunxi platform would
> not?
I think were Heinrich came from is selecting CONFIG_RSA for his
particular build. I guess this requires a bigger malloc area. Now this
somehow collides which how we calculate the stack pointer, but it is too
late here to really track this down ;-)
Heinrich, can you please give an explanation what problem
CONFIG_INIT_SP_RELATIVE fixed and why? It seems like to cause some side
effect, but does not sound like the proper solution (because this is
more mean for the position independent build option).
Cheers,
Andre
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-02 23:46 ` André Przywara
@ 2020-06-03 15:47 ` Heinrich Schuchardt
2020-06-03 16:31 ` André Przywara
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-06-03 15:47 UTC (permalink / raw)
To: u-boot
On 03.06.20 01:46, Andr? Przywara wrote:
> On 02/06/2020 20:55, Tom Rini wrote:
>
> Hi,
>
>> On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
>>> On 6/2/20 5:51 PM, Tom Rini wrote:
>>>> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>>>>
>>>>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>>>>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>>>>
>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>> ---
>>>>> configs/pine64-lts_defconfig | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> 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
>>>>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>>>>> CONFIG_SPL=y
>>>>> CONFIG_MACH_SUN50I=y
>>>>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>>>
>>>> Look at the option however. This is something that all sunxi should be
>>>> selecting.
>>>
>>> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
>>
>> config INIT_SP_RELATIVE
>> bool "Specify the early stack pointer relative to the .bss section"
>> help
>> U-Boot typically uses a hard-coded value for the stack pointer
>> before relocation. Enable this option to instead calculate the
>> initial SP at run-time. This is useful to avoid hard-coding addresses
>> into U-Boot, so that it can be loaded and executed at arbitrary
>> addresses and thus avoid using arbitrary addresses at runtime.
>>
>> If this option is enabled, the early stack pointer is set to
>> &_bss_start with a offset value added. The offset is specified by
>> SYS_INIT_SP_BSS_OFFSET.
>>
>> And that in turn tells me this is something that's done at the SoC
>> level, especially for sunxi where things have been abstracted such that
>> everyone (very roughly) shares the same board file, linker file, etc,
>> and it's just defconfig+dts* files that change from board to board.
>
> I agree on that, this particular defconfig change is generic to all
> sunxi boards and we should fix this properly for the whole platform.
>
>> So, to put it another way, what about the pine64-lts config is unique
>> and causing this to be needed, but another arm64 sunxi platform would
>> not?
>
> I think were Heinrich came from is selecting CONFIG_RSA for his
> particular build. I guess this requires a bigger malloc area. Now this
> somehow collides which how we calculate the stack pointer, but it is too
> late here to really track this down ;-)
>
> Heinrich, can you please give an explanation what problem
> CONFIG_INIT_SP_RELATIVE fixed and why? It seems like to cause some side
> effect, but does not sound like the proper solution (because this is
> more mean for the position independent build option).
>
> Cheers,
> Andre
>
Hello Andr?,
the problem is reproducible on the FriendlyARM NanoPi NEO Plus2. So Tom
is right in that we should solve it for all Allwinner ARMv8 devices.
I simply use a nanopi_neo_plus2_defconfig or pine64-lts_defconfig and
add CONFIG_RSA=y.
The result is that the whenever the BL31 loads main U-Boot the board
falls back to SPL. This loops forever. See below.
CONFIG_RSA=y is needed for signed UEFI variables and other use cases.
But the problem is not specific to RSA. You get into the same kind of
problems when selecting CONFIG_LOG=y.
With CONFIG_INIT_SP_RELATIVE=y the problem disappears.
As this all happens before we have a U-Boot console I was not able to
debug further than what I wrote in the thread
https://lists.denx.de/pipermail/u-boot/2020-May/414346.html. A
DEBUG_UART configuration for sunxi would have been very helpful here.
Best regards
Heinrich
U-Boot SPL 2020.07-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
NOTICE: BL31: Built : 22:17:08, Mar 30 2020
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
NEO Plus2
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
NOTICE: PMIC: Assuming H5 reference regulator design
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
NOTICE: BL31: Built : 22:17:08, Mar 30 2020
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
NEO Plus2
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
NOTICE: PMIC: Assuming H5 reference regulator design
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
NOTICE: BL31: Built : 22:17:08, Mar 30 2020
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
NEO Plus2
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
NOTICE: PMIC: Assuming H5 reference regulator design
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
DRAM: 1024 MiB
Trying to boot from MMC1
NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
NOTICE: BL31: Built : 22:17:08, Mar 30 2020
NOTICE: BL31: Detected Allwinner H5 SoC (1718)
NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
NEO Plus2
INFO: ARM GICv2 driver initialized
INFO: Configuring SPC Controller
NOTICE: PMIC: Assuming H5 reference regulator design
INFO: BL31: Platform setup done
INFO: BL31: Initializing runtime services
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] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-03 15:47 ` Heinrich Schuchardt
@ 2020-06-03 16:31 ` André Przywara
2020-06-03 17:07 ` Heinrich Schuchardt
0 siblings, 1 reply; 10+ messages in thread
From: André Przywara @ 2020-06-03 16:31 UTC (permalink / raw)
To: u-boot
On 03/06/2020 16:47, Heinrich Schuchardt wrote:
Hi Heinrich,
> On 03.06.20 01:46, Andr? Przywara wrote:
>> On 02/06/2020 20:55, Tom Rini wrote:
>>
>> Hi,
>>
>>> On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
>>>> On 6/2/20 5:51 PM, Tom Rini wrote:
>>>>> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>>>>>
>>>>>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>>>>>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>>>>>
>>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>> ---
>>>>>> configs/pine64-lts_defconfig | 3 +++
>>>>>> 1 file changed, 3 insertions(+)
>>>>>>
>>>>>> 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
>>>>>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>>>>>> CONFIG_SPL=y
>>>>>> CONFIG_MACH_SUN50I=y
>>>>>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>>>>
>>>>> Look at the option however. This is something that all sunxi should be
>>>>> selecting.
>>>>
>>>> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
>>>
>>> config INIT_SP_RELATIVE
>>> bool "Specify the early stack pointer relative to the .bss section"
>>> help
>>> U-Boot typically uses a hard-coded value for the stack pointer
>>> before relocation. Enable this option to instead calculate the
>>> initial SP at run-time. This is useful to avoid hard-coding addresses
>>> into U-Boot, so that it can be loaded and executed at arbitrary
>>> addresses and thus avoid using arbitrary addresses at runtime.
>>>
>>> If this option is enabled, the early stack pointer is set to
>>> &_bss_start with a offset value added. The offset is specified by
>>> SYS_INIT_SP_BSS_OFFSET.
>>>
>>> And that in turn tells me this is something that's done at the SoC
>>> level, especially for sunxi where things have been abstracted such that
>>> everyone (very roughly) shares the same board file, linker file, etc,
>>> and it's just defconfig+dts* files that change from board to board.
>>
>> I agree on that, this particular defconfig change is generic to all
>> sunxi boards and we should fix this properly for the whole platform.
>>
>>> So, to put it another way, what about the pine64-lts config is unique
>>> and causing this to be needed, but another arm64 sunxi platform would
>>> not?
>>
>> I think were Heinrich came from is selecting CONFIG_RSA for his
>> particular build. I guess this requires a bigger malloc area. Now this
>> somehow collides which how we calculate the stack pointer, but it is too
>> late here to really track this down ;-)
>>
>> Heinrich, can you please give an explanation what problem
>> CONFIG_INIT_SP_RELATIVE fixed and why? It seems like to cause some side
>> effect, but does not sound like the proper solution (because this is
>> more mean for the position independent build option).
>>
>> Cheers,
>> Andre
>>
>
> Hello Andr?,
>
> the problem is reproducible on the FriendlyARM NanoPi NEO Plus2. So Tom
> is right in that we should solve it for all Allwinner ARMv8 devices.
Thanks for testing this, and yeah, I am not surprised. As Tom mentioned,
all (arm64) Allwinner boards are the same in those basic aspects.
> I simply use a nanopi_neo_plus2_defconfig or pine64-lts_defconfig and
> add CONFIG_RSA=y.
>
> The result is that the whenever the BL31 loads main U-Boot the board
> falls back to SPL. This loops forever. See below.
>
> CONFIG_RSA=y is needed for signed UEFI variables and other use cases.
>
> But the problem is not specific to RSA. You get into the same kind of
> problems when selecting CONFIG_LOG=y.
>
> With CONFIG_INIT_SP_RELATIVE=y the problem disappears.
>
> As this all happens before we have a U-Boot console I was not able to
> debug further than what I wrote in the thread
> https://lists.denx.de/pipermail/u-boot/2020-May/414346.html. A
> DEBUG_UART configuration for sunxi would have been very helpful here.
Many thanks for the info, that looks very helpful! I wasn't sure if the
problem is in the SPL (because you just increased the malloc area for
U-Boot proper), but it looks very much like it. I will dig out some
debug techniques I used in the past to see what's actually going on. The
code size for Allwinner arm64 SPL is very limited, so we had this issue
before, where the stack ran into the code (if it didn't already violate
the build time limit check).
I am just a bit puzzled how CONFIG_INIT_SP_RELATIVE fixes this, as it
looks to me that just this option alone is not enough to make this work.
Cheers,
Andre
> Best regards
>
> Heinrich
>
> U-Boot SPL 2020.07-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
> NOTICE: BL31: Built : 22:17:08, Mar 30 2020
> NOTICE: BL31: Detected Allwinner H5 SoC (1718)
> NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
> NEO Plus2
> INFO: ARM GICv2 driver initialized
> INFO: Configuring SPC Controller
> NOTICE: PMIC: Assuming H5 reference regulator design
> INFO: BL31: Platform setup done
> INFO: BL31: Initializing runtime services
> 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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
> NOTICE: BL31: Built : 22:17:08, Mar 30 2020
> NOTICE: BL31: Detected Allwinner H5 SoC (1718)
> NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
> NEO Plus2
> INFO: ARM GICv2 driver initialized
> INFO: Configuring SPC Controller
> NOTICE: PMIC: Assuming H5 reference regulator design
> INFO: BL31: Platform setup done
> INFO: BL31: Initializing runtime services
> 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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
> NOTICE: BL31: Built : 22:17:08, Mar 30 2020
> NOTICE: BL31: Detected Allwinner H5 SoC (1718)
> NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
> NEO Plus2
> INFO: ARM GICv2 driver initialized
> INFO: Configuring SPC Controller
> NOTICE: PMIC: Assuming H5 reference regulator design
> INFO: BL31: Platform setup done
> INFO: BL31: Initializing runtime services
> 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-rc3-00115-gecd4d99f65 (Jun 03 2020 - 07:49:54 +0000)
> DRAM: 1024 MiB
> Trying to boot from MMC1
> NOTICE: BL31: v2.2(debug):v2.2-1030-g21e22c74c
> NOTICE: BL31: Built : 22:17:08, Mar 30 2020
> NOTICE: BL31: Detected Allwinner H5 SoC (1718)
> NOTICE: BL31: Found U-Boot DTB at 0x408d820, model: FriendlyARM NanoPi
> NEO Plus2
> INFO: ARM GICv2 driver initialized
> INFO: Configuring SPC Controller
> NOTICE: PMIC: Assuming H5 reference regulator design
> INFO: BL31: Platform setup done
> INFO: BL31: Initializing runtime services
> 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] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-03 16:31 ` André Przywara
@ 2020-06-03 17:07 ` Heinrich Schuchardt
2020-06-06 9:57 ` Heinrich Schuchardt
0 siblings, 1 reply; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-06-03 17:07 UTC (permalink / raw)
To: u-boot
On 6/3/20 6:31 PM, Andr? Przywara wrote:
> On 03/06/2020 16:47, Heinrich Schuchardt wrote:
>
> Hi Heinrich,
>
>> On 03.06.20 01:46, Andr? Przywara wrote:
>>> On 02/06/2020 20:55, Tom Rini wrote:
>>>
>>> Hi,
>>>
>>>> On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
>>>>> On 6/2/20 5:51 PM, Tom Rini wrote:
>>>>>> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>>>>>>
>>>>>>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>>>>>>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>>>>>>
>>>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>> ---
>>>>>>> configs/pine64-lts_defconfig | 3 +++
>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>
>>>>>>> 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
>>>>>>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>>>>>>> CONFIG_SPL=y
>>>>>>> CONFIG_MACH_SUN50I=y
>>>>>>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>>>>>
>>>>>> Look at the option however. This is something that all sunxi should be
>>>>>> selecting.
>>>>>
>>>>> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
>>>>
>>>> config INIT_SP_RELATIVE
>>>> bool "Specify the early stack pointer relative to the .bss section"
>>>> help
>>>> U-Boot typically uses a hard-coded value for the stack pointer
>>>> before relocation. Enable this option to instead calculate the
>>>> initial SP at run-time. This is useful to avoid hard-coding addresses
>>>> into U-Boot, so that it can be loaded and executed at arbitrary
>>>> addresses and thus avoid using arbitrary addresses at runtime.
>>>>
>>>> If this option is enabled, the early stack pointer is set to
>>>> &_bss_start with a offset value added. The offset is specified by
>>>> SYS_INIT_SP_BSS_OFFSET.
>>>>
>>>> And that in turn tells me this is something that's done at the SoC
>>>> level, especially for sunxi where things have been abstracted such that
>>>> everyone (very roughly) shares the same board file, linker file, etc,
>>>> and it's just defconfig+dts* files that change from board to board.
>>>
>>> I agree on that, this particular defconfig change is generic to all
>>> sunxi boards and we should fix this properly for the whole platform.
>>>
>>>> So, to put it another way, what about the pine64-lts config is unique
>>>> and causing this to be needed, but another arm64 sunxi platform would
>>>> not?
>>>
>>> I think were Heinrich came from is selecting CONFIG_RSA for his
>>> particular build. I guess this requires a bigger malloc area. Now this
>>> somehow collides which how we calculate the stack pointer, but it is too
>>> late here to really track this down ;-)
>>>
>>> Heinrich, can you please give an explanation what problem
>>> CONFIG_INIT_SP_RELATIVE fixed and why? It seems like to cause some side
>>> effect, but does not sound like the proper solution (because this is
>>> more mean for the position independent build option).
>>>
>>> Cheers,
>>> Andre
>>>
>>
>> Hello Andr?,
>>
>> the problem is reproducible on the FriendlyARM NanoPi NEO Plus2. So Tom
>> is right in that we should solve it for all Allwinner ARMv8 devices.
>
> Thanks for testing this, and yeah, I am not surprised. As Tom mentioned,
> all (arm64) Allwinner boards are the same in those basic aspects.
>
>> I simply use a nanopi_neo_plus2_defconfig or pine64-lts_defconfig and
>> add CONFIG_RSA=y.
>>
>> The result is that the whenever the BL31 loads main U-Boot the board
>> falls back to SPL. This loops forever. See below.
>>
>> CONFIG_RSA=y is needed for signed UEFI variables and other use cases.
>>
>> But the problem is not specific to RSA. You get into the same kind of
>> problems when selecting CONFIG_LOG=y.
>>
>> With CONFIG_INIT_SP_RELATIVE=y the problem disappears.
>>
>> As this all happens before we have a U-Boot console I was not able to
>> debug further than what I wrote in the thread
>> https://lists.denx.de/pipermail/u-boot/2020-May/414346.html. A
>> DEBUG_UART configuration for sunxi would have been very helpful here.
>
> Many thanks for the info, that looks very helpful! I wasn't sure if the
> problem is in the SPL (because you just increased the malloc area for
> U-Boot proper), but it looks very much like it. I will dig out some
> debug techniques I used in the past to see what's actually going on. The
> code size for Allwinner arm64 SPL is very limited, so we had this issue
> before, where the stack ran into the code (if it didn't already violate
> the build time limit check).
> I am just a bit puzzled how CONFIG_INIT_SP_RELATIVE fixes this, as it
> looks to me that just this option alone is not enough to make this work.
Why do you think there is a problem in SPL?
SPL loads BL31.
BL31 loads BL33 (main U-Boot)
BL33 crashes
the system reboots
Please, read through the mail thread
https://lists.denx.de/pipermail/u-boot/2020-May/414346.html and look at
the reverted patch 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
DM_FLAG_PRE_RELOC").
Best regards
Heinrich
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS
2020-06-03 17:07 ` Heinrich Schuchardt
@ 2020-06-06 9:57 ` Heinrich Schuchardt
0 siblings, 0 replies; 10+ messages in thread
From: Heinrich Schuchardt @ 2020-06-06 9:57 UTC (permalink / raw)
To: u-boot
On 6/3/20 7:07 PM, Heinrich Schuchardt wrote:
> On 6/3/20 6:31 PM, Andr? Przywara wrote:
>> On 03/06/2020 16:47, Heinrich Schuchardt wrote:
>>
>> Hi Heinrich,
>>
>>> On 03.06.20 01:46, Andr? Przywara wrote:
>>>> On 02/06/2020 20:55, Tom Rini wrote:
>>>>
>>>> Hi,
>>>>
>>>>> On Tue, Jun 02, 2020 at 09:45:25PM +0200, Heinrich Schuchardt wrote:
>>>>>> On 6/2/20 5:51 PM, Tom Rini wrote:
>>>>>>> On Sun, May 31, 2020 at 10:43:00AM +0000, Heinrich Schuchardt wrote:
>>>>>>>
>>>>>>>> Booting pine64-lts_defconfig with either of CONFIG_RSA=y or CONFIG_LOG=y
>>>>>>>> fails if CONFIG_INIT_SP_RELATIVE is not set.
>>>>>>>>
>>>>>>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>>> ---
>>>>>>>> configs/pine64-lts_defconfig | 3 +++
>>>>>>>> 1 file changed, 3 insertions(+)
>>>>>>>>
>>>>>>>> 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
>>>>>>>> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x400
>>>>>>>> CONFIG_SPL=y
>>>>>>>> CONFIG_MACH_SUN50I=y
>>>>>>>> CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
>>>>>>>
>>>>>>> Look at the option however. This is something that all sunxi should be
>>>>>>> selecting.
>>>>>>
>>>>>> What indicates that all sunxi should select CONFIG_INIT_SP_RELATIVE?
>>>>>
>>>>> config INIT_SP_RELATIVE
>>>>> bool "Specify the early stack pointer relative to the .bss section"
>>>>> help
>>>>> U-Boot typically uses a hard-coded value for the stack pointer
>>>>> before relocation. Enable this option to instead calculate the
>>>>> initial SP at run-time. This is useful to avoid hard-coding addresses
>>>>> into U-Boot, so that it can be loaded and executed at arbitrary
>>>>> addresses and thus avoid using arbitrary addresses at runtime.
>>>>>
>>>>> If this option is enabled, the early stack pointer is set to
>>>>> &_bss_start with a offset value added. The offset is specified by
>>>>> SYS_INIT_SP_BSS_OFFSET.
>>>>>
>>>>> And that in turn tells me this is something that's done at the SoC
>>>>> level, especially for sunxi where things have been abstracted such that
>>>>> everyone (very roughly) shares the same board file, linker file, etc,
>>>>> and it's just defconfig+dts* files that change from board to board.
>>>>
>>>> I agree on that, this particular defconfig change is generic to all
>>>> sunxi boards and we should fix this properly for the whole platform.
>>>>
>>>>> So, to put it another way, what about the pine64-lts config is unique
>>>>> and causing this to be needed, but another arm64 sunxi platform would
>>>>> not?
>>>>
>>>> I think were Heinrich came from is selecting CONFIG_RSA for his
>>>> particular build. I guess this requires a bigger malloc area. Now this
>>>> somehow collides which how we calculate the stack pointer, but it is too
>>>> late here to really track this down ;-)
>>>>
>>>> Heinrich, can you please give an explanation what problem
>>>> CONFIG_INIT_SP_RELATIVE fixed and why? It seems like to cause some side
>>>> effect, but does not sound like the proper solution (because this is
>>>> more mean for the position independent build option).
>>>>
>>>> Cheers,
>>>> Andre
>>>>
>>>
>>> Hello Andr?,
>>>
>>> the problem is reproducible on the FriendlyARM NanoPi NEO Plus2. So Tom
>>> is right in that we should solve it for all Allwinner ARMv8 devices.
>>
>> Thanks for testing this, and yeah, I am not surprised. As Tom mentioned,
>> all (arm64) Allwinner boards are the same in those basic aspects.
>>
>>> I simply use a nanopi_neo_plus2_defconfig or pine64-lts_defconfig and
>>> add CONFIG_RSA=y.
>>>
>>> The result is that the whenever the BL31 loads main U-Boot the board
>>> falls back to SPL. This loops forever. See below.
>>>
>>> CONFIG_RSA=y is needed for signed UEFI variables and other use cases.
>>>
>>> But the problem is not specific to RSA. You get into the same kind of
>>> problems when selecting CONFIG_LOG=y.
>>>
>>> With CONFIG_INIT_SP_RELATIVE=y the problem disappears.
>>>
>>> As this all happens before we have a U-Boot console I was not able to
>>> debug further than what I wrote in the thread
>>> https://lists.denx.de/pipermail/u-boot/2020-May/414346.html. A
>>> DEBUG_UART configuration for sunxi would have been very helpful here.
>>
>> Many thanks for the info, that looks very helpful! I wasn't sure if the
>> problem is in the SPL (because you just increased the malloc area for
>> U-Boot proper), but it looks very much like it. I will dig out some
>> debug techniques I used in the past to see what's actually going on. The
>> code size for Allwinner arm64 SPL is very limited, so we had this issue
>> before, where the stack ran into the code (if it didn't already violate
>> the build time limit check).
>> I am just a bit puzzled how CONFIG_INIT_SP_RELATIVE fixes this, as it
>> looks to me that just this option alone is not enough to make this work.
>
> Why do you think there is a problem in SPL?
>
> SPL loads BL31.
> BL31 loads BL33 (main U-Boot)
> BL33 crashes
> the system reboots
>
> Please, read through the mail thread
> https://lists.denx.de/pipermail/u-boot/2020-May/414346.html and look at
> the reverted patch 17e117408571 ("drivers: crypto: rsa_mod_exp: avoid
> DM_FLAG_PRE_RELOC").
>
> Best regards
>
> Heinrich
>
With the following settings I was able to enable the DEBUG_UART on the
Pine64 A64 LTS board:
CONFIG_DEBUG_UART=y
CONFIG_DEBUG_UART_NS16550=y
CONFIG_DEBUG_UART_BASE=1c28000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART_SHIFT=2
Now we can see that alloc_simple() reports "alloc space exhausted" after
board_init_f() is called. This indicates that SYS_MALLOC_F_LEN is at the
root of the problem.
This is the output for pine64-lts_defconfig with CONFIG_LOG=y:
U-Boot SPL 2020.07-rc3-00087-g88bd5b1793-dirty (Jun 06 2020 - 08:18:49
+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 0x4092100, 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
Entering board_init_f()
alloc_simple() alloc space exhausted
alloc_simple() alloc space exhausted
alloc_simple() alloc space exhausted
alloc_simple() alloc space exhausted
No serial driver found
resetting ...
alloc_simple() alloc space exhausted
U-Boot SPL 2020.07-rc3-00087-g88bd5b1793-dirty (Jun 06 2020 - 08:18:49
+0000)
DRAM: 2048 MiB
Trying to boot from MMC1
When changing the value of CONFIG_SYS_MALLOC_F_LEN this does not lead to
recompiling common/dlmalloc.c. This is what put me on the wrong track
(with CONFIG_INIT_SP_RELATIVE=y).
Increasing CONFIG_SYS_MALLOC_F_LEN is all that is needed. This change is
sufficient:
diff --git a/Kconfig b/Kconfig
index 0e7ccc0b07..13204e2384 100644
--- a/Kconfig
+++ b/Kconfig
@@ -146,7 +146,7 @@ config SYS_MALLOC_F_LEN
default 0x2000 if (ARCH_IMX8 || ARCH_IMX8M || ARCH_MX7 || \
ARCH_MX7ULP || ARCH_MX6 || ARCH_MX5 || \
ARCH_LS1012A || ARCH_LS1021A || ARCH_LS1043A || \
- ARCH_LS1046A)
+ ARCH_LS1046A || ARCH_SUNXI)
Best regards
Heinrich
^ permalink raw reply related [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-06-06 9:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-05-31 10:43 [PATCH 1/1] sunxi: CONFIG_INIT_SP_RELATIVE=y for Pine64 LTS Heinrich Schuchardt
2020-05-31 15:32 ` Fwd: " Heinrich Schuchardt
2020-06-02 15:51 ` Tom Rini
2020-06-02 19:45 ` Heinrich Schuchardt
2020-06-02 19:55 ` Tom Rini
2020-06-02 23:46 ` André Przywara
2020-06-03 15:47 ` Heinrich Schuchardt
2020-06-03 16:31 ` André Przywara
2020-06-03 17:07 ` Heinrich Schuchardt
2020-06-06 9:57 ` Heinrich Schuchardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox