Subject: Memory location question

From: <[email-masked]>
Date: Tue, 14 Sep 1999 11:36:31 -0500 (CDT)

Hi,

I am porting a device driver from vxWorks to Lionux, and it has some
specific memory needs.  In particular, it needs to use memory from 0x600
to 0x700, and 0x1000 to 0x1fff.  It's not clear to me yet if Linux is
using anything in this area that will conflict with the driver's needs.
It looks like the kernels page tables are at 0x4000.  Will this cause
problems if I try and reserve the memory ranges above for my driver?

--
Kyle Mestery			| StorageTek's Storage Networking Group
[email-masked]		| http://www.freebsd.org/
[email-masked]		| http://www.netwinder.org/
	Protect your right to privacy: www.freecrypto.org

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: [email-masked]
Date: Tue, 14 Sep 1999 19:35:05 +0100 (BST)

> problems if I try and reserve the memory ranges above for my driver?

There is nothing special with those memory locations.  Use get_free_page
to be returned the address of a page to use instead of 0x1000, and
kmalloc to allocate the other 256 bytes, which will also return the
address of some memory.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Tue, 14 Sep 1999 20:24:53 +0100

>to 0x700, and 0x1000 to 0x1fff.

Er, what for?  That sounds like a rather bad idea to me.

>It's not clear to me yet if Linux is

0x600..0x700 is probably OK because that page is pinned down anyway for the 
vector table - though it's usually marked inaccessible to trap NULL 
dereferences.  There is no page mapped at 0x1000 per default so you will need 
to create a fixed mapping there if you need it.  The page table shouldn't get 
in your way if you stay in the ranges you mentioned?

p.

---

From: <[email-masked]>
Date: Tue, 14 Sep 1999 14:33:30 -0500 (CDT)

Hi,

> Er, what for?  That sounds like a rather bad idea to me.
Well, I'm porting a shared memory driver from vxWorks that does TCP/IP
over the PCI bus, similar to Mark D.'s driver.  I would use Mark's, but
this one requires backwards compatibility with processors running
vxWorks, so I need to port our driver.  I am using Mark's as a
framework.

> in your way if you stay in the ranges you mentioned?
I plan on staying in those ranges, so hopefully it will work to use them
as I have outlined.  What is the easiest way to create the mapping, in
head-armv.S, or later on in the initialization?  Thanks.

---

From: Philip Blundell <[email-masked]>
Date: Tue, 14 Sep 1999 20:40:29 +0100

>vxWorks, so I need to port our driver.  I am using Mark's as a

Oh, I think I get it now.  Those are physical addresses, not virtual ones.  
In that case, the thing to do is ignore most of what I wrote before, fiddle 
mark_usable_memory_areas so that it keeps the page at 0x1000 reserved for the 
kernel, and then just access those pages through the normal kernel mappings at 
0xc000xxxx.

p.

---

From: <[email-masked]>
Date: Tue, 14 Sep 1999 14:43:27 -0500 (CDT)

Hi,

> kernel, and then just access those pages through the normal kernel mappings at
Sorry about that, I guess I wasn't too clear on them being physical
addresses. I'll take a look at that and see what I can produce.  Thanks
Phil.

---

From: [email-masked]
Date: Tue, 14 Sep 1999 22:35:28 +0100 (BST)

> kernel, and then just access those pages through the normal kernel mappings at 

But please only do this if your driver configuration option is switched on.
I don't want an extra page reserved for no reason on all architectures because
of this.

And yes, definitely go through the 0xc000xxxx mappings for now, and don't switch
off the cacheable and bufferable bits.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: <[email-masked]>
Date: Wed, 15 Sep 1999 06:33:31 -0500 (CDT)

Hi,

> off the cacheable and bufferable bits.

Why can't I do that?  The memory needs to be marked as
non-cacheable/non-buffferable.

---

From: Philip Blundell <[email-masked]>
Date: Wed, 15 Sep 1999 14:49:17 +0100

>non-cacheable/non-buffferable.

If you turn off cacheable and bufferable for the section at 0xc0000000 the 
kernel will run like a blocked drain.  You'll need to make a new mapping in 
that case -- probably easiest to use __ioremap.

p.

---

From: <[email-masked]>
Date: Wed, 15 Sep 1999 09:04:24 -0500 (CDT)

Hi,

> that case -- probably easiest to use __ioremap.
Thanks for the great imagery!:)  I was actually just starting down that
path now.  Thanks Phil.