[U-Boot] [PATCH 05/24] SPL: tiny-printf: add "l" modifier

[André Przywara]

On 27/11/16 17:02, Simon Glass wrote:

Hi,

> On 23 November 2016 at 20:19, Siarhei Siamashka
> <siarhei.siamashka at gmail.com> wrote:
>> On Sun, 20 Nov 2016 14:56:59 +0000
>> Andre Przywara <andre.przywara at arm.com> wrote:
>>
>>> tiny-printf does not know about the "l" modifier so far, which breaks
>>> the crash dump on AArch64, because it uses %lx to print the registers.
>>> Add an easy way of handling longs correctly.
>>
>> I can't help but notice that the changes of this kind are in a way
>> defeating the original purpose of tiny-printf. And it is surely not
>> the first patch adding features to tiny-printf. I guess, in the end
>> we may end up with a large and bloated printf implementation again :-)
>>
>> A possible solution might be just a strict check when parsing format
>> modifiers and abort with an error message (yeah, this will introduce
>> some size increase, but hopefully the last one). This way we
>> acknowledge the fact that tiny-printf is a reduced incomplete
>> implementation, and that the callers need to take this into account.
>>
>> As for the "l" modifier. How much does it add to the code size? IMHO
>> this information should be mentioned in the commit message. Can the
>> AArch64 crash dump code be modified to avoid using it? Or can we have
>> the "l" modifier supported on 64-bit platforms only?
>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>  lib/tiny-printf.c | 43 +++++++++++++++++++++++++++++++++----------
>>>  1 file changed, 33 insertions(+), 10 deletions(-)
> 
> I think I tested this patch as adding 36 bytes on Thumb2 so not too
> terrible. But I do agree with the sentiment.

Thanks for checking that!

> Why is aarch64 using tiny-printf? Surely all though chips have heaps of space?!

Ha, one would hope so, right?
But in fact this is basically an existing 32-bit Allwinner chip with
64-bit cores - mostly because they can ;-). Replacing Cortex-A7 cores
with A53s seems to be a common exercise.

But the point is that even the most capable chip needs to be booted
somehow, and here the Allwinner boot ROM still loads only 32KB into some
SRAM. This hasn't changed for years, so even the 64-bit chips suffer
from the same SPL space limitations.
And since AArch64 does not define a tight encoding variant like Thumb,
we are even more limited in our code size.

Of course this only applies to the SPL, so once we have DRAM up and an
MMC driver initialized, we indeed have quite some resources available.

Cheers,
Andre.