Subject: Re: Marvell/evbppc - netbsd-current
To: Fraser Douglas <D.Fraser@flarion.com>
From: Matt Thomas <firstname.lastname@example.org>
Date: 03/22/2004 07:22:57
On Mar 22, 2004, at 7:00 AM, Fraser Douglas wrote:
> Matt, Steve,
> I updated from CVS Saturday. The board boots and I get up
> to a shell prompt. Thanks for the answers to my questions.
> A couple questions about memory layout and virtual memory.
> I needed to define options in the config file for
> USER_SR, KERNEL_SR and KERNEL2_SR for my build to work.
> They default to 12, 13, and 14, which on my target causes
> problems in that the BATs for the PCI buses end up at 12 and 13.
> The BATs take priority over page tables so the
> USER_SR and KERNEL_SR are then inaccessible.
Basically there are two rules: USER_SR, KERNEL_SR, KERNEL2_SR
must be higher the amount of physical memory. KERNEL_SR and
KERNEL2_SR must be contiguous.
On one box, KERNEL_SR/KERNEL2_SR are 8 and 9 and USER_SR is 11.
Fortunately the kernel and user address spaces are completely
> Defining those down to 9, 10, and 11 seems to work, but is
> troubling in that there are a couple of spots in the
> source code (oea/oea_machdep.c oea/pmap.c) where hard coded
> comparisons to 13 and 14 exist. A real head scratcher
> for me, maybe not for you.
Nope. Those are to preserve holes in the address if the kernel
overlaps (to catch bugs).
> In particular, Matt, do you know where your PCI space gets
> mapped for your card (in oea_batinit() in oea/oea_machdep.c)?
Actually, I let NetBSD configure the PCI BARS so that isn't an
> Also, is there any documentation that addresses the BAT and
> page table layout and usage for the powerpc ports in general?
> (From a NetBSD perspective, of course.....)
> Doug Fraser
> -----Original Message-----
> From: Matt Thomas [mailto:email@example.com]
> Sent: Friday, March 19, 2004 9:15 PM
> To: Steve Woodford; Fraser Douglas; port-powerpc@NetBSD.org
> Subject: Re: Marvell/evbppc - netbsd-current
> At 03:04 PM 3/19/2004, Steve Woodford wrote:
>> On Friday 19 March 2004 9:49 pm, Fraser Douglas wrote:
>>> It needs (for the ev64260 port) to define macros
>> [in <evbppc/bus.h>]
>>> which I am afraid will most likely break other
>>> evbppc based ports if they are using that bus.h.
>>> Can anyone suggest a place to invoke those macros
>>> other than in that particular header?
>>> Possibly as an option in the config? (though that seems 'brutish')
>> I can't think of any other way to specify this. I've rattled up an
>> evbppc-specific defflag "EVBPPC_BUS_DMA_NEEDS_P2B" which DTRT if
>> specified in the kernel config file. If there are no objections, I'll
>> commit this.
>> As I recall, you just need the following definitions for the macros:
>> #define PHYS_TO_BUS_MEM(t, addr) (addr)
>> #define BUS_MEM_TO_PHYS(t, addr) (addr)
> Don't even need that anymore. I added gt_dma_phys_to_bus_mem and
> gt_dma_bus_mem_to_phys to the gt dma tag. Which effectively do the
> Matt Thomas email: firstname.lastname@example.org
> 3am Software Foundry www:
> Cupertino, CA disclaimer: I avow all knowledge of this