lkml.org 
[lkml]   [2000]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Reserving a (large) memory block
Date
On Thu, 31 Aug 2000 10:54:56 +0100 (BST) 
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

>> I'm working on a device driver for a device that sits on the PC
>> memory bus. I need to reserve/protect the memory range that the
>> device occupies from the rest of the kernel/system. How do I do
>> that? I think I see how I can mark blocks that are never to be
>> touched, but in this case the driver (obviously) needs to be able
>> to touch them, but the rest of the kernel must be hands-off.

> If its in the ISA or PCI space then we wont touch it. If its
> actually mapped as if it was part of RAM then the BIOS is
> responsible for reporting top of memory below it in the memory
> sizing calls, and optionally reporting it reserved as hole in the
> newer E820 call.

> We then just follow the bios. You can also reserve blocks of
> memory by hacking arch/i386/mm/init.c and marking them reserved

Ahh, that there is the problem. To explain I'd better start with
basically what the device is:

The device is a 168 pin SDRAM card which has a bunch of RAM on it
and also has a fat FPGA in the middle. The FPGA can be programmed
to do various interesting things like the mod exponentiation for
SSL, image processing (think photoshop plugins), etc. You can have
multiple firmware cores on the card(s) that are context shifted
among at runtime by the driver etc etc. API semantics for the
driver are the predictable open, read, write, close, trigger (tell
card to start processing written data), and wait (wait for driver to
tell its done).

Now the device behaves just like memory to the BIOS during POST
etc, and is in fact, exactly memory if no device drivers are loaded.
If a device driver is loaded and it detects one or more of these
devices then they and their memory ranges become obviously special.
Now, we can detect the devices and where their address ranges are
via the SMBUS and some careful probing so we know what we are trying
to grab. The problem is just telling the rest of the kernel that in
a clean VM&heap-happy manner.

--
J C Lawrence Home: claw@kanga.nu
---------(*) Other: coder@kanga.nu
http://www.kanga.nu/~claw/ Keys etc: finger claw@kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.067 / U:15.960 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site