Intel Eagle Height evaluation board support

[Thomas JOURDAN]

Hi

This series of patches add support in coreboot-v2 for the Intel Eagle
Heights evaluation board
(http://www.intel.com/design/intarch/manuals/316639.pdf). This board
has a Core 2 Duo Mobile SL9380 (FSB 800Mhz - 45nm) processor with a
SCH i3100 chipset (northbridge and southbridge in the same package).
It has 2 GB of ECC memory, 6 USB, 6 Sata, 2 serial, 1 parallel, PS/2
keyboard and mouse, 3 PCIe 4x slots and 1 PCI 32bits/33Mhz slot.

Features :
* CAR
* CBFS
* a little bit of ACPI
* AHCI sata (legacy IDE mode available).

Things that work :
* Ram with ECC (memtest ok)
* All PCI / PCIe slot
* All sata ports,
* serial ports, PS/2 keyboard

Things not tested (but should work) :
* PS/2 mouse
* parallel port
* hpet
* virtualization

Things broken :
* reset (the config file only has a fallback image and don't really
understand the concept of failover / fallback / normal image)
* vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
graphics card. Coreboot fails to execute the vga rom (either x86emu,
yabel or real mode). There is an exception 0x06 and everything will
freeze. It could be the loadall instruction
(http://en.wikipedia.org/wiki/LOADALL). I'll investigate tomorrow with
a probe to understand what happens.

Some remarks :
- the mptable is based on the RCBA interrupt routing config registers,
but not the acpi table
- the mmconf is hardcoded to 0xE0000000 but I don't understand how the
resource allocate can properly handle it. If you change the mmconf
address in the northbridge code, don't forget to adjust the associated
motherboard resource in the DSDT.

For lucky people (like me) who owns the board and wants to give it a
try, flashrom won't work with the original bios. The board has a
SST49LF008A (FWH 1MB) on a PLCC32 socket, which is cool. But the
default bios will lock down half of the chip. Flashrom will fail to
properly detect it. To bypass this, I forced flashrom to detect the
chip as a 49LF004A (512KB). This way, I can write a first 512KB
coreboot file. After, no more problems, the full 1MB are available in
flashrom. Of course, no problem if you use an external flasher.

Regards,
Thomas

[Myles Watson]

On Tue, Jun 23, 2009 at 12:42 PM, Thomas JOURDAN
wrote:
> Hi
>
> This series of patches add support in coreboot-v2 for the Intel Eagle
> Heights evaluation board

Welcome to the project!

http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

If you sign off your patches they can be reviewed, acked, and committed.
> Things broken :
> reset (the config file only has a fallback image and don't really
>
> understand the concept of failover / fallback / normal image)
> vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
>
> graphics card. Coreboot fails to execute the vga rom (either x86emu,
> yabel or real mode). There is an exception 0x06 and everything will
> freeze. It could be the loadall instruction
> (http://en.wikipedia.org/wiki/LOADALL). I'll investigate tomorrow with
> a probe to understand what happens.

You could try having SeaBIOS enable your ROM.  There have been several cases
where SeaBIOS was less picky than the others.

http://www.coreboot.org/SeaBIOS
> the mmconf is hardcoded to 0xE0000000 but I don't understand how the
>
> resource allocate can properly handle it. If you change the mmconf
> address in the northbridge code, don't forget to adjust the associated
> motherboard resource in the DSDT.

The current resource allocator can't handle it.  If you want to test the new
one,  you can apply the patches from this mail:

http://www.coreboot.org/pipermail/coreboot/2009-May/048928.html

Just make sure that your mmconf register gets hardcoded and set in the
read_resources function with the flags IORESOURCE_FIXED |
IORESOURCE_ASSIGNED

The new allocator avoids fixed resources, but can only allocate to one side
of them.  I recommend putting your resource as high as you can.

Make sure limit > base.

If you send me a log from before and after the patch it'll help both of us
:)

For lucky people (like me) who owns the board and wants to give it a
> try, flashrom won't work with the original bios. The board has a
> SST49LF008A (FWH 1MB) on a PLCC32 socket, which is cool. But the
> default bios will lock down half of the chip. Flashrom will fail to
> properly detect it. To bypass this, I forced flashrom to detect the
> chip as a 49LF004A (512KB). This way, I can write a first 512KB
> coreboot file. After, no more problems, the full 1MB are available in
> flashrom. Of course, no problem if you use an external flasher.

Very nice.

Thanks,
Myles

[Thomas JOURDAN]

Hi
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
>
> If you sign off your patches they can be reviewed, acked, and committed.

Done !
> You could try having SeaBIOS enable your ROM.  There have been several cases
> where SeaBIOS was less picky than the others.
>
> http://www.coreboot.org/SeaBIOS

I forgot to mention that also tried seabios without success.
> If you send me a log from before and after the patch it'll help both of us
> :)

I'll try this patch and report my results.

Regards,
Thomas

[Myles Watson]

> > http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure
> >
> > If you sign off your patches they can be reviewed, acked, and committed.
>
> Done !

Thanks.  As I glanced through I didn't see any copyright lines from you.  It
would speed the reviewing process if you sent the patch as a patch against
an existing board so we could see what you're changing.  I realize that's
more work for you.
> > You could try having SeaBIOS enable your ROM.  There have been several
>
> cases
> > where SeaBIOS was less picky than the others.
> >
> > http://www.coreboot.org/SeaBIOS
>
> I forgot to mention that also tried seabios without success.

After the resource allocator, I'd be interested in a log from that failure.
> > If you send me a log from before and after the patch it'll help both of
>
> us
> > :)
>
> I'll try this patch and report my results.

