Re: [linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Korsgaard]

> "Tom" == Tom Rini  writes:

Hi,

 >> That seems like a good idea to me.

 > I've lamented before (and I think others have too) that it's really a
 > shame that gcc treats arm32 and arm64 as totally distinct builds (and
 > where clang is a win).  But I don't think we can require people to have
 > both an arm and an aarch64 compiler available in order to build U-Boot
 > for some aarch64.

No, please not. It would make it very hard to handle U-Boot builds in
Buildroot for these boards.

-- 
Bye, Peter Korsgaard

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Tom Rini]

On Wed, Apr 04, 2018 at 01:53:17AM +0800, Simon Glass wrote:
> Hi Andre,
> 
> On 2 April 2018 at 19:00, André Przywara  wrote:
> > Hi,
> >
> > On 02/04/18 03:30, Simon Glass wrote:
> >>
> >> Hi Andre,
> >>
> >> On 2 April 2018 at 09:43, André Przywara  wrote:
> >>> Hi,
> >>>
> >>> On 01/04/18 14:19, Tom Rini wrote:
>  On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
> > On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> >> Hi Tom,
> >>
> >> On 7 August 2017 at 09:39, Tom Rini  wrote:
> >>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
> >>>
>  The CONFIG_BLK conversion involves quite invasive changes in the 
>  U-Boot
>  code, with #ifdefs and different code paths. We should try to move 
>  over to
>  this soon so we can drop the old code.
> >
> > I hope this will applicable to SPL too?
> >
> > If so, we are having SPL size issues with few Allwinner families, if
> > enable SPL_DM any suggestions?
> 
>  How close, and have you looked at the u-boot-spl.map to see what you can
>  maybe trim?  Or areas to look at reducing in code complexity?
> >>>
> >>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> >>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> >>> and picked most low hanging fruits already.
> >>> So far we discussed several mitigations, but mostly to cover the
> >>> "natural" SPL code size grow over time:
> >>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> >>> padding (for a 2KB architectural alignment). Given that the vectors are
> >>> used only for debugging purposes, we could scrap them entirely or
> >>> construct them on the fly in some other SRAM. So would free about 2.5KB,
> >>> ideally. Lowest hanging fruit so far.
> >>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> >>> encoding. This reduces the size significantly, to about 20KB. The
> >>> disadvantage is using a second cross-compiler or even a additional
> >>> cross-compiler for native builds, complicating the build process.
> >>> I maintain a branch for enabling FEL booting here [1], which provides
> >>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> >>> There are no technical disadvantages in running the SPL in 32-bit, so
> >>> this is mostly a build issue.
> >>
> >> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> >> ARMv7. It should be fairly easy to do,
> >
> > Yes, but this is merely different compiler *flags*, to the same (cross)
> > compiler binary. ARM32 and ARM64 are different architectures to GCC, so
> > require different compiler binaries with different prefixes.
> > Last time I checked this wasn't easy to integrate into the U-Boot build
> > system.
> > One hack could be a "switching script", which filters for, say -m32",
> > and calls the respective binary. But still we need to somehow set *two*
> > CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
> > But still it would require to install *two* cross compilers, and would
> > spoil a completely native build by still requiring a cross compiler.
> 
> That seems like a good idea to me.

I've lamented before (and I think others have too) that it's really a
shame that gcc treats arm32 and arm64 as totally distinct builds (and
where clang is a win).  But I don't think we can require people to have
both an arm and an aarch64 compiler available in order to build U-Boot
for some aarch64.

> 
> >
> >>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> >>> size and sizeof(long) to be 32-bit and should help, though I haven't
> >>> been able to successfully compile it yet (relocation types problems).
> >>> Despite lacking mainline support for AArch64 ILP32 in Linux and
> >>> glibc(?), GCC supports it for quite a while already. Unknown saving 
> >>> effect.
> >>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> >>> the 32KB, so we could leverage this. Siarhei knows more about this.
> >>> 5) Use a TPL. Haven't looked at this in detail yet.

Here, my preference would be to again look at (4) then (3).  I think a
(5) TPL here would be enough of a something to get DDR available so that
SPL can run there and not be subject to the tiny limits.  But I have no
idea how feasible that is here.

-- 
Tom

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Simon Glass]

Hi Andre,

