On 27/11/16 17:02, Simon Glass wrote:
Hi,
On 23 November 2016 at 20:19, Siarhei Siamashka siarhei.siamashka@gmail.com wrote:
On Sun, 20 Nov 2016 14:56:59 +0000 Andre Przywara andre.przywara@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@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.