Thanks,
Myles

[Thomas JOURDAN]

Hi
> Thanks.  As I glanced through I didn't see any copyright lines from you.  It
> would speed the reviewing process if you sent the patch as a patch against
> an existing board so we could see what you're changing.  I realize that's
> more work for you.

I'm not sure to understand what form you expect the patch to have ?
> > > You could try having SeaBIOS enable your ROM.  There have been several
> >
> > cases
> > > where SeaBIOS was less picky than the others.
> > >
> > > http://www.coreboot.org/SeaBIOS
> >
> > I forgot to mention that also tried seabios without success.

I attached a log file for seabios.

Thomas

[Myles Watson]

On Wed, Jun 24, 2009 at 6:34 AM, Thomas JOURDAN wrote:
> Hi
> > Thanks.  As I glanced through I didn't see any copyright lines from you.
>
> It
> > would speed the reviewing process if you sent the patch as a patch
>
> against
> > an existing board so we could see what you're changing.  I realize that's
> > more work for you.
>
> I'm not sure to understand what form you expect the patch to have ?

It's not an expectation, just a suggestion to speed the review process.  I
haven't looked which board you based your port on, but lets pretend it was
the Kontron board.  You could supply a patch for review that turned the
Kontron board into your board.  That patch should be _much_ smaller and
easier to review.

Then we could do something like

