strange behaviour of igfx and vesa

strange behaviour of igfx and vesa

[kokamoto]

I'm trying to use 8086/29a2 chip on a desktop terminal.
pci -v says:
0.2.0:	vid  03.00.00 8086/29a2  10 0:fde00000 1048576 2:d000000c 268435456 4:0000ff01 16
	Intel Corporation 82G965 Integrated Graphics Controller

I added that 8086/29a2  entry to /sys/src/9/pc/vgaigfx.c and /sys/src/cmd/aux/vga/igfx.c
and /lib/vgadb.

When I set the /cfg/pxe/xxx file like monitor=s3321wA,
I got blank screen.  I've tried display=0,1,2,3,4,5, and got
the same result.

However, I changed the the file content to:
monitor=vesa, and vgasize=1024x768x8,
and bootup the terminal as usual.

After that, I dispatched the command:
term% aux/vga -m igfx -l 1680x1050x32

Then I got the normal 1680x1050x32 screen on my LCD panel!
Of course, hardware cusor is also working fine.

What's going on here?

Kenji

PS. I'm writing this mail from that terminal.

Re: [9front] strange behaviour of igfx and vesa

[cinap_lenrek]

state. the vesa bios might initialze registers that the igfx
driver misses.

"blank screen" doesnt say much. do you get a stable, but
black screen? or does the screen not even turn on? is the
backlight just off?

you can dump the register contents with aux/vga and compare
native igfx vs vesa + igfx.

this will only catch register differences that igfx knows
about tho.

it is possible to run realemu in trace mode (-p) and log all
the io reads and writes while vesa programs the card. then
sort thru the log to identify registers that the driver doesnt
know about.

i'v written some scripts to decode realemu bios traces that
you could adapt for your card:

http://felloff.net/usr/cinap_lenrek/igdump.tar

you certanly have to change the port offsets for the banked
address/data register in mmio.awk (check the io bar of
the graphics card of your system)

in any case, make a realemu trace (from the initial no-graphics
state). so we get a real detailed programming sequence for the
card that is known to work. once we have that, it is possibe
to figure out what we are missing or where igfx diverges.

dont run the realemu trace when grapics is already running.
because vesa might skip initialization of registers that have
already been programmed, so you'll not catch the missing bits.

--
cinap

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

> state. the vesa bios might initialze registers that the igfx
> driver misses.
> 
> http://felloff.net/usr/cinap_lenrek/igdump.tar

I'll try this.

However, I have a memory of ducument that says somthing about
the value which you use port# of "2" like:
		switch(x){
		case PortVGA:
			vga->edid[x] = snarfgmedid(igfx, 2, 0x50);
			break;
in snarf() function. 

The document has a table which says individual chip has a different 
port number for a same PortVGA...
My memory goes bad these days, however, I think you can find it
from Intel's support site which was a short paged one.

I may be wrong, however, the behaviour suggests it, I suppose.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

[-- Attachment #1: Type: text/plain, Size: 2872 bytes --]

> you can dump the register contents with aux/vga and compare
> native igfx vs vesa + igfx.
> 
> this will only catch register differences that igfx knows
> about tho.

I did this, and the vga dump of aux/vga -l 1680x1050x32 for
bare igfx device is attached.
The diff of
#term diff (igfx on vesa dump) (bare igfx)
is as follows:
I don't see any serious problems...
In case bare igfx, monitor=s2231wA is defined, in the the other
not.
--------from here-----
5c5
< vga sequencer        03 21 0F 00 0E
---
> vga sequencer        03 00 03 00 02
8c8
< vga graphics         00 00 00 00 00 00 05 0F - FF
---
> vga graphics         00 00 00 00 00 10 0E 00 - FF
15c15
< igfx pipe a src      [0006001c] = 03ff02ff
---
> igfx pipe a src      [0006001c] = 027f01df
21,26c21,26
< igfx pipe a ht       [00060000] = 053f03ff
< igfx pipe a hb       [00060004] = 053f03ff
< igfx pipe a hs       [00060008] = 049f0417
< igfx pipe a vt       [0006000c] = 032502ff
< igfx pipe a vb       [00060010] = 032502ff
< igfx pipe a vs       [00060014] = 03080302
---
> igfx pipe a ht       [00060000] = 031f027f
> igfx pipe a hb       [00060004] = 03170287
> igfx pipe a hs       [00060008] = 02ef028f
> igfx pipe a vt       [0006000c] = 020c01df
> igfx pipe a vb       [00060010] = 020401e7
> igfx pipe a vs       [00060014] = 01eb01e9
28c28
< igfx dsp a cntr      [00070180] = c8000000
---
> igfx dsp a cntr      [00070180] = 48000000
30c30
< igfx dsp a stride    [00070188] = 00000400
---
> igfx dsp a stride    [00070188] = 00000280
57,58c57,58
< igfx dpll a ctrl     [00006014] = 94040c00
< igfx dpll a fp0      [00006040] = 00041505
---
> igfx dpll a ctrl     [00006014] = 84800c00
> igfx dpll a fp0      [00006040] = 00031108
60c60
< igfx dpll a ctrl p1  3
---
> igfx dpll a ctrl p1  8
62,64c62,64
< igfx dpll a fp0 m1   21
< igfx dpll a fp0 m2   5
< igfx dpll a fp0 n    4
---
> igfx dpll a fp0 m1   17
> igfx dpll a fp0 m2   8
> igfx dpll a fp0 n    3
66c66
< igfx dpll a fp0 freq 65066666
---
> igfx dpll a fp0 freq 25200000
80c80
< igfx adpa            [00061100] = 80000000
---
> igfx adpa            [00061100] = 80008000
84c84
< igfx vgacntrl        [00071400] = 8000008e
---
> igfx vgacntrl        [00071400] = 0000008e
160c160
< type=igfx, size=1680x1050x32
---
> type=s2231wA, size=1680x1050x32
167d166
< mode->attr: display=1
229c228
< igfx dpll a ctrl     [00006014] = 94010c00
---
> igfx dpll a ctrl     [00006014] = 94010c01
231c230
< igfx dpll a fp1      [00006044] = 00031108
---
> igfx dpll a fp1      [00006044] = 00061505
332c331
< type=igfx, size=1680x1050x32
---
> type=s2231wA, size=1680x1050x32
339d337
< mode->attr: display=1
402c400
< igfx dpll a ctrl     [00006014] = 94010c00
---
> igfx dpll a ctrl     [00006014] = 94010c01
404c402
< igfx dpll a fp1      [00006044] = 00031108
---
> igfx dpll a fp1      [00006044] = 00061505
diff 495: some
---- to here----

Kenji

[-- Attachment #2: vgaigfx --]
[-- Type: application/octet-stream, Size: 15688 bytes --]

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

No, there are some differences.
please give me days to check them.
I can work only slowly.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

I forgot one thing.

> "blank screen" doesnt say much. do you get a stable, but
> black screen? or does the screen not even turn on? is the
> backlight just off?

The screen begins to light at its very shorttime, 
and shows something veritical color image at the right side end.
After that shorttime, the screen becomes 'no signal', which
I know by a  "no signal" message from the panel.
It is something like to get off by a some command from
the PC, because the time that shows 'no signal' is too short.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

>you can dump the register contents with aux/vga and compare
>native igfx vs vesa + igfx.

After checking the differences between the two, I can now
say those do not explain the blank screen.   One is the
difference of resolutions, one is the difference between
started from VGA or started from 1024x768 etc.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

> http://felloff.net/usr/cinap_lenrek/igdump.tar

I started this today.

> you certanly have to change the port offsets for the banked
> address/data register in mmio.awk (check the io bar of
> the graphics card of your system)

Does this mean to use the data from pci command output result?
0.2.0:	vid  03.00.00 8086/29a2  10 0:fde00000 1048576 2:d000000c 268435456 4:0000ff01 16

In my case, use ff01 and ff05 instead of 1804 and 1805 in mmio.awk?
I used those value, and got all ffffffff value like:
rmmio 00041000 ffffffff 	#
rmmio 00044008 ffffffff 	#
rmmio 0004f000 ffffffff 	#
rmmio 0004f040 ffffffff 	#
rmmio 0004f044 ffffffff 	#
rmmio 0004f048 ffffffff 	#
rmmio 0004f04c ffffffff 	#
rmmio 00060000 ffffffff 	# HTOTAL_A
rmmio 00060004 ffffffff 	# HBLANK_A
rmmio 00060008 ffffffff 	# HSYNC_A
rmmio 0006000c ffffffff 	# VTOTAL_A
rmmio 00060010 ffffffff 	# VBLANK_A
rmmio 00060014 ffffffff 	# VSYNC_A
rmmio 0006001c ffffffff 	# PIPEASRC

I suppose we should compare the two dumps, one from vesa
using aux/realemu, which I got success like:
rport 03d4 0f 	# VGA_CRX
rport 03d6 ff 	#
rport 03d0 ff 	#
rport 03ce 06 	# VGA_GRX
rport 03d2 ff 	#
rport 03c4 01 	# VGA_SRX
rport 03c7 00 	# VGA_DACSTATE/DACRX
rport 03c8 40 	# VGA_DACWX
wport ff00 00002020 	#
rport ff04 cff80001 	#
wport ff00 00071414 	#
<snip>

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

> In my case, use ff01 and ff05 instead of 1804 and 1805 in mmio.awk?
> I used those value, and got all ffffffff value like:
> rmmio 00041000 ffffffff 	#
> rmmio 00044008 ffffffff 	#
> rmmio 0004f000 ffffffff 	#
> rmmio 0004f040 ffffffff 	#
> rmmio 0004f044 ffffffff 	#
> rmmio 0004f048 ffffffff 	#
> rmmio 0004f04c ffffffff 	#
> rmmio 00060000 ffffffff 	# HTOTAL_A
> rmmio 00060004 ffffffff 	# HBLANK_A
> rmmio 00060008 ffffffff 	# HSYNC_A
> rmmio 0006000c ffffffff 	# VTOTAL_A
> rmmio 00060010 ffffffff 	# VBLANK_A
> rmmio 00060014 ffffffff 	# VSYNC_A
> rmmio 0006001c ffffffff 	# PIPEASRC

Ichanged the value of 0xf000 and 0cf004 of dump.rc to
0xff00 and 0xff04, and got a reasonable value like:
rmmio 00041000 ffffffff 	#
rmmio 00044008 ffffffff 	#
rmmio 0004f000 ffffffff 	#
rmmio 0004f040 ffffffff 	#
rmmio 0004f044 ffffffff 	#
rmmio 0004f048 ffffffff 	#
rmmio 0004f04c ffffffff 	#
rmmio 00060000 8bf068f 	# HTOTAL_A
rmmio 00060004 8bf068f 	# HBLANK_A
rmmio 00060008 7a706f7 	# HSYNC_A
rmmio 0006000c 4400419 	# VTOTAL_A
rmmio 00060010 4400419 	# VBLANK_A
rmmio 00060014 422041c 	# VSYNC_A
rmmio 0006001c 68f0419 	# PIPEASRC
rmmio 00060030 0 	#
rmmio 00060034 0 	#
rmmio 00060040 0 	#
rmmio 00060044 0 	#
	....

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

> state. the vesa bios might initialze registers that the igfx
> driver misses.

I havn't find this yet, however I found the vesa driver also set the GMBUS port as 2
same as your code.
It's like:  (comments were written by me)
-----
wport 03c4 01 	# VGA_SRX
rport 03c4 0001 	# VGA_SRX
wport 03c4 2001 	# VGA_SRX
wport ff00 00071424 	# software Flag Reg 15
rport ff04 00000041 	#
wport ff00 00005108 	# GMBUS2 Status Reg
rport ff04 00000000 	#	read operation, not a wait phase, no slave timeout occured, int not occured
wport ff00 00005100 	# GMBUS0 clock/Port select
rport ff04 00000000 	#	default (None is selected)
wport ff04 00000002 	#	set it to 2 (=Rate=100KHz and Dedicated to Analog Monitor DDC pins)
wport ff00 00005108 	# GMBUS2 Status Reg
rport ff04 00008000 	#	GMBUS2 is in use by someone(default value)
wport ff00 00005104 	# GMBUS1 Command/Status
------

I'm still working.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[cinap_lenrek]

very good. the gmbus stuff is for reading edid. if aux/vga -p prints the
edid, then this probably not the issue. but you are on the right track.

the theory is that igfx programs the registers right that it knows
about (check the load function), otherwise you wouldnt see a picture
at all. (igfx disables all the ports and then reprograms everything).
so the missing bits might not even be in the driver.

we'r looking for the needle in the haystack. if you have a clean bios
trace, then you can use the power of text processing and make a list
of all the wport mmio addresses for both igfx and bios. that way, you
can find registers that the igfx driver doesnt know about but are
programmed by the bios. then we can look them up in the intel docs
and figure out what they do :-)

good luck!

--
cinap

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

I checked out all the output from vesa driver, and found
no missed registeres in igfx.c not including treatments of
sotware flag registers.

Then, I turned the direction to find chip differences from the
programming manual.   My chip belongs to DevBW, and
a working one to DevCL.   I found DebBW difference in
registers of [6200][6204][6110][70030][70034][72180],
the last three are not used in G45 in igfx.c.
The [6200][6204] are not important, because we are getting
the right values from those usage.
Then, the [6110] register, adps register, is the cause, I suppose.

In page 93, the manual says, in the case of DevBW, to enable 
the Analog display port, we must do a series of operations 
in the right order like:
1) set bit #31 to 1, and [11:10] to "11"
2) wait for VSYNC
3) clear [11:10] to "00"

