[U-Boot] [PATCH 0/2] Really complete SPL & u-boot log on all consoles

[Siarhei Siamashka]

On Wed, 14 Jan 2015 09:17:47 +0100
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi Siarhei,
> 
> On 13-01-15 13:30, Siarhei Siamashka wrote:
> > By enabling pre-console buffer in both SPL and u-boot and some minor
> > tweaks, it is possible to see all log messages (including SPL messages
> > too) on VGA/HDMI/LCD console and other stdio based consoles.
> >
> > The first patch adds the necessary code to implement this feature.
> > The second patch enables it for Allwinner (sunxi) devices.
> >
> > Siarhei Siamashka (2):
> >    console: Allow pre-console buffer to also extract SPL log messages
> >    sunxi: Enable SPL pre-console buffer
> 
> Interesting patchset, for 1/2 I agree with Simon's recommended changes,

I'll reply to Simon's e-mail a bit later today.

> for 2/2, can we make the buffer 512 bytes please?

Sure. In fact I'm currently trying to do more in-depth SPL stack usage
analysis. Just to see how much of it is really needed by the SPL and
not to make guesses whether reducing the stack from 8K to 6K (or to
some other arbitrary size) would be fine or not.

Currently u-boot already compiles code with '-fstack-usage' GCC option,
which reports stack usage for each individual function in *.su files.
The remaining part is how to find the total maximum stack usage, based
on this information. There are some guides and papers, which mention
the use of '-fstack-usage' option together with '-fcallgraph-info'.
But '-fcallgraph-info' does not seem to be supported at least by my
version of GCC. And there are various scripts and tools with different
level of maturity and support. I'm sure that some u-boot developers
are also using something (otherwise, what is the point enabling
'-fstack-usage' GCC option in the first place?).

Anyway, none of the tools seemed convenient/usable enough to me. And
I decided that it may be faster to quickly hack some script myself,
tailored specifically for u-boot SPL:
  http://people.freedesktop.org/~siamashka/files/20150114-spl-stackgraph/spl-stackgraph.rb

The results of running the script for u-boot v2015.01, analysing
normal and FEL variants of SPL, built for Cubieboard2 with GCC 4.8:
  http://people.freedesktop.org/~siamashka/files/20150114-spl-stackgraph/spl-stackgraph-v2015.01-cubieboard2.png
  http://people.freedesktop.org/~siamashka/files/20150114-spl-stackgraph/spl-stackgraph-v2015.01-cubieboard2-fel.png

And all the same for the current sunxi-next branch:
  http://people.freedesktop.org/~siamashka/files/20150114-spl-stackgraph/spl-stackgraph-sunxi-next-cubieboard2.png
  http://people.freedesktop.org/~siamashka/files/20150114-spl-stackgraph/spl-stackgraph-sunxi-next-cubieboard2-fel.png

This may be not entirely accurate, because doing this properly needs
correct tracking of indirect calls. Also there are 'dynamic' stack
frames if variable length arrays are involved. But at least it gives
an idea about the approximate stack size requirements.

> SPL does not print out much,

This can be changed. Having more detailed information about DRAM clock
and timings in the log would be quite useful. If, with the Simon's help,
we manage to implement handing over the u-boot log to the linux kernel
(so that it shows in the dmesg log), then suddenly the diagnostic
information from the SPL becomes a lot more accessible to the end users.

> and RAM is very constraint in the SPL.

Yes, exactly. Especially considering that we have already almost used
it up the space for code+data (~22K out of available 24K). Everything
is even much worse in the FEL mode. IMHO some improvements are needed
and I'm preparing patches to address the most obvious problems.

This is also the reason why I was not very happy about
  http://lists.denx.de/pipermail/u-boot/2014-December/199254.html

> Also can you please send a v2 of the display series for the ssd2828
> one of the coming days ?  I'm going to send a pull-req to get everything
> pending in u-boot-sunxi/next today, and after that I would like to
> get the ssd2828 + my hitachi lcd panel patches ready for a follow-up
> pull-req.

Sure. Unfortunately it looks like I'm not going to get any feedback
about the http://linux-sunxi.org/ICOU_Fatty_I tablet. So it does not
make sense waiting any longer.

-- 
Best regards,
Siarhei Siamashka