forward this to coreboot list too.
---------- Forwarded message ----------
From: Karl-Heinz Nirschl <kh.nirschl(a)googlemail.com>
Subject: Re: [coreboot] Getting started with Coreboot on Intel Core
To: Stefan Reinauer <stepan(a)coresystems.de>
thanks for your reply. i thought
src/northbridge/intel/i945/early_init.c is executed after stage1_main
somewhere in real main. i've put a lot of postcodes bevor that
- one in front of stage1_main and and one in real_main. shouldn't i see these?
in my understanding execution takes the following way:
1 some generic x86 startup assembler
3 cache_as_ram_disable.inc (stage1_main)
4 romstage.c (real_main) in mainboard dir
isn't that right? it looks like i hang between 2 und 3.
i'll go and check the toolschain in utils.
2010/3/8 Stefan Reinauer <stepan(a)coresystems.de>:
> On 3/8/10 6:36 PM, Karl-Heinz Nirschl wrote:
>> i should append:
>> this is using a spi flash with 2 Megs and todays svn version.
>> i also tried with a 1 meg fhw with a somewhat earlier version of
>> coreboot. same problem.
>> 2010/3/8 Karl-Heinz Nirschl <kh.nirschl(a)googlemail.com>:
>>> Hi there,
>>> i'm new to coreboot and trying to port coreboot to a intel core based
>>> board. it's a u2500 with a ich7m and 945gm.
>>> i started with kontron 986lcd-m which should be quite similar but
>>> didn't have much success so far.
> Did you adapt the code for your SuperIO chip? Do you get any messages on
> the serial port?
>>> the board hangs with post code 0x23 (pci post card) which is bevor
>>> "call stage1_main" in model_6ex/cache_as_ram.inc.
>>> as this is very early and the cpu never seem to come to stage1_main
>>> (in cache_as_ram_disable.c) i assume i have a problem with my
> Try this one:
> Index: src/northbridge/intel/i945/early_init.c
> --- src/northbridge/intel/i945/early_init.c (revision 5196)
> +++ src/northbridge/intel/i945/early_init.c (working copy)
> @@ -867,7 +867,7 @@
> /* Change port80 to LPC */
> - RCBA32(GCS) &= (~0x04);
> + //RCBA32(GCS) &= (~0x04);
> /* Just do it that way */
> RCBA32(0x2010) |= (1 << 10);
> Then post codes keep going to PCI instead of LPC and you should see
> where it's going.
>>> I build on ubuntu 8.04 (Hardy Heron) with nothing special.
>>> Any hints for a coreboot newbie? Which additional information could i
>>> provide to find the problem?
> You should use the reference toolchain in util/crossgcc
> coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
> Tel.: +49 761 7668825 • Fax: +49 761 7664613
> Email: info(a)coresystems.de • http://www.coresystems.de/
> Registergericht: Amtsgericht Freiburg • HRB 7656
> Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
> coreboot mailing list: coreboot(a)coreboot.org
[Fullquote because it seems Stefan's mail mail did not end up on the
list by accident.]
On 06.03.2010 23:39, Stefan Reinauer wrote:
> On 3/6/10 7:26 PM, Carl-Daniel Hailfinger wrote:
>>> Just having it as a FILO add-on would be the best solution. Then it can
>>> use all the FILO infrastructure (reading lots of filesystems, using a
>>> recovery with a nice menu on a USB stick,
>> OTOH, it could simply be an ELF loaded by FILO. That allows upgrades of
>> flashrom as needed, and if FILO can load flash images from any media, it
>> should be able to do the same with executable code.
> Unless FILO gets a full blown linker, that ELF file would need a full
> blown VFS, IDE driver, FS drivers, USB stack, ....
> But yes, maybe doing run time linking at firmware time is what we want
> to do, after all...
Assuming the addresses of symbols in FILO/libpayload are known at
compile/link (well, prelink) time of flashrom, it should be possible to
offer prelinked ELF files to FILO without needing any linker in FILO.
This would be similar to the linking of initram and stage2 in coreboot v3.
Or we make sure FILO is able to write out a symbol table over serial or
to disk. That symbol table can then be used by a linker on another
machine to link flashrom, and then a linked flashrom can be supplied to
I could try to dig up my symbol-table-in-LAR patches for v3.
That's surely an interesting project regardless of how we implement it.
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth
This thing is now ready for more exposure. Scratch my previous "patch" -
this is my first real deal.
- Adds Asus P2B-LS mainboard
- Adds RAM detection for i440bx (based on i82830 code). We're no longer hard
coded for 64MB on one row!
- Adds a proper Slot 1 cpu under src/cpu/intel/slot_1. It's a stub copied
from slot_2 but addresses a few FIXMEs. My P2B-LS code refers to this.
- Adds microcode for Intel Tualatin CPUs, cpuid 6B1 and 6B4.* Actually
loading them is pending.
Signed-off-by: Keith Hui <buurin(a)gmail.com>
* Microcodes for all Intel CPUs can be downloaded from Intel -
downloadcenter.intel.com. So TODO for me is to add all microcode updates
from Klamath to Tualatin as the Asus P2B family, with the right mods and/or
adapter, can run anything in between that can fit either Slot 1 or Socket
i'm new to coreboot and trying to port coreboot to a intel core based
board. it's a u2500 with a ich7m and 945gm.
i started with kontron 986lcd-m which should be quite similar but
didn't have much success so far.
the board hangs with post code 0x23 (pci post card) which is bevor
"call stage1_main" in model_6ex/cache_as_ram.inc.
as this is very early and the cpu never seem to come to stage1_main
(in cache_as_ram_disable.c) i assume i have a problem with my
I build on ubuntu 8.04 (Hardy Heron) with nothing special.
Any hints for a coreboot newbie? Which additional information could i
provide to find the problem?
Date: Mon Mar 8 14:09:45 2010
New Revision: 108
Set current cursor position in kernel header when VGA support was compiled
into libpayload so the kernel starts outputting it's messages at the right
position. The old code was actually working, but using the wrong
Signed-off-by: Mathias Krause <Mathias.Krause(a)secunet.com>
Acked-by: Stefan Reinauer <stepan(a)coresystems.de>
--- trunk/filo/i386/linux_load.c Tue Oct 6 05:10:00 2009 (r107)
+++ trunk/filo/i386/linux_load.c Mon Mar 8 14:09:45 2010 (r108)
@@ -26,6 +26,7 @@
@@ -585,7 +586,7 @@
struct segment_desc *linux_gdt;
struct context *ctx;
unsigned int cursor_x, cursor_y, cursor_en;
@@ -625,7 +626,7 @@
printf("Jumping to entry point...\n");
/* Update VGA cursor position.
* This must be here because the printf changes the value! */
video_console_get_cursor(&cursor_x, &cursor_y, &cursor_en);
On Sat, Mar 6, 2010 at 2:01 PM, ron minnich <rminnich(a)gmail.com> wrote:
> This activity is really impressive. It got me to wondering: how old is
> the 440bx chipset? I know it's been around a while. It sure seems to
> live one ...
Yup, 440BX is alive and well. :-)
I got scored by romcc again in the battle to complete its support.
Attached is my working copy of src/northbridge/intel/i440bx/raminit.c with
more or less complete SDRAM support at 100MHz. There is one problem: romcc
segfaults on it. Because of this, it is not patch ready. It compiles fine on
gcc for my test jig. Anything I added to make it compile for my jig did not
cause this, as I removed them all and it still segfaults.
Any help is again appreciated.
There is also preliminary work done to combine
into sdram_initialize(), like i82830. I also added a parameter to it for the
motherboard's FSB, so the motherboard romstage can get the FSB off the clock
chip and pass it to raminit.c where SDRAM timings are programmed.
I ended up just dumping the configuration space with three 256MB PC133 DIMMs
installed in all kind of combinations and analyze that. I tested this code
by comparing its output through my test jig with my collected dumps.
SerialICE still not involved. :-)
Joseph, the code to initialize the DIMMs are already there before I came
onboard. Instead of sending the sequence to one row at a time, the 440BX
code sends one command to all populated DIMM rows together. I figure we
could save some execution time as this method is not unlike boiling 8 eggs
all at once.
By the way where in the source tree would one put code to initialize
non-DRAM related aspects of northbridge?
Looking at this on the GSoC page:
> flashrom support for Willem hardware
Haha, I'd so love to see this.
For a base to work off of, look at firebrand:
You may even be able to google for an older version of the original control
program with source.
Also look at the sivava "PCB45" variant as well. This site has info (and
schematics with differences highlighted) on how to convert a PCB3B (for
which schematics is/was available) to a PCB45:
There are four versions that we can easily get schematics for - original
willem, PCB3B, a simplified, flash-only "EzoFlash", and the PCB45 conversion
above. There are newer variants but they are proprietary. I'd love to see
support for these four implemented.
>From what I read it may be a product of the shady parts of Internet. At
least it is sort of open and easily accessible. I first built EzoFlash on a
breadboard to flash a firmware for my infamous Apex 600A DVD player, and
then built a PCB3B on a crudely made PCB, that I am using right now to flash
440BX RAM initialization code for boot testing.