public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed
From: Grant Erickson <gerickson@nuovations•com>
To: "linuxppc-dev@ozlabs•org" <linuxppc-dev@ozlabs•org>
Subject: Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc
Date: Tue, 28 Oct 2008 15:41:11 -0700	[thread overview]
Message-ID: <C52CE317.12884%gerickson@nuovations.com> (raw)

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

             reply	other threads:[~2008-10-28 22:48 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 22:41 Grant Erickson [this message]
2008-10-28 23:01 ` Reserving Early RAM Regions and Porting Denx's CONFIG_LOGBUFFER to arch/powerpc Wolfgang Denk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C52CE317.12884%gerickson@nuovations.com \
    --to=gerickson@nuovations$(echo .)com \
    --cc=linuxppc-dev@ozlabs$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox