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.
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..
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.
I think we should put some effort making such x86 blobs runnable as kind of userspace process isolating it as much from coreboot as possible. I mean not only VGA BIOSes but also FSP or any other blobs.
The various other firmwares are next level problem, we should at least stick to the primary goal, to have free system which runs on main CPU.
Thanks Rudolf
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. 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.
2014-04-05 15:48 GMT+02:00 Luc Verhaegen libv@skynet.be:
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: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Idwer Vollering -
Luc Verhaegen -
Rudolf Marek