mkdir src/mainboard/intel/eagleheights
svn cp src/mainboard/kontron/986lcd-m/* src/mainboard/intel/eagleheights
apply your patch
commit

Thanks,
Myles

[Myles Watson]

> > > > You could try having SeaBIOS enable your ROM.  There have been
>
> several
> > > cases
> > > > where SeaBIOS was less picky than the others.
> > > >
> > > > http://www.coreboot.org/SeaBIOS
> > >
> > > I forgot to mention that also tried seabios without success.
>
> I attached a log file for seabios.

I don't see the lines setting the VGA bridge bits.

It should say something like "Allocating VGA resource PCI 3:00.0" and then
list the bridges.

Is your log level debug?  Do you have CONFIG_CONSOLE_VGA set?

Thanks,
Myles

[Kevin O'Connor]

On Wed, Jun 24, 2009 at 02:34:10PM +0200, Thomas JOURDAN wrote:
> > > I forgot to mention that also tried seabios without success.
>
> I attached a log file for seabios.

[...]
> Scan for VGA option rom
> Attempting to init PCI bdf 03:00.0 (dev/ven 2527102b)
> Searching CBFS for data file pci102b,2527.rom
> Found CBFS file fallback/payload
> Found CBFS file fallback/coreboot_ram
> Found CBFS file 
> Attempting to map option rom on dev 03:00.0
> Option rom sizing returned fe800000 fffe0000
> Inspecting possible rom at 0xfe800000 (dv=2527102b bdf=300)
> Copying option rom (size 36864) from 0xfe800000 to c0000
> Checking rom 0x000c0000 (sig aa55 size 72)
> Running option rom at c000:0003
> enter handle_1a:
>    a=0000b102  b=0000ffff  c=00001541  d=000010b9 ds=0000 es=0000 ss=0000
>   si=00000000 di=000000f8 bp=00000000 sp=00007a6e cs=c000 ip=8125  f=0086
> fail handle_1ab102:55(86):
>    a=0000b102  b=0000ffff  c=00001541  d=000010b9 ds=0000 es=0000 ss=0000
>   si=00000000 di=000000f8 bp=00000000 sp=00007a6e cs=c000 ip=8125  f=0086

This is a bios request to find the pci device 102b:1541.  Your machine
doesn't appear to have this device, so an error return is appropriate.
(The warning just states that seabios is returning an error code to
the caller - it doesn't necessarily indicate a problem.)

The above all looks normal.

[...]
> enter handle_16:
>    a=00000100  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=0000
>   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=ff50  f=0002
> enter handle_15:
>    a=00008600  b=00000000  c=00000000  d=0000c350 ds=0000 es=0000 ss=0000
>   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=e726  f=0002
> enter handle_16:
>    a=00000100  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=0000
>   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=ff50  f=0002
> enter handle_15:
>    a=00008600  b=00000000  c=00000000  d=0000c350 ds=0000 es=0000 ss=0000
>   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=e726  f=0002
> ...
> INT 15/16 endless
> ...

This is just the result of a very high debug level.  Try lowering the
debug level to 6.

-Kevin

[Thomas JOURDAN]

Hi Kevin, Myles, all

My mistake ! Seabios run the VGA bios of the matrox graphics card
flawless. When I tried seabios, the coreboot Options.lb file of my
mainboard wasn't correct. I set :
default CONFIG_VGA_ROM_RUN=0
default CONFIG_PCI_ROM_RUN=0
but also (and that was my mistake)
default CONFIG_CONSOLE_VGA=0

I was thinking that seabios didn't care of coreboot settings and if
the vga rom was executed, it will use automatically the VGA console.
So my apologizes, seabios works great with my graphics board.

Regards,
Thomas

2009/6/26 Kevin O'Connor :
> On Wed, Jun 24, 2009 at 02:34:10PM +0200, Thomas JOURDAN wrote:
> > > > I forgot to mention that also tried seabios without success.
> >
> > I attached a log file for seabios.
>
> [...]
> > Scan for VGA option rom
> > Attempting to init PCI bdf 03:00.0 (dev/ven 2527102b)
> > Searching CBFS for data file pci102b,2527.rom
> > Found CBFS file fallback/payload
> > Found CBFS file fallback/coreboot_ram
> > Found CBFS file
> > Attempting to map option rom on dev 03:00.0
> > Option rom sizing returned fe800000 fffe0000
> > Inspecting possible rom at 0xfe800000 (dv=2527102b bdf=300)
> > Copying option rom (size 36864) from 0xfe800000 to c0000
> > Checking rom 0x000c0000 (sig aa55 size 72)
> > Running option rom at c000:0003
> > enter handle_1a:
> >    a=0000b102  b=0000ffff  c=00001541  d=000010b9 ds=0000 es=0000 ss=0000
> >   si=00000000 di=000000f8 bp=00000000 sp=00007a6e cs=c000 ip=8125  f=0086
> > fail handle_1ab102:55(86):
> >    a=0000b102  b=0000ffff  c=00001541  d=000010b9 ds=0000 es=0000 ss=0000
> >   si=00000000 di=000000f8 bp=00000000 sp=00007a6e cs=c000 ip=8125  f=0086
>
> This is a bios request to find the pci device 102b:1541.  Your machine
> doesn't appear to have this device, so an error return is appropriate.
> (The warning just states that seabios is returning an error code to
> the caller - it doesn't necessarily indicate a problem.)
>
> The above all looks normal.
>
> [...]
> > enter handle_16:
> >    a=00000100  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=0000
> >   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=ff50  f=0002
> > enter handle_15:
> >    a=00008600  b=00000000  c=00000000  d=0000c350 ds=0000 es=0000 ss=0000
> >   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=e726  f=0002
> > enter handle_16:
> >    a=00000100  b=00000000  c=00000000  d=00000000 ds=0000 es=0000 ss=0000
> >   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=ff50  f=0002
> > enter handle_15:
> >    a=00008600  b=00000000  c=00000000  d=0000c350 ds=0000 es=0000 ss=0000
> >   si=00000000 di=00000000 bp=00000000 sp=00007af8 cs=f000 ip=e726  f=0002
> > ...
> > INT 15/16 endless
> > ...
>
> This is just the result of a very high debug level.  Try lowering the
> debug level to 6.
>
> -Kevin

[Kevin O'Connor]

On Tue, Jun 30, 2009 at 09:10:46AM +0200, Thomas JOURDAN wrote:
> My mistake ! Seabios run the VGA bios of the matrox graphics card
> flawless. When I tried seabios, the coreboot Options.lb file of my
> mainboard wasn't correct. I set :
> default CONFIG_VGA_ROM_RUN=0
> default CONFIG_PCI_ROM_RUN=0
> but also (and that was my mistake)
> default CONFIG_CONSOLE_VGA=0

That's odd - I didn't think these coreboot options had any impact to
SeaBIOS either.  As a guess, coreboot is initializing some hardware
only when the CONFIG_CONSOLE_VGA option is set.

-Kevin

[Myles Watson]

> On Tue, Jun 30, 2009 at 09:10:46AM +0200, Thomas JOURDAN wrote:
> > My mistake ! Seabios run the VGA bios of the matrox graphics card
> > flawless. When I tried seabios, the coreboot Options.lb file of my
> > mainboard wasn't correct. I set :
> > default CONFIG_VGA_ROM_RUN=0
> > default CONFIG_PCI_ROM_RUN=0
> > but also (and that was my mistake)
> > default CONFIG_CONSOLE_VGA=0
>
> That's odd - I didn't think these coreboot options had any impact to
> SeaBIOS either.  As a guess, coreboot is initializing some hardware
> only when the CONFIG_CONSOLE_VGA option is set.

Yes.  If you don't have CONSOLE_VGA set then the PCI bridge bits don't get
set to allow the legacy I/O and memory ranges to be mapped.

Thanks,
Myles

[Kevin O'Connor]

On Tue, Jun 30, 2009 at 08:09:05PM -0600, Myles Watson wrote:
> > That's odd - I didn't think these coreboot options had any impact to
> > SeaBIOS either.  As a guess, coreboot is initializing some hardware
> > only when the CONFIG_CONSOLE_VGA option is set.
>
> Yes.  If you don't have CONSOLE_VGA set then the PCI bridge bits don't get
> set to allow the legacy I/O and memory ranges to be mapped.

That's unfortunate - setting CONSOLE_VGA also causes coreboot to try
and write to the vga screen.

I would think coreboot should always configure the legacy PCI bridge
bits and CONSOLE_VGA should just control whether or not coreboot tries
to write to the screen.  (Or, if there is a reason to not configure
the pci ranges, then make it a separate config item.)

-Kevin

[ron minnich]

On Tue, Jun 30, 2009 at 7:40 PM, Kevin O'Connor wrote:
> I would think coreboot should always configure the legacy PCI bridge
> bits and CONSOLE_VGA should just control whether or not coreboot tries
> to write to the screen.  (Or, if there is a reason to not configure
> the pci ranges, then make it a separate config item.)

It probably needs to be a config item then.

ron

[Myles Watson]

> -----Original Message-----
> From: ron minnich [mailto:[e-mail]]
> On Tue, Jun 30, 2009 at 7:40 PM, Kevin O'Connor wrote:
> > I would think coreboot should always configure the legacy PCI bridge
> > bits and CONSOLE_VGA should just control whether or not coreboot tries
> > to write to the screen.  (Or, if there is a reason to not configure
> > the pci ranges, then make it a separate config item.)
>
> It probably needs to be a config item then.

If Coreboot never writes to the console, that fixes it too.  I think that
was Stefan's preferred solution.  I think he's right that most of the time
the VGA console is useless for debugging.  All the tricky things happen
before that's available.

Thanks,
Myles

coreboot VGA init vs. writes [was: Intel Eagle Height evaluation board support]

[Peter Stuge]

Myles Watson wrote:
> If Coreboot never writes to the console, that fixes it too.  I
> think that was Stefan's preferred solution.

I like that too! Where does coreboot write to VGA now?
> I think he's right that most of the time the VGA console is useless
> for debugging. All the tricky things happen before that's
> available.

Agree.

//Peter

coreboot VGA init vs. writes [was: Intel Eagle Height evaluation board support]

[Myles Watson]

On Wed, Jul 1, 2009 at 4:07 PM, Peter Stuge  wrote:
> Myles Watson wrote:
> > If Coreboot never writes to the console, that fixes it too.  I
> > think that was Stefan's preferred solution.
>
> I like that too! Where does coreboot write to VGA now?

from printk as soon as it thinks the console is initialized when CONSOLE_VGA
is set.

Thanks,
Myles

[Thomas JOURDAN]

Signed-off-by: Thomas Jourdan

[Myles Watson]

On Tue, Jun 23, 2009 at 3:04 PM, Thomas JOURDAN wrote:
> Signed-off-by: Thomas Jourdan

Rev 4392.

I used common code where I could to get the same end result.

Thanks,
Myles

[Pattrick Hueper]

Hi,

On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDAN wrote:
> vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
>
> graphics card. Coreboot fails to execute the vga rom (either x86emu,
> yabel or real mode). There is an exception 0x06 and everything will
> freeze. It could be the loadall instruction

i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to
see whats happening in yabel...

Regards, Patty

[Thomas JOURDAN]

Hi Pattrick

With Yabel I have the following error :
CBFS:  Could not find file pci102b,2527.rom
In cbfs, rom address for PCI: 03:00.0 = 00000000
On card, rom address for PCI: 03:00.0 = fe800000
copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes
Unexpected Exception: 0 @ 10:0011bfa1 - Halting
Code: 0 eflags: 00010046
eax: 00000001 ebx: 00000061 ecx: 00000000 edx: 00000000
edi: 00000003 esi: 00000000 ebp: 00155abc esp: 00155a98

Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces.

Regards,
Thomas

2009/6/24 Pattrick Hueper :
> Hi,
>
> On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDAN wrote:
> > vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
> >
> > graphics card. Coreboot fails to execute the vga rom (either x86emu,
> > yabel or real mode). There is an exception 0x06 and everything will
> > freeze. It could be the loadall instruction
>
> i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to
> see whats happening in yabel...
>
> Regards, Patty

[Thomas JOURDAN]

I forgot to mention that on the IRC, someone suspected a missing timer
setup leading to a division by zero. This might help.

Thomas

2009/6/24 Thomas JOURDAN :
> Hi Pattrick
>
> With Yabel I have the following error :
> CBFS:  Could not find file pci102b,2527.rom
> In cbfs, rom address for PCI: 03:00.0 = 00000000
> On card, rom address for PCI: 03:00.0 = fe800000
> copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes
> Unexpected Exception: 0 @ 10:0011bfa1 - Halting
> Code: 0 eflags: 00010046
> eax: 00000001 ebx: 00000061 ecx: 00000000 edx: 00000000
> edi: 00000003 esi: 00000000 ebp: 00155abc esp: 00155a98
>
> Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces.
>
> Regards,
> Thomas
>
> 2009/6/24 Pattrick Hueper :
> > Hi,
> >
> > On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDAN wrote:
> > > vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
> > >
> > > graphics card. Coreboot fails to execute the vga rom (either x86emu,
> > > yabel or real mode). There is an exception 0x06 and everything will
> > > freeze. It could be the loadall instruction
> >
> > i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to
> > see whats happening in yabel...
> >
> > Regards, Patty

[Tom Sylla]

On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDAN wrote:
> I forgot to mention that on the IRC, someone suspected a missing timer
> setup leading to a division by zero. This might help.

In the past, when trying to figure out a VGA ROM execution hang or
errors, it has been very helpful to watch full IO tracing in the
emulator to see what IOs were being accessed just before the hang. It
would be interesting if you could do the same, especially if you are
suspecting that some legacy part is not set up properly. I don't know
the exact mechanism to do that in the emulators you are trying (or if
it is possible any more), but it may be helpful to try.

[Thomas JOURDAN]

Hi all

I created a new thread for the vga rom execution issues, because it
does not seem related to the mainboard. It's here :
http://www.coreboot.org/pipermail/coreboot/2009-June/050176.html

Regards,
Thomas

2009/6/24 Tom Sylla :
> On Wed, Jun 24, 2009 at 8:43 AM, Thomas JOURDAN wrote:
> > I forgot to mention that on the IRC, someone suspected a missing timer
> > setup leading to a division by zero. This might help.
>
> In the past, when trying to figure out a VGA ROM execution hang or
> errors, it has been very helpful to watch full IO tracing in the
> emulator to see what IOs were being accessed just before the hang. It
> would be interesting if you could do the same, especially if you are
> suspecting that some legacy part is not set up properly. I don't know
> the exact mechanism to do that in the emulators you are trying (or if
> it is possible any more), but it may be helpful to try.

[Pattrick Hueper]

Hm...

thats strange... yabel should print some output before it even touches
the copied ROM...

did you try a clean rebuild after changing the CONFIG values ?

Pattrick

On Wed, Jun 24, 2009 at 2:40 PM, Thomas JOURDAN wrote:
> Hi Pattrick
>
> With Yabel I have the following error :
> CBFS:  Could not find file pci102b,2527.rom
> In cbfs, rom address for PCI: 03:00.0 = 00000000
> On card, rom address for PCI: 03:00.0 = fe800000
> copying VGA ROM Image from fe800000 to 0xc0000, 0x9000 bytes
> Unexpected Exception: 0 @ 10:0011bfa1 - Halting
> Code: 0 eflags: 00010046
> eax: 00000001 ebx: 00000061 ecx: 00000000 edx: 00000000
> edi: 00000003 esi: 00000000 ebp: 00155abc esp: 00155a98
>
> Setting CONFIG_YABEL_DEBUG_FLAGS to 0x9 (or 0x31FF) won't print more traces.
>
> Regards,
> Thomas
>
> 2009/6/24 Pattrick Hueper :
> > Hi,
> >
> > On Tue, Jun 23, 2009 at 8:42 PM, Thomas JOURDAN wrote:
> > > vga rom -> The evaluation board comes with a PCIe 1x Matrox G550
> > >
> > > graphics card. Coreboot fails to execute the vga rom (either x86emu,
> > > yabel or real mode). There is an exception 0x06 and everything will
> > > freeze. It could be the loadall instruction
> >
> > i would be interested in a log with CONFIG_YABEL_DEBUG_FLAGS=0x9 to
> > see whats happening in yabel...
> >
> > Regards, Patty

[Myles Watson]

Thomas,

from i3100_northbridge.patch:
> Index: a/src/northbridge/intel/i3100/raminit.c
>  /* The memory is now setup, use it */
>
> +#if USE_DCACHE_RAM == 0
>      cache_lbmem(MTRR_TYPE_WRBACK);
> +#endif
>  }

