Can't mmap the top 1MB of /dev/mem?

Mark S. Mathews mark at
Fri Jun 23 05:00:02 EST 2000

Sorry, I should have been more specific....aren't you all mind-readers?

The mmap is failing w/ errno=EINVAL.  Here's the call:

mem_fd = open("/dev/mem", ORDWR);

p = mmap( NULL, (16*1024*1024),
          (PROT_READ|PROT_WRITE), MAP_SHARED, mem_fd, 0xff000000UL);

15MB works just fine.  I just tried a test w/ offset 0xff800000 and size
of 8MB.  That failed too.  Here's a couple of other tests I just tried:

offset      len        result
0xfff00000, 1MB        failed
0xffe00000, 1MB        success

So it looks like it's specifically related to the top 1MB, not the size.

BTW: Dan, I think you may have run into this before.  The sample code you
once sent me only mmaps the lower 7MB of an 8MB flash setup.

This whole thing isn't really a critical issue for me.  More of a
curiosity.  I'm not using those sectors anyway.  ;-)

If it _were_ extremely  important I could always trace the mmap system
_That's_ why Linux is so cool.

Thanks to everyone for the responses,

On Thu, 22 Jun 2000, Dan Malek wrote:

> "Mark S. Mathews" wrote:
> > ...... One thing I've noticed is that it won't let me mmap the
> > top 1MB of the address space.
> That should work, I do this quite regularly.  What actually fails,
> the mmap() or your access to the mapped region?
> There is what I do:
> 	mem_addr = (u_char *)mmap(NULL, FLASH_MEM_SIZE,
> 			mem_fd, FLASH_MEM_ADDR);
> #define FLASH_MEM_SIZE and FLASH_MEM_ADDR accordingly.  I hope there
> isn't some weird arithmetic rounding problem when we hit the top.  I
> just usually tell this to map the upper 8M bytes.
> The MMU doesn't care, if the generic Linux VM subsystem creates the PTEs
> it just loads them.  I don't remember any code in the mem driver that
> would prevent this either.  None of this is unique to the 8xx.
> 	-- Dan

Mark S. Mathews

AbsoluteValue Systems      Web:
P.O. Box 941149            e-mail: mark at
Maitland, FL 32794-1149    Phone:  407.644.8582
USA                        Fax:    407.539.1294

** Sent via the linuxppc-embedded mail list. See

More information about the Linuxppc-embedded mailing list