Hi, On 14 January 2015 at 04:57, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > On Wed, 14 Jan 2015 09:17:47 +0100 > Hans de Goede <hdego...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot