[U-Boot] SUNXI: A64: Increase SPL size

[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

Hi,

I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
able to fit new features like falcon. I knew the limit about 32K but
page[1] stating that we can use approximately 192 KiB of contiguous
SRAM.

eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
because I've tried with 64K SPL size with existing SPL code and was
able to boot, but with increasing SPL by enabling falcon seems like
BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

diff:
----
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0bd8370..b43c1ff 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -139,7 +139,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
 config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
        hex "Address on the MMC to load U-Boot from"
        depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
-       default 0x50 if ARCH_SUNXI
+       default 0x90 if ARCH_SUNXI
        default 0x75 if ARCH_DAVINCI
        default 0x8a if ARCH_MX6
        default 0x100 if ARCH_ROCKCHIP || ARCH_UNIPHIER
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index bc74dba..805489c 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -99,7 +99,7 @@
  * the 1 actually activates the mapping of the first 32 KiB to 0x00000000.
  */
 #define CONFIG_SYS_INIT_RAM_ADDR       0x10000
-#define CONFIG_SYS_INIT_RAM_SIZE       0x08000 /* FIXME: 40 KiB ? */
+#define CONFIG_SYS_INIT_RAM_SIZE       0x10000 /* FIXME: 40 KiB ? */
 #else
 #define CONFIG_SYS_INIT_RAM_ADDR       0x0
 #define CONFIG_SYS_INIT_RAM_SIZE       0x8000  /* 32 KiB */
@@ -191,7 +191,7 @@

 #ifdef CONFIG_SUNXI_HIGH_SRAM
 #define CONFIG_SPL_TEXT_BASE           0x10060         /* sram start+header */
-#define CONFIG_SPL_MAX_SIZE            0x7fa0          /* 32 KiB */
+#define CONFIG_SPL_MAX_SIZE            0xffa0          /* 192 KiB */
 #ifdef CONFIG_ARM64
 /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
 #define LOW_LEVEL_SRAM_STACK           0x00054000
@@ -206,7 +206,7 @@

 #define CONFIG_SPL_STACK               LOW_LEVEL_SRAM_STACK

-#define CONFIG_SPL_PAD_TO              32768           /* decimal for 'dd' */
+#define CONFIG_SPL_PAD_TO              65536           /* decimal for 'dd' */
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index db0f10e..31df7e2 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p)
 #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
 #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))

-#define SUNXI_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */
+#define SUNXI_SRAM_SIZE 0x10000        /* SoC with smaller size are
limited before */
 #define SRAM_LOAD_MAX_SIZE (SUNXI_SRAM_SIZE - sizeof(struct boot_file_head))

[1] http://linux-sunxi.org/BROM

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] SUNXI: A64: Increase SPL size

[André Przywara]

On 08/11/17 19:59, Jagan Teki wrote:
> Hi,
> 
> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> able to fit new features like falcon. I knew the limit about 32K but
> page[1] stating that we can use approximately 192 KiB of contiguous
> SRAM.

We are not really sure about this. The memory following SRAM A1 is
called SRAM C (not A2, that is secure memory at 0x44000). And this is
actually meant for use by the DisplayEngine, AFAIK. We found it unstable
to use from the ARM cores. With the default config is it not even
covering the whole region as described in the manual.

> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?

Well, how? As far as I know the *BROM* does not load more than 32KB, at
least not with the ("un-encrypted") eGON.BT0 format. Or could you
actually load more code?

I *think* we can load more with the "secure" payload, which requires the
"secure boot" fuse to be burned (with no return), which in turn will let
the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
secure packaged version (TOC0): http://linux-sunxi.org/TOC0

> because I've tried with 64K SPL size with existing SPL code and was
> able to boot, but with increasing SPL by enabling falcon seems like
> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

So why do you need falcon, desperately? You can put the kernel into the
SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
booti (no further loading). That works from SPI flash, also. If you are
really want to, you can disable USB, Ethernet and the timeout and save
some time here. But those are .config options and shouldn't require code
changes.

Cheers,
Andre.

