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

Simon Glass sjg at chromium.org
Mon Apr 2 03:10:37 UTC 2018


Hi,

On 2 April 2018 at 11:07, Peter Robinson <pbrobinson at gmail.com> wrote:
> On Mon, Apr 2, 2018 at 3:56 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Peter,
>>
>> On 2 April 2018 at 10:45, Peter Robinson <pbrobinson at gmail.com> wrote:
>>> On Mon, Apr 2, 2018 at 3:28 AM, Simon Glass <sjg at google.com> 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,
>>>
>>> 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


More information about the U-Boot mailing list