[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 <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.

>
>>> 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