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
separate.

> 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
issue.

> 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.....)
>
> Thanks.
>
> Doug Fraser
>
> -----Original Message-----
> From: Matt Thomas [mailto:matt@3am-software.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
>>> for:
>>> PHYS_TO_BUS_MEM
>>> and
>>> BUS_MEM_TO_PHYS
>> [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
> above.
>
>
> -- 
> Matt Thomas                     email: matt@3am-software.com
> 3am Software Foundry              www: 
> http://3am-software.com/bio/matt/
> Cupertino, CA              disclaimer: I avow all knowledge of this 
> message.
>