Almost A Decade Later, RadeonHD Stories Still Coming To Light

[rene]

We live in a post-fact society.

Nobody cares about your fancy facts and figures, if their gut says there is a huge virtual machine language full of bugs then there must be.

I did not say the VM is buggy, I said potential BIOS / card bugs. If you want to rely on the vendors driver go use Windows, where everything is closed and supposedly bug free.

With AMDs arguments we would need 100++ custom VMs in the kernel for all the other graphic chips, WiFi region code, or RAID setups, you know because the vendor thinks it is too complicated to do in native code and publish docs and such. Everything would be plagued by obscure bugs just like we used from the decades of closed BIOS bugs experience. And as everything is controlled by byte code stored in the hardware you can not even just fix them.

This is simply not what we want open source drivers for.

[bridgman]

Fine, your VM is smaller then Qemu. Does not change the point that this is a classic example of over engineering a trial problem. Does the open source Intel or Nouveau driver also include a Virtual Machine for their display port mode setting?

Hold on, you seem to be jumping around a bit. Are you arguing about the use of the AtomBIOS interpreted bytecode in our VBIOS (which we need for CPU independence and to fit a lot of code into a small ROM) or just about the use of AtomBIOS calls in the modesetting driver ?

Your earlier posts seemed to be attacking AtomBIOS itself but your more recent posts seem to be more focused on its use in the driver. If so, that is easier to deal with since the DAL/DC effort replaces a lot of the AtomBIOS calls with native code, replacing the implicit sharing model with an explicit one.

[starshipeleven]

Fine, your VM is smaller then Qemu. Does not change the point that this is a classic example of over engineering a trial problem. Does the open source Intel or Nouveau driver also include a Virtual Machine for their display port mode setting?

No, overengineering is installing a full-blown android kernel in a modem device that has dozens of MB of ram (like most modern qualcomm modems, and also huawei ones) you then control by AT commands like any other dumb modem.

Using low-level VMs with a few dumb optcodes is not as bad as you think, and anyway that's stuff that would be turned in a blob, either flashed in a ROM or loaded at runtime anyway. Hardware is NOT open, so that's not "wrong" per-se.

[michaelb1]

And another point: Open source OS, drivers, libraries and everything has also to do with the freedom an ability to fix bugs. When there are bugs in ACPI, and AtomBIOS tables one can do nothing to fix them. Except putting workarounds and hack in the AtomBIOS interpreter glue.

I assume you are talking about moving all of the VBIOS code and table data to the driver, and maintaining thousands of different table sets in the driver ? Isn't that the same as treating *every* piece of hardware as needing a workaround and hack in the AtomBIOS interpreter glue ?

bridgman, why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work

It's certainly do-able but AFAIK no vendor in the world actually does it because it makes new hardware launches somewhere between impractical and impossible. Every new card, every new laptop would potentially need a new driver revision to function.

Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it

[michaelb1]

TEST .

[michaelb1]

Cant write anything... Why?

[rene]

Hold on, you seem to be jumping around a bit. Are you arguing about the use of the AtomBIOS interpreted bytecode in our VBIOS (which we need for CPU independence and to fit a lot of code into a small ROM) or just about the use of AtomBIOS calls in the modesetting driver ?

Your earlier posts seemed to be attacking AtomBIOS itself but your more recent posts seem to be more focused on its use in the driver. If so, that is easier to deal with since the DAL/DC effort replaces a lot of the AtomBIOS calls with native code, replacing the implicit sharing model with an explicit one.

I was not jumping around. The one jumping around in this thread is apparently you. I was always talking about native OS drivers. I could care less what AMD is doing in their BIOS (as long as it at least boots, and get's out of my way, open source BIOS welcome though, too).

Btw. you are fighting to wrong guy here. I never wanted to use a totally closed Nvidia binary only blob, I even always promoted the "more" open AMD cards for use on Linux.

The use of a virtual machine for mode setting is just unnecessary nonsense.

[rene]

No, overengineering is installing a full-blown android kernel in a modem device that has dozens of MB of ram (like most modern qualcomm modems, and also huawei ones) you then control by AT commands like any other dumb modem.

Using low-level VMs with a few dumb optcodes is not as bad as you think, and anyway that's stuff that would be turned in a blob, either flashed in a ROM or loaded at runtime anyway. Hardware is NOT open, so that's not "wrong" per-se.

I dont undertand why you jump to android modems (this really exists?).

That hardware is not open is not set in stone, and apparently also changing - see RiscV et al.

Also where should that stop? For me it is for example also not acceptable to have closed WiFi firmware. How should I know what backdoor is lurking inside there. And if this is not ok for WiFi chips, why should it be ok for some GPU? Mesa and LLVM have already all the real instruction secrets open source, and something as trivial and simple as mode setting needs a VM? Ridiculous.

[agd5f]

bridgman, why you don't just open source the complete source code of VBIOS, to let the open source community improve it and fix some bugs? With the help of flashrom open source project, anyone is able to reflash their VBIOS through In-System-Programming. We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work



Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! A win-win solution. Why not do it? For the bystanders like me, it gives an impression that either 1) VBIOS source code is a horrible quality, too ashamed to release it to public 2) VBIOS contains some hidden backdoors, hence the need for secrecy 3) AMD is not that friendly to open source community, if instead of sharing what you already got, you want the people to start reinventing the wheel and waste countless of unpaid work hours on it

It is effectively open source. The data tables are all documented in atombios.h. They are just data structures. The command table parameters are all documented in atombios.h (also just data structures). The command tables are all written in byte code to begin with. The source to the interpreter is open source so you can dump command tables and see exactly what they are doing. You can even write your own command tables in byte code or edit exiting ones if you wanted to. Those are the only things the driver uses from the vbios. The whole point of the data and command tables is to encapsulate board specific configuration details on the actual board itself so that the driver doesn't need explicit knowledge about every board configuration out there.

[bridgman]

I was not jumping around. The one jumping around in this thread is apparently you. I was always talking about native OS drivers. I could care less what AMD is doing in their BIOS (as long as it at least boots, and get's out of my way, open source BIOS welcome though, too).

Btw. you are fighting to wrong guy here. I never wanted to use a totally closed Nvidia binary only blob, I even always promoted the "more" open AMD cards for use on Linux.

The use of a virtual machine for mode setting is just unnecessary nonsense.

OK, maybe I misread the context, sorry. Most of your pushback about using an interpreter came when we were talking about what AtomBIOS did besides modesetting.

Anyways, we can talk about this forever but I don't see things changing any time soon. To summarize:

1. We use an interpreter in VBIOS in order to (a) fit a lot of functionality into a small ROM, (b) give us a degree of CPU independence. My understanding is that this is pretty common practice; either way it's not likely to change unless OEMs buying AMD chips are willing to spend more $$ on the ROM for our hardware than for competitors hardware AND we are willing to go back to having different BIOS code for each of the different CPUs our chips are used with.

... We just don't have the original source code of VBIOS, and the creation of open source VBIOS from scratch is like reinventing the wheel - a huge wheel, which is way too much for unpaid work. Just share the complete source code of VBIOS and let the open source community fix the bugs for you for free! ...

2. As agd5f said, the VBIOS source code is bytecode similar to what you get out of the disassembler, although the disassembler output is formatted more neatly. It's not like there is a single master copy of VBIOS source written in C that could be "opened once" - every HW vendor tweaks their BIOS images before production and AFAIK those changes are not ours to publish.

Relatively more of the changes are in data tables than in command tables but both get changed and so we need to use both in the driver if we want driver functionality to correctly match the HW config. There are literally thousands of different HW subsystems, each with their own VBIOS image and hence each with their own slightly different source code... and the associated HW differences DO generally need to be considered when the driver runs.

3. A couple of people have started projects to replace VBIOS with a fully open solution, but my impression is that they all run into the same issues:

- initial implementation is straightforward but ongoing maintenance is a big and boring effort nobody wants to own
- you lose CPU independence unless you are willing to maintain AND TEST a lot more different VBIOS builds
- without an interpreter the resulting implementation won't fit in the on-card ROM unless you cut back functionality

We make enough information for an open source BIOS replacement available as part of the open source driver effort (data table & command table headers, bytecode interpreter, open source drivers using the tables) although I don't think we support VBIOS re-flashing in general. It is easy to get the same result by over-riding tables in the driver code, however, and I believe there is an existing quirk mechanism.

4. Over time I think you will see a trend away from using AtomBIOS calls simply because ROM size limits the amount of complexity that can be supported in ROM-resident tables while HW complexity is continuing to grow as quickly as ever.

My understanding is that DAL/DC makes somewhat less use of AtomBIOS calls but it also replaces a relatively painless sharing model (drivers for all OSes/platforms make the same AtomBIOS calls for the fiddly HW-specific bits) with a much-harder-to-sell sharing model (drivers for all OSes/platforms share native driver code for the fiddly HW-specific bits).

I understand that this seems unnecessary (and maybe even counter-productive) if you believe that modesetting is trivial, but I don't know how to reconcile your views on modesetting with the views of developers working on the code at different vendors. Once we figure out how to close that gap the rest of the discussion should become easier.