Re: Pegasos dmesg

[Tim Rightnour <root%garbled.net@localhost>]

On 20-Jan-2008 Frank Wille wrote:
> So the easiest solution would be to run pci_configure_bus() on the primary
> PCI bus @0x80000000 only, and leave the secondary for "AGP-emulation" alone?

Yes, that is the "easiest" solution there, for pegasos, but to fix it
correctly, you should add a test for PCI_CLASS of VGA and if so, return 0.

Your solution will work for pegasos though, because of the crazy second pci
"bus", which in all reality should just be avoided by PCI_NETBSD_CONFIGURE.

> Ok. For the Pegasos2 the primary pchb maps pcimem at 0x80000000-0xbfffffff.
> But all the devices are usually limited to the 0x8 range.
> 
> When looking at vmparam.h, we need 0xa and 0xb for KERNEL_SR and KERNEL2_SR,
> so I would limit the mem extent to 0x80000000-0x9fffffff.

In practice, it shouldn't matter too much, unless you start loading VGA cards
into every slot.  Beyond that, the issue becomes just one of BAT maps, because
bus_space_map should be able to handle those addresses anyhow.

>> So we are saying that the ranges it will map those cards to, lies between
>> pbs.base (0xc) and pbs.limit (0xd).
> 
> Then pbs_limit is not absolutely correct, because extent_create needs the
> last address to include into the extent: pbs_limit - 1.

Yah, it probably needs that.

> But I'm still unsure if extent_create gets an offset to the pchb base address
> or the real physical addresses? Your example here lets me think the latter,
> but in the prep port you create a mem extent for 0x00000000-0x0fffffff,
> which is rather strange...?

It's strange, because prep has the base and offset flipped around, which is why
prep uses the BUS_MEM_TO_PHYS stuff.  (fiddling with ofwpci actually makes me
wonder if I could flip those two back around and nuke BUS_MEM_TO_PHYS on prep)

> Now I changed pegasospci.c to do the following in attach():
> 
>#ifdef PCI_NETBSD_CONFIGURE
>     if (isprim) {
>         ioext  = extent_create("pciio",  0x00001000, 0x00003fff,
>             M_DEVBUF, NULL, 0, EX_NOWAIT);
>         memext = extent_create("pcimem", 0x80000000, 0x9fffffff,
>             M_DEVBUF, NULL, 0, EX_NOWAIT);
>         if (pci_configure_bus(pc, ioext, memext, NULL, 0,
>             CACHELINESIZE))
>             printf("pci_configure_bus() failed\n");
>         extent_destroy(ioext);
>         extent_destroy(memext);
>     }
>#endif /* PCI_NETBSD_CONFIGURE */
> 
> 
> But it doesn't work much better. Refer to the attached dmesg.
> 
> It no longer maps the audio device correctly:
> auvia0 at pci0 dev 12 function 5bus_space_map(0xa005acd8[0:10000], 0x1000,
> 0x100) failed: 35
>: can't map i/o space

35 == EAGAIN.  Ie, you asked for more io space than was available in the range
1000-3fff. (odd, maybe the firewire or something is eating IO space).  Maybe
extend the io range up to about 8000 or ffff?

> The viaide is not recognized as being in native mode:
> viaide0 at pci0 dev 12 function 1
> viaide0: VIA Technologies VT8231 ATA100 controller
> viaide0: primary channel interrupting at irq 14
> atabus0 at viaide0 channel 0
> 
> And it still hangs after /sbin/init.

You didn't allow it to reconfigure the ide, right?  And none of the addresses
are stomping on the ide, are they?  It helps alot to keep PCI_CONF_DUMP in the
kernel as you go, to see the final mappings.

Where after /sbin/init did it hang exactly?

---
Tim Rightnour <root%garbled.net@localhost>
NetBSD: Free multi-architecture OS http://www.netbsd.org/
Genecys: Open Source 3D MMORPG: http://www.genecys.org/