[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 <andre.przywara at arm.com> wrote:
> > Hi,
> >
> > On 02/04/18 03:30, Simon Glass wrote:
> >>
> >> Hi Andre,
> >>
> >> On 2 April 2018 at 09:43, André Przywara <andre.przywara at arm.com> 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,  <sjg at google.com> wrote:
> >>>>>> Hi Tom,
> >>>>>>
> >>>>>> On 7 August 2017 at 09:39, Tom Rini <trini at konsulko.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180403/df83804a/attachment.sig>