Troubleshooting VGA under qemu?
Hello, I have tried running ofw without BIOS (as per http://www.openfirmware.info/Building_OFW_for_QEMU) and it seems that VGA support does not work. I am using config-virtualbox.fth as advised. I have uncommented "console-serial" in config.fth to be able to interact with the console and run: qemu-system-i386 -m 32 -bios emuofw.rom -hda fat:. -serial stdio (this qemu 2.4.0 on FreeBSD/amd64) "show-devs" reports (this is with video.fc included) ok show-devs /cpus /dropin-fs /flash@fff80000 /pci /dropin-fs /mmu /memory@0 /aliases /options /openprom /chosen /packages /cpus/cpu@0 /pci/ethernet@3 /pci/display@2 /pci/pci8086,7113@1,3 /pci/pci-ide@1,1 /pci/host@0 /pci/isa@1 /pci/pci-ide@1,1/ide@1 /pci/pci-ide@1,1/ide@0 /pci/pci-ide@1,1/ide@1/cdrom@0 /pci/pci-ide@1,1/ide@0/disk@0 /pci/isa@1/ide-controller@i1f0 /pci/isa@1/sound@i220 /pci/isa@1/rtc@i70 /pci/isa@1/8042@i60 /pci/isa@1/fdc@i3f0 /pci/isa@1/parallel@i378 /pci/isa@1/serial@i2f8 /pci/isa@1/serial@i3f8 /pci/isa@1/timer@i40 /pci/isa@1/interrupt-controller@i20 /pci/isa@1/dma-controller@i00 /pci/isa@1/ide-controller@i1f0/ide@1 /pci/isa@1/ide-controller@i1f0/ide@0 /pci/isa@1/ide-controller@i1f0/ide@0/<Unnamed>@0 /pci/isa@1/8042@i60/mouse@aux /pci/isa@1/8042@i60/keyboard@kbd /pci/isa@1/fdc@i3f0/disk /packages/http /packages/tcp ... I have tried uncommenting in: ${BP}/dev/video/build/video.fc in cpu/x86/pc/emu/emuofw.bth as well as uncommenting create use-vga in cpu/x86/pc/emu/config.fth, none of which improves the situation. When I switch consoles in qemu the VGA screen says "Guest has not initialized the display (yet)" Any hints to troubleshoot this? Additional questions: 1) Would that be possible to have a dual-console mode (similar to what FreeBSD early bootloader has) so that both vga and serial console are active? ofw prints messages on the serial console even if disabled, only input is not working. 2) Initially I thought ofw is completely dead and I have run it under gdb, only to figure out I am running in the Forth inner interpreter: 0xff9fc000: lods %ds:(%esi),%eax => 0xff9fc001: jmp *(%eax) Is there any way to have "symbol table" to map word addresses to the word names? (I figured out I can tick the word to get its address). Thank you, Marcin
On Wed, 30 Sep 2015, Marcin Cieslak wrote:
Hello,
I have tried running ofw without BIOS (as per http://www.openfirmware.info/Building_OFW_for_QEMU) and it seems that VGA support does not work.
So, I got it working. The solution was: Index: cpu/x86/pc/emu/emuofw.bth =================================================================== --- cpu/x86/pc/emu/emuofw.bth (wersja 3782) +++ cpu/x86/pc/emu/emuofw.bth (kopia robocza) @@ -25,6 +25,7 @@ in: ${BP}/dev/video/build/vmsvga.fc in: ${BP}/dev/ne2000/build/ne2kpci.fc in: ${BP}/dev/amd79970/build/vmlance.fc +in: ${BP}/dev/video/build/bga.fc \ in: ${BP}/dev/video/build/video.fc in: ${BP}/cpu/x86/pc/biosload/linux.fth @@ -58,6 +59,7 @@ \ Just use a driver targeted at the specific chipset that QEMU emulates " ${BP}/dev/video/build/cirrus.fc" " pci1013,b8" $add-deflated-dropin " ${BP}/dev/video/build/vmsvga.fc" " pci15ad,405" $add-deflated-dropin + " ${BP}/dev/video/build/bga.fc" " pci1234,1111" $add-deflated-dropin " ${BP}/dev/ne2000/build/ne2kpci.fc" " pci10ec,8029" $add-deflated-dropin " ${BP}/dev/amd79970/build/vmlance.fc" " pci1022,2000" $add-deflated-dropin Newer QEMU offers Bochs VGA adapter ~Marcin
On Wed, Sep 30, 2015 at 10:04:36AM +0000, Marcin Cieslak wrote:
1) Would that be possible to have a dual-console mode (similar to what FreeBSD early bootloader has) so that both vga and serial console are active? ofw prints messages on the serial console even if disabled, only input is not working.
I'm surprised serial console doesn't take input, but I haven't used OFW for QEMU for a long time. Add ofw/core/muxdev.fth to build?
2) Initially I thought ofw is completely dead and I have run it under gdb, only to figure out I am running in the Forth inner interpreter:
0xff9fc000: lods %ds:(%esi),%eax => 0xff9fc001: jmp *(%eax)
Is there any way to have "symbol table" to map word addresses to the word names? (I figured out I can tick the word to get its address).
Nothing obvious springs to mind. A variant of "words" that prints addresses? A replacement of ":" that prints name and address during build? On Wed, Sep 30, 2015 at 11:53:46AM +0000, Marcin Cieslak wrote:
So, I got it working.
The solution was:
Index: cpu/x86/pc/emu/emuofw.bth =================================================================== --- cpu/x86/pc/emu/emuofw.bth (wersja 3782) +++ cpu/x86/pc/emu/emuofw.bth (kopia robocza) @@ -25,6 +25,7 @@ in: ${BP}/dev/video/build/vmsvga.fc in: ${BP}/dev/ne2000/build/ne2kpci.fc in: ${BP}/dev/amd79970/build/vmlance.fc +in: ${BP}/dev/video/build/bga.fc \ in: ${BP}/dev/video/build/video.fc in: ${BP}/cpu/x86/pc/biosload/linux.fth
@@ -58,6 +59,7 @@ \ Just use a driver targeted at the specific chipset that QEMU emulates " ${BP}/dev/video/build/cirrus.fc" " pci1013,b8" $add-deflated-dropin " ${BP}/dev/video/build/vmsvga.fc" " pci15ad,405" $add-deflated-dropin + " ${BP}/dev/video/build/bga.fc" " pci1234,1111" $add-deflated-dropin
" ${BP}/dev/ne2000/build/ne2kpci.fc" " pci10ec,8029" $add-deflated-dropin " ${BP}/dev/amd79970/build/vmlance.fc" " pci1022,2000" $add-deflated-dropin
Newer QEMU offers Bochs VGA adapter
Thanks. Want me to commit? Do you happen to know which version of QEMU switched to Bochs? -- James Cameron http://quozl.linux.org.au/
On Wed, 30 Sep 2015, James Cameron wrote:
On Wed, Sep 30, 2015 at 10:04:36AM +0000, Marcin Cieslak wrote:
1) Would that be possible to have a dual-console mode (similar to what FreeBSD early bootloader has) so that both vga and serial console are active? ofw prints messages on the serial console even if disabled, only input is not working. Newer QEMU offers Bochs VGA adapter
Thanks. Want me to commit?
Would be good!
Do you happen to know which version of QEMU switched to Bochs?
No idea. One can switch VGA adapters with -vga switch: -vga std -> Bochs adapter (1234:1111), seems to be the default -vga cirrus -> Cirrus (1013:00b8), also works -vga vmware -> VMWare (15ad:404) - DOES NOT WORK 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 Regarding "silent serial" problem - it occurs when "serial-console" is not defined and the VGA adapter does not attach (as it is the case for vmware now): One gets on the serial console this output: Install console Can't open output device. Generic PC, Serial #0, 32 MiB memory installed but ofw continues to print to the serial device as it did before, which is good. Maybe "Install console" step should still probe for the input device even if the output is broken? ~Marcin
On Wed, 30 Sep 2015, Marcin Cieslak wrote:
One gets on the serial console this output:
Install console Can't open output device. Generic PC, Serial #0, 32 MiB memory installed
This one was easy... input-device keyboard is active so one just needs to type "blindly" at the "AT keyboard" (in the QEMU graphical window) and the output goes to the serial console. Maybe using fallback devices would be less surprising, but this is not a bug. Marcin
On Wed, Sep 30, 2015 at 01:31:31PM +0000, Marcin Cieslak wrote:
On Wed, 30 Sep 2015, James Cameron wrote:
On Wed, Sep 30, 2015 at 10:04:36AM +0000, Marcin Cieslak wrote:
1) Would that be possible to have a dual-console mode (similar to what FreeBSD early bootloader has) so that both vga and serial console are active? ofw prints messages on the serial console even if disabled, only input is not working. Newer QEMU offers Bochs VGA adapter
Thanks. Want me to commit?
Would be good!
Applied, r3784. r1059 was addition of VMware SVGA driver.
Do you happen to know which version of QEMU switched to Bochs?
No idea. One can switch VGA adapters with -vga switch:
-vga std -> Bochs adapter (1234:1111), seems to be the default
For me, on Ubuntu Trusty with qemu-2.0.0+dfsg, cirrus is the default.
-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? 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. 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. ;-) Another way to diagnose might be to add printf's to the qemu driver. You might also try bisecting. The VMware SVGA driver is closely connected to fb8, and there have been several changes to fb8 since the driver was added; maybe one of those broke something. Hope that all helps. -- Forthmacs Type 'i' to interrupt stand-init sequence First stand-init: Exceptions CIF DHCP init memory node Probing memory MMU Reclaim dictionary PCI host bridge ISA Calibrating millisecond timer RTC CPU nodes Keyboard overrides Sound Probe IDE Unimplemented package interface procedure nvramrc Probing probe-pci USB2 devices: USB1 devices: Install console Can't open output device. Generic PC, Serial #0, 128 MiB memory installed Open Firmware Copyright 1999 FirmWorks All Rights Reserved Open Firmware demonstration version by FirmWorks (info@firmworks.com) Type any key to interrupt automatic startup 2 ok com1 io ok true to scrolling-debug? ok dev /display ok debug init Stepper keys: <space> Down Up Continue Forth Go Help ? See $tring Quit ok dend ok select /display : init ( Empty ) map-regs d : map-regs ( Empty ) 0 Inside map-regs ( 0 ) 0 Inside map-regs ( 0 0 ) my-space Inside map-regs ( 0 0 1000 ) h# 1000010 Inside map-regs ( 0 0 1000 1000010 ) + Inside map-regs ( 0 0 1001010 ) h# 10 Inside map-regs ( 0 0 1001010 10 ) " map-in" Inside map-regs ( 0 0 1001010 10 ff89566d 6 ) $call-parent Inside map-regs ( fffffff0 ) to regs u [ Up to init ] Inside init ( Empty ) detect-version d : detect-version ( Empty ) h# 90000002 Inside detect-version ( 90000002 ) dup Inside detect-version ( 90000002 90000002 ) 0 Inside detect-version ( 90000002 90000002 0 ) reg! Inside detect-version ( 90000002 ) 0 Inside detect-version ( 90000002 0 ) reg@ Inside detect-version ( 90000002 ffffffff ) = -- James Cameron http://quozl.linux.org.au/
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
On Thu, 1 Oct 2015, James Cameron wrote:
-vga vmware -> VMWare (15ad:404) - DOES NOT WORK
For me, "-vga vmware" reproduces your problem.
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. ;-)
This was easy - changing "key?" in fw.fth to "true" and commenting out the delay - it just sits there and waits (for 'i' or otherwise). Fortunately I could just "dev /pci" and "debug assign-all-addresses" and then just resume. In the end I have just added "debug-me" there. Forth Lesson #15! Fantastic tutorial. The problem is that vwvga driver does not have a "reg" property describing its BARs. Not sure when (or how?) it ever worked. Maybe we should add a warning (with diag-switch? true or otherwise: =================================================================== --- dev/pcibus.fth (wersja 3784) +++ dev/pcibus.fth (kopia robocza) @@ -1183,7 +1183,8 @@ 4 ( increment ) then ( increment ) +loop - + else + " reg property missing!" diag-type-cr then r> finish-aa-property ; Marcin
On Thu, 1 Oct 2015, James Cameron wrote:
-vga vmware -> VMWare (15ad:404) - DOES NOT WORK
For me, "-vga vmware" reproduces your problem.
So, I got a bit further, although I am still puzzled a bit. It seems like the registers do not work initially, the first mapping of the fifo area causes a Page Fault. However, if you never check for the magic value in the register 0 AND initialize the driver again - things magically start to work! The first virtual mapping of fifo ffc00000 causes a segfault, but the next one works (fifo@ffbf0000). After this even "detect-version" works. Qemu complains on stderr about bad depth: vmsvga_value_write: Bad bits per pixel: 16 bits but it's harmless because we switch automatically to a 32 bit depth. This message helped me to realize that we actually start hitting registers at some point. Below is my patch to the tree to get the debug information out and provide more-or-less correct "reg" property. At the bottom a complete transcript of a session. What is a bit special about this device is that we need to map the registers first, then we need to read two values (register 15 and 19) and only then we can determine the sizes of the requested memory areas (actually those values match those in BARs). For now I have just hardcoded those values in the "reg" property, but once we figure out how to get registers work at an early stage those values should be entered into the property. I actually managed to switch console to vmsvga and it worked. Marcin Index: dev/pcibus.fth =================================================================== --- dev/pcibus.fth (wersja 3784) +++ dev/pcibus.fth (kopia robocza) @@ -14,8 +14,8 @@ defer setup-fcodes ( -- ) ' noop to setup-fcodes defer restore-fcodes ( -- ) ' noop to restore-fcodes -false value pcimsg? \ Optional Debug Msgs -false value probemsg? \ Optional Probing Msgs +true value pcimsg? \ Optional Debug Msgs +true value probemsg? \ Optional Probing Msgs \ The default value for first-io skips the area where built-in ISA \ devices normally live, but stays below 64K, in order to work with @@ -1183,7 +1183,8 @@ 4 ( increment ) then ( increment ) +loop - + else + " reg property missing!" diag-type-cr then r> finish-aa-property ; Index: dev/video/controlr/vmsvga.fth =================================================================== --- dev/video/controlr/vmsvga.fth (wersja 3784) +++ dev/video/controlr/vmsvga.fth (kopia robocza) @@ -95,6 +95,8 @@ /fb 0 my-space h# 0200.0018 + /fifo " map-in" $call-parent to fifo then 3 my-space h# 04 + " config-w!" $call-parent + cr ." map-mem: fifo@" fifo . ." size= " /fifo . + cr ." map-mem: fb@" frame-buffer-adr . ." size= " /fb . ; : unmap-regs ( -- ) regs h# 10 " map-out" $call-parent ; : unmap-mem ( -- ) @@ -110,6 +112,8 @@ : fifo-next@ ( -- n ) fifo 2 la+ l@ ; : fifo-next! ( n -- ) fifo 2 la+ l! ; : fifo-stop@ ( -- n ) fifo 3 la+ l@ ; : fifo-stop! ( n -- ) fifo 3 la+ l! ; +: int+ ( adr len n -- adr' len' ) encode-int encode+ ; + : detect-version ( -- ) h# 9000.0002 dup 0 reg! 0 reg@ = if exit then h# 9000.0001 dup 0 reg! 0 reg@ = if exit then @@ -116,6 +120,23 @@ unmap-regs abort \ We don't support version 0 ; + +: set-reg-property + my-address my-space encode-phys 0 int+ h# 0 int+ + my-address my-space h# 0100.0010 + encode-phys encode+ 0 int+ h# 10 int+ + my-address my-space h# 0200.0014 + encode-phys encode+ 0 int+ h# 1000000 int+ + my-address my-space h# 0200.0018 + encode-phys encode+ 0 int+ h# 10000 int+ + " reg" property +; + +: probe ( -- ) + \ map-regs + \ map-mem + set-reg-property + \ unmap-mem + \ unmap-regs +; + : init-fb ( -- ) depth 7 reg! 7 reg@ depth <> if 7 reg@ to depth then @@ -249,7 +270,7 @@ : init ( -- ) map-regs - detect-version + \ detect-version map-mem init-fb init-fifo Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (wersja 3784) +++ dev/video/vmsvga.bth (kopia robocza) @@ -12,6 +12,7 @@ " display" device-name fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe end0 ---------------------end----------------------------- ------------------- output begin -------------------- Script started on Thu Oct 1 15:30:31 2015 command: qemu-system-i386 -m 32 -bios /var/tmp/openfirmware/cpu/x86/pc/emu/build/emuofw.rom -hda fat:/var/tmp/openfirmware/cpu/x86/pc/emu/build -serial stdio -vga vmware vvfat /var/tmp/openfirmware/cpu/x86/pc/emu/build chs 1024,16,63 WARNING: Image format was not specified for 'json:{"fat-type": 0, "dir": "/var/tmp/openfirmware/cpu/x86/pc/emu/build", "driver": "vvfat", "floppy": false, "rw": false}' and probing guessed raw. Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted. Specify the 'raw' format explicitly to remove the restrictions. Forthmacs Type 'i' to interrupt stand-init sequence First stand-init: Exceptions CIF DHCP init memory node Probing memory MMU Reclaim dictionary PCI host bridge ISA Calibrating millisecond timer RTC CPU nodes Pseudo-NVRAM Can't read the configuration memory The configuration memory is invalid. Using default values. Sound Probe IDE Unimplemented package interface procedure nvramrc Probing probe-pci PCI PROBE-SELF: Phys.hi = 0 Checking for built-in FCode match for Vendor:8086 Device:1237 Checking for built-in FCode match... PCI PROBE-SELF: Phys.hi = 800 Checking for built-in FCode match for Vendor:8086 Device:7010 Checking for built-in FCode match... DROPIN CLASS MATCH PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 81000000 0 0 Checking for built-in FCode match for Vendor:8086 Device:7113 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 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 PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001830 0 0 Assigning PCI Space of length 40000 Memory Space... Base Reg: 2001830 = 10040000 Function:8086 Function:100e Non FCode Format ROM Image. Function:8086 Function:100e Non FCode Format ROM Image. Function:8086 Function:100e Non FCode Format ROM Image. Checking for built-in FCode match for Vendor:8086 Device:100e Checking for built-in FCode match... PCI PROBE-SELF: Phys.hi = 2000 Nothing there PCI PROBE-SELF: Phys.hi = 2800 Nothing there PCI PROBE-SELF: Phys.hi = 3000 Nothing there PCI PROBE-SELF: Phys.hi = 3800 Nothing there PCI PROBE-SELF: Phys.hi = 4000 Nothing there PCI PROBE-SELF: Phys.hi = 4800 Nothing there PCI PROBE-SELF: Phys.hi = 5000 Nothing there PCI PROBE-SELF: Phys.hi = 5800 Nothing there PCI PROBE-SELF: Phys.hi = 6000 Nothing there PCI PROBE-SELF: Phys.hi = 6800 Nothing there PCI PROBE-SELF: Phys.hi = 7000 Nothing there PCI PROBE-SELF: Phys.hi = 7800 Nothing there PCI PROBE-SELF: Phys.hi = 8000 Nothing there PCI PROBE-SELF: Phys.hi = 8800 Nothing there PCI PROBE-SELF: Phys.hi = 9000 Nothing there PCI PROBE-SELF: Phys.hi = 9800 Nothing there PCI PROBE-SELF: Phys.hi = a000 Nothing there PCI PROBE-SELF: Phys.hi = a800 Nothing there PCI PROBE-SELF: Phys.hi = b000 Nothing there PCI PROBE-SELF: Phys.hi = b800 Nothing there PCI PROBE-SELF: Phys.hi = c000 Nothing there PCI PROBE-SELF: Phys.hi = c800 Nothing there PCI PROBE-SELF: Phys.hi = d000 Nothing there PCI PROBE-SELF: Phys.hi = d800 Nothing there PCI PROBE-SELF: Phys.hi = e000 Nothing there PCI PROBE-SELF: Phys.hi = e800 Nothing there PCI PROBE-SELF: Phys.hi = f000 Nothing there PCI PROBE-SELF: Phys.hi = f800 Nothing there Assigning PCI Space of length 10 I/O Space... Base Reg: 1000920 = 8000 Assigning PCI Space of length 10 I/O Space... Base Reg: 1001010 = 8010 Assigning PCI Space of length 1000000 Memory Space... Base Reg: 2001014 = 10000000 Assigning PCI Space of length 10000 Memory Space... Base Reg: 2001018 = 11000000 Assigning PCI Space of length 20000 Memory Space... Base Reg: 2001810 = 11020000 Assigning PCI Space of length 40 I/O Space... Base Reg: 1001814 = 8040 USB2 devices: USB1 devices: Install console Generic PC, Serial #0, 32 MiB memory installed Open Firmware Copyright 1999 FirmWorks All Rights Reserved Open Firmware demonstration version by FirmWorks (info@firmworks.com) Type any key to interrupt automatic startup 6 5 4 3 2 ok select /pci/display@2 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1001010 0 0 PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001014 0 0 PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001018 0 0 map-mem: fifo@ffc00000 size= 10000 map-mem: fb@ffc00000 size= 1000000 vmsvga_value_write: Bad bits per pixel: 16 bits Page Fault ok dev /pci/display@2 ok 0 reg@ . 90000002 ok select /pci/display@2 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1001010 0 0 PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001014 0 0 PCI-MAP-IN: Bus: 0 , MEM, PCI PHYS.HI..LO = 2001018 0 0 map-mem: fifo@ffbf0000 size= 10000 map-mem: fb@fe800000 size= 1000000 vmsvga_value_write: Bad bits per pixel: 16 bits ok use-ks PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 81000000 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1000920 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 81000000 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1000920 0 0 input-device = keyboard PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 81000000 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1000920 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 81000000 0 0 PCI-MAP-IN: Bus: 0 , I/O, PCI PHYS.HI..LO = 1000920 0 0 output-device = screen ok install-console ok power-off Script done on Thu Oct 1 15:31:56 2015
On Thu, 1 Oct 2015, James Cameron wrote:
-vga vmware -> VMWare (15ad:404) - DOES NOT WORK
For me, "-vga vmware" reproduces your problem.
I think I have this solved with the following patch: Log: Fix VMWare VGA adapter * Send command to the PCI command port to inform the device that I/O port has been enabled. * Issue a warning during PCI resouce allocation if "reg" property has not been provided (with diag-switch? true). * Generate "reg" property for the PCI resource allocator: ok dev /display ok .properties linebytes 00001000 depth 00000020 height 00000300 width 00000400 assigned-addresses 81001010 00000000 00008010 00000000 00000010 82001014 00000000 10000000 00000000 01000000 82001018 00000000 11000000 00000000 00010000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000010 02001014 00000000 00000000 00000000 01000000 02001018 00000000 00000000 00000000 00010000 iso6429-1983-colors character-set ISO8859-1 device_type display name display devsel-speed 00000000 class-code 00030000 subsystem-vendor-id 000015ad subsystem-id 00000405 max-latency 00000000 min-grant 00000000 revision-id 00000000 device-id 00000405 vendor-id 000015ad Index: dev/pcibus.fth =================================================================== --- dev/pcibus.fth (wersja 3784) +++ dev/pcibus.fth (kopia robocza) @@ -1183,7 +1183,8 @@ 4 ( increment ) then ( increment ) +loop - + else + " reg property missing!" diag-type-cr then r> finish-aa-property ; Index: dev/video/controlr/vmsvga.fth =================================================================== --- dev/video/controlr/vmsvga.fth (wersja 3784) +++ dev/video/controlr/vmsvga.fth (kopia robocza) @@ -85,6 +85,9 @@ h# 200.0000 instance value /mem : map-regs ( -- ) 0 0 my-space h# 0100.0010 + h# 10 " map-in" $call-parent to regs + my-space h# 04 + + dup " config-w@" $call-parent + 1 or swap " config-w!" $call-parent ; : map-mem ( -- ) my-space h# 14 + " config-l@" $call-parent if @@ -116,6 +119,23 @@ unmap-regs abort \ We don't support version 0 ; + +: int+ ( adr len n -- adr' len' ) encode-int encode+ ; + +: set-reg-property + my-address my-space encode-phys 0 int+ h# 0 int+ + my-address my-space h# 0100.0010 + encode-phys encode+ 0 int+ h# 10 int+ + my-address my-space h# 0200.0014 + encode-phys encode+ 0 int+ /fb int+ + my-address my-space h# 0200.0018 + encode-phys encode+ 0 int+ /fifo int+ + " reg" property +; + +: probe ( -- ) + map-regs + set-reg-property + unmap-regs +; + : init-fb ( -- ) depth 7 reg! 7 reg@ depth <> if 7 reg@ to depth then Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (wersja 3784) +++ dev/video/vmsvga.bth (kopia robocza) @@ -12,6 +12,7 @@ " display" device-name fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe end0
Thanks. Some quick thoughts; On Thu, Oct 01, 2015 at 09:26:02PM +0000, Marcin Cieslak wrote:
--- dev/video/controlr/vmsvga.fth (wersja 3784) +++ dev/video/controlr/vmsvga.fth (kopia robocza) @@ -85,6 +85,9 @@ h# 200.0000 instance value /mem : map-regs ( -- ) 0 0 my-space h# 0100.0010 + h# 10 " map-in" $call-parent to regs + my-space h# 04 + + dup " config-w@" $call-parent + 1 or swap " config-w!" $call-parent ;
Suggest borrowing my-w@ and my-w! from other drivers instead : my-w@ ( offset -- w ) my-space + " config-w@" $call-parent ; : my-w! ( w offset -- ) my-space + " config-w!" $call-parent ; : map-regs ( -- ) 0 0 my-space h# 0100.0010 + h# 10 " map-in" $call-parent to regs 4 my-w@ 1 or 4 my-w! ; Several other drivers also impose a symmetry and undo in unmap-regs 4 my-w@ 1 invert and 4 my-w! Is needed?
: map-mem ( -- ) my-space h# 14 + " config-l@" $call-parent if @@ -116,6 +119,23 @@ unmap-regs abort \ We don't support version 0 ; + +: int+ ( adr len n -- adr' len' ) encode-int encode+ ; + +: set-reg-property + my-address my-space encode-phys 0 int+ h# 0 int+ + my-address my-space h# 0100.0010 + encode-phys encode+ 0 int+ h# 10 int+ + my-address my-space h# 0200.0014 + encode-phys encode+ 0 int+ /fb int+ + my-address my-space h# 0200.0018 + encode-phys encode+ 0 int+ /fifo int+ + " reg" property +;
Most other drivers set this property at load time outside the colon definitions; is there a reason for doing it after map-regs?
+ +: probe ( -- ) + map-regs + set-reg-property + unmap-regs +; + : init-fb ( -- ) depth 7 reg! 7 reg@ depth <> if 7 reg@ to depth then
-- James Cameron http://quozl.linux.org.au/
On Fri, 2 Oct 2015, James Cameron wrote:
Thanks.
Some quick thoughts;
Suggest borrowing my-w@ and my-w! from other drivers instead
done
Several other drivers also impose a symmetry and undo in unmap-regs
done
Is needed?
not sure, it works. Only right now qemu reports 4x more PCI remappings done
+: set-reg-property + my-address my-space encode-phys 0 int+ h# 0 int+ + my-address my-space h# 0100.0010 + encode-phys encode+ 0 int+ h# 10 int+ + my-address my-space h# 0200.0014 + encode-phys encode+ 0 int+ /fb int+ + my-address my-space h# 0200.0018 + encode-phys encode+ 0 int+ /fifo int+ + " reg" property +;
Most other drivers set this property at load time outside the colon definitions; is there a reason for doing it after map-regs?
That's a whole point here - /fb and /fifo are taken from the mapped registers. Some other video drivers have a more sophisticated machinery to construct that property - encode-reg-property, >reg-props Unfortunately I cannot test it on a real "hardware", i.e. under VMware :) Marcin Index: dev/pcibus.fth =================================================================== --- dev/pcibus.fth (revision 3784) +++ dev/pcibus.fth (working copy) @@ -1183,7 +1183,8 @@ 4 ( increment ) then ( increment ) +loop - + else + " reg property missing!" diag-type-cr then r> finish-aa-property ; Index: dev/video/controlr/vmsvga.fth =================================================================== --- dev/video/controlr/vmsvga.fth (revision 3784) +++ dev/video/controlr/vmsvga.fth (working copy) @@ -39,6 +39,9 @@ : reg@ ( index -- value ) regs rl! regs 1+ rl@ ; : reg! ( value index -- ) regs rl! regs 1+ rl! ; +: my-w@ ( offset -- w ) my-space + " config-w@" $call-parent ; +: my-w! ( w offset -- ) my-space + " config-w!" $call-parent ; + \ Here are the register numbers. Most of these registers are \ accessed only once, so I don't define access words for many of them. \ (W) means that it is meaningful for you to write to this register @@ -85,6 +88,7 @@ h# 200.0000 instance value /mem : map-regs ( -- ) 0 0 my-space h# 0100.0010 + h# 10 " map-in" $call-parent to regs + 4 my-w@ 1 or 4 my-w! ; : map-mem ( -- ) my-space h# 14 + " config-l@" $call-parent if @@ -94,12 +98,16 @@ 0 0 my-space h# 0200.0018 + /fb " map-in" $call-parent to frame-buffer-adr /fb 0 my-space h# 0200.0018 + /fifo " map-in" $call-parent to fifo then - 3 my-space h# 04 + " config-w!" $call-parent + 4 my-w@ 2 or 4 my-w! ; -: unmap-regs ( -- ) regs h# 10 " map-out" $call-parent ; +: unmap-regs ( -- ) + regs h# 10 " map-out" $call-parent + 4 my-w@ 1 invert and 4 my-w! +; : unmap-mem ( -- ) fifo /fifo " map-out" $call-parent frame-buffer-adr /fb " map-out" $call-parent + 4 my-w@ 2 invert and 4 my-w! ; \ Min and Max are the static limits of the FIFO area. @@ -116,6 +124,23 @@ unmap-regs abort \ We don't support version 0 ; + +: int+ ( adr len n -- adr' len' ) encode-int encode+ ; + +: set-reg-property + my-address my-space encode-phys 0 int+ h# 0 int+ + my-address my-space h# 0100.0010 + encode-phys encode+ 0 int+ h# 10 int+ + my-address my-space h# 0200.0014 + encode-phys encode+ 0 int+ /fb int+ + my-address my-space h# 0200.0018 + encode-phys encode+ 0 int+ /fifo int+ + " reg" property +; + +: probe ( -- ) + map-regs + set-reg-property + unmap-regs +; + : init-fb ( -- ) depth 7 reg! 7 reg@ depth <> if 7 reg@ to depth then Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (revision 3784) +++ dev/video/vmsvga.bth (working copy) @@ -12,6 +12,7 @@ " display" device-name fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe end0 Service unavailableService unavailableService unavailable
Summary: probe in .bth stops build? On Thu, Oct 01, 2015 at 10:36:24PM +0000, Marcin Cieslak wrote:
On Fri, 2 Oct 2015, James Cameron wrote:
Thanks.
Some quick thoughts;
Suggest borrowing my-w@ and my-w! from other drivers instead
done
Looks fine.
Several other drivers also impose a symmetry and undo in unmap-regs
done
Looks fine.
Is needed?
not sure, it works. Only right now qemu reports 4x more PCI remappings done
+: set-reg-property [...]
Most other drivers set this property at load time outside the colon definitions; is there a reason for doing it after map-regs?
That's a whole point here - /fb and /fifo are taken from the mapped registers.
Some other video drivers have a more sophisticated machinery to construct that property - encode-reg-property, >reg-props
Thanks.
Unfortunately I cannot test it on a real "hardware", i.e. under VMware :)
Nor I.
[...] Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (revision 3784) +++ dev/video/vmsvga.bth (working copy) @@ -12,6 +12,7 @@ " display" device-name
fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe
end0
Is this the right place for probe? The build now pauses in the builder; host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make clean) rm -f *.dic *.log headers *~ *.elf *.di *.img builton.fth build *.c32 *.rom host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make) ./build emuofw.rom --- Rebuilding rmreset.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmreset.bth --- Rebuilding pmreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../pmreset.bth --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.img --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth Page Fault ok ftrace @ Called from fdavail? at 5575ac58 0 fdavail? Called from fclose at 5575b09c 868278c execute Called from interpret-do-defined at 5575804c do-defined Called from $compile at 55757ff0 $compile Called from (interpret at 557582b4 interpret Called from interpret-lines at 5575ce08 Catch frame - SP: 55869058 my-self: 0 handler: 55868880 catch Called from include-file at 5575cf3c 47 8685880 44 86826f8 5 0 include-file Called from (included) at 5575d064 Catch frame - SP: 55869070 my-self: 0 handler: 55868878 catch Called from included at 5575d08c included Called from process-argument at 5575d5d0 Catch frame - SP: 558166b8 my-self: 0 handler: 55868878 catch Called from process-command-line at 5575d630 process-command-line Called from cold at 5575b6b4 ok -- James Cameron http://quozl.linux.org.au/
On Fri, 2 Oct 2015, James Cameron wrote:
Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (revision 3784) +++ dev/video/vmsvga.bth (working copy) @@ -12,6 +12,7 @@ " display" device-name
fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe
end0
Is this the right place for probe? The build now pauses in the builder;
host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make clean) rm -f *.dic *.log headers *~ *.elf *.di *.img builton.fth build *.c32 *.rom host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make) ./build emuofw.rom --- Rebuilding rmreset.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmreset.bth --- Rebuilding pmreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../pmreset.bth --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.img --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth Page Fault
That's strange! On my system "probe" is executed as soon the kernel tries to load fcode from devices' ROM. I have no idea how the build system works, I just copied it from bga.bth Is bga (Bochs Adapter, -vga std) working for you? I think that begin-tokenizing ... end-tokenizing should protect us from execution? ~Marcin
On Fri, Oct 02, 2015 at 08:01:22AM +0000, Marcin Cieslak wrote:
On Fri, 2 Oct 2015, James Cameron wrote:
Index: dev/video/vmsvga.bth =================================================================== --- dev/video/vmsvga.bth (revision 3784) +++ dev/video/vmsvga.bth (working copy) @@ -12,6 +12,7 @@ " display" device-name
fload ${BP}/dev/video/controlr/vmsvga.fth \ VMware-specific words +probe
end0
Is this the right place for probe? The build now pauses in the builder;
host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make clean) rm -f *.dic *.log headers *~ *.elf *.di *.img builton.fth build *.c32 *.rom host:~/openfirmware$ (cd cpu/x86/pc/emu/build; make) ./build emuofw.rom --- Rebuilding rmreset.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmreset.bth --- Rebuilding pmreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../pmreset.bth --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.img --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth Page Fault
That's strange!
My fault. I had built on my 64-bit host rather than my 32-bit schroot container. -- James Cameron http://quozl.linux.org.au/
On Fri, 2 Oct 2015, James Cameron wrote:
On Fri, Oct 02, 2015 at 08:01:22AM +0000, Marcin Cieslak wrote:
--- Rebuilding rmreset.img --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../rmreset.bth --- Rebuilding pmreset.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../pmreset.bth --- Rebuilding paging.di --- Cmd: ${HOSTDIR}/forth ${HOSTDIR}/../build/builder.dic ../../paging.bth --- Rebuilding fw.img --- Cmd: ${HOSTDIR}/x86forth ${BP}/cpu/x86/build/basefw.dic ../fw.bth Page Fault
That's strange!
My fault.
I had built on my 64-bit host rather than my 32-bit schroot container.
Interesting. On FreeBSD my box -m32 is enough. Using clang, by the way. Marcin
Summary: tested, missing some change box. I've tested your patch with qmeu-2.0.0 and it mostly works. qemu-system-i386 -L . -bios emuofw.rom -hda fat:. -vga vmware But when a burst of text occurs some of the screen is not updated. To reproduce, type show-devs at the ok prompt. See attached window capture. Forcing an X refresh of qemu does not fix. Forcing a screen scroll does fix. Forcing a whole screen change in the Open Firmware driver does fix: ok select /display screen-changed Debugger with serial shows char-changed is being called by vm-draw-character. My guess is that this may be a problem with the qemu-2.0.0 vmware driver, or that the burst of char-changed register writes is lost by qemu. Can you reproduce with later qemu? -- James Cameron http://quozl.linux.org.au/
On Sat, 3 Oct 2015, James Cameron wrote:
Summary: tested, missing some change box.
I've tested your patch with qmeu-2.0.0 and it mostly works.
qemu-system-i386 -L . -bios emuofw.rom -hda fat:. -vga vmware
But when a burst of text occurs some of the screen is not updated. To reproduce, type show-devs at the ok prompt. See attached window capture.
No, everything works here normally. Using either qemu 2.4.0 or qemu git master. Only getting lots of qemu messages when scrolling: vmsvga_update_rect: update height > 768 (y: 112, h: 768) but everything seems to be fine. Can you show me your .properties of the vmware display? Everything is fine with other VGAs (cirrus, std)? Marcin
On Fri, Oct 02, 2015 at 09:37:52PM +0000, Marcin Cieslak wrote:
On Sat, 3 Oct 2015, James Cameron wrote:
Summary: tested, missing some change box.
I've tested your patch with qmeu-2.0.0 and it mostly works.
qemu-system-i386 -L . -bios emuofw.rom -hda fat:. -vga vmware
But when a burst of text occurs some of the screen is not updated. To reproduce, type show-devs at the ok prompt. See attached window capture.
No, everything works here normally. Using either qemu 2.4.0 or qemu git master.
Only getting lots of qemu messages when scrolling:
vmsvga_update_rect: update height > 768 (y: 112, h: 768)
I'm not seeing that.
but everything seems to be fine.
Good.
Can you show me your .properties of the vmware display?
linebytes 00001000 depth 00000020 height 00000300 width 00000400 assigned-addresses 81001010 00000000 00008010 00000000 00000010 82001014 00000000 10000000 00000000 01000000 82001018 00000000 11000000 00000000 00010000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000010 02001014 00000000 00000000 00000000 01000000 02001018 00000000 00000000 00000000 00010000 iso6429-1983-colors character-set ISO8859-1 device_type display name display devsel-speed 00000000 class-code 00030000 subsystem-vendor-id 000015ad subsystem-id 00000405 max-latency 00000000 min-grant 00000000 revision-id 00000000 device-id 00000405 vendor-id 000015ad
Everything is fine with other VGAs (cirrus, std)?
-vga cirrus ... works fine, does not reproduce problem. -vga std ... does not work, with -serial $(tty) can interact with qemu window as input, terminal as output. -- James Cameron http://quozl.linux.org.au/
On Sat, 3 Oct 2015, James Cameron wrote:
Can you show me your .properties of the vmware display?
assigned-addresses 81001010 00000000 00008010 00000000 00000010 82001014 00000000 10000000 00000000 01000000 82001018 00000000 11000000 00000000 00010000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000010 02001014 00000000 00000000 00000000 01000000 02001018 00000000 00000000 00000000 00010000
This is all fine, your resources got allocated. As far as I understand we communicate with vmware VGA via the fifo area (the 02001018 resource, 0x10000 bytes) and maybe this fails somehow (overflows, wraps-around, whatever?)
-vga cirrus ... works fine, does not reproduce problem.
-vga std ... does not work, with -serial $(tty) can interact with qemu window as input, terminal as output.
Can you step over the initalization? Marcin
On Fri, Oct 02, 2015 at 10:37:03PM +0000, Marcin Cieslak wrote:
On Sat, 3 Oct 2015, James Cameron wrote:
Can you show me your .properties of the vmware display?
assigned-addresses 81001010 00000000 00008010 00000000 00000010 82001014 00000000 10000000 00000000 01000000 82001018 00000000 11000000 00000000 00010000 reg 00001000 00000000 00000000 00000000 00000000 01001010 00000000 00000000 00000000 00000010 02001014 00000000 00000000 00000000 01000000 02001018 00000000 00000000 00000000 00010000
This is all fine, your resources got allocated.
As far as I understand we communicate with vmware VGA via the fifo area (the 02001018 resource, 0x10000 bytes) and maybe this fails somehow (overflows, wraps-around, whatever?)
-vga cirrus ... works fine, does not reproduce problem.
-vga std ... does not work, with -serial $(tty) can interact with qemu window as input, terminal as output.
Can you step over the initalization?
Didn't get time to work on this, sorry. Committed r3785. -- James Cameron http://quozl.linux.org.au/
participants (2)
-
James Cameron -
Marcin Cieslak