> diff:
> ----
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 0bd8370..b43c1ff 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -139,7 +139,7 @@ config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
>  config SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR
>         hex "Address on the MMC to load U-Boot from"
>         depends on SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
> -       default 0x50 if ARCH_SUNXI
> +       default 0x90 if ARCH_SUNXI
>         default 0x75 if ARCH_DAVINCI
>         default 0x8a if ARCH_MX6
>         default 0x100 if ARCH_ROCKCHIP || ARCH_UNIPHIER
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index bc74dba..805489c 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -99,7 +99,7 @@
>   * the 1 actually activates the mapping of the first 32 KiB to 0x00000000.
>   */
>  #define CONFIG_SYS_INIT_RAM_ADDR       0x10000
> -#define CONFIG_SYS_INIT_RAM_SIZE       0x08000 /* FIXME: 40 KiB ? */
> +#define CONFIG_SYS_INIT_RAM_SIZE       0x10000 /* FIXME: 40 KiB ? */
>  #else
>  #define CONFIG_SYS_INIT_RAM_ADDR       0x0
>  #define CONFIG_SYS_INIT_RAM_SIZE       0x8000  /* 32 KiB */
> @@ -191,7 +191,7 @@
> 
>  #ifdef CONFIG_SUNXI_HIGH_SRAM
>  #define CONFIG_SPL_TEXT_BASE           0x10060         /* sram start+header */
> -#define CONFIG_SPL_MAX_SIZE            0x7fa0          /* 32 KiB */
> +#define CONFIG_SPL_MAX_SIZE            0xffa0          /* 192 KiB */
>  #ifdef CONFIG_ARM64
>  /* end of SRAM A2 for now, as SRAM A1 is pretty tight for an ARM64 build */
>  #define LOW_LEVEL_SRAM_STACK           0x00054000
> @@ -206,7 +206,7 @@
> 
>  #define CONFIG_SPL_STACK               LOW_LEVEL_SRAM_STACK
> 
> -#define CONFIG_SPL_PAD_TO              32768           /* decimal for 'dd' */
> +#define CONFIG_SPL_PAD_TO              65536           /* decimal for 'dd' */
> diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
> index db0f10e..31df7e2 100644
> --- a/tools/mksunxiboot.c
> +++ b/tools/mksunxiboot.c
> @@ -48,7 +48,7 @@ int gen_check_sum(struct boot_file_head *head_p)
>  #define ALIGN(x, a) __ALIGN_MASK((x), (typeof(x))(a)-1)
>  #define __ALIGN_MASK(x, mask) (((x)+(mask))&~(mask))
> 
> -#define SUNXI_SRAM_SIZE 0x8000 /* SoC with smaller size are limited before */
> +#define SUNXI_SRAM_SIZE 0x10000        /* SoC with smaller size are
> limited before */
>  #define SRAM_LOAD_MAX_SIZE (SUNXI_SRAM_SIZE - sizeof(struct boot_file_head))
> 
> [1] http://linux-sunxi.org/BROM
> 
> thanks!
> 