Could you explain why you had to add this?

After that I'll Ack this patch.

I've refactored two of your patches so that they use svn cp from kontron and
model_6fx sources to show the differences.  If you based your work on
different sources, let me know.

My comments:
There is some #if 0 code in acpi_tables.  Will it ever be enabled?  If not,
remove it.

I'm confused why we need eagleheights_fixups.  Can we remove it?

Index: svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
===================================================================
--- svn.orig/src/cpu/intel/model_1067x/cache_as_ram_post.c
+++ svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
@@ -50,9 +50,9 @@
     "wrmsr\n"
     "movl    $MTRRphysMask_MSR(1), %ecx\n"
     "wrmsr\n"
-#endif

"movb    $0x33, %al\noutb %al, $0x80\n"
+#endif
 #ifdef CLEAR_FIRST_1M_RAM
     "movb    $0x34, %al\noutb %al, $0x80\n"
     /* Enable Write Combining and Speculative Reads for the first 1MB */
@@ -120,7 +120,7 @@
     "movb    $0x3b, %al\noutb %al, $0x80\n"

/* Enable prefetchers */
-    "movl    $0x01a0, %eax\n"
+    "movl    $0x01a0, %ecx\n"
     "rdmsr\n"
     "andl    $~((1 << 9) | (1 << 19)), %eax\n"
     "andl    $~((1 << 5) | (1 << 7)), %edx\n"