On 2 April 2018 at 19:00, André Przywara  wrote:
> Hi,
>
> On 02/04/18 03:30, Simon Glass wrote:
>>
>> Hi Andre,
>>
>> On 2 April 2018 at 09:43, André Przywara  wrote:
>>> Hi,
>>>
>>> On 01/04/18 14:19, Tom Rini wrote:
 On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
>> Hi Tom,
>>
>> On 7 August 2017 at 09:39, Tom Rini  wrote:
>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>>
 The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
 code, with #ifdefs and different code paths. We should try to move 
 over to
 this soon so we can drop the old code.
>
> I hope this will applicable to SPL too?
>
> If so, we are having SPL size issues with few Allwinner families, if
> enable SPL_DM any suggestions?

 How close, and have you looked at the u-boot-spl.map to see what you can
 maybe trim?  Or areas to look at reducing in code complexity?
>>>
>>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>>> and picked most low hanging fruits already.
>>> So far we discussed several mitigations, but mostly to cover the
>>> "natural" SPL code size grow over time:
>>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>>> padding (for a 2KB architectural alignment). Given that the vectors are
>>> used only for debugging purposes, we could scrap them entirely or
>>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>>> ideally. Lowest hanging fruit so far.
>>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>>> encoding. This reduces the size significantly, to about 20KB. The
>>> disadvantage is using a second cross-compiler or even a additional
>>> cross-compiler for native builds, complicating the build process.
>>> I maintain a branch for enabling FEL booting here [1], which provides
>>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>>> There are no technical disadvantages in running the SPL in 32-bit, so
>>> this is mostly a build issue.
>>
>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
>> ARMv7. It should be fairly easy to do,
>
> Yes, but this is merely different compiler *flags*, to the same (cross)
> compiler binary. ARM32 and ARM64 are different architectures to GCC, so
> require different compiler binaries with different prefixes.
> Last time I checked this wasn't easy to integrate into the U-Boot build
> system.
> One hack could be a "switching script", which filters for, say -m32",
> and calls the respective binary. But still we need to somehow set *two*
> CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
> But still it would require to install *two* cross compilers, and would
> spoil a completely native build by still requiring a cross compiler.

That seems like a good idea to me.

>
>>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
>>> size and sizeof(long) to be 32-bit and should help, though I haven't
>>> been able to successfully compile it yet (relocation types problems).
>>> Despite lacking mainline support for AArch64 ILP32 in Linux and
>>> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
>>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
>>> the 32KB, so we could leverage this. Siarhei knows more about this.
>>> 5) Use a TPL. Haven't looked at this in detail yet.
>>>
>>> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
>>> the >10 KB toll the DM_SPL support actually takes.
>>
>> Is this the cost on 64-bit?
>
> Yes, this is AArch64, just enabling DM_SPL_MMC and DM_SPL.

OK I see, and presumably OF_CONTROL as well?

>
>> I wonder if CONFIG_OF_PLATDATA might be an option?
>
> Well, this would be a requirement, I guess, since adding any kind of DT
> to the mix makes it even worse.

Well it still uses DT as the source for the config. It's just that it
compiles it to C so we don't have to build in libfdt. It does have
some painful side effects though - e.g. you need to adjust drivers to
read the new C structure.

>
> Cheers,
> Andre
>

Regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[André Przywara]

Hi,

On 02/04/18 03:30, Simon Glass wrote:
> 
> Hi Andre,
> 
> On 2 April 2018 at 09:43, André Przywara  wrote:
>> Hi,
>>
>> On 01/04/18 14:19, Tom Rini wrote:
>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
 On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> Hi Tom,
>
> On 7 August 2017 at 09:39, Tom Rini  wrote:
>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>
>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>>> code, with #ifdefs and different code paths. We should try to move over 
>>> to
>>> this soon so we can drop the old code.

 I hope this will applicable to SPL too?

 If so, we are having SPL size issues with few Allwinner families, if
 enable SPL_DM any suggestions?
>>>
>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>> maybe trim?  Or areas to look at reducing in code complexity?
>>
>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>> and picked most low hanging fruits already.
>> So far we discussed several mitigations, but mostly to cover the
>> "natural" SPL code size grow over time:
>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>> padding (for a 2KB architectural alignment). Given that the vectors are
>> used only for debugging purposes, we could scrap them entirely or
>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>> ideally. Lowest hanging fruit so far.
>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>> encoding. This reduces the size significantly, to about 20KB. The
>> disadvantage is using a second cross-compiler or even a additional
>> cross-compiler for native builds, complicating the build process.
>> I maintain a branch for enabling FEL booting here [1], which provides
>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>> There are no technical disadvantages in running the SPL in 32-bit, so
>> this is mostly a build issue.
> 
> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> ARMv7. It should be fairly easy to do,

Yes, but this is merely different compiler *flags*, to the same (cross)
compiler binary. ARM32 and ARM64 are different architectures to GCC, so
require different compiler binaries with different prefixes.
Last time I checked this wasn't easy to integrate into the U-Boot build
system.
One hack could be a "switching script", which filters for, say -m32",
and calls the respective binary. But still we need to somehow set *two*
CROSS_COMPILE prefixes. CROSS_COMPILE_SPL, maybe?
But still it would require to install *two* cross compilers, and would
spoil a completely native build by still requiring a cross compiler.

>> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
>> size and sizeof(long) to be 32-bit and should help, though I haven't
>> been able to successfully compile it yet (relocation types problems).
>> Despite lacking mainline support for AArch64 ILP32 in Linux and
>> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
>> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
>> the 32KB, so we could leverage this. Siarhei knows more about this.
>> 5) Use a TPL. Haven't looked at this in detail yet.
>>
>> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
>> the >10 KB toll the DM_SPL support actually takes.
> 
> Is this the cost on 64-bit?

Yes, this is AArch64, just enabling DM_SPL_MMC and DM_SPL.

> I wonder if CONFIG_OF_PLATDATA might be an option?

Well, this would be a requirement, I guess, since adding any kind of DT
to the mix makes it even worse.

Cheers,
Andre

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Jagan Teki]

On Mon, Apr 2, 2018 at 7:13 AM, André Przywara  wrote:
> Hi,
>
> On 01/04/18 14:19, Tom Rini wrote:
>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
 Hi Tom,

 On 7 August 2017 at 09:39, Tom Rini  wrote:
> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>
>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>> code, with #ifdefs and different code paths. We should try to move over 
>> to
>> this soon so we can drop the old code.
>>>
>>> I hope this will applicable to SPL too?
>>>
>>> If so, we are having SPL size issues with few Allwinner families, if
>>> enable SPL_DM any suggestions?
>>
>> How close, and have you looked at the u-boot-spl.map to see what you can
>> maybe trim?  Or areas to look at reducing in code complexity?
>
> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> and picked most low hanging fruits already.
> So far we discussed several mitigations, but mostly to cover the
> "natural" SPL code size grow over time:
> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> padding (for a 2KB architectural alignment). Given that the vectors are
> used only for debugging purposes, we could scrap them entirely or
> construct them on the fly in some other SRAM. So would free about 2.5KB,
> ideally. Lowest hanging fruit so far.
> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> encoding. This reduces the size significantly, to about 20KB. The
> disadvantage is using a second cross-compiler or even a additional
> cross-compiler for native builds, complicating the build process.
> I maintain a branch for enabling FEL booting here [1], which provides
> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> There are no technical disadvantages in running the SPL in 32-bit, so
> this is mostly a build issue.

May be this can be a good option and it has verified with board. As
Simon pointed tegra for this matter about building two arch's I think
we can try this out. I made some know change in arm/Makefile but
unable to export armv7 and armv8 compilers so-that build can pick
based on SPL and U-Boot?

--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -24,6 +24,8 @@ arch-$(CONFIG_ARM64)  =-march=armv8-a
 # but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
 ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy)
 arch-y += -D__LINUX_ARM_ARCH__=4
+else ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_MACH_SUN50I),yy)
+arch-y += -D__LINUX_ARM_ARCH__=7
 else
 arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
 endif

> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> size and sizeof(long) to be 32-bit and should help, though I haven't
> been able to successfully compile it yet (relocation types problems).
> Despite lacking mainline support for AArch64 ILP32 in Linux and
> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> the 32KB, so we could leverage this. Siarhei knows more about this.
> 5) Use a TPL. Haven't looked at this in detail yet.

I think it's difficult to implement TPL here because, we should
require same SPL code for TPL like cpu, clock, DRAM and MMC(for boot
mode) butif we have a way to return from BootROM once TPL loaded(like
rockchip does) so-that we can skip MMC code from TPL.

Jagan.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Simon Glass]

Hi,

