Re: VGA Problem about 440bx chipset
right. linuxbios+ADLO+Bochs
From: Adam Sulmicki <adam@cfar.umd.edu> To: Chiu Gerald <snow2moutain@hotmail.com> CC: rsmith@bitworks.com, <linuxbios@clustermatic.org> Subject: Re: VGA Problem about 440bx chipset Date: Sat, 4 Sep 2004 10:54:45 -0400 (EDT)
is this with ADLO?
neat!
On Sat, 4 Sep 2004, Chiu Gerald wrote:
Wow! I got it! I use another S3 video card,and succeeded in bringing up the VGA,and booted RedHat linux. So wonderful linuxbios is! Richard Smith,thanks for your help very very much!
From: Richard Smith <rsmith@bitworks.com> To: LinuxBIOS <linuxbios@clustermatic.org> Subject: Re: VGA Problem about 440bx chipset Date: Wed, 01 Sep 2004 10:04:52 -0500
Chiu Gerald wrote:
you mean that PCI card works?
Yes some PCI cards work. I've made several Assiliant 65550 and 69000 based PCI cards work and some S3 based cards work. There are reports of some ATI cards working but I am still having problems getting my ATI M1 based card to work.
Now I changed to a PCI video card,and bochs had run the vga bios,but still nothing happened!
I have no idea what should I do next.
Are you setting up the shadowing correctly? You have to setup the shadowing in loader.s or bochs and the video bios never make it into ram. The stock ADLO setup won't work on the 440bx.
I've attached my loader.s which sets up the shadowing correctly.
Also the DEBUG_SERIAL option in rombios.c is very useful. You can enable it and all the bochs bios messages will be redirected out the serial port. This way you can see if bochs rombios is even getting called. You have to turn it back off to get text on the VGA screen. But your cards VSYNC should happen regardless. (assuming the vbios runs correctly)
I leave in a few hours and won't be back till Tuesday the 2nd so you are on your own for a few days. I'll try to check email during that time but I'm not promising anything.
Search the mailing list for things like "ADLO", "vgabios", etc there are several threads on getting this up.
_________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_________________________________________________________________ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
perhaps it would make sense to summarize "lessons learned" and send them to list, so that whoever will play with ADLO next can benefit from the knowledge Just put in all right keywords so that it is easie to find it later on, like ADLO, S3, etc. The shadow patch probably isn't big either. On Sun, 5 Sep 2004, Chiu Gerald wrote:
right.
linuxbios+ADLO+Bochs
From: Adam Sulmicki <adam@cfar.umd.edu> To: Chiu Gerald <snow2moutain@hotmail.com> CC: rsmith@bitworks.com, <linuxbios@clustermatic.org> Subject: Re: VGA Problem about 440bx chipset Date: Sat, 4 Sep 2004 10:54:45 -0400 (EDT)
is this with ADLO?
neat!
On Sat, 4 Sep 2004, Chiu Gerald wrote:
Wow! I got it! I use another S3 video card,and succeeded in bringing up the VGA,and booted RedHat linux. So wonderful linuxbios is! Richard Smith,thanks for your help very very much!
From: Richard Smith <rsmith@bitworks.com> To: LinuxBIOS <linuxbios@clustermatic.org> Subject: Re: VGA Problem about 440bx chipset Date: Wed, 01 Sep 2004 10:04:52 -0500
Chiu Gerald wrote:
you mean that PCI card works?
Yes some PCI cards work. I've made several Assiliant 65550 and 69000 based PCI cards work and some S3 based cards work. There are reports of some ATI cards working but I am still having problems getting my ATI M1 based card to work.
Now I changed to a PCI video card,and bochs had run the vga bios,but still nothing happened!
I have no idea what should I do next.
Are you setting up the shadowing correctly? You have to setup the shadowing in loader.s or bochs and the video bios never make it into ram. The stock ADLO setup won't work on the 440bx.
I've attached my loader.s which sets up the shadowing correctly.
Also the DEBUG_SERIAL option in rombios.c is very useful. You can enable it and all the bochs bios messages will be redirected out the serial port. This way you can see if bochs rombios is even getting called. You have to turn it back off to get text on the VGA screen. But your cards VSYNC should happen regardless. (assuming the vbios runs correctly)
I leave in a few hours and won't be back till Tuesday the 2nd so you are on your own for a few days. I'll try to check email during that time but I'm not promising anything.
Search the mailing list for things like "ADLO", "vgabios", etc there are several threads on getting this up.
_________________________________________________________________ �����������ѽ��н�������ʹ�� MSN Messenger: http://messenger.msn.com/cn
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
_________________________________________________________________ �����������ѽ��н�������ʹ�� MSN Messenger: http://messenger.msn.com/cn
Wow! I got it! I use another S3 video card,and succeeded in bringing up the VGA,and
Excellent. Its really touchy about what VBIOS will work and what won't. I haven't been able to narrow it down as to what the missing piece is yet. ATI seems to be the worst though. Probally because of all the bios extensions they use.
perhaps it would make sense to summarize "lessons learned" and send them to list, so that whoever will play with ADLO next can benefit from the knowledge
Setting up a "known to work" table of chipsets vs cards may be a good idea as well.
Just put in all right keywords so that it is easie to find it later on, like ADLO, S3, etc. The shadow patch probably isn't big either.
After my initial post of the patch (about a 1.5 years ago) I never really tried to push the patch upstream since its chipset specific. What's really needed here is vga expansion rom shadowing support in the pci resource allocation code. So that you could do something like this in the config file. option SHADOW_VGA_BIOS=1 option SHADOW_VGA_BIOS_DEST=0xC0000 Then the mainboard chipset code could handle copying it from the PCI ROM to the shadow location and ADLO would not need to know anything about how to shadow for a specific chipset. I for one could really use this feature. I'd offer to code up an implementation for the 440bx but I don't have much of a clue on how the PCI resource allocation works.
On Tue, 7 Sep 2004, Richard Smith wrote:
option SHADOW_VGA_BIOS=1 option SHADOW_VGA_BIOS_DEST=0xC0000
we'll put this on the list, though not quite this way (unless you want it in V1) ron
ron minnich wrote:
option SHADOW_VGA_BIOS=1 option SHADOW_VGA_BIOS_DEST=0xC0000
we'll put this on the list, though not quite this way (unless you want it in V1)
Well until myself or some other industrious soul ports the 440bx stuff to V2 its not much use to me unless its V1. It dosen't really matter to me how its implemented in V1. If you have what you think is the "right" way then I'm game. And if someone will guide me through what needs to be done in the PCI allocation stuff I'll give it a whirl but at first blush that PCI allocation stuff appears fairly complex. I guess the part I need help on would be the methodology of the ROM expansion address assignment. The actual copy seems pretty trivial. - Scan for the id of the vga device. - Get the rom address and enable the decode. - set the shadowing. - do the copy. - disable writes to the shadow. - disable the ROM decode. Yes?
It dosen't really matter to me how its implemented in V1. If you have what you think is the "right" way then I'm game. And if someone will guide me through what needs to be done in the PCI allocation stuff I'll give it a whirl but at first blush that PCI allocation stuff appears fairly complex.
For V1, we're not too worried about pretty. I'll try to work up an example for you. ron
Ronald G. Minnich wrote: I'm changing the subject to something more specific.
think is the "right" way then I'm game. And if someone will guide me through what needs to be done in the PCI allocation stuff I'll give it a whirl but at first blush that PCI allocation stuff appears fairly complex.
For V1, we're not too worried about pretty. I'll try to work up an example for you.
Dude, you've got plenty to do.... A few rough explanations on whats going on may be all I need. I dug through the PCI code last night and I seem to be getting the jist of how it goes. I don't quite yet grok the actual allocation "scheme" but the magic seems to be happening in pci_set_resource() in linuxpci.c and compute_allocate_resource in newpci.c. Neither of these seem to understand expansion roms. What resource flags will be set for a device with expansion roms? MEM? but with perhaps with IORESOURCE_SHADOWABLE? I don't see anything specific to expansion roms. The red book so far hasn't been much help. Or I just haven't found the right section. Eric (or anybody else): where did you get your info when you re-factored all this code?
On Wed, 2004-09-08 at 09:17, Richard Smith wrote:
Ronald G. Minnich wrote:
I'm changing the subject to something more specific.
think is the "right" way then I'm game. And if someone will guide me through what needs to be done in the PCI allocation stuff I'll give it a whirl but at first blush that PCI allocation stuff appears fairly complex.
For V1, we're not too worried about pretty. I'll try to work up an example for you.
Dude, you've got plenty to do.... A few rough explanations on whats going on may be all I need.
I dug through the PCI code last night and I seem to be getting the jist of how it goes. I don't quite yet grok the actual allocation "scheme" but the magic seems to be happening in pci_set_resource() in linuxpci.c and compute_allocate_resource in newpci.c.
Neither of these seem to understand expansion roms. What resource flags will be set for a device with expansion roms? MEM? but with perhaps with IORESOURCE_SHADOWABLE? I don't see anything specific to expansion roms.
I don't think either V1 or V2 can do expansion ROM. It is the first thing on my todo list for porting testbios into LB.
The red book so far hasn't been much help. Or I just haven't found the right section. Eric (or anybody else): where did you get your info when you re-factored all this code?
What's red book ? Ollie
What I'd say for your one option which was something like: option ENABLE_SHADOW_C000 is that you would put code in northbridge.c to enable that shadow. The other one is probably not needed. ron
Li-Ta Lo wrote:
I don't think either V1 or V2 can do expansion ROM. It is the first thing on my todo list for porting testbios into LB.
Correct. They don't. I'm trying to see what it will take to make them. I don't need general expansion rom support. All I need for ADLO is a valid memory range assigned to the VGA expansion ROM. Then my chipset code can enable the rom and do the shadowing copy.
The red book so far hasn't been much help. Or I just haven't found the right section. Eric (or anybody else): where did you get your info when you re-factored all this code?
What's red book ?
"PCI Hardware and Software. Architecture and Design" by Edward Solari and George Willse. It has a red cover.
On Wed, 2004-09-08 at 10:49, Richard Smith wrote:
What's red book ?
"PCI Hardware and Software. Architecture and Design" by Edward Solari and George Willse. It has a red cover.
Do you have a copy of the real spec ? It is in chapter 6. The expansion rom base addres is at 0x30 instead of the 0x10 - 0x24 is IO/MEM bar. The bit 0 of the register is enable bit and bit 11-31 is the address. Ollie
ron minnich wrote:
What I'd say for your one option which was something like: option ENABLE_SHADOW_C000
What I'm thinking of would only be for the VGA device so perhaps ENABLE_VBIOS_SHADOW_C000 would be more descriptive? V1 has lots of options that don't really match what they do and I'd rather not contribute to expanding that list.
is that you would put code in northbridge.c to enable that shadow. The other one is probably not needed.
On our prior desing we had a ISA PCMCIA bridge that only seemed to work at c000 and we had to move the VGA shadow to e000. But now that everything is PCI thats probally not an issue anymore.
On Wed, 8 Sep 2004, Richard Smith wrote:
What I'm thinking of would only be for the VGA device so perhaps
ENABLE_VBIOS_SHADOW_C000
yes, that name is fine. The issue is that the handling of that option (in V1) would be done in code in northbridge.c for almost every chipset we support in v1 ron
ron minnich wrote:
ENABLE_VBIOS_SHADOW_C000
yes, that name is fine. The issue is that the handling of that option (in V1) would be done in code in northbridge.c for almost every chipset we support in v1
I don't understand. Shadowing is chipset specific and would have to be done for all chipsets in v1 or v2. Putting it in the chipsets northbridge.c is way better than having to modify and keep a special version of ADLO's loader.s thats only works for one specfic chipset. But who said anything about doing it for all chipsets in v1? Ther are only a few of us that are trying to use ADLO. Let those who desire this add the necessary code. All this does is provide an nice easy method of getting the vbios into C000. Rather than the multi-step method of boot card in machine with COTS bios, copy bios to file, add file to the ADLO build, rebuild linuxbios, boot card under linuxbios+adlo.
ENABLE_VBIOS_SHADOW_C000
yes, that name is fine. The issue is that the handling of that option (in V1) would be done in code in northbridge.c for almost every chipset we support in v1
I don't understand. Shadowing is chipset specific and would have to be done for all chipsets in v1 or v2. Putting it in the chipsets northbridge.c is way better than having to modify and keep a special version of ADLO's loader.s thats only works for one specfic chipset.
But who said anything about doing it for all chipsets in v1? Ther are only a few of us that are trying to use ADLO. Let those who desire this add the necessary code.
All this does is provide an nice easy method of getting the vbios into C000. Rather than the multi-step method of boot card in machine with COTS bios, copy bios to file, add file to the ADLO build, rebuild linuxbios, boot card under linuxbios+adlo.
this obviously assumes non-integrated vga bios. On SiS 650 (IIRC) the VGA BIOS would be on the same chip as PC BIOS but yeah, otherwise it sounds like a neat trick. I assume LB would do all copying? IIRC ADLO would turn off write access once copying it was done. The " E) shadow - OFF (write)" Not sure if that's strictly necessary but it does happen after the copy operation.
Adam Sulmicki wrote:
this obviously assumes non-integrated vga bios. On SiS 650 (IIRC) the VGA BIOS would be on the same chip as PC BIOS
Thats the way the Bitworks board works as well. We have the vbios included the LB image because our video chips are on board. But if you are trying to debug things and try other video cards via a slot its a real pain. I end up with like 6 or 7 different flash chips that I have to plug in depending on what video card I am trying to mess with.
I assume LB would do all copying?
Yes. That way ADLO dosen't have to care about the shadowing. I'll probally ifdef out all the the shadow copy stuff from loader.s when LB can handle the vbios shadow since it already does PIRQ. Not really sure how I'll handle the vbios-in-system-image yet but something similar exists with the vbios via real mode IDT code.
IIRC ADLO would turn off write access once copying it was done. The " E) shadow - OFF (write)" Not sure if that's strictly necessary but it does happen after the copy operation.
Yeah you RC. Thats the way it works. The off isn't strictly necessary. I ran for about 6 months before I realized I wasn't turning write access to that range back off. As long as no stray process goes plowing through that range it dosen't matter. Of course if that happens you have other problems.
On Wed, 8 Sep 2004, Richard Smith wrote:
IIRC ADLO would turn off write access once copying it was done. The " E) shadow - OFF (write)" Not sure if that's strictly necessary but it does happen after the copy operation.
Yeah you RC. Thats the way it works. The off isn't strictly necessary. I ran for about 6 months before I realized I wasn't turning write access to that range back off. As long as no stray process goes plowing through that range it dosen't matter. Of course if that happens you have other problems.
that is a good news. it would really simplify the design and eliminate needs for any call-backs. still where would the LB code make the original image available? it seems that we still need ADLO-specific "plugin" in LB for ALDO proper to work. ie a) make vbios image available b) setup shadow ram c) copy the vbios image into shadow ram. I seem to recall some talk on (b) in this thread.. which would be chip-set specific. I suppose (a) and (c) could be some fairly generic routines for just about any expansion rom.
Richard Smith <rsmith@bitworks.com> writes:
ron minnich wrote:
ENABLE_VBIOS_SHADOW_C000 yes, that name is fine. The issue is that the handling of that option (in V1) would be done in code in northbridge.c for almost every chipset we support in v1
I don't understand. Shadowing is chipset specific and would have to be done for all chipsets in v1 or v2. Putting it in the chipsets northbridge.c is way better than having to modify and keep a special version of ADLO's loader.s thats only works for one specfic chipset.
Enabling everything as memory except the legacy vga bios hole should be done. On an Intel chipset it should just be properly setting the PAM register. Unless there is a good reason not to every chipsets northbridge should do this. And there is no reason to make it conditional.
But who said anything about doing it for all chipsets in v1? Ther are only a few of us that are trying to use ADLO. Let those who desire this add the necessary code.
Agreed.
All this does is provide an nice easy method of getting the vbios into C000. Rather than the multi-step method of boot card in machine with COTS bios, copy bios to file, add file to the ADLO build, rebuild linuxbios, boot card under linuxbios+adlo.
As for the copy that is something different. ADLO should really look at the pci options roms and do the appropriate thing, so if LinuxBIOS can reserve a hole in the memory address space to map the ROM into, ADLO should do the rest. That way ADLO can support all options ROMS. Eric
* Eric W. Biederman <ebiederman@lnxi.com> [040909 02:58]:
I don't understand. Shadowing is chipset specific and would have to be done for all chipsets in v1 or v2. Putting it in the chipsets northbridge.c is way better than having to modify and keep a special version of ADLO's loader.s thats only works for one specfic chipset.
Enabling everything as memory except the legacy vga bios hole should be done. On an Intel chipset it should just be properly setting the PAM register.
Unless there is a good reason not to every chipsets northbridge should do this. And there is no reason to make it conditional.
All this does is provide an nice easy method of getting the vbios into C000. Rather than the multi-step method of boot card in machine with COTS bios, copy bios to file, add file to the ADLO build, rebuild linuxbios, boot card under linuxbios+adlo.
As for the copy that is something different.
ADLO should really look at the pci options roms and do the appropriate thing, so if LinuxBIOS can reserve a hole in the memory address space to map the ROM into, ADLO should do the rest.
This would require to actively change the PAM registers during ADLO still, would it not? With our current abstraction, this is something that should clearly go to LinuxBIOS though since it is chipset specific. Ok, we don't want callbacks, but could we not store the information on how to cope with PAM registers in the LinuxBIOS table, probably as some array of PCI addresses to read+[&|]+write to? This would allow to keep ADLO completely generic. Thinking forward, we should store much more information in the LinuxBIOS table. For example on machines where LinuxBIOS initializes video itself (ATI XL, Trident Cyberblade) the LinuxBIOS table should contain an entry with the framebuffer address, the resolution and the color depth. Then any payload can spare reinitializing video without having to make ventured assumptions on the status of the hardware. Stefan
Stefan Reinauer wrote:
ADLO should really look at the pci options roms and do the appropriate thing, so if LinuxBIOS can reserve a hole in the memory address space to map the ROM into, ADLO should do the rest.
This would require to actively change the PAM registers during ADLO still, would it not?
With our current abstraction, this is something that should clearly go to LinuxBIOS though since it is chipset specific.
Ok, we don't want callbacks, but could we not store the information on how to cope with PAM registers in the LinuxBIOS table, probably as some array of PCI addresses to read+[&|]+write to? This would allow to keep ADLO completely generic.
Are you guys discussing how this needs to be done for V2? Because for V1 this is really starting to sound complicated which was not what I was attemping to suggest. The only thing that BOCHS needs is a copy of the ROM extension in the legacy range. It already scans the range and runs any extension it finds. ADLO currently does this copy because LB dosen't. All I need is an address assigned to the ROM that won't conflict. Then a few changes in the chipsets northbridge code will make this work for on card expansion ROMS. Simple and fairly non-intrusive. The only intrusive change is the assignment of a mem-address to the ROM. Why make it more complex than that? Am I just missing something here?
participants (8)
-
Adam Sulmicki -
Chiu Gerald -
ebiederman＠lnxi.com -
Li-Ta Lo -
Richard Smith -
ron minnich -
Ronald G. Minnich
-
Stefan Reinauer