These changes were surprising.  Is there a bug in the original code?

Thanks,
Myles

[Thomas JOURDAN]

Hi Myles, guys
> > /* The memory is now setup, use it */
> > +#if USE_DCACHE_RAM == 0
> >       cache_lbmem(MTRR_TYPE_WRBACK);
> > +#endif
> >   }
>
> Could you explain why you had to add this?

This board uses CAR, like the kontron. When we initialize the memory,
we are still in CAR, and cache_lbmem will setup MTRR its ways. From
what I understand, this will break CAR and we'll get stuck here. So
cache_lbmem is OK for boards using ROMCC (mtarvon, truxton...), but is
bad with CAR.
> I've refactored two of your patches so that they use svn cp from kontron and
> model_6fx sources to show the differences.  If you based your work on
> different sources, let me know.

I'm really I wanted to do that but I did not find the time (lot of
work right now). I used a mix of 2 board : for the CAR skeleton I used
the Kontron 986LCDM mainboard, for the 3100 stuff the mt arvon board.
> My comments:
> There is some #if 0 code in acpi_tables.  Will it ever be enabled?  If not,
> remove it.

Yes indeed. As I said I started from the kontron mainboard but in my
case I didn't fill the OEMB table so they can safely be removed. We
can still fill table later if needed. I also found another #if 0 /
#endif pair in auto.c. Its about the MSR_THERM2_CTL. I remember I add
to disable it on a core 2 duo L7400 otherwise I was stuck. I'll check
it today if we can re-enable this one.
> I'm confused why we need eagleheights_fixups.  Can we remove it?

