[PATCH] VIA CX700 support

[Stefan Reinauer]

See patch.

[ron minnich]

Wonderful!

What's a god box to buy to try this out?

Acked-by: Ronald G. Minnich

[Stefan Reinauer]

On 10.04.2009 16:50 Uhr, ron minnich wrote:
> Wonderful!
>
> What's a god box to buy to try this out?

My personal favorite is this one, though i didn't get my fingers on it
before:

http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id...

Stefan

[ron minnich]

On Fri, Apr 10, 2009 at 8:23 AM, Stefan Reinauer  wrote:
> On 10.04.2009 16:50 Uhr, ron minnich wrote:
> > Wonderful!
> >
> > What's a god box to buy to try this out?
>
> My personal favorite is this one, though i didn't get my fingers on it
> before:
>
> http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id...

and it's certain to work? I keep buying the wrong via mainboards it seems :-)

But if it's certain to work it looks perfect for our uses.

thanks

ron

[Stefan Reinauer]

On 10.04.2009 17:38 Uhr, ron minnich wrote:
> On Fri, Apr 10, 2009 at 8:23 AM, Stefan Reinauer  wrote:
> > On 10.04.2009 16:50 Uhr, ron minnich wrote:
> > > Wonderful!
> > >
> > > What's a god box to buy to try this out?
> >
> > My personal favorite is this one, though i didn't get my fingers on it
> > before:
> >
> > http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id...
>
> and it's certain to work? I keep buying the wrong via mainboards it seems :-)

Currently the only mainboard in the tree is a VIA VT8454C which is a
development board. As you can see the source code has been living on my
hard disk since 2007.

Sorry, I can't say much more than that.

Stefan

[bari]

Ron,

The CX700 integrates the cn700 and vt8237 into one part so you're just 
as well off with any of the cn700 boards. The cx700 and cn700 both use 
Chrome Pro vs the faster/newer Chrome9 gpu core found in the vx800 and 
vx855 which are still not supported even though there are open docs and 
a working-ish patch at VIA.

-Bari

ron minnich wrote:
> On Fri, Apr 10, 2009 at 8:23 AM, Stefan Reinauer  wrote:
> > On 10.04.2009 16:50 Uhr, ron minnich wrote:
> > > Wonderful!
> > >
> > > What's a god box to buy to try this out?
> >
> > My personal favorite is this one, though i didn't get my fingers on it
> > before:
> >
> > http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id...
>
> and it's certain to work? I keep buying the wrong via mainboards it seems :-)
>
> But if it's certain to work it looks perfect for our uses.
>
> thanks
>
> ron

[Stephan Raue]

Am 10.04.2009 17:23, schrieb Stefan Reinauer:
> On 10.04.2009 16:50 Uhr, ron minnich wrote:
> > Wonderful!
> >
> > What's a god box to buy to try this out?
>
> My personal favorite is this one, though i didn't get my fingers on it
> before:
>
> http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id...

i like this one
http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=370&proname=J7F5...
> Stefan

[Stephan Raue]

Am 10.04.2009 16:31, schrieb Stefan Reinauer:
> See patch.

Hi all,

how i can add support for Jetway J7F5M1G5E-VHE-LF 
(http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=374&proname=J7F5...) 
in coreboot with this patch, or better - because i have not experience 
with coreboot - can anyone do this for me?

i have this board so i can test this.

[Peter Stuge]

Hi Stephan,

Stephan Raue wrote:
> how i can add support for Jetway J7F5M1G5E-VHE-LF
> (http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=374&proname=J7F5...) 
> in coreboot with this patch,

Start by comparing the added board (VIA reference board) with the
Jetway board, chip wise. If they are using the same superio you could
try simply booting a coreboot image built for the VIA board on the
Jetway board, and it might work.
> or better - because i have not experience with coreboot - can
> anyone do this for me?

Maybe you can find a volunteer, but everyone is busy.. Also, trying
to do development of this kind without physical access to the
hardware kills the spirit. There are often many problems to solve,
and it is really heavy work to try to debug them via the internet.
> i have this board so i can test this.

