On Wed, Nov 10, 2004 at 01:58:29PM -0000, Neil Wilson wrote: > Hi, > > I am trying to write a command line utility for our dev board > (440GX,2.6.9 kernel) in order to provide support for our hardware > engineers. As a test I am trying to dump the first few bytes of the > U-boot header. > > I though that this would work but using /dev/mem gives me a bad address > error on the pread64, using /dev/kmem only reads back 0 bytes. Is there > something blindingly obvious that I am missing for using 36bit addresses > ? I believe the address is correct as I can see the boot code from > within the kernel. Thanks.
No, it's not blindingly obvious at all. First, mmaping /dev/mem is a completely non-portable way to get at devices in userspace. It has no guarantees of working across architectures and is broken in many ways. One way is on PPC440 where we have a 36-bit physical address space. The /dev/mem implementation simply allows you to mmap an offset within a 32-bit physical address space. On PPC440, this means you can't get to any of the useful devices since they are all above 4GB. In post 2.6.9, remap_pfn_range() helps a bit but there is still a local (arch/ppc/) problem... I'm working on some patches to fix 36-bit support for io_remap_page_range() and to fix some problems with set_pte() and friends on 36-bit platforms. This is the first bit necessary to make this work at all in 2.6. I should be posting something RSN. ;) -Matt