On 2 April 2018 at 11:07, Peter Robinson  wrote:
> On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass  wrote:
>> Hi Peter,
>>
>> On 2 April 2018 at 10:45, Peter Robinson  wrote:
>>> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass  wrote:
 Hi Andre,

 On 2 April 2018 at 09:43, André Przywara  wrote:
> Hi,
>
> On 01/04/18 14:19, Tom Rini wrote:
>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
 Hi Tom,

 On 7 August 2017 at 09:39, Tom Rini  wrote:
> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>
>> The CONFIG_BLK conversion involves quite invasive changes in the 
>> U-Boot
>> code, with #ifdefs and different code paths. We should try to move 
>> over to
>> this soon so we can drop the old code.
>>>
>>> I hope this will applicable to SPL too?
>>>
>>> If so, we are having SPL size issues with few Allwinner families, if
>>> enable SPL_DM any suggestions?
>>
>> How close, and have you looked at the u-boot-spl.map to see what you can
>> maybe trim?  Or areas to look at reducing in code complexity?
>
> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> and picked most low hanging fruits already.
> So far we discussed several mitigations, but mostly to cover the
> "natural" SPL code size grow over time:
> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> padding (for a 2KB architectural alignment). Given that the vectors are
> used only for debugging purposes, we could scrap them entirely or
> construct them on the fly in some other SRAM. So would free about 2.5KB,
> ideally. Lowest hanging fruit so far.
> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> encoding. This reduces the size significantly, to about 20KB. The
> disadvantage is using a second cross-compiler or even a additional
> cross-compiler for native builds, complicating the build process.
> I maintain a branch for enabling FEL booting here [1], which provides
> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> There are no technical disadvantages in running the SPL in 32-bit, so
> this is mostly a build issue.

 FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
 ARMv7. It should be fairly easy to do,
>>>
>>> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
>>> the case of Allwinner A64
>>
>> Yes, but that is just a matter of compiler or compiler flags. My point
>> was we should be able to use different build for each without too much
>> work.
>
> It's a lot more work for the way most distros build u-boot, but TBH
> the sooner I don't need to the better ;-)

I don't understand the last part of that sentence. But getting back to
the original question, DM does add size, DT adds more. There is
CONFIG_OF_PLATDATA which essentially removes the DT cost, but DM
remains (perhaps 5KB at a guess on 64-bit). So we will have pressure
to avoid using DM in SPL for some time to come, I think.

Regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Robinson]

On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass  wrote:
> Hi Peter,
>
> On 2 April 2018 at 10:45, Peter Robinson  wrote:
>> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass  wrote:
>>> Hi Andre,
>>>
>>> On 2 April 2018 at 09:43, André Przywara  wrote:
 Hi,

 On 01/04/18 14:19, Tom Rini wrote:
> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
>>> Hi Tom,
>>>
>>> On 7 August 2017 at 09:39, Tom Rini  wrote:
 On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:

> The CONFIG_BLK conversion involves quite invasive changes in the 
> U-Boot
> code, with #ifdefs and different code paths. We should try to move 
> over to
> this soon so we can drop the old code.
>>
>> I hope this will applicable to SPL too?
>>
>> If so, we are having SPL size issues with few Allwinner families, if
>> enable SPL_DM any suggestions?
>
> How close, and have you looked at the u-boot-spl.map to see what you can
> maybe trim?  Or areas to look at reducing in code complexity?

 The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
 SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
 and picked most low hanging fruits already.
 So far we discussed several mitigations, but mostly to cover the
 "natural" SPL code size grow over time:
 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
 padding (for a 2KB architectural alignment). Given that the vectors are
 used only for debugging purposes, we could scrap them entirely or
 construct them on the fly in some other SRAM. So would free about 2.5KB,
 ideally. Lowest hanging fruit so far.
 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
 encoding. This reduces the size significantly, to about 20KB. The
 disadvantage is using a second cross-compiler or even a additional
 cross-compiler for native builds, complicating the build process.
 I maintain a branch for enabling FEL booting here [1], which provides
 two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
 There are no technical disadvantages in running the SPL in 32-bit, so
 this is mostly a build issue.
>>>
>>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
>>> ARMv7. It should be fairly easy to do,
>>
>> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
>> the case of Allwinner A64
>
> Yes, but that is just a matter of compiler or compiler flags. My point
> was we should be able to use different build for each without too much
> work.

It's a lot more work for the way most distros build u-boot, but TBH
the sooner I don't need to the better ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Simon Glass]

Hi Peter,

