K8 state of v3 tree

[ron minnich]

Current state of tree. This all compiles with only errors for stuff
not yet defined.

Too many fixes in here to list them all :-)
but:
convert mcp55 over to new resource maps.
fix my misunderstanding of one aspect of resource map setup
Fix typo in config_{read,write} naming.
Fix random mistakes in include files.

YHLU: question: is REV F a proper superset of all K8? If we do REV F compatible
code, and test for REV A-E in our coded and take appropriate action,
will the code work properly? Can we have e.g.
the same mem_controller struct for all K8?

I'd like to avoid the files we had in v2 with stuff like xyz_f and
just have one common set of K8 files.
It's even ok if, e.g., there are struct members in the mem_controller
struct that are only used on rev f
or dual core, and unused otherwise. I'd like to simplify the tangle we
had in v2.

Signed-off-by: Ronald G. Minnich

[Peter Stuge]

On Mon, Aug 04, 2008 at 07:38:18PM -0700, ron minnich wrote:
> Current state of tree. This all compiles with only errors for stuff
> not yet defined.

..
> Signed-off-by: Ronald G. Minnich

Looked through it, looks good.

Acked-by: Peter Stuge

[ron minnich]

Committed revision 722.

Thanks. Will continue to fill it out tomorrow.

ron

[Peter Stuge]

On Mon, Aug 04, 2008 at 07:50:55PM -0700, ron minnich wrote:
> Committed revision 722.
>
> Thanks. Will continue to fill it out tomorrow.

mainboard/gigabyte/m57sli/cmos.layout is missing

//Peter

[Peter Stuge]

On Tue, Aug 05, 2008 at 04:56:06AM +0200, Peter Stuge wrote:
> mainboard/gigabyte/m57sli/cmos.layout is missing

I once again commented out mcp55 to see how far it would go;

DTC     build/statictree.h
  DTC     mainboard/gigabyte/m57sli/dts (dts->lbh)
  CC      build/superio/ite/it8716f/stage1.o
  CC      build/device/pnp_raw.o
  CC      build/stage0.init
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/bin/as: /unrecognized option '-T'
make: *** [/home/stuge/co/v3/build/stage0.init] Error 1

//Peter

[ron minnich]

On Mon, Aug 4, 2008 at 7:57 PM, Peter Stuge  wrote:
> On Tue, Aug 05, 2008 at 04:56:06AM +0200, Peter Stuge wrote:
> > mainboard/gigabyte/m57sli/cmos.layout is missing
>
> I once again commented out mcp55 to see how far it would go;
>
> DTC     build/statictree.h
>  DTC     mainboard/gigabyte/m57sli/dts (dts->lbh)
>  CC      build/superio/ite/it8716f/stage1.o
>  CC      build/device/pnp_raw.o
>  CC      build/stage0.init
> /usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/bin/as: /unrecognized option '-T'
> make: *** [/home/stuge/co/v3/build/stage0.init] Error 1

can you run
make Q=  V=1

thanks

ron

[Peter Stuge]

On Mon, Aug 04, 2008 at 07:59:59PM -0700, ron minnich wrote:
> can you run
> make Q=  V=1

first plain:

$ make
  CP      build/config.h
  GEN     build/build.h
  HOSTCC  build/util/options/build_opt_tbl
  OPTIONS build/mainboard/gigabyte/m57sli/option_table.c
  CC      build/stage0.init
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/bin/as: unrecognized option '-T'
make: *** [/home/stuge/co/v3/build/stage0.init] Error 1

then loud:

$ make Q= V=1
mkdir -p /home/stuge/co/v3/build
printf "  CP      build/config.h\n"
  CP      build/config.h
cp /home/stuge/co/v3/.tmpconfig.h /home/stuge/co/v3/build/config.h
printf "  GEN     build/build.h\n"
  GEN     build/build.h
printf "#define COREBOOT_VERSION "3.0."722""\n" > /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_EXTRA_VERSION ""\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_BUILD "`LANG= date`"\n" >> /home/stuge/co/v3/build/build.h
printf "\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_COMPILER "gcc (GCC) 4.2.2 (Gentoo 4.2.2 p1.0)"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_ASSEMBLER "GNU assembler (GNU Binutils) 2.18"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_LINKER "GNU ld (GNU Binutils) 2.18"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_COMPILE_TIME "`LANG= date +%T`"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_COMPILE_BY "stuge"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_COMPILE_HOST "n410c"\n" >> /home/stuge/co/v3/build/build.h
printf "#define COREBOOT_COMPILE_DOMAIN "stuge.se"\n" >> /home/stuge/co/v3/build/build.h
mkdir -p /home/stuge/co/v3/build/util/options/
printf "  HOSTCC  build/util/options/build_opt_tbl\n"
  HOSTCC  build/util/options/build_opt_tbl
gcc -Wall -Wstrict-prototypes -g -fomit-frame-pointer -Wno-unused -Wno-sign-compare -o /home/stuge/co/v3/build/util/options/build_opt_tbl /home/stuge/co/v3/build/util/options/build_opt_tbl.o
printf "  OPTIONS build/mainboard/gigabyte/m57sli/option_table.c\n"
  OPTIONS build/mainboard/gigabyte/m57sli/option_table.c
mkdir -p /home/stuge/co/v3/build/mainboard/gigabyte/m57sli
/home/stuge/co/v3/build/util/options/build_opt_tbl -b \
                --config /home/stuge/co/v3/mainboard/gigabyte/m57sli/cmos.layout \
                --option /home/stuge/co/v3/build/mainboard/gigabyte/m57sli/option_table.c 
# We need to be careful. If stage0.o gets bigger than
# 0x4000 - 0x100, we will end up with a 4 gig file.
# I wonder if that behavior is on purpose.
# Note: we invoke gcc (instead of ld directly) here, as we hit
# strange problems in the past. It seems that only gcc knows how
# to properly invoke ld.
printf "  CC      build/stage0.init\n"
  CC      build/stage0.init
gcc -nostdlib -static -T /home/stuge/co/v3/arch/x86/ldscript.ld \
                /home/stuge/co/v3/build/lib/uart8250.o /home/stuge/co/v3/build/lib/mem.o /home/stuge/co/v3/build/lib/lar.o /home/stuge/co/v3/build/lib/delay.o /home/stuge/co/v3/build/lib/vtxprintf.o /home/stuge/co/v3/build/lib/vsprintf.o /home/stuge/co/v3/build/lib/console.o /home/stuge/co/v3/build/lib/string.o /home/stuge/co/v3/build/lib/lzma.o /home/stuge/co/v3/build/arch/x86/stage1.o /home/stuge/co/v3/build/arch/x86/serial.o /home/stuge/co/v3/build/arch/x86/speaker.o /home/stuge/co/v3/build/arch/x86/udelay_io.o /home/stuge/co/v3/build/arch/x86/mc146818rtc.o /home/stuge/co/v3/build/arch/x86/post_code.o /home/stuge/co/v3/build/arch/x86/amd/k8/stage1.o /home/stuge/co/v3/build/arch/x86/amd/stage0.o /home/stuge/co/v3/build/mainboard/gigabyte/m57sli/stage1.o /home/stuge/co/v3/build/mainboard/gigabyte/m57sli/option_table.c /home/stuge/co/v3/build/superio/ite/it8716f/stage1.o /home/stuge/co/v3/build/device/pnp_raw.o -o /home/stuge/co/v3/build/stage0.o
/usr/lib/gcc/i686-pc-linux-gnu/4.2.2/../../../../i686-pc-linux-gnu/bin/as: unrecognized option '-T'
make: *** [/home/stuge/co/v3/build/stage0.init] Error 1

//Peter

[yhlu]

On Mon, Aug 4, 2008 at 7:38 PM, ron minnich  wrote:
> Current state of tree. This all compiles with only errors for stuff
> not yet defined.
>
> Too many fixes in here to list them all :-)
> but:
> convert mcp55 over to new resource maps.
> fix my misunderstanding of one aspect of resource map setup
> Fix typo in config_{read,write} naming.
> Fix random mistakes in include files.
>
> YHLU: question: is REV F a proper superset of all K8? If we do REV F compatible
> code, and test for REV A-E in our coded and take appropriate action,
> will the code work properly? Can we have e.g.
> the same mem_controller struct for all K8?

No. REV A-E got DDR1. REV F got DDR2
> I'd like to avoid the files we had in v2 with stuff like xyz_f and
> just have one common set of K8 files.
> It's even ok if, e.g., there are struct members in the mem_controller
> struct that are only used on rev f
> or dual core, and unused otherwise. I'd like to simplify the tangle we
> had in v2.

YH

[ron minnich]

On Tue, Aug 5, 2008 at 1:41 AM, yhlu  wrote:
> No. REV A-E got DDR1. REV F got DDR2

OK but can I use the same data structures and just live with the fact
that on A-E some parts are unused and on F other parts are unused?

ron

[yhlu]

On Tue, Aug 5, 2008 at 8:48 AM, ron minnich  wrote:
> On Tue, Aug 5, 2008 at 1:41 AM, yhlu  wrote:
> > No. REV A-E got DDR1. REV F got DDR2
>
> OK but can I use the same data structures and just live with the fact
> that on A-E some parts are unused and on F other parts are unused?

Yes

YH

[ron minnich]

On Tue, Aug 5, 2008 at 12:23 PM, yhlu  wrote:
> On Tue, Aug 5, 2008 at 8:48 AM, ron minnich  wrote:
> > On Tue, Aug 5, 2008 at 1:41 AM, yhlu  wrote:
> > > No. REV A-E got DDR1. REV F got DDR2
> >
> > OK but can I use the same data structures and just live with the fact
> > that on A-E some parts are unused and on F other parts are unused?
>
> Yes

Thanks! This is good news ...

ron