Dear coreboot folks,
similar to implementing native graphics for Intel hardware to replace the Video BIOS [1], which brings down the time from 1.5 seconds with the Video BIOS to 200 ms with native graphics init [2], the same should be done for hardware with AMD/ATI graphics.
Would such a project be feasible for Google Summer of Code 2013?
1. Is that even possible for AMD/ATI hardware in their current design with ATOM BIOS and firmware? 2. Surely some student and mentor have to be found for tackling this task. I could ask the Radeon and Linux DRM folks if they would be willing to join such an effort. (Though the AMD/ATI developers seem to be understaffed.) 3. Has anyone already thought about this idea?
Thanks,
Paul
[1] https://docs.google.com/document/d/1g8FMob25VZYxbWri2iFB8YiSL8gwF9vKJH3HGxr0... [2] http://review.coreboot.org/#/c/2531/5//COMMIT_MSG
Am 20.03.2013 11:28, schrieb Paul Menzel:
- Is that even possible for AMD/ATI hardware in their current design
with ATOM BIOS and firmware?
For simply initializing the chip, tracing what the driver does works just as well as on Intel chips.
The main issue is that OS drivers have an expectation to find those tables (closed source drivers less so than open source, it seems), so you'd need to provide them in one form or another.
Semi-automatically building new (and independent) ATOMBIOS tables from trace data is probably a hard problem.
Patrick
I like the idea. It would be a good project.
ron
* Patrick Georgi patrick@georgi-clan.de [130320 11:52]:
Am 20.03.2013 11:28, schrieb Paul Menzel:
- Is that even possible for AMD/ATI hardware in their current design
with ATOM BIOS and firmware?
For simply initializing the chip, tracing what the driver does works just as well as on Intel chips.
The main issue is that OS drivers have an expectation to find those tables (closed source drivers less so than open source, it seems), so you'd need to provide them in one form or another.
Semi-automatically building new (and independent) ATOMBIOS tables from trace data is probably a hard problem.
As far as I remember, ATOM BIOS is some sort of virtual machine that interprets a list of memory and IO instructions to initialize the hardware. Which is actually very similar to what Ron does now on the Sandybridge/Ivybridge hardware.
Maybe it's feasible to find and interpret the ATOM BIOS tables in the vga oprom of those machines as a first step instead of jumping into the blob?
A next step might be to port those tables to work with Ron's state machine? And/or SeaBIOS' VGA oprom sub project.
Related information: http://olivermcfadden.livejournal.com/11669.html http://www.phoronix.com/scan.php?page=news_item&px=NjA2NA
Regards, Stefan
Am 20.03.2013 19:36, schrieb Stefan Reinauer:
As far as I remember, ATOM BIOS is some sort of virtual machine that interprets a list of memory and IO instructions to initialize the hardware. Which is actually very similar to what Ron does now on the Sandybridge/Ivybridge hardware.
It is and the Linux drivers actually contain an interpreter. The command set is quite small, too.
The issue is to extract useful information (semi-automatically) and create new ATOMBIOS tables (since drivers rely on them, to my knowledge) that are independent enough so we can ship them under own (C).
Patrick
The issue is to extract useful information (semi-automatically) and create new ATOMBIOS tables (since drivers rely on them, to my knowledge) that are independent enough so we can ship them under own (C).
Best would be to ask AMD to include ATOMbios tables in vendorcode.
Does it sound unreal?
If we get the tables rest is easier, but I also looked into this some time ago and just running ATOMbios interpreter is definetly NOT enough to get some legacy VGA mode. I tried to get in touch with Xorg people and they thought i will need some "driver" for this.
Also please note that the option ROM is more or less just interpreter of the bytecode too.
Thanks Rudolf
Patrick
-
Patrick Georgi -
Paul Menzel -
ron minnich -
Rudolf Marek -
Stefan Reinauer