Yes indeed. I always add it in case but here I did not had to use it, so trash.
> Index: svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
>
> --- svn.orig/src/cpu/intel/model_1067x/cache_as_ram_post.c
> +++ svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
> @@ -50,9 +50,9 @@
>      "wrmsr\n"
>      "movl    $MTRRphysMask_MSR(1), %ecx\n"
>      "wrmsr\n"
> -#endif
>
> "movb    $0x33, %al\noutb %al, $0x80\n"
> +#endif
>  #ifdef CLEAR_FIRST_1M_RAM
>      "movb    $0x34, %al\noutb %al, $0x80\n"
>      /* Enable Write Combining and Speculative Reads for the first 1MB */
> @@ -120,7 +120,7 @@
>      "movb    $0x3b, %al\noutb %al, $0x80\n"
>
> /* Enable prefetchers */
> -    "movl    $0x01a0, %eax\n"
> +    "movl    $0x01a0, %ecx\n"
>      "rdmsr\n"
>      "andl    $~((1 << 9) | (1 << 19)), %eax\n"
>      "andl    $~((1 << 5) | (1 << 7)), %edx\n"
>
> These changes were surprising.  Is there a bug in the original code?

In the code, we execute a block a instructions to setup stuffs, then
output a post code. But if the instructions are disabled (ifdef
CLEAR_FIRST_1M_RAM), it's useless to output the post code no ? For the
last modifications (enable prefetchers : eax becomes ecx), there is
indeed a bug. I already sent a patch for this one few months ago but
it has been lost in the mailing list. The rdmsr instruction will read
the msr specified by ecx into edx:eax (Intel Software Dev Manual,
volume 2B, 4-322).

Thanks again for taking the time to review my patch.

Thomas

[Myles Watson]

> > > /* The memory is now setup, use it */
> > > +#if USE_DCACHE_RAM == 0
> > >       cache_lbmem(MTRR_TYPE_WRBACK);
> > > +#endif
> > >   }
> >
> > Could you explain why you had to add this?
>
> This board uses CAR, like the kontron. When we initialize the memory,
> we are still in CAR, and cache_lbmem will setup MTRR its ways. From
> what I understand, this will break CAR and we'll get stuck here. So
> cache_lbmem is OK for boards using ROMCC (mtarvon, truxton...), but is
> bad with CAR.

OK.
> > I've refactored two of your patches so that they use svn cp from kontron
>
> and
> > model_6fx sources to show the differences.  If you based your work on
> > different sources, let me know.
>
> I'm really I wanted to do that but I did not find the time (lot of
> work right now). I used a mix of 2 board : for the CAR skeleton I used
> the Kontron 986LCDM mainboard, for the 3100 stuff the mt arvon board.

Great.
> > My comments:
> > There is some #if 0 code in acpi_tables.  Will it ever be enabled?  If
>
> not,
> > remove it.
>
> Yes indeed. As I said I started from the kontron mainboard but in my
> case I didn't fill the OEMB table so they can safely be removed. We
> can still fill table later if needed. I also found another #if 0 /
> #endif pair in auto.c. Its about the MSR_THERM2_CTL. I remember I add
> to disable it on a core 2 duo L7400 otherwise I was stuck. I'll check
> it today if we can re-enable this one.

