Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc

Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc

[Grant Erickson]

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

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.

However, such an approach in arch/powerpc falters because an attempt to
prematurely reduce total_lowmem results in mapin_ram(), via mmu_mapin_ram(),
only covering part of the total, say 128 MiB or 256 MiB, RAM with 16 MiB and
4 MiB large pages, leaving a residual, of say 4 MiB, to cover with smaller 4
KiB map_page() pages.

However, when map_page() runs, it eventually calls lmb_alloc_base() which
returns a page in that 4 MiB "tail" unmapped region. This then explodes due
to a page fault when clear_page() is called on the page in unmapped RAM at
the dcbz instruction in clear_pages().

Regards,

Grant

Re: Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc

[Wolfgang Denk]

Dear Grant,

In message <C52CE317.12884%gerickson@nuovations.com> 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  <6940@jpl-devvax.JPL.NASA.GOV>