AMD Publishes New SB Register, Programming Docs

[phoronix]

Phoronix: AMD Publishes New SB Register, Programming Docs

While most of the time getting new documentation out of AMD is for their ATI graphics processors, today they have pushed out four documents that amount to several hundred pages of information covering their latest Southbridges. The AMD SB700/710/750 chipsets are now well documented in these NDA-free programming guides that also cover the registers for this hardware.Over at AMD Developer Central is the AMD SB700/710/750 Register Reference Guide, AMD SB700/710/750 BIOS Developerâ??s Guide, AMD SB700/710/750 Register Programming Requirements, and lastly is the AMD SB710 Databook.Sure, programming guides and register descriptions for a southbridge is not nearly as exciting as for the latest ATI GPU, but this information is what the CoreBoot developers (the same ones working on Flashrom) have been after for a while...

http://www.phoronix.com/vr.php?view=NzM3Ng

[mirv]

cheers AMD!

[Pfanne]

now we only need a company that focuses on tinkering a complete oss experience arround amd hardware...
something like the open source apple with hard+software that works together perfectly.
so you can get your pear (my imaginary company's name) computer and you know itll work perfectly with linux...
unlike other companies like acer or asus they dont have to sell crippled hardware with their linux computers, because they cant lose any microsoft partnership contracts....
haaaaaaa, in my imaginary world everything would be sooooooooooo fine...

[DanL]

so you can get your pear (my imaginary company's name) computer

The Pear Computers name has already been used in multiple places as a way to imply "Apple" without copyright infringement. Try again.

[snogglethorpe]

Thanks AMD!

It's so nice to finally see more major hardware companies actually getting the point that widespread knowledge of how to use your hardware is good, and helps you sell more chips...

I work for a big semiconductor company, and have met many older managers who simply cannot come to terms with idea of giving anything away without strict conditions and renumeration, even if restricting information in the end hurts the company far more than any advantage it confers. There's a sort of ingrained conservatism and downright control-freakery that seems very hard to get rid of except though generational change.

[bridgman]

Here it's mostly us old guys driving the open source support

[Louise]

This is so cool!

CoreBoot really is an important project that many don't care much about. Apparently also Michael

But it really is important to have an open source BIOS, as it is possible for the BIOS vendors to include a secret hyper visor that in "best case" "only" monitors what you do.

In "worst" case, it can forbid you from doing some things.

So CoreBoot really is important, and anything that helps that is exceeding good news

Also with CoreBoot you would be able to encrypt your harddrive, and have CoreBoot ask for the passphrase.

[deanjo]

But it really is important to have an open source BIOS, as it is possible for the BIOS vendors to include a secret hyper visor that in "best case" "only" monitors what you do.

In "worst" case, it can forbid you from doing some things.

Heh, that's just plain paranoia talking.

[Kano]

Working Coreboot on latest AMD boards would be very interesting for me - those docs will certainly help that. Intel docs seem to be very outdated, only very old chipsets are supported. As you can add custom payloads it should be really fun to use, hopefully the bios chip is on a socket

[unix_epoch]

The most annoying thing about proprietary BIOSes in my opinion is that they are completely unpredictable in their use of SMIs (the so-called ring -2 that people get paranoid about). My old Sony laptop had random apparent hangs for as long as 10-20ms (fatal to the audio project I was trying to use it for). Downgrading its BIOS fixed the problem, which was caused by system management interrupts taking too long to give control back to the OS.

SMIs can be used for good, of course, like updating ACPI data, monitoring CPU temperature, and adjusting fan speed, but in a real operating system, I'd much rather do that using a low-priority preemptible thread than a realtime priority non-preemptible SMI.