Yes, I see large wait loop for Vsync in vesa drivers output.
like:
wport ff00 00070024 	# pipe A display status
rport ff04 00000000 	#	default value(no event)
wport ff04 00000002 	#	set to detect Vertical Blank Interrupt
wport ff00 00070024 	# pipe A display status
rport ff04 00000000 	#	done above set
		.....
wport ff00 00070024 	# pipe A display status
rport ff04 00000000 	#	no event (default)
rport 0061 00 	# PIT_CTL2
wport 0061 01 	# PIT_CTL2
wport 0043 b6 	# PIT_MODE
wport 0042 50 	# PIT_CNTR2
wport 0042 05 	# PIT_CNTR2
wport 0043 80 	# PIT_MODE
rport 0042 33 	# PIT_CNTR2
rport 0042 04 	# PIT_CNTR2
wport 0043 80 	# PIT_MODE
rport 0042 e3 	# PIT_CNTR2
rport 0042 00 	# PIT_CNTR2
wport 0043 80 	# PIT_MODE
rport 0042 cb 	# PIT_CNTR2
rport 0042 02 	# PIT_CNTR2
wport 0061 00 	# PIT_CTL2
		...
		...
wport ff00 00070024 	# pipe A display status
rport ff04 00000207 	#	State = Vsync occured, Start of VSYNC occured, VBLANK occured, Overlay Reg updated

