Hello all,
The K8M890 BIOS needs int 0x15 0x5f18 to write to scratch register for a driver the memory size of framebuffer and also the memory speed. The X.org openchrome driver as well Unichrome driver needs that.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
Hmm my test computer does not have check-and-send plugin, so I forgot the attachment. Sorry.
Rudolf Marek wrote:
Hello all,
The K8M890 BIOS needs int 0x15 0x5f18 to write to scratch register for a driver the memory size of framebuffer and also the memory speed. The X.org openchrome driver as well Unichrome driver needs that.
Signed-off-by: Rudolf Marek r.marek@assembler.cz
Thanks, Rudolf
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Wed, Dec 24, 2008 at 12:16:14AM +0100, Rudolf Marek wrote:
The K8M890 BIOS needs int 0x15 0x5f18 to write to scratch register for a driver the memory size of framebuffer and also the memory speed. The X.org openchrome driver as well Unichrome driver needs that.
[...]
diff --git a/src/vgahooks.c b/src/vgahooks.c index 7c229ba..86050fd 100644 --- a/src/vgahooks.c +++ b/src/vgahooks.c
[...]
- bdf = pci_find_device(PCI_VENDOR_ID_VIA, 0x3336); /* K8M890 supported so far */
[...]
- bdf = pci_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB_MEMCTL); /* get the memory speed */
I thought the code would be vga chip dependent. However, it looks like it depends on both the chipset and vga chip.
It's going to be hard to maintain cpu and chipset specific features in SeaBIOS. I wonder if we can find an alternative.
Can you provide more details on what you're seeing? The VGA BIOS is calling int 155f18 and then populating a register in the vga card's pci config space? If so, could coreboot populate the register directly?
-Kevin
Hi,
Just a quick jump from nice evening back to nice stuff ;)
I thought the code would be vga chip dependent. However, it looks like it depends on both the chipset and vga chip.
Well VGA is inside chipset.
It's going to be hard to maintain cpu and chipset specific features in SeaBIOS. I wonder if we can find an alternative.
For another chipsets like VX800 or CN700 it would be approx same amount of code. Not that bad.
Can you provide more details on what you're seeing? The VGA BIOS is calling int 155f18 and then populating a register in the vga card's pci config space?
Yes exactly. Its in the card registers, not a PCI space, but yes in principle.
If so, could coreboot populate the register
directly?
No, BIOS ROM overwrites this.
Rudolf
Hi Jason,
I'm reconnecting this to correct thread. Maybe you can set your settings for this conference to receive individual emails.
I had added some very similar code on my VX800 port, except the location of pci register that get speed of DDR2(mine is 0x90). I add those code in both vgahook.c of Seabios and vgabios.c of Coreboot
Do you have the 0x15 0x5f specification? I never succeeded to get it from Bruce.
Maybe 155f is VGABIOS dependent? Yesterday, I test two different VGABIOS on my VX800 board for my coreboot code. First one is extracted from legacy bios on board, which doesn't play with my 155fcallback(s3 resume fails). Second one (I don't know where it is from), however, seems work fine.
Yes seems so. Mine BIOS works also fine without any callback, but OpenChrome Drivers would not allow any other resolution than 640x480 complaining about low memory bandwidth.
I studied both sides, VGA ROM BIOS and main BIOS Callbacks. It just writes the values of ebx from 0x5f18 to scratch registers.
Mine BIOS is: ruik@ruiktest:~/coreboot-merge-seabios-XP/coreboot-v2/zal$ strings 32301106.pci | head IBM COMPATIBLEBCPOST 03/01/07 PCIR VIA TRC63M *VT3336 Desktop NoTV Ver20
And finally I have one idea for the S3 resume. We do not need to call SeaBIOS again, we can jump to real mode, call the c000:0003 and then jump to waking vector directly. SeaBIOS will handle this directly for us without any S3 entrypoint ;)
Rudolf
-jasonzhao
-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Thursday, December 25, 2008 5:47 PM To: Jason Zhao Cc: Kevin O'Connor; Coreboot Subject: Re: [coreboot] [PATCH] SeaBIOS - vgahooks improvements
Hi Jason,
I'm reconnecting this to correct thread. Maybe you can set your settings for this conference to receive individual emails.
I had added some very similar code on my VX800 port, except the location of pci register that get speed of DDR2(mine is 0x90). I add those code in both vgahook.c of Seabios and vgabios.c of Coreboot
Do you have the 0x15 0x5f specification? I never succeeded to get it from Bruce.
Yes，I do, I have a spec named "Video BIOS External Interface Spec for UniChrome IGP". A 75 pages file. But it is confidential. (I can not understand why it is confidential). Maybe you can ask Bruce for getting this file from me(maybe he has no this file...).
Maybe 155f is VGABIOS dependent? Yesterday, I test two different VGABIOS on my VX800 board for my coreboot code. First one is extracted from legacy bios on board, which doesn't play with my 155fcallback(s3 resume fails). Second one (I don't know where it is from), however, seems work fine.
Yes seems so. Mine BIOS works also fine without any callback, but OpenChrome Drivers would not allow any other resolution than 640x480 complaining about low memory bandwidth.
return value of all int0x15(int21) AH AL Completion status ?? 5Fh Function call supported ?? !=5Fh Function not supported 00 5Fh Function call successful 01 5Fh Function call failed
Return value of 5f18. BL Bit[7:4] Memory Data Rate 0000: 66MHz 0001: 100MHz 0010: 133MHz 0011: 200MHz ( DDR200 ) 0100: 266MHz ( DDR266 ) 0101: 333MHz ( DDR333 ) 0110: 400MHz ( DDR400 ) 0111: 533MHz ( DDR I/II 533 1000: 667MHz ( DDR I/II 667) Bit[3:0] N: Frame Buffer Size 2^N MB
I studied both sides, VGA ROM BIOS and main BIOS Callbacks. It just writes the values of ebx from 0x5f18 to scratch registers.
Mine BIOS is: ruik@ruiktest:~/coreboot-merge-seabios-XP/coreboot-v2/zal$ strings 32301106.pci | head IBM COMPATIBLEBCPOST 03/01/07 PCIR VIA TRC63M *VT3336 Desktop NoTV Ver20
And finally I have one idea for the S3 resume. We do not need to call SeaBIOS again, we can jump to real mode, call the c000:0003 and then jump to waking vector directly. SeaBIOS will handle this directly for us without any S3 entrypoint ;)
Please see Kevin's newest reply for thread "[coreboot] 2 keypoints to use coreboot+seabios toachieveWINDOWS-XP's s3 sleep/resume". He said when S3 resume, coreboot can jump to f000:fff0 instead of jump into elf file. Although I didn’t test it yet.
Rudolf
Yes，I do, I have a spec named "Video BIOS External Interface Spec for UniChrome IGP". A 75 pages file. But it is confidential. (I can not understand why it is confidential). Maybe you can ask Bruce for getting this file from me(maybe he has no this file...).
Yes exactly that file. I think I will write Bruce that this is wrong for unichrome/openchrome. Also for higher bandwidth memories, the specs is silent... I guess DDR2 400 would mean 6 maybe.
Specs: 0: 66MHz 1: 100MHz 2: 133MHz 3: 200MHz ( DDR200 ) 4: 266MHz ( DDR266 ) 5: 333MHz ( DDR333 ) 6: 400MHz ( DDR400 ) 7: 533MHz ( DDR I/II 533 8: 667MHz ( DDR I/II 667)
Hmm so both OpenChrome an Unichrome drivers have it wrong ;)
Unichrome thinks:
/* For pVia->MemClk */ #define VIA_MEM_DDR_200 0x00 #define VIA_MEM_DDR_266 0x01 #define VIA_MEM_DDR_333 0x02 #define VIA_MEM_DDR_400 0x03 #define VIA_MEM_DDR2_400 0x04 #define VIA_MEM_DDR2_533 0x05 #define VIA_MEM_DDR2_667 0x06 #define VIA_MEM_DDR2_800 0x07 #define VIA_MEM_DDR2_1066 0x08
Openchrome thinks: + 0: SDR 66Mhz + 1: SDR 100Mhz + 2: SDR 133Mhz + 3: DDR 100Mhz (PC1600 or DDR200) + 4: DDR 133Mhz (PC2100 or DDR266) + 5: DDR 166Mhz (PC2700 or DDR333) + 6: DDR 200Mhz (PC3200 or DDR400) + 7: DDR2 100Mhz (DDR2 400) + 8: DDR2 133Mhz (DDR2 533) + 9: DDR2 166Mhz (DDR2 667) + A: DDR2 200Mhz (DDR2 800) + B: DDR2 233Mhz (DDR2 1066)
Perhaps they should be fixed in the future. Rudolf
On Wed, Dec 24, 2008 at 12:16:14AM +0100, Rudolf Marek wrote:
The K8M890 BIOS needs int 0x15 0x5f18 to write to scratch register for a driver the memory size of framebuffer and also the memory speed. The X.org openchrome driver as well Unichrome driver needs that.
[...]
diff --git a/src/vgahooks.c b/src/vgahooks.c index 7c229ba..86050fd 100644 --- a/src/vgahooks.c +++ b/src/vgahooks.c
[...]
- bdf = pci_find_device(PCI_VENDOR_ID_VIA, 0x3336); /* K8M890 supported so far */
[...]
- bdf = pci_find_device(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_K8_NB_MEMCTL); /* get the memory speed */
[...]
I think I understand your patch a little bit better now. The first pci device is used to obtain the framebuffer size, and the second device is used to find the ram speed.
Perhaps we should break this into two separate functions - that way it's clear that each device provides independent information. (Something like the attached?)
Also, does unichrome/openchrome drivers need the framebuffer size? It seems odd to me that they'd read a scratch register for that, when they could just as easily read the real register.
-Kevin
Hi,
I think I understand your patch a little bit better now.
OK good.
The first pci device is used to obtain the framebuffer size, and the second device is used to find the ram speed.
Yep. Check this:
http://linux.via.com.tw/support/beginDownload.action?eleid=161&fid=241 (page 70)
Its from VX800 (which Jason already added in his not yet published patch) Its exactly the same as for K8M890.
The memory speed is in: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/3255...
Perhaps we should break this into two separate functions - that way it's clear that each device provides independent information. (Something like the attached?)
Yes, but please leave it with the warnings as I did. It is difficult to know where is the problem if we blindly supply default without knowing.
Also, does unichrome/openchrome drivers need the framebuffer size? It seems odd to me that they'd read a scratch register for that, when they could just as easily read the real register.
Yes it is like that. Perhaps to make it more hw independent?
Rudolf
-
JasonZhao＠viatech.com.cn -
Kevin O'Connor -
Rudolf Marek