Thanks.
> > I'm confused why we need eagleheights_fixups.  Can we remove it?
>
> Yes indeed. I always add it in case but here I did not had to use it, so
> trash.

Will do.
> > Index: svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
> >
> > --- svn.orig/src/cpu/intel/model_1067x/cache_as_ram_post.c
> > +++ svn/src/cpu/intel/model_1067x/cache_as_ram_post.c
> > @@ -50,9 +50,9 @@
> >      "wrmsr\n"
> >      "movl    $MTRRphysMask_MSR(1), %ecx\n"
> >      "wrmsr\n"
> > -#endif
> >
> > "movb    $0x33, %al\noutb %al, $0x80\n"
> > +#endif
> >  #ifdef CLEAR_FIRST_1M_RAM
> >      "movb    $0x34, %al\noutb %al, $0x80\n"
> >      /* Enable Write Combining and Speculative Reads for the first 1MB
>
> */
> > @@ -120,7 +120,7 @@
> >      "movb    $0x3b, %al\noutb %al, $0x80\n"
> >
> > /* Enable prefetchers */
> > -    "movl    $0x01a0, %eax\n"
> > +    "movl    $0x01a0, %ecx\n"
> >      "rdmsr\n"
> >      "andl    $~((1 << 9) | (1 << 19)), %eax\n"
> >      "andl    $~((1 << 5) | (1 << 7)), %edx\n"
> >
> > These changes were surprising.  Is there a bug in the original code?
>
> In the code, we execute a block a instructions to setup stuffs, then
> output a post code. But if the instructions are disabled (ifdef
> CLEAR_FIRST_1M_RAM), it's useless to output the post code no ? For the
> last modifications (enable prefetchers : eax becomes ecx), there is
> indeed a bug. I already sent a patch for this one few months ago but
> it has been lost in the mailing list.

Sorry about that.
> The rdmsr instruction will read
> the msr specified by ecx into edx:eax (Intel Software Dev Manual,
> volume 2B, 4-322).

So I think we should fix the original code and not duplicate it.

Stefan:  What do you think about unifying
src/cpu/intel/model_*/cache_as_ram_post.c?

There are a couple of the files that are very similar.
> Thanks again for taking the time to review my patch.

No problem.  Could you send me the corrected Config.lb now that you removed
the disabled devices?

Thanks,
Myles

[Thomas JOURDAN]

Hi Myles, all
> Could you send me the corrected Config.lb now that you removed the disabled devices?

Here it is. As I said the audio and modem devices are disabled early
so they won't be present and won't be enumerated despite the function
exists in the i3100. Anyway, no internal connectors are present on the
board for audio or modem.

Thomas

[Myles Watson]

Could you send the copyright line for your work?  You made several
non-trivial additions.  I'll add it to the files for you.

Thanks,
Myles

[Thomas JOURDAN]

Hi Myles, guys
> Could you send the copyright line for your work?  You made several
> non-trivial additions.  I'll add it to the files for you.

Is it mandatory ? A coreboot copyright is fine to me. If you need one,
we can put :

Copyright (C) 2009 Thomas Jourdan

Regards,
Thomas

Copyright [was: Intel Eagle Height evaluation board support]

[Peter Stuge]

Hello Thomas,

Thanks a lot for your contributions to coreboot!

Thomas JOURDAN wrote:
> Is it mandatory ?

Yes.
> A coreboot copyright is fine to me.

Please note that there is no "coreboot" legal entity.

Unfortunately the name of Stefan Reinauer's company, coresystems GmbH,
is quite similar to the name of this project and the two could easily
be confused - but please keep in mind that coresystems GmbH is only
one part of the greater coreboot community. While Stefan and Patrick
do some amazing work with coreboot, I am sure that it is not the
intention of coresystems GmbH to own copyright for all coreboot code.
> Copyright (C) 2009 Thomas Jourdan

Great! Thanks.

//Peter