From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Wed, 14 Jan 2015 15:28:41 +0100 Subject: [U-Boot] [PATCH 0/2] Really complete SPL & u-boot log on all consoles In-Reply-To: <20150114145729.0649352e@i7> References: <1421152210-14441-1-git-send-email-siarhei.siamashka@gmail.com> <54B6262B.2070505@redhat.com> <20150114145729.0649352e@i7> Message-ID: <54B67D19.9090003@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 14-01-15 13:57, Siarhei Siamashka wrote: > On Wed, 14 Jan 2015 09:17:47 +0100 > Hans de Goede 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 Oh pretty pictures, nice. Good work. > 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. Thanks for working on this, this sounds like a very useful effort. Regards, Hans > >> 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. >