Date: Fri, 16 Aug 2002 11:12:36 +1000 From: Peter Grehan <peterg@ptree32.com.au> To: Benno Rice <benno@FreeBSD.org> Cc: freebsd-ppc@FreeBSD.org Subject: Re: Yet more updated kernels Message-ID: <3D5C5184.ED9DF4DC@ptree32.com.au> References: <3D5BA563.362C35C7@ptree32.com.au> <1029457832.362.4.camel@ratchet.jeamland.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Benno, > Actually NetBSD has (or at least used to) use their ability to have > separate page free lists to only ever allocate pvo entries from them low > 256MB of RAM. At least that's how I read it. This meant that only > direct-mapping the low 256MB worked fine as that's where all the pvo > entries were. That wasn't the problem I hit, and may not have for a long time. The pmap_enter() routine calls pmap_syncicache with the physical address, so that implies that all physical memory must have a 1:1 mapping. It's not possible to use the virtual address, since the segment registers for that pmap may not be in use. I hit this problem immediately, since OpenFirmware lives just below high memory, and my always-sync-icache mod had a DSI when doing a syncicache with the unmapped address. There is some NetBSD code that disables the MMU to sync the icache, but it's not used for 6XX processors. BTW, when using BATs for all of RAM, most of the OpenFirmware mappings aren't necessary, so the BPVO_POOL_SIZE constant can be dropped down to 2048 or so. later, Peter. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ppc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D5C5184.ED9DF4DC>