[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

Hi Andre,

On Thu, Nov 9, 2017 at 3:36 AM, André Przywara <andre.przywara@arm.com> wrote:
> On 08/11/17 19:59, Jagan Teki wrote:
>> Hi,
>>
>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>> able to fit new features like falcon. I knew the limit about 32K but
>> page[1] stating that we can use approximately 192 KiB of contiguous
>> SRAM.
>
> We are not really sure about this. The memory following SRAM A1 is
> called SRAM C (not A2, that is secure memory at 0x44000). And this is
> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
> to use from the ARM cores. With the default config is it not even
> covering the whole region as described in the manual.

>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>
> Well, how? As far as I know the *BROM* does not load more than 32KB, at
> least not with the ("un-encrypted") eGON.BT0 format. Or could you
> actually load more code?

Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
A1 and I had an impression of using SRAM C for > 32KB. So BROM only
have an access to A1 (not any other SRAM's like SRAM C) we can't
increase the SPL size > 32KB..this is strict. correct?

>
> I *think* we can load more with the "secure" payload, which requires the
> "secure boot" fuse to be burned (with no return), which in turn will let
> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
> secure packaged version (TOC0): http://linux-sunxi.org/TOC0

Did you try this? if yes please point the same.

>
>> because I've tried with 64K SPL size with existing SPL code and was
>> able to boot, but with increasing SPL by enabling falcon seems like
>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>
> So why do you need falcon, desperately? You can put the kernel into the
> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
> booti (no further loading). That works from SPI flash, also. If you are
> really want to, you can disable USB, Ethernet and the timeout and save
> some time here. But those are .config options and shouldn't require code
> changes.

Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
ATF). I'm not using USB, ethernet on SPL so current code look fit with
what SPL wants.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 11:38, Jagan Teki wrote:
> Hi Andre,
> 
> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara <andre.przywara@arm.com> wrote:
>> On 08/11/17 19:59, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>
>> We are not really sure about this. The memory following SRAM A1 is
>> called SRAM C (not A2, that is secure memory at 0x44000). And this is
>> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
>> to use from the ARM cores. With the default config is it not even
>> covering the whole region as described in the manual.
> 
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>
>> Well, how? As far as I know the *BROM* does not load more than 32KB, at
>> least not with the ("un-encrypted") eGON.BT0 format. Or could you
>> actually load more code?
> 
> Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
> A1 and I had an impression of using SRAM C for > 32KB. So BROM only
> have an access to A1 (not any other SRAM's like SRAM C) we can't
> increase the SPL size > 32KB..this is strict. correct?

It's not so much about BROM not having access to SRAM C, it's just not
doing it. That's a design decision made by Allwinner, and since it's
ROM, we can't do anything about it.

>>
>> I *think* we can load more with the "secure" payload, which requires the
>> "secure boot" fuse to be burned (with no return), which in turn will let
>> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
>> secure packaged version (TOC0): http://linux-sunxi.org/TOC0
> 
> Did you try this? if yes please point the same.

I tried TOC0 on a Pine64 where I burnt the fuse. But I didn't try to
load more than 32KB. Anyway I don't believe it's an option for you,
since it's an revocable change to the SoC (it's a one-time fuse).
I guess you don't want to force that on your customer's boards.

>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> So why do you need falcon, desperately? You can put the kernel into the
>> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
>> booti (no further loading). That works from SPI flash, also. If you are
>> really want to, you can disable USB, Ethernet and the timeout and save
>> some time here. But those are .config options and shouldn't require code
>> changes.
> 
> Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
> ATF). I'm not using USB, ethernet on SPL so current code look fit with
> what SPL wants.

I understand that, my question was: What does Falcon give you to justify
all the hacking and the pain you go through? Why can't you just go the
normal way and trim U-Boot proper to not waste time?

Cheers,
Andre.

[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:23 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 09/11/17 11:38, Jagan Teki wrote:
>> Hi Andre,
>>
>> On Thu, Nov 9, 2017 at 3:36 AM, André Przywara <andre.przywara@arm.com> wrote:
>>> On 08/11/17 19:59, Jagan Teki wrote:
>>>> Hi,
>>>>
>>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>>> able to fit new features like falcon. I knew the limit about 32K but
>>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>>> SRAM.
>>>
>>> We are not really sure about this. The memory following SRAM A1 is
>>> called SRAM C (not A2, that is secure memory at 0x44000). And this is
>>> actually meant for use by the DisplayEngine, AFAIK. We found it unstable
>>> to use from the ARM cores. With the default config is it not even
>>> covering the whole region as described in the manual.
>>
>>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>>
>>> Well, how? As far as I know the *BROM* does not load more than 32KB, at
>>> least not with the ("un-encrypted") eGON.BT0 format. Or could you
>>> actually load more code?
>>
>> Yes, I've 40K SPL start from sector 16 of SD Since BROM load 32KB to
>> A1 and I had an impression of using SRAM C for > 32KB. So BROM only
>> have an access to A1 (not any other SRAM's like SRAM C) we can't
>> increase the SPL size > 32KB..this is strict. correct?
>
> It's not so much about BROM not having access to SRAM C, it's just not
> doing it. That's a design decision made by Allwinner, and since it's
> ROM, we can't do anything about it.
>
>>>
>>> I *think* we can load more with the "secure" payload, which requires the
>>> "secure boot" fuse to be burned (with no return), which in turn will let
>>> the BROM refuse to load a standard eGON.BT0 Boot0/SPL, but only the
>>> secure packaged version (TOC0): http://linux-sunxi.org/TOC0
>>
>> Did you try this? if yes please point the same.
>
> I tried TOC0 on a Pine64 where I burnt the fuse. But I didn't try to
> load more than 32KB. Anyway I don't believe it's an option for you,
> since it's an revocable change to the SoC (it's a one-time fuse).
> I guess you don't want to force that on your customer's boards.

I've few dev boards, may be I can try > 32KB can you point me the link
or source about this?

>>>> because I've tried with 64K SPL size with existing SPL code and was
>>>> able to boot, but with increasing SPL by enabling falcon seems like
>>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> So why do you need falcon, desperately? You can put the kernel into the
>>> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
>>> booti (no further loading). That works from SPI flash, also. If you are
>>> really want to, you can disable USB, Ethernet and the timeout and save
>>> some time here. But those are .config options and shouldn't require code
>>> changes.
>>
>> Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
>> ATF). I'm not using USB, ethernet on SPL so current code look fit with
>> what SPL wants.
>
> I understand that, my question was: What does Falcon give you to justify
> all the hacking and the pain you go through? Why can't you just go the
> normal way and trim U-Boot proper to not waste time?

