[Top] [All Lists]

RE: [PATCH] Synthesize TLB refill handler at runtime

To: "'Maciej W. Rozycki'" <>
Subject: RE: [PATCH] Synthesize TLB refill handler at runtime
From: Brad Larson <>
Date: Mon, 29 Nov 2004 11:57:39 -0800
Cc: "'Ralf Baechle'" <>, Thiemo Seufer <>, Manish Lachwani <>, Geert Uytterhoeven <>, Linux/MIPS Development <>
Original-recipient: rfc822;
hmm, the original email left the impression that its desirable for the firmware 
to be available after kernel handoff.  Looks like the current status is fine 
for those who need it.


-----Original Message-----
From: []On
Behalf Of Maciej W. Rozycki
Sent: Monday, November 29, 2004 11:47 AM
To: Brad Larson
Cc: 'Ralf Baechle'; Thiemo Seufer; Manish Lachwani; Geert Uytterhoeven;
Linux/MIPS Development
Subject: RE: [PATCH] Synthesize TLB refill handler at runtime

On Mon, 29 Nov 2004, Brad Larson wrote:

> Real, not-demo, 32-bit systems are the majority and will typically put
> the io up at 4GB and let it grow down and have the memory grow up from
> zero.  There is a natural dividing line, minimal TLB usage, and
> straightforward access to the first 512MB of memory unmapped.  Which of
> course means moving the boot device at bfc00000 up high as well as
> getting things like discovery at b4000000 out of the way as well.


> So, for firmware callbacks to do printf the kernel would need to restore
> the mappings the firmware needed before handoff.  Also firmware usually

 If it needs to access anything beyond KSEG0/1 and XKPHYS is unavailable,
then setting up a single wired TLB entry, using a large page if hardware
is scattered (you can have 256MB pages, you know; if you don't implement
that and your largest page size does not cover the whole area, you can
switch mappings), upon entry and removing it upon exit is trivial and
should just work.  Firmware callbacks are not meant to be common -- the
performance loss from an invalidated TLB entry will be negligible; you can 
restore the original TLB entry, too.

> carves out some memory above 1MB for its drivers so either the firmware
> has to stop servicing drivers if the kernel stomps on this memory or the
> kernel needs to get the memory ranges available at handoff which I
> recall doing with netbsd since it accepted non-contiguous memory.

 Everything needed for that is already present (it's been there for a
couple of years already) -- just let Linux know in some way which areas of
RAM are available for general use and which ones are best left untouched.  
It's being done for other systems.  There is a dedicated "ROM data" tag
available for that even in addition to the generic "reserved" one.


<Prev in Thread] Current Thread [Next in Thread>