Re: [coreboot] Native init for AMD cards

[Rudolf Marek]

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.

Thanks
Rudolf

Native init for AMD cards

[David Hubbard]

On Mon, May 27, 2013 at 11:46 PM, ron minnich  wrote:
> On Mon, May 27, 2013 at 9:45 PM, David Hubbard
>  wrote:
> > How hard would it be to import the kernel code into coreboot

directly?
> >
>
> don't. You should do a lot of extraction using coccinelle. And even
> then, there's lots of work to do. I hope to start commits next week
> and hopefully this will provide some ideas.

Ok I'll not pull the entire radeon driver. :)
> > It feels wrong to add so much code to coreboot.
>
> So, don't add it. The i915 support is slowly boiling down to a few
> hundred lines and that should be your goal.

This sounds right. The i915 support is boiled down to just lighting up the
connected displays and setting up a linear framebuffer?

There is a balance, since the radeon driver does not come with extensive,
complete documentation like i915. A successful project will most likely
need to rely on the open source radeon driver upstream for the time being.
> Also, the kernel uses
> generic code to switch to device specific functions. That makes sense
> for a kernel, because it boots on many chipsets and many vga devices.
> It makes no sense for firmware, because we have so much we already
> know -- what chipset, what vga, etc.. Remove generic code and create
> device specific functions with a reasonable API.

Unless a larger team is available, it seems wiser to limit the complexity
of the problem by applying the linux radeon driver. I mean, keep it as
intact as possible and remove the unneeded code. That should even be
compatible with the i915 API, namely modesetting and linear framebuffer for
grub2.

Here's a way to slice the code:

Some low-level parts are nicely self-contained and can be incorporated
without much work: atombios and CRTC for example.

Coccinelle can be used to remove the unneeded code from the asic-specific
files.

The primary init function can be rewritten as a boiled-down set of calls to
the pieces provided by coccinelle.

The big caveat --

We may not know ahead of time what type of GPU it is. It is possible for
.config to select a GPU, but it seems smarter for .config to enable radeon
support -- which supports all radeon GPUs.

If the user switches their GPU (or APU) later, imho coreboot should still
boot. This is in line with what existing BIOSes do.
> > Is a modular approach better? A payload to modeset or some sort of

driver
> > model would be nice.
>
> No, what's best is a simple set of functions with a simple API. See
> superio for example. Or give it 2 more weeks and see what is coming
> :-)

Yes, stripping radeon down makes sense.

What's coming in 2 weeks? What commits are you working on for next week?

On Tue, May 28, 2013 at 10:24 AM, Rudolf Marek  wrote:
> 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

The open source radeon driver is a good place to start.
> 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.

Yes, I think just a framebuffer for grub2 is more than enough to take on
right now.

Regards,
David

Native init for AMD cards

[Deucher, Alexander]

> -----Original Message-----
> From: Rudolf Marek [mailto:[e-mail]]
> 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

Native init for AMD cards

[ron minnich]

well, we're lighting up 4 laptop panels from source today. So it's doable.

ron