source-based replacement for video bios on ivybridge -- I'm stuck!

source-based replacement for video bios on ivybridge -- I'm stuck!

[ron minnich]

Dear intel graphics experts:

I am looking at trying to get coreboot to move away from binary video
bios on google chromebook platforms. The current target is an
ivybridge system. We'd like to get minimal graphics going with a
source-based startup code in coreboot, such that we can avoid the
issues that come with binary video bioses.

The good news is that the kernel driver works fine without a video
bios having been run -- the new samsung chromebox/chromebook work in
this manner.

As an experiment, I have used cocinnelle to extract the relevant
driver functions from the kernel (in this case 3.4.2) and am running
them in user mode. I've had good luck with prototyping hardware
drivers for coreboot in user mode, and this approach is *almost*
working on this graphics hardware.

You can see the result here: http://pastebin.com/3e77Y66C

The I2C is working, and I'm recovering EDID and the mode. I can
control the panel backlight. I can easily program the GTT and other
simple functions.

The issue now is that I am not able to get the link trained. I figure
I'm misordering or missing some crucial step, and on the off chance
that some one of you can look at that output and say "Ron you idiot!
You're missing *this* step" I've posted it.

If anyone has any thoughts on this I'd welcome them. This thing is
close, and I feel it is possible, but I've obviously got something
wrong.

Thanks in advance for any help or advice you can give me!

ron

Re: source-based replacement for video bios on ivybridge -- I'm stuck!

[Daniel Vetter]

On Wed, Aug 01, 2012 at 06:47:58PM -0700, ron minnich wrote:
> Dear intel graphics experts:
> 
> I am looking at trying to get coreboot to move away from binary video
> bios on google chromebook platforms. The current target is an
> ivybridge system. We'd like to get minimal graphics going with a
> source-based startup code in coreboot, such that we can avoid the
> issues that come with binary video bioses.
> 
> The good news is that the kernel driver works fine without a video
> bios having been run -- the new samsung chromebox/chromebook work in
> this manner.
> 
> As an experiment, I have used cocinnelle to extract the relevant
> driver functions from the kernel (in this case 3.4.2) and am running
> them in user mode. I've had good luck with prototyping hardware
> drivers for coreboot in user mode, and this approach is *almost*
> working on this graphics hardware.
> 
> You can see the result here: http://pastebin.com/3e77Y66C
> 
> The I2C is working, and I'm recovering EDID and the mode. I can
> control the panel backlight. I can easily program the GTT and other
> simple functions.

Sounds rather awesome ;-)

> The issue now is that I am not able to get the link trained. I figure
> I'm misordering or missing some crucial step, and on the off chance
> that some one of you can look at that output and say "Ron you idiot!
> You're missing *this* step" I've posted it.
> 
> If anyone has any thoughts on this I'd welcome them. This thing is
> close, and I feel it is possible, but I've obviously got something
> wrong.
> 
> Thanks in advance for any help or advice you can give me!

DP link training is a feeble beast, and we've fixed quite a few issues
just recently. I suggest you retry with the drm/i915 code from 3.6-rc1, in
particular the following two patches:

commit 0d71068835e2610576d369d6d4cbf90e0f802a71
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Jun 29 16:03:34 2012 -0300

    drm/i915: try to train DP even harder

commit 2514bc510d0c3aadcc5204056bb440fa36845147
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Jun 21 15:13:50 2012 -0700

    drm/i915: prefer wide & slow to fast & narrow in DP configs

Cheers, Daniel

[Note that not all these fixes are cc: stable, since we fear that they
might blow up on onther configurations - these things always need tons of
testing.]
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: source-based replacement for video bios on ivybridge -- I'm stuck!

[ron minnich]

Thanks for the suggestions, I did move forward to 3.6-rc1.

It gives me lots of messages I expect, but does not yet work...

http://pastebin.com/RLp5qjQX

I'm still convinced there is some basic thing I'm not setting up
right; still getting these pipe0 stuck messages. Now, the one thing
I'm definitely doing different than the driver, after a discussion
with Jesse, is not setting up the ring or status page. It's not
supposed to be needed for this basic set up.

It all starts to go sour here:
[000000.0] [drm:ironlake_edp_panel_on], Turn eDP power on
[000000.0] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle
[000000.0] [drm:ironlake_wait_panel_status], mask b800000f value
00000000 status 00000000 control abcd0008
[000000.0] [drm:ironlake_wait_panel_on], Wait for panel power on
[000000.0] [drm:ironlake_wait_panel_status], mask b000000f value
80000008 status 0000000a control abcd000b
[000000.0] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
[000000.0] [drm:ironlake_panel_vdd_off_sync], PCH_PP_STATUS:
0x80000008 PCH_PP_CONTROL: 0xabcd0003
[000000.0] [drm:intel_dp_start_link_train], too many voltage retries, give up

And then we get no further (after several iterations) than the voltage
retries. Any further suggestions welcome :-)

ron

Re: source-based replacement for video bios on ivybridge -- I'm stuck!

[Daniel Vetter]

On Thu, Aug 09, 2012 at 10:10:05AM -0700, ron minnich wrote:
> Thanks for the suggestions, I did move forward to 3.6-rc1.
> 
> It gives me lots of messages I expect, but does not yet work...
> 
> http://pastebin.com/RLp5qjQX
> 
> I'm still convinced there is some basic thing I'm not setting up
> right; still getting these pipe0 stuck messages. Now, the one thing
> I'm definitely doing different than the driver, after a discussion
> with Jesse, is not setting up the ring or status page. It's not
> supposed to be needed for this basic set up.

Yeah, this should all work without ring and status pages ...

> It all starts to go sour here:
> [000000.0] [drm:ironlake_edp_panel_on], Turn eDP power on
> [000000.0] [drm:ironlake_wait_panel_power_cycle], Wait for panel power cycle
> [000000.0] [drm:ironlake_wait_panel_status], mask b800000f value
> 00000000 status 00000000 control abcd0008
> [000000.0] [drm:ironlake_wait_panel_on], Wait for panel power on
> [000000.0] [drm:ironlake_wait_panel_status], mask b000000f value
> 80000008 status 0000000a control abcd000b
> [000000.0] [drm:ironlake_edp_panel_vdd_off], Turn eDP VDD off 1
> [000000.0] [drm:ironlake_panel_vdd_off_sync], PCH_PP_STATUS:
> 0x80000008 PCH_PP_CONTROL: 0xabcd0003
> [000000.0] [drm:intel_dp_start_link_train], too many voltage retries, give up
> 
> And then we get no further (after several iterations) than the voltage
> retries. Any further suggestions welcome :-)

If this is cpu edp, you might want to try the giant modeset-rework branch
of mine at:

http://cgit.freedesktop.org/~danvet/drm/log/?h=modeset-rework

This fixes (among tons of prep work) and ordering issue with our cpu edp
code, which at least on ivb results in stuck pipes (and black screens).

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: source-based replacement for video bios on ivybridge -- I'm stuck!

[ron minnich]

OK, thanks to the great suggestions and help I found on this list I am
now lighting up the display, i.e. clock recovery and so on work, the
display is trained, and it seems I am getting
data from memory to the display. Now I'm trying to understand some
other things.

I can set the GTT entries, and as an experiment I set them to start at
physical 0. i.e. [0] = 1, [1] = 4097, and so on. The low order bits
are the same as the BIOS settings: Valid is set but no other bits.
Now, as I change the GTT entries to point at different windows of low
memory, what is on the display changes -- I'm essentially looking at
kernel memory. But what surprised me a bit was I was hoping to
get a pretty dynamic display as the contents of kernel memory changed.
Such is not the case -- the display is static. So I think I'm missing
something else, any ideas? I think the display hardware is kind of
running
as each time I change the gtt the image on the screen changes in a
very consistent way, e.g. if I increase the value of all gtt's by 1
MiB then the screen scrolls up.

Next, the GSM on this system is at ADA00000. If I leave the entries
set to what the bios sets, e..g
[0] = 0xada0001
[1] - 0xada1001

etc. then I would expect I can mmap bar[2] and store into that region.
But what happens instead, is that nothing changes when I write to the
mmap'ed region. Is there some other issue I am getting wrong here?

Finally, if I dump what the data I mmap at bar[2], then change the
gtt, then dump it again, it does change. I think I have the bar values
right, but ...

Thanks again for your help.

ron