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. --Brad -----Original Message----- From: macro@xxxxxxxxxxxxxxxxxx [mailto:macro@xxxxxxxxxxxxxxxxxx]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? > 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