It seems to be using mostly VIA chips. Maybe you are lucky and a VIA
reference board image will just work. We are interested in any test
results!

//Peter

[Stephan Raue]

Am 13.04.2009 06:40, schrieb Peter Stuge:
> Hi Stephan,
>
> Stephan Raue wrote:
> > how i can add support for Jetway J7F5M1G5E-VHE-LF
> > (http://www.jetway.com.tw/jw/ipcboard_view.asp?productid=374&proname=J7F5...)
> > in coreboot with this patch,
>
> Start by comparing the added board (VIA reference board) with the
> Jetway board, chip wise. If they are using the same superio you could
> try simply booting a coreboot image built for the VIA board on the
> Jetway board, and it might work.

here is the first problem - Jetway seems like to use Fintek SuperIOs now 
Coreboot has included F71805F/FG and the

J7F5M1G5E Board uses F71806F/FG or F71872F/FG (i think F71806F/FG because F71872F/FG has a Keyboardcontroller and the Board have no PS/2 Keyboard Port). I have found at Google that 71806 [3] and 71872 [4] (both supports 11 sets of voltage sensors) with are fully compatible (except the Keyboard Controller) [1], [2] and mostly(fully?) compatible with 71805 [5] (9 sets of voltage sensor).

Can anyone include this SuperIOs or can i try this with F71805? How i can change the Configuration from the VIA VT8454C to include this SuperIO (the rest must be identical)
- i think like the creation of Jetway J7F2/4 from VIA CN

Output of Superiotool: Found Fintek F71872F/FG / F71806F/FG (vid=0x3419, id=0x4103) at 0x4e

[1] http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020419.html
[2] http://lists.lm-sensors.org/pipermail/lm-sensors/2007-July/020420.html
[3] http://www.fintek.com.tw/files/productfiles/F71806_V026P.pdf
[4] http://www.fintek.com.tw/files/productfiles/F71872F_ab.pdf
[5] http://www.fintek.com.tw/files/productfiles/F71805F_V025.pdf

Stephan
> > or better - because i have not experience with coreboot - can
> > anyone do this for me?
>
> Maybe you can find a volunteer, but everyone is busy.. Also, trying
> to do development of this kind without physical access to the
> hardware kills the spirit. There are often many problems to solve,
> and it is really heavy work to try to debug them via the internet.
> > i have this board so i can test this.
>
> It seems to be using mostly VIA chips. Maybe you are lucky and a VIA
> reference board image will just work. We are interested in any test
> results!
>
> //Peter

[Peter Stuge]

Stephan Raue wrote:
> > If they are using the same superio you could try simply booting a
> > coreboot image built for the VIA board on the Jetway board
>
> here is the first problem - Jetway seems like to use Fintek
> SuperIOs now Coreboot has included F71805F/FG and the J7F5M1G5E
> Board uses F71806F/FG or F71872F/FG

..
> Can anyone include this SuperIOs or can i try this with F71805? How
> i can change the Configuration from the VIA VT8454C to include this
> SuperIO (the rest must be identical)
> i think like the creation of Jetway J7F2/4 from VIA CN

It is probably easier to make changes directly in the vt8454c target
first. I am afraid I can't help much here, but maybe it is enough to
replace the superio chip line in src/mainboard/via/*8454*/Config.lb
and then rebuild.

//Peter

[Corey Osgood]

On Tue, Apr 14, 2009 at 5:51 AM, Peter Stuge  wrote:
> Stephan Raue wrote:
> > > If they are using the same superio you could try simply booting a
> > > coreboot image built for the VIA board on the Jetway board
> >
> > here is the first problem - Jetway seems like to use Fintek
> > SuperIOs now Coreboot has included F71805F/FG and the J7F5M1G5E
> > Board uses F71806F/FG or F71872F/FG
>
> ..
> > Can anyone include this SuperIOs or can i try this with F71805? How
> > i can change the Configuration from the VIA VT8454C to include this
> > SuperIO (the rest must be identical)
> > i think like the creation of Jetway J7F2/4 from VIA CN

At the very least, the f71805f and f71806f use the same sequence to
enter/exit configuration mode, and have the same LDN for the UARTs, so you
should be able to at least get serial port console output from the f71805f
code on the f71806f.

-Corey

[Stephan Raue]

Am 10.04.2009 16:31, schrieb Stefan Reinauer:
> See patch.

when i try build via vt8454c for testing if this patch is ok i am become 
follow error. Can you/anyone fix this or help me, because i will test 
this patch wit my jetway J7F5 Board.

Stephan

[stephan@dv9000 targets]$ cd via/vt8454c/via_vt8454c
[stephan@dv9000 via_vt8454c]$ make
if (cd normal; \
    	make coreboot.rom)\
    then true; else exit 1; fi;
make[1]: Entering directory `/home/stephan/projects/OpenELEC/work/test/targets/via/vt8454c/via_vt8454c/normal'
cp /home/stephan/projects/OpenELEC/work/test/src/arch/i386/init/crt0.S.lb crt0.S
gcc -Os -Wall --include=settings.h /home/stephan/projects/OpenELEC/work/test/util/options/build_opt_tbl.c -o build_opt_tbl
./build_opt_tbl --config /home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/cmos.layout --header option_table.h --option option_table.c
gcc -m32 -fno-stack-protector -I/home/stephan/projects/OpenELEC/work/test/src -I.  -I/home/stephan/projects/OpenELEC/work/test/src/include -I/home/stephan/projects/OpenELEC/work/test/src/arch/i386/include -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include --include=settings.h /home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c -Os -nostdinc -nostdlib -fno-builtin -g -dA -fverbose-asm -Wall -c -S -o auto.inc
In file included from /home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:32:
/home/stephan/projects/OpenELEC/work/test/src/arch/i386/lib/console.c: In Funktion »console_init«:
/home/stephan/projects/OpenELEC/work/test/src/arch/i386/lib/console.c:30: Warnung: Variable »console_test« wird nicht verwendet
In file included from /home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:51:
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/cx700_early_smbus.c: In Funktion »set_ics_data«:
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/cx700_early_smbus.c:133: Warnung: Um Zuweisung, die als Wahrheitswert verwendet wird, werden Klammern empfohlen
In file included from /home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:55:
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c: In Funktion »sdram_enable«:
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c:1441: Warnung: Große Ganzzahl implizit auf vorzeichenlosen Typen abgeschnitten
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c:1444: Warnung: Große Ganzzahl implizit auf vorzeichenlosen Typen abgeschnitten
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c:1447: Warnung: Große Ganzzahl implizit auf vorzeichenlosen Typen abgeschnitten
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c:1450: Warnung: Große Ganzzahl implizit auf vorzeichenlosen Typen abgeschnitten
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/raminit.c:1457: Warnung: Große Ganzzahl implizit auf vorzeichenlosen Typen abgeschnitten
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c: Auf höchster Ebene:
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:103: Warnung: Rückgabetyp von »main« ist nicht »int«
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:103: Warnung: erstes Argument von »main« sollte »int« sein
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:103: Warnung: »main« benötigt entweder null oder zwei Argumente
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/auto.c:103: Warnung: »main« ist normalerweise eine Nicht-static-Funktion
/home/stephan/projects/OpenELEC/work/test/src/arch/i386/include/arch/romcc_io.h:275: Warnung: »pci_io_locate_device« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/arch/i386/include/arch/romcc_io.h:299: Warnung: »pci_locate_device_on_bus« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/mtrr/earlymtrr.c:29: Warnung: »disable_var_mtrr« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/mtrr/earlymtrr.c:55: Warnung: »set_var_mtrr_x« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/mtrr/earlymtrr.c:74: Warnung: »cache_lbmem« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/mtrr/earlymtrr.c:118: Warnung: »early_mtrr_init« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/mtrr/earlymtrr.c:139: Warnung: »early_mtrr_init_detected« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/cpu/x86/lapic/boot_cpu.c:3: Warnung: »boot_cpu« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/northbridge/via/cx700/cx700_early_smbus.c:63: Warnung: »smbus_print_error« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/debug.c:32: Warnung: »print_pci_devices« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/debug.c:70: Warnung: »dump_pci_devices« definiert, aber nicht verwendet
/home/stephan/projects/OpenELEC/work/test/src/mainboard/via/vt8454c/debug.c:87: Warnung: »dump_io_resources« definiert, aber nicht verwendet
perl -e 's/.rodata/.rom.data/g' -pi auto.inc
perl -e 's/.text/.section .rom.text/g' -pi auto.inc
gcc -m32 -x assembler-with-cpp -DASSEMBLY -E -I/home/stephan/projects/OpenELEC/work/test/src/include -I/home/stephan/projects/OpenELEC/work/test/src/arch/i386/include -I/usr/lib/gcc/i586-redhat-linux/4.4.0/include --include=settings.h -I. -I/home/stephan/projects/OpenELEC/work/test/src  crt0.S>  crt0.s.new&&  mv crt0

.s.new crt0.s
gcc -m32 -Wa,-acdlns -ä...n $unk at end of line, first unrecognized character is `#'
crt0.s:26648: Error: junk at end of line, first unrecognized character is `#'
crt0.s:26649: Error: junk at end of line, first unrecognized character is `#'
crt0.s:26650: Error: junk at end of line, first unrecognized character is `#'
crt0.s:26651: Error: junk at end of line, first unrecognized character is `#'
crt0.s:26652: Error: junk at end of line, first unrecognized character is `#'
crt0.s:26653: Error: junk at end of line, first unrecognized character is `#'
.
.
.
crt0.s:62656: Error: junk at end of line, first unrecognized character is `#'
crt0.s:62664: Error: junk at end of line, first unrecognized character is `#'
crt0.s:62672: Error: junk at end of line, first unrecognized character is `#'
crt0.s:62680: Error: junk at end of line, first unrecognized character is `#'
crt0.s:62688: Error: junk at end of line, first unrecognized character is `#'
crt0.s:63063: Error: junk at end of line, first unrecognized character is `"'
make[1]: *** [crt0.o] Fehler 1
make[1]: Leaving directory `/home/stephan/projects/OpenELEC/work/test/targets/via/vt8454c/via_vt8454c/normal'
make: *** [normal/coreboot.rom] Fehler 1
[stephan@dv9000 via_vt8454c]$

[Uwe Hermann]

Hi,

On Fri, Apr 10, 2009 at 04:31:40PM +0200, Stefan Reinauer wrote:
> Add VIA CX700 support, plus VIA vt8454c reference board support.

Nice work!

Quick review below. With the few issues in the code fixed it's

Acked-by: Uwe Hermann
> Index: src/include/pc80/i8259.h
>
> --- src/include/pc80/i8259.h	(revision 4087)
> +++ src/include/pc80/i8259.h	(working copy)
> @@ -1 +1,6 @@
> +#ifndef PC80_I8259_H
> +#define PC80_I8259_H
>
> void setup_i8259(void);
>
> +#endif /* PC80_I8259_H */

Please add the usual license header. The file is trivial, just
use (C) coresystems.
> Index: src/mainboard/via/vt8454c/failover.c
>
> --- src/mainboard/via/vt8454c/failover.c	(revision 0)
> +++ src/mainboard/via/vt8454c/failover.c	(revision 0)
> @@ -0,0 +1,49 @@
> +#define ASSEMBLY 1
> +#include <arch/io.h>
> +#include "arch/romcc_io.h"
> +#include "pc80/mc146818rtc_early.c"
>
> +static unsigned long main(unsigned long bist)
> +{
> if (do_normal_boot()) {
> goto normal_image;
> } else {
> goto fallback_image;
> }
>
> +normal_image:
> asm volatile ("jmp __normal_image":	/* outputs */
>       :"a" (bist)		/* inputs */
>       :				/* clobbers */
> );
>
> +cpu_reset:
> asm volatile ("jmp __cpu_reset":	/* outputs */
>       :"a" (bist)		/* inputs */
>       :				/* clobbers */
> );
>
> +fallback_image:
> return bist;
>
> +}

This file is equivalent to the global src/arch/i386/lib/failover.c,
please use that one (and drop this file here) by using something like

depends "$(MAINBOARD)/../../../arch/i386/lib/failover.c ../romcc"
        action "../romcc -E -O2 -mcpu=p2 --label-prefix=failover -I$(TOP)/src -I. $(CPPFLAGS) $(MAINBOARD)/../../../arch/i386/lib/failover.c -o $@"

etc. in the board's Config.lb.
> Index: src/mainboard/via/vt8454c/auto.c
>
> --- src/mainboard/via/vt8454c/auto.c	(revision 0)
> +++ src/mainboard/via/vt8454c/auto.c	(revision 0)
> @@ -0,0 +1,134 @@
> +void udelay(unsigned usecs)
> +{
> int i;
> for (i = 0; i < usecs; i++)
> outb(0xff, 0x80);
>
> +}

#include "pc80/udelay_io.c"

provides this already.
> +#include "lib/delay.c"

Oh, we should unify delay.c and udelay_io.c at some point btw, but
that's for another patch.
> Index: src/mainboard/via/vt8454c/dmi.h
>
> --- src/mainboard/via/vt8454c/dmi.h	(revision 0)
> +++ src/mainboard/via/vt8454c/dmi.h	(revision 0)
> @@ -0,0 +1,31 @@
> +#define DMI_TABLE_SIZE 0x55
>
> +static u8 dmi_table[DMI_TABLE_SIZE] = {
> 0x5f, 0x53, 0x4d, 0x5f, 0x2d, 0x1f, 0x02, 0x03, 0x51, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> 0x5f, 0x44, 0x4d, 0x49, 0x5f, 0xeb, 0xa8, 0x03, 0xa0, 0xff, 0x0f, 0x00, 0x01, 0x00, 0x23, 0x00,
> 0x00, 0x14, 0x00, 0x00, 0x01, 0x02, 0x00, 0xe0, 0x03, 0x07, 0x90, 0xde, 0xcb, 0x7f, 0x00, 0x00,
> 0x00, 0x00, 0x37, 0x01, 0x63, 0x6f, 0x72, 0x65, 0x73, 0x79, 0x73, 0x74, 0x65, 0x6d, 0x73, 0x20,
> 0x47, 0x6d, 0x62, 0x48, 0x00, 0x32, 0x2e, 0x30, 0x00, 0x30, 0x33, 0x2f, 0x31, 0x33, 0x2f, 0x32,
> 0x30, 0x30, 0x38, 0x00, 0x00
>
> +};

Hm, interesting, I guess this is the first board where we use DMI in
coreboot? Is this a hard requirement for the board? What is DMI used
for here? Not knowing much about DMI myself, what are all those hex
numbers?
> Index: src/mainboard/via/vt8454c/Config.lb
>
> --- src/mainboard/via/vt8454c/Config.lb	(revision 0)
> +++ src/mainboard/via/vt8454c/Config.lb	(revision 0)
> @@ -0,0 +1,196 @@
> +makerule ./auto.inc
>    depends "$(MAINBOARD)/auto.c option_table.h"
>    action "$(CC) $(DISTRO_CFLAGS) -I$(TOP)/src -I.  $(CPPFLAGS) $(MAINBOARD)/auto.c -Os -nostdinc -nostdlib -fno-builtin -g -dA -fverbose-asm -Wall -c -S -o $@"

Might need small fixes to make it similar to what Carl-Daniel changed
the other Config.lb files to (can be done after the commit though).
> +##
> +## Build our 16 bit and 32 bit linuxBIOS entry code

^^^^^^^^^
                                  coreboot
> +##
> +mainboardinit cpu/x86/16bit/entry16.inc
> +mainboardinit cpu/x86/32bit/entry32.inc
> +ldscript /cpu/x86/16bit/entry16.lds
> +ldscript /cpu/x86/32bit/entry32.lds
>
> +##
> +## Build our reset vector (This is where linuxBIOS is entered)

coreboot
> 	chip drivers/pci/onboard
> 		device pci 0.0 on end
> 		register "rom_address" = "0xfff80000" #512k image

Please also add comments for 256K and 1MB images to make it easier
for users to switch when using different ROM sizes.
> Index: src/mainboard/via/vt8454c/irq_tables.c
>
> --- src/mainboard/via/vt8454c/irq_tables.c	(revision 0)
> +++ src/mainboard/via/vt8454c/irq_tables.c	(revision 0)
> @@ -0,0 +1,65 @@
> +/*
> Documentation at: http://www.microsoft.com/whdc/archive/pciirq.mspx
> */

Drop this comment please (we did in most other boards). The link is in
the wiki, we don't need it in all irq_table.c files.
> Index: src/mainboard/via/vt8454c/debug.c
>
> --- src/mainboard/via/vt8454c/debug.c	(revision 0)
> +++ src/mainboard/via/vt8454c/debug.c	(revision 0)
> @@ -0,0 +1,108 @@

This is equivalent to the global src/lib/debug.c, except for the
dump_io_resources() function. Please add that one to src/lib/debug.c,
use the global file then, and drop this one.

Feel free to add the (C) coresystems + GPL2 header to that global
debug.c, it doesn't yet have a header.
> Index: src/northbridge/via/cx700/cx700_vga.c
>
> --- src/northbridge/via/cx700/cx700_vga.c	(revision 0)
> +++ src/northbridge/via/cx700/cx700_vga.c	(revision 0)
> @@ -0,0 +1,119 @@
> +static void vga_init(device_t dev)
> +{
> u8 reg8;
> printk_debug("Initiailizing VGA...\n");

Typo.
> Index: src/northbridge/via/cx700/raminit.c
>
> --- src/northbridge/via/cx700/raminit.c	(revision 0)
> +++ src/northbridge/via/cx700/raminit.c	(revision 0)
> @@ -0,0 +1,1480 @@
> +#define	GET_SPD(i, val, tmp, reg)								\
> do{											\
> val = 0;									\
> tmp = 0;									\
> for(i = 0; i < 2; i++)	{							\
> 	if(pci_read_config8(PCI_DEV(0, 0, 4), (SCRATCH_REG_BASE + (i << 1)))) {	\
> 		tmp = get_spd_data(ctrl, i, reg);				\
> 		if(tmp > val)							\
> 			val = tmp;						\
> 	}									\
> }										\
> } while ( 0 )

Hm, this is a bit ugly, why not make it a function instead of a #define?
> +// TODO factor out to another file
> +static void c7_cpu_setup(const struct mem_controller *ctrl)
> +{
> u8 size, i;
> size = sizeof(Reg_Val) / sizeof(Reg_Val[0]);
> for (i = 0; i < size; i += 2)

Please use ARRAY_SIZE here.
> pci_write_config8(HOSTCTRL, Reg_Val[i], Reg_Val[i + 1]);
>
> +}
> Index: targets/via/vt8454c/Config-abuild.lb
>
> --- targets/via/vt8454c/Config-abuild.lb	(revision 0)
> +++ targets/via/vt8454c/Config-abuild.lb	(revision 0)
> @@ -0,0 +1,24 @@

Add the usual GPL header please.
> Index: targets/via/vt8454c/Config.lb
>
> --- targets/via/vt8454c/Config.lb	(revision 0)
> +++ targets/via/vt8454c/Config.lb	(revision 0)

Add the usual GPL header please.

Uwe.