2014-04-05 15:48 GMT+02:00 Luc Verhaegen <[email protected]>: > On Sat, Apr 05, 2014 at 03:20:08PM +0200, Rudolf Marek wrote: >> Hi all, >> >> I think there is OpenRadeonBios. The problem is that thhe AtomBIOS >> bytecode is vendor specific blob, which cannot be in principle released >> by AMD because it is written by board manufacturers for specific wireup >> of graphical output. This is what I have learnt when I was interested in >> that way more. > > Iirc, this does not replace atombios in any way, just replaces the bits > around atombios. > >> Ron, if you create dummy atombios bios whithout an x86 code the radeon >> driver in kernel should be able to post it. It even works now. If you >> include the orginal rom in the cbfs but don't run it, the kernel driver >> is able to modeset it and "post" it. I think David Hubbard was >> interested in the replacement BIOS as well.. > > Atombios has bytecode which is run through an interpreter. There is no > x86 code in there. All the ASIC and board specific bits should be in the > function and data tables of atombios... But that might have changed > already... > > Initially (for the R500), the promise was that all board specific bits > would live in the datatables, and would not protrude into the function > tables. but that got thrown wildly but of the window with rv610/630. > > Of course, not all things can ever be hidden away completely by > atombios, and we had to do hard stuff ourselves still. Plus, the > fglrx/windows driver worked around bugs in both the hw _and_ atombios. > So who knows to what extent that rot has spread in the past 5 years, > and to what extent the ATI VGA bios code works around atombios today? > > For all i know, ATI still doesn't allow people to flash their bioses.
Correct. Quoting Alexander Deucher: "There is no public documentation on how to write to the flash chips on AMD GPUs and we do not plan to expose this functionality as far as I know." (dated April 14, 2013). > Iirc, Biostar gave some of their users the tool to do so back in late > 2007, and ATI was not exactly happy. So fixing shipped hardware can only > be done through fglrx/windows driver. > > Did you know that read access to the bios was disabled from within the > original ASIC_Init atombios function? Egbert Eich had to go and bisect > the atombios bytecode to pinpoint what did that, as of course ATI > couldn't or wouldn't tell us. > > Why was that important? Well, suppose you would restart your X server... > >> I think still that graphics modesetting is only minor problem. I feel >> very disturbed about AMD plans considering to go same way as Intel. I >> always liked AMD for opening their systems as much as possible. There was >> always my goal to have some x86 blob free at least for the x86 CPU code. >> This worked fine with VIA K8M890 where in VGA bios could be replaced by >> QEMU bios ;) Now we are drifting slowly away from any truly open x86 >> system. > > Ah, the long dead and now utterly irrelevant unichrome. It spawned a > great many things. > > Luc Verhaegen. > > -- > coreboot mailing list: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
