Re: [radeonhd] Re: Making AtomBIOS modesetting the default

Luc, this remembers me at the old days where we did load the 8086 PC BIOS to RAM to make it run faster - greetings from the A20 gate ;) I progged a lot of uCs and hw in the past but have absolutely no glue how AtomBIOS looks like internally, so please correct me if I make false assumptions or if this is technically not possible: What about doing kind of what C++ has with it's virtual function pointer tables for AtomBIOS, so we could 'overload' broken AtomBIOS code with our own functions in RAM? Or to first load the whole AtomBIOS 'scripts' to RAM and replacing known flaws based on card-id, etc)? Flashing a graphics card bios is always the last resort, because this would eventually break other drivers like fglrx or win-catalyst which have built in 'exceptional handling code' (which is in praxis > 50% of the whole codebase) LieGrue, strub --- Luc Verhaegen schrieb am Di, 10.3.2009:

Von: Luc Verhaegen Betreff: Re: [radeonhd] Re: Making AtomBIOS modesetting the default An: "Paul Fertser" CC: "Matthias Hopf" , radeonhd@opensuse.org Datum: Dienstag, 10. März 2009, 13:57

-----Integrierter Anhang folgt-----

On Mon, Mar 09, 2009 at 09:04:44PM +0300, Paul Fertser wrote:

...

Matthias Hopf

...

...

On Mar 09, 09 20:15:30 +0300, Paul Fertser wrote:

...

...

Luc also has had a hard time with BIOS related issues in the past, so [snip] Turns out that the issues weren't as severe as we thought.

But that's just a happy coincidence, if i understand it right. Sooner or later it will break, because it's defective-by-design.

AFAICS it's not defective by design, but rather defective by too little validation. Of course you could assume that this won't get better, as BIOS programmers tend to behave this way.

Even if they didn't, updating a driver is much easier

...

videocard BIOS.

And if ATI/AMD wanted "scripts", they should have

...

exactly what they claim they did: scripts. Imagine a free tool to byte-compile (probably through a c compiler directly to native shared object) well-commented scripts and that byte-compiled code loaded in the driver at runtime. And an easy way to override the

writes: than updating a probably done scripts

...

used. _That_ would be a reasonable compromise. I can't see how you can call the current AtomBIOS way to do things not defective comparing to that.

ATI does want to force you to use the BIOS bytecode they provided, but ATI, at all cost, refuses to provide people with updated bioses, even when there are known defects, as their official stance is close to "but it is perfect when we're done anyway".

Everyone sane knows that a BIOS is just hardtoget-to/alter software, and that software is never perfect, so this is close to... hrm... bending the truth :)

A while back a user here got an updated bios from his hw vendor, together with a tool to flash his bios. This made ati quite unhappy :)

Now... What would be rather easy to do is code up something that loads a bios image provided as an option in your xorg.conf device section. This way you can load whatever image you want (at your own very explicit risk). Then we could look into cutting down the bios image to only hold the atombios part. Then we could look into assimilating our own images from something like atomdis output.

The first step there is trivial, the second shouldn't be too hard either. The rest is for someone with a lot of time and clue. Personally i think it would be fun to spend a few minutes doing the first two bits, but i can't be bothered with the last bit.

Luc Verhaegen. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org

-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org