On 2 April 2018 at 10:45, Peter Robinson  wrote:
> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass  wrote:
>> Hi Andre,
>>
>> On 2 April 2018 at 09:43, André Przywara  wrote:
>>> Hi,
>>>
>>> On 01/04/18 14:19, Tom Rini wrote:
 On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
>> Hi Tom,
>>
>> On 7 August 2017 at 09:39, Tom Rini  wrote:
>>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>>
 The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
 code, with #ifdefs and different code paths. We should try to move 
 over to
 this soon so we can drop the old code.
>
> I hope this will applicable to SPL too?
>
> If so, we are having SPL size issues with few Allwinner families, if
> enable SPL_DM any suggestions?

 How close, and have you looked at the u-boot-spl.map to see what you can
 maybe trim?  Or areas to look at reducing in code complexity?
>>>
>>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>>> and picked most low hanging fruits already.
>>> So far we discussed several mitigations, but mostly to cover the
>>> "natural" SPL code size grow over time:
>>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>>> padding (for a 2KB architectural alignment). Given that the vectors are
>>> used only for debugging purposes, we could scrap them entirely or
>>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>>> ideally. Lowest hanging fruit so far.
>>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>>> encoding. This reduces the size significantly, to about 20KB. The
>>> disadvantage is using a second cross-compiler or even a additional
>>> cross-compiler for native builds, complicating the build process.
>>> I maintain a branch for enabling FEL booting here [1], which provides
>>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>>> There are no technical disadvantages in running the SPL in 32-bit, so
>>> this is mostly a build issue.
>>
>> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
>> ARMv7. It should be fairly easy to do,
>
> ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
> the case of Allwinner A64

Yes, but that is just a matter of compiler or compiler flags. My point
was we should be able to use different build for each without too much
work.

Regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Peter Robinson]

On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass  wrote:
> Hi Andre,
>
> On 2 April 2018 at 09:43, André Przywara  wrote:
>> Hi,
>>
>> On 01/04/18 14:19, Tom Rini wrote:
>>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
 On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
> Hi Tom,
>
> On 7 August 2017 at 09:39, Tom Rini  wrote:
>> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>>
>>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>>> code, with #ifdefs and different code paths. We should try to move over 
>>> to
>>> this soon so we can drop the old code.

 I hope this will applicable to SPL too?

 If so, we are having SPL size issues with few Allwinner families, if
 enable SPL_DM any suggestions?
>>>
>>> How close, and have you looked at the u-boot-spl.map to see what you can
>>> maybe trim?  Or areas to look at reducing in code complexity?
>>
>> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
>> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
>> and picked most low hanging fruits already.
>> So far we discussed several mitigations, but mostly to cover the
>> "natural" SPL code size grow over time:
>> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
>> padding (for a 2KB architectural alignment). Given that the vectors are
>> used only for debugging purposes, we could scrap them entirely or
>> construct them on the fly in some other SRAM. So would free about 2.5KB,
>> ideally. Lowest hanging fruit so far.
>> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
>> encoding. This reduces the size significantly, to about 20KB. The
>> disadvantage is using a second cross-compiler or even a additional
>> cross-compiler for native builds, complicating the build process.
>> I maintain a branch for enabling FEL booting here [1], which provides
>> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
>> There are no technical disadvantages in running the SPL in 32-bit, so
>> this is mostly a build issue.
>
> FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
> ARMv7. It should be fairly easy to do,

ARMv4 and ARMv7 are both 32 bit though, as opposed to 32 and 64 bit in
the case of Allwinner A64

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[Simon Glass]

[resending from correct address]

Hi Andre,

On 2 April 2018 at 09:43, André Przywara  wrote:
> Hi,
>
> On 01/04/18 14:19, Tom Rini wrote:
>> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
 Hi Tom,

 On 7 August 2017 at 09:39, Tom Rini  wrote:
