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