RE: [PATCH] Synthesize TLB refill handler at runtime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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

  Maciej


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux