-----Original Message----- From: Rudolf Marek [mailto:r.marek@assembler.cz] Sent: Tuesday, May 28, 2013 12:24 PM To: David Hubbard Cc: ron minnich; Coreboot; Deucher, Alexander Subject: Re: [coreboot] Native init for AMD cards
Hi David,
I read the kernel sources today, looking for a way of doing native init for
AMD boards like the F2A85-M.
Comments welcome on the insanity of this proposal :)
In fact I did the same some time ago, but there is a problem with the AtomBIOS and the graphical data paths.
- Do coreboot developers have contact with the radeon driver
developers? A
little nudge from time to time could keep a project like this on track.
I was speaking with Alex (I put him on CC) My Q was:
My plan (which may sound bit naiive), is/was to Initialize the GPU with AsicInit (so simple run of AtomBIOS interpreter) and then switch it to
legacy VGA
mode and handle this with SeaBIOS VGA BIOS. Maybe there is a gap
between -
setting up a legacy VGA and AsicInit, I don't know, possibly I need to detect
what kind of output is used, but all I need is simple text mode
Please can you throw some light on this topic?
Alex told me:
The AsicInit table just performs low level setup on the asic, it doesn't mess with the displays at all. The radeon vbios has real mode x86 code that gets executed at post or via vbe calls to read in the information in the atombios tables, figure out the display topology and detect and light up whatever displays are attached. You would need to implement that functionality in your vbios replacement. If you want a bios console, you'll have to use the open source radeon driver as a guide to how to write a vbios replacement that enumerates and lights up the displays.
END
Also it turned out that the bytecode is there for the OEM so the changed topology does not need the new VBIOS assembly but just the AtomBIOS bytecode. Which is quite bad, because the VBIOS is depending on how it is routed and may only work with similar boards even when chipset is same. We would have to find out a way how to include the AtomBIOS in some form in the coreboot or re- write it somehow, because the bytecode is not even "property" of AMD but OEM and radeon driver needs that to be present in a rom. Maybe it would be possible to write some commmon init and handle just small changes in the bytecode.
For now, I would say kind of "reply" init might work, it depends if your goals are similar like we have with intel, so just graphic framebuffer for grub2 or something like I had in my mind.
You'll hit the same issue regardless of whether you are using radeon hw or some other vendor. On just about any modern hardware it will end up being pretty complex. You need to: 1. initialize the chip 2. determine the display topology 3. determine which displays are connected 4. light up the connected displays
There's not really a simple way to do it due to the complexity of modern display hardware. Whether you are using the legacy bios or UEFI, you end up with a basic driver for the GPU in order to light up the console. Coreboot would need something similar if you want to support a bios console. That said, you can skip a lot of what the open source driver does since much of it is related to the acceleration hardware. All you really need to do is call AsicInit, set up the GPU's memory controller, and port the atombios display handling code. You can skip the GART/VM, CP, GFX, DMA, UVD, interrupts, etc. init. The legacy vbios and GOP driver modesetting logic is pretty similar to the radeon driver. The whole reason for using atombios is to have a common set of routines for modeseting shared across vbios and drivers and to provide a common simplified abstraction to constantly changing display hardware interfaces.
Alex