Messages in this thread | | | Date | Sat, 12 Aug 2000 11:18:12 +0200 (MET DST) | From | Bjorn Wesen <> | Subject | Re: pte_pagenr/MAP_NR deleted in pre6 |
| |
On Fri, 11 Aug 2000, Roman Zippel wrote: > The problem here is that the relation between virtual address / physical > address / page struct / memmap+index is hardly documented and it gets > more interesting when a page struct might also represent an i/o area
Amen to that - I'm doing a 2.4 port currently and our architecture has all DRAM at a pseudo-physical address 0xc0000000. Figuring out how to not make mem_map start at 0 and waste a lot of struct page's to cover everything up to 0xc0000000 and beyond, and what the __pa/__va things should do wrgds to the pseudo-0xc0000000 took some hours of groping around the archs and bootmem/zone code :) then it suddenly worked.. and like, "wow, don't touch it again!" :)
(luckily I found a comment in mm/numa.c about exactly that and that m68k and arm used it - you could never have been led to believe that looking through the non-commented source :)
The relationships between virtual/logical/physical etc. can be extremely confusing - our CPU has physical DRAM at 0x40000000 but it is segmented into 0xc0000000 in kernel-mode, while the paged virtual memory is at 0. Heh. Fortunately the 0x40000000 business can be largely ignored since it is only visible inside the TLB - for all other purposes the DRAM is at 0xc...
So what I ended up doing was to make __pa/__va convert between 0xc.. and 0x4.., put PAGE_OFFSET == 0xc.., max/min_low_pfn's at 0xc..., mem_map indexes start at 0 (corresponding to 0xc).. seems to work so far :)
It does not help of course that all archs do the bootmem and zone initialization in their own ways :)
-Bjorn
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |