On Thu, 08 Jan 2015 08:49:54 +0000 Ian Campbell ijc@hellion.org.uk wrote:
On Thu, 2015-01-08 at 09:02 +0200, Siarhei Siamashka wrote:
This allows to always have a complete log on the VGA/HDMI/LCD console.
Signed-off-by: Siarhei Siamashka siarhei.siamashka@gmail.com
include/configs/sunxi-common.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index b4324ee..5ddcc42 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -272,10 +272,15 @@ #ifndef CONFIG_SPL_BUILD #include <config_distro_defaults.h>
+/* Enable pre-console buffer to get complete log on the VGA console */ +#define CONFIG_PRE_CONSOLE_BUFFER +#define CONFIG_PRE_CON_BUF_SZ (1024 * 1024) +#define CONFIG_PRE_CON_BUF_ADDR (0x43000000 - CONFIG_PRE_CON_BUF_SZ)
/*
- 240M RAM (256M minimum minus space for the framebuffer),
- 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
- 1M script, 1M pxe and the ramdisk at the end.
- 32M uncompressed kernel, 15M compressed kernel, 1M pre-console
- buffer, 1M fdt, 1M script, 1M pxe and the ramdisk at the end.
Am I correct in thinking that the pre-console buffer is long gone (replaced by the actual console) by the time any of these mem layout choices come into play (i.e. long before anything might load a kernel, initrd or fdt)?
Yes, my understanding is that it should be already gone, but not too long ago. Logging in the patched pre-console buffer ends at the time when the following messages get displayed: In: serial Out: vga Err: vga
Now that you mentioned it, the patch is indeed extending the life time of the pre-console buffer, and this might be an unwanted side effect. Maybe Simon has some opinion.
If yes then I think it is confusing to modify this comment, and the comment before the pre-console #defines should mention that the buffer is boottime only/short lived etc.
Just in case if something goes really wrong (in theory it shouldn't, but in practice you know...) it is still somewhat safer to keep the buffer in its own dedicated area and keep everything else out.
If no then I'm not sure putting a "u-boot managed" buffer in the middle of the "user managed" load space is a good idea, since it could lead to odd/hard to debug corruptions etc if the kernel was >15M.
Either way I think it would be better to put this buffer somewhere else entirely since it isn't really the same as these things.
In a hypothetical scenario of having neither serial console nor hdmi/lcd/vga console available, the user managed code could probably dump the pre-console buffer to the SD card and provide some rudimentary debugging aid. Yes, hardly anyone would ever do this.
If the u-boot log could be somehow passed to the kernel and show in dmesg, that would be in fact quite useful in my opinion. But this is well out of scope of discussing the current patch.
*/ #define MEM_LAYOUT_ENV_SETTINGS \ "bootm_size=0xf000000\0" \
Both u-boot-sunxi#master and #next still have 0x10000000 here, which tree is this patch on? Some branch of Hans' tree (with "sunxi: sunxi-common.h: Reduce bootm_size to take the framebuffer into account" in it) I suppose?
Now the u-boot-sunxi#next branch has "bootm_size=0xf000000" too.
Yes, I was using the Hans' branch with the pending lcd patches, because I was working with this stuff too.
Perhaps a better place for the pre-console buffer would be right before the framebuffer (or at the top of RAM if no video on the board), with modifications to bootm_size or not depending on the answer to the original question above.
If this needs any kind of runtime address calculations instead of compile time constants, then IMHO it becomes unnecessarily complicated.
Anyway. The sunxi part of these changes just needs to assign some memory area to the pre-console buffer. In the end it does not really matter which one. The size also does not need to be too large. For example 1920 * 1080 / (8 * 16) = 16200. It means that only ~16K of the log buffer can fully cover the FullHD display using the 8x16 font. And this is even assuming no line breaks. I picked 1M only because it was the smallest unit of the address space allocation in sunxi-common.h :-)