> On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:
>
>> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
>> code, with #ifdefs and different code paths. We should try to move over 
>> to
>> this soon so we can drop the old code.
>>>
>>> I hope this will applicable to SPL too?
>>>
>>> If so, we are having SPL size issues with few Allwinner families, if
>>> enable SPL_DM any suggestions?
>>
>> How close, and have you looked at the u-boot-spl.map to see what you can
>> maybe trim?  Or areas to look at reducing in code complexity?
>
> The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
> SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
> and picked most low hanging fruits already.
> So far we discussed several mitigations, but mostly to cover the
> "natural" SPL code size grow over time:
> 1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
> padding (for a 2KB architectural alignment). Given that the vectors are
> used only for debugging purposes, we could scrap them entirely or
> construct them on the fly in some other SRAM. So would free about 2.5KB,
> ideally. Lowest hanging fruit so far.
> 2) We can compile the SPL in AArch32 mode, which can use the Thumb2
> encoding. This reduces the size significantly, to about 20KB. The
> disadvantage is using a second cross-compiler or even a additional
> cross-compiler for native builds, complicating the build process.
> I maintain a branch for enabling FEL booting here [1], which provides
> two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
> There are no technical disadvantages in running the SPL in 32-bit, so
> this is mostly a build issue.

FYI 32-bit tegra compiles SPL with ARMv4T and U-Boot proper with
ARMv7. It should be fairly easy to do,

> 3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
> size and sizeof(long) to be 32-bit and should help, though I haven't
> been able to successfully compile it yet (relocation types problems).
> Despite lacking mainline support for AArch64 ILP32 in Linux and
> glibc(?), GCC supports it for quite a while already. Unknown saving effect.
> 4) Use runtime decompression. Most SoCs have larger or more SRAM than
> the 32KB, so we could leverage this. Siarhei knows more about this.
> 5) Use a TPL. Haven't looked at this in detail yet.
>
> So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
> the >10 KB toll the DM_SPL support actually takes.

Is this the cost on 64-bit?

I wonder if CONFIG_OF_PLATDATA might be an option?

Regards,
Simon

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [U-Boot] [PATCH 1/3] dm: Add migration plan for CONFIG_BLK

[André Przywara]

Hi,

On 01/04/18 14:19, Tom Rini wrote:
> On Tue, Mar 27, 2018 at 11:34:19PM +0530, Jagan Teki wrote:
>> On Mon, Sep 4, 2017 at 9:57 PM,   wrote:
>>> Hi Tom,
>>>
>>> On 7 August 2017 at 09:39, Tom Rini  wrote:
 On Sat, Aug 05, 2017 at 03:45:53PM -0600, Simon Glass wrote:

> The CONFIG_BLK conversion involves quite invasive changes in the U-Boot
> code, with #ifdefs and different code paths. We should try to move over to
> this soon so we can drop the old code.
>>
>> I hope this will applicable to SPL too?
>>
>> If so, we are having SPL size issues with few Allwinner families, if
>> enable SPL_DM any suggestions?
> 
> How close, and have you looked at the u-boot-spl.map to see what you can
> maybe trim?  Or areas to look at reducing in code complexity?

The Boot ROM limit for all Allwinner SoCs known so far is 32KB. The A64
SPL (AArch64) stands at ~31KB at the moment. Yes, we went over the map
and picked most low hanging fruits already.
So far we discussed several mitigations, but mostly to cover the
"natural" SPL code size grow over time:
1) The AArch64 exception vectors take 1KB, plus an unnecessary ~1.6KB of
padding (for a 2KB architectural alignment). Given that the vectors are
used only for debugging purposes, we could scrap them entirely or
construct them on the fly in some other SRAM. So would free about 2.5KB,
ideally. Lowest hanging fruit so far.
2) We can compile the SPL in AArch32 mode, which can use the Thumb2
encoding. This reduces the size significantly, to about 20KB. The
disadvantage is using a second cross-compiler or even a additional
cross-compiler for native builds, complicating the build process.
I maintain a branch for enabling FEL booting here [1], which provides
two _defconfigs (one 32-bit for SPL, one 64-bit for U-Boot proper).
There are no technical disadvantages in running the SPL in 32-bit, so
this is mostly a build issue.
3) Try to use ILP32 for the AArch64 SPL build. This reduces the pointer
size and sizeof(long) to be 32-bit and should help, though I haven't
been able to successfully compile it yet (relocation types problems).
Despite lacking mainline support for AArch64 ILP32 in Linux and
glibc(?), GCC supports it for quite a while already. Unknown saving effect.
4) Use runtime decompression. Most SoCs have larger or more SRAM than
the 32KB, so we could leverage this. Siarhei knows more about this.
5) Use a TPL. Haven't looked at this in detail yet.

So 1) would be the easiest to pursue, but 2.5KB are not enough to offset
the >10 KB toll the DM_SPL support actually takes.

Cheers,
Andre.


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.