However, there are output from/to many software flag registers
in this interval, I have been abondoned to deal with it, because
I have to investigate assembly codes. (sigh)

However, I got realized that the above 1) to 3) procedures
are not done in igfx.c.   Therefore, I think this is our
problem.  It may cause some large code rewriting.
How do you think?

Kenji

Re: [9front] strange behaviour of igfx and vesa

[cinap_lenrek]

why would this cause large code rewriting?

--
cinap

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

Oh!

That point I did not consider throughly, just my hand
wrote the line, because I did it before and failed to get
success.

Have you good idea?
If so, please do it.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

I'm still experimenting this, but no success.

When I posted last mail, and pointed supposed to do some large
rewriting neccessary, which was thought less.

At that time, I was thinking to change in init() function for 29a2 chip.
Now I fugured it was wrong, and am now adding some code in load()
function.

Now experimenting codes are(in load() function):
	/* program vga plane */
	loadreg(igfx, igfx->vgacntrl);

	/* program ports */
/* from here====K.Okamoto====*/
	if(igfx->pci->did == 0x29a2){		/* K.Okamoto */
		wr(igfx, igfx->adpa.a, 1<<31);		/* enable adpa */
		wr(igfx, igfx->adpa.a, 3<<10);		/* off disable hsync/vsync */
		wr(igfx, igfx->adpa.a, 1<<15);		/* use 4,3 bits for hsync/vsync */
//		wr(igfx, 0x070024, 1<<9);
//		while((rr(igfx, 0x070024) & 1<<9) == 0)
//			continue;
//		wr(igfx, 0x070024, 1<<1);
//		wr(igfx, 0x070024, 1<<9);
		wr(igfx, 0x070024, 0x207);
		while((rr(igfx, 0x070024) & 0x207) == 0)
			continue;
		wr(igfx, igfx->adpa.a, 1<<15);		/* use VGA bits for hsync/vsync */
		wr(igfx, igfx->adpa.a, ~(3<<10));		/* adpa hsync/vsynx on */
	}
