Am Dienstag den, 15. Januar 2002, um 18:41, schrieb Jason R Thorpe:

> On Tue, Jan 15, 2002 at 02:46:05PM -0800, John Clark wrote:
>
>> I got the kernel on to the IQ80310 board and now get the following:
>>
>>
>> RedBoot> go 0xa0200000
>
> Hm, did you load this via the Ethernet, or copy it into flash and boot
> it from there?

System setup:
Board: IQ80310
Backplane: (Cheating) ATX mother board with no CPU installed.
PCI Slots: 2 used: (arbitrary numbering):
Slot 1: LSI Logic PCI card with 53c1010 SCSI controler.
Slot 2: PCI card with Intel 82544GC Gigabit Ethernet.
(I'm not trying to get either of these PCI devices up at the moment, 
hence
there should be no drivers in the kernel for them.)

I downloaded the image netbsd-fxp0 built straight from the cvs archives,
burnt that into flash, then before the above
'go' command, had copied it back out of flash into ram.

>
>> obio0 at mainbus0: board rev. F, CPLD rev. A, backplane not present
>    .
>    .
>    .
>> iopxs0 at mainbus0: i80312 Companion I/O, acting as PCI slave
>
> Hm.  Ok, this is different from my IQ80310 setup:
>
> obio0 at mainbus0: board rev. F, CPLD rev. D, backplane present
> .
> .
> .
> iopxs0 at mainbus0: i80312 Companion I/O, acting as PCI host
>
> Now, this "is_host" variable is consulted when the i80312 is configured.
> In particular, if is_host is false, then the assumption is that we're
> plugged into a PCI host that will configure some i80312 paramters as 
> part
> of its own PCI bus configuration.  This could be part of the problem.
>
>> Intel product 0x100d (ethernet network, revision 0x02) at pci0 dev 5
>> function 0
>> not configured
>
> Which Intel Gig-E is this?  My i82544GC parts have a product ID of 
> 0x100c.

These are eval boards. But I think the doc says that copper gig-e device 
is 0x100d.
Do you have a fiber board?


>
>> root on fxp0
>> nfs_boot: trying DHCP/BOOTP
>> nfs_boot: DHCP next-server: 63.221.93.162
>> nfs_boot: my_addr=192.168.111.155
>> nfs_boot: my_mask=255.255.255.0
>> nfs_boot: gateway=192.168.111.112
>> panic: lockmgr: draining against myself
>> Stopped in pid 0 (swapper) at   0xa0321d20:[u]vm_fault(0xa0366aec,
>> a01e0000, 3,
>> 0) -> e
>
> Hm.  This is strange.  Is the physical address space laid out on
> your board differently from a stock IQ80310?  Can you please use
> gdb to determine what source file/line that PC maps to?  (It maps
> to uvm_swap.c:933 in my source tree, but my tree is almost certainly
> different from yours, and so it's not very meaningful.)

The memory starts at 0xa0000000, and I have 128 Megs rather than the 32
which is the 'stock' board.


>
> If you don't have a cross-gdb, you can get one by doing:
>
>     MKCROSSGDB=yes ./build.sh -t -m evbarm ...

I'll try that tonight.