Amd Atombios Drivers For Mac

Amd Atombios Drivers For Mac

I've been thinking about doing some reverse engineering of AtomBIOS, the BIOS used on newer Radeon cards; R500, R600, etc. Ultimately I'd like to create a free software (GPL) replacement BIOS for at least one Radeon card. Please refrain from comments regarding my sanity.:-) As far as I know, AtomBIOS is a modular BIOS consisting of initialization code, an AtomBIOS script interpreter, AtomBIOS scripts, and some data tables. Having access to the AtomBIOS parser code should be helpful, although I suspect there are some sections that AMD have intentionally omitted.

I expect that I would have to build a flash memory programmer that could be connected to the card for reading/writing/verifying the flash memory. It's likely that the flash can be programmed via the GPIO registers, but one mistake means a bricked card; a flash programmer should, in theory, be a somewhat safer method. Oh, if anyone knows the part number of the flash memory used on any Radeon card, post a comment. It's neigh on impossible to find this information online. I guess I'll have to look at some of my Radeon cards. comments regarding my sanity.:-) Great project to kill some time & boredom. Totaly sane for sure.;) Surely, atomB & r500+ limit the effort somewhat: you'd get much more interrested users:) for r400 and below, i guess.

Amd atombios graphics driver

Did you contact LinuxBIOS project? They might be not that interested in 'full-featured' re-implrmentation of prop.technology, but they have that flashrom tool (natural choice for vga bios flasher funcionality integration to me, and they just started to imlpement SPI parts flashing), plenty of rev.-engeering experts at one place (some of them undoubtfully have much to say WRT vga BIOS-es -) ). Free-VGA-BIOS, someone?

Luc Verhaegen made BIOS-less:)) X driver for VIA / Unichrome vga and booted that on a device w/LinuxBIOS. Best vga BIOS - no vga BIOS, in the end? I haven't contacted the LinuxBIOS project yet; this is just a side project which I may look at developing. Although if the LinuxBIOS project is developing tools for flashing the BIOS on graphics cards, that would certainly be useful. I'm not completely sure what happens when you power up a system with a graphics card that has a bad BIOS. I would need a hardware flash programmer if the system BIOS decides to be 'helpful' and halt at POST. Otherwise it could likely be recovered by software flashing.

I'm one of the LinuxBIOS developers, so I'm probably qualified to answer these questions. We have code to check the signature of option ROMs (e.g.

Video BIOS) and (depending on the configuration) can skip execution if the signature is not there (as would probably be the case if flashing failed). You're of course free to disable execution of option ROMs unconditionally if you want. Feel free to either join our mailing list or drop by in on freenode (which is an alias to ). Regards, Carl-Daniel Hailfinger. I'm not completely sure what happens when you power up a system with a graphics card that has a bad BIOS If the card is configured as secondary and there's a nother card in the system: Pretty much nothing peculiar happens. Modern BIOS only boot the BIOS of the first card and rely on the OS for subsequent initialisation of the secondary card. You could, say, plug a last-gen PCIe card that you want to hack, plug some old PCI card for backup, and configure the BIOS to boot on that card first.

Amd Atombios Drivers For Mac

If you brick your card, only the second head of your dual setup will open, but you'll still be able to recover the card from there. (Not I happen to have an old AGP+PCI dual card setup, with a half-fried AGP card). Yes, it would be interesting to have some some insights in the AtomBIOS. This would help to make ATI cards work on some more hardware platforms. For me a special interesting point would be: Can we support the card without the AtomBIOS? I own an MacBookPro and it would be interesting to know if I can boot Linux directly via EFI (probably without using AtomBIOS?).

But I'm not sure, if it's worth the time to implement a complete replacement, because it would be very time consuming until you finished it and in the meantime AMD replaced it together with some new hardware. I think that AtomBIOS will be around for quite some time; AtomBIOS is AMD/ATI's replacement for the legacy BIOS, which is a blob of x86 code unique to every card. As far as I know, AtomBIOS uses a simple assembly language (AtomBIOS scripts) to perform most of the work; the interpreter just executes these scripts. The scripts may differ from card to card, but all cards could share the same generic interpreter code. In fact, there are a few clues suggesting the AtomBIOS parser which was released by AMD may also be used by the BIOS. #if (PARSERTYPE!=DRIVERTYPEPARSER) BIOSSTACKMODIFIER; #endif Currently I'm just guessing and haven't looked deeply into the AtomBIOS yet, but it's quite interesting. I got linked to some information on replacing the 64K ROM on a Radeon 7000 PCI card with a 128K version to.

Convert mpeg1 for mac. This page confirms the ROM is Serial Flash Memory using the SPI interface. Although I haven't completely read the datasheet linked on the page, it should be a lot easier to program the SPI flash than the much larger parallel flash; it would also be easier to (de-)solder when something goes wrong. It might be possible to build something similar to the but for SPI flash memory. Anyone got any ideas? I really do need to get more into electronics design. Hi Oliver, I'm one of the LinuxBIOS developers. Some of our project members are developing a BIOS-Saviour-like tool for SPI flash.

Amd Atombios Drivers Download

It's called FLASH-PLAICE. We recently have been notified about another project similar to the FLASH-PLAICE that may be useful as well. I have written the (Super I/O translation chip based) SPI flashing code in flashrom (our BIOS flashing tool) and am interested in adding SPI support for more chipsets, regardless of which card the SPI chips live on. Join our mailing list and ask away. Regards, Carl-Daniel Hailfinger.

Comments are closed.