/* ======to here K.Okamoto======*/
	loadreg(igfx, igfx->adpa);
	igfx->adpa.v &= ~(3<<10);	/* Monitor DPMS: on */

Results are not successfull, however, I suppose I'm now on right truck.
If you have some comments on this, please do it.

Kenji

Re: [9front] strange behaviour of igfx and vesa

[kokamoto]

> I'm still experimenting this, but no success.

I think I did all I can do now, but not success.
Then, I'll post my results here for memory of someone else.

I added codes below to ensure the VBLANK timing to enable
Analog Display port according to the manual, like:
in load() function of igfx.c
------- from here-----
	/* program ports */
	if(igfx->pci->did == 0x29a2){		/* K.Okamoto */
		igfx->adpa.v |= 1<<31;		/* enable adpa */
		wr(igfx, igfx->adpa.a, igfx->adpa.v);
		igfx->adpa.v |= 3<<10;		/* disable hsync/vsync */
		wr(igfx, igfx->adpa.a, igfx->adpa.v);
		wr(igfx, 0x070024, 0x207);
		while((rr(igfx, 0x070024) & 1<<9) == 0)
			{/* wait for VSYNC */
		}
		wr(igfx, 0x070024, 0x207);
		while((rr(igfx, 0x070024) & 1<<9) == 0)
			{/* wait for VSYNC */
		}
	}
	igfx->adpa.v &= ~(3<<10);	/* Monitor DPMS: on */
------to here-------

After somewhat longer period to wait the panel shouws no signal,
this fails to show screen.  
Here, I got 0x207 or 0x4 etc on 0x70024 register after the wait loop,
which means above loops work right.

Next, I compared the two dump.rc (using mmio.all), one of which
is done after vesa --> aux/vga -m igfx -l 1680x1050x32
(this case works fine), and the other is done after boot the
terminal without aux/vga.   Then, on the CGA console, I did the comand,
aux/vga -m igfx -l 1680x1050x32; dump.rc | pretty.rc >regdump.

The two register outputs were all the same without one value of
rmmio 00070000, which is not important here.
Therefore, I concluded the difference comes from neither the
settings of registers nor VSYNC problem.   
Therefore, there should be something not written in the manual.

I can use this terminal by booting vesa mode, then
aux/vga -m igfx -l 1680x1050x32, which may be OK now.

Kenji