From: <t_...@ya...> - 2009-05-20 20:22:55
|
Hello, I have a very big question for you guys : For the gumstix verdex-pro ( PXA270 ) To map the GPIO register in memory we have to do : src : http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs map = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, GPIO_BASE_OFFSET & ~MAP_MASK ); I would like to understand why we use as starting address the address 0 and we use as offset (GPIO_BASE_OFFSET & ~MAP_MASK) ???? Moreover, I don't understand why we have to GPIO_BASE_OFFSET : 0x40E00000 MAP_MASK : 4096-1 :0x00000FFF ~MAP_MASK = 0x00000000 ..... that mean that my offset = 0! Why not writing as offset 0 or why we do not specify the real address of the BASE_ADDRESS ( 0x40E00000 )??! Moreover, when we get or put memory in the mapping, why we again use : ((u32)map + (addr & MAP_MASK)); if addr == GPDR1 0x40E00010 & 0x00000FFF ---------- 0x00000010 So it is the MAP + 0x10. That is OK if the map is beginning at the address 0x40E00010. But it doesn't! Except if the /dev/mem start to map the memory at address 0x40E00010. That is why I'm asking this mailing list if the mapping of /dev/mem starts at the address 0x40E00010 ?! Thank you a lot Kris __________________________________________________________________ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ |
From: Dave H. <dhy...@gm...> - 2009-05-20 21:44:20
|
Hi Kris, > I have a very big question for you guys : > For the gumstix verdex-pro ( PXA270 ) > > To map the GPIO register in memory we have to do : > > src : http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs > > map = mmap(0, > MAP_SIZE, > PROT_READ | PROT_WRITE, > MAP_SHARED, > fd, > GPIO_BASE_OFFSET & ~MAP_MASK ); > > I would like to understand why we use as starting address the address 0 and we use as offset (GPIO_BASE_OFFSET & ~MAP_MASK) ???? The way that mmap works, offset is the real input parameter (see the man pages for mmap). The start (first parameter) is a suggestion about where to put the mapped memory in the applications memory space. 0 just causes mmap to choose the address itself. > Moreover, I don't understand why we have to > > GPIO_BASE_OFFSET : 0x40E00000 > MAP_MASK : 4096-1 :0x00000FFF > ~MAP_MASK = 0x00000000 ..... > > that mean that my offset = 0! Why not writing as offset 0 or why we do not specify the real address of the BASE_ADDRESS ( 0x40E00000 )??! Huh? MAP_MASK = 0x00000FFF so ~MAP_MASK = 0xFFFFF000 What the code is doing is ensuring that te offset passed in is aligned to a 4K page boundary. > Moreover, when we get or put memory in the mapping, why we again use : > ((u32)map + (addr & MAP_MASK)); > > if addr == GPDR1 > 0x40E00010 & > 0x00000FFF > ---------- > 0x00000010 > > So it is the MAP + 0x10. That is OK if the map is beginning at the address 0x40E00010. But it doesn't! 0x40E00000 is the physical address of the mapping. map (returned by mmap) is the virtual address in your process's memory space of that physical page of memory. Think of it as a 4K window into physical memory. You MUST map things in page boundaries (pages are 4K aligned). > Except if the /dev/mem start to map the memory at address 0x40E00010. That is why I'm asking this mailing list if the mapping of /dev/mem starts at the address 0x40E00010 ?! /de/mem starts at memory location 0, which is why you need to pass in a offset of 0x40E00000. mmap will return a virtual address which maps the region 0x40E00000 to 0x40E00FFF Since the real address that you want is 0x10 bytes into the window, you need to take the returned virtual address and add 0x10 to it to get the correpondsing virtual address. One thing to keep in mind, is that all code (whether it be in user or kernel mode) can only access memory using a virtual address. physical addresses can't be used directly. -- Dave Hylands Shuswap, BC, Canada http://www.DaveHylands.com/ |
From: Anon <ano...@co...> - 2009-05-20 23:08:39
|
If MAP_MASK : 4096-1 :0x00000FFF Then ~MAP_MASK: 0xFFFFF000 -----Original Message----- From: t_...@ya... [mailto:t_...@ya...] Sent: Wednesday, May 20, 2009 4:23 PM To: gum...@li... Subject: [Gumstix-users] question about mmap() for gpio ( is the /dev/mem map at the register base address 0x40E00010 ?) Hello, I have a very big question for you guys : For the gumstix verdex-pro ( PXA270 ) To map the GPIO register in memory we have to do : src : http://docwiki.gumstix.org/index.php/Sample_code/C/gpregs map = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, GPIO_BASE_OFFSET & ~MAP_MASK ); I would like to understand why we use as starting address the address 0 and we use as offset (GPIO_BASE_OFFSET & ~MAP_MASK) ???? Moreover, I don't understand why we have to GPIO_BASE_OFFSET : 0x40E00000 MAP_MASK : 4096-1 :0x00000FFF ~MAP_MASK = 0x00000000 ..... that mean that my offset = 0! Why not writing as offset 0 or why we do not specify the real address of the BASE_ADDRESS ( 0x40E00000 )??! Moreover, when we get or put memory in the mapping, why we again use : ((u32)map + (addr & MAP_MASK)); if addr == GPDR1 0x40E00010 & 0x00000FFF ---------- 0x00000010 So it is the MAP + 0x10. That is OK if the map is beginning at the address 0x40E00010. But it doesn't! Except if the /dev/mem start to map the memory at address 0x40E00010. That is why I'm asking this mailing list if the mapping of /dev/mem starts at the address 0x40E00010 ?! Thank you a lot Kris __________________________________________________________________ Make your browsing faster, safer, and easier with the new Internet ExplorerR 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/ ---------------------------------------------------------------------------- -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ gumstix-users mailing list gum...@li... https://lists.sourceforge.net/lists/listinfo/gumstix-users |