[openfirmware] Troubleshooting VGA under qemu?

[Marcin Cieslak]

On Thu, 1 Oct 2015, James Cameron wrote:

> Applied, r3784.  r1059 was addition of VMware SVGA driver.

Thanks!

> >  -vga cirrus ->  Cirrus (1013:00b8), also works
> >  -vga vmware -> VMWare (15ad:404) - DOES NOT WORK
> 
> For me, "-vga vmware" reproduces your problem.
> 
> > It seems that FCode gets detected, but the driver
> > does not want to attach:
> > 
> > Assigning PCI Space of length    10000
> > Memory Space...
> >   Base Reg: 2001030  = 11010000 
> >   Function:15ad  Function: 405
> >   Non FCode Format ROM Image. 
> >   Checking for built-in FCode match for 
> >   Vendor:15ad  Device: 405
> >   Checking for built-in FCode match... DROPIN NAME MATCH 
> > PCI PROBE-SELF:  Phys.hi = 1800 
> 
> Where is that output from?

true  value pcimsg?     \ Optional Debug Msgs
true  value probemsg?   \ Optional Probing Msgs

in dev/pcibus.fth

> I've stepped through a second invocation of the driver, and the abort
> 
> in detect-version is hit.
> 
> : detect-version  ( -- )
>    h# 9000.0002 dup 0 reg!  0 reg@ =  if  exit  then
>    h# 9000.0001 dup 0 reg!  0 reg@ =  if  exit  then
>    unmap-regs
>    abort  \ We don't support version 0
> ;
> 
> I've checked my qemu sources, and the id register should return what
> is written to it if the value is h# 9000.0002 but from the log below
> it does not.

Same done here. Qemu code seems correct.

> My guess is something wrong with register mapping ... or the driver
> shouldn't be tried twice.  Next step might be to increase the delay
> for the stand-init interrupt key 'i' ... which I've been unable to
> trigger.  I'm also not sure how to apply the debugger to an FCode
> driver that isn't loaded yet, but that would be a learning exercise.
> ;-)

The problem is here:

Install console
PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1001010  0  0     Probe state is 0 fffffff0 Register 0:0 
Can't open output device.

(Probe state is 0 fffffff0 Register 0:0 is my additional debug output)

Resource 1001010 is the I/O space for registers, which has not been assigned
during "the first invocation" (as you put it) and has not been assigned
later in the assign-all-addresses loop.

"The first invocation" is in find-fcode? where (I think) we hope
to find ROM in the memory space and the FCode in it.. Good luck:

Checking for built-in FCode match... PCI PROBE-SELF:  Phys.hi = 1000 
PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001030  0  0
Assigning PCI Space of length    10000

etc.

Then at least memory resource (all of them?) get initialized 
- this is the  " map-in" $call-parent invocation in find-fcode?

After this we go into normal PCI resource assignement loop
which seems to skip this I/O space for the reason I am
investigating now:

PCI: Assign all-addresses 
PCI assign-package-addresses phys.hi = 800 
PCI assign-package-addresses phys.hi = 0 
PCI assign-package-addresses phys.hi = 900 
PCI assign-address phys.hi 81000010 ... avoided!
PCI assign-address phys.hi 81000014 ... avoided!
PCI assign-address phys.hi 81000018 ... avoided!
PCI assign-address phys.hi 8100001c ... avoided!
PCI assign-address phys.hi 1000920 
PCI (assign-address): Working on: 1000920 
Assigning PCI Space of length       10
I/O Space...
  Base Reg: 1000920  = 8000 
PCI (assign-address): Working on: 1000920 
PCI (assign-address): Already assigned
PCI assign-package-addresses phys.hi = b00 
PCI assign-package-addresses phys.hi = 1800 
PCI assign-address phys.hi 2001810 
PCI (assign-address): Working on: 2001810 
Assigning PCI Space of length    20000
Memory Space...
  Base Reg: 2001810  = 10000000 
PCI assign-address phys.hi 1001814 
PCI (assign-address): Working on: 1001814 
Assigning PCI Space of length       40
I/O Space...
  Base Reg: 1001814  = 8040 
PCI (assign-address): Working on: 2001810 
PCI (assign-address): Already assigned
PCI (assign-address): Working on: 1001814 
PCI (assign-address): Already assigned

So after this the probing ends and the
I/O space never gets assigned.
We should see "Working on: 1001010" somewhere,
probably.

After probing ends, the "map-in" which
we do in the driver does not properly
assign the address - only the port number
is extracted (anded with h# ffff etc.)
and given to rl@, rl!

I traced this with gdb and we indeed
get 0 when asking for data from 
I/O port 0xfff0, which is bogus I think
(rl@ converts 0xfffffff1 stored in
the BAR into 0xfff0 port). At least
qemu has no idea it should respond to this one.

(What worries me a bit if I change
the I/O port manually in the debugger
to 0xfffffff0 we also get zeros, but
maybe PCI I/O devices does not respond
at all to unassigned resources, dunno).

I don't know a lot about PCI but we skip this resource
(1001010) for some reason.

~Marcin