Re: [9fans] PCI vs. VPC

Re: [9fans] PCI vs. VPC

[jmk]

Also, you'd need to do more work to get a 21041 to work,
a lot of details are different.

Re: [9fans] PCI vs. VPC

[Don]

> Also, you'd need to do more work to get a 21041 to work,
> a lot of details are different.
>
Yea, we figured there would be just alittle more work than
that, but, it was worth a start to see if the card got
recognized. The main concern was to determine why PCI
wasn't being recognized at all. Now that we know other
OSs pull the information from the BIOS and the port
addressing is invalid (which is what we speculated) our
next (mission) is to determine the best way to obtain
valid port addresses. What would you suggest?
Don
http://www.7f.no-ip.info/

Re: [9fans] PCI vs. VPC

[jmk]

On Tue May  7 08:01:22 EDT 2002, north_@www.7f.no-ip.com wrote:
> > Also, you'd need to do more work to get a 21041 to work,
> > a lot of details are different.
> >
> Yea, we figured there would be just alittle more work than
> that, but, it was worth a start to see if the card got
> recognized. The main concern was to determine why PCI
> wasn't being recognized at all. Now that we know other
> OSs pull the information from the BIOS and the port
> addressing is invalid (which is what we speculated) our
> next (mission) is to determine the best way to obtain
> valid port addresses. What would you suggest?
> Don
> http://www.7f.no-ip.info/

There is no way other than rewriting much of the driver initialisation code.
The fault lies with your emulator, the hardware description page you pointed to
in a previous message said it emulated the Intel Triton Chipset - it doesn't.

Re: [9fans] PCI vs. VPC

[Stephen J. Bevan]

jmk@plan9.bell-labs.com writes:
> My first suspect would be that the PCI configuration ports are not
> being emulated. Windows and Linux use the BIOS to retrieve PCI configuration
> space information, Plan 9 does it raw.

Linux can do it raw or via the BIOS.  The default is to do it raw even
if there is a BIOS.  However, if a raw probe for configuration types 1
or 2 fails, it falls back to using the BIOS.  This fallback can be
disabled by booting Linux with "nobios".

Re: [9fans] PCI vs. VPC

[jmk]

My first suspect would be that the PCI configuration ports are not
being emulated. Windows and Linux use the BIOS to retrieve PCI configuration
space information, Plan 9 does it raw.

[9fans] PCI vs. VPC

[Jake]

Hi,

We got release 4 running in Virtual PC 5.0.2 on Mac OS X 10.1.4.
Everything seems to work as expected except ethernet. VPC emulates an
Intel 21041-based ethernet card.

	Ethernet
	* Emulates a DEC/Intel 21041-based PCI Ethernet card
	* The card is plug-and-play and can be reconfigured by the
	  operating system, but default settings use IRQ 1

complete list of emulated hardware is here:
http://fmpweb.connectix.com/kdb_new/FMPro?-db=kdb%5fweb.fp5&-format=detail.htm&-lay=entry&-sortfield=modified&-sortorder=descend&Keywords=emulated%20hardware&-max=30&-recid=34251&-find=


We change the ethernet driver with the following modification in hope to
make it work:

191d190
<       Tulip2          = (0x0002 << 16) | 0x1011,
678c677
<       if(ctlr->id == Pnic || ctlr->id == Tulip2){
---
>       if(ctlr->id == Pnic){
727c726
<       if(ctlr->id == Pnic || ctlr->id == Tulip2){
---
>       if(ctlr->id == Pnic){
1391c1390
<       if(ctlr->id == Pnic || ctlr->id == Tulip2){
---
>       if(ctlr->id == Pnic){
1515d1513
<               case Tulip2:            /* 2104x */
1555d1552
<               case Tulip2:

We decided to try this as a simple hack before we noticed that the OS
wasn't seeing PCI devices at all. Our /dev/pci directory is completely
empty! and we do mean dead empty, not even the VGA card was noted in the
pci list, despite that we have video running at 1600x1024.

So the next step, we sprinkled some diagnostic code throughout pci.c and
noticed that we are getting failures in the pcilscan() routine.

for the inner loop of that function, we added

        tbdf = MKBUS(BusPCI, bno, dno, fno);
            l = pcicfgrw32(tbdf, PciVID, 0, 1);
            if(l == 0xFFFFFFFF || l == 0) {
                print("pcicfgrw32 error %d\n", l);
                continue;
            }

with this snippet, pcicfgrw32() consistently returns -1 for every bus(0-7)
and every device(0-15).

we then added the following code to pcicfgrw32()

    if(BUSDNO(tbdf) > pcimaxdno) {
        print("BUSDNO(%d) failed!\n", tbdf);
        return x;
    }

and this message was never printed, indicating the -1 was read from the
port.

We also tried adding the following attribute to the plan9.ini file without
success.

*nobios=1

We speculate the bug is in the inl() code, but we don't know enough about
PCI to debug this. (Both Windows and Linux have no problem seeing the PCI
and the Ethernet card in the vm).


below is the boot text. All you 9gods out there,
would you please shed some light on this? thank you.

jake & north_



MBR...PBS...Plan 9 from Bell Labs
ELCR: 0A00
apm ax=f000 cx=f000 dx=40 di=1200 ebx=a519 esi=3e6
dev A0 port 1F0 config 045A capabilities 0F00 mwdma 0407
dev A0 port 170 config 85A0 capabilities 0300 mwdma 0000
using sdC0!9fat!plan9.ini
found 9PCDISK .    attr 0x0 start 0x702 len 1743030
....742283.........................................................................
....................+674324........................................................
.............................+76940=1493547
entry: 0x80100020
cpu0: 533MHz ConnectixCPU PentiumIII/Xeon (cpuid: AX 0x0684 DX 0x80A1FB)
ELCR: 0A00
dev A0 port 1F0 config 045A capabilities 0F00 mwdma 0407 dma 00000004 rwm
16
dev A0 port 170 config 85A0 capabilities 0300 mwdma 0000 dma 00000000 rwm
0
19379 free pages, 77516K bytes, 311116K swap
root is from (il, local)[local!#S/sdC0/fs]: