Re: Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc
From: Wolfgang Denk <hidden>
Date: 2008-10-28 23:08:33
Dear Grant, In message [ref] you wrote:
I am working on attempting to migrate the Denx CONFIG_LOGBUFFER feature from arch/ppc: http://git.denx.de/?p=linux-2.6-denx.git;a=blob_plain;f=arch/ppc/mm/init.c;h b=3df65660bbfa769b10b141351b0ea10427b0b709 http://git.denx.de/?p=linux-2.6-denx.git;a=blob_plain;f=kernel/printk.c;hb=3 df65660bbfa769b10b141351b0ea10427b0b709 In the historical implementation, basically, u-boot (if so configured) allocates 16 KiB + 4 KiB of memory at the end of physical RAM to store log messages that are compatible with the Linux kernel's printk. When Linux (if
Note that recent versions also can put the log buffer in SRAM or other similar storage areas like the OCM on some 4xx PowerPC systems; this is actively used for example on PPC440EPx to make sure the log buffer data remain unchanged by a system reset.
so configured with CONFIG_LOGBUFFER) starts up, it redirects the normal log_buf to this "external log buffer" and appends any existing printk messages to those already pushed by u-boot. Future printk messages are then sent off to this new "external log buffer".
A short explanation for those who don't know what this is used for: 1) This allos to pass power-on selft test results from theboot loader (U-Boot) to the Linux kenrel, where it then can retrieved by application code using standard methods (syslog). 2) After a system crash, the log buffer is kept and can be read either by U-Boot or after rebooting into Linux. There are cases where the log buffer contains information that didn't make it any more to the console - if there is some console at all.
What is the preferred method for hiding/reserving chunks of memory such as this during early boot? The device tree? The 'mem=' parameter? Adding an lmb_reserve() in prom.c:early_reserve_mem()? Twiddling things auto-magically such as the historical implementation? Some combination thereof? The arch/ppc historical implementation simply twiddled total_memory and total_lowmem and then ioremap'd the 20 KiB off the end of memory.
That's a good question - such a mechanism is needed in several
places, for example to pass a pre-initialized video buffer to Linux
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Let's say the docs present a simplified view of reality... :-)
- Larry Wall in [off-list ref]