[lkml]   [2008]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] OLPC: Add support for calling into Open Firmware
Mitch Bradley wrote:
> d) OFW itself lives at the top of the virtual address space, just below
> the ROM. (The ROM is mapped virtual=physical for convenience) OFW
> uses RAM allocated from the top of physical memory, mapped at the
> aforementioned high virtual addresses. One page directory entry - the
> next to last one - is used for that RAM mapping and also for mapping
> additional miscellaneous I/O devices. The 8MB frame buffer requires 2
> additional PDEs, just below. When Linux takes over the display, OFW no
> longer needs the frame buffer mapping, but it is convenient to preserve
> that mapping temporarily while using OFW as a debugger.

So let me see here... you want the virtual address range [0xffc00000,
0xfff00000) to be reserved for OFW, and you are prohibiting the kernel
from using PAE?

> e) Low memory - everything except the ~1Meg that OFW lives in - is
> mapped virtual=physical.

Are you making this assumption when called from the kernel, too?

> j) Linux must save the following information during early startup:
> 1) The callback function address - either from the initial value of eax
> or from the OFW info block.
> 2) The the next-to-last page directory entry - just the pointer to the
> page table. The page table itself lives in OFW's reserved memory.
> k) When calling back into OFW, Linux must:
> 1) Establish a page directory that contains OFW's PDE (saved in j2
> above) and that maps the client interface argument array, including any
> buffer pointers.
> 2) Call callback_function with the address of the argument array in
> eax. (Ordinary 32-bit near call).
> For all of the OLPC kernel's current callbacks into OFW, the
> requirements (j2) and (k1) are easily satisfied by "priming"
> swapper_pg_dir with the contents of the current page directory (as
> pointed to by the CR3 register).

I do not like it, simply because it amounts to "initialize this
otherwise zero-initialized piece of data without making any kind of
reservations and blindly hope nothing else overwrites it."

I'm also troubled with the assumption that the kernel doesn't use PAE.
I realize that this is not an issue for OLPC, but it certainly makes
this a less-than-generic solution.

Having mapped page table entries which are not under kernel control is a
very serious problem for PAT - PAT requires, by hardware specification,
the kernel to eliminate all potential aliases with different mappings.

One way to deal with this, of course, is to save the firmware-provided
PGD and only use it for OFW calls. On the other hand, perhaps a better
questions is to what extent it is needed at all.

Furthermore, since you're using a nonstandard OFW interface (not
compliant with the x86 OFW binding document), all of this should be
called something like OLPC_OFW to make it clear that it's the OLPC variant.

If I had designed this, I would probably have used an SMI; since you
have control over the firmware you can do that. SMI saves the entire
machine state including all the modes, cleans them all up for you, and
puts it all back together at RSM time. It is slow, of course, but it
completely decouples the firmware and the OS, which is why it's used.


 \ /
  Last update: 2008-04-21 13:45    [W:0.105 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site