Yes, we can trim the U-Boot proper but my idea is to skip it so-that
we can achieve better boot-time. I've seen better boot-time numbers
with other SOC.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 11:53:48AM +0000, Andre Przywara wrote:
> >>> because I've tried with 64K SPL size with existing SPL code and was
> >>> able to boot, but with increasing SPL by enabling falcon seems like
> >>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> >>
> >> So why do you need falcon, desperately? You can put the kernel into the
> >> SPL FIT image (u-boot.itb), then have the U-Boot proper just execute
> >> booti (no further loading). That works from SPI flash, also. If you are
> >> really want to, you can disable USB, Ethernet and the timeout and save
> >> some time here. But those are .config options and shouldn't require code
> >> changes.
> > 
> > Falcon make direct Linux boot, from SPL. we can skip U-Boot, (even
> > ATF). I'm not using USB, ethernet on SPL so current code look fit with
> > what SPL wants.
> 
> I understand that, my question was: What does Falcon give you to justify
> all the hacking and the pain you go through? Why can't you just go the
> normal way and trim U-Boot proper to not waste time?

Even a trimmed U-Boot will take easily around 500ms. If your plan is
to boot in less that one or two seconds, it's already a significant
part of your boot time that you are wasting without any particular
reason.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171109/f2ffcd1a/attachment.sig>

[U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
> Hi,
> 
> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> able to fit new features like falcon. I knew the limit about 32K but
> page[1] stating that we can use approximately 192 KiB of contiguous
> SRAM.
> 
> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
> because I've tried with 64K SPL size with existing SPL code and was
> able to boot, but with increasing SPL by enabling falcon seems like
> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?

I've been able to use the falcon mode without this change on an A33,
what's so different about the A64?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171109/d7f37758/attachment.sig>

[U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 12:11, Maxime Ripard wrote:
> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>> Hi,
>>
>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>> able to fit new features like falcon. I knew the limit about 32K but
>> page[1] stating that we can use approximately 192 KiB of contiguous
>> SRAM.
>>
>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>> because I've tried with 64K SPL size with existing SPL code and was
>> able to boot, but with increasing SPL by enabling falcon seems like
>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> 
> I've been able to use the falcon mode without this change on an A33,
> what's so different about the A64?

That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
exceed 32KB (we are quite close already)

Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
which is smaller than the AArch64 version.
You might be able to include Falcon there, but I am afraid you have to
work out how to boot a 64-bit kernel from there and how to enable SMP.

Hence my question about the pain you want to endure and if those 500ms
are really worth it.

Cheers,
Andre

[1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip

[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 09/11/17 12:11, Maxime Ripard wrote:
>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>>
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> I've been able to use the falcon mode without this change on an A33,
>> what's so different about the A64?
>
> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> exceed 32KB (we are quite close already)

Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.
of-course Linux failed to boot. Maxime did you find similar behaviour?
is falcon worked on A33?

>
> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
> which is smaller than the AArch64 version.
> You might be able to include Falcon there, but I am afraid you have to
> work out how to boot a 64-bit kernel from there and how to enable SMP.

Thanks, let me try this.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 12:41, Jagan Teki wrote:
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 09/11/17 12:11, Maxime Ripard wrote:
>>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>>> Hi,
>>>>
>>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>>> able to fit new features like falcon. I knew the limit about 32K but
>>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>>> SRAM.
>>>>
>>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>>> because I've tried with 64K SPL size with existing SPL code and was
>>>> able to boot, but with increasing SPL by enabling falcon seems like
>>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> I've been able to use the falcon mode without this change on an A33,
>>> what's so different about the A64?
>>
>> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
>> exceed 32KB (we are quite close already)
> 
> Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
> H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.

That's due to padding when creating the eGON wrapped file. It's rounded
up to multiple of 8KB.
Use "size" on spl/u-boot-spl, that gives you the real information:
$ aarch64-linux-size spl/u-boot-spl
   text    data     bss     dec     hex filename
  31231     376     440   32047    7d2f spl/u-boot-spl

Cheers,
Andre.

> of-course Linux failed to boot. Maxime did you find similar behaviour?
> is falcon worked on A33?
> 
>>
>> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
>> which is smaller than the AArch64 version.
>> You might be able to include Falcon there, but I am afraid you have to
>> work out how to boot a 64-bit kernel from there and how to enable SMP.
> 
> Thanks, let me try this.
> 
> thanks!
> 

[U-Boot] SUNXI: A64: Increase SPL size

[Maxime Ripard]

On Thu, Nov 09, 2017 at 06:11:58PM +0530, Jagan Teki wrote:
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> > Hi,
> >
> > On 09/11/17 12:11, Maxime Ripard wrote:
> >> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
> >>> Hi,
> >>>
> >>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
> >>> able to fit new features like falcon. I knew the limit about 32K but
> >>> page[1] stating that we can use approximately 192 KiB of contiguous
> >>> SRAM.
> >>>
> >>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
> >>> because I've tried with 64K SPL size with existing SPL code and was
> >>> able to boot, but with increasing SPL by enabling falcon seems like
> >>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
> >>
> >> I've been able to use the falcon mode without this change on an A33,
> >> what's so different about the A64?
> >
> > That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> > exceed 32KB (we are quite close already)
> 
> Yes, but with arm32 I didn't see increasing size with SPL_OS_BOOT on
> H3 spl/sunxi-spl.bin size become 24576(24KB) even with falcon-enabled.
> of-course Linux failed to boot. Maxime did you find similar behaviour?
> is falcon worked on A33?

I didn't look at that back then because I wasn't aware that was an
issue, but it worked flawlessly for me, so I'm guessing it didn't add
that much.

But then, like Andre was suggesting, I wasn't using the PSCI stuff
either, which we would also need to compile.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20171109/f3624892/attachment.sig>

[U-Boot] SUNXI: A64: Increase SPL size

[Jagan Teki]

Hi Andre,

On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara <andre.przywara@arm.com> wrote:
> Hi,
>
> On 09/11/17 12:11, Maxime Ripard wrote:
>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>> Hi,
>>>
>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>> able to fit new features like falcon. I knew the limit about 32K but
>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>> SRAM.
>>>
>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>> because I've tried with 64K SPL size with existing SPL code and was
>>> able to boot, but with increasing SPL by enabling falcon seems like
>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>
>> I've been able to use the falcon mode without this change on an A33,
>> what's so different about the A64?
>
> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
> exceed 32KB (we are quite close already)
>
> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
> which is smaller than the AArch64 version.
> You might be able to include Falcon there, but I am afraid you have to
> work out how to boot a 64-bit kernel from there and how to enable SMP.
>
> Hence my question about the pain you want to endure and if those 500ms
> are really worth it.
>
> Cheers,
> Andre
>
> [1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip

Looking at the "32-bit SPL" patch [2], commit message "so a 32-bit SPL
can be combined with a 64-bit U-Boot" Does this means we need to build
U-Boot proper for 64-bit compiler with pine64_plus_defconfig and SPL
for 32-bit compiler with sun50i_spl32_defconfig? because I've tried of
sun50i_spl32 with 32-bit compiler ended with build issue.

Build log:
----------
  MKIMAGE u-boot.img
  BINMAN  u-boot-sunxi-with-spl.bin
binman: Device tree 'u-boot.dtb' does not have a 'binman' node
Makefile:1157: recipe for target 'u-boot-sunxi-with-spl.bin' failed
make: *** [u-boot-sunxi-with-spl.bin] Error 1

Look like it is not taking CONFIG_SPL_FIT_GENERATOR script.

[2] https://github.com/apritzel/u-boot/commit/5f1fe133aabfd0c3c5867c453cb405d9624e52ce

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.

[U-Boot] SUNXI: A64: Increase SPL size

[Andre Przywara]

Hi,

On 09/11/17 15:23, Jagan Teki wrote:
> Hi Andre,
> 
> On Thu, Nov 9, 2017 at 5:48 PM, Andre Przywara <andre.przywara@arm.com> wrote:
>> Hi,
>>
>> On 09/11/17 12:11, Maxime Ripard wrote:
>>> On Thu, Nov 09, 2017 at 01:29:21AM +0530, Jagan Teki wrote:
>>>> Hi,
>>>>
>>>> I'm trying to increase SPL size to 64K(with SRAM A2), so-that SPL can
>>>> able to fit new features like falcon. I knew the limit about 32K but
>>>> page[1] stating that we can use approximately 192 KiB of contiguous
>>>> SRAM.
>>>>
>>>> eGON.BT0 has limit of reading 32KB, Can't we use > 32KB SPL here?
>>>> because I've tried with 64K SPL size with existing SPL code and was
>>>> able to boot, but with increasing SPL by enabling falcon seems like
>>>> BROM unable read eGON.BT0 which eventually booting failed. Any inputs?
>>>
>>> I've been able to use the falcon mode without this change on an A33,
>>> what's so different about the A64?
>>
>> That the SPL is bigger in AArch64 and enabling SPL_OS_BOOT will probably
>> exceed 32KB (we are quite close already)
>>
>> Jagan: you could try this branch of mine [1], this enables a 32-bit SPL,
>> which is smaller than the AArch64 version.
>> You might be able to include Falcon there, but I am afraid you have to
>> work out how to boot a 64-bit kernel from there and how to enable SMP.
>>
>> Hence my question about the pain you want to endure and if those 500ms
>> are really worth it.
>>
>> Cheers,
>> Andre
>>
>> [1] https://github.com/apritzel/u-boot/commits/a64-fel32-wip
> 
> Looking at the "32-bit SPL" patch [2], commit message "so a 32-bit SPL
> can be combined with a 64-bit U-Boot" Does this means we need to build
> U-Boot proper for 64-bit compiler with pine64_plus_defconfig and SPL
> for 32-bit compiler with sun50i_spl32_defconfig?

Well, yes. One thing is the issue you mention below, which should be
easy to fix (was just too lazy to look at it).
But more importantly a 32-bit U-Boot proper only allows you to boot
32-bit kernels, which is interesting, but not my goal.
Also AFAIK you can't build a 32-bit mainline kernel for an A64 out of
the box.

I just build the SPL from this tree and use it for FEL booting.
Another use case is your's, when you want more features and this exceeds
the maximum SPL size on AArch64.

Those patches were part of my original A64 SPL series, so I also keep
them around just in case.

So: Yes, I build this tree with an ARM cross-compiler, copy
spl/sunxi-spl.bin somewhere, then build again (after make clean) with an
Aarch64 cross compiler and combine the pieces manually, for instance:

$ sunxi-fel -v -p spl /tmp/sunxi-spl32.bin write 0x44000 bl31.bin write
0x4a000000 u-boot.bin reset64 0x44000

or:

$ cat /tmp/sunxi-spl32.bin u-boot.itb > u-boot-sunxi-with-spl.bin

(which would be your use case).

This nastiness is one of the reasons I haven't tried to upstream this yet.

Cheers,
Andre.

> because I've tried of
> sun50i_spl32 with 32-bit compiler ended with build issue.
> 
> Build log:
> ----------
>   MKIMAGE u-boot.img
>   BINMAN  u-boot-sunxi-with-spl.bin
> binman: Device tree 'u-boot.dtb' does not have a 'binman' node
> Makefile:1157: recipe for target 'u-boot-sunxi-with-spl.bin' failed
> make: *** [u-boot-sunxi-with-spl.bin] Error 1
> 
> Look like it is not taking CONFIG_SPL_FIT_GENERATOR script.
> 
> [2] https://github.com/apritzel/u-boot/commit/5f1fe133aabfd0c3c5867c453cb405d9624e52ce
> 
> thanks!
>