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

[Simon Glass]

Hi,

On 14 January 2015 at 04:57, Siarhei Siamashka
<siarhei.siamashka at gmail.com> wrote:
> 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.

Nice work! The mmc path uses more stack than I would expect.

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

Let's not. We can print out DRAM clock info in U-Boot instead. It has
a line devoted to DRAM and another to CPU. If even more info is
required then we could add a command to print it.

But just because SPL sets up some clocks it doesn't mean that U-Boot
proper cannot display the info.

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

Regards,
Simon