From kevin at koconnor.net  Tue Sep  1 02:51:22 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Mon, 31 Aug 2009 20:51:22 -0400
Subject: [coreboot] SeaBIOS and USB?
In-Reply-To: <20090828025531.GA24618@morn.localdomain>
References: <20090828025531.GA24618@morn.localdomain>
Message-ID: <20090901005122.GB7768@morn.localdomain>

On Thu, Aug 27, 2009 at 10:55:31PM -0400, Kevin O'Connor wrote:
> Anyway, it would be helpful to hear from those that are planning to
> work in this area and the work that they are planning.

To include myself on the discussion of plans - I've been reading up on
the USB specs and am looking at what it would take to add UHCI
keyboard support to SeaBIOS.

-Kevin



From svn at coreboot.org  Tue Sep  1 11:52:15 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  1 Sep 2009 11:52:15 +0200
Subject: [coreboot] [v2] r4621 - trunk/util/inteltool
Message-ID: <mailman.3683.1355071616.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-01 11:52:14 +0200 (Tue, 01 Sep 2009)
New Revision: 4621

Modified:
   trunk/util/inteltool/Makefile
   trunk/util/inteltool/cpu.c
   trunk/util/inteltool/inteltool.c
   trunk/util/inteltool/inteltool.h
Log:
Clean up Mac OS X support of inteltool

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>

Some minor modifications to allow 64bit/32bit compilation on Darwin



Modified: trunk/util/inteltool/Makefile
===================================================================
--- trunk/util/inteltool/Makefile	2009-08-29 15:45:43 UTC (rev 4620)
+++ trunk/util/inteltool/Makefile	2009-09-01 09:52:14 UTC (rev 4621)
@@ -31,9 +31,7 @@
 
 OS_ARCH	= $(shell uname)
 ifeq ($(OS_ARCH), Darwin)
-CFLAGS += -DDARWIN -I/usr/local/include 
-LDFLAGS = -framework IOKit -framework DirectIO -L/usr/local/lib -lpci -lz
-# OBJS += darwinio.o
+LDFLAGS = -framework DirectIO -lpci -lz
 endif
 
 all: pciutils dep $(PROGRAM)
@@ -56,7 +54,7 @@
 		   printf "struct pci_access *pacc;\n";		\
 		   printf "int main(int argc, char **argv)\n";	\
 		   printf "{ pacc = pci_alloc(); return 0; }\n"; ) > .test.c )
-	@$(CC) $(CFLAGS) .test.c -o .test $(LDFLAGS) &>/dev/null &&	  \
+	@$(CC) $(CFLAGS) $(LDFLAGS) .test.c -o .test &>/dev/null &&	  \
 		printf "found.\n" || ( printf "not found.\n\n"; 	  \
 		printf "Please install pciutils-devel and zlib-devel.\n"; \
 		printf "See README for more information.\n\n";		  \
@@ -64,6 +62,7 @@
 	@rm -rf .test.c .test .test.dSYM
 
 install: $(PROGRAM)
+	mkdir -p $(DESTDIR)$(PREFIX)/sbin
 	$(INSTALL) $(PROGRAM) $(DESTDIR)$(PREFIX)/sbin
 	mkdir -p $(DESTDIR)$(PREFIX)/share/man/man8
 	$(INSTALL) $(PROGRAM).8 $(DESTDIR)$(PREFIX)/share/man/man8

Modified: trunk/util/inteltool/cpu.c
===================================================================
--- trunk/util/inteltool/cpu.c	2009-08-29 15:45:43 UTC (rev 4620)
+++ trunk/util/inteltool/cpu.c	2009-09-01 09:52:14 UTC (rev 4621)
@@ -30,30 +30,23 @@
 
 unsigned int cpuid(unsigned int op)
 {
-	unsigned int ret;
-	unsigned int dummy2, dummy3, dummy4;
-#if DARWIN
-	asm volatile ( 
-		"pushl %%ebx	\n"
-		"cpuid		\n"
-		"movl %%ebx, %1	\n"
-		"popl %%ebx	\n"
-		: "=a" (ret), "=r" (dummy2), "=c" (dummy3), "=d" (dummy4)
-		: "a" (op)
-		: "cc"
-	);
+	uint32_t ret;
+
+#if defined(__DARWIN__) && !defined(__LP64__)
+        asm volatile (
+                "pushl %%ebx    \n"
+                "cpuid          \n"
+                "popl %%ebx     \n"
+                : "=a" (ret) : "a" (op) : "%ecx", "%edx"
+        );
 #else
-	asm volatile ( 
-		"cpuid"
-		: "=a" (ret), "=b" (dummy2), "=c" (dummy3), "=d" (dummy4)
-		: "a" (op)
-		: "cc"
-	);
+	asm ("cpuid" : "=a" (ret) : "a" (op) : "%ebx", "%ecx", "%edx");
 #endif
+
 	return ret;
 }
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 int msr_readerror = 0;
 
 msr_t rdmsr(int addr)
@@ -288,7 +281,7 @@
 		return -1;
 	}
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 	fd_msr = open("/dev/cpu/0/msr", O_RDWR);
 	if (fd_msr < 0) {
 		perror("Error while opening /dev/cpu/0/msr");
@@ -309,7 +302,7 @@
 	close(fd_msr);
 
 	for (core = 0; core < 8; core++) {
-#ifndef DARWIN
+#ifndef __DARWIN__
 		char msrfilename[64];
 		memset(msrfilename, 0, 64);
 		sprintf(msrfilename, "/dev/cpu/%d/msr", core);
@@ -330,12 +323,12 @@
 			       cpu->per_core_msrs[i].number, msr.hi, msr.lo,
 			       cpu->per_core_msrs[i].name);
 		}
-#ifndef DARWIN
+#ifndef __DARWIN__
 		close(fd_msr);
 #endif
 	}
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 	if (msr_readerror)
 		printf("\n(*) Some MSRs could not be read. The marked values are unreliable.\n");
 #endif

Modified: trunk/util/inteltool/inteltool.c
===================================================================
--- trunk/util/inteltool/inteltool.c	2009-08-29 15:45:43 UTC (rev 4620)
+++ trunk/util/inteltool/inteltool.c	2009-09-01 09:52:14 UTC (rev 4621)
@@ -50,10 +50,10 @@
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH, "ICH" }
 };
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 static int fd_mem;
 
-void *map_physical(unsigned long phys_addr, int len)
+void *map_physical(unsigned long phys_addr, size_t len)
 {
 	void *virt_addr;
 
@@ -68,7 +68,7 @@
 	return virt_addr;
 }
 
-void unmap_physical(void *virt_addr, int len)
+void unmap_physical(void *virt_addr, size_t len)
 {
 	munmap(virt_addr, len);
 }
@@ -192,7 +192,7 @@
 		exit(1);
 	}
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 	if ((fd_mem = open("/dev/mem", O_RDWR)) < 0) {
 		perror("Can not open /dev/mem");
 		exit(1);

Modified: trunk/util/inteltool/inteltool.h
===================================================================
--- trunk/util/inteltool/inteltool.h	2009-08-29 15:45:43 UTC (rev 4620)
+++ trunk/util/inteltool/inteltool.h	2009-09-01 09:52:14 UTC (rev 4621)
@@ -18,12 +18,13 @@
  */
 
 #include <stdint.h>
-#ifndef DARWIN
+
+#if defined(__GLIBC__)
 #include <sys/io.h>
-#else
-/* DirectIO is available here:
- * http://www.coresystems.de/en/directio
- */
+#endif
+#if (defined(__MACH__) && defined(__APPLE__))
+/* DirectIO is available here: http://www.coresystems.de/en/directio */
+#define __DARWIN__
 #include <DirectIO/darwinio.h>
 #endif
 #include <pci/pci.h>
@@ -55,13 +56,13 @@
 
 #define ARRAY_SIZE(a) ((int)(sizeof(a) / sizeof((a)[0])))
 
-#ifndef DARWIN
+#ifndef __DARWIN__
 typedef struct { uint32_t hi, lo; } msr_t;
 #endif
 typedef struct { uint16_t addr; int size; char *name; } io_register_t;
 
-void *map_physical(unsigned long phys_addr, int len);
-void unmap_physical(void *virt_addr, int len);
+void *map_physical(unsigned long phys_addr, size_t len);
+void unmap_physical(void *virt_addr, size_t len);
 
 unsigned int cpuid(unsigned int op);
 int print_intel_core_msrs(void);




From svn at coreboot.org  Tue Sep  1 11:54:22 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  1 Sep 2009 11:54:22 +0200
Subject: [coreboot] [v2] r4622 - trunk/util/nvramtool
Message-ID: <mailman.3684.1355071616.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-01 11:54:21 +0200 (Tue, 01 Sep 2009)
New Revision: 4622

Modified:
   trunk/util/nvramtool/Makefile
   trunk/util/nvramtool/common.h
   trunk/util/nvramtool/nvramtool.spec
Log:

nvramtool:

* Add OSX/Darwin support
* Add $DESTDIR support
* Clean up make install/spec

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: trunk/util/nvramtool/Makefile
===================================================================
--- trunk/util/nvramtool/Makefile	2009-09-01 09:52:14 UTC (rev 4621)
+++ trunk/util/nvramtool/Makefile	2009-09-01 09:54:21 UTC (rev 4622)
@@ -18,6 +18,11 @@
 	hexdump.o input_file.o layout.o layout_file.o lbtable.o   \
 	nvramtool.o opts.o reg_expr.o
 
+OS_ARCH        = $(shell uname)
+ifeq ($(OS_ARCH), Darwin)
+LDFLAGS = -framework DirectIO
+endif
+
 all: dep $(PROGRAM)
 
 $(PROGRAM): $(OBJS)
@@ -34,9 +39,10 @@
 	@$(CC) -MM *.c > .dependencies
 
 install: $(PROGRAM)
-	$(INSTALL) $(PROGRAM) $(PREFIX)/sbin
-	mkdir -p $(PREFIX)/share/man/man1
-	$(INSTALL) $(PROGRAM).8 $(PREFIX)/share/man/man8
+	mkdir -p $(DESTDIR)$(PREFIX)/sbin
+	$(INSTALL) $(PROGRAM) $(DESTDIR)$(PREFIX)/sbin
+	mkdir -p $(DESTDIR)$(PREFIX)/share/man/man8
+	$(INSTALL) $(PROGRAM).8 $(DESTDIR)$(PREFIX)/share/man/man8
 
 .PHONY: all clean distclean dep
 

Modified: trunk/util/nvramtool/common.h
===================================================================
--- trunk/util/nvramtool/common.h	2009-09-01 09:52:14 UTC (rev 4621)
+++ trunk/util/nvramtool/common.h	2009-09-01 09:54:21 UTC (rev 4622)
@@ -53,7 +53,12 @@
 #define INW(x) __extension__ ({ u_int tmp = (x); inw(tmp); })
 #define INL(x) __extension__ ({ u_int tmp = (x); inl(tmp); })
 #else
+#if defined(__GLIBC__)
 #include <sys/io.h>
+#endif
+#if (defined(__MACH__) && defined(__APPLE__))
+#include <DirectIO/darwinio.h>
+#endif
 #define OUTB outb
 #define OUTW outw
 #define OUTL outl

Modified: trunk/util/nvramtool/nvramtool.spec
===================================================================
--- trunk/util/nvramtool/nvramtool.spec	2009-09-01 09:52:14 UTC (rev 4621)
+++ trunk/util/nvramtool/nvramtool.spec	2009-09-01 09:54:21 UTC (rev 4622)
@@ -33,9 +33,9 @@
 %install
 rm -rf "$RPM_BUILD_ROOT"
 mkdir -p "$RPM_BUILD_ROOT/usr/bin"
-mkdir -p "$RPM_BUILD_ROOT/usr/man/man1"
+mkdir -p "$RPM_BUILD_ROOT/usr/man/man8"
 cp nvramtool "$RPM_BUILD_ROOT/usr/bin"
-cp nvramtool.1.gz $RPM_BUILD_ROOT/usr/man/man1
+cp nvramtool.8.gz $RPM_BUILD_ROOT/usr/man/man8
 
 %clean
 rm -rf "$RPM_BUILD_ROOT"
@@ -45,4 +45,4 @@
 %doc ChangeLog README
 %doc README
 /usr/bin/nvramtool
-/usr/man/man1/nvramtool.1.gz
+/usr/man/man8/nvramtool.8.gz




From svn at coreboot.org  Tue Sep  1 11:57:55 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  1 Sep 2009 11:57:55 +0200
Subject: [coreboot] [v2] r4623 - trunk/util/superiotool
Message-ID: <mailman.3685.1355071616.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-01 11:57:55 +0200 (Tue, 01 Sep 2009)
New Revision: 4623

Modified:
   trunk/util/superiotool/Makefile
   trunk/util/superiotool/superiotool.h
Log:

* Add OSX/Darwin support
* Add DESTDIR support

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: trunk/util/superiotool/Makefile
===================================================================
--- trunk/util/superiotool/Makefile	2009-09-01 09:54:21 UTC (rev 4622)
+++ trunk/util/superiotool/Makefile	2009-09-01 09:57:55 UTC (rev 4623)
@@ -34,17 +34,23 @@
 
 OBJS = superiotool.o ali.o fintek.o ite.o nsc.o smsc.o winbond.o
 
+OS_ARCH = $(shell uname)
+ifeq ($(OS_ARCH), Darwin)
+LDFLAGS = -framework IOKit -framework DirectIO -lpci -lz
+endif
+
 all: $(PROGRAM)
 
 superiotool.o: *.c superiotool.h
 
 $(PROGRAM): $(OBJS) superiotool.h
-	$(CC) $(CFLAGS) -o $(PROGRAM) $(OBJS)
+	$(CC) $(LDFLAGS) -o $(PROGRAM) $(OBJS)
 
 install: $(PROGRAM)
-	$(INSTALL) $(PROGRAM) $(PREFIX)/sbin
-	mkdir -p $(PREFIX)/share/man/man8
-	$(INSTALL) $(PROGRAM).8 $(PREFIX)/share/man/man8
+	mkdir -p $(DESTDIR)$(PREFIX)/sbin
+	$(INSTALL) $(PROGRAM) $(DESTDIR)$(PREFIX)/sbin
+	mkdir -p $(DESTDIR)$(PREFIX)/share/man/man8
+	$(INSTALL) $(PROGRAM).8 $(DESTDIR)$(PREFIX)/share/man/man8
 
 clean:
 	rm -f $(PROGRAM) *.o

Modified: trunk/util/superiotool/superiotool.h
===================================================================
--- trunk/util/superiotool/superiotool.h	2009-09-01 09:54:21 UTC (rev 4622)
+++ trunk/util/superiotool/superiotool.h	2009-09-01 09:57:55 UTC (rev 4623)
@@ -4,6 +4,7 @@
  * Copyright (C) 2007 Carl-Daniel Hailfinger
  * Copyright (C) 2007 Uwe Hermann <uwe at hermann-uwe.de>
  * Copyright (C) 2008 Robinson P. Tryon <bishop.robinson at gmail.com>
+ * Copyright (C) 2008-2009 coresystems GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -31,6 +32,10 @@
 #if defined(__GLIBC__)
 #include <sys/io.h>
 #endif
+#if (defined(__MACH__) && defined(__APPLE__))
+/* DirectIO is available here: http://www.coresystems.de/en/directio */
+#include <DirectIO/darwinio.h>
+#endif
 
 #if defined(__FreeBSD__)
 #include <sys/types.h>




From svn at coreboot.org  Tue Sep  1 12:03:02 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  1 Sep 2009 12:03:02 +0200
Subject: [coreboot] [v2] r4624 - trunk/util/msrtool
Message-ID: <mailman.3686.1355071616.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-01 12:03:01 +0200 (Tue, 01 Sep 2009)
New Revision: 4624

Added:
   trunk/util/msrtool/darwin.c
Modified:
   trunk/util/msrtool/Makefile.in
   trunk/util/msrtool/configure
   trunk/util/msrtool/msrtool.c
   trunk/util/msrtool/msrtool.h
   trunk/util/msrtool/sys.c
Log:
port msrtool to darwin.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>

with minor changes to allow 32bit and 64bit compilation and (I hope), Peter's
concerns addressed.



Modified: trunk/util/msrtool/Makefile.in
===================================================================
--- trunk/util/msrtool/Makefile.in	2009-09-01 09:57:55 UTC (rev 4623)
+++ trunk/util/msrtool/Makefile.in	2009-09-01 10:03:01 UTC (rev 4624)
@@ -27,7 +27,7 @@
 LDFLAGS = @LDFLAGS@
 
 TARGETS = geodelx.o cs5536.o k8.o
-SYSTEMS = linux.o
+SYSTEMS = linux.o darwin.o
 OBJS    = $(PROGRAM).o msrutils.o sys.o $(SYSTEMS) $(TARGETS)
 
 all: $(PROGRAM)
@@ -39,9 +39,8 @@
 	$(CC) $(CFLAGS) -DVERSION='"@VERSION@"' -c $< -o $@
 
 install: $(PROGRAM)
-	$(INSTALL) $(PROGRAM) $(PREFIX)/sbin
-	mkdir -p $(PREFIX)/share/man/man8
-	$(INSTALL) $(PROGRAM).8 $(PREFIX)/share/man/man8
+	mkdir -p $(DESTDIR)$(PREFIX)/sbin
+	$(INSTALL) $(PROGRAM) $(DESTDIR)$(PREFIX)/sbin
 
 distprep: distclean Makefile.deps
 

Modified: trunk/util/msrtool/configure
===================================================================
--- trunk/util/msrtool/configure	2009-09-01 09:57:55 UTC (rev 4623)
+++ trunk/util/msrtool/configure	2009-09-01 10:03:01 UTC (rev 4624)
@@ -155,7 +155,7 @@
 	rm -f .config.c
 	exit 1
 }
-LDFLAGS=`trylink "libpci (from pciutils)" "${pc_LDFLAGS}" "-lpci -lz" "-L/usr/local/lib -lpci -lz" "-framework IOKit -L/usr/local/lib -lpci -lz"` || {
+LDFLAGS=`trylink "libpci (from pciutils)" "${pc_LDFLAGS}" "-lpci -lz" "-L/usr/local/lib -lpci -lz" "-framework DirectIO -lpci -lz"` || {
 	rm -f .config.c .config.o
 	exit 1
 }

Added: trunk/util/msrtool/darwin.c
===================================================================
--- trunk/util/msrtool/darwin.c	                        (rev 0)
+++ trunk/util/msrtool/darwin.c	2009-09-01 10:03:01 UTC (rev 4624)
@@ -0,0 +1,61 @@
+/*
+ * This file is part of msrtool.
+ *
+ * Copyright (c) 2009 coresystems GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
+
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <string.h>
+#include <errno.h>
+
+#include "msrtool.h"
+
+int darwin_probe(const struct sysdef *system)
+{
+#ifdef __DARWIN__
+	return iopl(3) == 0;
+#else
+	return 0;
+#endif
+}
+
+int darwin_open(uint8_t cpu, enum SysModes mode)
+{
+	if (cpu > 0) {
+		fprintf(stderr, "%s: only core 0 is supported on Mac OS X right now.\n", __func__);
+		return 0;
+	}
+	return 1;
+}
+
+int darwin_close(uint8_t cpu)
+{
+	return 1;
+}
+
+int darwin_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val)
+{
+	msr_t msr;
+
+	msr = rdmsr(addr);
+
+	val->hi = msr.lo;
+	val->lo = msr.hi;
+	return 1;
+}

Modified: trunk/util/msrtool/msrtool.c
===================================================================
--- trunk/util/msrtool/msrtool.c	2009-09-01 09:57:55 UTC (rev 4623)
+++ trunk/util/msrtool/msrtool.c	2009-09-01 10:03:01 UTC (rev 4624)
@@ -48,6 +48,7 @@
 
 static struct sysdef allsystems[] = {
 	{ "linux", "Linux with /dev/cpu/*/msr", linux_probe, linux_open, linux_close, linux_rdmsr },
+	{ "darwin", "OS X with DirectIO", darwin_probe, darwin_open, darwin_close, darwin_rdmsr },
 	{ SYSTEM_EOT }
 };
 

Modified: trunk/util/msrtool/msrtool.h
===================================================================
--- trunk/util/msrtool/msrtool.h	2009-09-01 09:57:55 UTC (rev 4623)
+++ trunk/util/msrtool/msrtool.h	2009-09-01 10:03:01 UTC (rev 4624)
@@ -2,6 +2,7 @@
  * This file is part of msrtool.
  *
  * Copyright (c) 2008 Peter Stuge <peter at stuge.se>
+ * Copyright (c) 2009 coresystems GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -22,6 +23,11 @@
 
 #include <stdio.h>
 #include <stdint.h>
+#if (defined(__MACH__) && defined(__APPLE__))
+/* DirectIO is available here: http://www.coresystems.de/en/directio */
+#define __DARWIN__
+#include <DirectIO/darwinio.h>
+#endif
 #include <pci/pci.h>
 
 #define HEXCHARS "0123456789abcdefABCDEF"
@@ -174,6 +180,11 @@
 extern int linux_close(uint8_t cpu);
 extern int linux_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val);
 
+/* darwin.c */
+extern int darwin_probe(const struct sysdef *system);
+extern int darwin_open(uint8_t cpu, enum SysModes mode);
+extern int darwin_close(uint8_t cpu);
+extern int darwin_rdmsr(uint8_t cpu, uint32_t addr, struct msr *val);
 
 /** target externs **/
 

Modified: trunk/util/msrtool/sys.c
===================================================================
--- trunk/util/msrtool/sys.c	2009-09-01 09:57:55 UTC (rev 4623)
+++ trunk/util/msrtool/sys.c	2009-09-01 10:03:01 UTC (rev 4624)
@@ -2,6 +2,7 @@
  * This file is part of msrtool.
  *
  * Copyright (c) 2008 Peter Stuge <peter at stuge.se>
+ * Copyright (c) 2009 coresystems GmbH
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -25,7 +26,18 @@
 
 struct cpuid_t *cpuid(void) {
 	uint32_t outeax;
+
+#if defined(__DARWIN__) && !defined(__LP64__)
+        asm volatile (
+                "pushl %%ebx    \n"
+                "cpuid          \n"
+                "popl %%ebx     \n"
+                : "=a" (outeax) : "a" (1) : "%ecx", "%edx"
+        );
+#else
 	asm ("cpuid" : "=a" (outeax) : "a" (1) : "%ebx", "%ecx", "%edx");
+#endif
+
 	id.stepping = outeax & 0xf;
 	outeax >>= 4;
 	id.model = outeax & 0xf;
@@ -40,6 +52,9 @@
 		id.model |= (id.ext_model << 4);
 		id.family += id.ext_family;
 	}
+	printf_verbose("CPU: family %x, model %x, stepping %x\n",
+			id.family, id.model, id.stepping);
+
 	return &id;
 }
 




From stepan at coresystems.de  Tue Sep  1 12:29:03 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Sep 2009 12:29:03 +0200
Subject: [coreboot] coreboot utilities on  MacOSX
Message-ID: <4A9CF76F.4090406@coresystems.de>

Hi,

As a weekend project I had been porting coreboot utilities to Mac OS X.

I put up a new set of installer images, source code and patches to

http://www.coresystems.de/~stepan/OSX/

The order of installation should be:
- DirectIO 1.1
- pciutils 3.1.4
- coreboot-utils 1.0

All packages are both 32bit and 64bit and they have been tested on Mac
OS X 10.6.

Feedback is welcome!

Stefan



From gregg.drwho8 at gmail.com  Tue Sep  1 13:36:58 2009
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Tue, 1 Sep 2009 07:36:58 -0400
Subject: [coreboot] coreboot utilities on MacOSX
In-Reply-To: <4A9CF76F.4090406@coresystems.de>
References: <4A9CF76F.4090406@coresystems.de>
Message-ID: <18d205ed0909010436w6886a7dcv82a877494560d5ec@mail.gmail.com>

On Tue, Sep 1, 2009 at 6:29 AM, Stefan Reinauer<stepan at coresystems.de> wrote:
> Hi,
>
> As a weekend project I had been porting coreboot utilities to Mac OS X.
>
> I put up a new set of installer images, source code and patches to
>
> http://www.coresystems.de/~stepan/OSX/
>
> The order of installation should be:
> - DirectIO 1.1
> - pciutils 3.1.4
> - coreboot-utils 1.0
>
> All packages are both 32bit and 64bit and they have been tested on Mac
> OS X 10.6.
>
> Feedback is welcome!
>
> Stefan
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

Hello!
I am decidedly impressed. Those are well needed. Next question have
they been tested against the next latest version of OS/X?

There's some controversy raging regarding a user space program not
running properly on this big cat, as it no longer does everything that
it did before.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature was once found posting rude
 messages in English in the Moscow subway."



From arnaud.maye at 4dsp.com  Tue Sep  1 15:00:44 2009
From: arnaud.maye at 4dsp.com (Arnaud Maye)
Date: Tue, 01 Sep 2009 15:00:44 +0200
Subject: [coreboot] SeaBIOS WinXP install
Message-ID: <4A9D1AFC.7080607@4dsp.com>

Hello Myles, Kevin and others

I've been implementing the ACPI for the ep80579 and so far it is not 
going very well. Linux refuses to boot unless I use acpi=off or acpi=ht 
as boot parameters. acpi=ht seems to display my ACPI ioports in 
proc/ioports as expected ( the ioports addresses are all mapped to the 
ACPI BAR ). Without to disable acpi the kernel complains that the 
0xE0000000 range is not a reserved  range and the MMCONF is not 
supported and then hangs. Using acpi=noirq still hangs so I believe the 
problem is not related to the acpi irqoverride.

The DSDT been dumped from the legacy BIOS using acpidump and this is 
what I am including in the build process to test. Actually I've based my 
code on the mainboard\intel\eagleheigths.

I wanted to discard the linux problem so far and concentrate on Windows 
XP install. I've been disabling the ACPI ( pressing F7 in early install 
) and it goes well until "Starting windows..." then I get a BSOD : STOP: 
0x0000007B (0xF8980524, 0xc0000034, 0x0000000, 0x00000000).

This error indeed point to "Inaccessible Boot Device" and the second 
argument 0xc0000043 points to "Status Object Name Not Found"

This post is quite old and nothing have been answered to it since July 
2008. You probably been able to fix that issue. What is related to 
missing floppy disk controller or something else?

Thank you.

Arnaud

reference email :

>/ -----Original Message-----
/>/ From: Kevin O'Connor [mailto:kevin at koconnor.net <http://www.coreboot.org/mailman/listinfo/coreboot>]
/>/ Sent: Friday, July 25, 2008 9:49 PM
/>/ To: Myles Watson
/>/ Cc: Coreboot
/>/ Subject: Re: SeaBIOS WinXP install
/>/ 
/>/ Hi Myles,
/>/ 
/>/ On Fri, Jul 25, 2008 at 03:58:05PM -0600, Myles Watson wrote:
/>/ > Just for the fun of it I tried installing XP with the old Bochs BIOS and
/>/ > then booting it with SeaBIOS.  It installs fine, then can't boot with
/>/ either
/>/ > BIOS.  With SeaBIOS, it blue screens with the same message as the
/>/ install
/>/ > CD.  Here's the log:
/>/ 
/>/ The log looks like a CD boot log - was it the same for the hd boot?
/
After an install, you have to reboot with the CD.
 
>/ A couple of notes:
/>/ 
/>/ A "STOP: 0x0000007B" message is an INACCESSIBLE_BOOT_DEVICE error
/>/ according to:
/>/ 
/>/ http://blogs.technet.com/asksbs/archive/2008/03/30/how-to-troubleshoot-
/>/ the-stop-error-0x0000007b.aspx
/>/ 
/>/ I did notice that the last log message always seems to be:
/>/ 
/>/ > fail floppy_13XX:709(00000001):
/>/ >   a=00001507 b=00000003 c=0000000f d=00065000 si=00005026 di=00000000
/>/ >   ds=00001a49 es=0000504a ip=000055be cs=00001000 f=00000212 r=00000c02
/>/ 
/>/ you could try enabling the CONFIG_FLOPPY_SUPPORT on your machine.  If
/>/ that doesn't work, you could try just enabling a floppy_1315() handler
/>/ that always sets regs->ah=0 and calls set_success().
/
I'll try it.
 
>/ Another thing to try would be to set DEBUG_HDL_13 and DEBUG_HDL_40 to
/>/ 1 so that you see every call into the bios disk handlers.
/>/ 
/>/ BTW, what are you using to log the output from serial?  If something
/>/ is sending backspaces - is there a way to capture that?
/
I'm using HyperTerminal.  Thanks for pointing this out.  It shoots my theory
about backspaces, because HyperTerminal logs those.  Any thoughts on where
the disappearing output might go?

>/ 
/>/ Also, you reported that Bochs 1.186 is working with ADLO.  Does a more
/>/ recent version of Bochs also work?  The seabios code is basically in
/>/ synch with the latest bochs (v1.211).
/
I can try it.

>/ I wish there was more help I could give; unfortunately I'm seeing a
/>/ totally different set of failures here.  :-(
/
Hopefully we'll get to a common case eventually so we can help each other
better.

Thanks,
Myles




*
*



From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep  1 15:34:24 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 01 Sep 2009 15:34:24 +0200
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9D1AFC.7080607@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com>
Message-ID: <4A9D22E0.3070906@gmx.net>

Hi Arnaud,

On 01.09.2009 15:00, Arnaud Maye wrote:
> I've been implementing the ACPI for the ep80579 and so far it is not
> going very well. Linux refuses to boot unless I use acpi=off or
> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
> in proc/ioports as expected ( the ioports addresses are all mapped to
> the ACPI BAR ). Without to disable acpi the kernel complains that the
> 0xE0000000 range is not a reserved  range and the MMCONF is not
> supported and then hangs.

Rudolf knows how to reserve the MMCONFIG area properly so that Linux is
happy with it. I've seen all sorts of boot problems on machines where
Linux disabled MMCONFIG.

> Using acpi=noirq still hangs so I believe the problem is not related
> to the acpi irqoverride.
>
> The DSDT been dumped from the legacy BIOS using acpidump and this is
> what I am including in the build process to test. Actually I've based
> my code on the mainboard\intel\eagleheigths.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Tue Sep  1 15:34:40 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 01 Sep 2009 15:34:40 +0200
Subject: [coreboot] coreboot utilities on MacOSX
In-Reply-To: <18d205ed0909010436w6886a7dcv82a877494560d5ec@mail.gmail.com>
References: <4A9CF76F.4090406@coresystems.de>
	<18d205ed0909010436w6886a7dcv82a877494560d5ec@mail.gmail.com>
Message-ID: <4A9D22F0.8060108@coresystems.de>

Gregg Levine wrote:
> On Tue, Sep 1, 2009 at 6:29 AM, Stefan Reinauer<stepan at coresystems.de> wrote:
>   
>> Hi,
>>
>> As a weekend project I had been porting coreboot utilities to Mac OS X.
>>
>> I put up a new set of installer images, source code and patches to
>>
>> http://www.coresystems.de/~stepan/OSX/
>>
>> The order of installation should be:
>> - DirectIO 1.1
>> - pciutils 3.1.4
>> - coreboot-utils 1.0
>>
>> All packages are both 32bit and 64bit and they have been tested on Mac
>> OS X 10.6.
>>
>> Feedback is welcome!
>>
>> Stefan
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>>     
>
> Hello!
> I am decidedly impressed. Those are well needed. Next question have
> they been tested against the next latest version of OS/X?
>
> There's some controversy raging regarding a user space program not
> running properly on this big cat, as it no longer does everything that
> it did before.
>   
OS X 10.6 is the "latest and greatest". In fact, the binaries didn't
work very well on an OS X 10.5.8 installation, but the source can be
easily compiled on 10.5.x and 10.4.x by removing the x86_64 stuff from
DirectIO's Xcode project file.

Stefan



From peter at stuge.se  Tue Sep  1 15:57:13 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 1 Sep 2009 15:57:13 +0200
Subject: [coreboot] [PATCH] misc coreboot utility patches
In-Reply-To: <4A9C28F4.7010105@coresystems.de>
References: <4A9C15AC.7060009@coresystems.de>
	<20090831192711.13528.qmail@stuge.se>
	<4A9C28F4.7010105@coresystems.de>
Message-ID: <20090901135713.28317.qmail@stuge.se>

Stefan Reinauer wrote:
> Ah right.. I misunderstood the API.

No problem.


> Shouldn't the code for Darwin be only compiled into the Darwin
> executable, and the code for Linux only on Linux systems?
> 
> Doing a check every time the program runs when it can be checked at
> compile time seems a bit overkill, on the first thought.

Yes, if there's no chance for the binary to be used on another
system. (File formats, etc.)

The idea behind the system list is that some systems may be similar
enough to use the same binary, but will still need different register
access implementations and that some systems could support multiple
register access implementations.

But maybe there will only ever be two? Native, and inline asm rdmsr?
There's no use left for the probing then.


> > I have no problem with this, but can you explain why the manual
> > push/pop is needed? Maybe the new variant is the only one we need?
> 
> ebx is a reserved register on OSX/PIC

Ok. Do you still recommend to keep both implementations?


> >> -LDFLAGS=`trylink "libpci (from pciutils)" "${pc_LDFLAGS}" "-lpci -lz" "-L/usr/local/lib -lpci -lz" "-framework IOKit -L/usr/local/lib -lpci -lz"` || {
> >> +LDFLAGS=`trylink "libpci (from pciutils)" "${pc_LDFLAGS}" "-lpci -lz" "-lpci -lz" "-framework IOKit -framework DirectIO -lpci -lz"` || {
> >>     
> > Why remove /usr/local/lib ? I'd like to have that still in there.
> 
> Because the default install location for the packages is in /usr..

Not in pciutils-3.1.2.tar.gz;

$ tar xfz /usr/portage/distfiles/pciutils-3.1.2.tar.gz
$ cd pciutils-3.1.2/
$ grep PREFIX Makefile
PREFIX=/usr/local
...


> The libpci in /usr/local comes from another source which is
> incompatible with the one compiled with directio.

I understand. Will it build successfully but fail to run - or also
fail to build? Hm, in any case I think it's possible to fix this up.
I suggest:

LDFLAGS=`trylink "libpci (from pciutils)" "${pc_LDFLAGS}" "-lpci -lz" "-L/usr/local/lib -lpci -lz" "-framework IOKit -framework DirectIO -lpci -lz" "-framework IOKit -framework DirectIO -L/usr/local/lib -lpci -lz"` || {

The entries without frameworks should fail on Darwin but build OK on
systems with libpci in /usr/local, right?

You could also take out the very last argument if you want.


//Peter



From svn at coreboot.org  Tue Sep  1 17:29:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue,  1 Sep 2009 17:29:13 +0200
Subject: [coreboot] [v2] r4625 -
	trunk/coreboot-v2/src/southbridge/via/vt8237r
Message-ID: <mailman.3687.1355071616.16123.coreboot@coreboot.org>

Author: ruik
Date: 2009-09-01 17:29:12 +0200 (Tue, 01 Sep 2009)
New Revision: 4625

Modified:
   trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237_ctrl.c
Log:
As more users of Asus M2V-MX SE emerged. Here is long pending patch I wanted to
write. It boots the SB/NB V-link performance to full duplex 533MB/s. (in fact x2
for FDX)

The default was 266MB/s but half duplex only. If you encourage any stability
issues we need to look into fine tuning the bus. The values are VIA recommended.

Signed-off-by: Rudolf Marek <r.marek at assembler.cz>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237_ctrl.c
===================================================================
--- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237_ctrl.c	2009-09-01 10:03:01 UTC (rev 4624)
+++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237_ctrl.c	2009-09-01 15:29:12 UTC (rev 4625)
@@ -94,6 +94,9 @@
  * V-Link CKG Control				 0xb0  0x05  0x05  0x06  0x03
  * V-Link CKG Control				 0xb1  0x05  0x05  0x01  0x03
  */
+
+/* we setup 533MB/s mode full duplex */
+
 static void vt8237s_vlink_init(struct device *dev)
 {
 	u8 reg;
@@ -114,24 +117,47 @@
 	 * and VT8251) a different init code is required.
 	 */
 
+	/* disable auto disconnect */
+	reg = pci_read_config8(devfun7, 0x42);
+	reg &= ~0x4;
+	pci_write_config8(devfun7, 0x42, reg);
+
+	/* NB part setup */
 	pci_write_config8(devfun7, 0xb5, 0x66);
 	pci_write_config8(devfun7, 0xb6, 0x66);
-	pci_write_config8(devfun7, 0xb7, 0x65);
+	pci_write_config8(devfun7, 0xb7, 0x64);
 
 	reg = pci_read_config8(devfun7, 0xb4);
 	reg |= 0x1;
+	reg &= ~0x10;
 	pci_write_config8(devfun7, 0xb4, reg);
 
-	pci_write_config8(dev, 0xb9, 0x68);
+	pci_write_config8(devfun7, 0xb0, 0x6);
+	pci_write_config8(devfun7, 0xb1, 0x1);
+
+	/* SB part setup */
+	pci_write_config8(dev, 0xb7, 0x60);
+	pci_write_config8(dev, 0xb9, 0x88);
 	pci_write_config8(dev, 0xba, 0x88);
 	pci_write_config8(dev, 0xbb, 0x89);
 
 	reg = pci_read_config8(dev, 0xbd);
 	reg |= 0x3;
+	reg &= ~0x4;
 	pci_write_config8(dev, 0xbd, reg);
 
-	/* Program V-link 8X 8bit full duplex, parity disabled. FIXME. */
-	pci_write_config8(dev, 0x48, 0x13);
+	reg = pci_read_config8(dev, 0xbc);
+	reg &= ~0x7;
+	pci_write_config8(dev, 0xbc, reg);
+
+	/* Program V-link 8X 8bit full duplex, parity enabled.  */
+	pci_write_config8(dev, 0x48, 0x23 | 0x80);
+
+	/* enable auto disconnect, for STPGNT and HALT */
+	reg = pci_read_config8(devfun7, 0x42);
+	reg |= 0x7;
+	pci_write_config8(devfun7, 0x42, reg);
+
 }
 
 static void ctrl_enable(struct device *dev)
@@ -158,8 +184,7 @@
 	device_t devsb = dev_find_device(PCI_VENDOR_ID_VIA,
 					 PCI_DEVICE_ID_VIA_VT8237S_LPC, 0);
 	if (devsb) {
-		/* FIXME: Skip v-link setup for now. */
-//              vt8237s_vlink_init(dev);
+		vt8237s_vlink_init(dev);
 	}
 
 	/* Configure PCI1 and copy mirror registers from D0F3. */




From r.marek at assembler.cz  Tue Sep  1 17:29:43 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 01 Sep 2009 17:29:43 +0200
Subject: [coreboot] [PATCH] V-link optimization on K8M890/VT8237S
In-Reply-To: <4A9BE2F1.4040205@coresystems.de>
References: <4A9A9BF8.7070009@assembler.cz> <4A9BE2F1.4040205@coresystems.de>
Message-ID: <4A9D3DE7.6080601@assembler.cz>

> Is there some way to find out the "correct" maximum speed, as on Hyper
> Transport?

Yes there is but it is fixed for the known SB/NB combinations so we don't need 
this yet. Also for each mode a set of fine tunes is necessary.

> Acked-by: Stefan Reinauer <stepan at coresystems.de>

Ok thanks.

I forgot to Signed-off-by: Rudolf Marek <r.marek at assembler.cz>

Committed revision 4625.

Thanks,
Rudolf



From mylesgw at gmail.com  Tue Sep  1 17:33:36 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 1 Sep 2009 09:33:36 -0600
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9D1AFC.7080607@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com>
Message-ID: <2831fecf0909010833h36f5381fi965e74eae9206d08@mail.gmail.com>

On Tue, Sep 1, 2009 at 7:00 AM, Arnaud Maye<arnaud.maye at 4dsp.com> wrote:
> Hello Myles, Kevin and others
>
> I've been implementing the ACPI for the ep80579 and so far it is not going
> very well. Linux refuses to boot unless I use acpi=off or acpi=ht as boot
> parameters. acpi=ht seems to display my ACPI ioports in proc/ioports as
> expected ( the ioports addresses are all mapped to the ACPI BAR ). Without
> to disable acpi the kernel complains that the 0xE0000000 range is not a
> reserved ?range and the MMCONF is not supported and then hangs. Using
> acpi=noirq still hangs so I believe the problem is not related to the acpi
> irqoverride.
If you boot using acpi=off you can use the Linux Firmware Developers
Kit ( http://linuxfirmwarekit.org/ ) to debug ACPI issues.  Then
you'll have lspci available to check against what the tables are
saying.

> The DSDT been dumped from the legacy BIOS using acpidump and this is what I
> am including in the build process to test. Actually I've based my code on
> the mainboard\intel\eagleheigths.
I couldn't use the factory DSDT for my mainboard because so many of
the initialization values were different when booted with Coreboot.

> I wanted to discard the linux problem so far and concentrate on Windows XP
> install. I've been disabling the ACPI ( pressing F7 in early install ) and
> it goes well until "Starting windows..." then I get a BSOD : STOP:
> 0x0000007B (0xF8980524, 0xc0000034, 0x0000000, 0x00000000).
Linux is much more forgiving.  I personally wouldn't try Windows
without Linux working.  There's much more debugging information
available with Linux.

> This error indeed point to "Inaccessible Boot Device" and the second
> argument 0xc0000043 points to "Status Object Name Not Found"
>
> This post is quite old and nothing have been answered to it since July 2008.
> You probably been able to fix that issue. What is related to missing floppy
> disk controller or something else?
I haven't looked at it since then.  One of the things that makes my
s2895 challenging is multiple PCI root buses.  I haven't gotten that
quite right yet.

Thanks,
Myles



From andrew.goodbody at tadpole.com  Tue Sep  1 18:28:58 2009
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Tue, 01 Sep 2009 17:28:58 +0100
Subject: [coreboot] Phoenix Technologies and General Software
In-Reply-To: <13426df10908280841v5e6f94dcq1f63b7a67a92557c@mail.gmail.com>
References: <8D45F866BEB34DC2AB6C47D5DE42F374@chimp>	<5FBC4C9BD2AB42E1BD86C6B0F0CC2DB1@who8>	<55ef9dc50908280241n7a644f34s71baaa906d93178@mail.gmail.com>	<4A97A752.8020303@coresystems.de>	<55ef9dc50908280324v1dee17d7kaa7efc4b3ea80279@mail.gmail.com>	<534e5dc20908280834n21374d88v3176a3547bee7000@mail.gmail.com>
	<13426df10908280841v5e6f94dcq1f63b7a67a92557c@mail.gmail.com>
Message-ID: <4A9D4BCA.3010908@tadpole.com>

ron minnich wrote:
> On Fri, Aug 28, 2009 at 8:34 AM, Marc Jones<marcj303 at gmail.com> wrote:
> 
>> http://www.bizjournals.com/seattle/stories/2008/09/01/daily3.html?ana=from_rss
>> http://en.wikipedia.org/wiki/Phoenix_Technologies
> 
> interesting, the consolidation continues. Do you think they killed the
> product or are still reselling it? I am guessing the former.
> 
> ron
> 

Phoenix are still selling it.
http://www.phoenix.com/en/Embedded/Products/Core+Bios+Products/Embedded+BIOS/default.htm

Andrew




From r.marek at assembler.cz  Tue Sep  1 22:15:50 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Tue, 01 Sep 2009 22:15:50 +0200
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9D22E0.3070906@gmx.net>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
Message-ID: <4A9D80F6.1040906@assembler.cz>

Hi

> On 01.09.2009 15:00, Arnaud Maye wrote:
>> I've been implementing the ACPI for the ep80579 and so far it is not
>> going very well. Linux refuses to boot unless I use acpi=off or
>> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
>> in proc/ioports as expected ( the ioports addresses are all mapped to
>> the ACPI BAR ). Without to disable acpi the kernel complains that the
>> 0xE0000000 range is not a reserved  range and the MMCONF is not
>> supported and then hangs.

It should not hang. The complain is only about e820 map is not reserved. I made 
recently a small patch for this for K8M890. Simply the problem seems elsewhere 
to me.

>> The DSDT been dumped from the legacy BIOS using acpidump and this is
>> what I am including in the build process to test. Actually I've based
>> my code on the mainboard\intel\eagleheigths.
> 
Please try to develop minimalistic  DSDT based on M2V-MX SE and read the ACPI 
guide on the wiki.

You need to have linux working first and then go for windows.

Please try to read the wiki pages and then ask so we can improve the pages.
http://www.coreboot.org/ACPI_in_coreboot

Rudolf




From c-d.hailfinger.devel.2006 at gmx.net  Wed Sep  2 00:34:05 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 02 Sep 2009 00:34:05 +0200
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9D80F6.1040906@assembler.cz>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz>
Message-ID: <4A9DA15D.2000704@gmx.net>

On 01.09.2009 22:15, Rudolf Marek wrote:
>> On 01.09.2009 15:00, Arnaud Maye wrote:
>>> I've been implementing the ACPI for the ep80579 and so far it is not
>>> going very well. Linux refuses to boot unless I use acpi=off or
>>> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
>>> in proc/ioports as expected ( the ioports addresses are all mapped to
>>> the ACPI BAR ). Without to disable acpi the kernel complains that the
>>> 0xE0000000 range is not a reserved  range and the MMCONF is not
>>> supported and then hangs.
>
> It should not hang. The complain is only about e820 map is not
> reserved. I made recently a small patch for this for K8M890. Simply
> the problem seems elsewhere to me.

But if MMCONF is not seen as active, the kernel might allocate something
else in that area. If the ACPI code uses MMCONF for PCI accesses, this
means the ACPI code will write/read with undefined side effects.
Besides that, if you forgot to (re)activate MMCONFIG inside coreboot,
you might see similar effects. I was fighting with RS690 code which
enabled MMCONF, used it for a few accesses, then disabled it again, but
the ACPI code tried to use MMCONF anyway. Effect were SATA problems/hangs.
Besides that, enabling MMCONF in the chipset may break some classic PCI
accesses. For example, if I enable MMCONF in the chipset and if the
kernel doesn't accept it due to missing reservation, my network card
fails because it uses extended config space for storing the MAC and
other stuff. When MMCONFIG in the chipset is disabled, it works, so
there must be some further interaction (maybe enabling MMCONFIG breaks
other access methods to extended config space).

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From kevin at koconnor.net  Wed Sep  2 02:25:01 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 1 Sep 2009 20:25:01 -0400
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9D1AFC.7080607@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com>
Message-ID: <20090902002501.GA8992@morn.localdomain>

On Tue, Sep 01, 2009 at 03:00:44PM +0200, Arnaud Maye wrote:
> The DSDT been dumped from the legacy BIOS using acpidump and this is  
> what I am including in the build process to test. Actually I've based my  
> code on the mainboard\intel\eagleheigths.

As others have mentioned, using the stock DSDT tables wont work with
coreboot and SeaBIOS.

-Kevin



From hansolofalcon at worldnet.att.net  Wed Sep  2 02:40:54 2009
From: hansolofalcon at worldnet.att.net (Gregg C Levine)
Date: Tue, 1 Sep 2009 20:40:54 -0400
Subject: [coreboot] Phoenix Technologies and General Software
In-Reply-To: <4A9D4BCA.3010908@tadpole.com>
Message-ID: <567666DB6F7446FDA9B3C0E68876245E@who8>

Hello!
Yes indeed, I did look at the page.

But I am miffed over the passing of General Software. The fellow who
launched it, escaped from Micro$~ft to create a version of DOS that was
real-time friendly. And then they buried that product hoping to capitalize
on the growing embedded BIOS market... I believe that's what prompted
Phoenix to grab them, to rescue the company before it made anymore bad
decisions.....

Now Andrew if we could track down a collection of Tadpole VME bus based
boards wearing the M68K family of processors......

(Ignore that remark fellow Coreboot participants, that's a side-remark to
Andrew G.
--
Gregg C Levine hansolofalcon at worldnet.att.net
"The Force will be with you always." Obi-Wan Kenobi
? 


> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
On
> Behalf Of Andrew Goodbody
> Sent: Tuesday, September 01, 2009 12:29 PM
> To: coreboot
> Subject: Re: [coreboot] Phoenix Technologies and General Software
> 
> ron minnich wrote:
> > On Fri, Aug 28, 2009 at 8:34 AM, Marc Jones<marcj303 at gmail.com> wrote:
> >
> >>
http://www.bizjournals.com/seattle/stories/2008/09/01/daily3.html?ana=from_r
ss
> >> http://en.wikipedia.org/wiki/Phoenix_Technologies
> >
> > interesting, the consolidation continues. Do you think they killed the
> > product or are still reselling it? I am guessing the former.
> >
> > ron
> >
> 
> Phoenix are still selling it.
>
http://www.phoenix.com/en/Embedded/Products/Core+Bios+Products/Embedded+BIOS
/de
> fault.htm
> 
> Andrew
> 
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot




From list_linuxbios at greencroft.co.uk  Wed Sep  2 02:50:26 2009
From: list_linuxbios at greencroft.co.uk (greg)
Date: Wed, 2 Sep 2009 01:50:26 +0100
Subject: [coreboot] Phoenix Technologies and General Software
In-Reply-To: <567666DB6F7446FDA9B3C0E68876245E@who8>
References: <4A9D4BCA.3010908@tadpole.com>
	<567666DB6F7446FDA9B3C0E68876245E@who8>
Message-ID: <1211799075.20090902015026@somewhere.somehow>

> Now Andrew if we could track down a collection of Tadpole VME bus based
> boards wearing the M68K family of processors......
> (Ignore that remark fellow Coreboot participants, that's a side-remark to
> Andrew G.

Now if I could only find a spare VME chasis to put this here TP43M in,
I could have a fiddle with it... :)

greg




From andrew.goodbody at tadpole.com  Wed Sep  2 12:15:04 2009
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Wed, 02 Sep 2009 11:15:04 +0100
Subject: [coreboot] Phoenix Technologies and General Software
In-Reply-To: <1211799075.20090902015026@somewhere.somehow>
References: <4A9D4BCA.3010908@tadpole.com>
	<567666DB6F7446FDA9B3C0E68876245E@who8>
	<1211799075.20090902015026@somewhere.somehow>
Message-ID: <4A9E45A8.7000804@tadpole.com>

greg wrote:
>> Now Andrew if we could track down a collection of Tadpole VME bus based
>> boards wearing the M68K family of processors......
>> (Ignore that remark fellow Coreboot participants, that's a side-remark to
>> Andrew G.
> 
> Now if I could only find a spare VME chasis to put this here TP43M in,
> I could have a fiddle with it... :)
> 
> greg
> 

Sorry guys but that's the wrong Tadpole. AFAIK the VME stuff was by 
Tadpole Technology which is I believe no longer in existence. I work for 
what is left of Tadpole Computer.

Andrew



From arnaud.maye at 4dsp.com  Wed Sep  2 16:31:19 2009
From: arnaud.maye at 4dsp.com (Arnaud Maye)
Date: Wed, 02 Sep 2009 16:31:19 +0200
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9DA15D.2000704@gmx.net>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz> <4A9DA15D.2000704@gmx.net>
Message-ID: <4A9E81B7.1040901@4dsp.com>

Carl-Daniel Hailfinger wrote:
> On 01.09.2009 22:15, Rudolf Marek wrote:
>   
>>> On 01.09.2009 15:00, Arnaud Maye wrote:
>>>       
>>>> I've been implementing the ACPI for the ep80579 and so far it is not
>>>> going very well. Linux refuses to boot unless I use acpi=off or
>>>> acpi=ht as boot parameters. acpi=ht seems to display my ACPI ioports
>>>> in proc/ioports as expected ( the ioports addresses are all mapped to
>>>> the ACPI BAR ). Without to disable acpi the kernel complains that the
>>>> 0xE0000000 range is not a reserved  range and the MMCONF is not
>>>> supported and then hangs.
>>>>         
>> It should not hang. The complain is only about e820 map is not
>> reserved. I made recently a small patch for this for K8M890. Simply
>> the problem seems elsewhere to me.
>>     
>
> But if MMCONF is not seen as active, the kernel might allocate something
> else in that area. If the ACPI code uses MMCONF for PCI accesses, this
> means the ACPI code will write/read with undefined side effects.
> Besides that, if you forgot to (re)activate MMCONFIG inside coreboot,
> you might see similar effects. I was fighting with RS690 code which
> enabled MMCONF, used it for a few accesses, then disabled it again, but
> the ACPI code tried to use MMCONF anyway. Effect were SATA problems/hangs.
> Besides that, enabling MMCONF in the chipset may break some classic PCI
> accesses. For example, if I enable MMCONF in the chipset and if the
> kernel doesn't accept it due to missing reservation, my network card
> fails because it uses extended config space for storing the MAC and
> other stuff. When MMCONFIG in the chipset is disabled, it works, so
> there must be some further interaction (maybe enabling MMCONFIG breaks
> other access methods to extended config space).
>
> Regards,
> Carl-Daniel
>
>   
Hello Guys,

So actually, I've been able to prevent linux complaining about non 
reserved 0xe0000000 range via
add_mainboard_resource().

With the intel firmware dev kit pointed by Myles I've been able to 
remove all the obvious ACPI
issues. I've enabled the HPET in the chipset and modified the 
acpi_tables.c file to create that table
as well as the MADT table.

The kernel hangs around the sata! Actually the system hang for a minute 
and then start to display:
-------------------------------------------------------------------------------------------------
ata1.00: exception Emask 0x0 SAct 0x0 Srr 0x0 action 0x2 frozen
ata1.00: cmd a0/00:00:00:24:00/00:00:00:00:00/a0 tag 0 pio 36 in
ata1.00: status: { DRDY }
...
ata2.00: exception Emask 0x0 DAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
ata2.00: status: { DRDY }
...
ata1: WARNING: synchronous SCSI scan failed without making any progress,
...
Buffer I/O error on device sda, logical block 0
...

Just before the system to hang, seabios displays :
-------------------------------------------------
fail handle_legacy_disk:845(1):
   a=ffff0201  b=00000d00  c=00000001  d=47530081 ds=9000 es=9000 ss=9000
  si=fff0fff0 di=0009fff0 bp=00001ff0 sp=00008ff8 cs=9020 ip=1015  f=0283
fail handle_legacy_disk:845(1):
   a=ffff415a  b=000055aa  c=0000fe03  d=47530081 ds=9000 es=9000 ss=9000
  si=fff00d5a di=00090000 bp=00001ff0 sp=00008ffe cs=9020 ip=1043  f=0293


Here is the lspci for both legacy and coreboot :
-----------------------------------------------
legacy :
00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01) 
(prog-if 8f [Master SecP SecO PriP PriO])
    Subsystem: Intel Corporation EP80579 S-ATA IDE
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
    I/O ports at f080 [size=8]
    I/O ports at f070 [size=4]
    I/O ports at f060 [size=8]
    I/O ports at f050 [size=4]
    I/O ports at f040 [size=16]
    Memory at d0100000 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [70] Power Management version 2

00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01) 
(prog-if 8f [Master SecP SecO PriP PriO])
    Subsystem: Intel Corporation Unknown device 2680
    Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
    I/O ports at 2410 [size=8]
    I/O ports at 2420 [size=4]
    I/O ports at 2418 [size=8]
    I/O ports at 2424 [size=4]
    I/O ports at 2400 [size=16]
    Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
    Capabilities: [70] Power Management version 2

Actually same except io ports are located another place and the 
subsystem IDs is set differently by the driver. I do
not think the last one would cause any troubles.

So am not sure where is the problem here, booting with acpi=off does not 
show any sata issue.

Any help/pointers are welcome,

Thank you

Arnaud











*


*



From mylesgw at gmail.com  Wed Sep  2 16:37:37 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 2 Sep 2009 08:37:37 -0600
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9E81B7.1040901@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz> <4A9DA15D.2000704@gmx.net>
	<4A9E81B7.1040901@4dsp.com>
Message-ID: <9BA9DB77A65E49D4A822B419AAE607F4@chimp>

> Here is the lspci for both legacy and coreboot :
> -----------------------------------------------
> legacy :
> 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
> (prog-if 8f [Master SecP SecO PriP PriO])
>     Subsystem: Intel Corporation EP80579 S-ATA IDE
>     Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
>     I/O ports at f080 [size=8]
>     I/O ports at f070 [size=4]
>     I/O ports at f060 [size=8]
>     I/O ports at f050 [size=4]
>     I/O ports at f040 [size=16]
>     Memory at d0100000 (32-bit, non-prefetchable) [size=1K]
>     Capabilities: [70] Power Management version 2
> 
> 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
> (prog-if 8f [Master SecP SecO PriP PriO])
>     Subsystem: Intel Corporation Unknown device 2680
>     Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
>     I/O ports at 2410 [size=8]
>     I/O ports at 2420 [size=4]
>     I/O ports at 2418 [size=8]
>     I/O ports at 2424 [size=4]
>     I/O ports at 2400 [size=16]
>     Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
>     Capabilities: [70] Power Management version 2
> 
> Actually same except io ports are located another place and the
> subsystem IDs is set differently by the driver. I do
> not think the last one would cause any troubles.
I don't think the IO port location is a problem, unless it conflicts with
something in the DSDT.  The IRQ setting is also different. 145 seems pretty
high.

Thanks,
Myles





From arnaud.maye at 4dsp.com  Wed Sep  2 17:04:10 2009
From: arnaud.maye at 4dsp.com (Arnaud Maye)
Date: Wed, 02 Sep 2009 17:04:10 +0200
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <9BA9DB77A65E49D4A822B419AAE607F4@chimp>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz> <4A9DA15D.2000704@gmx.net>
	<4A9E81B7.1040901@4dsp.com>
	<9BA9DB77A65E49D4A822B419AAE607F4@chimp>
Message-ID: <4A9E896A.8070907@4dsp.com>

Myles Watson wrote:
>> Here is the lspci for both legacy and coreboot :
>> -----------------------------------------------
>> legacy :
>> 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
>> (prog-if 8f [Master SecP SecO PriP PriO])
>>     Subsystem: Intel Corporation EP80579 S-ATA IDE
>>     Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 58
>>     I/O ports at f080 [size=8]
>>     I/O ports at f070 [size=4]
>>     I/O ports at f060 [size=8]
>>     I/O ports at f050 [size=4]
>>     I/O ports at f040 [size=16]
>>     Memory at d0100000 (32-bit, non-prefetchable) [size=1K]
>>     Capabilities: [70] Power Management version 2
>>
>> 00:1f.2 IDE interface: Intel Corporation EP80579 S-ATA IDE (rev 01)
>> (prog-if 8f [Master SecP SecO PriP PriO])
>>     Subsystem: Intel Corporation Unknown device 2680
>>     Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 145
>>     I/O ports at 2410 [size=8]
>>     I/O ports at 2420 [size=4]
>>     I/O ports at 2418 [size=8]
>>     I/O ports at 2424 [size=4]
>>     I/O ports at 2400 [size=16]
>>     Memory at d4a07400 (32-bit, non-prefetchable) [size=1K]
>>     Capabilities: [70] Power Management version 2
>>
>> Actually same except io ports are located another place and the
>> subsystem IDs is set differently by the driver. I do
>> not think the last one would cause any troubles.
>>     
> I don't think the IO port location is a problem, unless it conflicts with
> something in the DSDT.  The IRQ setting is also different. 145 seems pretty
> high.
>   
What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an 
ACPI=force boot and on coreboot
this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the 
operating system. I just want to
verify if this is normal or not.

Thank you,

Arnaud



From mylesgw at gmail.com  Wed Sep  2 17:13:34 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 2 Sep 2009 09:13:34 -0600
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9E896A.8070907@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz> <4A9DA15D.2000704@gmx.net>
	<4A9E81B7.1040901@4dsp.com>
	<9BA9DB77A65E49D4A822B419AAE607F4@chimp>
	<4A9E896A.8070907@4dsp.com>
Message-ID: <A3A9283CFF5F4F4DB1DE29D74737FDEF@chimp>

> > I don't think the IO port location is a problem, unless it conflicts
> with
> > something in the DSDT.  The IRQ setting is also different. 145 seems
> pretty
> > high.
> >
> What this IRQ 145 (or 58) relates to. On the legacy BIOS this is an
> ACPI=force boot and on coreboot
> this is an ACPI=off. Is this IRQ assigned by coreboot, by seabios or the
> operating system. I just want to
> verify if this is normal or not.

I wish I knew more about it.  Here's the part of Rudolf's page about that:
http://www.coreboot.org/ACPI_in_coreboot#Interrupt_routing_in_DSDT

My understanding is that the IRQs are specified as offsets from IOAPICs,
each of which supply some number of IRQs.  If your DSDT specifies this
differently than the chipset was configured by Coreboot, it breaks.

Myles






From bernie at codewiz.org  Wed Sep  2 22:12:21 2009
From: bernie at codewiz.org (Bernie Innocenti)
Date: Wed, 02 Sep 2009 16:12:21 -0400
Subject: [coreboot] PATCH: do not rely on "tempfile" being available
Message-ID: <1251922341.1487.57.camel@giskard>

Signed-off-by: Bernie Innocenti <bernie at codewiz.org>

Build fix: add a fallback for systems where tempfile is missing

Index: bin/show-instructions.sh
===================================================================
--- bin/show-instructions.sh	(revision 261)
+++ bin/show-instructions.sh	(working copy)
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-tmp=`tempfile`
+tmp=`tempfile 2>/dev/null || echo /tmp/show-instructions.$$`
 cat $1 | sed -e "s:%DESTFILE%:$2:" > $tmp
 
 if [ -x `dirname $0`/../scripts/kconfig/lxdialog/lxdialog ]; then

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/




From ward at gnu.org  Wed Sep  2 23:14:57 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 2 Sep 2009 17:14:57 -0400
Subject: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps
	resetting
Message-ID: <20090902211457.GA14114@countzero.vandewege.net>

Hi all,

I'm having some problems with a supermicro h8dme board with 2 K8 processors
and 64 GB of ram.

Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.

The memory is installed like this:

BANK     CPU1        CPU2
1B       KING        KING
1A       KING        KING
2B       KING        KING
2A       KING        KING
3B       SAMS        SAMS
3A       SAMS        SAMS
4B       SAMS        SAMS
4A       SAMS        SAMS

With the proprietary BIOS, this setup works perfectly. That said, the manual
for the board does say it's not recommended to mix memory types. Our system
integrator mentions that when 16 banks are used, the memory runs at maximum
533MHz.

I should mention that this particular coreboot port has one oddity - the
memory on each CPU must be matched because we don't know how to do the SPD
address switch to detect ram on the second CPU.

As you can see in the diagram above, that condition is met.

There are two problems. First, with the above (64GB) configuration coreboot
just keeps resetting itself after printing "Clearing initial memory region:".
I've attached a log with RAM_TIMING_DEBUG enabled, see
minicom-20090902-with-64G.cap.

Perhaps this is related to coreboot not dropping down to 533MHz with 16 DIMMs
installed?

Dropping the installed ram down to 48GB like this:

BANK     CPU1        CPU2
1B       KING        KING
1A       KING        KING
2B       KING        KING
2A       KING        KING
3B       SAMS        SAMS
3A       SAMS        SAMS
4B        --          --
4A        --          --

Makes the boot get all the way to seabios, but the board still resets itself
just before booting the linux kernel. See attached
minicom-20090902-with-48G.cap.

Any thoughts on what might be happening here, or how I could debug further?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20090902-with-64G.cap
Type: application/cap
Size: 50637 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090902/ff6b9d35/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minicom-20090902-with-48G.cap
Type: application/cap
Size: 404768 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090902/ff6b9d35/attachment-0001.bin>

From svn at coreboot.org  Wed Sep  2 23:41:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed,  2 Sep 2009 23:41:13 +0200
Subject: [coreboot] [BuildROM] r271 - buildrom-devel/bin
Message-ID: <mailman.3688.1355071617.16123.coreboot@coreboot.org>

Author: ward
Date: 2009-09-02 23:41:13 +0200 (Wed, 02 Sep 2009)
New Revision: 271

Modified:
   buildrom-devel/bin/show-instructions.sh
Log:

Build fix: add a fallback for systems where tempfile is missing

Signed-off-by: Bernie Innocenti <bernie at codewiz.org>
Acked-by: Ward Vandewege <ward at gnu.org>



Modified: buildrom-devel/bin/show-instructions.sh
===================================================================
--- buildrom-devel/bin/show-instructions.sh	2009-08-24 16:10:31 UTC (rev 270)
+++ buildrom-devel/bin/show-instructions.sh	2009-09-02 21:41:13 UTC (rev 271)
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-tmp=`tempfile`
+tmp=`tempfile 2>/dev/null || echo /tmp/show-instructions.$$`
 cat $1 | sed -e "s:%DESTFILE%:$2:" > $tmp
 
 if [ -x `dirname $0`/../scripts/kconfig/lxdialog/lxdialog ]; then




From ward at gnu.org  Wed Sep  2 23:42:32 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 2 Sep 2009 17:42:32 -0400
Subject: [coreboot] PATCH: do not rely on "tempfile" being available
In-Reply-To: <1251922341.1487.57.camel@giskard>
References: <1251922341.1487.57.camel@giskard>
Message-ID: <20090902214232.GA30052@countzero.vandewege.net>

On Wed, Sep 02, 2009 at 04:12:21PM -0400, Bernie Innocenti wrote:
> Signed-off-by: Bernie Innocenti <bernie at codewiz.org>
> 
> Build fix: add a fallback for systems where tempfile is missing

Acked-by: Ward Vandewege <ward at gnu.org>

Committed in r271.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From ralfgb at gmail.com  Tue Sep  1 23:15:34 2009
From: ralfgb at gmail.com (Ralf Grosse Boerger)
Date: Tue, 01 Sep 2009 23:15:34 +0200
Subject: [coreboot] unstable AMD Fam10h boot
Message-ID: <op.uzljz7kn1ay1or@x53k>

Hi,

this a reply to the following message:
http://www.coreboot.org/pipermail/coreboot/2009-August/051629.html
[I am not subscribed to this list.]

The sporadic boot problems ("FIXME! CPU Version unknown or not  
supported!") are caused by a race condition in Get_NB32().

This function performs a read operation to the PCI configuration space via  
port CF8/CFC.

u32 Get_NB32(u32 dev, u32 reg)
{
	u32 addr;

	addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16);
	outl((1<<31) | (addr & ~3), 0xcf8);

	return inl(0xcfc);
}

As ports CF8/CFC are shared across cores (maybe even sockets?) concurrent  
accesses from different cores may yield random results.

This race condition is not limited to mctGetLogicalCPUID(), but should  
affect any PCI configuration space access.
A real bugfix requires some sort of mutex, but mutexes are difficult to  
implement (this was already discusses on this list).

If the cores are started sequentially, concurrent PCI accesses can be  
avoided.
I'll post example code as soon as I find some time...

Best Regards
	Ralf
 



From marcj303 at gmail.com  Thu Sep  3 00:03:45 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Wed, 2 Sep 2009 16:03:45 -0600
Subject: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps
	resetting
In-Reply-To: <20090902211457.GA14114@countzero.vandewege.net>
References: <20090902211457.GA14114@countzero.vandewege.net>
Message-ID: <534e5dc20909021503n3e1366ffkce39c2f6e3b1256d@mail.gmail.com>

Hi Ward,

On Wed, Sep 2, 2009 at 3:14 PM, Ward Vandewege<ward at gnu.org> wrote:
> Hi all,
>
> I'm having some problems with a supermicro h8dme board with 2 K8 processors
> and 64 GB of ram.
>
> Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
> Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
> types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.
>
> The memory is installed like this:
>
> BANK ? ? CPU1 ? ? ? ?CPU2
> 1B ? ? ? KING ? ? ? ?KING
> 1A ? ? ? KING ? ? ? ?KING
> 2B ? ? ? KING ? ? ? ?KING
> 2A ? ? ? KING ? ? ? ?KING
> 3B ? ? ? SAMS ? ? ? ?SAMS
> 3A ? ? ? SAMS ? ? ? ?SAMS
> 4B ? ? ? SAMS ? ? ? ?SAMS
> 4A ? ? ? SAMS ? ? ? ?SAMS
>
> With the proprietary BIOS, this setup works perfectly. That said, the manual
> for the board does say it's not recommended to mix memory types. Our system
> integrator mentions that when 16 banks are used, the memory runs at maximum
> 533MHz.

As we talked about, it looks like the memory is sized correctly and
the next thing to try forcing the memory speed slower. 8 dual rank
dimms (16 banks) s[eed limitation might be spec'd or errata. A check
might need to go into the main k8 mem init code.

Marc

-- 
http://marcjonesconsulting.com



From slaramen at gmail.com  Thu Sep  3 03:46:26 2009
From: slaramen at gmail.com (Sebastian Lara)
Date: Wed, 2 Sep 2009 21:46:26 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
Message-ID: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>

Hi,

I'm trying to revive a Linux Netwox eVelocity 2 Cluster with
LinuxBIOS-1.1.7.8 and Etherboot 5.2 on compute nodes. After some
trouble, I have access to a shell after node system installation over
network. My problem now is that I can't get localboot to work.

I need to know if I can re-burn the BIOS with a newer version of
coreboot or something else, so I can use PXE and use GRUB for booting
from local.

Here is my lspci output. Thanks in advance for any help

lspci -tv
-+-[0000:01]-+-01.0-[0000:02]--+-03.0  Broadcom Corporation NetXtreme
BCM5702X Gigabit Ethernet
 |           |                 \-04.0  Broadcom Corporation NetXtreme
BCM5702X Gigabit Ethernet
 |           +-01.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
 |           +-02.0-[0000:03-04]----01.0-[0000:04]----00.0  Mellanox
Technologies MT23108 InfiniHost
 |           +-02.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
 |           +-03.0-[0000:05]--+-00.0  Advanced Micro Devices [AMD] AMD-8111 USB
 |           |                 +-00.1  Advanced Micro Devices [AMD] AMD-8111 USB
 |           |                 \-06.0  ATI Technologies Inc Rage XL
 |           +-04.0  Advanced Micro Devices [AMD] AMD-8111 LPC
 |           +-04.1  Advanced Micro Devices [AMD] AMD-8111 IDE
 |           +-04.2  Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
 |           +-04.3  Advanced Micro Devices [AMD] AMD-8111 ACPI
 |           \-04.6  Advanced Micro Devices [AMD] AMD-8111 MC97 Modem
 \-[0000:00]-+-18.0  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
             +-18.1  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
             +-18.2  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
             +-18.3  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control
             +-19.0  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
             +-19.1  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Address Map
             +-19.2  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller
             \-19.3  Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] Miscellaneous Control


sh-3.2#  lspci -tvnn
-+-[0000:01]-+-01.0-[0000:02]--+-03.0  14e4:16a6
 |           |                 \-04.0  14e4:16a6
 |           +-01.1  1022:7451
 |           +-02.0-[0000:03-04]----01.0-[0000:04]----00.0  15b3:5a44
 |           +-02.1  1022:7451
 |           +-03.0-[0000:05]--+-00.0  1022:7464
 |           |                 +-00.1  1022:7464
 |           |                 \-06.0  1002:4752
 |           +-04.0  1022:7468
 |           +-04.1  1022:7469
 |           +-04.2  1022:746a
 |           +-04.3  1022:746b
 |           \-04.6  1022:746e
 \-[0000:00]-+-18.0  1022:1100
             +-18.1  1022:1101
             +-18.2  1022:1102
             +-18.3  1022:1103
             +-19.0  1022:1100
             +-19.1  1022:1101
             +-19.2  1022:1102
             \-19.3  1022:1103





-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From ward at gnu.org  Thu Sep  3 04:03:39 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 2 Sep 2009 22:03:39 -0400
Subject: [coreboot] K8 machine with (a lot of) ram from 2 vendors
	keeps	resetting
In-Reply-To: <534e5dc20909021503n3e1366ffkce39c2f6e3b1256d@mail.gmail.com>
References: <20090902211457.GA14114@countzero.vandewege.net>
	<534e5dc20909021503n3e1366ffkce39c2f6e3b1256d@mail.gmail.com>
Message-ID: <20090903020339.GA28966@countzero.vandewege.net>

Hi Marc,

On Wed, Sep 02, 2009 at 04:03:45PM -0600, Marc Jones wrote:
> > With the proprietary BIOS, this setup works perfectly. That said, the manual
> > for the board does say it's not recommended to mix memory types. Our system
> > integrator mentions that when 16 banks are used, the memory runs at maximum
> > 533MHz.
> 
> As we talked about, it looks like the memory is sized correctly and
> the next thing to try forcing the memory speed slower. 8 dual rank
> dimms (16 banks) s[eed limitation might be spec'd or errata. A check
> might need to go into the main k8 mem init code.

I've forced the speed down to 533MHz with this patch:

--- src/northbridge/amd/amdk8/raminit_f.code(revision 4625)
+++ src/northbridge/amd/amdk8/raminit_f.code(working copy)
@@ -1811,6 +1811,10 @@
    }
    min_latency = 3;
 
+   // Force minimum cycle time to 3.75ns (i.e. 266MHz)
+   min_cycle_time = 0x375;
+
+   printk_raminit("1 bios_cycle_time: %08x\n", bios_cycle_time);
    printk_raminit("1 min_cycle_time: %08x\n", min_cycle_time);
 
    /* Compute the least latency with the fastest clock supported

Which appears to do the right thing, but the behavior is unchanged. Here's a
boot log prior to the patch:

  http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-before-533MHz-limit.cap

and here's after the patch:

  http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-after-533MHz-limit.cap

This is with all samsung ram on CPU1 and all kingston ram on CPU2, as you
suggested on irc.

Anything else I should try?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From kevin at koconnor.net  Thu Sep  3 05:30:27 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 2 Sep 2009 23:30:27 -0400
Subject: [coreboot] SeaBIOS WinXP install
In-Reply-To: <4A9E81B7.1040901@4dsp.com>
References: <4A9D1AFC.7080607@4dsp.com> <4A9D22E0.3070906@gmx.net>
	<4A9D80F6.1040906@assembler.cz> <4A9DA15D.2000704@gmx.net>
	<4A9E81B7.1040901@4dsp.com>
Message-ID: <20090903033027.GB12134@morn.localdomain>

On Wed, Sep 02, 2009 at 04:31:19PM +0200, Arnaud Maye wrote:
> Just before the system to hang, seabios displays :
> -------------------------------------------------
> fail handle_legacy_disk:845(1):
>   a=ffff0201  b=00000d00  c=00000001  d=47530081 ds=9000 es=9000 ss=9000
>  si=fff0fff0 di=0009fff0 bp=00001ff0 sp=00008ff8 cs=9020 ip=1015  f=0283
> fail handle_legacy_disk:845(1):
>   a=ffff415a  b=000055aa  c=0000fe03  d=47530081 ds=9000 es=9000 ss=9000
>  si=fff00d5a di=00090000 bp=00001ff0 sp=00008ffe cs=9020 ip=1043  f=0293

If you see these messages after Linux starts, then something very
strange is occurring.

If you're seeing these messages prior to the Linux start, then they
like normal -- the messages are just warnings resulting from a call
with invalid parameters (looks like grub is probing for a second hard
drive).

-Kevin



From c-d.hailfinger.devel.2006 at gmx.net  Thu Sep  3 07:26:27 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 03 Sep 2009 07:26:27 +0200
Subject: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps
 resetting
In-Reply-To: <20090902211457.GA14114@countzero.vandewege.net>
References: <20090902211457.GA14114@countzero.vandewege.net>
Message-ID: <4A9F5383.10201@gmx.net>

On 02.09.2009 23:14, Ward Vandewege wrote:
> I'm having some problems with a supermicro h8dme board with 2 K8 processors
> and 64 GB of ram.
>
> Sadly, the ram is of two types (that was not my decision :/). We have 8x 4GB
> Samsung M393T5160QZA-CE6 and 8x 4GB Kingston KVR667D2D4P5/4G. Both of these
> types of ram are dual rank DDR2, 667 MHz, CL5, 1.8 V, registered, ECC.
>   

The K8 memory code has some oddities which cause it to break down even
if the SPD parameters you use are identical. Not only must all SPD
timing parameters be identical, they also have to be stored at the same
byte addresses in each SPD. I sent a patch for this to the list sometime
last year, but it was never completely finished. I can try to dig it up
if you want to take a look.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From jaagar at gmail.com  Thu Sep  3 11:54:41 2009
From: jaagar at gmail.com (=?EUC-KR?B?wK/Fw7+s?=)
Date: Thu, 3 Sep 2009 18:54:41 +0900
Subject: [coreboot] How do I turn on display with RS690 ?
Message-ID: <efa814ff0909030254l6f1c5a55qde20229139b0cee0@mail.gmail.com>

I used coreboot with SeaBIOS and AMD's vBIOS.
System booted successfully except display not turned on.

I used DirectTMDS for primay display.
BIOS had been red my display's EDID rom.
I had seen this signals with an oscilloscope.

Error ocurred on executing VGA BIOS code.
How do I turn on display?

Here is log message.

-------------
.....
Start bios (version pre-0.4.2-20090903_180544-azalea)
init ivt
init bda
init pic
init timer
tsc calibrate start=2407971776 end=2410548093 diff=2576317
CPU Mhz=1500
math cp init
Find memory size
Attempting to find coreboot table
Found coreboot table forwarder.
Now attempting to find coreboot memory map
Found mainboard amd dbm690t
Found CBFS header at 0xfffdffe0
Ram Size=0x1c000000
Found 1 cpu(s)
malloc setup
init PMM
init PNPBIOS table
Scan for VGA option rom
Attempting to init PCI bdf 01:05.0 (dev/ven 791f1002)
Searching CBFS for prefix pci1002,791f.rom
Found CBFS file fallback/payload
Found CBFS file fallback/coreboot_ram
Found CBFS file vgaroms/radeon.rom
Found CBFS file img/filo
Found CBFS file
Attempting to map option rom on dev 01:05.0
Option rom sizing returned 0 0
Searching CBFS for prefix vgaroms/
Found CBFS file fallback/payload
Found CBFS file fallback/coreboot_ram
Found CBFS file vgaroms/radeon.rom
Copying data 55296 at 0xfff20678 to 196608 at 0x000c0000
Checking rom 0x000c0000 (sig aa55 size 108)
Running option rom at c000:0003
fail handle_15XX:294(86):
   a=00004e08  b=00000080  c=00000000  d=0000c000 ds=c000 es=f000 ss=0000
  si=0000abc8 di=0000b0b6 bp=00000000 sp=000079f2 cs=c000 ip=2cc2  f=0046
fail handle_15XX:294(86):
   a=07ff4e08  b=00000005  c=00004e17  d=0000c002 ds=c000 es=f000 ss=0000
  si=00002d58 di=0000b0b6 bp=000079d6 sp=000079f2 cs=c000 ip=2c5f  f=0046
fail handle_15XX:294(86):
   a=00004e08  b=00000000  c=0000a401  d=00000080 ds=c000 es=f000 ss=0000
  si=0000abc8 di=0000b0b6 bp=000079d6 sp=000079f0 cs=c000 ip=2c19  f=0046
Searching CBFS for prefix vgaroms/
Found CBFS file img/filo
Found CBFS file
Turning on vga console
Starting SeaBIOS (version pre-0.4.2-20090903_180544-azalea)

init keyboard
i8042 timeout on flush
init serial
Found 2 serial ports
Relocating coreboot bios tables
init SMBIOS tables
SMBIOS ptr=0x000fdce0 table=0x1bfff800
init boot device ordering
init hard drives
ATA controller 0 at 2020/2040 (dev 90 prog_if 8f)
ATA controller 1 at 2028/2044 (dev 90 prog_if 8f)
powerup iobase=2020 st=7f
powerup iobase=2020 st=7f
ata_detect ataid=0 sc=7f sn=7f dh=7f
powerup iobase=2020 st=7f
powerup iobase=2020 st=7f
ata_detect ataid=1 sc=7f sn=7f dh=7f
powerup iobase=2028 st=7f
powerup iobase=2028 st=7f
ata_detect ataid=2 sc=7f sn=7f dh=7f
powerup iobase=2028 st=7f
powerup iobase=2028 st=7f
ata_detect ataid=3 sc=7f sn=7f dh=7f
.....
-------------------

Jaagar



From stepan at coresystems.de  Thu Sep  3 22:22:02 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 03 Sep 2009 22:22:02 +0200
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
Message-ID: <4AA0256A.3000806@coresystems.de>

Sebastian Lara wrote:
> Hi,
>
> I'm trying to revive a Linux Netwox eVelocity 2 Cluster with
> LinuxBIOS-1.1.7.8 and Etherboot 5.2 on compute nodes. After some
> trouble, I have access to a shell after node system installation over
> network. My problem now is that I can't get localboot to work.
>   
What's the error?

> I need to know if I can re-burn the BIOS with a newer version of
> coreboot or something else, so I can use PXE and use GRUB for booting
> from local.
>   
What mainboard type is that? Can you post a boot log from serial console?


> Here is my lspci output. Thanks in advance for any help
>
> lspci -tv
> -+-[0000:01]-+-01.0-[0000:02]--+-03.0  Broadcom Corporation NetXtreme
> BCM5702X Gigabit Ethernet
>  |           |                 \-04.0  Broadcom Corporation NetXtreme
> BCM5702X Gigabit Ethernet
>  |           +-01.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
>  |           +-02.0-[0000:03-04]----01.0-[0000:04]----00.0  Mellanox
> Technologies MT23108 InfiniHost
>  |           +-02.1  Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
>  |           +-03.0-[0000:05]--+-00.0  Advanced Micro Devices [AMD] AMD-8111 USB
>  |           |                 +-00.1  Advanced Micro Devices [AMD] AMD-8111 USB
>  |           |                 \-06.0  ATI Technologies Inc Rage XL
>  |           +-04.0  Advanced Micro Devices [AMD] AMD-8111 LPC
>  |           +-04.1  Advanced Micro Devices [AMD] AMD-8111 IDE
>  |           +-04.2  Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
>  |           +-04.3  Advanced Micro Devices [AMD] AMD-8111 ACPI
>  |           \-04.6  Advanced Micro Devices [AMD] AMD-8111 MC97 Modem
>  \-[0000:00]-+-18.0  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] HyperTransport Technology Configuration
>              +-18.1  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Address Map
>              +-18.2  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] DRAM Controller
>              +-18.3  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Miscellaneous Control
>              +-19.0  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] HyperTransport Technology Configuration
>              +-19.1  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Address Map
>              +-19.2  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] DRAM Controller
>              \-19.3  Advanced Micro Devices [AMD] K8
> [Athlon64/Opteron] Miscellaneous Control
>
>
> sh-3.2#  lspci -tvnn
> -+-[0000:01]-+-01.0-[0000:02]--+-03.0  14e4:16a6
>  |           |                 \-04.0  14e4:16a6
>  |           +-01.1  1022:7451
>  |           +-02.0-[0000:03-04]----01.0-[0000:04]----00.0  15b3:5a44
>  |           +-02.1  1022:7451
>  |           +-03.0-[0000:05]--+-00.0  1022:7464
>  |           |                 +-00.1  1022:7464
>  |           |                 \-06.0  1002:4752
>  |           +-04.0  1022:7468
>  |           +-04.1  1022:7469
>  |           +-04.2  1022:746a
>  |           +-04.3  1022:746b
>  |           \-04.6  1022:746e
>  \-[0000:00]-+-18.0  1022:1100
>              +-18.1  1022:1101
>              +-18.2  1022:1102
>              +-18.3  1022:1103
>              +-19.0  1022:1100
>              +-19.1  1022:1101
>              +-19.2  1022:1102
>              \-19.3  1022:1103
>
>
>
>
>
>   




From marcj303 at gmail.com  Thu Sep  3 23:06:03 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 3 Sep 2009 15:06:03 -0600
Subject: [coreboot] K8 machine with (a lot of) ram from 2 vendors keeps
	resetting
In-Reply-To: <20090903020339.GA28966@countzero.vandewege.net>
References: <20090902211457.GA14114@countzero.vandewege.net>
	<534e5dc20909021503n3e1366ffkce39c2f6e3b1256d@mail.gmail.com>
	<20090903020339.GA28966@countzero.vandewege.net>
Message-ID: <534e5dc20909031406s27ec1a46h508591a13afb20fb@mail.gmail.com>

Hi Ward,

On Wed, Sep 2, 2009 at 8:03 PM, Ward Vandewege<ward at gnu.org> wrote:
> Hi Marc,
>
> On Wed, Sep 02, 2009 at 04:03:45PM -0600, Marc Jones wrote:
>> > With the proprietary BIOS, this setup works perfectly. That said, the manual
>> > for the board does say it's not recommended to mix memory types. Our system
>> > integrator mentions that when 16 banks are used, the memory runs at maximum
>> > 533MHz.
>>
>> As we talked about, it looks like the memory is sized correctly and
>> the next thing to try forcing the memory speed slower. 8 dual rank
>> dimms (16 banks) s[eed limitation might be spec'd or errata. A check
>> might need to go into the main k8 mem init code.
>
> I've forced the speed down to 533MHz with this patch:
>
> --- src/northbridge/amd/amdk8/raminit_f.code(revision 4625)
> +++ src/northbridge/amd/amdk8/raminit_f.code(working copy)
> @@ -1811,6 +1811,10 @@
> ? ?}
> ? ?min_latency = 3;
>
> + ? // Force minimum cycle time to 3.75ns (i.e. 266MHz)
> + ? min_cycle_time = 0x375;
> +
> + ? printk_raminit("1 bios_cycle_time: %08x\n", bios_cycle_time);
> ? ?printk_raminit("1 min_cycle_time: %08x\n", min_cycle_time);
>
> ? ?/* Compute the least latency with the fastest clock supported
>
> Which appears to do the right thing, but the behavior is unchanged. Here's a
> boot log prior to the patch:
>
> ?http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-before-533MHz-limit.cap
>
> and here's after the patch:
>
> ?http://ward.vandewege.net/coreboot/h8dme/minicom-20090902-with-64G-samsung-on-cpu1-kingston-on-cpu2-after-533MHz-limit.cap
>
> This is with all samsung ram on CPU1 and all kingston ram on CPU2, as you
> suggested on irc.
>

I don't think that this is a RAM matching problem. Each CPU/MC is
completely has completely matched RAM in this setup. The memory is
being sized correctly and I had hoped that slowing down would help.
The next step is to do a memory test or instrument the memory clear to
see how it fails. If it is on a boundary it would indicate an
addressing problem. Something more random would indicate timing. But
it is a little bit of guess work from here. Comparing the MC PCI
registers (function1 and 2) against the legacy bios might reveal
something as well.

The actual reset is probably a triple fault which probably started
with a op-code exception. We can instrument the exception handler if
you get really stuck.

Marc


-- 
http://marcjonesconsulting.com



From slara at udec.cl  Fri Sep  4 00:53:28 2009
From: slara at udec.cl (Sebastian Lara)
Date: Thu, 3 Sep 2009 18:53:28 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <4AA0256A.3000806@coresystems.de>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
Message-ID: <b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>

Hi,

2009/9/3 Stefan Reinauer <stepan at coresystems.de>:
> Sebastian Lara wrote:
>> Hi,
>>
>> I'm trying to revive a Linux Netwox eVelocity 2 Cluster with
>> LinuxBIOS-1.1.7.8 and Etherboot 5.2 on compute nodes. After some
>> trouble, I have access to a shell after node system installation over
>> network. My problem now is that I can't get localboot to work.
>>
> What's the error?

Boot from (N)etwork (D)isk or (Q)uit? D

Probing pci disk...
[IDE]LBA48 mode
disk-1 78150744k cap: 2f00
Searching for image...
................................<abort>
Probing pci disk...
[IDE]
Probing isa disk...
<sleep>


Etherboot searches for an ELF header in the first 8K. I don't really
know how can I do this. I had tried to use a ELF image of the kernel
installed in the node but it doesn't work.



>
>> I need to know if I can re-burn the BIOS with a newer version of
>> coreboot or something else, so I can use PXE and use GRUB for booting
>> from local.
>>
> What mainboard type is that? Can you post a boot log from serial console?

It's there some way to know the mainboard type without open a node
case? Get permission to do that may take some time.

Here is the boot log:

LinuxBIOS-1.1.7.8Normal Fri Jan ?7 13:55:58 MST 2005 starting...
setting up resource map....done.
02 nodes initialized.
ht reset -


LinuxBIOS-1.1.7.8Normal Fri Jan ?7 13:55:58 MST 2005 starting...
setting up resource map....done.
02 nodes initialized.
Ram1.00
Ram1.01
Ram2.00
Ram2.01
Ram3
Initializing memory: ?done
Initializing memory: ?done
Clearing initial memory region: ?done
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-1.1.7.8Normal Fri Jan ?7 13:55:58 MST 2005 booting...
Enumerating buses...
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 0
PCI: 00:18.0 [1022/1100] bus ops
PCI: 00:18.0 [1022/1100] enabled
PCI: 00:18.1 [1022/1101] enabled
PCI: 00:18.2 [1022/1102] enabled
PCI: 00:18.3 [1022/1103] ops
PCI: 00:18.3 [1022/1103] enabled
PCI: 00:19.0 [1022/1100] bus ops
PCI: 00:19.0 [1022/1100] enabled
PCI: 00:19.1 [1022/1101] enabled
PCI: 00:19.2 [1022/1102] enabled
PCI: 00:19.3 [1022/1103] ops
PCI: 00:19.3 [1022/1103] enabled
PCI: 01:01.0 [1022/7450] enabled next_unitid: 0003
PCI: 01:03.0 [1022/7460] enabled next_unitid: 0007
HyperT reset not needed
PCI: pci_scan_bus for bus 1
PCI: 01:01.0 [1022/7450] bus ops
PCI: 01:01.0 [1022/7450] enabled
PCI: 01:01.1 [1022/7451] ops
PCI: 01:01.1 [1022/7451] enabled
PCI: 01:02.0 [1022/7450] bus ops
PCI: 01:02.0 [1022/7450] enabled
PCI: 01:02.1 [1022/7451] ops
PCI: 01:02.1 [1022/7451] enabled
PCI: 01:03.0 [1022/7460] bus ops
PCI: 01:03.0 [1022/7460] enabled
PCI: 01:04.0 [1022/7468] bus ops
PCI: 01:04.0 [1022/7468] enabled
PCI: 01:04.1 [1022/7469] ops
PCI: 01:04.1 [1022/7469] enabled
PCI: 01:04.2 [1022/746a] bus ops
PCI: 01:04.2 [1022/746a] enabled
PCI: 01:04.3 [1022/746b] bus ops
PCI: 01:04.3 [1022/746b] enabled
PCI: 01:04.5 No device operations
PCI: 01:04.6 [1022/746e] ops
PCI: 01:04.6 [1022/746e] enabled
PCI: pci_scan_bus for bus 2
PCI: 02:03.0 [14e4/16a6] enabled
PCI: 02:04.0 [14e4/16a6] enabled
PCI: pci_scan_bus returning with max=02
PCI: pci_scan_bus for bus 3
PCI: 03:01.0 [15b3/5a46] enabled
PCI: pci_scan_bus for bus 4
PCI: 04:00.0 [15b3/5a44] enabled
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus returning with max=04
PCI: pci_scan_bus for bus 5
PCI: 05:00.0 [1022/7464] bus ops
PCI: 05:00.0 [1022/7464] enabled
PCI: 05:00.1 [1022/7464] bus ops
PCI: 05:00.1 [1022/7464] enabled
PCI: 05:00.2 No device operations
PCI: 05:01.0 No device operations
PCI: 05:06.0 [1002/4752] enabled
PCI: pci_scan_bus returning with max=05
PNP: 002e.0 disabled
PNP: 002e.1 disabled
PNP: 002e.2 disabled
PNP: 002e.3 enabled
PNP: 002e.4 disabled
PNP: 002e.5 disabled
PNP: 002e.6 enabled
PNP: 002e.7 disabled
PNP: 002e.8 disabled
PNP: 002e.9 disabled
PNP: 002e.a disabled
I2C: 70 enabled
I2C: 50 enabled
I2C: 51 enabled
I2C: 52 enabled
I2C: 53 enabled
I2C: 54 enabled
I2C: 55 enabled
I2C: 56 enabled
I2C: 57 enabled
PCI: pci_scan_bus returning with max=05
PCI: pci_scan_bus returning with max=05
CPU: APIC: 00 enabled
CPU: APIC: 01 enabled
done
Allocating resources...
PCI: 01:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 2 io
PCI: 01:01.0 24 <- [0xfffffffffff00000 - 0xffffffffffefffff] bus 2 prefmem
PCI: 03:01.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 4 io
PCI: 01:02.0 1c <- [0x00fffff000 - 0x00ffffefff] bus 3 io
PCI: 01:03.0 24 <- [0x00fff00000 - 0x00ffefffff] bus 5 prefmem
Allocating VGA resource PCI: 05:06.0
PCI: 00:18.0 1b8 <- [0x00e8000000 - 0x00f07fffff] prefmem <node 0 link 0>
PCI: 00:18.0 1c0 <- [0x0000001000 - 0x0000002fff] io <node 0 link 0>
PCI: 00:18.0 1b0 <- [0x00f8000000 - 0x00f93fffff] mem <node 0 link 0>
PCI: 01:01.0 20 <- [0x00f9100000 - 0x00f91fffff] bus 2 mem
PCI: 02:03.0 10 <- [0x00f9100000 - 0x00f910ffff] mem
PCI: 02:04.0 10 <- [0x00f9110000 - 0x00f911ffff] mem
PCI: 01:01.1 10 <- [0x00f9300000 - 0x00f9300fff] mem
PCI: 01:02.0 24 <- [0x00e8000000 - 0x00f07fffff] bus 3 prefmem
PCI: 01:02.0 20 <- [0x00f9200000 - 0x00f92fffff] bus 3 mem
PCI: 03:01.0 24 <- [0x00e8000000 - 0x00f07fffff] bus 4 prefmem
PCI: 03:01.0 20 <- [0x00f9200000 - 0x00f92fffff] bus 4 mem
PCI: 04:00.0 10 <- [0x00f9200000 - 0x00f92fffff] mem
PCI: 04:00.0 18 <- [0x00f0000000 - 0x00f07fffff] prefmem
PCI: 04:00.0 20 <- [0x00e8000000 - 0x00efffffff] prefmem
PCI: 01:02.1 10 <- [0x00f9301000 - 0x00f9301fff] mem
PCI: 01:03.0 1c <- [0x0000001000 - 0x0000001fff] bus 5 io
PCI: 01:03.0 20 <- [0x00f8000000 - 0x00f90fffff] bus 5 mem
PCI: 05:00.0 10 <- [0x00f9000000 - 0x00f9000fff] mem
PCI: 05:00.1 10 <- [0x00f9001000 - 0x00f9001fff] mem
PCI: 05:06.0 10 <- [0x00f8000000 - 0x00f8ffffff] mem
PCI: 05:06.0 14 <- [0x0000001000 - 0x00000010ff] io
PCI: 05:06.0 18 <- [0x00f9002000 - 0x00f9002fff] mem
PNP: 002e.3 60 <- [0x00000003f8 - 0x00000003ff] io
PNP: 002e.3 70 <- [0x0000000004 - 0x0000000004] irq
PNP: 002e.6 60 <- [0x0000000060 - 0x0000000067] io
PNP: 002e.6 62 <- [0x0000000064 - 0x000000006b] io
PNP: 002e.6 70 <- [0x0000000001 - 0x0000000001] irq
PCI: 01:04.1 20 <- [0x00000028a0 - 0x00000028af] io
PCI: 01:04.2 10 <- [0x0000002880 - 0x000000289f] io
PCI: 01:04.3 58 <- [0x0000002000 - 0x00000020ff] io
PCI: 01:04.6 10 <- [0x0000002400 - 0x00000024ff] io
PCI: 01:04.6 14 <- [0x0000002800 - 0x000000287f] io
PCI: 00:18.3 94 <- [0x00f4000000 - 0x00f7ffffff] mem <gart>
PCI: 00:19.3 94 <- [0x00f4000000 - 0x00f7ffffff] mem <gart>
done.
Enabling resourcess...
PCI: 00:18.0 cmd <- 140
PCI: 01:01.0 bridge ctrl <- 0003
PCI: 01:01.0 cmd <- 146
PCI: 02:03.0 cmd <- 142
PCI: 02:04.0 cmd <- 142
PCI: 01:01.1 subsystem <- 161f/3016
PCI: 01:01.1 cmd <- 146
PCI: 01:02.0 bridge ctrl <- 0003
PCI: 01:02.0 cmd <- 146
PCI: 03:01.0 bridge ctrl <- 0003
PCI: 03:01.0 cmd <- 146
PCI: 04:00.0 cmd <- 142
PCI: 01:02.1 subsystem <- 161f/3016
PCI: 01:02.1 cmd <- 146
PCI: 01:03.0 bridge ctrl <- 000b
PCI: 01:03.0 cmd <- 147
PCI: 05:00.0 subsystem <- 161f/3016
PCI: 05:00.0 cmd <- 142
PCI: 05:00.1 subsystem <- 161f/3016
PCI: 05:00.1 cmd <- 142
PCI: 05:06.0 cmd <- 1c3
PCI: 01:04.0 subsystem <- 161f/3016
PCI: 01:04.0 cmd <- 14f
PCI: 01:04.1 subsystem <- 161f/3016
PCI: 01:04.1 cmd <- 141
PCI: 01:04.2 subsystem <- 161f/3016
PCI: 01:04.2 cmd <- 141
PCI: 01:04.3 subsystem <- 161f/3016
PCI: 01:04.3 cmd <- 141
PCI: 01:04.6 subsystem <- 161f/3016
PCI: 01:04.6 cmd <- 141
PCI: 00:18.1 subsystem <- 161f/3016
PCI: 00:18.1 cmd <- 140
PCI: 00:18.2 subsystem <- 161f/3016
PCI: 00:18.2 cmd <- 140
PCI: 00:18.3 cmd <- 140
PCI: 00:19.0 cmd <- 140
PCI: 00:19.1 subsystem <- 161f/3016
PCI: 00:19.1 cmd <- 140
PCI: 00:19.2 subsystem <- 161f/3016
PCI: 00:19.2 cmd <- 140
PCI: 00:19.3 cmd <- 140
done.
Initializing devices...
Root Device init
PCI: 00:18.0 init
PCI: 01:01.0 init
PCI: 01:02.0 init
PCI: 01:03.0 init
PCI: 01:04.0 init
RTC Init
enabling HPET @0xfed00000
PNP: 002e.3 init
PNP: 002e.6 init
PCI: 01:04.1 init
IDE1 IDE0 PCI: 01:04.3 init
set power on after power fail
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:19.0 init
PCI: 00:19.3 init
NB: Function 3 Misc Control.. done.
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device f5a
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base: ? ?0MB, range: 2048MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs ? : Enabled
Variable MTRRs: Enabled

Clearing memory 0K - 1048576K: --------------- done
Setting up local apic... apic_id: 0 done.
CPU #0 Initialized
Initializing CPU #1
Waiting for 1 CPUS to stop
CPU: vendor AMD device f5a
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB
Setting fixed MTRRs(24-88) Type: WB
DONE fixed MTRRs
Setting variable MTRR 0, base: ? ?0MB, range: 2048MB, type WB
DONE variable MTRRs
Clear out the extra MTRR's

MTRR check
Fixed MTRRs ? : Enabled
Variable MTRRs: Enabled

Clearing memory 1048576K - 2097152K: ---------------- done
Setting up local apic... apic_id: 1 done.
CPU #1 Initialized
All AP CPUs stopped
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
/home/cwxbuild/modules/linuxbios/hdama/freebios2/src/arch/i386/boot/pirq_routing.c:
? 28:check_pirq_routing_table() - irq_routing_table located at:
0x000f0000
done.
Wrote the mp table end at: 00000020 - 00000224
Wrote linuxbios table at: 00000500 - 00000d88 ?checksum 9e78

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

Found ELF candiate at offset 0
Loading Etherboot version: 5.2.4js1
Dropping non PT_LOAD segment
New segment addr 0x20000 size 0x41e65 offset 0xc0 filesize 0x993a
(cleaned up) New segment addr 0x20000 size 0x41e65 offset 0xc0 filesize 0x993a
Loading Segment: addr: 0x000000007ffc4000 memsz: 0x0000000000010000
filesz: 0x000000000000993a
Clearing Segment: addr: 0x000000007ffcd93a memsz: 0x00000000000066c6
Loading Segment: addr: 0x0000000000030000 memsz: 0x0000000000031e65
filesz: 0x0000000000000000
Clearing Segment: addr: 0x0000000000030000 memsz: 0x0000000000031e65
Jumping to boot code at 0x20000
ROM segment 0x0000 length 0x0000 reloc 0x00020000
CPU 2486 Mhz
Etherboot 5.2.4js1 (GPL) http://etherboot.org ELF64 ELF with TFTP SLAM
LACP for [EEPRO100][E1000][3C90X][TG3][IDE]
Relocating _text from: [00029930,00063080) to [7fec68b0,7ff00000)
?Probing pci nic... (D)isk or (Q)uit?
[tg3-5702X]Ethernet addr: 00:50:45:5C:34:1A
Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit)
Link is up at 100 Mbps, full duplex.
Searching for server (DHCP)...
...Me: 10.1.255.254, Server: 10.1.1.1, Gateway 10.1.1.1
Loading 10.1.1.1:vmlinuz.vo ...(ELF)... ................


Thanks for the help.
-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From nathan at traverse.com.au  Fri Sep  4 06:57:42 2009
From: nathan at traverse.com.au (Nathan Williams)
Date: Fri, 04 Sep 2009 14:57:42 +1000
Subject: [coreboot] [PATCH] buildrom: Force creation of symlink
Message-ID: <E1MjQrm-0004Jd-1S@fileserver.traverse>

Building grub2 was failing if the symlink already exists.

Signed-off-by: Nathan Williams <nathan at traverse.com.au>

Index: buildrom-devel/packages/grub2/grub2.mk
===================================================================
--- buildrom-devel/packages/grub2/grub2.mk	(revision 271)
+++ buildrom-devel/packages/grub2/grub2.mk	(working copy)
@@ -48,7 +48,7 @@
 	@ echo "Using custom config $(GRUB2_CONFIG)"
 endif
 	@ echo "Building grub2..."
-	@ ln -s $(GRUB2_SRC_DIR)/config.log $(GRUB2_LOG_DIR)
+	@ ln -sf $(GRUB2_SRC_DIR)/config.log $(GRUB2_LOG_DIR)
 	@ (cd $(GRUB2_SRC_DIR) ; sh ./autogen.sh >> $(GRUB2_BUILD_LOG) 2>&1)
 	@ (cd $(GRUB2_SRC_DIR) ; export LIBS= CC= LDFLAGS= CFLAGS=; ./configure --with-platform=coreboot --prefix=$(STAGING_DIR) >> $(GRUB2_BUILD_LOG) 2>&1)
 	@ make -C $(GRUB2_SRC_DIR) >> $(GRUB2_BUILD_LOG) 2>&1



From uwe at hermann-uwe.de  Fri Sep  4 13:19:41 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 4 Sep 2009 13:19:41 +0200
Subject: [coreboot] [PATCH] Use driver-y instead of obj-y for
	model_6xx_init.o
Message-ID: <20090904111940.GS7448@greenwood>

See patch.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_kconfig_cpufix.patch
Type: text/x-diff
Size: 697 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090904/66a05bb3/attachment.bin>

From svn at coreboot.org  Fri Sep  4 15:06:59 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  4 Sep 2009 15:06:59 +0200
Subject: [coreboot] [BuildROM] r272 - buildrom-devel/packages/grub2
Message-ID: <mailman.3689.1355071617.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-04 15:06:59 +0200 (Fri, 04 Sep 2009)
New Revision: 272

Modified:
   buildrom-devel/packages/grub2/grub2.mk
Log:
Force symlink creation so grub2 builds when the symlink already exists.

Signed-off-by: Nathan Williams <nathan at traverse.com.au>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: buildrom-devel/packages/grub2/grub2.mk
===================================================================
--- buildrom-devel/packages/grub2/grub2.mk	2009-09-02 21:41:13 UTC (rev 271)
+++ buildrom-devel/packages/grub2/grub2.mk	2009-09-04 13:06:59 UTC (rev 272)
@@ -48,7 +48,7 @@
 	@ echo "Using custom config $(GRUB2_CONFIG)"
 endif
 	@ echo "Building grub2..."
-	@ ln -s $(GRUB2_SRC_DIR)/config.log $(GRUB2_LOG_DIR)
+	@ ln -sf $(GRUB2_SRC_DIR)/config.log $(GRUB2_LOG_DIR)
 	@ (cd $(GRUB2_SRC_DIR) ; sh ./autogen.sh >> $(GRUB2_BUILD_LOG) 2>&1)
 	@ (cd $(GRUB2_SRC_DIR) ; export LIBS= CC= LDFLAGS= CFLAGS=; ./configure --with-platform=coreboot --prefix=$(STAGING_DIR) >> $(GRUB2_BUILD_LOG) 2>&1)
 	@ make -C $(GRUB2_SRC_DIR) >> $(GRUB2_BUILD_LOG) 2>&1




From mylesgw at gmail.com  Fri Sep  4 15:07:36 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Sep 2009 07:07:36 -0600
Subject: [coreboot] [PATCH] buildrom: Force creation of symlink
In-Reply-To: <E1MjQrm-0004Jd-1S@fileserver.traverse>
References: <E1MjQrm-0004Jd-1S@fileserver.traverse>
Message-ID: <2831fecf0909040607o2c743270w7fd801a7ea8c4330@mail.gmail.com>

On Thu, Sep 3, 2009 at 10:57 PM, Nathan Williams<nathan at traverse.com.au> wrote:
> Building grub2 was failing if the symlink already exists.
>
> Signed-off-by: Nathan Williams <nathan at traverse.com.au>
Acked-by: Myles Watson <mylesgw at gmail.com>

Rev 272.

Thanks,
Myles



From mylesgw at gmail.com  Fri Sep  4 15:03:06 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Sep 2009 07:03:06 -0600
Subject: [coreboot] [PATCH] Use driver-y instead of obj-y
	formodel_6xx_init.o
In-Reply-To: <20090904111940.GS7448@greenwood>
References: <20090904111940.GS7448@greenwood>
Message-ID: <B75093D3B2AD4B199C4967B3A1B6BD20@chimp>

> Subject: [coreboot] [PATCH] Use driver-y instead of obj-y
> formodel_6xx_init.o
Good find.  Have you looked at the other CPUs to see if they need this?  Is
it documented?

Acked-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles




From stepan at coresystems.de  Fri Sep  4 16:01:47 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 04 Sep 2009 16:01:47 +0200
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
Message-ID: <4AA11DCB.6040503@coresystems.de>

Sebastian Lara wrote:
> Hi,
>
> 2009/9/3 Stefan Reinauer <stepan at coresystems.de>:
>   
>> Sebastian Lara wrote:
>>     
>>> Hi,
>>>
>>> I'm trying to revive a Linux Netwox eVelocity 2 Cluster with
>>> LinuxBIOS-1.1.7.8 and Etherboot 5.2 on compute nodes. After some
>>> trouble, I have access to a shell after node system installation over
>>> network. My problem now is that I can't get localboot to work.
>>>
>>>       
>> What's the error?
>>     
>
> Boot from (N)etwork (D)isk or (Q)uit? D
>
> Probing pci disk...
> [IDE]LBA48 mode
> disk-1 78150744k cap: 2f00
> Searching for image...
> ................................<abort>
> Probing pci disk...
> [IDE]
> Probing isa disk...
> <sleep>
>
>
> Etherboot searches for an ELF header in the first 8K. I don't really
> know how can I do this. I had tried to use a ELF image of the kernel
> installed in the node but it doesn't work.
>   

I think you need to run "mkelfimage" on a Linux kernel in order to get
it booted and dump that directly on the first partition




>   
>>> I need to know if I can re-burn the BIOS with a newer version of
>>> coreboot or something else, so I can use PXE and use GRUB for booting
>>> from local.
>>>
>>>       
>> What mainboard type is that? Can you post a boot log from serial console?
>>     
>
> It's there some way to know the mainboard type without open a node
> case? Get permission to do that may take some time.
>
>   
if you can run "nvramtool" from a current coreboot tree on that node, it
can dump the fields


> Here is the boot log:
>   

> Found ELF candiate at offset 0
> Loading Etherboot version: 5.2.4js1
> Dropping non PT_LOAD segment
> New segment addr 0x20000 size 0x41e65 offset 0xc0 filesize 0x993a
> (cleaned up) New segment addr 0x20000 size 0x41e65 offset 0xc0 filesize 0x993a
> Loading Segment: addr: 0x000000007ffc4000 memsz: 0x0000000000010000
> filesz: 0x000000000000993a
> Clearing Segment: addr: 0x000000007ffcd93a memsz: 0x00000000000066c6
> Loading Segment: addr: 0x0000000000030000 memsz: 0x0000000000031e65
> filesz: 0x0000000000000000
> Clearing Segment: addr: 0x0000000000030000 memsz: 0x0000000000031e65
> Jumping to boot code at 0x20000
> ROM segment 0x0000 length 0x0000 reloc 0x00020000
> CPU 2486 Mhz
> Etherboot 5.2.4js1 (GPL) http://etherboot.org ELF64 ELF with TFTP SLAM
> LACP for [EEPRO100][E1000][3C90X][TG3][IDE]
> Relocating _text from: [00029930,00063080) to [7fec68b0,7ff00000)
> ?Probing pci nic... (D)isk or (Q)uit?
> [tg3-5702X]Ethernet addr: 00:50:45:5C:34:1A
> Tigon3 [partno(BCM95702A20) rev 1002 PHY(5703)] (PCI:66MHz:32-bit)
> Link is up at 100 Mbps, full duplex.
> Searching for server (DHCP)...
> ...Me: 10.1.255.254, Server: 10.1.1.1, Gateway 10.1.1.1
> Loading 10.1.1.1:vmlinuz.vo ...(ELF)... ................
>   

Does booting over the network work?





From slara at udec.cl  Fri Sep  4 16:47:59 2009
From: slara at udec.cl (Sebastian Lara)
Date: Fri, 4 Sep 2009 10:47:59 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <4AA11DCB.6040503@coresystems.de>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
Message-ID: <b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>

2009/9/4 Stefan Reinauer <stepan at coresystems.de>:
> Sebastian Lara wrote:
>> Hi,
>>[...]
>[...]
>
>I think you need to run "mkelfimage" on a Linux kernel in order to get
>it booted and dump that directly on the first partition

How should I dump that image? should I use dd or just put /boot as the
first partition of the disc?

> Does booting over the network work?
>
Network booting works fine. I can install the node without any problem.


-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From rminnich at gmail.com  Fri Sep  4 18:29:07 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 09:29:07 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <op.uzljz7kn1ay1or@x53k>
References: <op.uzljz7kn1ay1or@x53k>
Message-ID: <13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>

On Tue, Sep 1, 2009 at 2:15 PM, Ralf Grosse Boerger<ralfgb at gmail.com> wrote:
> Hi,
>
> this a reply to the following message:
> http://www.coreboot.org/pipermail/coreboot/2009-August/051629.html
> [I am not subscribed to this list.]
>
> The sporadic boot problems ("FIXME! CPU Version unknown or not supported!")
> are caused by a race condition in Get_NB32().
>
> This function performs a read operation to the PCI configuration space via
> port CF8/CFC.
>
> u32 Get_NB32(u32 dev, u32 reg)
> {
> ? ? ? ?u32 addr;
>
> ? ? ? ?addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16);
> ? ? ? ?outl((1<<31) | (addr & ~3), 0xcf8);
>
> ? ? ? ?return inl(0xcfc);
> }
>
> As ports CF8/CFC are shared across cores (maybe even sockets?) concurrent
> accesses from different cores may yield random results.

I would be surprised were they shared across sockets but ...
I'm realizing I have no clue how config cycles work on Opteron. I just
assumed this cf8/cfc cycle was magically converted inside the cpu into
an HT cycle of some sort, and that cycle was routed via the config
space maps in the NB. But ... can someone inform me on how this really
works? Is my picture even close?

Is there some better way on fam10 to do config cycles that is more
multi-core friendly? It seems odd that we are still locked into this
cf8/cfc stuff.

ron



From svn at coreboot.org  Fri Sep  4 18:30:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  4 Sep 2009 18:30:31 +0200
Subject: [coreboot] [v2] r4626 - trunk/coreboot-v2/src/cpu/intel/model_6xx
Message-ID: <mailman.3690.1355071617.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-09-04 18:30:31 +0200 (Fri, 04 Sep 2009)
New Revision: 4626

Modified:
   trunk/coreboot-v2/src/cpu/intel/model_6xx/Makefile.inc
Log:
Use driver-y instead of obj-y for model_6xx_init.o.

Otherwise booting (but not building) fails:

  Initializing CPU #0
  CPU: vendor Intel device 665
  CPU: family 06, model 06, stepping 05
  Unknown cpu

This patch was tested to fix the issue on MSI MS-6178.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: trunk/coreboot-v2/src/cpu/intel/model_6xx/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/cpu/intel/model_6xx/Makefile.inc	2009-09-01 15:29:12 UTC (rev 4625)
+++ trunk/coreboot-v2/src/cpu/intel/model_6xx/Makefile.inc	2009-09-04 16:30:31 UTC (rev 4626)
@@ -18,5 +18,5 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
-obj-y += model_6xx_init.o
+driver-y += model_6xx_init.o
 




From uwe at hermann-uwe.de  Fri Sep  4 18:32:57 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Fri, 4 Sep 2009 18:32:57 +0200
Subject: [coreboot] [PATCH] Use driver-y instead of obj-y
 formodel_6xx_init.o
In-Reply-To: <B75093D3B2AD4B199C4967B3A1B6BD20@chimp>
References: <20090904111940.GS7448@greenwood>
	<B75093D3B2AD4B199C4967B3A1B6BD20@chimp>
Message-ID: <20090904163257.GC24546@greenwood>

On Fri, Sep 04, 2009 at 07:03:06AM -0600, Myles Watson wrote:
> > Subject: [coreboot] [PATCH] Use driver-y instead of obj-y
> > formodel_6xx_init.o
> Good find.  Have you looked at the other CPUs to see if they need this?  Is
> it documented?

Not sure. All other model_*.o files are driver-y already, _but_ there
are other *.o files in src/cpu/ that are obj-y (not driver-y), dunno
if that is intentional.


> Acked-by: Myles Watson <mylesgw at gmail.com>

Thanks, r4626.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From rminnich at gmail.com  Fri Sep  4 18:39:27 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 09:39:27 -0700
Subject: [coreboot] [PATCH] Use driver-y instead of obj-y
	formodel_6xx_init.o
In-Reply-To: <20090904163257.GC24546@greenwood>
References: <20090904111940.GS7448@greenwood>
	<B75093D3B2AD4B199C4967B3A1B6BD20@chimp>
	<20090904163257.GC24546@greenwood>
Message-ID: <13426df10909040939n1f73cb9ctac6d822fee5f8a4e@mail.gmail.com>

In the case of files I converted, the use of driver or obj *should*
have just followed the Config.lb.

This sort of thing is best done with scripts ...

ron



From rminnich at gmail.com  Fri Sep  4 18:42:02 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 09:42:02 -0700
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
Message-ID: <13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>

quick meta-question: why do you want to boot from local? Reason I ask
is that the newest compute clusters are
moving away from local disks for  many reasons.

Using a local disk from storage is fine, people still do that, but
booting from local can make life harder when errors crop up.

ron



From mylesgw at gmail.com  Fri Sep  4 18:57:02 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Sep 2009 10:57:02 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
Message-ID: <1EF2A528D4C54ACE940C759DE50892FC@chimp>


> > As ports CF8/CFC are shared across cores (maybe even sockets?)
> concurrent
> > accesses from different cores may yield random results.
> 
> I would be surprised were they shared across sockets but ...
> I'm realizing I have no clue how config cycles work on Opteron. I just
> assumed this cf8/cfc cycle was magically converted inside the cpu into
> an HT cycle of some sort, and that cycle was routed via the config
> space maps in the NB. But ... can someone inform me on how this really
> works? Is my picture even close?

I don't know how the conversion works exactly, or where it takes place, but
the HT packet is a read or a write to 0xFD.FE00.0000 + an offset for the
UnitID(pci device number).  So, for device 7 on the bus and config register
0x14, you get 0xFDFE003814.  You don't have to worry about bus numbers
because they get taken care of based on the HT chain the to which the packet
is routed.

Based on that, I would say it's not shared across sockets, but it definitely
could be shared across cores.

> Is there some better way on fam10 to do config cycles that is more
> multi-core friendly? It seems odd that we are still locked into this
> cf8/cfc stuff.
Isn't there a way to do MMCONF cycles from the NB?

Myles




From rminnich at gmail.com  Fri Sep  4 19:06:21 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 10:06:21 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <1EF2A528D4C54ACE940C759DE50892FC@chimp>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
Message-ID: <13426df10909041006r637fd61bg3b18a9fe26ad88bb@mail.gmail.com>

On Fri, Sep 4, 2009 at 9:57 AM, Myles Watson<mylesgw at gmail.com> wrote:
>
>> > As ports CF8/CFC are shared across cores (maybe even sockets?)
>> concurrent
>> > accesses from different cores may yield random results.
>>
>> I would be surprised were they shared across sockets but ...
>> I'm realizing I have no clue how config cycles work on Opteron. I just
>> assumed this cf8/cfc cycle was magically converted inside the cpu into
>> an HT cycle of some sort, and that cycle was routed via the config
>> space maps in the NB. But ... can someone inform me on how this really
>> works? Is my picture even close?
>
> I don't know how the conversion works exactly, or where it takes place, but
> the HT packet is a read or a write to 0xFD.FE00.0000 + an offset for the
> UnitID(pci device number). ?So, for device 7 on the bus and config register
> 0x14, you get 0xFDFE003814. ?You don't have to worry about bus numbers
> because they get taken care of based on the HT chain the to which the packet
> is routed.

This is a memory read/write?

>
> Based on that, I would say it's not shared across sockets, but it definitely
> could be shared across cores.

> Isn't there a way to do MMCONF cycles from the NB?

Marc? If there were, it would make sense to convert the code to use
these, instead of trying to make cf8/cfc SMP-safe.

ron



From r.marek at assembler.cz  Fri Sep  4 19:07:54 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 04 Sep 2009 19:07:54 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <1EF2A528D4C54ACE940C759DE50892FC@chimp>
References: <op.uzljz7kn1ay1or@x53k>	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
Message-ID: <4AA1496A.5030206@assembler.cz>

> Isn't there a way to do MMCONF cycles from the NB?

No, I think only newer fam10h cpus can do that.

http://lkml.org/lkml/2007/12/21/134

So, the K8 internal devices are not accessible with the mmconf aperture which is 
NB dependent anyway. That post says that it may work for newer fam10h cpus. I 
think this is related: F1x[EC:E0] Configuration Map Registers and
DisCohLdtCfg: disable coherent link configuration accesses.


I think linux has some test which test what devices can be accessed through 
type1 and what it sees on mmconf.

http://www.x86-64.org/pipermail/discuss/2005-December/007371.html

I think the only proper way is to do type1 and maybe some locking is necessary.
Rudolf




From mylesgw at gmail.com  Fri Sep  4 19:10:28 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 4 Sep 2009 11:10:28 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909041006r637fd61bg3b18a9fe26ad88bb@mail.gmail.com>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<13426df10909041006r637fd61bg3b18a9fe26ad88bb@mail.gmail.com>
Message-ID: <AF401C7D9E9A4AB389DB59E1F3D3B7D2@chimp>

> > I don't know how the conversion works exactly, or where it takes place,
> but
> > the HT packet is a read or a write to 0xFD.FE00.0000 + an offset for the
> > UnitID(pci device number). ?So, for device 7 on the bus and config
> register
> > 0x14, you get 0xFDFE003814. ?You don't have to worry about bus numbers
> > because they get taken care of based on the HT chain the to which the
> packet
> > is routed.
> 
> This is a memory read/write?
Yes.  It's just to the reserved addresses for config space.

Myles




From rminnich at gmail.com  Fri Sep  4 19:20:44 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 10:20:44 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA1496A.5030206@assembler.cz>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
Message-ID: <13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>

On Fri, Sep 4, 2009 at 10:07 AM, Rudolf Marek<r.marek at assembler.cz> wrote:

> I think the only proper way is to do type1 and maybe some locking is
> necessary.

but our thread subject is "unstable fam10h". Given that fam10h is the
problem, and that it supports MMCONF, why not make new versions of the
functions for processors that have MMCONF and use them on those
processors?

We've never seen this kind of problem on K8 AFAIK. We can continue to
use the old functions on those old CPUs.

So, what I'm trying to say:
- we have a problem on fam10h
- it seems to be a non-smp-safe function doing a config cycle
- there are two ways to eliminate the problem
  o write a fam10 version of that function that will use MMCONF (will
work on all later CPUs)
  o modify old function by adding a lock  (i.e. stick with legacy
mechanism for older CPUs)

I just can't see a good reason to stick with the type 1 access when
the fam10h and, presumably all later families, will
support MMCONF. The cf8/cfc is a 15-year-old idea (at least) that
predates smp and multicore. We should be
trying to eliminate that old mechanism whenever we can (at least it
seems that way to me). It is the cf8/cfc mechanism that is the
problem, not the lack of locking.

ron



From r.marek at assembler.cz  Fri Sep  4 19:20:27 2009
From: r.marek at assembler.cz (Rudolf Marek)
Date: Fri, 04 Sep 2009 19:20:27 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA1496A.5030206@assembler.cz>
References: <op.uzljz7kn1ay1or@x53k>	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
Message-ID: <4AA14C5B.3090703@assembler.cz>

Hi all,

I think I just found an answer:

2.11 Configuration Space

This BKDG chapter suggest that there is a MSR which can be used to do MMIO accesses.

MSRC001_0058 MMIO Configuration Base Address Register

Note that all cores should have this addr. Also it seems that this is what\ it 
should be used in ACPI instead of the NB MCFG aperture.



Rudolf




From svn at coreboot.org  Fri Sep  4 21:25:51 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  4 Sep 2009 21:25:51 +0200
Subject: [coreboot] [v2] r4627 - trunk/coreboot-v2/documentation
Message-ID: <mailman.3691.1355071617.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-09-04 21:25:51 +0200 (Fri, 04 Sep 2009)
New Revision: 4627

Modified:
   trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex
Log:
Fix various build issues and errors in LinuxBIOS-AMD64.tex.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex
===================================================================
--- trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-09-04 16:30:31 UTC (rev 4626)
+++ trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex	2009-09-04 19:25:51 UTC (rev 4627)
@@ -1234,7 +1234,7 @@
 coreboot has to either assert an LDTSTOP or a reset to make the changes
 become active.  Additionally Linux can do a firmware reset, if coreboot
 provides the needed infrastructure. To use this capability, define the
-option \texttt{HAVE\_HARD\CONFIG_RESET} and add an object file specifying the
+option \texttt{CONFIG\_HAVE\_HARD\_RESET} and add an object file specifying the
 reset code in your mainboard specific configuration file
 \texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}:
 
@@ -1552,7 +1552,7 @@
 ROMCC images are so-called because C code for the ROM part is compiled with romcc. romcc is an optimizing C compiler which compiles one, and only 
 one file; to get more than one file, one must include the C code via include statements. The main ROM code .c file is usually called auto.c. 
 \subsubsection{How it is built}
-Romcc compiles auto.c to produce auto.inc. auto.inc is included in the main crt0.S, which is then preprocessed to produce crt0.s. The inclusion of files into crt0.S is controlled by the CONFIG_CRT0\_INCLUDES variable. crt0.s is then assembled. 
+Romcc compiles auto.c to produce auto.inc. auto.inc is included in the main crt0.S, which is then preprocessed to produce crt0.s. The inclusion of files into crt0.S is controlled by the CONFIG\_CRT0\_INCLUDES variable. crt0.s is then assembled. 
 
 File for the ram part are compiled in a conventional manner. 
 
@@ -1574,17 +1574,17 @@
 As we mentioned, the ROM file consists of multiple images. In the basic file, there are two full coreboot rom images. The build sequence for each is the same, and in fact the ldscript.ld files are almost identical. The only difference is in a few makefile variables, generated by the config tool. 
 
 \begin{itemize}
-\item PAYLOAD\_SIZE. Each image may have a different payload size. 
-\item \CONFIG_ROMBASE Each image must have a different base in rom. 
-\item \CONFIG_RESET Unclear what this is used for. 
-\item \_EXCEPTION\_VECTORS where an optional IDT might go.
-\item USE\_OPTION\_TABLE if set, an option table section will be linked in. 
+\item CONFIG\_PAYLOAD\_SIZE. Each image may have a different payload size. 
+\item CONFIG\_ROMBASE Each image must have a different base in rom. 
+\item CONFIG\_RESET Unclear what this is used for. 
+\item CONFIG\_EXCEPTION\_VECTORS where an optional IDT might go.
+\item CONFIG\_USE\_OPTION\_TABLE if set, an option table section will be linked in. 
 \item CONFIG\_ROM\_PAYLOAD\_START This is the soon-to-be-deprecated way of locating a payload. cbfs eliminates this. 
-\item USE\_FALLBACK\_IMAGE Whether this is a fallback or normal image
-\item ROM\_SECTION\_SIZE Essentially, the payload size. Soon to be deprecated. 
-\item ROM\_IMAGE\_SIZE Size of this image (i.e. fallback or normal image)
-\item ROM\_SIZE Total size of the ROM
-\item XIP\_RAM\_BASE The start of eXecute In Place code. XIP allows for not copying code to ram, but just running it from ROM. 
+\item CONFIG\_USE\_FALLBACK\_IMAGE Whether this is a fallback or normal image
+\item CONFIG\_ROM\_SECTION\_SIZE Essentially, the payload size. Soon to be deprecated. 
+\item CONFIG\_ROM\_IMAGE\_SIZE Size of this image (i.e. fallback or normal image)
+\item CONFIG\_ROM\_SIZE Total size of the ROM
+\item CONFIG\_XIP\_RAM\_BASE The start of eXecute In Place code. XIP allows for not copying code to ram, but just running it from ROM. 
 \end{itemize}
 
 Each image (normal or fallback) is built completely independently and does not get linked to the other. They are assembled into one ROM image by the (soon to be deprecated) buildrom tool, or by the cbfs tool. 




From svn at coreboot.org  Fri Sep  4 21:34:44 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri,  4 Sep 2009 21:34:44 +0200
Subject: [coreboot] [v2] r4628 - trunk/coreboot-v2/documentation
Message-ID: <mailman.3692.1355071617.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-09-04 21:34:43 +0200 (Fri, 04 Sep 2009)
New Revision: 4628

Modified:
   trunk/coreboot-v2/documentation/Makefile
Log:
Fix clean rules for the tex files.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/coreboot-v2/documentation/Makefile
===================================================================
--- trunk/coreboot-v2/documentation/Makefile	2009-09-04 19:25:51 UTC (rev 4627)
+++ trunk/coreboot-v2/documentation/Makefile	2009-09-04 19:34:43 UTC (rev 4628)
@@ -63,10 +63,9 @@
 	grep '^config' $< | awk '{print $2}'  >>$@
 	cat endverbatim.tex  >> $@
 
-
 clean:
-	rm -f *.aux *.idx *.log *.toc *.out $(FIGS) mainboardkconfig.tex skconfig.tex cpukconfig.tex socketkconfig.tex
+	rm -f *.aux *.idx *.log *.toc *.out $(FIGS) mainboardkconfig.tex skconfig.tex cpukconfig.tex socketfkconfig.tex
 
 distclean: clean
-	rm -f LinuxBIOS-AMD64.pdf 
-	
+	rm -f LinuxBIOS-AMD64.pdf Kconfig.pdf
+




From slara at udec.cl  Sat Sep  5 03:40:12 2009
From: slara at udec.cl (Sebastian Lara)
Date: Fri, 4 Sep 2009 21:40:12 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
Message-ID: <b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>

2009/9/4 ron minnich <rminnich at gmail.com>:
> quick meta-question: why do you want to boot from local? Reason I ask
> is that the newest compute clusters are
> moving away from local disks for ?many reasons.
>
> Using a local disk from storage is fine, people still do that, but
> booting from local can make life harder when errors crop up.
>

Just because we start using ROCKS Clusters.  Are there some cluster
distributions that can run without local disk on nodes?

Thanks

-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From rminnich at gmail.com  Sat Sep  5 05:24:06 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 4 Sep 2009 20:24:06 -0700
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
	<b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
Message-ID: <13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>

On Fri, Sep 4, 2009 at 6:40 PM, Sebastian Lara<slara at udec.cl> wrote:

> Just because we start using ROCKS Clusters. ?Are there some cluster
> distributions that can run without local disk on nodes?

Yes. I strongly suggest you take a look at this: http://onesis.org/

No local disks required. How big is your cluster? If less than 128
nodes, just run NFS root with one NFS root server. onesis is
incredibly clever, in that you can easily configure it to put each
nodes /tmp, /var, and so on in local ramfs or on a local disk.

We use it to run a 4400 node (not a typo) system at sandia: it scales.
We have many different types of installations, and it runs well one
even very small systems, like my Geode clusters.

And, it's very network oriented, but allows you to have data on local
disks. I'm really sold on it. One of our newer interns, Chris Kinney,
who is also on this list, can tell you more. He set up an 80-node
cluster, with no previous experience, in an afternoon.

I think if you went with onesis you could avoid having to refresh your
bios. Your life would be easier.

For compute node clusters, in fact, the best thing you can do is yank
the disks and throw them away -- unless you need them for local data
storage. They tend to cause trouble. I have not built a disk-based
cluster in 10 years, and I've built clusters that range in size from 4
nodes to 2048 nodes. Local disks are just trouble.

While I respect the work the Rocks guys have done, I think onesis is a
good way to go. So does Sun: they use onesis for their commercial
cluster offerings.

Thanks

ron



From c-d.hailfinger.devel.2006 at gmx.net  Sat Sep  5 05:48:52 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sat, 05 Sep 2009 05:48:52 +0200
Subject: [coreboot] [PATCH] Some K8 revF RAM SPD refactoring
Message-ID: <4AA1DFA4.7070501@gmx.net>

Hi Ward,

I wanted to calculate the optimal timing for any setup with mixed DIMMs
where the timing parameters may be compatible but not identical.
This patch is a step in the right direction (hopefully). I think Marc
already reviewed parts of it last year, but I couldn't find the
conversation anymore.

Warning: The spec is horribly backwards in some places, and the code
sort of inherits this. I spent a few days figuring out why the old code
even worked, and then I noticed it wasn't as bad as it originally looked.

Feel free to comment, fix, apply, rip to shreds.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Index: LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c
===================================================================
--- LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c	(Revision 4614)
+++ LinuxBIOSv2-asus_m2a-vm/src/northbridge/amd/amdk8/raminit_f.c	(Arbeitskopie)
@@ -39,7 +39,7 @@
 #error This file needs CONFIG_USE_PRINTK_IN_CAR
 #endif
 
-#define RAM_TIMING_DEBUG 0
+#define RAM_TIMING_DEBUG 1
 
 #if RAM_TIMING_DEBUG == 1
 #define printk_raminit printk_debug
@@ -1499,7 +1499,8 @@
 			}
 			if (value0 != value1) {
 				printk_raminit("SPD values differ between channel 0/1 for byte %i\n", addr);
-				goto single_channel;
+				printk_raminit("Ignoring the differences for now!\n", addr);
+				//goto single_channel;
 			}
 		}
 	}
@@ -1786,6 +1787,51 @@
 	return 0;
 }
 
+int check_spd_latency_available(u32 spd_device, unsigned min_cycle_time, unsigned min_latency)
+{
+	int latencies;
+	int latency;
+	int index;
+	int value;
+
+	latencies = spd_read_byte(spd_device, SPD_CAS_LAT);
+	if (latencies < 0)
+		return -1;
+	if (latencies == 0)
+		return 1;
+
+	/* Compute the lowest cas latency supported */
+	latency = log2(latencies) -2;
+
+	/* Walk through searching for the selected latency */
+	for (index = 0; index < 3; index++, latency++) {
+		if (!(latencies & (1 << latency))) {
+			continue;
+		}
+		if (latency == min_latency)
+			break;
+	}
+	/* If I can't find the latency or my index is bad error */
+	if ((latency != min_latency) || (index >= 3)) {
+		return -2;
+	}
+
+	/* Read the min_cycle_time for this latency */
+	value = spd_read_byte(spd_device, latency_indicies[index]);
+	if (value < 0)
+		return -1;
+
+	value = convert_to_linear(value);
+	/* All is good if the selected clock speed
+	 * is what I need or slower.
+	 */
+	if (value <= min_cycle_time)
+		return 1;
+
+	/* That didn't work out... */
+	return -2;
+}
+
 static struct spd_set_memclk_result spd_set_memclk(const struct mem_controller *ctrl, struct mem_info *meminfo)
 {
 	/* Compute the minimum cycle time for these dimms */
@@ -1856,10 +1902,6 @@
 	printk_raminit("3 min_latency: %08x\n", min_latency);
 
 	for (i = 0; (i < DIMM_SOCKETS); i++) {
-		int latencies;
-		int latency;
-		int index;
-		int value;
 		u32 spd_device = ctrl->channel0[i];
 
 		if (!(meminfo->dimm_mask & (1 << i))) {
@@ -1870,42 +1912,17 @@
 			}
 		}
 
-		latencies = spd_read_byte(spd_device, SPD_CAS_LAT);
-		if (latencies < 0) goto hw_error;
-		if (latencies == 0) {
+		switch (check_spd_latency_available(spd_device, min_cycle_time, min_latency)) {
+		case -2:
+			/* We have an error, disable the dimm */
+			meminfo->dimm_mask = disable_dimm(ctrl, i, meminfo);
+			break;
+		case -1:
+			goto hw_error;
+			break;
+		case 1:
 			continue;
 		}
-
-		/* Compute the lowest cas latency supported */
-		latency = log2(latencies) -2;
-
-		/* Walk through searching for the selected latency */
-		for (index = 0; index < 3; index++, latency++) {
-			if (!(latencies & (1 << latency))) {
-				continue;
-			}
-			if (latency == min_latency)
-				break;
-		}
-		/* If I can't find the latency or my index is bad error */
-		if ((latency != min_latency) || (index >= 3)) {
-			goto dimm_err;
-		}
-
-		/* Read the min_cycle_time for this latency */
-		value = spd_read_byte(spd_device, latency_indicies[index]);
-		if (value < 0) goto hw_error;
-
-		value = convert_to_linear(value);
-		/* All is good if the selected clock speed
-		 * is what I need or slower.
-		 */
-		if (value <= min_cycle_time) {
-			continue;
-		}
-		/* Otherwise I have an error, disable the dimm */
-	dimm_err:
-		meminfo->dimm_mask = disable_dimm(ctrl, i, meminfo);
 	}
 
 	printk_raminit("4 min_cycle_time: %08x\n", min_cycle_time);


-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Sat Sep  5 19:36:02 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 05 Sep 2009 19:36:02 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
References: <op.uzljz7kn1ay1or@x53k>	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>	<1EF2A528D4C54ACE940C759DE50892FC@chimp>	<4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
Message-ID: <4AA2A182.4040506@coresystems.de>

ron minnich wrote:
> So, what I'm trying to say:
> - we have a problem on fam10h
> - it seems to be a non-smp-safe function doing a config cycle
> - there are two ways to eliminate the problem
>   o write a fam10 version of that function that will use MMCONF (will
> work on all later CPUs)
>   o modify old function by adding a lock  (i.e. stick with legacy
> mechanism for older CPUs)
>   

Another idea would be to get rid of SMP setup in CAR stage. It sounds
highly funky to me anyways.

- Why are we doing this anyways?
   o Is there a reason?
   o No other SMP system except K10 does this.

* How many ms do we benefit from that? (Honest question). Any at all?

Stefan






From rminnich at gmail.com  Sat Sep  5 19:46:57 2009
From: rminnich at gmail.com (ron minnich)
Date: Sat, 5 Sep 2009 10:46:57 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA2A182.4040506@coresystems.de>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
	<4AA2A182.4040506@coresystems.de>
Message-ID: <13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>

On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauer<stepan at coresystems.de> wrote:

> Another idea would be to get rid of SMP setup in CAR stage. It sounds
> highly funky to me anyways.
>
> - Why are we doing this anyways?
> ? o Is there a reason?
> ? o No other SMP system except K10 does this.
>
> * How many ms do we benefit from that? (Honest question). Any at all?

This may fix one problem, but it does not fix the general problem:
using cf8/cfc is not going to be safe on multiple cores, from my
understanding.

ron



From ward at gnu.org  Sat Sep  5 20:33:01 2009
From: ward at gnu.org (Ward Vandewege)
Date: Sat, 5 Sep 2009 14:33:01 -0400
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
	<4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
Message-ID: <20090905183301.GA12631@countzero.vandewege.net>

On Sat, Sep 05, 2009 at 10:46:57AM -0700, ron minnich wrote:
> On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauer<stepan at coresystems.de> wrote:
> 
> > Another idea would be to get rid of SMP setup in CAR stage. It sounds
> > highly funky to me anyways.
> >
> > - Why are we doing this anyways?
> > ? o Is there a reason?
> > ? o No other SMP system except K10 does this.
> >
> > * How many ms do we benefit from that? (Honest question). Any at all?
> 
> This may fix one problem, but it does not fix the general problem:
> using cf8/cfc is not going to be safe on multiple cores, from my
> understanding.

Not to complicate matters even further, but since we are talking about
locking - will any of this improve the 'many cores talking to serial at once'
problem?

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From stepan at coresystems.de  Sat Sep  5 21:13:38 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sat, 05 Sep 2009 21:13:38 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <20090905183301.GA12631@countzero.vandewege.net>
References: <op.uzljz7kn1ay1or@x53k>	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>	<1EF2A528D4C54ACE940C759DE50892FC@chimp>	<4AA1496A.5030206@assembler.cz>	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>	<4AA2A182.4040506@coresystems.de>	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
Message-ID: <4AA2B862.3070409@coresystems.de>

Ward Vandewege wrote:
> On Sat, Sep 05, 2009 at 10:46:57AM -0700, ron minnich wrote:
>   
>> On Sat, Sep 5, 2009 at 10:36 AM, Stefan Reinauer<stepan at coresystems.de> wrote:
>>
>>     
>>> Another idea would be to get rid of SMP setup in CAR stage. It sounds
>>> highly funky to me anyways.
>>>
>>> - Why are we doing this anyways?
>>>   o Is there a reason?
>>>   o No other SMP system except K10 does this.
>>>
>>> * How many ms do we benefit from that? (Honest question). Any at all?
>>>       
>> This may fix one problem, but it does not fix the general problem:
>> using cf8/cfc is not going to be safe on multiple cores, from my
>> understanding.
>>     
>
> Not to complicate matters even further, but since we are talking about
> locking - will any of this improve the 'many cores talking to serial at once'
> problem?
>
>   
Yes, going non-parallel in CAR would. Finding a way to do locking via a
(memory mapped) chipset register, would make it possible to fix that,
too. With a lot of work. Just going MMCONF would not fix the printk thing.




From gregg.drwho8 at gmail.com  Sun Sep  6 02:49:20 2009
From: gregg.drwho8 at gmail.com (Gregg C Levine)
Date: Sat, 5 Sep 2009 20:49:20 -0400
Subject: [coreboot] DOS booting using V3
Message-ID: <70B9B763-86BC-4DE1-BA19-5433F2325AB0@gmail.com>

Hello!
Can it boot what I am calling original DOS? I have access to DOS 6.22  
and of course DOS 3.3. And also the thing promoted by General  
Software. Which is also called DOS and is largely code and binary- 
level compatible.



This is from an iPod Touch.



From peter at stuge.se  Sun Sep  6 04:30:21 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 6 Sep 2009 04:30:21 +0200
Subject: [coreboot] DOS booting using V3
In-Reply-To: <70B9B763-86BC-4DE1-BA19-5433F2325AB0@gmail.com>
References: <70B9B763-86BC-4DE1-BA19-5433F2325AB0@gmail.com>
Message-ID: <20090906023021.17572.qmail@stuge.se>

Gregg C Levine wrote:
> Can it boot what I am calling original DOS?

Yes, using SeaBIOS as payload that should work well.


//Peter



From rminnich at gmail.com  Sun Sep  6 07:00:26 2009
From: rminnich at gmail.com (ron minnich)
Date: Sat, 5 Sep 2009 22:00:26 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA2B862.3070409@coresystems.de>
References: <op.uzljz7kn1ay1or@x53k>
	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
	<4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
Message-ID: <13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>

there's at least three problems here :-)
1. do we want to do SMP of any kind in CAR? I think not, but I'd like
to hear Marc's opinion
2. There are techniques from the oldest days of PCI (cf8/cfc) that we
use that don't work well in a multicore world.
     MMCONF, it seems, can help here. Using MMCONF for config cycles
may only work for newer CPUs,
     but we really ought to move to something that doesn't require a
shared resource such as cf8/cfc for more modern
     CPUs.
3. we need smp style locking code for printk.

Any more :-)

ron



From stepan at coresystems.de  Sun Sep  6 10:58:47 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Sep 2009 10:58:47 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
References: <op.uzljz7kn1ay1or@x53k>	<13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>	<1EF2A528D4C54ACE940C759DE50892FC@chimp>	<4AA1496A.5030206@assembler.cz>	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>	<4AA2A182.4040506@coresystems.de>	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>	<20090905183301.GA12631@countzero.vandewege.net>	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
Message-ID: <4AA379C7.1090508@coresystems.de>


ron minnich wrote:
> 2. There are techniques from the oldest days of PCI (cf8/cfc) that we
> use that don't work well in a multicore world.
>   
Since there is only one set of PCI devices, I wonder what the benefit
would be to "penetrate" them from all CPU cores or what would even cause
that as a requirement.
> 3. we need smp style locking code for printk.
>   
We have. But not in raminit.


Stefan



From peter at stuge.se  Sun Sep  6 14:39:41 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 6 Sep 2009 14:39:41 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA379C7.1090508@coresystems.de>
References: <13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>
	<1EF2A528D4C54ACE940C759DE50892FC@chimp>
	<4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
	<4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
Message-ID: <20090906123941.27507.qmail@stuge.se>

Stefan Reinauer wrote:
> Since there is only one set of PCI devices, I wonder what the
> benefit would be to "penetrate" them from all CPU cores or what
> would even cause that as a requirement.

RAM init working concurrently with multiple memory controllers -
they're on PCI, right?


//Peter



From maciej.pijanka at gmail.com  Sun Sep  6 18:06:04 2009
From: maciej.pijanka at gmail.com (Maciej Pijanka)
Date: Sun, 6 Sep 2009 18:06:04 +0200
Subject: [coreboot] possible bug, reported on irc
Message-ID: <e7f94b360909060906u30bbd357w912c6410b2b4a4ff@mail.gmail.com>

Hello,

< Guest836553> Hello I noticed that OpenBIOS' disk-label package
doesn't allow raw disk access unless it has an apple partition map. In
particular I noticed that only modules/mac-parts.c honours the specs
(ftp://playground.sun.com/pub/1275/bindings/postscript/CHRP.ps,
section 11.1.2), which state the partition number 0 indicates the
whole disk. In pc-parts.c (MSDOS partition table format) partiton 0 is
the first primary partiton (it should be partition 1, I suppose) and
in sun-parts.c (I didn't try it) I don't see any special-handling code
for partition 0, so I suppose it's affected by the bug too.

I asked reporting person to post mail to list, so at least after
moderation it could reach ML. But mail don't appear so i am posting
this now.

best regards
Maciej

-- 
Maciej Pijanka, PLD-Linux Developer, Reg Linux user #133161
POE/Perl user



From stepan at coresystems.de  Sun Sep  6 21:36:16 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Sep 2009 21:36:16 +0200
Subject: [coreboot] Kconfig status
Message-ID: <4AA40F30.9080608@coresystems.de>

Hi developers!

I started creating a Kconfig status page in the Wiki at

http://www.coreboot.org/Kconfig

Currently all boards in there are marked "Unsupported". If you worked on
a Kconfig port of a board, please change the status on that page, so we
can see what's still missing. Please also use the Status/ Comments field
to mention issues or hints.

Thanks a lot,

Stefan



From stepan at coresystems.de  Sun Sep  6 21:40:06 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 06 Sep 2009 21:40:06 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <20090906123941.27507.qmail@stuge.se>
References: <13426df10909040929n5a360b4fr6b4d11eebd9ffffb@mail.gmail.com>	<1EF2A528D4C54ACE940C759DE50892FC@chimp>	<4AA1496A.5030206@assembler.cz>	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>	<4AA2A182.4040506@coresystems.de>	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>	<20090905183301.GA12631@countzero.vandewege.net>	<4AA2B862.3070409@coresystems.de>	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
Message-ID: <4AA41016.6010501@coresystems.de>

Peter Stuge wrote:
> Stefan Reinauer wrote:
>   
>> Since there is only one set of PCI devices, I wonder what the
>> benefit would be to "penetrate" them from all CPU cores or what
>> would even cause that as a requirement.
>>     
>
> RAM init working concurrently with multiple memory controllers -
> they're on PCI, right?
>   
Yes.

But why would it not be completely sufficient to set up all ram
controllers in the system from the BSP?

Or, put differently.

We're smart and we fix the PCI problem. Then we suddenly notice that
that is not enough. because a PCI operation is by no means an atomic
operation. We're going to have to add another layer of locking on top of
that, for example for SMBUS access, which might involve PCI access.

I'm saying we're opening a can of worms here, and unless we really like
to go fishing we should close it again and walk in the dry.

Stefan




From rminnich at gmail.com  Sun Sep  6 21:52:48 2009
From: rminnich at gmail.com (ron minnich)
Date: Sun, 6 Sep 2009 12:52:48 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <op.uzljz7kn1ay1or@x53k>
References: <op.uzljz7kn1ay1or@x53k>
Message-ID: <13426df10909061252q79f581fev58092057b1d019cb@mail.gmail.com>

On Tue, Sep 1, 2009 at 2:15 PM, Ralf Grosse Boerger<ralfgb at gmail.com> wrote:
> Hi,
>
> this a reply to the following message:
> http://www.coreboot.org/pipermail/coreboot/2009-August/051629.html
> [I am not subscribed to this list.]
>
> The sporadic boot problems ("FIXME! CPU Version unknown or not supported!")
> are caused by a race condition in Get_NB32().
>
> This function performs a read operation to the PCI configuration space via
> port CF8/CFC.
>
> u32 Get_NB32(u32 dev, u32 reg)
> {
> ? ? ? ?u32 addr;
>
> ? ? ? ?addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16);
> ? ? ? ?outl((1<<31) | (addr & ~3), 0xcf8);
>
> ? ? ? ?return inl(0xcfc);
> }
>
> As ports CF8/CFC are shared across cores (maybe even sockets?) concurrent
> accesses from different cores may yield random results.

OK, let's start this discussion again.

Can we at least answer this question. Ports CF8/CFC are shared across
- sockets
- cores

I am betting they are not shared across sockets, and would be
surprised if they are shared across cores but am
willing to believe it.

Anybody?


ron



From peter at stuge.se  Sun Sep  6 22:13:47 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 6 Sep 2009 22:13:47 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <4AA41016.6010501@coresystems.de>
References: <4AA1496A.5030206@assembler.cz>
	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>
	<4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
Message-ID: <20090906201347.16045.qmail@stuge.se>

Stefan Reinauer wrote:
> > RAM init working concurrently with multiple memory controllers -
> > they're on PCI, right?
> 
> Yes.
> 
> But why would it not be completely sufficient to set up all ram
> controllers in the system from the BSP?

The big coreboot SMP win is with ECC scrubbing, right? Does that
involve some PCI config space accesses to the memory controllers?
Is it simpler to create locking for PCI accesses, or to split out
the part of RAM init which sets up MCs into the BSP (as opposed to
keeping the code for each MC running on that same core)?


> I'm saying we're opening a can of worms here, and unless we really
> like to go fishing we should close it again and walk in the dry.

I'm thinking we're already hooked on that tasty fish? (By fish I mean
SMP memory init.)


//Peter



From slara at udec.cl  Mon Sep  7 00:10:34 2009
From: slara at udec.cl (Sebastian Lara)
Date: Sun, 6 Sep 2009 18:10:34 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
	<b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
	<13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>
Message-ID: <b09184500909061510r69eb8858o604d7e25f2094d65@mail.gmail.com>

2009/9/4 ron minnich <rminnich at gmail.com>:
> On Fri, Sep 4, 2009 at 6:40 PM, Sebastian Lara<slara at udec.cl> wrote:
>
>> Just because we start using ROCKS Clusters. ?Are there some cluster
>> distributions that can run without local disk on nodes?
>
> Yes. I strongly suggest you take a look at this: http://onesis.org/
>
> No local disks required. How big is your cluster? If less than 128
> nodes, just run NFS root with one NFS root server. onesis is
> incredibly clever, in that you can easily configure it to put each
> nodes /tmp, /var, and so on in local ramfs or on a local disk.
>
> We use it to run a 4400 node (not a typo) system at sandia: it scales.
> We have many different types of installations, and it runs well one
> even very small systems, like my Geode clusters.
>
> And, it's very network oriented, but allows you to have data on local
> disks. I'm really sold on it. One of our newer interns, Chris Kinney,
> who is also on this list, can tell you more. He set up an 80-node
> cluster, with no previous experience, in an afternoon.
>
> I think if you went with onesis you could avoid having to refresh your
> bios. Your life would be easier.
>
> For compute node clusters, in fact, the best thing you can do is yank
> the disks and throw them away -- unless you need them for local data
> storage. They tend to cause trouble. I have not built a disk-based
> cluster in 10 years, and I've built clusters that range in size from 4
> nodes to 2048 nodes. Local disks are just trouble.
>
> While I respect the work the Rocks guys have done, I think onesis is a
> good way to go. So does Sun: they use onesis for their commercial
> cluster offerings.
>
> Thanks

This sounds really good. I will definitely try this. Thanks.


-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From rminnich at gmail.com  Mon Sep  7 00:32:34 2009
From: rminnich at gmail.com (ron minnich)
Date: Sun, 6 Sep 2009 15:32:34 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <20090906201347.16045.qmail@stuge.se>
References: <4AA1496A.5030206@assembler.cz> <4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
Message-ID: <13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>

The way I see it the memory setup and SMP support in CAR are two very
different issues.

BSP can do its own memory. Once that memory is set up the APs can use
it. Thus, the APs can have working memory when they do their RAM
setup. In other words,
BSP does RAM setup in CAR
APs can do RAM setup with working RAM -- they just use the BSP RAM,
which is working.

The K8 code hints of this model, and, when I did my trial code for V3,
this is how I set it up to work.

Hence, we can do SMP memory setup  as long as the BSP sets up its own
memory before it starts up the APs. We are really talking about SMP in
CAR, which seems like a much harder issue.

Make sense? Something I'm missing?

ron



From rminnich at gmail.com  Mon Sep  7 00:44:36 2009
From: rminnich at gmail.com (ron minnich)
Date: Sun, 6 Sep 2009 15:44:36 -0700
Subject: [coreboot] I just stumbled across this
Message-ID: <13426df10909061544g197613ddq73cc965fc98b15ea@mail.gmail.com>

http://blogs.sun.com/makia/entry/building_a_mini_cluster

Short writeup on building a onesis minicluster.

Makia is no relation to me, as you can tell 'cause he spells his last
name wrong. But he's very smart and acccomplished in supercomputing,
and always worth paying attention to :-)

ron



From daniel at dmhome.net  Mon Sep  7 12:57:24 2009
From: daniel at dmhome.net (Daniel Toussaint)
Date: Mon, 7 Sep 2009 18:57:24 +0800
Subject: [coreboot] AMD 780 support
Message-ID: <6cb69d4a0909070357o5f5c9ed7j837f86a2ad2e06a5@mail.gmail.com>

Dear Coreboot ,

Is there any sign of the AMD 780 code yet ? I have a board just waiting to
be flashed with it ... :)

Greetings,

Daniel Toussaint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090907/e1aa32a3/attachment.html>

From Zheng.Bao at amd.com  Tue Sep  8 03:35:12 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 8 Sep 2009 09:35:12 +0800
Subject: [coreboot] AMD 780 support
In-Reply-To: <6cb69d4a0909070357o5f5c9ed7j837f86a2ad2e06a5@mail.gmail.com>
References: <6cb69d4a0909070357o5f5c9ed7j837f86a2ad2e06a5@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B170301F7CC@sbjgexmb1.amd.com>


RS780 code has been roughly done. I don't have the permission to give it
to you. Please contact Kevin.Tanguay at amd.com to get that.

Zheng 
________________________________________
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Daniel Toussaint
Sent: Monday, September 07, 2009 6:57 PM
To: coreboot at coreboot.org
Subject: [coreboot] AMD 780 support

Dear Coreboot , 

Is there any sign of the AMD 780 code yet ? I have a board just waiting
to be flashed with it ... :) 

Greetings, 

Daniel Toussaint




From marcj303 at gmail.com  Tue Sep  8 19:02:44 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 8 Sep 2009 11:02:44 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
Message-ID: <534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>

On Sun, Sep 6, 2009 at 4:32 PM, ron minnich<rminnich at gmail.com> wrote:
> The way I see it the memory setup and SMP support in CAR are two very
> different issues.

This bug is totally my fault...

Yes,  Memory setup and SMP CAR are two different issues. The SMP setup
happens during CAR is to setup microcode, HT and FIDVID prior to the
PLL reset and memory setup.

All the SMP PCI config space access should be MMIO. It is the first
thing that is enabled in CPU init in set_pci_mmio_conf_reg().

The bug is that I mixed a mem setup function in with SMP setup by
using mctGetLogicalCPUID() which uses Get_NB32. As pointed out, the
GET_NB32 is a cf8/cfc function. The mct code ported from AGESA assumes
that it is running on the BSP only and uses cf8/cfc..... (historical
k8 bug I think)

I think that I should change the mct PCI config functions to call the
coreboot pci_read_config32 functions that handle MMIO vs cfc/cf8
nicely. This should future proof  mct functions in CAR and a step
toward SMP memory setup.

Some of that mct code PCI config space code is a little funny (ok, a
lot funny), so it will take a little care. I should be able work patch
in a couple of days.

Marc

-- 
http://marcjonesconsulting.com



From stepan at coresystems.de  Tue Sep  8 19:29:10 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 08 Sep 2009 19:29:10 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <20090906201347.16045.qmail@stuge.se>
References: <4AA1496A.5030206@assembler.cz>	<13426df10909041020i58e95c01t2f41c497707e1152@mail.gmail.com>	<4AA2A182.4040506@coresystems.de>	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>	<20090905183301.GA12631@countzero.vandewege.net>	<4AA2B862.3070409@coresystems.de>	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>	<4AA379C7.1090508@coresystems.de>	<20090906123941.27507.qmail@stuge.se>	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
Message-ID: <4AA69466.5070709@coresystems.de>

Peter Stuge wrote:
> Stefan Reinauer wrote:
>   
>>> RAM init working concurrently with multiple memory controllers -
>>> they're on PCI, right?
>>>       
>> Yes.
>>
>> But why would it not be completely sufficient to set up all ram
>> controllers in the system from the BSP?
>>     
>
> The big coreboot SMP win is with ECC scrubbing, right? 
Yes, but that does not happen until we're in stage2. It's not really
part of memory init.

> Does that
> involve some PCI config space accesses to the memory controllers?
>   
I don't think so.






From ebiederm at xmission.com  Tue Sep  8 15:00:53 2009
From: ebiederm at xmission.com (Eric W. Biederman)
Date: Tue, 08 Sep 2009 06:00:53 -0700
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	(ron minnich's message of "Sun\, 6 Sep 2009 15\:32\:34 -0700")
References: <4AA1496A.5030206@assembler.cz> <4AA2A182.4040506@coresystems.de>
	<13426df10909051046k377a8d7bqd12406e2a4cf5594@mail.gmail.com>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
Message-ID: <m1pra1ioai.fsf@fess.ebiederm.org>

ron minnich <rminnich at gmail.com> writes:

> The way I see it the memory setup and SMP support in CAR are two very
> different issues.
>
> BSP can do its own memory. Once that memory is set up the APs can use
> it. Thus, the APs can have working memory when they do their RAM
> setup. In other words,
> BSP does RAM setup in CAR
> APs can do RAM setup with working RAM -- they just use the BSP RAM,
> which is working.
>
> The K8 code hints of this model, and, when I did my trial code for V3,
> this is how I set it up to work.
>
> Hence, we can do SMP memory setup  as long as the BSP sets up its own
> memory before it starts up the APs. We are really talking about SMP in
> CAR, which seems like a much harder issue.
>
> Make sense? Something I'm missing?

Long ago and far away.  When I did the K8 code here is what I recall
of my reasoning.

The only operation that benefited from being parallel was the clearing
ECC memory so it had consistent ECC bits.  Everything else works just
dandy from the BSP, and in fact because of the way the K8 memory
layout works you have to do all of the heavy lifting on a single cpu
so that you can place all of memory into one nice area for the mtrrs
and the like.

If the K10 has gotten as far as true cpu hotoplug support things may
be more decoupled now but I would be surprised if that mattered in
any real configuration.

The only thing that I ever had the other cpus starting earlier for
and this was pretty fundamental was to assign them their local apic
id's and put them to sleep.  After making that code work I never
put a print statement in there or did anything fancy.  There is just
nothing in there to make parallelism any more than an nuisance.

A big chunk of what has to happen very early is setting up hypertransport
and enabling routing between the cpus.  As I recall some point at the
end of setting up hypertransport routing the secondary cpus all come
online.  

With the K7 AMD actually had a model where both of the cpus started
booting at once and you read a northbridge register to see which one
should be primary the first read of that register returned 0 all
subsequent reads return 1 (or visa versa).  If you didn't read that
register first you got to sleep.  The K8 had a very similar model
except only one processor was every connected up as a bootstrap
processor in practice, and if you aren't connected up as a bootstrap
processor you sleep until the bootsrap processor setups up your
hypertransport.

SMP in coreboot (except where required) is a bad idea.  There are no
performance wins (unless you need to initialize memory with writes)
and it is an unnecessary complication.  So konk the other cpus on
the head as quickly as you can and go single processor.

Eric



From kevin at koconnor.net  Wed Sep  9 15:33:45 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Wed, 9 Sep 2009 09:33:45 -0400
Subject: [coreboot] Geode LX VGA BIOS Patch
In-Reply-To: <4A943378.7010000@umbc.edu>
References: <4A829320.4020606@umbc.edu> <4A943378.7010000@umbc.edu>
Message-ID: <20090909133345.GA5979@morn.localdomain>

On Tue, Aug 25, 2009 at 02:54:48PM -0400, Chris Kindt wrote:
> Another Updated Patch:
>
>    So far I have heard of problems when using a lcd connected to the vga 
> port and when switching from X to back to the console. I was able to  
> replicate problems and address them with this patch.
>
>    For the lcd issues, the left side of the screen was distorted and  
> cropped.  This was a timing problem from using incorrect modes. My crt  
> was able to function correctly with these modes.  There were two issues  
> with the mode table. When creating the patch I copied the original  
> seabios table instead of the geodelx modified table. Then even with the  
> correct geodelx table, the seabios table is still addressed at compile  
> time. The geodelx-v3 patch includes the modified table, while the  
> geodelx-modehack patch is a temporary quick fix to address the right 
> table.

Hi Chris,

As before, the main seabios patch looks good to me.  The "modehack"
patch, of course, needs to be cleaned up before committing.  Are you
still working on this?

-Kevin



From stepan at coresystems.de  Thu Sep 10 09:12:08 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Sep 2009 09:12:08 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
Message-ID: <4AA8A6C8.1020104@coresystems.de>

Hi,

in the progress of restructuring coreboot to work with CBFS, Kconfig and
other new features, we basically broke the PowerPC boards. Since none of
us has any of the supported hardware available for testing, and there is
no real reason to use coreboot on PowerPC processors (there are fine
bootloaders, like u-boot), we have been discussing to drop the PowerPC
port completely if nobody is willing to step up and revive it. Comments?

Stefan



From stepan at coresystems.de  Thu Sep 10 09:13:02 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Sep 2009 09:13:02 +0200
Subject: [coreboot] Kconfig status
In-Reply-To: <4AA40F30.9080608@coresystems.de>
References: <4AA40F30.9080608@coresystems.de>
Message-ID: <4AA8A6FE.7010803@coresystems.de>

Stefan Reinauer wrote:
> Hi developers!
>
> I started creating a Kconfig status page in the Wiki at
>
> http://www.coreboot.org/Kconfig
>
> Currently all boards in there are marked "Unsupported". If you worked on
> a Kconfig port of a board, please change the status on that page, so we
> can see what's still missing. Please also use the Status/ Comments field
> to mention issues or hints.
>
> Thanks a lot,
>
> Stefan
>
>   
Any takers?

Stefan



From peter at stuge.se  Thu Sep 10 11:50:47 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 10 Sep 2009 11:50:47 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <4AA8A6C8.1020104@coresystems.de>
References: <4AA8A6C8.1020104@coresystems.de>
Message-ID: <20090910095047.16365.qmail@stuge.se>

Stefan Reinauer wrote:
> we have been discussing to drop the PowerPC port completely if
> nobody is willing to step up and revive it. Comments?

The old revs will still be there.

In a way I think this is fine for all boards. Unless someone does the
work to update soon, there's no point in keeping broken ports around.


//Peter



From svn at coreboot.org  Thu Sep 10 13:21:48 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 10 Sep 2009 13:21:48 +0200
Subject: [coreboot] [v2] r4629 - trunk/util/getpir
Message-ID: <mailman.3693.1355071617.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-10 13:21:48 +0200 (Thu, 10 Sep 2009)
New Revision: 4629

Modified:
   trunk/util/getpir/code_gen.c
   trunk/util/getpir/pirq_routing.h
Log:
fix compilation issues for pirq checker tool (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/getpir/code_gen.c
===================================================================
--- trunk/util/getpir/code_gen.c	2009-09-04 19:34:43 UTC (rev 4628)
+++ trunk/util/getpir/code_gen.c	2009-09-10 11:21:48 UTC (rev 4629)
@@ -50,7 +50,7 @@
 		fprintf(fpir, "%s", *code++);
 
 	fprintf(fpir, "\t32 + 16 * %d,		/* Max. number of devices on the bus */\n",
-		ts, ts);
+		ts);
 	fprintf(fpir, "\t0x%02x,			/* Interrupt router bus */\n",
 		rt->rtr_bus);
 	fprintf(fpir, "\t(0x%02x << 3) | 0x%01x,	/* Interrupt router dev */\n",

Modified: trunk/util/getpir/pirq_routing.h
===================================================================
--- trunk/util/getpir/pirq_routing.h	2009-09-04 19:34:43 UTC (rev 4628)
+++ trunk/util/getpir/pirq_routing.h	2009-09-10 11:21:48 UTC (rev 4629)
@@ -39,6 +39,10 @@
 
 extern const struct irq_routing_table intel_irq_routing_table;
 
+#ifdef GETPIR
+#define copy_pirq_routing_table(start) (start)
+unsigned long write_pirq_routing_table(unsigned long start);
+#else
 #if CONFIG_HAVE_PIRQ_TABLE==1
 unsigned long copy_pirq_routing_table(unsigned long start);
 unsigned long write_pirq_routing_table(unsigned long start);
@@ -46,5 +50,6 @@
 #define copy_pirq_routing_table(start) (start)
 #define write_pirq_routing_table(start) (start)
 #endif
+#endif
 
 #endif /* ARCH_PIRQ_ROUTING_H */




From uwe at hermann-uwe.de  Thu Sep 10 16:04:12 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 10 Sep 2009 16:04:12 +0200
Subject: [coreboot] Kconfig status
In-Reply-To: <4AA8A6FE.7010803@coresystems.de>
References: <4AA40F30.9080608@coresystems.de> <4AA8A6FE.7010803@coresystems.de>
Message-ID: <20090910140412.GT7448@greenwood>

On Thu, Sep 10, 2009 at 09:13:02AM +0200, Stefan Reinauer wrote:
> Stefan Reinauer wrote:
> > Hi developers!
> >
> > I started creating a Kconfig status page in the Wiki at
> >
> > http://www.coreboot.org/Kconfig
> >
> > Currently all boards in there are marked "Unsupported". If you worked on
> > a Kconfig port of a board, please change the status on that page, so we
> > can see what's still missing. Please also use the Status/ Comments field
> > to mention issues or hints.
> >
> > Thanks a lot,
> >
> > Stefan
> >
> >   
> Any takers?

Yep, I'll have a look and update the table soonish. We should probably
also record if the targets have been build-tested and/or run-time
tested.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From marcj303 at gmail.com  Thu Sep 10 17:35:57 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Thu, 10 Sep 2009 09:35:57 -0600
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <20090910095047.16365.qmail@stuge.se>
References: <4AA8A6C8.1020104@coresystems.de>
	<20090910095047.16365.qmail@stuge.se>
Message-ID: <534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:50 AM, Peter Stuge <peter at stuge.se> wrote:
> Stefan Reinauer wrote:
>> we have been discussing to drop the PowerPC port completely if
>> nobody is willing to step up and revive it. Comments?
>
> The old revs will still be there.
>
> In a way I think this is fine for all boards. Unless someone does the
> work to update soon, there's no point in keeping broken ports around.
>
>
> //Peter

I agree, We should probably try to have a "last known working version"
in the supported boards list on the wiki.

Marc


-- 
http://marcjonesconsulting.com



From rminnich at gmail.com  Thu Sep 10 17:45:41 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 10 Sep 2009 08:45:41 -0700
Subject: [coreboot] Kconfig status
In-Reply-To: <20090910140412.GT7448@greenwood>
References: <4AA40F30.9080608@coresystems.de> <4AA8A6FE.7010803@coresystems.de>
	<20090910140412.GT7448@greenwood>
Message-ID: <13426df10909100845s318d8af8v5f97cd386732f03@mail.gmail.com>

I'm working on it but I have to put a few things together first. I'm
reviving some old tools that make network booting more efficient. If
anyone cares, they're called beoboot.

ron



From rminnich at gmail.com  Thu Sep 10 17:47:42 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 10 Sep 2009 08:47:42 -0700
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>
References: <4AA8A6C8.1020104@coresystems.de>
	<20090910095047.16365.qmail@stuge.se>
	<534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>
Message-ID: <13426df10909100847x18a6d5eco2fbb1cfaca649b51@mail.gmail.com>

On Thu, Sep 10, 2009 at 8:35 AM, Marc Jones<marcj303 at gmail.com> wrote:

> I agree, We should probably try to have a "last known working version"
> in the supported boards list on the wiki.

agree. Let's clean out the attic. It makes it easier for people to
focus on the boards we do have.

ron



From uwe at hermann-uwe.de  Thu Sep 10 18:12:30 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 10 Sep 2009 18:12:30 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>
References: <4AA8A6C8.1020104@coresystems.de>
	<20090910095047.16365.qmail@stuge.se>
	<534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>
Message-ID: <20090910161230.GU7448@greenwood>

On Thu, Sep 10, 2009 at 09:35:57AM -0600, Marc Jones wrote:
> On Thu, Sep 10, 2009 at 3:50 AM, Peter Stuge <peter at stuge.se> wrote:
> > Stefan Reinauer wrote:
> >> we have been discussing to drop the PowerPC port completely if
> >> nobody is willing to step up and revive it. Comments?
> >
> > The old revs will still be there.
> >
> > In a way I think this is fine for all boards. Unless someone does the
> > work to update soon, there's no point in keeping broken ports around.
> >
> >
> > //Peter
> 
> I agree,

Ditto. For PowerPC and ARM and MIPS u-boot and other bootloaders are
better suited and already work and are maintained etc...


> We should probably try to have a "last known working version"
> in the supported boards list on the wiki.

Hm, dunno, if the boards are removed from svn we could also remove them from
the wiki table completely (or put them in a "supported in earlier revisions"
table somewhere else, in case somebody may want to resurrect them).


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From stepan at coresystems.de  Thu Sep 10 19:02:56 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 10 Sep 2009 19:02:56 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <20090910161230.GU7448@greenwood>
References: <4AA8A6C8.1020104@coresystems.de>	<20090910095047.16365.qmail@stuge.se>	<534e5dc20909100835i386dcd04q71d468c144e439c@mail.gmail.com>
	<20090910161230.GU7448@greenwood>
Message-ID: <4AA93140.80707@coresystems.de>

Uwe Hermann wrote:
>> We should probably try to have a "last known working version"
>> in the supported boards list on the wiki.
>>     
>
> Hm, dunno, if the boards are removed from svn we could also remove them from
> the wiki table completely (or put them in a "supported in earlier revisions"
> table somewhere else, in case somebody may want to resurrect them).
>   

Good idea. We might want to put the v1 and v3 only boards there, too..




From jonathansturges at yahoo.com  Thu Sep 10 23:01:42 2009
From: jonathansturges at yahoo.com (Jonathan Sturges)
Date: Thu, 10 Sep 2009 14:01:42 -0700 (PDT)
Subject: [coreboot] Geode GX1 with VGA-enabled payload?
Message-ID: <797163.19662.qm@web35907.mail.mud.yahoo.com>

Hi,
I am trying to remind myself what I need (or if it's even possible) to use a payload that makes use of VGA on a Geode GX1/CS5530 system.  I'd like to have a bootloader payload that uses VGA instead of serial, if possible.

Now, I've got VGA enabled in the coreboot image I'm currently using, and I get the coreboot logo splash screen, but I'm still using a payload configured for COM1.  Aside from changing payloads to one that uses VGA and PS/2 devices, what else is required?  Am I required to have a VGA BIOS?  I'm guessing that I am.  Can someone confirm that that's what I need?  If so, I remember seeing the tutorial somewhere on extracting the VGA BIOS and incorporating it in coreboot.  Though, if someone has an up-to-date recipe for this, that'd be even better!

thanks,
Jonathan



From tommy24 at gatech.edu  Thu Sep 10 23:28:44 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Thu, 10 Sep 2009 14:28:44 -0700
Subject: [coreboot] Control Transfer from coreboot to payload
Message-ID: <1519b3fb0909101428u4df488c6sd2af8bcc7f19b811@mail.gmail.com>

Hey there,
I read the documents on the website.
But those documents cover the internal stages of coreboot.
I am more curious about how coreboot transfers control to the payload, where
the payload is loaded and the processor state, paging enabled or not.
Please give me some clues about how coreboot achieve those things or where I
can find such information.
Thanks in advance.

Regards,
Tommy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090910/118a5e3f/attachment.html>

From slara at udec.cl  Fri Sep 11 00:22:52 2009
From: slara at udec.cl (Sebastian Lara)
Date: Thu, 10 Sep 2009 18:22:52 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909061510r69eb8858o604d7e25f2094d65@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
	<b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
	<13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>
	<b09184500909061510r69eb8858o604d7e25f2094d65@mail.gmail.com>
Message-ID: <b09184500909101522k64565d2mc7f8d75f25f95d7c@mail.gmail.com>

Hi,

2009/9/6 Sebastian Lara <slara at udec.cl>:
> 2009/9/4 ron minnich <rminnich at gmail.com>:
>> On Fri, Sep 4, 2009 at 6:40 PM, Sebastian Lara<slara at udec.cl> wrote:
>>
>>> Just because we start using ROCKS Clusters. ?Are there some cluster
>>> distributions that can run without local disk on nodes?
>>
>> Yes. I strongly suggest you take a look at this: http://onesis.org/
>>

Thanks for the suggestion. My cluster is finnally up. The installation went fine

-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From rminnich at gmail.com  Fri Sep 11 02:13:41 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 10 Sep 2009 17:13:41 -0700
Subject: [coreboot] USB debug port in ICH5?
Message-ID: <13426df10909101713n56f82031jb04fdd210a4a1154@mail.gmail.com>

I'm looking but don't see info yet on a USB debug port in ICH5, anyone know?

The issue is that the Dell Server 1850 node I'm trying to get working
doesn't give direct COM1 access to the P4; it goes through a (ack!
Ptui!) baseboard maintenance controller. So to talk to COM1 you have
to know how to talk to the BMC. This may just be another non-standard
IPMI interface or something else, not sure, but in any case I figure
the USB debug port might be easier.

ron



From rminnich at gmail.com  Fri Sep 11 02:22:12 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 10 Sep 2009 17:22:12 -0700
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <b09184500909101522k64565d2mc7f8d75f25f95d7c@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<4AA0256A.3000806@coresystems.de>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
	<b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
	<13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>
	<b09184500909061510r69eb8858o604d7e25f2094d65@mail.gmail.com>
	<b09184500909101522k64565d2mc7f8d75f25f95d7c@mail.gmail.com>
Message-ID: <13426df10909101722y7eed2caes1ca82190d7cdecd3@mail.gmail.com>

On Thu, Sep 10, 2009 at 3:22 PM, Sebastian Lara<slara at udec.cl> wrote:

> Thanks for the suggestion. My cluster is finnally up. The installation went fine

If you have onesis questions don't hesitate to contact me. Also, what
size cluster? Just curious.

thanks

ron



From tommy24 at gatech.edu  Fri Sep 11 02:26:51 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Thu, 10 Sep 2009 17:26:51 -0700
Subject: [coreboot] SMP Linux on QEMU
Message-ID: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>

Hi,
I am using coreboot v3 with FILO.
I specify "qemu -L . vd.img -smp 4".
But I always see one cpu in /proc/cpuinfo.
Then I tried if SMP works in v2.
However, when I tried to boot, qemu showed the following error messages: (v3
works fine here)
Uncompressing coreboot to RAM.
Jumping to image.
Check CBFS header at fffeffe0
magic is 4f524243
Found CBFS header at fffeffe0
Check fallback/payload
CBFS: follow chain: fff80000 + 38 + 14efa + align -> fff94f40
Check fallback/coreboot_ram
CBFS: follow chain: fff94f40 + 38 + 687f + align -> fff9b800
Check
CBFS: follow chain: fff9b800 + 28 + 547d8 + align -> ffff0000
CBFS:  Could not find file normal/coreboot_ram
Jumping to image.
qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0000
Does anyone know how to boot up SMP kernel on qemu?
Any hint is very appreciated.
Thanks in advance.

Regards,
Tommy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090910/66009aa8/attachment.html>

From eswierk at aristanetworks.com  Fri Sep 11 03:53:44 2009
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Thu, 10 Sep 2009 18:53:44 -0700
Subject: [coreboot] USB debug port in ICH5?
In-Reply-To: <13426df10909101713n56f82031jb04fdd210a4a1154@mail.gmail.com>
References: <13426df10909101713n56f82031jb04fdd210a4a1154@mail.gmail.com>
Message-ID: <9ae48b020909101853h7c54deebnde9027b1dd1e77e6@mail.gmail.com>

On Thu, Sep 10, 2009 at 5:13 PM, ron minnich <rminnich at gmail.com> wrote:
> I'm looking but don't see info yet on a USB debug port in ICH5, anyone know?
>
> The issue is that the Dell Server 1850 node I'm trying to get working
> doesn't give direct COM1 access to the P4; it goes through a (ack!
> Ptui!) baseboard maintenance controller. So to talk to COM1 you have
> to know how to talk to the BMC. This may just be another non-standard
> IPMI interface or something else, not sure, but in any case I figure
> the USB debug port might be easier.

Sec. 5.20.10 of the ICH5 datasheet
(http://www.intel.com/design/chipsets/embedded/docs/865g.htm)
describes the EHCI debug port.

I suppose you could also try reverse-engineering Dell's configuration
utilities (bioscfg.exe and bmccfg.exe) to see how they configure the
COM1 port.

--Ed



From eswierk at aristanetworks.com  Fri Sep 11 04:00:41 2009
From: eswierk at aristanetworks.com (Ed Swierk)
Date: Thu, 10 Sep 2009 19:00:41 -0700
Subject: [coreboot] USB debug port in ICH5?
In-Reply-To: <9ae48b020909101853h7c54deebnde9027b1dd1e77e6@mail.gmail.com>
References: <13426df10909101713n56f82031jb04fdd210a4a1154@mail.gmail.com>
	<9ae48b020909101853h7c54deebnde9027b1dd1e77e6@mail.gmail.com>
Message-ID: <9ae48b020909101900y66838e1ci49718d710123d69@mail.gmail.com>

Also see the ICH5 EHCI programming manual:
http://www.intel.com/Assets/PDF/manual/298656.pdf

--Ed



From slara at udec.cl  Fri Sep 11 04:52:20 2009
From: slara at udec.cl (Sebastian Lara)
Date: Thu, 10 Sep 2009 22:52:20 -0400
Subject: [coreboot] LNXI eVelocity 2 BIOS reburn
In-Reply-To: <13426df10909101722y7eed2caes1ca82190d7cdecd3@mail.gmail.com>
References: <b09184500909021846n2ed3c3bnb91bd282c4880ae7@mail.gmail.com>
	<b09184500909031553v2b2cdbbfw2d6402e8378628d8@mail.gmail.com>
	<4AA11DCB.6040503@coresystems.de>
	<b09184500909040747t5367dca1q71a8348a7f2d7dd2@mail.gmail.com>
	<13426df10909040942i3185da17i8a62fdbfddb619f5@mail.gmail.com>
	<b09184500909041840o31a3038bw48cd2e20fc769a6@mail.gmail.com>
	<13426df10909042024o5bc2e9cdwfa440b1f11710524@mail.gmail.com>
	<b09184500909061510r69eb8858o604d7e25f2094d65@mail.gmail.com>
	<b09184500909101522k64565d2mc7f8d75f25f95d7c@mail.gmail.com>
	<13426df10909101722y7eed2caes1ca82190d7cdecd3@mail.gmail.com>
Message-ID: <b09184500909101952g58f3879dg7c37ad6cf364419@mail.gmail.com>

2009/9/10 ron minnich <rminnich at gmail.com>:
> On Thu, Sep 10, 2009 at 3:22 PM, Sebastian Lara<slara at udec.cl> wrote:
>
>> Thanks for the suggestion. My cluster is finnally up. The installation went fine
>
> If you have onesis questions don't hesitate to contact me. Also, what
> size cluster? Just curious.
>

It's a 10 node, 20 cores, 2.35GHz per core  2Gb RAM per node, and infiniband.

Thanks  ;-)

-- 
Sebasti?n Lara Menares
Ingenier?a Civil Electr?nica
Universidad de Concepci?n



From patrick.georgi at coresystems.de  Sat Sep 12 00:09:23 2009
From: patrick.georgi at coresystems.de (Patrick Georgi)
Date: Sat, 12 Sep 2009 00:09:23 +0200
Subject: [coreboot] cbfstool2 0.9
Message-ID: <1252706963.17126.20.camel@tetris>

Hi,

at http://www.coresystems.de/~patrick/cbfstool2-0.9.tar.bz2 you can find
a copy of my current work on improving the CBFS toolchain.

It's a drop-in replacement for cbfstool as provided in the coreboot
tree, with the following differences:
- no more mmap, nor fork/exec, improving portability
- locking a file to a specific location in the flash image works
- bootblock size is determined from the file size, the command line
argument is ignored (but expected for compatibility purposes)

Some parts of the code are clean rewrites, from the cbfstool README,
with tests using cbfstool, the cbfs_file handling (creation, splitting,
iterating) in particular.
Other parts of the code are mostly unchanged, like the ELF parsers that
handle stages and payloads.

I figured that it's more work to get rid of mmap and fork/exec and
implement working fixed-address files in the existing code base without
introducing lots of hacks then re-implementing parts of it.
I also tried to document a couple of the finer points, I hope I caught
all the important things.

There are a couple of things left to do:
1. The CodingStyle must be followed, right now it follows my own (with
>160 characters per lines, for example)
2. Licensing information is missing in lots of source files. Given that
some of them contain GPLv2 references, and the nature of that license,
all of the tarball is distributed under GPLv2. Still, I'll have to clean
it up.
3. There's no integration into the coreboot build system yet.
4. Some commands aren't implemented yet. This is not really a problem,
given that they touch functionality that is rather fragile in cbfstool.
Deleting files comes to mind.

It's supposed to be a drop-in replacement, meaning that I re-implemented
the behaviour of the CLI. It's hand-threaded spaghetti code now, and I'd
love to replace the command line format with something more getopt
compatible eventually.
I also didn't bother to free() all malloc()ed memory regions given that
the code survives a couple of milliseconds, before it ends itself.

One battle at a time.

Still, I think it's good enough to get some public exposure, maybe some
watchful eyes at code and behaviour.
The big new feature of this code is the capability to lock files to
fixed locations, which we'll need for a variety of things: I'm currently
working on moving the ROM stage (that does CAR and raminit) into CBFS,
and this project came into existence because I needed some way to put
code at defined places without cbfstool blowing up. Certain EC roms,
romstraps, and other auxilliary data of devices also must be located at
pre-defined places to make hardware happy.


Regards,
Patrick




From mylesgw at gmail.com  Sat Sep 12 00:41:48 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 11 Sep 2009 16:41:48 -0600
Subject: [coreboot] SMP Linux on QEMU
In-Reply-To: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
Message-ID: <2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>

On Thu, Sep 10, 2009 at 6:26 PM, Jen-Cheng(Tommy) Huang
<tommy24 at gatech.edu>wrote:

> Hi,
> I am using coreboot v3 with FILO.
> I specify "qemu -L . vd.img -smp 4".
> But I always see one cpu in /proc/cpuinfo.
> Then I tried if SMP works in v2.
> However, when I tried to boot, qemu showed the following error messages:
> (v3 works fine here)
>
> CBFS: follow chain: fff9b800 + 28 + 547d8 + align -> ffff0000
> CBFS:  Could not find file normal/coreboot_ram
> Jumping to image.
> qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0000
>
Have you modified it?  I just tried the latest from svn, and I don't get
that error.

Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090911/1972da9a/attachment.html>

From tommy24 at gatech.edu  Sat Sep 12 01:10:50 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Fri, 11 Sep 2009 16:10:50 -0700
Subject: [coreboot] SMP Linux on QEMU
In-Reply-To: <2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
Message-ID: <1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>

Thanks for the response.
No, I didn't modify it.The qemu version is 0.10.5.
coreboot version is the latest one.
And I used the method mentioned in
http://www.coreboot.org/QEMU_Build_Tutorial
<http://www.coreboot.org/QEMU_Build_Tutorial>I can build successfully. But
the resulting bios still crashed.
But I think even in v2, I still can't see multiple cpus in OS.
Since "-smp n" is only recognized by qemu, coreboot won't generate
corresponding MP table.
So Linux won't be able to see multiple cpus.
I am still trying how to make linux see multiple cpus if I use FILO.
Any information is appreciated.
Thanks.

Regards,
Tommy
On Fri, Sep 11, 2009 at 3:41 PM, Myles Watson <mylesgw at gmail.com> wrote:

>
>
> On Thu, Sep 10, 2009 at 6:26 PM, Jen-Cheng(Tommy) Huang <
> tommy24 at gatech.edu> wrote:
>
>> Hi,
>> I am using coreboot v3 with FILO.
>> I specify "qemu -L . vd.img -smp 4".
>> But I always see one cpu in /proc/cpuinfo.
>> Then I tried if SMP works in v2.
>> However, when I tried to boot, qemu showed the following error messages:
>> (v3 works fine here)
>>
>> CBFS: follow chain: fff9b800 + 28 + 547d8 + align -> ffff0000
>> CBFS:  Could not find file normal/coreboot_ram
>> Jumping to image.
>> qemu: fatal: Trying to execute code outside RAM or ROM at 0x000a0000
>>
> Have you modified it?  I just tried the latest from svn, and I don't get
> that error.
>
> Myles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090911/b6b55c4d/attachment.html>

From rminnich at gmail.com  Sat Sep 12 01:15:34 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 11 Sep 2009 16:15:34 -0700
Subject: [coreboot] SMP Linux on QEMU
In-Reply-To: <1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
	<1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
Message-ID: <13426df10909111615mff99e48oe4bc166e5afa30db@mail.gmail.com>

so we have a report of success and failure.

Let's compare:
1. distros
2. gcc toolchain (gcc -v  etc)
3. qemu versions

this could be just another toolchain problem.

ron



From tommy24 at gatech.edu  Sat Sep 12 01:41:36 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Fri, 11 Sep 2009 16:41:36 -0700
Subject: [coreboot]  SMP Linux on QEMU
In-Reply-To: <1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
	<1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
	<13426df10909111615mff99e48oe4bc166e5afa30db@mail.gmail.com>
	<1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
Message-ID: <1519b3fb0909111641p1aed40ebhf82fde0162d8156f@mail.gmail.com>

Thanks for the info.

coreboot v2 rev. 4629qemu 0.10.5
filo 0.6
gcc 4.2.4

running on Dual-Core AMD Opteron(tm) Processor 2220 SE
I will try to build it again later.
Thanks.

Tommy

On Fri, Sep 11, 2009 at 4:15 PM, ron minnich <rminnich at gmail.com> wrote:

> so we have a report of success and failure.
>
> Let's compare:
> 1. distros
> 2. gcc toolchain (gcc -v  etc)
> 3. qemu versions
>
> this could be just another toolchain problem.
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090911/9e856eff/attachment.html>

From tommy24 at gatech.edu  Sat Sep 12 01:41:36 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Fri, 11 Sep 2009 16:41:36 -0700
Subject: [coreboot]  SMP Linux on QEMU
In-Reply-To: <1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
	<1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
	<13426df10909111615mff99e48oe4bc166e5afa30db@mail.gmail.com>
	<1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
Message-ID: <1519b3fb0909111641p1aed40ebhf82fde0162d8156f@mail.gmail.com>

Thanks for the info.

coreboot v2 rev. 4629qemu 0.10.5
filo 0.6
gcc 4.2.4

running on Dual-Core AMD Opteron(tm) Processor 2220 SE
I will try to build it again later.
Thanks.

Tommy

On Fri, Sep 11, 2009 at 4:15 PM, ron minnich <rminnich at gmail.com> wrote:

> so we have a report of success and failure.
>
> Let's compare:
> 1. distros
> 2. gcc toolchain (gcc -v  etc)
> 3. qemu versions
>
> this could be just another toolchain problem.
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090911/9e856eff/attachment-0001.html>

From tommy24 at gatech.edu  Sat Sep 12 01:41:36 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Fri, 11 Sep 2009 16:41:36 -0700
Subject: [coreboot]  SMP Linux on QEMU
In-Reply-To: <1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
	<1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
	<13426df10909111615mff99e48oe4bc166e5afa30db@mail.gmail.com>
	<1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
Message-ID: <1519b3fb0909111641p1aed40ebhf82fde0162d8156f@mail.gmail.com>

Thanks for the info.

coreboot v2 rev. 4629qemu 0.10.5
filo 0.6
gcc 4.2.4

running on Dual-Core AMD Opteron(tm) Processor 2220 SE
I will try to build it again later.
Thanks.

Tommy

On Fri, Sep 11, 2009 at 4:15 PM, ron minnich <rminnich at gmail.com> wrote:

> so we have a report of success and failure.
>
> Let's compare:
> 1. distros
> 2. gcc toolchain (gcc -v  etc)
> 3. qemu versions
>
> this could be just another toolchain problem.
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090911/9e856eff/attachment-0002.html>

From tommy24 at gatech.edu  Sun Sep 13 10:10:47 2009
From: tommy24 at gatech.edu (Jen-Cheng(Tommy) Huang)
Date: Sun, 13 Sep 2009 01:10:47 -0700
Subject: [coreboot] QEMU BIOS question
Message-ID: <1519b3fb0909130110k143fc030se173af6d80af11de@mail.gmail.com>

Hi,

1. What is the difference between QEMU BIOS and the other coreboot BIOS
which can be flashed to ROM? I mean what functionalities QEMU lack or
incomplete compared to the others?

2. What is the major difference between QEMU coreboot BIOS and the original
QEMU BIOS?

High-level answers would be very helpful. I just want to know some basics.
Any response is very appreciated.
Thanks.

Regards,
Tommy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090913/3cf288c6/attachment.html>

From patrick at georgi-clan.de  Sun Sep 13 14:29:06 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Sun, 13 Sep 2009 14:29:06 +0200
Subject: [coreboot] cbfstool2 0.9.9
Message-ID: <1252844946.11115.4.camel@tetris>

Hi,

I got my TODO covered: the current cbfstool2 works (as cbfstool, that
"2" suffix is purely internal) as a drop-in replacement in the coreboot
tree, incl. makefiles to build it both for newconfig and kconfig style
builds.

The code should match the codingstyle and license headers are added, so
I think this is ready to go in.

You can find the tarball at
http://www.coresystems.de/~patrick/cbfstool2-0.9.9.tar.bz2

My change would also include a trivial change to newconfig, to only
create a $(obj)/cbfs directory, instead of $(obj)/cbfs/tools/lzma, as
this isn't necessary anymore.

The "svn diff" is quite messy, as I reused files that are sufficiently
similar using svn mv, and those changes aren't well expressed in diff
output.


That code is
Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>


Regards,
Patrick




From stepan at coresystems.de  Sun Sep 13 19:30:46 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 13 Sep 2009 19:30:46 +0200
Subject: [coreboot] cbfstool2 0.9.9
In-Reply-To: <1252844946.11115.4.camel@tetris>
References: <1252844946.11115.4.camel@tetris>
Message-ID: <4AAD2C46.2020501@coresystems.de>

Patrick Georgi wrote:
> Hi,
>
> I got my TODO covered: the current cbfstool2 works (as cbfstool, that
> "2" suffix is purely internal) as a drop-in replacement in the coreboot
> tree, incl. makefiles to build it both for newconfig and kconfig style
> builds.
>
> The code should match the codingstyle and license headers are added, so
> I think this is ready to go in.
>
> You can find the tarball at
> http://www.coresystems.de/~patrick/cbfstool2-0.9.9.tar.bz2
>
> My change would also include a trivial change to newconfig, to only
> create a $(obj)/cbfs directory, instead of $(obj)/cbfs/tools/lzma, as
> this isn't necessary anymore.
>
> The "svn diff" is quite messy, as I reused files that are sufficiently
> similar using svn mv, and those changes aren't well expressed in diff
> output.
>
>
> That code is
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   
Always glad to see additional reviews, but this update was really
necessary for future use cases of coreboot / CBFS.

Therefore
Acked-by: Stefan Reinauer <stepan at coresystems.de>



From eranshemi at gmail.com  Sun Sep 13 13:38:16 2009
From: eranshemi at gmail.com (eran shemi)
Date: Sun, 13 Sep 2009 14:38:16 +0300
Subject: [coreboot] hello coreboot
Message-ID: <753d54630909130438l3269cb40k7050087331294837@mail.gmail.com>

Hi coreboot

my name is eran and i want to now what is road map for supporting the Intel
atom core

and what version of coreboot bios will support Intel? 945GM + Intel? ICH7R
Chipset with Winbond W83627HF

Thanks,

Eran Shemi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090913/d50c7ed7/attachment.html>

From chriskindt at umbc.edu  Sun Sep 13 21:48:58 2009
From: chriskindt at umbc.edu (Chris Kindt)
Date: Sun, 13 Sep 2009 15:48:58 -0400
Subject: [coreboot] Geode LX VGA BIOS Patch
In-Reply-To: <20090909133345.GA5979@morn.localdomain>
References: <4A829320.4020606@umbc.edu> <4A943378.7010000@umbc.edu>
	<20090909133345.GA5979@morn.localdomain>
Message-ID: <4AAD4CAA.9050905@umbc.edu>

Kevin O'Connor wrote:
> As before, the main seabios patch looks good to me.  The "modehack"
> patch, of course, needs to be cleaned up before committing.  Are you
> still working on this?
> 
> -Kevin
> 

Yes, it is on my todo list. I was thinking about using a device
operations structure or macros to replace the "if(hw_type)"
statements. This might be overkill at the moment, however it would
be helpful for any future hardware specific expansion. I am lacking 
insight on what such a struct should be. The following example is 
crafted mostly to fix the current problems I am having.

struct videoDevice {
	int  (*present) (void);   /* check for existence */
	void (*enable) (int);     /* enable device/mode  */

	void (*pre_init) (void);
	void (*post_init) (void);
	void (*set_mode) (u8 mode);
	
	struct VideoParam_s *vga_param_table[];
	struct vgamode_s   *vga_mode_table[];

	void *hw_tables;
};

struct videoDevice geodelx = {
	.present = legacyio_check,
	.pre_init = geodelx_init,
	.post_init = geodelx_demo,
	.vga_param_table = lx_param_table,
	.vga_mode_table  = lx_mode_table,
};

struct videoDevice cirrus = {
	.pre_init = cirrus_init,
	.set_mode = cirrus_set_video_mode,
	.hw_tables = cirrus_modes,		
};

struct videoDevice vbe = {
	.present = vbe_has_vbe_display,
	.enable  = dispi_set_enable,
	.pre_init = vbe_init,
	.hw_tables = vbe_modes,
};


Let me know what you think and I can work on a patch,

Chris Kindt




From c-d.hailfinger.devel.2006 at gmx.net  Sun Sep 13 21:47:09 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Sun, 13 Sep 2009 21:47:09 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <4AA8A6C8.1020104@coresystems.de>
References: <4AA8A6C8.1020104@coresystems.de>
Message-ID: <4AAD4C3D.7030706@gmx.net>

On 10.09.2009 09:12, Stefan Reinauer wrote:
> in the progress of restructuring coreboot to work with CBFS, Kconfig and
> other new features, we basically broke the PowerPC boards. Since none of
> us has any of the supported hardware available for testing, and there is
> no real reason to use coreboot on PowerPC processors (there are fine
> bootloaders, like u-boot), we have been discussing to drop the PowerPC
> port completely if nobody is willing to step up and revive it.

I remember some people talking about MIPS64 support for coreboot, and
having _working_ PowerPC support in coreboot might help us to keep the
general coreboot design mostly architecture-independent. However, since
PowerPC support is essentially untestable without supported hardware, we
don't even know if it is (or was) broken and thus it serves no purpose
except holding development back.

Drop it unless someone has the hardware and the skills to at least keep
PowerPC support working with some help from others. In case someone
magically appears, we can still dig up the old code from svn.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Sun Sep 13 22:45:25 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Sun, 13 Sep 2009 22:45:25 +0200
Subject: [coreboot] [RFC] Drop PowerPC port
In-Reply-To: <4AAD4C3D.7030706@gmx.net>
References: <4AA8A6C8.1020104@coresystems.de> <4AAD4C3D.7030706@gmx.net>
Message-ID: <4AAD59E5.5070603@coresystems.de>

Carl-Daniel Hailfinger wrote:
> On 10.09.2009 09:12, Stefan Reinauer wrote:
>   
>> in the progress of restructuring coreboot to work with CBFS, Kconfig and
>> other new features, we basically broke the PowerPC boards. Since none of
>> us has any of the supported hardware available for testing, and there is
>> no real reason to use coreboot on PowerPC processors (there are fine
>> bootloaders, like u-boot), we have been discussing to drop the PowerPC
>> port completely if nobody is willing to step up and revive it.
>>     
>
> I remember some people talking about MIPS64 support for coreboot, and
> having _working_ PowerPC support in coreboot might help us to keep the
> general coreboot design mostly architecture-independent. 
Unfortunately, those people never even showed up on the mailing list to
ask questions, so I doubt it's ever going to happen.
> However, since
> PowerPC support is essentially untestable without supported hardware, we
> don't even know if it is (or was) broken and thus it serves no purpose
> except holding development back.
>   
It compiles, but it basically can not work as it is now, sadly.

> Drop it unless someone has the hardware and the skills to at least keep
> PowerPC support working with some help from others. In case someone
> magically appears, we can still dig up the old code from svn.
>
>   
Full ack.

Stefan





From marcj303 at gmail.com  Mon Sep 14 01:38:41 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Sun, 13 Sep 2009 17:38:41 -0600
Subject: [coreboot] [v2][patch] Remover waits for keyboard controller
	keyboard enable status
In-Reply-To: <534e5dc20908202204x30f96fbfme102ee61cfa2a981@mail.gmail.com>
References: <534e5dc20908202204x30f96fbfme102ee61cfa2a981@mail.gmail.com>
Message-ID: <534e5dc20909131638p61d4f0abpba068ba43d220f25@mail.gmail.com>

Ping.
Anyone want to test and ack this?

Marc

On Thu, Aug 20, 2009 at 11:04 PM, Marc Jones <marcj303 at gmail.com> wrote:
> The code was waiting for status that doesn't get returned.
>
> Stefan,
> This should be correct. Can you try it out on a few of your problem
> KBCs/keyboards?
>
>
> Signed-off-by: Marc Jones <marcj303 at gmail.com>
>
> -Marc
>
>
> --
> http://marcjonesconsulting.com
>



-- 
http://marcjonesconsulting.com



From marcj303 at gmail.com  Mon Sep 14 02:46:38 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Sun, 13 Sep 2009 18:46:38 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz>
	<20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
Message-ID: <534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>

On Tue, Sep 8, 2009 at 11:02 AM, Marc Jones <marcj303 at gmail.com> wrote:
> On Sun, Sep 6, 2009 at 4:32 PM, ron minnich<rminnich at gmail.com> wrote:
>> The way I see it the memory setup and SMP support in CAR are two very
>> different issues.
>
> This bug is totally my fault...
>
> Yes, ?Memory setup and SMP CAR are two different issues. The SMP setup
> happens during CAR is to setup microcode, HT and FIDVID prior to the
> PLL reset and memory setup.
>
> All the SMP PCI config space access should be MMIO. It is the first
> thing that is enabled in CPU init in set_pci_mmio_conf_reg().
>
> The bug is that I mixed a mem setup function in with SMP setup by
> using mctGetLogicalCPUID() which uses Get_NB32. As pointed out, the
> GET_NB32 is a cf8/cfc function. The mct code ported from AGESA assumes
> that it is running on the BSP only and uses cf8/cfc..... (historical
> k8 bug I think)
>
> I think that I should change the mct PCI config functions to call the
> coreboot pci_read_config32 functions that handle MMIO vs cfc/cf8
> nicely. This should future proof ?mct functions in CAR and a step
> toward SMP memory setup.
>
> Some of that mct code PCI config space code is a little funny (ok, a
> lot funny), so it will take a little care. I should be able work patch
> in a couple of days.


Here is a patch that fixes the cf8 config access. Not complicated like
I initially recalled.  Thanks to Ralf for pointing out the bug.

This needs testing. Anyone?

Signed-off-by: Marc Jones <marcj303 at gmail.com>

Thanks,
Marc

-- 
http://marcjonesconsulting.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_rw.patch
Type: text/x-diff
Size: 1034 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090913/d91e58c5/attachment.bin>

From ward at gnu.org  Mon Sep 14 04:13:43 2009
From: ward at gnu.org (Ward Vandewege)
Date: Sun, 13 Sep 2009 22:13:43 -0400
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
References: <20090905183301.GA12631@countzero.vandewege.net>
	<4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
Message-ID: <20090914021343.GA24166@countzero.vandewege.net>

On Sun, Sep 13, 2009 at 06:46:38PM -0600, Marc Jones wrote:
> Here is a patch that fixes the cf8 config access. Not complicated like
> I initially recalled.  Thanks to Ralf for pointing out the bug.
> 
> This needs testing. Anyone?

We've got a couple H8DME/fam10 boxes coming this week, so I should be able to
test this in a couple days. Will do as soon as we get the hardware.

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From svn at coreboot.org  Mon Sep 14 15:29:27 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 14 Sep 2009 15:29:27 +0200
Subject: [coreboot] [v2] r4630 - in trunk/coreboot-v2/util: cbfstool
	cbfstool/lzma newconfig
Message-ID: <mailman.3694.1355071617.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-14 15:29:27 +0200 (Mon, 14 Sep 2009)
New Revision: 4630

Added:
   trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c
   trunk/coreboot-v2/util/cbfstool/cbfs-mkstage.c
   trunk/coreboot-v2/util/cbfstool/cbfs.h
   trunk/coreboot-v2/util/cbfstool/cbfstool.c
   trunk/coreboot-v2/util/cbfstool/common.c
   trunk/coreboot-v2/util/cbfstool/common.h
   trunk/coreboot-v2/util/cbfstool/compress.c
   trunk/coreboot-v2/util/cbfstool/elf.h
   trunk/coreboot-v2/util/cbfstool/lzma/
Removed:
   trunk/coreboot-v2/util/cbfstool/TODO
   trunk/coreboot-v2/util/cbfstool/add.c
   trunk/coreboot-v2/util/cbfstool/bootblock.c
   trunk/coreboot-v2/util/cbfstool/cbfs.h
   trunk/coreboot-v2/util/cbfstool/cbfstool.c
   trunk/coreboot-v2/util/cbfstool/cbfstool.h
   trunk/coreboot-v2/util/cbfstool/create.c
   trunk/coreboot-v2/util/cbfstool/delete.c
   trunk/coreboot-v2/util/cbfstool/extract.c
   trunk/coreboot-v2/util/cbfstool/fs.c
   trunk/coreboot-v2/util/cbfstool/print.c
   trunk/coreboot-v2/util/cbfstool/resize.c
   trunk/coreboot-v2/util/cbfstool/tools/
   trunk/coreboot-v2/util/cbfstool/types.c
   trunk/coreboot-v2/util/cbfstool/util.c
Modified:
   trunk/coreboot-v2/util/cbfstool/Makefile
   trunk/coreboot-v2/util/cbfstool/Makefile.inc
   trunk/coreboot-v2/util/cbfstool/README
   trunk/coreboot-v2/util/newconfig/config.g
Log:
New cbfstool. Works without mmap or fork/exec and
supports fixed location files. Some parts are salvaged
from the pre-commit version (esp. stage and payload creation),
others are completely rewritten (eg. the main loop that handles
file addition)

Also adapt newconfig (we don't need cbfs/tools anymore) and fix
some minor issues in the cbfstool-README.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: trunk/coreboot-v2/util/cbfstool/Makefile
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,42 +1,51 @@
-#
-#
-#
-
 obj ?= $(shell pwd)
 
-COMMANDS=create.o bootblock.o delete.o extract.o add.o print.o resize.o
-OBJ=$(COMMANDS) cbfstool.o util.o fs.o
-INC=cbfstool.h cbfs.h
-
+HOSTCXX ?= g++
 HOSTCC ?= gcc
-HOSTCXX ?= g++
 
-CFLAGS=-g -Wall -W -Werror
+BINARY:=$(obj)/cbfstool
 
-DESTDIR ?= /usr/local/bin
+COMMON:=common.o compress.o minilzma.o
+COMMON+=LZMAEncoder.o LZInWindow.o
+COMMON+=RangeCoderBit.o StreamUtils.o
+COMMON+=OutBuffer.o Alloc.o CRC.o
+COMMON+=cbfs-mkstage.o cbfs-mkpayload.o cbfstool.o
 
-all: $(obj)/cbfstool $(obj)/tools/cbfs-mkpayload $(obj)/tools/cbfs-mkstage
+COMMON:=$(addprefix $(obj)/,$(COMMON))
 
-$(obj)/cbfstool: $(patsubst %,$(obj)/%,$(OBJ))
-	$(HOSTCC) -o $@ $(patsubst %,$(obj)/%,$(OBJ))
+$(obj)/%.o: %.c
+	$(HOSTCC) $(CFLAGS) -c -o $@ $<
 
-tobj = $(obj)/tools
-tsrc = $(shell pwd)/tools
+$(obj)/%.o: lzma/%.cc
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
 
-include $(tsrc)/Makefile
+$(obj)/%.o: lzma/C/7zip/Compress/LZMA/%.cpp
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
 
-$(obj)/%.o: %.c $(INC)
-	$(HOSTCC) $(CFLAGS) -c -o $@ $<
+$(obj)/%.o: lzma/C/7zip/Compress/LZ/%.cpp
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
 
-install: $(obj)/cbfstool $(obj)/tools/cbfs-mkpayload $(obj)/tools/cbfs-mkstage
-	@ install -d $(DESTDIR)
-	@ install -m 0755 $(obj)/cbfstool $(DESTDIR)/cbfstool
-	@ install -m 0755 $(obj)/tools/cbfs-mkstage $(DESTDIR)/cbfs-mkstage
-	@ install -m 0755 $(obj)/tools/cbfs-mkpayload $(DESTDIR)/cbfs-mkpayload
+$(obj)/%.o: lzma/C/7zip/Compress/RangeCoder/%.cpp
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
 
+$(obj)/%.o: lzma/C/7zip/Common/%.cpp
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
+
+$(obj)/%.o: lzma/C/Common/%.cpp
+	$(HOSTCXX) $(CXXFLAGS) -c -o $@ $<
+
+all: $(BINARY)
+
+clean:
+	rm -f $(COMMON) $(BINARY)
+
 tags: 
-	ctags *.[ch] */*.[ch]
+	ctags *.[ch]
 
-clean: tools-clean
-	rm -f $(patsubst %,$(obj)/%,$(OBJ)) $(obj)/cbfstool
+CXXFLAGS=-DCOMPACT -m32
+CFLAGS=-m32
+LDFLAGS=-m32
 
+$(obj)/cbfstool:$(COMMON)
+	$(HOSTCXX) $(LDFLAGS) -o $@ $^
+	strip $@

Modified: trunk/coreboot-v2/util/cbfstool/Makefile.inc
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-14 13:29:27 UTC (rev 4630)
@@ -2,34 +2,56 @@
 ifdef POST_EVALUATION
 
 cbfsobj :=
-# commands
-cbfsobj += create.o
-cbfsobj += bootblock.o
-cbfsobj += delete.o
-cbfsobj += extract.o 
-cbfsobj += add.o 
-cbfsobj += print.o
-cbfsobj += resize.o
-# main tool
+cbfsobj += common.o
+cbfsobj += compress.o
+cbfsobj += minilzma.o
+cbfsobj += LZMAEncoder.o
+cbfsobj += LZInWindow.o
+cbfsobj += RangeCoderBit.o
+cbfsobj += StreamUtils.o
+cbfsobj += OutBuffer.o
+cbfsobj += Alloc.o
+cbfsobj += CRC.o
+cbfsobj += cbfs-mkstage.o
+cbfsobj += cbfs-mkpayload.o
 cbfsobj += cbfstool.o
-cbfsobj += util.o
-cbfsobj += fs.o
 
-cbfsinc := cbfstool.h cbfs.h
+CBFSTOOLFLAGS=-m32 -DCOMPACT
 
 $(obj)/util/cbfstool:
 	mkdir -p $@
-	mkdir -p $@/tools/lzma
 
 $(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/%.c
 	printf "    HOSTCC     $(subst $(obj)/,,$(@))\n"
-	$(HOSTCC) $(HOSTCFLAGS) -c -o $@ $<
+	$(HOSTCC) $(CBFSTOOLFLAGS) $(HOSTCFLAGS) -c -o $@ $<
 
-$(obj)/util/cbfstool/cbfstool: $(obj)/util/cbfstool $(obj)/util/cbfstool/tools/cbfs-mkpayload $(obj)/util/cbfstool/tools/cbfs-mkstage $(addprefix $(obj)/util/cbfstool/,$(cbfsobj))
-	printf "    HOSTCC     $(subst $(obj)/,,$(@)) (link)\n"
-	$(HOSTCC) -o $@ $(addprefix $(obj)/util/cbfstool/,$(cbfsobj))
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/%.cc
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
 
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/C/7zip/Compress/LZMA/%.cpp
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
+
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/C/7zip/Compress/LZ/%.cpp
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
+
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/C/7zip/Compress/RangeCoder/%.cpp
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
+
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/C/7zip/Common/%.cpp
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
+
+$(obj)/util/cbfstool/%.o: $(top)/util/cbfstool/lzma/C/Common/%.cpp
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@))\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) $(HOSTCXXFLAGS) -c -o $@ $<
+
+$(obj)/util/cbfstool/cbfstool: $(obj)/util/cbfstool $(addprefix $(obj)/util/cbfstool/,$(cbfsobj))
+	printf "    HOSTCXX    $(subst $(obj)/,,$(@)) (link)\n"
+	$(HOSTCXX) $(CBFSTOOLFLAGS) -o $@ $(addprefix $(obj)/util/cbfstool/,$(cbfsobj))
+
 endif
 
-include $(top)/util/cbfstool/tools/Makefile.inc
-

Modified: trunk/coreboot-v2/util/cbfstool/README
===================================================================
--- trunk/coreboot-v2/util/cbfstool/README	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/README	2009-09-14 13:29:27 UTC (rev 4630)
@@ -100,7 +100,7 @@
 the ROM).  This is to allow for arbitrary space to be left at the beginning
 of the ROM for things like embedded controller firmware.
 
-'pad' rounds the header to 32 bits and reserves a little room for later use. 
+'pad' rounds the header to 32 bytes and reserves a little room for later use. 
 
 = Bootblock =
 The bootblock is a mandatory component in the ROM.  It is located in the
@@ -123,7 +123,7 @@
 
 Each CBFS component starts with a header:
 
-struct CBFS_file {
+struct cbfs_file {
         char magic[8];
         unsigned int len;
         unsigned int type;
@@ -335,24 +335,3 @@
 type is not necessary (such as when the name of the component is unique.
 i.e. option_table).  It is recommended that all components be assigned a
 unique type, but NULL can be used when the type does not matter.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-

Deleted: trunk/coreboot-v2/util/cbfstool/TODO
===================================================================
--- trunk/coreboot-v2/util/cbfstool/TODO	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/TODO	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,4 +0,0 @@
-Add interactive mode
-Add script mode (./cbfstool [ROM] -s script)
-Support compression for stages and payloads
-Add nrv2b

Deleted: trunk/coreboot-v2/util/cbfstool/add.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/add.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/add.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,364 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <ctype.h>
-#include <string.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <signal.h>
-#include <sys/stat.h>
-#include <sys/mman.h>
-#include <sys/wait.h>
-#include "cbfstool.h"
-
-#define MAX_PATH 255
-
-static int add_from_fd(struct rom *rom, const char *name, int type, int fd)
-{
-	unsigned char *buffer = malloc(16 * 1024);
-	unsigned char *ptr = buffer;
-
-	int size = 0;
-	int aloc = 16 * 1024;
-	int remain = 16 * 1024;
-	int ret;
-
-	if (buffer == NULL)
-		return -1;
-
-	while (1) {
-		ret = read(fd, ptr, remain);
-
-		if (ret <= 0)
-			break;
-
-		ptr += ret;
-		remain -= ret;
-		size += ret;
-
-		if (remain == 0) {
-			buffer = realloc(buffer, aloc + 16 * 1024);
-
-			if (buffer == NULL) {
-				ret = -1;
-				break;
-			}
-
-			ptr = buffer + size;
-
-			aloc += (16 * 1024);
-			remain = 16 * 1024;
-		}
-	}
-
-	if (ret == -1 || size == 0) {
-
-		if (buffer != NULL)
-			free(buffer);
-
-		return -1;
-	}
-
-	ret = rom_add(rom, name, buffer, 0, size, type);
-	free(buffer);
-
-	return ret;
-}
-
-int fork_tool_and_add(struct rom *rom, const char *tool, const char *input,
-		      const char *name, int type, int argc, char **argv)
-{
-	int output[2];
-	pid_t pid;
-	int ret;
-	int status;
-	char **toolargs;
-	int i;
-
-	/* Create the pipe */
-
-	if (pipe(output)) {
-		ERROR("Couldn't create a pipe: %m\n");
-		return -1;
-	}
-
-	toolargs = (char **)malloc((5 + argc) * sizeof(char *));
-
-	if (toolargs == NULL) {
-		ERROR("Unable to allocate memory: %m\n");
-		return -1;
-	}
-
-	toolargs[0] = (char *)tool;
-
-	/* these are args. So they need a - in front */
-	for (i = 0; i < argc; i++) {
-		/* I wish I had python */
-		char *c = malloc(strlen(argv[i])) + 2;
-		c[0] = '-';
-		strcpy(&c[1], argv[i]);
-		c[strlen(argv[i])+1] = 0;
-		toolargs[1 + i] = c;
-	}
-
-	toolargs[1 + argc] = "-o";
-	toolargs[2 + argc] = "-";
-	toolargs[3 + argc] = (char *)input;
-	toolargs[4 + argc] = NULL;
-
-	pid = fork();
-
-	if (pid == 0) {
-
-		/* Set up stdin/stdout for the child */
-
-		dup2(output[1], STDOUT_FILENO);
-		close(output[0]);
-
-		/* Execute the tool */
-		if (execv(tool, toolargs)) {
-			ERROR("Unable to execute %s: %m\n", tool);
-			exit(-1);
-		}
-
-		exit(0);
-	}
-
-	free(toolargs);
-
-	close(output[1]);
-
-	/* Read from the file */
-	ret = add_from_fd(rom, name, type, output[0]);
-
-	/* Reap the child */
-	waitpid(pid, &status, 0);
-
-	if (WIFSIGNALED(status)) {
-		kill(pid, WTERMSIG(status));
-		ERROR("Error while executing %s\n", tool);
-		return -1;
-	} else if (WEXITSTATUS(status) != 0) {
-		ERROR("Error while executing %s: %d\n", tool,
-		      (int)WEXITSTATUS(status));
-		return -1;
-	}
-
-	return ret;
-}
-
-static int add_blob(struct rom *rom, const char *filename,
-		    const char *name, unsigned long address, int type)
-{
-	void *ptr;
-	struct stat s;
-	int fd, ret;
-
-	if (!strcmp(filename, "-"))
-		return add_from_fd(rom, name, type, 0);
-
-	fd = open(filename, O_RDONLY);
-
-	if (fd == -1) {
-		ERROR("Could not open %s: %m\n", filename);
-		return -1;
-	}
-
-	if (fstat(fd, &s)) {
-		ERROR("Could not stat %s: %m\n", filename);
-		close(fd);
-		return -1;
-	}
-
-	ptr = mmap(0, s.st_size, PROT_READ, MAP_SHARED, fd, 0);
-
-	if (ptr == MAP_FAILED) {
-		ERROR("Unable to map %s: %m\n", filename);
-		close(fd);
-		return -1;
-	}
-
-	ret = rom_add(rom, name, ptr, address, s.st_size, type);
-
-	munmap(ptr, s.st_size);
-	close(fd);
-
-	return ret;
-}
-
-void add_usage(void)
-{
-	printf("add FILE NAME TYPE [base address]\tAdd a component\n");
-}
-
-void add_stage_usage(void)
-{
-	printf("add-stage FILE NAME [OPTIONS]\tAdd a stage to the ROM\n");
-}
-
-void add_payload_usage(void)
-{
-	printf
-	    ("add-payload FILE NAME [OPTIONS]\tAdd a payload to the ROM\n");
-}
-
-int select_component_type(char *s)
-{
-	int i = 0;
-	char *accepted_strings[] = {
-		"stage",
-		"payload",
-		"optionrom",
-		"deleted",
-		"free",
-	};
-	for (i=0; i < 5; i++)
-		if (!strcmp(s, accepted_strings[i]))
-			return i;
-	return -1;
-}
-
-int add_handler(struct rom *rom, int argc, char **argv)
-{
-	unsigned int type = CBFS_COMPONENT_NULL;
-	unsigned long address = 0;
-
-	if ((argc < 3) || (argc >  4)) {
-		add_usage();
-		return -1;
-	}
-
-	if (argc > 3) {
-		address = strtoul(argv[3], 0, 0);
-	}
-
-	if (!rom_exists(rom)) {
-		ERROR("You need to create the ROM before adding files to it\n");
-		return -1;
-	}
-
-	/* There are two ways to specify the type - a string or a number */
-
-	if (isdigit(*(argv[2])))
-		type = strtoul(argv[2], 0, 0);
-	else {
-		switch(select_component_type(argv[2])) {
-			case 0:
-				type = CBFS_COMPONENT_STAGE;
-				break;
-			case 1:
-				type = CBFS_COMPONENT_PAYLOAD;
-				break;
-			case 2:
-				type = CBFS_COMPONENT_OPTIONROM;
-				break;
-			case 3:
-				type = CBFS_COMPONENT_DELETED;
-				break;
-			case 4:
-				type = CBFS_COMPONENT_NULL;
-				break;
-			default:
-				ERROR("Unrecognized component type %s.\nValid options are: stage, payload, optionrom, deleted, free.\n", argv[2]);
-				return -1;
-		}
-	}
-
-	return add_blob(rom, argv[0], argv[1], address, type);
-}
-
-char *find_tool(char *tool)
-{
-	static char toolpath[MAX_PATH];
-	extern char cbfstool_bindir[];
-
-	snprintf(toolpath, MAX_PATH - 1, "tools/%s", tool);
-	if (!access(toolpath, X_OK))
-		return toolpath;
-
-	snprintf(toolpath, MAX_PATH - 1, "%s/tools/%s", cbfstool_bindir, tool);
-
-	if (!access(toolpath, X_OK))
-		return toolpath;
-
-	snprintf(toolpath, MAX_PATH - 1, "%s/%s", cbfstool_bindir, tool);
-
-	if (!access(toolpath, X_OK))
-		return toolpath;
-
-	strncpy(toolpath, tool, MAX_PATH - 1);
-	return toolpath;
-}
-
-/* Invoke the cbfs-mkpayload utility */
-
-int add_payload_handler(struct rom *rom, int argc, char **argv)
-{
-	if (argc < 2) {
-		add_payload_usage();
-		return -1;
-	}
-
-	/* Make sure the ROM exists */
-
-	if (!rom_exists(rom)) {
-		ERROR("You need to create the ROM before adding files to it\n");
-		return -1;
-	}
-
-	/* Check that the incoming file exists */
-
-	if (access(argv[0], R_OK)) {
-		ERROR("File %s does not exist\n", argv[0]);
-		return -1;
-	}
-
-	return fork_tool_and_add(rom, find_tool("cbfs-mkpayload"), argv[0],
-				 argv[1], CBFS_COMPONENT_PAYLOAD, argc - 2,
-				 argc > 2 ? &argv[2] : NULL);
-}
-
-/* Invoke the cbfs-mkstage utility */
-
-int add_stage_handler(struct rom *rom, int argc, char **argv)
-{
-	if (argc < 2) {
-		add_stage_usage();
-		return -1;
-	}
-
-	/* Make sure the ROM exists */
-
-	if (!rom_exists(rom)) {
-		ERROR("You need to create the ROM before adding files to it\n");
-		return -1;
-	}
-
-	/* Check that the incoming file exists */
-
-	if (access(argv[0], R_OK)) {
-		ERROR("File %s does not exist\n", argv[0]);
-		return -1;
-	}
-
-	return fork_tool_and_add(rom, find_tool("cbfs-mkstage"), argv[0],
-				 argv[1], CBFS_COMPONENT_STAGE, argc - 2,
-				 argc > 2 ? &argv[2] : NULL);
-}

Deleted: trunk/coreboot-v2/util/cbfstool/bootblock.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/bootblock.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/bootblock.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,38 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include "cbfstool.h"
-
-void bootblock_usage(void)
-{
-	printf("bootblock [FILE]\t\tAdd a bootblock to the ROM\n");
-}
-
-int bootblock_handler(struct rom *rom, int argc, char **argv)
-{
-	if (argc < 1) {
-		bootblock_usage();
-		return -1;
-	}
-
-	return add_bootblock(rom, argv[0]);
-}

Copied: trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/cbfs-mkpayload.c)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,194 @@
+/*
+ * cbfs-mkpayload
+ *
+ * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
+ *               2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include "elf.h"
+#include <fcntl.h>
+#include <getopt.h>
+#include <sys/stat.h>
+#include <arpa/inet.h>
+
+#include "common.h"
+#include "cbfs.h"
+
+int parse_elf_to_payload(unsigned char *input, unsigned char **output,
+			 comp_algo algo)
+{
+	Elf32_Phdr *phdr;
+	Elf32_Ehdr *ehdr;
+	Elf32_Shdr *shdr;
+	char *header;
+	char *strtab;
+	unsigned char *sptr;
+	int headers;
+	int segments = 1;
+	int isize = 0, osize = 0;
+	int doffset = 0;
+	struct cbfs_payload_segment *segs;
+	int i;
+
+	comp_func_ptr compress = compression_function(algo);
+	if (!compress)
+		return -1;
+
+	ehdr = (Elf32_Ehdr *) input;
+	headers = ehdr->e_phnum;
+	header = (char *)ehdr;
+
+	phdr = (Elf32_Phdr *) & (header[ehdr->e_phoff]);
+	shdr = (Elf32_Shdr *) & (header[ehdr->e_shoff]);
+
+	strtab = &header[shdr[ehdr->e_shstrndx].sh_offset];
+
+	/* Count the number of headers - look for the .notes.pinfo
+	 * section */
+
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		char *name;
+
+		if (i == ehdr->e_shstrndx)
+			continue;
+
+		if (shdr[i].sh_size == 0)
+			continue;
+
+		name = (char *)(strtab + shdr[i].sh_name);
+
+		if (!strcmp(name, ".note.pinfo"))
+			segments++;
+	}
+
+	/* Now, regular headers - we only care about PT_LOAD headers,
+	 * because thats what we're actually going to load
+	 */
+
+	for (i = 0; i < headers; i++) {
+		if (phdr[i].p_type != PT_LOAD)
+			continue;
+
+		/* Empty segments are never interesting */
+		if (phdr[i].p_memsz == 0)
+			continue;
+
+		isize += phdr[i].p_filesz;
+
+		segments++;
+	}
+
+	/* Allocate a block of memory to store the data in */
+
+	sptr =
+	    calloc((segments * sizeof(struct cbfs_payload_segment)) + isize, 1);
+	doffset = (segments * sizeof(struct cbfs_payload_segment));
+
+	if (sptr == NULL)
+		goto err;
+
+	segs = (struct cbfs_payload_segment *)sptr;
+	segments = 0;
+
+	for (i = 0; i < ehdr->e_shnum; i++) {
+		char *name;
+
+		if (i == ehdr->e_shstrndx)
+			continue;
+
+		if (shdr[i].sh_size == 0)
+			continue;
+
+		name = (char *)(strtab + shdr[i].sh_name);
+
+		if (!strcmp(name, ".note.pinfo")) {
+			segs[segments].type = PAYLOAD_SEGMENT_PARAMS;
+			segs[segments].load_addr = 0;
+			segs[segments].len = (unsigned int)shdr[i].sh_size;
+			segs[segments].offset = doffset;
+
+			memcpy((unsigned long *)(sptr + doffset),
+			       &header[shdr[i].sh_offset], shdr[i].sh_size);
+
+			doffset += segs[segments].len;
+			osize += segs[segments].len;
+
+			segments++;
+		}
+	}
+
+	for (i = 0; i < headers; i++) {
+		if (phdr[i].p_type != PT_LOAD)
+			continue;
+
+		if (phdr[i].p_memsz == 0)
+			continue;
+
+		if (phdr[i].p_filesz == 0) {
+			segs[segments].type = PAYLOAD_SEGMENT_BSS;
+			segs[segments].load_addr =
+			    (unsigned long long)htonl(phdr[i].p_paddr);
+			segs[segments].mem_len =
+			    (unsigned int)htonl(phdr[i].p_memsz);
+			segs[segments].offset = htonl(doffset);
+
+			segments++;
+			continue;
+		}
+
+		segs[segments].type = PAYLOAD_SEGMENT_DATA;
+		segs[segments].load_addr = (unsigned int)htonl(phdr[i].p_paddr);
+		segs[segments].mem_len = (unsigned int)htonl(phdr[i].p_memsz);
+		segs[segments].compression = htonl(algo);
+		segs[segments].offset = htonl(doffset);
+
+		int len;
+		compress((char *)&header[phdr[i].p_offset],
+			 phdr[i].p_filesz, (char *)(sptr + doffset), &len);
+		segs[segments].len = htonl(len);
+
+		/* If the compressed section is larger, then use the
+		   original stuff */
+
+		if ((unsigned int)len > phdr[i].p_filesz) {
+			segs[segments].compression = 0;
+			segs[segments].len = htonl(phdr[i].p_filesz);
+
+			memcpy((char *)(sptr + doffset),
+			       &header[phdr[i].p_offset], phdr[i].p_filesz);
+		}
+
+		doffset += ntohl(segs[segments].len);
+		osize += ntohl(segs[segments].len);
+
+		segments++;
+	}
+
+	segs[segments].type = PAYLOAD_SEGMENT_ENTRY;
+	segs[segments++].load_addr = (unsigned long long)htonl(ehdr->e_entry);
+
+	*output = sptr;
+
+	return (segments * sizeof(struct cbfs_payload_segment)) + osize;
+
+      err:
+	return -1;
+}


Property changes on: trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c
___________________________________________________________________
Added: svn:mergeinfo
   + 

Copied: trunk/coreboot-v2/util/cbfstool/cbfs-mkstage.c (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/cbfs-mkstage.c)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfs-mkstage.c	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/cbfs-mkstage.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,171 @@
+/*
+ * cbfs-mkstage
+ *
+ * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
+ *               2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include "elf.h"
+#include <fcntl.h>
+#include <getopt.h>
+#include <sys/stat.h>
+
+#include "common.h"
+#include "cbfs.h"
+
+unsigned int idemp(unsigned int x)
+{
+	return x;
+}
+
+unsigned int swap32(unsigned int x)
+{
+	return ((x >> 24) | ((x >> 8) & 0xff00) | ((x << 8) & 0xff0000) |
+		(x << 24));
+}
+
+unsigned int (*elf32_to_native) (unsigned int) = idemp;
+
+/* returns size of result, or -1 if error */
+int parse_elf_to_stage(unsigned char *input, unsigned char **output,
+		       comp_algo algo, uint32_t * location)
+{
+	Elf32_Phdr *phdr;
+	Elf32_Ehdr *ehdr = (Elf32_Ehdr *) input;
+	char *header, *buffer;
+	unsigned char *out;
+
+	int headers;
+	int i;
+	struct cbfs_stage *stage;
+	unsigned int data_start, data_end, mem_end;
+
+	int elf_bigendian = 0;
+	int host_bigendian = 0;
+
+	comp_func_ptr compress = compression_function(algo);
+	if (!compress)
+		return -1;
+
+	if (!iself(input)) {
+		fprintf(stderr, "E:  The incoming file is not an ELF\n");
+		return -1;
+	}
+
+	if (ehdr->e_ident[EI_DATA] == ELFDATA2MSB) {
+		elf_bigendian = 1;
+	}
+	char test[4] = "1234";
+	uint32_t inttest = *(uint32_t *) test;
+	if (inttest == 0x31323334) {
+		host_bigendian = 1;
+	}
+	if (elf_bigendian != host_bigendian) {
+		elf32_to_native = swap32;
+	}
+
+	headers = ehdr->e_phnum;
+	header = (char *)ehdr;
+
+	phdr = (Elf32_Phdr *) & header[elf32_to_native(ehdr->e_phoff)];
+
+	/* Now, regular headers - we only care about PT_LOAD headers,
+	 * because thats what we're actually going to load
+	 */
+
+	data_start = 0xFFFFFFFF;
+	data_end = 0;
+	mem_end = 0;
+
+	for (i = 0; i < headers; i++) {
+		unsigned int start, mend, rend;
+
+		if (elf32_to_native(phdr[i].p_type) != PT_LOAD)
+			continue;
+
+		/* Empty segments are never interesting */
+		if (elf32_to_native(phdr[i].p_memsz) == 0)
+			continue;
+
+		/* BSS */
+
+		start = elf32_to_native(phdr[i].p_paddr);
+
+		mend = start + elf32_to_native(phdr[i].p_memsz);
+		rend = start + elf32_to_native(phdr[i].p_filesz);
+
+		if (start < data_start)
+			data_start = start;
+
+		if (rend > data_end)
+			data_end = rend;
+
+		if (mend > mem_end)
+			mem_end = mend;
+	}
+
+	/* allocate an intermediate buffer for the data */
+	buffer = calloc(data_end - data_start, 1);
+
+	if (buffer == NULL) {
+		fprintf(stderr, "E: Unable to allocate memory: %m\n");
+		return -1;
+	}
+
+	/* Copy the file data into the buffer */
+
+	for (i = 0; i < headers; i++) {
+
+		if (elf32_to_native(phdr[i].p_type) != PT_LOAD)
+			continue;
+
+		if (elf32_to_native(phdr[i].p_memsz) == 0)
+			continue;
+
+		memcpy(buffer + (elf32_to_native(phdr[i].p_paddr) - data_start),
+		       &header[elf32_to_native(phdr[i].p_offset)],
+		       elf32_to_native(phdr[i].p_filesz));
+	}
+
+	/* Now make the output buffer */
+	out = calloc(sizeof(struct cbfs_stage) + data_end - data_start, 1);
+
+	if (out == NULL) {
+		fprintf(stderr, "E: Unable to allocate memory: %m\n");
+		return -1;
+	}
+
+	stage = (struct cbfs_stage *)out;
+
+	stage->load = data_start;
+	stage->memlen = mem_end - data_start;
+	stage->compression = algo;
+	stage->entry = ehdr->e_entry;
+
+	compress(buffer, data_end - data_start,
+		 (char *)(out + sizeof(struct cbfs_stage)), (int *)&stage->len);
+
+	*output = out;
+
+	if (*location)
+		*location -= sizeof(struct cbfs_stage);
+	return sizeof(struct cbfs_stage) + stage->len;
+}


Property changes on: trunk/coreboot-v2/util/cbfstool/cbfs-mkstage.c
___________________________________________________________________
Added: svn:mergeinfo
   + 

Deleted: trunk/coreboot-v2/util/cbfstool/cbfs.h
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfs.h	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/cbfs.h	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,139 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#ifndef _CBFS_H_
-#define _CBFS_H_
-
-/** These are standard values for the known compression
-    alogrithms that coreboot knows about for stages and
-    payloads.  Of course, other LAR users can use whatever
-    values they want, as long as they understand them. */
-
-#define CBFS_COMPRESS_NONE  0
-#define CBFS_COMPRESS_LZMA  1
-#define CBFS_COMPRESS_NRV2B 2
-
-/** These are standard component types for well known
-    components (i.e - those that coreboot needs to consume.
-    Users are welcome to use any other value for their
-    components */
-
-#define CBFS_COMPONENT_STAGE     0x10
-#define CBFS_COMPONENT_PAYLOAD   0x20
-#define CBFS_COMPONENT_OPTIONROM 0x30
-
-/* The deleted type is chosen to be a value
- * that can be written in a FLASH from all other
- * values. 
- */
-#define CBFS_COMPONENT_DELETED 0
-
-/* for all known FLASH, this value can be changed 
- * to all other values. This allows NULL files to be 
- * changed without a block erase
- */
-#define CBFS_COMPONENT_NULL 0xFFFFFFFF
-
-/** this is the master cbfs header - it need to be
-    located somewhere in the bootblock.  Where it
-    actually lives is up to coreboot. A pointer to
-    this header will live at 0xFFFFFFF4, so we can
-    easily find it. */
-
-#define HEADER_MAGIC 0x4F524243
-
-/* this is a version that gives the right answer in any endian-ness */
-#define VERSION1 0x31313131
-
-struct cbfs_header {
-	unsigned int magic;
-	unsigned int version; 
-	unsigned int romsize;
-	unsigned int bootblocksize;
-	unsigned int align;
-	unsigned int offset;
-	unsigned int pad[2];
-} __attribute__ ((packed));
-
-/** This is a component header - every entry in the CBFS
-    will have this header.
-
-    This is how the component is arranged in the ROM:
-
-    --------------   <- 0
-    component header 
-    --------------   <- sizeof(struct component)
-    component name
-    --------------   <- offset
-    data
-    ...
-    --------------   <- offset + len
-*/
-
-#define COMPONENT_MAGIC "LARCHIVE"
-
-struct cbfs_file {
-	char magic[8];
-	unsigned int len;
-	unsigned int type;
-	unsigned int checksum;
-	unsigned int offset;
-} __attribute__ ((packed));
-
-/*** Component sub-headers ***/
-
-/* Following are component sub-headers for the "standard"
-   component types */
-
-/** This is the sub-header for stage components.  Stages are
-    loaded by coreboot during the normal boot process */
-
-struct cbfs_stage {
-	unsigned int compression;  /** Compression type */
-	unsigned long long entry;  /** entry point */
-	unsigned long long load;   /** Where to load in memory */
-	unsigned int len;	   /** length of data to load */
-	unsigned int memlen;	   /** total length of object in memory */
-} __attribute__ ((packed));
-
-/** this is the sub-header for payload components.  Payloads
-    are loaded by coreboot at the end of the boot process */
-
-struct cbfs_payload_segment {
-	unsigned int type;
-	unsigned int compression;
-	unsigned int offset;
-	unsigned long long load_addr;
-	unsigned int len;
-	unsigned int mem_len;
-} __attribute__ ((packed));
-
-struct cbfs_payload {
-	struct cbfs_payload_segment segments;
-};
-
-#define PAYLOAD_SEGMENT_CODE   0x45444F43
-#define PAYLOAD_SEGMENT_DATA   0x41544144
-#define PAYLOAD_SEGMENT_BSS    0x20535342
-#define PAYLOAD_SEGMENT_PARAMS 0x41524150
-#define PAYLOAD_SEGMENT_ENTRY  0x52544E45
-
-#define CBFS_NAME(_c) (((unsigned char *) (_c)) + sizeof(struct cbfs_file))
-
-#endif

Added: trunk/coreboot-v2/util/cbfstool/cbfs.h
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfs.h	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/cbfs.h	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,88 @@
+/*
+ * Copyright (C) 2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdint.h>
+
+struct cbfs_header {
+	uint32_t magic;
+	uint32_t version;
+	uint32_t romsize;
+	uint32_t bootblocksize;
+	uint32_t align;
+	uint32_t offset;
+	uint32_t pad[2];
+} __attribute__ ((packed));
+
+struct cbfs_file {
+	char magic[8];
+	uint32_t len;
+	uint32_t type;
+	uint32_t checksum;
+	uint32_t offset;
+} __attribute__ ((packed));
+
+struct cbfs_stage {
+	unsigned int compression;
+	unsigned long long entry;
+	unsigned long long load;
+	unsigned int len;
+	unsigned int memlen;
+} __attribute__ ((packed));
+
+#define PAYLOAD_SEGMENT_CODE	0x45444F43
+#define PAYLOAD_SEGMENT_DATA	0x41544144
+#define PAYLOAD_SEGMENT_BSS	0x20535342
+#define PAYLOAD_SEGMENT_PARAMS	0x41524150
+#define PAYLOAD_SEGMENT_ENTRY	0x52544E45
+
+struct cbfs_payload_segment {
+	unsigned int type;
+	unsigned int compression;
+	unsigned int offset;
+	unsigned long long load_addr;
+	unsigned int len;
+	unsigned int mem_len;
+} __attribute__ ((packed));
+
+struct cbfs_payload {
+	struct cbfs_payload_segment segments;
+} __attribute__ ((packed));
+
+/** These are standard component types for well known
+    components (i.e - those that coreboot needs to consume.
+    Users are welcome to use any other value for their
+    components */
+
+#define CBFS_COMPONENT_STAGE     0x10
+#define CBFS_COMPONENT_PAYLOAD   0x20
+#define CBFS_COMPONENT_OPTIONROM 0x30
+
+/* The deleted type is chosen to be a value
+ * that can be written in a FLASH from all other
+ * values. 
+ */
+#define CBFS_COMPONENT_DELETED 0
+
+/* for all known FLASH, this value can be changed 
+ * to all other values. This allows NULL files to be 
+ * changed without a block erase
+ */
+#define CBFS_COMPONENT_NULL 0xFFFFFFFF
+
+int cbfs_file_header(uint32_t physaddr);
+struct cbfs_file *cbfs_create_empty_file(uint32_t physaddr, uint32_t size);

Deleted: trunk/coreboot-v2/util/cbfstool/cbfstool.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,161 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-/* v2 compat: First, assumes a 64K bootblock. 
- * cbfstool coreboot.rom create 0x80000 coreboot.strip 
- * cbfstool coreboot.rom add-payload /tmp/filo.elf payload 
- * cbfstool coreboot.rom extract new_filo.elf payload 
- * cbfstool coreboot.rom print
- */
-
-
-#include <string.h>
-#include <unistd.h>
-#include <libgen.h>
-#include <sys/mman.h>
-#include "cbfstool.h"
-
-extern int create_handler(struct rom *, int, char **);
-extern int bootblock_handler(struct rom *, int, char **);
-extern int print_handler(struct rom *, int, char **);
-extern int add_handler(struct rom *, int, char **);
-extern int extract_handler(struct rom *, int, char **);
-extern int delete_handler(struct rom *, int, char **);
-extern int resize_handler(struct rom *, int, char **);
-extern int add_payload_handler(struct rom *, int, char **);
-extern int add_stage_handler(struct rom *, int, char **);
-
-extern void create_usage(void);
-extern void bootblock_usage(void);
-extern void print_usage(void);
-extern void add_usage(void);
-extern void delete_usage(void);
-extern void extract_usage(void);
-extern void resize_usage(void);
-extern void add_payload_usage(void);
-extern void add_stage_usage(void);
-
-struct {
-	char *command;
-	int (*handler) (struct rom *, int, char **);
-	void (*help) (void);
-} commands[] = {
-	{
-	"add", add_handler, add_usage}, {
-	"add-payload", add_payload_handler, add_payload_usage}, {
-	"add-stage", add_stage_handler, add_stage_usage}, {
-	"bootblock", bootblock_handler, bootblock_usage}, {
-	"create", create_handler, create_usage}, {
-	"delete", delete_handler, delete_usage}, {
-	"extract", extract_handler, extract_usage}, {
-	"print", print_handler, print_usage}, {
-	"resize", resize_handler, resize_usage}, {
-"", NULL, NULL},};
-
-static struct rom rom;
-
-char cbfstool_bindir[255];
-
-void show_help(void)
-{
-	int i;
-
-	printf("cbfstool [OPTION] [[FILE] [COMMAND] [PARAMETERS]...\n");
-	printf("Apply COMMANDS with PARAMETERS to FILE.  If no COMMAND is\n");
-	printf("given, run in interactive mode\n\n");
-	printf("OPTIONs:\n");
-	printf(" -h\t\tDisplay this help message\n");
-	printf(" -C <dir>\tChange to the directory before operating\n\n");
-	printf("COMMANDs:\n");
-
-	for (i = 0; commands[i].handler != NULL; i++)
-		commands[i].help();
-}
-
-int main(int argc, char **argv)
-{
-	char *cdir = NULL;
-	char *rname;
-	char *cmd;
-	int ret = -1, i;
-
-	strncpy(cbfstool_bindir, dirname(argv[0]), 254);
-
-	while (1) {
-		signed ch = getopt(argc, argv, "hC:");
-		if (ch == -1)
-			break;
-		switch (ch) {
-		case 'h':
-			show_help();
-			return -1;
-		case 'C':
-			cdir = optarg;
-			break;
-		}
-	}
-
-	if (optind >= argc) {
-		show_help();
-		return -1;
-	}
-
-	if (cdir != NULL && chdir(cdir)) {
-		ERROR("Unable to switch to %s: %m\n", cdir);
-		return -1;
-	}
-
-	rname = argv[optind];
-	cmd = optind + 1 < argc ? argv[optind + 1] : NULL;
-
-	/* Open the ROM (if it exists) */
-	rom.name = (unsigned char *)strdup(rname);
-
-	if (!access(rname, F_OK)) {
-		if (open_rom(&rom, rname)) {
-			ERROR("Problem while reading the ROM\n");
-			return -1;
-		}
-	}
-
-	if (cmd) {
-		/* Process the incoming comand */
-
-		for (i = 0; commands[i].handler != NULL; i++) {
-			if (!strcmp(commands[i].command, cmd)) {
-				ret = commands[i].handler(&rom,
-							  argc - 3, &argv[3]);
-				goto leave;
-			}
-		}
-
-		ERROR("Command %s not valid\n", cmd);
-	} else {
-		printf("Interactive mode not ready yet!\n");
-	}
-
-leave:
-	if (rom.ptr != NULL && rom.ptr != MAP_FAILED)
-		munmap(rom.ptr, rom.size);
-
-	if (rom.fd > 0)
-		close(rom.fd);
-
-	return ret;
-}

Added: trunk/coreboot-v2/util/cbfstool/cbfstool.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfstool.c	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,133 @@
+/*
+ * cbfstool, CLI utility for CBFS file manipulation
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdint.h>
+#include "common.h"
+#include "cbfs.h"
+
+int main(int argc, char **argv)
+{
+	if (argc < 3) {
+		printf
+		    ("cbfstool: Management utility for CBFS formatted ROM images\n"
+		     "USAGE:\n" "cbfstool [-h]\n"
+		     "cbfstool FILE COMMAND [PARAMETERS]...\n\n" "OPTIONs:\n"
+		     " -h		Display this help message\n\n"
+		     "COMMANDs:\n"
+		     "add FILE NAME TYPE [base address]    Add a component\n"
+		     "add-payload FILE NAME [COMP] [base]  Add a payload to the ROM\n"
+		     "add-stage FILE NAME [COMP] [base]    Add a stage to the ROM\n"
+		     "create SIZE BSIZE BOOTBLOCK [ALIGN]  Create a ROM file\n"
+		     "print                                Show the contents of the ROM\n");
+		return 1;
+	}
+	char *romname = argv[1];
+	char *cmd = argv[2];
+
+	if (strcmp(cmd, "create") == 0) {
+		if (argc < 6) {
+			printf("not enough arguments to 'create'.\n");
+			return 1;
+		}
+		uint32_t size = strtoul(argv[3], NULL, 0);
+		/* ignore bootblock size. we use whatever we get and won't allocate any larger */
+		char *bootblock = argv[5];
+		uint32_t align = 0;
+		if (argc > 6)
+			align = strtoul(argv[6], NULL, 0);
+		return create_cbfs_image(romname, size, bootblock, align);
+	}
+
+	void *rom = loadrom(romname);
+
+	if (strcmp(cmd, "print") == 0) {
+		print_cbfs_directory(romname);
+		return 0;
+	}
+
+	if (argc < 5) {
+		printf("not enough arguments to '%s'.\n", cmd);
+		return 1;
+	}
+
+	void *filename = argv[3];
+	void *cbfsname = argv[4];
+
+	uint32_t filesize = 0;
+	void *filedata = loadfile(filename, &filesize, 0, SEEK_SET);
+
+	uint32_t base = 0;
+	void *cbfsfile;
+
+	if (strcmp(cmd, "add") == 0) {
+		if (argc < 6) {
+			printf("not enough arguments to 'add'.\n");
+			return 1;
+		}
+		uint32_t type;
+		if (intfiletype(argv[5]) != ((uint64_t) - 1))
+			type = intfiletype(argv[5]);
+		else
+			type = strtoul(argv[5], NULL, 0);
+		if (argc > 6) {
+			base = strtoul(argv[6], NULL, 0);
+		}
+		cbfsfile =
+		    create_cbfs_file(cbfsname, filedata, &filesize, type,
+				     &base);
+	}
+
+	if (strcmp(cmd, "add-payload") == 0) {
+		comp_algo algo = CBFS_COMPRESS_NONE;
+		if (argc > 5) {
+			if (argv[5][0] == 'l')
+				algo = CBFS_COMPRESS_LZMA;
+		}
+		if (argc > 6) {
+			base = strtoul(argv[6], NULL, 0);
+		}
+		unsigned char *payload;
+		filesize = parse_elf_to_payload(filedata, &payload, algo);
+		cbfsfile =
+		    create_cbfs_file(cbfsname, payload, &filesize,
+				     CBFS_COMPONENT_PAYLOAD, &base);
+	}
+
+	if (strcmp(cmd, "add-stage") == 0) {
+		comp_algo algo = CBFS_COMPRESS_NONE;
+		if (argc > 5) {
+			if (argv[5][0] == 'l')
+				algo = CBFS_COMPRESS_LZMA;
+		}
+		if (argc > 6) {
+			base = strtoul(argv[6], NULL, 0);
+		}
+		unsigned char *stage;
+		filesize = parse_elf_to_stage(filedata, &stage, algo, &base);
+		cbfsfile =
+		    create_cbfs_file(cbfsname, stage, &filesize,
+				     CBFS_COMPONENT_STAGE, &base);
+	}
+
+	add_file_to_cbfs(cbfsfile, filesize, base);
+	writerom(romname, rom, romsize);
+	return 0;
+}

Deleted: trunk/coreboot-v2/util/cbfstool/cbfstool.h
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfstool.h	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.h	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,87 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#ifndef _ROMTOOL_H_
-#define _ROMTOOL_H_
-
-#include <stdio.h>
-#include <arpa/inet.h>
-#include "cbfs.h"
-
-/* Definitions */
-
-/* Structures */
-
-struct rom {
-	unsigned char *name;
-	unsigned char *ptr;
-	/* this will *almost* *always* be 0-rom->size, save for some really 
-	 * misdesigned systems (which have existed)
-	 */
-	unsigned long rombase;
-
-	int fd;
-	int size;
-	int fssize;
-
-	struct cbfs_header *header;
-};
-
-/* Macros */
-
-#define ROM_OFFSET(_r, _c) ((unsigned int) ((unsigned char *) (_c) - (_r)->ptr))
-
-#define ROM_PTR(_r, _o) ((_r)->ptr + (_o))
-#define ROM_WRITEL(_r, _o, _v) do { *((unsigned int *) ROM_PTR((_r), (_o))) = (_v); } while(0)
-#define ROM_READL(_r, _o) *((unsigned int *) (ROM_PTR((_r), (_o))))
-
-#define ERROR(err, args...) fprintf(stderr, "(cbfstool) E: " err, ##args)
-#define WARN(err, args...) fprintf(stderr, "(cbfstool) W: " err, ##args)
-#define VERBOSE(str, args...) printf(str, ##args)
-
-#define TRUNCATE(_v, _a)  ( (_v) & ~( (_a) - 1 ) )
-#define ALIGN(_v, _a) ( ( (_v) + ( (_a) - 1 ) ) & ~( (_a) - 1 ) )
-
-/* Function prototypes */
-
-/* util.c */
-void flashinit(void *ptr, size_t len);
-int open_rom(struct rom *rom, const char *filename);
-int create_rom(struct rom *rom, const unsigned char *filename, int size,
-	       const char *bootblockname, int bootblocksize,
-	       int align);
-int size_and_open(const char *filename, unsigned int *size);
-int copy_from_fd(int fd, void *ptr, int size);
-int get_size(const char *size);
-int add_bootblock(struct rom *rom, const char *filename);
-
-/* fs.c */
-
-struct cbfs_file *rom_find(struct rom *rom, int offset);
-struct cbfs_file *rom_find_first(struct rom *);
-struct cbfs_file *rom_find_next(struct rom *, struct cbfs_file *);
-int rom_add(struct rom *rom, const char *name, void *, unsigned long address, int size, int type);
-int rom_set_header(struct rom *rom, struct cbfs_file *c, 
-	const char*name, int size, int type);
-int rom_extract(struct rom *rom, const char *name, void **buf, int *size);
-int rom_remove(struct rom *rom, const char *name);
-int rom_used_space(struct rom *rom);
-int rom_exists(struct rom *rom);
-
-#endif

Copied: trunk/coreboot-v2/util/cbfstool/common.c (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/common.c)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/common.c	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/common.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,298 @@
+/*
+ * common utility functions for cbfstool
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include "common.h"
+#include "cbfs.h"
+#include "elf.h"
+
+#define dprintf
+
+void *loadfile(const char *filename, uint32_t * romsize_p, void *content,
+	       int place)
+{
+	FILE *file = fopen(filename, "rb");
+	fseek(file, 0, SEEK_END);
+	*romsize_p = ftell(file);
+	fseek(file, 0, SEEK_SET);
+	if (!content)
+		content = malloc(*romsize_p);
+	else if (place == SEEK_END)
+		content -= *romsize_p;
+	if (!fread(content, *romsize_p, 1, file)) {
+		printf("failed to read %s\n", filename);
+		return NULL;
+	}
+	fclose(file);
+	return content;
+}
+
+struct cbfs_header *master_header;
+uint32_t phys_start, phys_end, align, romsize;
+void *offset;
+
+void recalculate_rom_geometry(void *romarea)
+{
+	offset = romarea + romsize - 0x100000000ULL;
+	master_header = (struct cbfs_header *)
+	    phys_to_virt(*((uint32_t *) phys_to_virt(0xfffffffc)));
+	phys_start = (0 - romsize + ntohl(master_header->offset)) & 0xffffffff;
+	phys_end =
+	    (0 - ntohl(master_header->bootblocksize) -
+	     sizeof(struct cbfs_header)) & 0xffffffff;
+	align = ntohl(master_header->align);
+}
+
+void *loadrom(const char *filename)
+{
+	void *romarea = loadfile(filename, &romsize, 0, SEEK_SET);
+	recalculate_rom_geometry(romarea);
+	return romarea;
+}
+
+void writerom(const char *filename, void *start, uint32_t size)
+{
+	FILE *file = fopen(filename, "wb");
+	fwrite(start, size, 1, file);
+	fclose(file);
+}
+
+int cbfs_file_header(uint32_t physaddr)
+{
+	/* maybe improve this test */
+	return (strncmp(phys_to_virt(physaddr), "LARCHIVE", 8) == 0);
+}
+
+struct cbfs_file *cbfs_create_empty_file(uint32_t physaddr, uint32_t size)
+{
+	struct cbfs_file *nextfile = (struct cbfs_file *)phys_to_virt(physaddr);
+	strncpy(nextfile->magic, "LARCHIVE", 8);
+	nextfile->len = htonl(size);
+	nextfile->type = htonl(0xffffffff);
+	nextfile->checksum = 0;	// FIXME?
+	nextfile->offset = htonl(sizeof(struct cbfs_file) + 16);
+	memset(((void *)nextfile) + sizeof(struct cbfs_file), 0, 16);
+	return nextfile;
+}
+
+int iself(unsigned char *input)
+{
+	Elf32_Ehdr *ehdr = (Elf32_Ehdr *) input;
+	return !memcmp(ehdr->e_ident, ELFMAG, 4);
+}
+
+struct filetypes_t {
+	uint32_t type;
+	const char *name;
+} filetypes[] = {
+	{CBFS_COMPONENT_STAGE, "stage"},
+	{CBFS_COMPONENT_PAYLOAD, "payload"},
+	{CBFS_COMPONENT_OPTIONROM, "optionrom"},
+	{CBFS_COMPONENT_DELETED, "deleted"},
+	{CBFS_COMPONENT_NULL, "null"}
+};
+
+const char *strfiletype(uint32_t number)
+{
+	int i;
+	for (i = 0; i < (sizeof(filetypes) / sizeof(struct filetypes_t)); i++)
+		if (filetypes[i].type == number)
+			return filetypes[i].name;
+	return "unknown";
+}
+
+uint64_t intfiletype(const char *name)
+{
+	int i;
+	for (i = 0; i < (sizeof(filetypes) / sizeof(struct filetypes_t)); i++)
+		if (strcmp(filetypes[i].name, name) == 0)
+			return filetypes[i].type;
+	return -1;
+}
+
+void print_cbfs_directory(const char *filename)
+{
+	printf
+	    ("%s: %d kB, bootblocksize %d, romsize %d, offset 0x%x\nAlignment: %d bytes\n\n",
+	     filename, romsize / 1024, ntohl(master_header->bootblocksize),
+	     romsize, ntohl(master_header->offset), align);
+	printf("%-30s %-10s %-12s Size\n", "Name", "Offset", "Type");
+	uint32_t current = phys_start;
+	while (current < phys_end) {
+		if (!cbfs_file_header(current)) {
+			current += align;
+			continue;
+		}
+		struct cbfs_file *thisfile =
+		    (struct cbfs_file *)phys_to_virt(current);
+		uint32_t length = ntohl(thisfile->len);
+		printf("%-30s 0x%-8x %-12s %d\n",
+		       (const char *)(phys_to_virt(current) +
+				      sizeof(struct cbfs_file)),
+		       current - phys_start, strfiletype(ntohl(thisfile->type)),
+		       length);
+		current =
+		    ALIGN(current + ntohl(thisfile->len) +
+			  ntohl(thisfile->offset), align);
+	}
+}
+
+int add_file_to_cbfs(void *content, uint32_t contentsize, uint32_t location)
+{
+	uint32_t current = phys_start;
+	while (current < phys_end) {
+		if (!cbfs_file_header(current)) {
+			current += align;
+			continue;
+		}
+		struct cbfs_file *thisfile =
+		    (struct cbfs_file *)phys_to_virt(current);
+		uint32_t length = ntohl(thisfile->len);
+
+		dprintf("at %x, %x bytes\n", current, length);
+		/* Is this a free chunk? */
+		if ((thisfile->type == CBFS_COMPONENT_DELETED)
+		    || (thisfile->type == CBFS_COMPONENT_NULL)) {
+			dprintf("null||deleted at %x, %x bytes\n", current,
+				length);
+			/* if this is the right size, and if specified, the right location, use it */
+			if ((contentsize <= length)
+			    && ((location == 0) || (current == location))) {
+				if (contentsize < length) {
+					dprintf
+					    ("this chunk is %x bytes, we need %x. create a new chunk at %x with %x bytes\n",
+					     length, contentsize,
+					     ALIGN(current + contentsize,
+						   align),
+					     length - contentsize);
+					uint32_t start =
+					    ALIGN(current + contentsize, align);
+					uint32_t size =
+					    current + ntohl(thisfile->offset)
+					    + length - start - 16 -
+					    sizeof(struct cbfs_file);
+					cbfs_create_empty_file(start, size);
+				}
+				dprintf("copying data\n");
+				memcpy(phys_to_virt(current), content,
+				       contentsize);
+				break;
+			}
+			if (location == 0)
+				continue;
+
+			/* CBFS has the constraint that the chain always moves up in memory. so once
+			   we're past the place we seek, we don't need to look any further */
+			if (current > location) {
+				printf
+				    ("the requested space is not available\n");
+				return 1;
+			}
+
+			/* Is the requested location inside the current chunk? */
+			if ((current < location)
+			    && ((location + contentsize) <= (current + length))) {
+				/* Split it up. In the next iteration the code will be at the right place. */
+				dprintf("split up. new length: %x\n",
+					location - current -
+					ntohl(thisfile->offset));
+				thisfile->len =
+				    htonl(location - current -
+					  ntohl(thisfile->offset));
+				struct cbfs_file *nextfile =
+				    cbfs_create_empty_file(location,
+							   length - (location -
+								     current));
+			}
+		}
+		current =
+		    ALIGN(current + ntohl(thisfile->len) +
+			  ntohl(thisfile->offset), align);
+	}
+	return 0;
+}
+
+/* returns new data block with cbfs_file header, suitable to dump into the ROM. location returns
+   the new location that points to the cbfs_file header */
+void *create_cbfs_file(const char *filename, void *data, uint32_t * datasize,
+		       uint32_t type, uint32_t * location)
+{
+	uint32_t filename_len = ALIGN(strlen(filename) + 1, 16);
+	uint32_t headersize = sizeof(struct cbfs_file) + filename_len;
+	if ((location != 0) && (*location != 0)) {
+		uint32_t offset = *location % align;
+		/* If offset >= (headersize % align), we can stuff the header into the offset.
+		   Otherwise the header has to be aligned itself, and put before the offset data */
+		if (offset >= (headersize % align)) {
+			offset -= (headersize % align);
+		} else {
+			offset += align - (headersize % align);
+		}
+		headersize += offset;
+		*location -= headersize;
+	}
+	void *newdata = malloc(*datasize + headersize);
+	struct cbfs_file *nextfile = (struct cbfs_file *)newdata;
+	strncpy(nextfile->magic, "LARCHIVE", 8);
+	nextfile->len = htonl(*datasize);
+	nextfile->type = htonl(type);
+	nextfile->checksum = 0;	// FIXME?
+	nextfile->offset = htonl(headersize);
+	strcpy(newdata + sizeof(struct cbfs_file), filename);
+	memcpy(newdata + headersize, data, *datasize);
+	*datasize += headersize;
+	return newdata;
+}
+
+int create_cbfs_image(const char *romfile, uint32_t _romsize,
+		      const char *bootblock, uint32_t align)
+{
+	romsize = _romsize;
+	unsigned char *romarea = malloc(romsize);
+	memset(romarea, 0xff, romsize);
+	recalculate_rom_geometry(romarea);
+
+	if (align == 0)
+		align = 64;
+
+	uint32_t bootblocksize = 0;
+	loadfile(bootblock, &bootblocksize, romarea + romsize, SEEK_END);
+	struct cbfs_header *master_header =
+	    (struct cbfs_header *)(romarea + romsize - bootblocksize -
+				   sizeof(struct cbfs_header));
+	master_header->magic = ntohl(0x4f524243);
+	master_header->version = ntohl(0x31313131);
+	master_header->romsize = htonl(romsize);
+	master_header->bootblocksize = htonl(bootblocksize);
+	master_header->align = htonl(align);
+	master_header->offset = htonl(0);
+	((uint32_t *) phys_to_virt(0xfffffffc))[0] =
+	    virt_to_phys(master_header);
+	struct cbfs_file *one_empty_file =
+	    cbfs_create_empty_file((0 - romsize) & 0xffffffff,
+				   romsize - bootblocksize -
+				   sizeof(struct cbfs_header) -
+				   sizeof(struct cbfs_file) - 16);
+
+	writerom(romfile, romarea, romsize);
+	return 0;
+}


Property changes on: trunk/coreboot-v2/util/cbfstool/common.c
___________________________________________________________________
Added: svn:mergeinfo
   + 

Copied: trunk/coreboot-v2/util/cbfstool/common.h (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/common.h)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/common.h	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/common.h	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,63 @@
+/*
+ * Copyright (C) 2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <stdint.h>
+
+extern void *offset;
+extern struct cbfs_header *master_header;
+extern uint32_t phys_start, phys_end, align, romsize;
+
+static void *phys_to_virt(uint32_t addr)
+{
+	return offset + addr;
+}
+
+static uint32_t virt_to_phys(void *addr)
+{
+	return (long)(addr - offset) & 0xffffffff;
+}
+
+#define ALIGN(val, by) (((val) + (by)-1)&~((by)-1))
+
+void *loadfile(const char *filename, uint32_t * romsize_p, void *content,
+	       int place);
+void *loadrom(const char *filename);
+void writerom(const char *filename, void *start, uint32_t size);
+
+int iself(unsigned char *input);
+
+typedef void (*comp_func_ptr) (char *, int, char *, int *);
+typedef enum { CBFS_COMPRESS_NONE = 0, CBFS_COMPRESS_LZMA = 1 } comp_algo;
+
+comp_func_ptr compression_function(comp_algo algo);
+
+uint64_t intfiletype(const char *name);
+
+int parse_elf_to_payload(unsigned char *input, unsigned char **output,
+			 comp_algo algo);
+int parse_elf_to_stage(unsigned char *input, unsigned char **output,
+		       comp_algo algo, uint32_t * location);
+
+void *create_cbfs_file(const char *filename, void *data, uint32_t * datasize,
+		       uint32_t type, uint32_t * location);
+
+int create_cbfs_image(const char *romfile, uint32_t romsize,
+		      const char *bootblock, uint32_t align);
+
+int add_file_to_cbfs(void *content, uint32_t contentsize, uint32_t location);
+void print_cbfs_directory(const char *filename);


Property changes on: trunk/coreboot-v2/util/cbfstool/common.h
___________________________________________________________________
Added: svn:mergeinfo
   + 

Copied: trunk/coreboot-v2/util/cbfstool/compress.c (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/compress.c)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/compress.c	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/compress.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,57 @@
+/*
+ * compression handling for cbfstool
+ *
+ * Copyright (C) 2009 coresystems GmbH
+ *                 written by Patrick Georgi <patrick.georgi at coresystems.de>
+ *
+ * Adapted from code
+ * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>, released
+ * under identical license terms
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
+ */
+
+#include <string.h>
+#include <stdio.h>
+#include "common.h"
+
+extern void do_lzma_compress(char *in, int in_len, char *out, int *out_len);
+
+void lzma_compress(char *in, int in_len, char *out, int *out_len)
+{
+	do_lzma_compress(in, in_len, out, out_len);
+}
+
+void none_compress(char *in, int in_len, char *out, int *out_len)
+{
+	memcpy(out, in, in_len);
+	*out_len = in_len;
+}
+
+comp_func_ptr compression_function(comp_algo algo)
+{
+	comp_func_ptr compress;
+	switch (algo) {
+	case CBFS_COMPRESS_NONE:
+		compress = none_compress;
+		break;
+	case CBFS_COMPRESS_LZMA:
+		compress = lzma_compress;
+		break;
+	default:
+		fprintf(stderr, "E: Unknown compression algorithm %d!\n", algo);
+		return NULL;
+	}
+	return compress;
+}


Property changes on: trunk/coreboot-v2/util/cbfstool/compress.c
___________________________________________________________________
Added: svn:mergeinfo
   + 

Deleted: trunk/coreboot-v2/util/cbfstool/create.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/create.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/create.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,65 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include "cbfstool.h"
-
-void create_usage(void)
-{
-	printf("create SIZE BOOTBLOCKSIZE BOOTBLOCK [ALIGN]\tCreate a ROM file\n");
-}
-
-int create_handler(struct rom *rom, int argc, char **argv)
-{
-	int align = 16, size;
-	char *bootblock = NULL;
-	int bootblocksize;
-
-	if (argc < 3) {
-		create_usage();
-		return -1;
-	}
-
-	size = get_size(argv[0]);
-
-	bootblocksize = get_size(argv[1]);
-
-	bootblock = argv[2];
-
-	if (argc >= 4) {
-		align = strtoul(argv[3], NULL, 0);
-	}
-
-	if (size < bootblocksize) {
-		ERROR("Cannot create a rom %d smaller then bootblock size %d\n", size, bootblocksize);
-		return -1;
-	}
-
-	if (align == 0) {
-		ERROR("Cannot create with an align size of 0\n");
-		return -1;
-	}
-
-	if (create_rom(rom, rom->name, size, bootblock, bootblocksize, align))
-		return -1;
-
-	return 0;
-}

Deleted: trunk/coreboot-v2/util/cbfstool/delete.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/delete.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/delete.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,44 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <ctype.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include "cbfstool.h"
-
-void delete_usage(void)
-{
-	printf("delete [NAME] ...\t\tDelete a component\n");
-}
-
-int delete_handler(struct rom *rom, int argc, char **argv)
-{
-	int i;
-	int ret = 0;
-
-	if (argc < 1) {
-		delete_usage();
-		return -1;
-	}
-
-	for (i = 0; i < argc; i++)
-		ret |= rom_remove(rom, argv[i]);
-
-	return ret;
-}

Copied: trunk/coreboot-v2/util/cbfstool/elf.h (from rev 4629, trunk/coreboot-v2/util/cbfstool/tools/elf.h)
===================================================================
--- trunk/coreboot-v2/util/cbfstool/elf.h	                        (rev 0)
+++ trunk/coreboot-v2/util/cbfstool/elf.h	2009-09-14 13:29:27 UTC (rev 4630)
@@ -0,0 +1,2637 @@
+/* This file defines standard ELF types, structures, and macros.
+   Copyright (C) 1995-2003,2004,2005,2006,2007 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#ifndef _ELF_H
+#define	_ELF_H 1
+
+#include <stdint.h>
+
+/* Type for a 16-bit quantity.  */
+typedef uint16_t Elf32_Half;
+typedef uint16_t Elf64_Half;
+
+/* Types for signed and unsigned 32-bit quantities.  */
+typedef uint32_t Elf32_Word;
+typedef	int32_t  Elf32_Sword;
+typedef uint32_t Elf64_Word;
+typedef	int32_t  Elf64_Sword;
+
+/* Types for signed and unsigned 64-bit quantities.  */
+typedef uint64_t Elf32_Xword;
+typedef	int64_t  Elf32_Sxword;
+typedef uint64_t Elf64_Xword;
+typedef	int64_t  Elf64_Sxword;
+
+/* Type of addresses.  */
+typedef uint32_t Elf32_Addr;
+typedef uint64_t Elf64_Addr;
+
+/* Type of file offsets.  */
+typedef uint32_t Elf32_Off;
+typedef uint64_t Elf64_Off;
+
+/* Type for section indices, which are 16-bit quantities.  */
+typedef uint16_t Elf32_Section;
+typedef uint16_t Elf64_Section;
+
+/* Type for version symbol information.  */
+typedef Elf32_Half Elf32_Versym;
+typedef Elf64_Half Elf64_Versym;
+
+
+/* The ELF file header.  This appears at the start of every ELF file.  */
+
+#define EI_NIDENT (16)
+
+typedef struct
+{
+  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
+  Elf32_Half	e_type;			/* Object file type */
+  Elf32_Half	e_machine;		/* Architecture */
+  Elf32_Word	e_version;		/* Object file version */
+  Elf32_Addr	e_entry;		/* Entry point virtual address */
+  Elf32_Off	e_phoff;		/* Program header table file offset */
+  Elf32_Off	e_shoff;		/* Section header table file offset */
+  Elf32_Word	e_flags;		/* Processor-specific flags */
+  Elf32_Half	e_ehsize;		/* ELF header size in bytes */
+  Elf32_Half	e_phentsize;		/* Program header table entry size */
+  Elf32_Half	e_phnum;		/* Program header table entry count */
+  Elf32_Half	e_shentsize;		/* Section header table entry size */
+  Elf32_Half	e_shnum;		/* Section header table entry count */
+  Elf32_Half	e_shstrndx;		/* Section header string table index */
+} Elf32_Ehdr;
+
+typedef struct
+{
+  unsigned char	e_ident[EI_NIDENT];	/* Magic number and other info */
+  Elf64_Half	e_type;			/* Object file type */
+  Elf64_Half	e_machine;		/* Architecture */
+  Elf64_Word	e_version;		/* Object file version */
+  Elf64_Addr	e_entry;		/* Entry point virtual address */
+  Elf64_Off	e_phoff;		/* Program header table file offset */
+  Elf64_Off	e_shoff;		/* Section header table file offset */
+  Elf64_Word	e_flags;		/* Processor-specific flags */
+  Elf64_Half	e_ehsize;		/* ELF header size in bytes */
+  Elf64_Half	e_phentsize;		/* Program header table entry size */
+  Elf64_Half	e_phnum;		/* Program header table entry count */
+  Elf64_Half	e_shentsize;		/* Section header table entry size */
+  Elf64_Half	e_shnum;		/* Section header table entry count */
+  Elf64_Half	e_shstrndx;		/* Section header string table index */
+} Elf64_Ehdr;
+
+/* Fields in the e_ident array.  The EI_* macros are indices into the
+   array.  The macros under each EI_* macro are the values the byte
+   may have.  */
+
+#define EI_MAG0		0		/* File identification byte 0 index */
+#define ELFMAG0		0x7f		/* Magic number byte 0 */
+
+#define EI_MAG1		1		/* File identification byte 1 index */
+#define ELFMAG1		'E'		/* Magic number byte 1 */
+
+#define EI_MAG2		2		/* File identification byte 2 index */
+#define ELFMAG2		'L'		/* Magic number byte 2 */
+
+#define EI_MAG3		3		/* File identification byte 3 index */
+#define ELFMAG3		'F'		/* Magic number byte 3 */
+
+/* Conglomeration of the identification bytes, for easy testing as a word.  */
+#define	ELFMAG		"\177ELF"
+#define	SELFMAG		4
+
+#define EI_CLASS	4		/* File class byte index */
+#define ELFCLASSNONE	0		/* Invalid class */
+#define ELFCLASS32	1		/* 32-bit objects */
+#define ELFCLASS64	2		/* 64-bit objects */
+#define ELFCLASSNUM	3
+
+#define EI_DATA		5		/* Data encoding byte index */
+#define ELFDATANONE	0		/* Invalid data encoding */
+#define ELFDATA2LSB	1		/* 2's complement, little endian */
+#define ELFDATA2MSB	2		/* 2's complement, big endian */
+#define ELFDATANUM	3
+
+#define EI_VERSION	6		/* File version byte index */
+					/* Value must be EV_CURRENT */
+
+#define EI_OSABI	7		/* OS ABI identification */
+#define ELFOSABI_NONE		0	/* UNIX System V ABI */
+#define ELFOSABI_SYSV		0	/* Alias.  */
+#define ELFOSABI_HPUX		1	/* HP-UX */
+#define ELFOSABI_NETBSD		2	/* NetBSD.  */
+#define ELFOSABI_LINUX		3	/* Linux.  */
+#define ELFOSABI_SOLARIS	6	/* Sun Solaris.  */
+#define ELFOSABI_AIX		7	/* IBM AIX.  */
+#define ELFOSABI_IRIX		8	/* SGI Irix.  */
+#define ELFOSABI_FREEBSD	9	/* FreeBSD.  */
+#define ELFOSABI_TRU64		10	/* Compaq TRU64 UNIX.  */
+#define ELFOSABI_MODESTO	11	/* Novell Modesto.  */
+#define ELFOSABI_OPENBSD	12	/* OpenBSD.  */
+#define ELFOSABI_ARM		97	/* ARM */
+#define ELFOSABI_STANDALONE	255	/* Standalone (embedded) application */
+
+#define EI_ABIVERSION	8		/* ABI version */
+
+#define EI_PAD		9		/* Byte index of padding bytes */
+
+/* Legal values for e_type (object file type).  */
+
+#define ET_NONE		0		/* No file type */
+#define ET_REL		1		/* Relocatable file */
+#define ET_EXEC		2		/* Executable file */
+#define ET_DYN		3		/* Shared object file */
+#define ET_CORE		4		/* Core file */
+#define	ET_NUM		5		/* Number of defined types */
+#define ET_LOOS		0xfe00		/* OS-specific range start */
+#define ET_HIOS		0xfeff		/* OS-specific range end */
+#define ET_LOPROC	0xff00		/* Processor-specific range start */
+#define ET_HIPROC	0xffff		/* Processor-specific range end */
+
+/* Legal values for e_machine (architecture).  */
+
+#define EM_NONE		 0		/* No machine */
+#define EM_M32		 1		/* AT&T WE 32100 */
+#define EM_SPARC	 2		/* SUN SPARC */
+#define EM_386		 3		/* Intel 80386 */
+#define EM_68K		 4		/* Motorola m68k family */
+#define EM_88K		 5		/* Motorola m88k family */
+#define EM_860		 7		/* Intel 80860 */
+#define EM_MIPS		 8		/* MIPS R3000 big-endian */
+#define EM_S370		 9		/* IBM System/370 */
+#define EM_MIPS_RS3_LE	10		/* MIPS R3000 little-endian */
+
+#define EM_PARISC	15		/* HPPA */
+#define EM_VPP500	17		/* Fujitsu VPP500 */
+#define EM_SPARC32PLUS	18		/* Sun's "v8plus" */
+#define EM_960		19		/* Intel 80960 */
+#define EM_PPC		20		/* PowerPC */
+#define EM_PPC64	21		/* PowerPC 64-bit */
+#define EM_S390		22		/* IBM S390 */
+
+#define EM_V800		36		/* NEC V800 series */
+#define EM_FR20		37		/* Fujitsu FR20 */
+#define EM_RH32		38		/* TRW RH-32 */
+#define EM_RCE		39		/* Motorola RCE */
+#define EM_ARM		40		/* ARM */
+#define EM_FAKE_ALPHA	41		/* Digital Alpha */
+#define EM_SH		42		/* Hitachi SH */
+#define EM_SPARCV9	43		/* SPARC v9 64-bit */
+#define EM_TRICORE	44		/* Siemens Tricore */
+#define EM_ARC		45		/* Argonaut RISC Core */
+#define EM_H8_300	46		/* Hitachi H8/300 */
+#define EM_H8_300H	47		/* Hitachi H8/300H */
+#define EM_H8S		48		/* Hitachi H8S */
+#define EM_H8_500	49		/* Hitachi H8/500 */
+#define EM_IA_64	50		/* Intel Merced */
+#define EM_MIPS_X	51		/* Stanford MIPS-X */
+#define EM_COLDFIRE	52		/* Motorola Coldfire */
+#define EM_68HC12	53		/* Motorola M68HC12 */
+#define EM_MMA		54		/* Fujitsu MMA Multimedia Accelerator*/
+#define EM_PCP		55		/* Siemens PCP */
+#define EM_NCPU		56		/* Sony nCPU embeeded RISC */
+#define EM_NDR1		57		/* Denso NDR1 microprocessor */
+#define EM_STARCORE	58		/* Motorola Start*Core processor */
+#define EM_ME16		59		/* Toyota ME16 processor */
+#define EM_ST100	60		/* STMicroelectronic ST100 processor */
+#define EM_TINYJ	61		/* Advanced Logic Corp. Tinyj emb.fam*/
+#define EM_X86_64	62		/* AMD x86-64 architecture */
+#define EM_PDSP		63		/* Sony DSP Processor */
+
+#define EM_FX66		66		/* Siemens FX66 microcontroller */
+#define EM_ST9PLUS	67		/* STMicroelectronics ST9+ 8/16 mc */
+#define EM_ST7		68		/* STmicroelectronics ST7 8 bit mc */
+#define EM_68HC16	69		/* Motorola MC68HC16 microcontroller */
+#define EM_68HC11	70		/* Motorola MC68HC11 microcontroller */
+#define EM_68HC08	71		/* Motorola MC68HC08 microcontroller */
+#define EM_68HC05	72		/* Motorola MC68HC05 microcontroller */
+#define EM_SVX		73		/* Silicon Graphics SVx */
+#define EM_ST19		74		/* STMicroelectronics ST19 8 bit mc */
+#define EM_VAX		75		/* Digital VAX */
+#define EM_CRIS		76		/* Axis Communications 32-bit embedded processor */
+#define EM_JAVELIN	77		/* Infineon Technologies 32-bit embedded processor */
+#define EM_FIREPATH	78		/* Element 14 64-bit DSP Processor */
+#define EM_ZSP		79		/* LSI Logic 16-bit DSP Processor */
+#define EM_MMIX		80		/* Donald Knuth's educational 64-bit processor */
+#define EM_HUANY	81		/* Harvard University machine-independent object files */
+#define EM_PRISM	82		/* SiTera Prism */
+#define EM_AVR		83		/* Atmel AVR 8-bit microcontroller */
+#define EM_FR30		84		/* Fujitsu FR30 */
+#define EM_D10V		85		/* Mitsubishi D10V */
+#define EM_D30V		86		/* Mitsubishi D30V */
+#define EM_V850		87		/* NEC v850 */
+#define EM_M32R		88		/* Mitsubishi M32R */
+#define EM_MN10300	89		/* Matsushita MN10300 */
+#define EM_MN10200	90		/* Matsushita MN10200 */
+#define EM_PJ		91		/* picoJava */
+#define EM_OPENRISC	92		/* OpenRISC 32-bit embedded processor */
+#define EM_ARC_A5	93		/* ARC Cores Tangent-A5 */
+#define EM_XTENSA	94		/* Tensilica Xtensa Architecture */
+#define EM_NUM		95
+
+/* If it is necessary to assign new unofficial EM_* values, please
+   pick large random numbers (0x8523, 0xa7f2, etc.) to minimize the
+   chances of collision with official or non-GNU unofficial values.  */
+
+#define EM_ALPHA	0x9026
+
+/* Legal values for e_version (version).  */
+
+#define EV_NONE		0		/* Invalid ELF version */
+#define EV_CURRENT	1		/* Current version */
+#define EV_NUM		2
+
+/* Section header.  */
+
+typedef struct
+{
+  Elf32_Word	sh_name;		/* Section name (string tbl index) */
+  Elf32_Word	sh_type;		/* Section type */
+  Elf32_Word	sh_flags;		/* Section flags */
+  Elf32_Addr	sh_addr;		/* Section virtual addr at execution */
+  Elf32_Off	sh_offset;		/* Section file offset */
+  Elf32_Word	sh_size;		/* Section size in bytes */
+  Elf32_Word	sh_link;		/* Link to another section */
+  Elf32_Word	sh_info;		/* Additional section information */
+  Elf32_Word	sh_addralign;		/* Section alignment */
+  Elf32_Word	sh_entsize;		/* Entry size if section holds table */
+} Elf32_Shdr;
+
+typedef struct
+{
+  Elf64_Word	sh_name;		/* Section name (string tbl index) */
+  Elf64_Word	sh_type;		/* Section type */
+  Elf64_Xword	sh_flags;		/* Section flags */
+  Elf64_Addr	sh_addr;		/* Section virtual addr at execution */
+  Elf64_Off	sh_offset;		/* Section file offset */
+  Elf64_Xword	sh_size;		/* Section size in bytes */
+  Elf64_Word	sh_link;		/* Link to another section */
+  Elf64_Word	sh_info;		/* Additional section information */
+  Elf64_Xword	sh_addralign;		/* Section alignment */
+  Elf64_Xword	sh_entsize;		/* Entry size if section holds table */
+} Elf64_Shdr;
+
+/* Special section indices.  */
+
+#define SHN_UNDEF	0		/* Undefined section */
+#define SHN_LORESERVE	0xff00		/* Start of reserved indices */
+#define SHN_LOPROC	0xff00		/* Start of processor-specific */
+#define SHN_BEFORE	0xff00		/* Order section before all others
+					   (Solaris).  */
+#define SHN_AFTER	0xff01		/* Order section after all others
+					   (Solaris).  */
+#define SHN_HIPROC	0xff1f		/* End of processor-specific */
+#define SHN_LOOS	0xff20		/* Start of OS-specific */
+#define SHN_HIOS	0xff3f		/* End of OS-specific */
+#define SHN_ABS		0xfff1		/* Associated symbol is absolute */
+#define SHN_COMMON	0xfff2		/* Associated symbol is common */
+#define SHN_XINDEX	0xffff		/* Index is in extra table.  */
+#define SHN_HIRESERVE	0xffff		/* End of reserved indices */
+
+/* Legal values for sh_type (section type).  */
+
+#define SHT_NULL	  0		/* Section header table entry unused */
+#define SHT_PROGBITS	  1		/* Program data */
+#define SHT_SYMTAB	  2		/* Symbol table */
+#define SHT_STRTAB	  3		/* String table */
+#define SHT_RELA	  4		/* Relocation entries with addends */
+#define SHT_HASH	  5		/* Symbol hash table */
+#define SHT_DYNAMIC	  6		/* Dynamic linking information */
+#define SHT_NOTE	  7		/* Notes */
+#define SHT_NOBITS	  8		/* Program space with no data (bss) */
+#define SHT_REL		  9		/* Relocation entries, no addends */
+#define SHT_SHLIB	  10		/* Reserved */
+#define SHT_DYNSYM	  11		/* Dynamic linker symbol table */
+#define SHT_INIT_ARRAY	  14		/* Array of constructors */
+#define SHT_FINI_ARRAY	  15		/* Array of destructors */
+#define SHT_PREINIT_ARRAY 16		/* Array of pre-constructors */
+#define SHT_GROUP	  17		/* Section group */
+#define SHT_SYMTAB_SHNDX  18		/* Extended section indeces */
+#define	SHT_NUM		  19		/* Number of defined types.  */
+#define SHT_LOOS	  0x60000000	/* Start OS-specific.  */
+#define SHT_GNU_HASH	  0x6ffffff6	/* GNU-style hash table.  */
+#define SHT_GNU_LIBLIST	  0x6ffffff7	/* Prelink library list */
+#define SHT_CHECKSUM	  0x6ffffff8	/* Checksum for DSO content.  */
+#define SHT_LOSUNW	  0x6ffffffa	/* Sun-specific low bound.  */
+#define SHT_SUNW_move	  0x6ffffffa
+#define SHT_SUNW_COMDAT   0x6ffffffb
+#define SHT_SUNW_syminfo  0x6ffffffc
+#define SHT_GNU_verdef	  0x6ffffffd	/* Version definition section.  */
+#define SHT_GNU_verneed	  0x6ffffffe	/* Version needs section.  */
+#define SHT_GNU_versym	  0x6fffffff	/* Version symbol table.  */
+#define SHT_HISUNW	  0x6fffffff	/* Sun-specific high bound.  */
+#define SHT_HIOS	  0x6fffffff	/* End OS-specific type */
+#define SHT_LOPROC	  0x70000000	/* Start of processor-specific */
+#define SHT_HIPROC	  0x7fffffff	/* End of processor-specific */
+#define SHT_LOUSER	  0x80000000	/* Start of application-specific */
+#define SHT_HIUSER	  0x8fffffff	/* End of application-specific */
+
+/* Legal values for sh_flags (section flags).  */
+
+#define SHF_WRITE	     (1 << 0)	/* Writable */
+#define SHF_ALLOC	     (1 << 1)	/* Occupies memory during execution */
+#define SHF_EXECINSTR	     (1 << 2)	/* Executable */
+#define SHF_MERGE	     (1 << 4)	/* Might be merged */
+#define SHF_STRINGS	     (1 << 5)	/* Contains nul-terminated strings */
+#define SHF_INFO_LINK	     (1 << 6)	/* `sh_info' contains SHT index */
+#define SHF_LINK_ORDER	     (1 << 7)	/* Preserve order after combining */
+#define SHF_OS_NONCONFORMING (1 << 8)	/* Non-standard OS specific handling
+					   required */
+#define SHF_GROUP	     (1 << 9)	/* Section is member of a group.  */
+#define SHF_TLS		     (1 << 10)	/* Section hold thread-local data.  */
+#define SHF_MASKOS	     0x0ff00000	/* OS-specific.  */
+#define SHF_MASKPROC	     0xf0000000	/* Processor-specific */
+#define SHF_ORDERED	     (1 << 30)	/* Special ordering requirement
+					   (Solaris).  */
+#define SHF_EXCLUDE	     (1 << 31)	/* Section is excluded unless
+					   referenced or allocated (Solaris).*/
+
+/* Section group handling.  */
+#define GRP_COMDAT	0x1		/* Mark group as COMDAT.  */
+
+/* Symbol table entry.  */
+
+typedef struct
+{
+  Elf32_Word	st_name;		/* Symbol name (string tbl index) */
+  Elf32_Addr	st_value;		/* Symbol value */
+  Elf32_Word	st_size;		/* Symbol size */
+  unsigned char	st_info;		/* Symbol type and binding */
+  unsigned char	st_other;		/* Symbol visibility */
+  Elf32_Section	st_shndx;		/* Section index */
+} Elf32_Sym;
+
+typedef struct
+{
+  Elf64_Word	st_name;		/* Symbol name (string tbl index) */
+  unsigned char	st_info;		/* Symbol type and binding */
+  unsigned char st_other;		/* Symbol visibility */
+  Elf64_Section	st_shndx;		/* Section index */
+  Elf64_Addr	st_value;		/* Symbol value */
+  Elf64_Xword	st_size;		/* Symbol size */
+} Elf64_Sym;
+
+/* The syminfo section if available contains additional information about
+   every dynamic symbol.  */
+
+typedef struct
+{
+  Elf32_Half si_boundto;		/* Direct bindings, symbol bound to */
+  Elf32_Half si_flags;			/* Per symbol flags */
+} Elf32_Syminfo;
+
+typedef struct
+{
+  Elf64_Half si_boundto;		/* Direct bindings, symbol bound to */
+  Elf64_Half si_flags;			/* Per symbol flags */
+} Elf64_Syminfo;
+
+/* Possible values for si_boundto.  */
+#define SYMINFO_BT_SELF		0xffff	/* Symbol bound to self */
+#define SYMINFO_BT_PARENT	0xfffe	/* Symbol bound to parent */
+#define SYMINFO_BT_LOWRESERVE	0xff00	/* Beginning of reserved entries */
+
+/* Possible bitmasks for si_flags.  */
+#define SYMINFO_FLG_DIRECT	0x0001	/* Direct bound symbol */
+#define SYMINFO_FLG_PASSTHRU	0x0002	/* Pass-thru symbol for translator */
+#define SYMINFO_FLG_COPY	0x0004	/* Symbol is a copy-reloc */
+#define SYMINFO_FLG_LAZYLOAD	0x0008	/* Symbol bound to object to be lazy
+					   loaded */
+/* Syminfo version values.  */
+#define SYMINFO_NONE		0
+#define SYMINFO_CURRENT		1
+#define SYMINFO_NUM		2
+
+
+/* How to extract and insert information held in the st_info field.  */
+
+#define ELF32_ST_BIND(val)		(((unsigned char) (val)) >> 4)
+#define ELF32_ST_TYPE(val)		((val) & 0xf)
+#define ELF32_ST_INFO(bind, type)	(((bind) << 4) + ((type) & 0xf))
+
+/* Both Elf32_Sym and Elf64_Sym use the same one-byte st_info field.  */
+#define ELF64_ST_BIND(val)		ELF32_ST_BIND (val)
+#define ELF64_ST_TYPE(val)		ELF32_ST_TYPE (val)
+#define ELF64_ST_INFO(bind, type)	ELF32_ST_INFO ((bind), (type))
+
+/* Legal values for ST_BIND subfield of st_info (symbol binding).  */
+
+#define STB_LOCAL	0		/* Local symbol */
+#define STB_GLOBAL	1		/* Global symbol */
+#define STB_WEAK	2		/* Weak symbol */
+#define	STB_NUM		3		/* Number of defined types.  */
+#define STB_LOOS	10		/* Start of OS-specific */
+#define STB_HIOS	12		/* End of OS-specific */
+#define STB_LOPROC	13		/* Start of processor-specific */
+#define STB_HIPROC	15		/* End of processor-specific */
+
+/* Legal values for ST_TYPE subfield of st_info (symbol type).  */
+
+#define STT_NOTYPE	0		/* Symbol type is unspecified */
+#define STT_OBJECT	1		/* Symbol is a data object */
+#define STT_FUNC	2		/* Symbol is a code object */
+#define STT_SECTION	3		/* Symbol associated with a section */
+#define STT_FILE	4		/* Symbol's name is file name */
+#define STT_COMMON	5		/* Symbol is a common data object */
+#define STT_TLS		6		/* Symbol is thread-local data object*/
+#define	STT_NUM		7		/* Number of defined types.  */
+#define STT_LOOS	10		/* Start of OS-specific */
+#define STT_HIOS	12		/* End of OS-specific */
+#define STT_LOPROC	13		/* Start of processor-specific */
+#define STT_HIPROC	15		/* End of processor-specific */
+
+
+/* Symbol table indices are found in the hash buckets and chain table
+   of a symbol hash table section.  This special index value indicates
+   the end of a chain, meaning no further symbols are found in that bucket.  */
+
+#define STN_UNDEF	0		/* End of a chain.  */
+
+
+/* How to extract and insert information held in the st_other field.  */
+
+#define ELF32_ST_VISIBILITY(o)	((o) & 0x03)
+
+/* For ELF64 the definitions are the same.  */
+#define ELF64_ST_VISIBILITY(o)	ELF32_ST_VISIBILITY (o)
+
+/* Symbol visibility specification encoded in the st_other field.  */
+#define STV_DEFAULT	0		/* Default symbol visibility rules */
+#define STV_INTERNAL	1		/* Processor specific hidden class */
+#define STV_HIDDEN	2		/* Sym unavailable in other modules */
+#define STV_PROTECTED	3		/* Not preemptible, not exported */
+
+
+/* Relocation table entry without addend (in section of type SHT_REL).  */
+
+typedef struct
+{
+  Elf32_Addr	r_offset;		/* Address */
+  Elf32_Word	r_info;			/* Relocation type and symbol index */
+} Elf32_Rel;
+
+/* I have seen two different definitions of the Elf64_Rel and
+   Elf64_Rela structures, so we'll leave them out until Novell (or
+   whoever) gets their act together.  */
+/* The following, at least, is used on Sparc v9, MIPS, and Alpha.  */
+
+typedef struct
+{
+  Elf64_Addr	r_offset;		/* Address */
+  Elf64_Xword	r_info;			/* Relocation type and symbol index */
+} Elf64_Rel;
+
+/* Relocation table entry with addend (in section of type SHT_RELA).  */
+
+typedef struct
+{
+  Elf32_Addr	r_offset;		/* Address */
+  Elf32_Word	r_info;			/* Relocation type and symbol index */
+  Elf32_Sword	r_addend;		/* Addend */
+} Elf32_Rela;
+
+typedef struct
+{
+  Elf64_Addr	r_offset;		/* Address */
+  Elf64_Xword	r_info;			/* Relocation type and symbol index */
+  Elf64_Sxword	r_addend;		/* Addend */
+} Elf64_Rela;
+
+/* How to extract and insert information held in the r_info field.  */
+
+#define ELF32_R_SYM(val)		((val) >> 8)
+#define ELF32_R_TYPE(val)		((val) & 0xff)
+#define ELF32_R_INFO(sym, type)		(((sym) << 8) + ((type) & 0xff))
+
+#define ELF64_R_SYM(i)			((i) >> 32)
+#define ELF64_R_TYPE(i)			((i) & 0xffffffff)
+#define ELF64_R_INFO(sym,type)		((((Elf64_Xword) (sym)) << 32) + (type))
+
+/* Program segment header.  */
+
+typedef struct
+{
+  Elf32_Word	p_type;			/* Segment type */
+  Elf32_Off	p_offset;		/* Segment file offset */
+  Elf32_Addr	p_vaddr;		/* Segment virtual address */
+  Elf32_Addr	p_paddr;		/* Segment physical address */
+  Elf32_Word	p_filesz;		/* Segment size in file */
+  Elf32_Word	p_memsz;		/* Segment size in memory */
+  Elf32_Word	p_flags;		/* Segment flags */
+  Elf32_Word	p_align;		/* Segment alignment */
+} Elf32_Phdr;
+
+typedef struct
+{
+  Elf64_Word	p_type;			/* Segment type */
+  Elf64_Word	p_flags;		/* Segment flags */
+  Elf64_Off	p_offset;		/* Segment file offset */
+  Elf64_Addr	p_vaddr;		/* Segment virtual address */
+  Elf64_Addr	p_paddr;		/* Segment physical address */
+  Elf64_Xword	p_filesz;		/* Segment size in file */
+  Elf64_Xword	p_memsz;		/* Segment size in memory */
+  Elf64_Xword	p_align;		/* Segment alignment */
+} Elf64_Phdr;
+
+/* Legal values for p_type (segment type).  */
+
+#define	PT_NULL		0		/* Program header table entry unused */
+#define PT_LOAD		1		/* Loadable program segment */
+#define PT_DYNAMIC	2		/* Dynamic linking information */
+#define PT_INTERP	3		/* Program interpreter */
+#define PT_NOTE		4		/* Auxiliary information */
+#define PT_SHLIB	5		/* Reserved */
+#define PT_PHDR		6		/* Entry for header table itself */
+#define PT_TLS		7		/* Thread-local storage segment */
+#define	PT_NUM		8		/* Number of defined types */
+#define PT_LOOS		0x60000000	/* Start of OS-specific */
+#define PT_GNU_EH_FRAME	0x6474e550	/* GCC .eh_frame_hdr segment */
+#define PT_GNU_STACK	0x6474e551	/* Indicates stack executability */
+#define PT_GNU_RELRO	0x6474e552	/* Read-only after relocation */
+#define PT_LOSUNW	0x6ffffffa
+#define PT_SUNWBSS	0x6ffffffa	/* Sun Specific segment */
+#define PT_SUNWSTACK	0x6ffffffb	/* Stack segment */
+#define PT_HISUNW	0x6fffffff
+#define PT_HIOS		0x6fffffff	/* End of OS-specific */
+#define PT_LOPROC	0x70000000	/* Start of processor-specific */
+#define PT_HIPROC	0x7fffffff	/* End of processor-specific */
+
+/* Legal values for p_flags (segment flags).  */
+
+#define PF_X		(1 << 0)	/* Segment is executable */
+#define PF_W		(1 << 1)	/* Segment is writable */
+#define PF_R		(1 << 2)	/* Segment is readable */
+#define PF_MASKOS	0x0ff00000	/* OS-specific */
+#define PF_MASKPROC	0xf0000000	/* Processor-specific */
+
+/* Legal values for note segment descriptor types for core files. */
+
+#define NT_PRSTATUS	1		/* Contains copy of prstatus struct */
+#define NT_FPREGSET	2		/* Contains copy of fpregset struct */
+#define NT_PRPSINFO	3		/* Contains copy of prpsinfo struct */
+#define NT_PRXREG	4		/* Contains copy of prxregset struct */
+#define NT_TASKSTRUCT	4		/* Contains copy of task structure */
+#define NT_PLATFORM	5		/* String from sysinfo(SI_PLATFORM) */
+#define NT_AUXV		6		/* Contains copy of auxv array */
+#define NT_GWINDOWS	7		/* Contains copy of gwindows struct */
+#define NT_ASRS		8		/* Contains copy of asrset struct */
+#define NT_PSTATUS	10		/* Contains copy of pstatus struct */
+#define NT_PSINFO	13		/* Contains copy of psinfo struct */
+#define NT_PRCRED	14		/* Contains copy of prcred struct */
+#define NT_UTSNAME	15		/* Contains copy of utsname struct */
+#define NT_LWPSTATUS	16		/* Contains copy of lwpstatus struct */
+#define NT_LWPSINFO	17		/* Contains copy of lwpinfo struct */
+#define NT_PRFPXREG	20		/* Contains copy of fprxregset struct */
+#define NT_PRXFPREG	0x46e62b7f	/* Contains copy of user_fxsr_struct */
+
+/* Legal values for the note segment descriptor types for object files.  */
+
+#define NT_VERSION	1		/* Contains a version string.  */
+
+
+/* Dynamic section entry.  */
+
+typedef struct
+{
+  Elf32_Sword	d_tag;			/* Dynamic entry type */
+  union
+    {
+      Elf32_Word d_val;			/* Integer value */
+      Elf32_Addr d_ptr;			/* Address value */
+    } d_un;
+} Elf32_Dyn;
+
+typedef struct
+{
+  Elf64_Sxword	d_tag;			/* Dynamic entry type */
+  union
+    {
+      Elf64_Xword d_val;		/* Integer value */
+      Elf64_Addr d_ptr;			/* Address value */
+    } d_un;
+} Elf64_Dyn;
+
+/* Legal values for d_tag (dynamic entry type).  */
+
+#define DT_NULL		0		/* Marks end of dynamic section */
+#define DT_NEEDED	1		/* Name of needed library */
+#define DT_PLTRELSZ	2		/* Size in bytes of PLT relocs */
+#define DT_PLTGOT	3		/* Processor defined value */
+#define DT_HASH		4		/* Address of symbol hash table */
+#define DT_STRTAB	5		/* Address of string table */
+#define DT_SYMTAB	6		/* Address of symbol table */
+#define DT_RELA		7		/* Address of Rela relocs */
+#define DT_RELASZ	8		/* Total size of Rela relocs */
+#define DT_RELAENT	9		/* Size of one Rela reloc */
+#define DT_STRSZ	10		/* Size of string table */
+#define DT_SYMENT	11		/* Size of one symbol table entry */
+#define DT_INIT		12		/* Address of init function */
+#define DT_FINI		13		/* Address of termination function */
+#define DT_SONAME	14		/* Name of shared object */
+#define DT_RPATH	15		/* Library search path (deprecated) */
+#define DT_SYMBOLIC	16		/* Start symbol search here */
+#define DT_REL		17		/* Address of Rel relocs */
+#define DT_RELSZ	18		/* Total size of Rel relocs */
+#define DT_RELENT	19		/* Size of one Rel reloc */
+#define DT_PLTREL	20		/* Type of reloc in PLT */
+#define DT_DEBUG	21		/* For debugging; unspecified */
+#define DT_TEXTREL	22		/* Reloc might modify .text */
+#define DT_JMPREL	23		/* Address of PLT relocs */
+#define	DT_BIND_NOW	24		/* Process relocations of object */
+#define	DT_INIT_ARRAY	25		/* Array with addresses of init fct */
+#define	DT_FINI_ARRAY	26		/* Array with addresses of fini fct */
+#define	DT_INIT_ARRAYSZ	27		/* Size in bytes of DT_INIT_ARRAY */
+#define	DT_FINI_ARRAYSZ	28		/* Size in bytes of DT_FINI_ARRAY */
+#define DT_RUNPATH	29		/* Library search path */
+#define DT_FLAGS	30		/* Flags for the object being loaded */
+#define DT_ENCODING	32		/* Start of encoded range */
+#define DT_PREINIT_ARRAY 32		/* Array with addresses of preinit fct*/
+#define DT_PREINIT_ARRAYSZ 33		/* size in bytes of DT_PREINIT_ARRAY */
+#define	DT_NUM		34		/* Number used */
+#define DT_LOOS		0x6000000d	/* Start of OS-specific */
+#define DT_HIOS		0x6ffff000	/* End of OS-specific */
+#define DT_LOPROC	0x70000000	/* Start of processor-specific */
+#define DT_HIPROC	0x7fffffff	/* End of processor-specific */
+#define	DT_PROCNUM	DT_MIPS_NUM	/* Most used by any processor */
+
+/* DT_* entries which fall between DT_VALRNGHI & DT_VALRNGLO use the
+   Dyn.d_un.d_val field of the Elf*_Dyn structure.  This follows Sun's
+   approach.  */
+#define DT_VALRNGLO	0x6ffffd00
+#define DT_GNU_PRELINKED 0x6ffffdf5	/* Prelinking timestamp */
+#define DT_GNU_CONFLICTSZ 0x6ffffdf6	/* Size of conflict section */
+#define DT_GNU_LIBLISTSZ 0x6ffffdf7	/* Size of library list */
+#define DT_CHECKSUM	0x6ffffdf8
+#define DT_PLTPADSZ	0x6ffffdf9
+#define DT_MOVEENT	0x6ffffdfa
+#define DT_MOVESZ	0x6ffffdfb
+#define DT_FEATURE_1	0x6ffffdfc	/* Feature selection (DTF_*).  */
+#define DT_POSFLAG_1	0x6ffffdfd	/* Flags for DT_* entries, effecting
+					   the following DT_* entry.  */
+#define DT_SYMINSZ	0x6ffffdfe	/* Size of syminfo table (in bytes) */
+#define DT_SYMINENT	0x6ffffdff	/* Entry size of syminfo */
+#define DT_VALRNGHI	0x6ffffdff
+#define DT_VALTAGIDX(tag)	(DT_VALRNGHI - (tag))	/* Reverse order! */
+#define DT_VALNUM 12
+
+/* DT_* entries which fall between DT_ADDRRNGHI & DT_ADDRRNGLO use the
+   Dyn.d_un.d_ptr field of the Elf*_Dyn structure.
+
+   If any adjustment is made to the ELF object after it has been
+   built these entries will need to be adjusted.  */
+#define DT_ADDRRNGLO	0x6ffffe00
+#define DT_GNU_HASH	0x6ffffef5	/* GNU-style hash table.  */
+#define DT_TLSDESC_PLT	0x6ffffef6
+#define DT_TLSDESC_GOT	0x6ffffef7
+#define DT_GNU_CONFLICT	0x6ffffef8	/* Start of conflict section */
+#define DT_GNU_LIBLIST	0x6ffffef9	/* Library list */
+#define DT_CONFIG	0x6ffffefa	/* Configuration information.  */
+#define DT_DEPAUDIT	0x6ffffefb	/* Dependency auditing.  */
+#define DT_AUDIT	0x6ffffefc	/* Object auditing.  */
+#define	DT_PLTPAD	0x6ffffefd	/* PLT padding.  */
+#define	DT_MOVETAB	0x6ffffefe	/* Move table.  */
+#define DT_SYMINFO	0x6ffffeff	/* Syminfo table.  */
+#define DT_ADDRRNGHI	0x6ffffeff
+#define DT_ADDRTAGIDX(tag)	(DT_ADDRRNGHI - (tag))	/* Reverse order! */
+#define DT_ADDRNUM 11
+
+/* The versioning entry types.  The next are defined as part of the
+   GNU extension.  */
+#define DT_VERSYM	0x6ffffff0
+
+#define DT_RELACOUNT	0x6ffffff9
+#define DT_RELCOUNT	0x6ffffffa
+
+/* These were chosen by Sun.  */
+#define DT_FLAGS_1	0x6ffffffb	/* State flags, see DF_1_* below.  */
+#define	DT_VERDEF	0x6ffffffc	/* Address of version definition
+					   table */
+#define	DT_VERDEFNUM	0x6ffffffd	/* Number of version definitions */
+#define	DT_VERNEED	0x6ffffffe	/* Address of table with needed
+					   versions */
+#define	DT_VERNEEDNUM	0x6fffffff	/* Number of needed versions */
+#define DT_VERSIONTAGIDX(tag)	(DT_VERNEEDNUM - (tag))	/* Reverse order! */
+#define DT_VERSIONTAGNUM 16
+
+/* Sun added these machine-independent extensions in the "processor-specific"
+   range.  Be compatible.  */
+#define DT_AUXILIARY    0x7ffffffd      /* Shared object to load before self */
+#define DT_FILTER       0x7fffffff      /* Shared object to get values from */
+#define DT_EXTRATAGIDX(tag)	((Elf32_Word)-((Elf32_Sword) (tag) <<1>>1)-1)
+#define DT_EXTRANUM	3
+
+/* Values of `d_un.d_val' in the DT_FLAGS entry.  */
+#define DF_ORIGIN	0x00000001	/* Object may use DF_ORIGIN */
+#define DF_SYMBOLIC	0x00000002	/* Symbol resolutions starts here */
+#define DF_TEXTREL	0x00000004	/* Object contains text relocations */
+#define DF_BIND_NOW	0x00000008	/* No lazy binding for this object */
+#define DF_STATIC_TLS	0x00000010	/* Module uses the static TLS model */
+
+/* State flags selectable in the `d_un.d_val' element of the DT_FLAGS_1
+   entry in the dynamic section.  */
+#define DF_1_NOW	0x00000001	/* Set RTLD_NOW for this object.  */
+#define DF_1_GLOBAL	0x00000002	/* Set RTLD_GLOBAL for this object.  */
+#define DF_1_GROUP	0x00000004	/* Set RTLD_GROUP for this object.  */
+#define DF_1_NODELETE	0x00000008	/* Set RTLD_NODELETE for this object.*/
+#define DF_1_LOADFLTR	0x00000010	/* Trigger filtee loading at runtime.*/
+#define DF_1_INITFIRST	0x00000020	/* Set RTLD_INITFIRST for this object*/
+#define DF_1_NOOPEN	0x00000040	/* Set RTLD_NOOPEN for this object.  */
+#define DF_1_ORIGIN	0x00000080	/* $ORIGIN must be handled.  */
+#define DF_1_DIRECT	0x00000100	/* Direct binding enabled.  */
+#define DF_1_TRANS	0x00000200
+#define DF_1_INTERPOSE	0x00000400	/* Object is used to interpose.  */
+#define DF_1_NODEFLIB	0x00000800	/* Ignore default lib search path.  */
+#define DF_1_NODUMP	0x00001000	/* Object can't be dldump'ed.  */
+#define DF_1_CONFALT	0x00002000	/* Configuration alternative created.*/
+#define DF_1_ENDFILTEE	0x00004000	/* Filtee terminates filters search. */
+#define	DF_1_DISPRELDNE	0x00008000	/* Disp reloc applied at build time. */
+#define	DF_1_DISPRELPND	0x00010000	/* Disp reloc applied at run-time.  */
+
+/* Flags for the feature selection in DT_FEATURE_1.  */
+#define DTF_1_PARINIT	0x00000001
+#define DTF_1_CONFEXP	0x00000002
+
+/* Flags in the DT_POSFLAG_1 entry effecting only the next DT_* entry.  */
+#define DF_P1_LAZYLOAD	0x00000001	/* Lazyload following object.  */
+#define DF_P1_GROUPPERM	0x00000002	/* Symbols from next object are not
+					   generally available.  */
+
+/* Version definition sections.  */
+
+typedef struct
+{
+  Elf32_Half	vd_version;		/* Version revision */
+  Elf32_Half	vd_flags;		/* Version information */
+  Elf32_Half	vd_ndx;			/* Version Index */
+  Elf32_Half	vd_cnt;			/* Number of associated aux entries */
+  Elf32_Word	vd_hash;		/* Version name hash value */
+  Elf32_Word	vd_aux;			/* Offset in bytes to verdaux array */
+  Elf32_Word	vd_next;		/* Offset in bytes to next verdef
+					   entry */
+} Elf32_Verdef;
+
+typedef struct
+{
+  Elf64_Half	vd_version;		/* Version revision */
+  Elf64_Half	vd_flags;		/* Version information */
+  Elf64_Half	vd_ndx;			/* Version Index */
+  Elf64_Half	vd_cnt;			/* Number of associated aux entries */
+  Elf64_Word	vd_hash;		/* Version name hash value */
+  Elf64_Word	vd_aux;			/* Offset in bytes to verdaux array */
+  Elf64_Word	vd_next;		/* Offset in bytes to next verdef
+					   entry */
+} Elf64_Verdef;
+
+
+/* Legal values for vd_version (version revision).  */
+#define VER_DEF_NONE	0		/* No version */
+#define VER_DEF_CURRENT	1		/* Current version */
+#define VER_DEF_NUM	2		/* Given version number */
+
+/* Legal values for vd_flags (version information flags).  */
+#define VER_FLG_BASE	0x1		/* Version definition of file itself */
+#define VER_FLG_WEAK	0x2		/* Weak version identifier */
+
+/* Versym symbol index values.  */
+#define	VER_NDX_LOCAL		0	/* Symbol is local.  */
+#define	VER_NDX_GLOBAL		1	/* Symbol is global.  */
+#define	VER_NDX_LORESERVE	0xff00	/* Beginning of reserved entries.  */
+#define	VER_NDX_ELIMINATE	0xff01	/* Symbol is to be eliminated.  */
+
+/* Auxialiary version information.  */
+
+typedef struct
+{
+  Elf32_Word	vda_name;		/* Version or dependency names */
+  Elf32_Word	vda_next;		/* Offset in bytes to next verdaux
+					   entry */
+} Elf32_Verdaux;
+
+typedef struct
+{
+  Elf64_Word	vda_name;		/* Version or dependency names */
+  Elf64_Word	vda_next;		/* Offset in bytes to next verdaux
+					   entry */
+} Elf64_Verdaux;
+
+
+/* Version dependency section.  */
+
+typedef struct
+{
+  Elf32_Half	vn_version;		/* Version of structure */
+  Elf32_Half	vn_cnt;			/* Number of associated aux entries */
+  Elf32_Word	vn_file;		/* Offset of filename for this
+					   dependency */
+  Elf32_Word	vn_aux;			/* Offset in bytes to vernaux array */
+  Elf32_Word	vn_next;		/* Offset in bytes to next verneed
+					   entry */
+} Elf32_Verneed;
+
+typedef struct
+{
+  Elf64_Half	vn_version;		/* Version of structure */
+  Elf64_Half	vn_cnt;			/* Number of associated aux entries */
+  Elf64_Word	vn_file;		/* Offset of filename for this
+					   dependency */
+  Elf64_Word	vn_aux;			/* Offset in bytes to vernaux array */
+  Elf64_Word	vn_next;		/* Offset in bytes to next verneed
+					   entry */
+} Elf64_Verneed;
+
+
+/* Legal values for vn_version (version revision).  */
+#define VER_NEED_NONE	 0		/* No version */
+#define VER_NEED_CURRENT 1		/* Current version */
+#define VER_NEED_NUM	 2		/* Given version number */
+
+/* Auxiliary needed version information.  */
+
+typedef struct
+{
+  Elf32_Word	vna_hash;		/* Hash value of dependency name */
+  Elf32_Half	vna_flags;		/* Dependency specific information */
+  Elf32_Half	vna_other;		/* Unused */
+  Elf32_Word	vna_name;		/* Dependency name string offset */
+  Elf32_Word	vna_next;		/* Offset in bytes to next vernaux
+					   entry */
+} Elf32_Vernaux;
+
+typedef struct
+{
+  Elf64_Word	vna_hash;		/* Hash value of dependency name */
+  Elf64_Half	vna_flags;		/* Dependency specific information */
+  Elf64_Half	vna_other;		/* Unused */
+  Elf64_Word	vna_name;		/* Dependency name string offset */
+  Elf64_Word	vna_next;		/* Offset in bytes to next vernaux
+					   entry */
+} Elf64_Vernaux;
+
+
+/* Legal values for vna_flags.  */
+#define VER_FLG_WEAK	0x2		/* Weak version identifier */
+
+
+/* Auxiliary vector.  */
+
+/* This vector is normally only used by the program interpreter.  The
+   usual definition in an ABI supplement uses the name auxv_t.  The
+   vector is not usually defined in a standard <elf.h> file, but it
+   can't hurt.  We rename it to avoid conflicts.  The sizes of these
+   types are an arrangement between the exec server and the program
+   interpreter, so we don't fully specify them here.  */
+
+typedef struct
+{
+  uint32_t a_type;		/* Entry type */
+  union
+    {
+      uint32_t a_val;		/* Integer value */
+      /* We use to have pointer elements added here.  We cannot do that,
+	 though, since it does not work when using 32-bit definitions
+	 on 64-bit platforms and vice versa.  */
+    } a_un;
+} Elf32_auxv_t;
+
+typedef struct
+{
+  uint64_t a_type;		/* Entry type */
+  union
+    {
+      uint64_t a_val;		/* Integer value */
+      /* We use to have pointer elements added here.  We cannot do that,
+	 though, since it does not work when using 32-bit definitions
+	 on 64-bit platforms and vice versa.  */
+    } a_un;
+} Elf64_auxv_t;
+
+/* Legal values for a_type (entry type).  */
+
+#define AT_NULL		0		/* End of vector */
+#define AT_IGNORE	1		/* Entry should be ignored */
+#define AT_EXECFD	2		/* File descriptor of program */
+#define AT_PHDR		3		/* Program headers for program */
+#define AT_PHENT	4		/* Size of program header entry */
+#define AT_PHNUM	5		/* Number of program headers */
+#define AT_PAGESZ	6		/* System page size */
+#define AT_BASE		7		/* Base address of interpreter */
+#define AT_FLAGS	8		/* Flags */
+#define AT_ENTRY	9		/* Entry point of program */
+#define AT_NOTELF	10		/* Program is not ELF */
+#define AT_UID		11		/* Real uid */
+#define AT_EUID		12		/* Effective uid */
+#define AT_GID		13		/* Real gid */
+#define AT_EGID		14		/* Effective gid */
+#define AT_CLKTCK	17		/* Frequency of times() */
+
+/* Some more special a_type values describing the hardware.  */
+#define AT_PLATFORM	15		/* String identifying platform.  */
+#define AT_HWCAP	16		/* Machine dependent hints about
+					   processor capabilities.  */
+
+/* This entry gives some information about the FPU initialization
+   performed by the kernel.  */
+#define AT_FPUCW	18		/* Used FPU control word.  */
+
+/* Cache block sizes.  */
+#define AT_DCACHEBSIZE	19		/* Data cache block size.  */
+#define AT_ICACHEBSIZE	20		/* Instruction cache block size.  */
+#define AT_UCACHEBSIZE	21		/* Unified cache block size.  */
+
+/* A special ignored value for PPC, used by the kernel to control the
+   interpretation of the AUXV. Must be > 16.  */
+#define AT_IGNOREPPC	22		/* Entry should be ignored.  */
+
+#define	AT_SECURE	23		/* Boolean, was exec setuid-like?  */
+
+/* Pointer to the global system page used for system calls and other
+   nice things.  */
+#define AT_SYSINFO	32
+#define AT_SYSINFO_EHDR	33
+
+/* Shapes of the caches.  Bits 0-3 contains associativity; bits 4-7 contains
+   log2 of line size; mask those to get cache size.  */
+#define AT_L1I_CACHESHAPE	34
+#define AT_L1D_CACHESHAPE	35
+#define AT_L2_CACHESHAPE	36
+#define AT_L3_CACHESHAPE	37
+
+/* Note section contents.  Each entry in the note section begins with
+   a header of a fixed form.  */
+
+typedef struct
+{
+  Elf32_Word n_namesz;			/* Length of the note's name.  */
+  Elf32_Word n_descsz;			/* Length of the note's descriptor.  */
+  Elf32_Word n_type;			/* Type of the note.  */
+} Elf32_Nhdr;
+
+typedef struct
+{
+  Elf64_Word n_namesz;			/* Length of the note's name.  */
+  Elf64_Word n_descsz;			/* Length of the note's descriptor.  */
+  Elf64_Word n_type;			/* Type of the note.  */
+} Elf64_Nhdr;
+
+/* Known names of notes.  */
+
+/* Solaris entries in the note section have this name.  */
+#define ELF_NOTE_SOLARIS	"SUNW Solaris"
+
+/* Note entries for GNU systems have this name.  */
+#define ELF_NOTE_GNU		"GNU"
+
+
+/* Defined types of notes for Solaris.  */
+
+/* Value of descriptor (one word) is desired pagesize for the binary.  */
+#define ELF_NOTE_PAGESIZE_HINT	1
+
+
+/* Defined note types for GNU systems.  */
+
+/* ABI information.  The descriptor consists of words:
+   word 0: OS descriptor
+   word 1: major version of the ABI
+   word 2: minor version of the ABI
+   word 3: subminor version of the ABI
+*/
+#define NT_GNU_ABI_TAG	1
+#define ELF_NOTE_ABI	NT_GNU_ABI_TAG /* Old name.  */
+
+/* Known OSes.  These values can appear in word 0 of an
+   NT_GNU_ABI_TAG note section entry.  */
+#define ELF_NOTE_OS_LINUX	0
+#define ELF_NOTE_OS_GNU		1
+#define ELF_NOTE_OS_SOLARIS2	2
+#define ELF_NOTE_OS_FREEBSD	3
+
+/* Synthetic hwcap information.  The descriptor begins with two words:
+   word 0: number of entries
+   word 1: bitmask of enabled entries
+   Then follow variable-length entries, one byte followed by a
+   '\0'-terminated hwcap name string.  The byte gives the bit
+   number to test if enabled, (1U << bit) & bitmask.  */
+#define NT_GNU_HWCAP	2
+
+/* Build ID bits as generated by ld --build-id.
+   The descriptor consists of any nonzero number of bytes.  */
+#define NT_GNU_BUILD_ID	3
+
+
+/* Move records.  */
+typedef struct
+{
+  Elf32_Xword m_value;		/* Symbol value.  */
+  Elf32_Word m_info;		/* Size and index.  */
+  Elf32_Word m_poffset;		/* Symbol offset.  */
+  Elf32_Half m_repeat;		/* Repeat count.  */
+  Elf32_Half m_stride;		/* Stride info.  */
+} Elf32_Move;
+
+typedef struct
+{
+  Elf64_Xword m_value;		/* Symbol value.  */
+  Elf64_Xword m_info;		/* Size and index.  */
+  Elf64_Xword m_poffset;	/* Symbol offset.  */
+  Elf64_Half m_repeat;		/* Repeat count.  */
+  Elf64_Half m_stride;		/* Stride info.  */
+} Elf64_Move;
+
+/* Macro to construct move records.  */
+#define ELF32_M_SYM(info)	((info) >> 8)
+#define ELF32_M_SIZE(info)	((unsigned char) (info))
+#define ELF32_M_INFO(sym, size)	(((sym) << 8) + (unsigned char) (size))
+
+#define ELF64_M_SYM(info)	ELF32_M_SYM (info)
+#define ELF64_M_SIZE(info)	ELF32_M_SIZE (info)
+#define ELF64_M_INFO(sym, size)	ELF32_M_INFO (sym, size)
+
+
+/* Motorola 68k specific definitions.  */
+
+/* Values for Elf32_Ehdr.e_flags.  */
+#define EF_CPU32	0x00810000
+
+/* m68k relocs.  */
+
+#define R_68K_NONE	0		/* No reloc */
+#define R_68K_32	1		/* Direct 32 bit  */
+#define R_68K_16	2		/* Direct 16 bit  */
+#define R_68K_8		3		/* Direct 8 bit  */
+#define R_68K_PC32	4		/* PC relative 32 bit */
+#define R_68K_PC16	5		/* PC relative 16 bit */
+#define R_68K_PC8	6		/* PC relative 8 bit */
+#define R_68K_GOT32	7		/* 32 bit PC relative GOT entry */
+#define R_68K_GOT16	8		/* 16 bit PC relative GOT entry */
+#define R_68K_GOT8	9		/* 8 bit PC relative GOT entry */
+#define R_68K_GOT32O	10		/* 32 bit GOT offset */
+#define R_68K_GOT16O	11		/* 16 bit GOT offset */
+#define R_68K_GOT8O	12		/* 8 bit GOT offset */
+#define R_68K_PLT32	13		/* 32 bit PC relative PLT address */
+#define R_68K_PLT16	14		/* 16 bit PC relative PLT address */
+#define R_68K_PLT8	15		/* 8 bit PC relative PLT address */
+#define R_68K_PLT32O	16		/* 32 bit PLT offset */
+#define R_68K_PLT16O	17		/* 16 bit PLT offset */
+#define R_68K_PLT8O	18		/* 8 bit PLT offset */
+#define R_68K_COPY	19		/* Copy symbol at runtime */
+#define R_68K_GLOB_DAT	20		/* Create GOT entry */
+#define R_68K_JMP_SLOT	21		/* Create PLT entry */
+#define R_68K_RELATIVE	22		/* Adjust by program base */
+/* Keep this the last entry.  */
+#define R_68K_NUM	23
+
+/* Intel 80386 specific definitions.  */
+
+/* i386 relocs.  */
+
+#define R_386_NONE	   0		/* No reloc */
+#define R_386_32	   1		/* Direct 32 bit  */
+#define R_386_PC32	   2		/* PC relative 32 bit */
+#define R_386_GOT32	   3		/* 32 bit GOT entry */
+#define R_386_PLT32	   4		/* 32 bit PLT address */
+#define R_386_COPY	   5		/* Copy symbol at runtime */
+#define R_386_GLOB_DAT	   6		/* Create GOT entry */
+#define R_386_JMP_SLOT	   7		/* Create PLT entry */
+#define R_386_RELATIVE	   8		/* Adjust by program base */
+#define R_386_GOTOFF	   9		/* 32 bit offset to GOT */
+#define R_386_GOTPC	   10		/* 32 bit PC relative offset to GOT */
+#define R_386_32PLT	   11
+#define R_386_TLS_TPOFF	   14		/* Offset in static TLS block */
+#define R_386_TLS_IE	   15		/* Address of GOT entry for static TLS
+					   block offset */
+#define R_386_TLS_GOTIE	   16		/* GOT entry for static TLS block
+					   offset */
+#define R_386_TLS_LE	   17		/* Offset relative to static TLS
+					   block */
+#define R_386_TLS_GD	   18		/* Direct 32 bit for GNU version of
+					   general dynamic thread local data */
+#define R_386_TLS_LDM	   19		/* Direct 32 bit for GNU version of
+					   local dynamic thread local data
+					   in LE code */
+#define R_386_16	   20
+#define R_386_PC16	   21
+#define R_386_8		   22
+#define R_386_PC8	   23
+#define R_386_TLS_GD_32	   24		/* Direct 32 bit for general dynamic
+					   thread local data */
+#define R_386_TLS_GD_PUSH  25		/* Tag for pushl in GD TLS code */
+#define R_386_TLS_GD_CALL  26		/* Relocation for call to
+					   __tls_get_addr() */
+#define R_386_TLS_GD_POP   27		/* Tag for popl in GD TLS code */
+#define R_386_TLS_LDM_32   28		/* Direct 32 bit for local dynamic
+					   thread local data in LE code */
+#define R_386_TLS_LDM_PUSH 29		/* Tag for pushl in LDM TLS code */
+#define R_386_TLS_LDM_CALL 30		/* Relocation for call to
+					   __tls_get_addr() in LDM code */
+#define R_386_TLS_LDM_POP  31		/* Tag for popl in LDM TLS code */
+#define R_386_TLS_LDO_32   32		/* Offset relative to TLS block */
+#define R_386_TLS_IE_32	   33		/* GOT entry for negated static TLS
+					   block offset */
+#define R_386_TLS_LE_32	   34		/* Negated offset relative to static
+					   TLS block */
+#define R_386_TLS_DTPMOD32 35		/* ID of module containing symbol */
+#define R_386_TLS_DTPOFF32 36		/* Offset in TLS block */
+#define R_386_TLS_TPOFF32  37		/* Negated offset in static TLS block */
+/* Keep this the last entry.  */
+#define R_386_NUM	   38
+
+/* SUN SPARC specific definitions.  */
+
+/* Legal values for ST_TYPE subfield of st_info (symbol type).  */
+
+#define STT_SPARC_REGISTER	13	/* Global register reserved to app. */
+
+/* Values for Elf64_Ehdr.e_flags.  */
+
+#define EF_SPARCV9_MM		3
+#define EF_SPARCV9_TSO		0
+#define EF_SPARCV9_PSO		1
+#define EF_SPARCV9_RMO		2
+#define EF_SPARC_LEDATA		0x800000 /* little endian data */
+#define EF_SPARC_EXT_MASK	0xFFFF00
+#define EF_SPARC_32PLUS		0x000100 /* generic V8+ features */
+#define EF_SPARC_SUN_US1	0x000200 /* Sun UltraSPARC1 extensions */
+#define EF_SPARC_HAL_R1		0x000400 /* HAL R1 extensions */
+#define EF_SPARC_SUN_US3	0x000800 /* Sun UltraSPARCIII extensions */
+
+/* SPARC relocs.  */
+
+#define R_SPARC_NONE		0	/* No reloc */
+#define R_SPARC_8		1	/* Direct 8 bit */
+#define R_SPARC_16		2	/* Direct 16 bit */
+#define R_SPARC_32		3	/* Direct 32 bit */
+#define R_SPARC_DISP8		4	/* PC relative 8 bit */
+#define R_SPARC_DISP16		5	/* PC relative 16 bit */
+#define R_SPARC_DISP32		6	/* PC relative 32 bit */
+#define R_SPARC_WDISP30		7	/* PC relative 30 bit shifted */
+#define R_SPARC_WDISP22		8	/* PC relative 22 bit shifted */
+#define R_SPARC_HI22		9	/* High 22 bit */
+#define R_SPARC_22		10	/* Direct 22 bit */
+#define R_SPARC_13		11	/* Direct 13 bit */
+#define R_SPARC_LO10		12	/* Truncated 10 bit */
+#define R_SPARC_GOT10		13	/* Truncated 10 bit GOT entry */
+#define R_SPARC_GOT13		14	/* 13 bit GOT entry */
+#define R_SPARC_GOT22		15	/* 22 bit GOT entry shifted */
+#define R_SPARC_PC10		16	/* PC relative 10 bit truncated */
+#define R_SPARC_PC22		17	/* PC relative 22 bit shifted */
+#define R_SPARC_WPLT30		18	/* 30 bit PC relative PLT address */
+#define R_SPARC_COPY		19	/* Copy symbol at runtime */
+#define R_SPARC_GLOB_DAT	20	/* Create GOT entry */
+#define R_SPARC_JMP_SLOT	21	/* Create PLT entry */
+#define R_SPARC_RELATIVE	22	/* Adjust by program base */
+#define R_SPARC_UA32		23	/* Direct 32 bit unaligned */
+
+/* Additional Sparc64 relocs.  */
+
+#define R_SPARC_PLT32		24	/* Direct 32 bit ref to PLT entry */
+#define R_SPARC_HIPLT22		25	/* High 22 bit PLT entry */
+#define R_SPARC_LOPLT10		26	/* Truncated 10 bit PLT entry */
+#define R_SPARC_PCPLT32		27	/* PC rel 32 bit ref to PLT entry */
+#define R_SPARC_PCPLT22		28	/* PC rel high 22 bit PLT entry */
+#define R_SPARC_PCPLT10		29	/* PC rel trunc 10 bit PLT entry */
+#define R_SPARC_10		30	/* Direct 10 bit */
+#define R_SPARC_11		31	/* Direct 11 bit */
+#define R_SPARC_64		32	/* Direct 64 bit */
+#define R_SPARC_OLO10		33	/* 10bit with secondary 13bit addend */
+#define R_SPARC_HH22		34	/* Top 22 bits of direct 64 bit */
+#define R_SPARC_HM10		35	/* High middle 10 bits of ... */
+#define R_SPARC_LM22		36	/* Low middle 22 bits of ... */
+#define R_SPARC_PC_HH22		37	/* Top 22 bits of pc rel 64 bit */
+#define R_SPARC_PC_HM10		38	/* High middle 10 bit of ... */
+#define R_SPARC_PC_LM22		39	/* Low miggle 22 bits of ... */
+#define R_SPARC_WDISP16		40	/* PC relative 16 bit shifted */
+#define R_SPARC_WDISP19		41	/* PC relative 19 bit shifted */
+#define R_SPARC_7		43	/* Direct 7 bit */
+#define R_SPARC_5		44	/* Direct 5 bit */
+#define R_SPARC_6		45	/* Direct 6 bit */
+#define R_SPARC_DISP64		46	/* PC relative 64 bit */
+#define R_SPARC_PLT64		47	/* Direct 64 bit ref to PLT entry */
+#define R_SPARC_HIX22		48	/* High 22 bit complemented */
+#define R_SPARC_LOX10		49	/* Truncated 11 bit complemented */
+#define R_SPARC_H44		50	/* Direct high 12 of 44 bit */
+#define R_SPARC_M44		51	/* Direct mid 22 of 44 bit */
+#define R_SPARC_L44		52	/* Direct low 10 of 44 bit */
+#define R_SPARC_REGISTER	53	/* Global register usage */
+#define R_SPARC_UA64		54	/* Direct 64 bit unaligned */
+#define R_SPARC_UA16		55	/* Direct 16 bit unaligned */
+#define R_SPARC_TLS_GD_HI22	56
+#define R_SPARC_TLS_GD_LO10	57
+#define R_SPARC_TLS_GD_ADD	58
+#define R_SPARC_TLS_GD_CALL	59
+#define R_SPARC_TLS_LDM_HI22	60
+#define R_SPARC_TLS_LDM_LO10	61
+#define R_SPARC_TLS_LDM_ADD	62
+#define R_SPARC_TLS_LDM_CALL	63
+#define R_SPARC_TLS_LDO_HIX22	64
+#define R_SPARC_TLS_LDO_LOX10	65
+#define R_SPARC_TLS_LDO_ADD	66
+#define R_SPARC_TLS_IE_HI22	67
+#define R_SPARC_TLS_IE_LO10	68
+#define R_SPARC_TLS_IE_LD	69
+#define R_SPARC_TLS_IE_LDX	70
+#define R_SPARC_TLS_IE_ADD	71
+#define R_SPARC_TLS_LE_HIX22	72
+#define R_SPARC_TLS_LE_LOX10	73
+#define R_SPARC_TLS_DTPMOD32	74
+#define R_SPARC_TLS_DTPMOD64	75
+#define R_SPARC_TLS_DTPOFF32	76
+#define R_SPARC_TLS_DTPOFF64	77
+#define R_SPARC_TLS_TPOFF32	78
+#define R_SPARC_TLS_TPOFF64	79
+/* Keep this the last entry.  */
+#define R_SPARC_NUM		80
+
+/* For Sparc64, legal values for d_tag of Elf64_Dyn.  */
+
+#define DT_SPARC_REGISTER 0x70000001
+#define DT_SPARC_NUM	2
+
+/* Bits present in AT_HWCAP on SPARC.  */
+
+#define HWCAP_SPARC_FLUSH	1	/* The CPU supports flush insn.  */
+#define HWCAP_SPARC_STBAR	2
+#define HWCAP_SPARC_SWAP	4
+#define HWCAP_SPARC_MULDIV	8
+#define HWCAP_SPARC_V9		16	/* The CPU is v9, so v8plus is ok.  */
+#define HWCAP_SPARC_ULTRA3	32
+#define HWCAP_SPARC_BLKINIT	64	/* Sun4v with block-init/load-twin.  */
+
+/* MIPS R3000 specific definitions.  */
+
+/* Legal values for e_flags field of Elf32_Ehdr.  */
+
+#define EF_MIPS_NOREORDER   1		/* A .noreorder directive was used */
+#define EF_MIPS_PIC	    2		/* Contains PIC code */
+#define EF_MIPS_CPIC	    4		/* Uses PIC calling sequence */
+#define EF_MIPS_XGOT	    8
+#define EF_MIPS_64BIT_WHIRL 16
+#define EF_MIPS_ABI2	    32
+#define EF_MIPS_ABI_ON32    64
+#define EF_MIPS_ARCH	    0xf0000000	/* MIPS architecture level */
+
+/* Legal values for MIPS architecture level.  */
+
+#define EF_MIPS_ARCH_1	    0x00000000	/* -mips1 code.  */
+#define EF_MIPS_ARCH_2	    0x10000000	/* -mips2 code.  */
+#define EF_MIPS_ARCH_3	    0x20000000	/* -mips3 code.  */
+#define EF_MIPS_ARCH_4	    0x30000000	/* -mips4 code.  */
+#define EF_MIPS_ARCH_5	    0x40000000	/* -mips5 code.  */
+#define EF_MIPS_ARCH_32	    0x60000000	/* MIPS32 code.  */
+#define EF_MIPS_ARCH_64	    0x70000000	/* MIPS64 code.  */
+
+/* The following are non-official names and should not be used.  */
+
+#define E_MIPS_ARCH_1	  0x00000000	/* -mips1 code.  */
+#define E_MIPS_ARCH_2	  0x10000000	/* -mips2 code.  */
+#define E_MIPS_ARCH_3	  0x20000000	/* -mips3 code.  */
+#define E_MIPS_ARCH_4	  0x30000000	/* -mips4 code.  */
+#define E_MIPS_ARCH_5	  0x40000000	/* -mips5 code.  */
+#define E_MIPS_ARCH_32	  0x60000000	/* MIPS32 code.  */
+#define E_MIPS_ARCH_64	  0x70000000	/* MIPS64 code.  */
+
+/* Special section indices.  */
+
+#define SHN_MIPS_ACOMMON    0xff00	/* Allocated common symbols */
+#define SHN_MIPS_TEXT	    0xff01	/* Allocated test symbols.  */
+#define SHN_MIPS_DATA	    0xff02	/* Allocated data symbols.  */
+#define SHN_MIPS_SCOMMON    0xff03	/* Small common symbols */
+#define SHN_MIPS_SUNDEFINED 0xff04	/* Small undefined symbols */
+
+/* Legal values for sh_type field of Elf32_Shdr.  */
+
+#define SHT_MIPS_LIBLIST       0x70000000 /* Shared objects used in link */
+#define SHT_MIPS_MSYM	       0x70000001
+#define SHT_MIPS_CONFLICT      0x70000002 /* Conflicting symbols */
+#define SHT_MIPS_GPTAB	       0x70000003 /* Global data area sizes */
+#define SHT_MIPS_UCODE	       0x70000004 /* Reserved for SGI/MIPS compilers */
+#define SHT_MIPS_DEBUG	       0x70000005 /* MIPS ECOFF debugging information*/
+#define SHT_MIPS_REGINFO       0x70000006 /* Register usage information */
+#define SHT_MIPS_PACKAGE       0x70000007
+#define SHT_MIPS_PACKSYM       0x70000008
+#define SHT_MIPS_RELD	       0x70000009
+#define SHT_MIPS_IFACE         0x7000000b
+#define SHT_MIPS_CONTENT       0x7000000c
+#define SHT_MIPS_OPTIONS       0x7000000d /* Miscellaneous options.  */
+#define SHT_MIPS_SHDR	       0x70000010
+#define SHT_MIPS_FDESC	       0x70000011
+#define SHT_MIPS_EXTSYM	       0x70000012
+#define SHT_MIPS_DENSE	       0x70000013
+#define SHT_MIPS_PDESC	       0x70000014
+#define SHT_MIPS_LOCSYM	       0x70000015
+#define SHT_MIPS_AUXSYM	       0x70000016
+#define SHT_MIPS_OPTSYM	       0x70000017
+#define SHT_MIPS_LOCSTR	       0x70000018
+#define SHT_MIPS_LINE	       0x70000019
+#define SHT_MIPS_RFDESC	       0x7000001a
+#define SHT_MIPS_DELTASYM      0x7000001b
+#define SHT_MIPS_DELTAINST     0x7000001c
+#define SHT_MIPS_DELTACLASS    0x7000001d
+#define SHT_MIPS_DWARF         0x7000001e /* DWARF debugging information.  */
+#define SHT_MIPS_DELTADECL     0x7000001f
+#define SHT_MIPS_SYMBOL_LIB    0x70000020
+#define SHT_MIPS_EVENTS	       0x70000021 /* Event section.  */
+#define SHT_MIPS_TRANSLATE     0x70000022
+#define SHT_MIPS_PIXIE	       0x70000023
+#define SHT_MIPS_XLATE	       0x70000024
+#define SHT_MIPS_XLATE_DEBUG   0x70000025
+#define SHT_MIPS_WHIRL	       0x70000026
+#define SHT_MIPS_EH_REGION     0x70000027
+#define SHT_MIPS_XLATE_OLD     0x70000028
+#define SHT_MIPS_PDR_EXCEPTION 0x70000029
+
+/* Legal values for sh_flags field of Elf32_Shdr.  */
+
+#define SHF_MIPS_GPREL	 0x10000000	/* Must be part of global data area */
+#define SHF_MIPS_MERGE	 0x20000000
+#define SHF_MIPS_ADDR	 0x40000000
+#define SHF_MIPS_STRINGS 0x80000000
+#define SHF_MIPS_NOSTRIP 0x08000000
+#define SHF_MIPS_LOCAL	 0x04000000
+#define SHF_MIPS_NAMES	 0x02000000
+#define SHF_MIPS_NODUPE	 0x01000000
+
+
+/* Symbol tables.  */
+
+/* MIPS specific values for `st_other'.  */
+#define STO_MIPS_DEFAULT		0x0
+#define STO_MIPS_INTERNAL		0x1
+#define STO_MIPS_HIDDEN			0x2
+#define STO_MIPS_PROTECTED		0x3
+#define STO_MIPS_SC_ALIGN_UNUSED	0xff
+
+/* MIPS specific values for `st_info'.  */
+#define STB_MIPS_SPLIT_COMMON		13
+
+/* Entries found in sections of type SHT_MIPS_GPTAB.  */
+
+typedef union
+{
+  struct
+    {
+      Elf32_Word gt_current_g_value;	/* -G value used for compilation */
+      Elf32_Word gt_unused;		/* Not used */
+    } gt_header;			/* First entry in section */
+  struct
+    {
+      Elf32_Word gt_g_value;		/* If this value were used for -G */
+      Elf32_Word gt_bytes;		/* This many bytes would be used */
+    } gt_entry;				/* Subsequent entries in section */
+} Elf32_gptab;
+
+/* Entry found in sections of type SHT_MIPS_REGINFO.  */
+
+typedef struct
+{
+  Elf32_Word	ri_gprmask;		/* General registers used */
+  Elf32_Word	ri_cprmask[4];		/* Coprocessor registers used */
+  Elf32_Sword	ri_gp_value;		/* $gp register value */
+} Elf32_RegInfo;
+
+/* Entries found in sections of type SHT_MIPS_OPTIONS.  */
+
+typedef struct
+{
+  unsigned char kind;		/* Determines interpretation of the
+				   variable part of descriptor.  */
+  unsigned char size;		/* Size of descriptor, including header.  */
+  Elf32_Section section;	/* Section header index of section affected,
+				   0 for global options.  */
+  Elf32_Word info;		/* Kind-specific information.  */
+} Elf_Options;
+
+/* Values for `kind' field in Elf_Options.  */
+
+#define ODK_NULL	0	/* Undefined.  */
+#define ODK_REGINFO	1	/* Register usage information.  */
+#define ODK_EXCEPTIONS	2	/* Exception processing options.  */
+#define ODK_PAD		3	/* Section padding options.  */
+#define ODK_HWPATCH	4	/* Hardware workarounds performed */
+#define ODK_FILL	5	/* record the fill value used by the linker. */
+#define ODK_TAGS	6	/* reserve space for desktop tools to write. */
+#define ODK_HWAND	7	/* HW workarounds.  'AND' bits when merging. */
+#define ODK_HWOR	8	/* HW workarounds.  'OR' bits when merging.  */
+
+/* Values for `info' in Elf_Options for ODK_EXCEPTIONS entries.  */
+
+#define OEX_FPU_MIN	0x1f	/* FPE's which MUST be enabled.  */
+#define OEX_FPU_MAX	0x1f00	/* FPE's which MAY be enabled.  */
+#define OEX_PAGE0	0x10000	/* page zero must be mapped.  */
+#define OEX_SMM		0x20000	/* Force sequential memory mode?  */
+#define OEX_FPDBUG	0x40000	/* Force floating point debug mode?  */
+#define OEX_PRECISEFP	OEX_FPDBUG
+#define OEX_DISMISS	0x80000	/* Dismiss invalid address faults?  */
+
+#define OEX_FPU_INVAL	0x10
+#define OEX_FPU_DIV0	0x08
+#define OEX_FPU_OFLO	0x04
+#define OEX_FPU_UFLO	0x02
+#define OEX_FPU_INEX	0x01
+
+/* Masks for `info' in Elf_Options for an ODK_HWPATCH entry.  */
+
+#define OHW_R4KEOP	0x1	/* R4000 end-of-page patch.  */
+#define OHW_R8KPFETCH	0x2	/* may need R8000 prefetch patch.  */
+#define OHW_R5KEOP	0x4	/* R5000 end-of-page patch.  */
+#define OHW_R5KCVTL	0x8	/* R5000 cvt.[ds].l bug.  clean=1.  */
+
+#define OPAD_PREFIX	0x1
+#define OPAD_POSTFIX	0x2
+#define OPAD_SYMBOL	0x4
+
+/* Entry found in `.options' section.  */
+
+typedef struct
+{
+  Elf32_Word hwp_flags1;	/* Extra flags.  */
+  Elf32_Word hwp_flags2;	/* Extra flags.  */
+} Elf_Options_Hw;
+
+/* Masks for `info' in ElfOptions for ODK_HWAND and ODK_HWOR entries.  */
+
+#define OHWA0_R4KEOP_CHECKED	0x00000001
+#define OHWA1_R4KEOP_CLEAN	0x00000002
+
+/* MIPS relocs.  */
+
+#define R_MIPS_NONE		0	/* No reloc */
+#define R_MIPS_16		1	/* Direct 16 bit */
+#define R_MIPS_32		2	/* Direct 32 bit */
+#define R_MIPS_REL32		3	/* PC relative 32 bit */
+#define R_MIPS_26		4	/* Direct 26 bit shifted */
+#define R_MIPS_HI16		5	/* High 16 bit */
+#define R_MIPS_LO16		6	/* Low 16 bit */
+#define R_MIPS_GPREL16		7	/* GP relative 16 bit */
+#define R_MIPS_LITERAL		8	/* 16 bit literal entry */
+#define R_MIPS_GOT16		9	/* 16 bit GOT entry */
+#define R_MIPS_PC16		10	/* PC relative 16 bit */
+#define R_MIPS_CALL16		11	/* 16 bit GOT entry for function */
+#define R_MIPS_GPREL32		12	/* GP relative 32 bit */
+
+#define R_MIPS_SHIFT5		16
+#define R_MIPS_SHIFT6		17
+#define R_MIPS_64		18
+#define R_MIPS_GOT_DISP		19
+#define R_MIPS_GOT_PAGE		20
+#define R_MIPS_GOT_OFST		21
+#define R_MIPS_GOT_HI16		22
+#define R_MIPS_GOT_LO16		23
+#define R_MIPS_SUB		24
+#define R_MIPS_INSERT_A		25
+#define R_MIPS_INSERT_B		26
+#define R_MIPS_DELETE		27
+#define R_MIPS_HIGHER		28
+#define R_MIPS_HIGHEST		29
+#define R_MIPS_CALL_HI16	30
+#define R_MIPS_CALL_LO16	31
+#define R_MIPS_SCN_DISP		32
+#define R_MIPS_REL16		33
+#define R_MIPS_ADD_IMMEDIATE	34
+#define R_MIPS_PJUMP		35
+#define R_MIPS_RELGOT		36
+#define R_MIPS_JALR		37
+#define R_MIPS_TLS_DTPMOD32	38	/* Module number 32 bit */
+#define R_MIPS_TLS_DTPREL32	39	/* Module-relative offset 32 bit */
+#define R_MIPS_TLS_DTPMOD64	40	/* Module number 64 bit */
+#define R_MIPS_TLS_DTPREL64	41	/* Module-relative offset 64 bit */
+#define R_MIPS_TLS_GD		42	/* 16 bit GOT offset for GD */
+#define R_MIPS_TLS_LDM		43	/* 16 bit GOT offset for LDM */
+#define R_MIPS_TLS_DTPREL_HI16	44	/* Module-relative offset, high 16 bits */
+#define R_MIPS_TLS_DTPREL_LO16	45	/* Module-relative offset, low 16 bits */
+#define R_MIPS_TLS_GOTTPREL	46	/* 16 bit GOT offset for IE */
+#define R_MIPS_TLS_TPREL32	47	/* TP-relative offset, 32 bit */
+#define R_MIPS_TLS_TPREL64	48	/* TP-relative offset, 64 bit */
+#define R_MIPS_TLS_TPREL_HI16	49	/* TP-relative offset, high 16 bits */
+#define R_MIPS_TLS_TPREL_LO16	50	/* TP-relative offset, low 16 bits */
+#define R_MIPS_GLOB_DAT		51
+/* Keep this the last entry.  */
+#define R_MIPS_NUM		52
+
+/* Legal values for p_type field of Elf32_Phdr.  */
+
+#define PT_MIPS_REGINFO	0x70000000	/* Register usage information */
+#define PT_MIPS_RTPROC  0x70000001	/* Runtime procedure table. */
+#define PT_MIPS_OPTIONS 0x70000002
+
+/* Special program header types.  */
+
+#define PF_MIPS_LOCAL	0x10000000
+
+/* Legal values for d_tag field of Elf32_Dyn.  */
+
+#define DT_MIPS_RLD_VERSION  0x70000001	/* Runtime linker interface version */
+#define DT_MIPS_TIME_STAMP   0x70000002	/* Timestamp */
+#define DT_MIPS_ICHECKSUM    0x70000003	/* Checksum */
+#define DT_MIPS_IVERSION     0x70000004	/* Version string (string tbl index) */
+#define DT_MIPS_FLAGS	     0x70000005	/* Flags */
+#define DT_MIPS_BASE_ADDRESS 0x70000006	/* Base address */
+#define DT_MIPS_MSYM	     0x70000007
+#define DT_MIPS_CONFLICT     0x70000008	/* Address of CONFLICT section */
+#define DT_MIPS_LIBLIST	     0x70000009	/* Address of LIBLIST section */
+#define DT_MIPS_LOCAL_GOTNO  0x7000000a	/* Number of local GOT entries */
+#define DT_MIPS_CONFLICTNO   0x7000000b	/* Number of CONFLICT entries */
+#define DT_MIPS_LIBLISTNO    0x70000010	/* Number of LIBLIST entries */
+#define DT_MIPS_SYMTABNO     0x70000011	/* Number of DYNSYM entries */
+#define DT_MIPS_UNREFEXTNO   0x70000012	/* First external DYNSYM */
+#define DT_MIPS_GOTSYM	     0x70000013	/* First GOT entry in DYNSYM */
+#define DT_MIPS_HIPAGENO     0x70000014	/* Number of GOT page table entries */
+#define DT_MIPS_RLD_MAP	     0x70000016	/* Address of run time loader map.  */
+#define DT_MIPS_DELTA_CLASS  0x70000017	/* Delta C++ class definition.  */
+#define DT_MIPS_DELTA_CLASS_NO    0x70000018 /* Number of entries in
+						DT_MIPS_DELTA_CLASS.  */
+#define DT_MIPS_DELTA_INSTANCE    0x70000019 /* Delta C++ class instances.  */
+#define DT_MIPS_DELTA_INSTANCE_NO 0x7000001a /* Number of entries in
+						DT_MIPS_DELTA_INSTANCE.  */
+#define DT_MIPS_DELTA_RELOC  0x7000001b /* Delta relocations.  */
+#define DT_MIPS_DELTA_RELOC_NO 0x7000001c /* Number of entries in
+					     DT_MIPS_DELTA_RELOC.  */
+#define DT_MIPS_DELTA_SYM    0x7000001d /* Delta symbols that Delta
+					   relocations refer to.  */
+#define DT_MIPS_DELTA_SYM_NO 0x7000001e /* Number of entries in
+					   DT_MIPS_DELTA_SYM.  */
+#define DT_MIPS_DELTA_CLASSSYM 0x70000020 /* Delta symbols that hold the
+					     class declaration.  */
+#define DT_MIPS_DELTA_CLASSSYM_NO 0x70000021 /* Number of entries in
+						DT_MIPS_DELTA_CLASSSYM.  */
+#define DT_MIPS_CXX_FLAGS    0x70000022 /* Flags indicating for C++ flavor.  */
+#define DT_MIPS_PIXIE_INIT   0x70000023
+#define DT_MIPS_SYMBOL_LIB   0x70000024
+#define DT_MIPS_LOCALPAGE_GOTIDX 0x70000025
+#define DT_MIPS_LOCAL_GOTIDX 0x70000026
+#define DT_MIPS_HIDDEN_GOTIDX 0x70000027
+#define DT_MIPS_PROTECTED_GOTIDX 0x70000028
+#define DT_MIPS_OPTIONS	     0x70000029 /* Address of .options.  */
+#define DT_MIPS_INTERFACE    0x7000002a /* Address of .interface.  */
+#define DT_MIPS_DYNSTR_ALIGN 0x7000002b
+#define DT_MIPS_INTERFACE_SIZE 0x7000002c /* Size of the .interface section. */
+#define DT_MIPS_RLD_TEXT_RESOLVE_ADDR 0x7000002d /* Address of rld_text_rsolve
+						    function stored in GOT.  */
+#define DT_MIPS_PERF_SUFFIX  0x7000002e /* Default suffix of dso to be added
+					   by rld on dlopen() calls.  */
+#define DT_MIPS_COMPACT_SIZE 0x7000002f /* (O32)Size of compact rel section. */
+#define DT_MIPS_GP_VALUE     0x70000030 /* GP value for aux GOTs.  */
+#define DT_MIPS_AUX_DYNAMIC  0x70000031 /* Address of aux .dynamic.  */
+#define DT_MIPS_NUM	     0x32
+
+/* Legal values for DT_MIPS_FLAGS Elf32_Dyn entry.  */
+
+#define RHF_NONE		   0		/* No flags */
+#define RHF_QUICKSTART		   (1 << 0)	/* Use quickstart */
+#define RHF_NOTPOT		   (1 << 1)	/* Hash size not power of 2 */
+#define RHF_NO_LIBRARY_REPLACEMENT (1 << 2)	/* Ignore LD_LIBRARY_PATH */
+#define RHF_NO_MOVE		   (1 << 3)
+#define RHF_SGI_ONLY		   (1 << 4)
+#define RHF_GUARANTEE_INIT	   (1 << 5)
+#define RHF_DELTA_C_PLUS_PLUS	   (1 << 6)
+#define RHF_GUARANTEE_START_INIT   (1 << 7)
+#define RHF_PIXIE		   (1 << 8)
+#define RHF_DEFAULT_DELAY_LOAD	   (1 << 9)
+#define RHF_REQUICKSTART	   (1 << 10)
+#define RHF_REQUICKSTARTED	   (1 << 11)
+#define RHF_CORD		   (1 << 12)
+#define RHF_NO_UNRES_UNDEF	   (1 << 13)
+#define RHF_RLD_ORDER_SAFE	   (1 << 14)
+
+/* Entries found in sections of type SHT_MIPS_LIBLIST.  */
+
+typedef struct
+{
+  Elf32_Word l_name;		/* Name (string table index) */
+  Elf32_Word l_time_stamp;	/* Timestamp */
+  Elf32_Word l_checksum;	/* Checksum */
+  Elf32_Word l_version;		/* Interface version */
+  Elf32_Word l_flags;		/* Flags */
+} Elf32_Lib;
+
+typedef struct
+{
+  Elf64_Word l_name;		/* Name (string table index) */
+  Elf64_Word l_time_stamp;	/* Timestamp */
+  Elf64_Word l_checksum;	/* Checksum */
+  Elf64_Word l_version;		/* Interface version */
+  Elf64_Word l_flags;		/* Flags */
+} Elf64_Lib;
+
+
+/* Legal values for l_flags.  */
+
+#define LL_NONE		  0
+#define LL_EXACT_MATCH	  (1 << 0)	/* Require exact match */
+#define LL_IGNORE_INT_VER (1 << 1)	/* Ignore interface version */
+#define LL_REQUIRE_MINOR  (1 << 2)
+#define LL_EXPORTS	  (1 << 3)
+#define LL_DELAY_LOAD	  (1 << 4)
+#define LL_DELTA	  (1 << 5)
+
+/* Entries found in sections of type SHT_MIPS_CONFLICT.  */
+
+typedef Elf32_Addr Elf32_Conflict;
+
+
+/* HPPA specific definitions.  */
+
+/* Legal values for e_flags field of Elf32_Ehdr.  */
+
+#define EF_PARISC_TRAPNIL	0x00010000 /* Trap nil pointer dereference.  */
+#define EF_PARISC_EXT		0x00020000 /* Program uses arch. extensions. */
+#define EF_PARISC_LSB		0x00040000 /* Program expects little endian. */
+#define EF_PARISC_WIDE		0x00080000 /* Program expects wide mode.  */
+#define EF_PARISC_NO_KABP	0x00100000 /* No kernel assisted branch
+					      prediction.  */
+#define EF_PARISC_LAZYSWAP	0x00400000 /* Allow lazy swapping.  */
+#define EF_PARISC_ARCH		0x0000ffff /* Architecture version.  */
+
+/* Defined values for `e_flags & EF_PARISC_ARCH' are:  */
+
+#define EFA_PARISC_1_0		    0x020b /* PA-RISC 1.0 big-endian.  */
+#define EFA_PARISC_1_1		    0x0210 /* PA-RISC 1.1 big-endian.  */
+#define EFA_PARISC_2_0		    0x0214 /* PA-RISC 2.0 big-endian.  */
+
+/* Additional section indeces.  */
+
+#define SHN_PARISC_ANSI_COMMON	0xff00	   /* Section for tenatively declared
+					      symbols in ANSI C.  */
+#define SHN_PARISC_HUGE_COMMON	0xff01	   /* Common blocks in huge model.  */
+
+/* Legal values for sh_type field of Elf32_Shdr.  */
+
+#define SHT_PARISC_EXT		0x70000000 /* Contains product specific ext. */
+#define SHT_PARISC_UNWIND	0x70000001 /* Unwind information.  */
+#define SHT_PARISC_DOC		0x70000002 /* Debug info for optimized code. */
+
+/* Legal values for sh_flags field of Elf32_Shdr.  */
+
+#define SHF_PARISC_SHORT	0x20000000 /* Section with short addressing. */
+#define SHF_PARISC_HUGE		0x40000000 /* Section far from gp.  */
+#define SHF_PARISC_SBP		0x80000000 /* Static branch prediction code. */
+
+/* Legal values for ST_TYPE subfield of st_info (symbol type).  */
+
+#define STT_PARISC_MILLICODE	13	/* Millicode function entry point.  */
+
+#define STT_HP_OPAQUE		(STT_LOOS + 0x1)
+#define STT_HP_STUB		(STT_LOOS + 0x2)
+
+/* HPPA relocs.  */
+
+#define R_PARISC_NONE		0	/* No reloc.  */
+#define R_PARISC_DIR32		1	/* Direct 32-bit reference.  */
+#define R_PARISC_DIR21L		2	/* Left 21 bits of eff. address.  */
+#define R_PARISC_DIR17R		3	/* Right 17 bits of eff. address.  */
+#define R_PARISC_DIR17F		4	/* 17 bits of eff. address.  */
+#define R_PARISC_DIR14R		6	/* Right 14 bits of eff. address.  */
+#define R_PARISC_PCREL32	9	/* 32-bit rel. address.  */
+#define R_PARISC_PCREL21L	10	/* Left 21 bits of rel. address.  */
+#define R_PARISC_PCREL17R	11	/* Right 17 bits of rel. address.  */
+#define R_PARISC_PCREL17F	12	/* 17 bits of rel. address.  */
+#define R_PARISC_PCREL14R	14	/* Right 14 bits of rel. address.  */
+#define R_PARISC_DPREL21L	18	/* Left 21 bits of rel. address.  */
+#define R_PARISC_DPREL14R	22	/* Right 14 bits of rel. address.  */
+#define R_PARISC_GPREL21L	26	/* GP-relative, left 21 bits.  */
+#define R_PARISC_GPREL14R	30	/* GP-relative, right 14 bits.  */
+#define R_PARISC_LTOFF21L	34	/* LT-relative, left 21 bits.  */
+#define R_PARISC_LTOFF14R	38	/* LT-relative, right 14 bits.  */
+#define R_PARISC_SECREL32	41	/* 32 bits section rel. address.  */
+#define R_PARISC_SEGBASE	48	/* No relocation, set segment base.  */
+#define R_PARISC_SEGREL32	49	/* 32 bits segment rel. address.  */
+#define R_PARISC_PLTOFF21L	50	/* PLT rel. address, left 21 bits.  */
+#define R_PARISC_PLTOFF14R	54	/* PLT rel. address, right 14 bits.  */
+#define R_PARISC_LTOFF_FPTR32	57	/* 32 bits LT-rel. function pointer. */
+#define R_PARISC_LTOFF_FPTR21L	58	/* LT-rel. fct ptr, left 21 bits. */
+#define R_PARISC_LTOFF_FPTR14R	62	/* LT-rel. fct ptr, right 14 bits. */
+#define R_PARISC_FPTR64		64	/* 64 bits function address.  */
+#define R_PARISC_PLABEL32	65	/* 32 bits function address.  */
+#define R_PARISC_PLABEL21L	66	/* Left 21 bits of fdesc address.  */
+#define R_PARISC_PLABEL14R	70	/* Right 14 bits of fdesc address.  */
+#define R_PARISC_PCREL64	72	/* 64 bits PC-rel. address.  */
+#define R_PARISC_PCREL22F	74	/* 22 bits PC-rel. address.  */
+#define R_PARISC_PCREL14WR	75	/* PC-rel. address, right 14 bits.  */
+#define R_PARISC_PCREL14DR	76	/* PC rel. address, right 14 bits.  */
+#define R_PARISC_PCREL16F	77	/* 16 bits PC-rel. address.  */
+#define R_PARISC_PCREL16WF	78	/* 16 bits PC-rel. address.  */
+#define R_PARISC_PCREL16DF	79	/* 16 bits PC-rel. address.  */
+#define R_PARISC_DIR64		80	/* 64 bits of eff. address.  */
+#define R_PARISC_DIR14WR	83	/* 14 bits of eff. address.  */
+#define R_PARISC_DIR14DR	84	/* 14 bits of eff. address.  */
+#define R_PARISC_DIR16F		85	/* 16 bits of eff. address.  */
+#define R_PARISC_DIR16WF	86	/* 16 bits of eff. address.  */
+#define R_PARISC_DIR16DF	87	/* 16 bits of eff. address.  */
+#define R_PARISC_GPREL64	88	/* 64 bits of GP-rel. address.  */
+#define R_PARISC_GPREL14WR	91	/* GP-rel. address, right 14 bits.  */
+#define R_PARISC_GPREL14DR	92	/* GP-rel. address, right 14 bits.  */
+#define R_PARISC_GPREL16F	93	/* 16 bits GP-rel. address.  */
+#define R_PARISC_GPREL16WF	94	/* 16 bits GP-rel. address.  */
+#define R_PARISC_GPREL16DF	95	/* 16 bits GP-rel. address.  */
+#define R_PARISC_LTOFF64	96	/* 64 bits LT-rel. address.  */
+#define R_PARISC_LTOFF14WR	99	/* LT-rel. address, right 14 bits.  */
+#define R_PARISC_LTOFF14DR	100	/* LT-rel. address, right 14 bits.  */
+#define R_PARISC_LTOFF16F	101	/* 16 bits LT-rel. address.  */
+#define R_PARISC_LTOFF16WF	102	/* 16 bits LT-rel. address.  */
+#define R_PARISC_LTOFF16DF	103	/* 16 bits LT-rel. address.  */
+#define R_PARISC_SECREL64	104	/* 64 bits section rel. address.  */
+#define R_PARISC_SEGREL64	112	/* 64 bits segment rel. address.  */
+#define R_PARISC_PLTOFF14WR	115	/* PLT-rel. address, right 14 bits.  */
+#define R_PARISC_PLTOFF14DR	116	/* PLT-rel. address, right 14 bits.  */
+#define R_PARISC_PLTOFF16F	117	/* 16 bits LT-rel. address.  */
+#define R_PARISC_PLTOFF16WF	118	/* 16 bits PLT-rel. address.  */
+#define R_PARISC_PLTOFF16DF	119	/* 16 bits PLT-rel. address.  */
+#define R_PARISC_LTOFF_FPTR64	120	/* 64 bits LT-rel. function ptr.  */
+#define R_PARISC_LTOFF_FPTR14WR	123	/* LT-rel. fct. ptr., right 14 bits. */
+#define R_PARISC_LTOFF_FPTR14DR	124	/* LT-rel. fct. ptr., right 14 bits. */
+#define R_PARISC_LTOFF_FPTR16F	125	/* 16 bits LT-rel. function ptr.  */
+#define R_PARISC_LTOFF_FPTR16WF	126	/* 16 bits LT-rel. function ptr.  */
+#define R_PARISC_LTOFF_FPTR16DF	127	/* 16 bits LT-rel. function ptr.  */
+#define R_PARISC_LORESERVE	128
+#define R_PARISC_COPY		128	/* Copy relocation.  */
+#define R_PARISC_IPLT		129	/* Dynamic reloc, imported PLT */
+#define R_PARISC_EPLT		130	/* Dynamic reloc, exported PLT */
+#define R_PARISC_TPREL32	153	/* 32 bits TP-rel. address.  */
+#define R_PARISC_TPREL21L	154	/* TP-rel. address, left 21 bits.  */
+#define R_PARISC_TPREL14R	158	/* TP-rel. address, right 14 bits.  */
+#define R_PARISC_LTOFF_TP21L	162	/* LT-TP-rel. address, left 21 bits. */
+#define R_PARISC_LTOFF_TP14R	166	/* LT-TP-rel. address, right 14 bits.*/
+#define R_PARISC_LTOFF_TP14F	167	/* 14 bits LT-TP-rel. address.  */
+#define R_PARISC_TPREL64	216	/* 64 bits TP-rel. address.  */
+#define R_PARISC_TPREL14WR	219	/* TP-rel. address, right 14 bits.  */
+#define R_PARISC_TPREL14DR	220	/* TP-rel. address, right 14 bits.  */
+#define R_PARISC_TPREL16F	221	/* 16 bits TP-rel. address.  */
+#define R_PARISC_TPREL16WF	222	/* 16 bits TP-rel. address.  */
+#define R_PARISC_TPREL16DF	223	/* 16 bits TP-rel. address.  */
+#define R_PARISC_LTOFF_TP64	224	/* 64 bits LT-TP-rel. address.  */
+#define R_PARISC_LTOFF_TP14WR	227	/* LT-TP-rel. address, right 14 bits.*/
+#define R_PARISC_LTOFF_TP14DR	228	/* LT-TP-rel. address, right 14 bits.*/
+#define R_PARISC_LTOFF_TP16F	229	/* 16 bits LT-TP-rel. address.  */
+#define R_PARISC_LTOFF_TP16WF	230	/* 16 bits LT-TP-rel. address.  */
+#define R_PARISC_LTOFF_TP16DF	231	/* 16 bits LT-TP-rel. address.  */
+#define R_PARISC_GNU_VTENTRY	232
+#define R_PARISC_GNU_VTINHERIT	233
+#define R_PARISC_TLS_GD21L	234	/* GD 21-bit left.  */
+#define R_PARISC_TLS_GD14R	235	/* GD 14-bit right.  */
+#define R_PARISC_TLS_GDCALL	236	/* GD call to __t_g_a.  */
+#define R_PARISC_TLS_LDM21L	237	/* LD module 21-bit left.  */
+#define R_PARISC_TLS_LDM14R	238	/* LD module 14-bit right.  */
+#define R_PARISC_TLS_LDMCALL	239	/* LD module call to __t_g_a.  */
+#define R_PARISC_TLS_LDO21L	240	/* LD offset 21-bit left.  */
+#define R_PARISC_TLS_LDO14R	241	/* LD offset 14-bit right.  */
+#define R_PARISC_TLS_DTPMOD32	242	/* DTP module 32-bit.  */
+#define R_PARISC_TLS_DTPMOD64	243	/* DTP module 64-bit.  */
+#define R_PARISC_TLS_DTPOFF32	244	/* DTP offset 32-bit.  */
+#define R_PARISC_TLS_DTPOFF64	245	/* DTP offset 32-bit.  */
+#define R_PARISC_TLS_LE21L	R_PARISC_TPREL21L
+#define R_PARISC_TLS_LE14R	R_PARISC_TPREL14R
+#define R_PARISC_TLS_IE21L	R_PARISC_LTOFF_TP21L
+#define R_PARISC_TLS_IE14R	R_PARISC_LTOFF_TP14R
+#define R_PARISC_TLS_TPREL32	R_PARISC_TPREL32
+#define R_PARISC_TLS_TPREL64	R_PARISC_TPREL64
+#define R_PARISC_HIRESERVE	255
+
+/* Legal values for p_type field of Elf32_Phdr/Elf64_Phdr.  */
+
+#define PT_HP_TLS		(PT_LOOS + 0x0)
+#define PT_HP_CORE_NONE		(PT_LOOS + 0x1)
+#define PT_HP_CORE_VERSION	(PT_LOOS + 0x2)
+#define PT_HP_CORE_KERNEL	(PT_LOOS + 0x3)
+#define PT_HP_CORE_COMM		(PT_LOOS + 0x4)
+#define PT_HP_CORE_PROC		(PT_LOOS + 0x5)
+#define PT_HP_CORE_LOADABLE	(PT_LOOS + 0x6)
+#define PT_HP_CORE_STACK	(PT_LOOS + 0x7)
+#define PT_HP_CORE_SHM		(PT_LOOS + 0x8)
+#define PT_HP_CORE_MMF		(PT_LOOS + 0x9)
+#define PT_HP_PARALLEL		(PT_LOOS + 0x10)
+#define PT_HP_FASTBIND		(PT_LOOS + 0x11)
+#define PT_HP_OPT_ANNOT		(PT_LOOS + 0x12)
+#define PT_HP_HSL_ANNOT		(PT_LOOS + 0x13)
+#define PT_HP_STACK		(PT_LOOS + 0x14)
+
+#define PT_PARISC_ARCHEXT	0x70000000
+#define PT_PARISC_UNWIND	0x70000001
+
+/* Legal values for p_flags field of Elf32_Phdr/Elf64_Phdr.  */
+
+#define PF_PARISC_SBP		0x08000000
+
+#define PF_HP_PAGE_SIZE		0x00100000
+#define PF_HP_FAR_SHARED	0x00200000
+#define PF_HP_NEAR_SHARED	0x00400000
+#define PF_HP_CODE		0x01000000
+#define PF_HP_MODIFY		0x02000000
+#define PF_HP_LAZYSWAP		0x04000000
+#define PF_HP_SBP		0x08000000
+
+
+/* Alpha specific definitions.  */
+
+/* Legal values for e_flags field of Elf64_Ehdr.  */
+
+#define EF_ALPHA_32BIT		1	/* All addresses must be < 2GB.  */
+#define EF_ALPHA_CANRELAX	2	/* Relocations for relaxing exist.  */
+
+/* Legal values for sh_type field of Elf64_Shdr.  */
+
+/* These two are primerily concerned with ECOFF debugging info.  */
+#define SHT_ALPHA_DEBUG		0x70000001
+#define SHT_ALPHA_REGINFO	0x70000002
+
+/* Legal values for sh_flags field of Elf64_Shdr.  */
+
+#define SHF_ALPHA_GPREL		0x10000000
+
+/* Legal values for st_other field of Elf64_Sym.  */
+#define STO_ALPHA_NOPV		0x80	/* No PV required.  */
+#define STO_ALPHA_STD_GPLOAD	0x88	/* PV only used for initial ldgp.  */
+
+/* Alpha relocs.  */
+
+#define R_ALPHA_NONE		0	/* No reloc */
+#define R_ALPHA_REFLONG		1	/* Direct 32 bit */
+#define R_ALPHA_REFQUAD		2	/* Direct 64 bit */
+#define R_ALPHA_GPREL32		3	/* GP relative 32 bit */
+#define R_ALPHA_LITERAL		4	/* GP relative 16 bit w/optimization */
+#define R_ALPHA_LITUSE		5	/* Optimization hint for LITERAL */
+#define R_ALPHA_GPDISP		6	/* Add displacement to GP */
+#define R_ALPHA_BRADDR		7	/* PC+4 relative 23 bit shifted */
+#define R_ALPHA_HINT		8	/* PC+4 relative 16 bit shifted */
+#define R_ALPHA_SREL16		9	/* PC relative 16 bit */
+#define R_ALPHA_SREL32		10	/* PC relative 32 bit */
+#define R_ALPHA_SREL64		11	/* PC relative 64 bit */
+#define R_ALPHA_GPRELHIGH	17	/* GP relative 32 bit, high 16 bits */
+#define R_ALPHA_GPRELLOW	18	/* GP relative 32 bit, low 16 bits */
+#define R_ALPHA_GPREL16		19	/* GP relative 16 bit */
+#define R_ALPHA_COPY		24	/* Copy symbol at runtime */
+#define R_ALPHA_GLOB_DAT	25	/* Create GOT entry */
+#define R_ALPHA_JMP_SLOT	26	/* Create PLT entry */
+#define R_ALPHA_RELATIVE	27	/* Adjust by program base */
+#define R_ALPHA_TLS_GD_HI	28
+#define R_ALPHA_TLSGD		29
+#define R_ALPHA_TLS_LDM		30
+#define R_ALPHA_DTPMOD64	31
+#define R_ALPHA_GOTDTPREL	32
+#define R_ALPHA_DTPREL64	33
+#define R_ALPHA_DTPRELHI	34
+#define R_ALPHA_DTPRELLO	35
+#define R_ALPHA_DTPREL16	36
+#define R_ALPHA_GOTTPREL	37
+#define R_ALPHA_TPREL64		38
+#define R_ALPHA_TPRELHI		39
+#define R_ALPHA_TPRELLO		40
+#define R_ALPHA_TPREL16		41
+/* Keep this the last entry.  */
+#define R_ALPHA_NUM		46
+
+/* Magic values of the LITUSE relocation addend.  */
+#define LITUSE_ALPHA_ADDR	0
+#define LITUSE_ALPHA_BASE	1
+#define LITUSE_ALPHA_BYTOFF	2
+#define LITUSE_ALPHA_JSR	3
+#define LITUSE_ALPHA_TLS_GD	4
+#define LITUSE_ALPHA_TLS_LDM	5
+
+/* Legal values for d_tag of Elf64_Dyn.  */
+#define DT_ALPHA_PLTRO		(DT_LOPROC + 0)
+#define DT_ALPHA_NUM		1
+
+/* PowerPC specific declarations */
+
+/* Values for Elf32/64_Ehdr.e_flags.  */
+#define EF_PPC_EMB		0x80000000	/* PowerPC embedded flag */
+
+/* Cygnus local bits below */
+#define EF_PPC_RELOCATABLE	0x00010000	/* PowerPC -mrelocatable flag*/
+#define EF_PPC_RELOCATABLE_LIB	0x00008000	/* PowerPC -mrelocatable-lib
+						   flag */
+
+/* PowerPC relocations defined by the ABIs */
+#define R_PPC_NONE		0
+#define R_PPC_ADDR32		1	/* 32bit absolute address */
+#define R_PPC_ADDR24		2	/* 26bit address, 2 bits ignored.  */
+#define R_PPC_ADDR16		3	/* 16bit absolute address */
+#define R_PPC_ADDR16_LO		4	/* lower 16bit of absolute address */
+#define R_PPC_ADDR16_HI		5	/* high 16bit of absolute address */
+#define R_PPC_ADDR16_HA		6	/* adjusted high 16bit */
+#define R_PPC_ADDR14		7	/* 16bit address, 2 bits ignored */
+#define R_PPC_ADDR14_BRTAKEN	8
+#define R_PPC_ADDR14_BRNTAKEN	9
+#define R_PPC_REL24		10	/* PC relative 26 bit */
+#define R_PPC_REL14		11	/* PC relative 16 bit */
+#define R_PPC_REL14_BRTAKEN	12
+#define R_PPC_REL14_BRNTAKEN	13
+#define R_PPC_GOT16		14
+#define R_PPC_GOT16_LO		15
+#define R_PPC_GOT16_HI		16
+#define R_PPC_GOT16_HA		17
+#define R_PPC_PLTREL24		18
+#define R_PPC_COPY		19
+#define R_PPC_GLOB_DAT		20
+#define R_PPC_JMP_SLOT		21
+#define R_PPC_RELATIVE		22
+#define R_PPC_LOCAL24PC		23
+#define R_PPC_UADDR32		24
+#define R_PPC_UADDR16		25
+#define R_PPC_REL32		26
+#define R_PPC_PLT32		27
+#define R_PPC_PLTREL32		28
+#define R_PPC_PLT16_LO		29
+#define R_PPC_PLT16_HI		30
+#define R_PPC_PLT16_HA		31
+#define R_PPC_SDAREL16		32
+#define R_PPC_SECTOFF		33
+#define R_PPC_SECTOFF_LO	34
+#define R_PPC_SECTOFF_HI	35
+#define R_PPC_SECTOFF_HA	36
+
+/* PowerPC relocations defined for the TLS access ABI.  */
+#define R_PPC_TLS		67 /* none	(sym+add)@tls */
+#define R_PPC_DTPMOD32		68 /* word32	(sym+add)@dtpmod */
+#define R_PPC_TPREL16		69 /* half16*	(sym+add)@tprel */
+#define R_PPC_TPREL16_LO	70 /* half16	(sym+add)@tprel at l */
+#define R_PPC_TPREL16_HI	71 /* half16	(sym+add)@tprel at h */
+#define R_PPC_TPREL16_HA	72 /* half16	(sym+add)@tprel at ha */
+#define R_PPC_TPREL32		73 /* word32	(sym+add)@tprel */
+#define R_PPC_DTPREL16		74 /* half16*	(sym+add)@dtprel */
+#define R_PPC_DTPREL16_LO	75 /* half16	(sym+add)@dtprel at l */
+#define R_PPC_DTPREL16_HI	76 /* half16	(sym+add)@dtprel at h */
+#define R_PPC_DTPREL16_HA	77 /* half16	(sym+add)@dtprel at ha */
+#define R_PPC_DTPREL32		78 /* word32	(sym+add)@dtprel */
+#define R_PPC_GOT_TLSGD16	79 /* half16*	(sym+add)@got at tlsgd */
+#define R_PPC_GOT_TLSGD16_LO	80 /* half16	(sym+add)@got at tlsgd@l */
+#define R_PPC_GOT_TLSGD16_HI	81 /* half16	(sym+add)@got at tlsgd@h */
+#define R_PPC_GOT_TLSGD16_HA	82 /* half16	(sym+add)@got at tlsgd@ha */
+#define R_PPC_GOT_TLSLD16	83 /* half16*	(sym+add)@got at tlsld */
+#define R_PPC_GOT_TLSLD16_LO	84 /* half16	(sym+add)@got at tlsld@l */
+#define R_PPC_GOT_TLSLD16_HI	85 /* half16	(sym+add)@got at tlsld@h */
+#define R_PPC_GOT_TLSLD16_HA	86 /* half16	(sym+add)@got at tlsld@ha */
+#define R_PPC_GOT_TPREL16	87 /* half16*	(sym+add)@got at tprel */
+#define R_PPC_GOT_TPREL16_LO	88 /* half16	(sym+add)@got at tprel@l */
+#define R_PPC_GOT_TPREL16_HI	89 /* half16	(sym+add)@got at tprel@h */
+#define R_PPC_GOT_TPREL16_HA	90 /* half16	(sym+add)@got at tprel@ha */
+#define R_PPC_GOT_DTPREL16	91 /* half16*	(sym+add)@got at dtprel */
+#define R_PPC_GOT_DTPREL16_LO	92 /* half16*	(sym+add)@got at dtprel@l */
+#define R_PPC_GOT_DTPREL16_HI	93 /* half16*	(sym+add)@got at dtprel@h */
+#define R_PPC_GOT_DTPREL16_HA	94 /* half16*	(sym+add)@got at dtprel@ha */
+
+/* Keep this the last entry.  */
+#define R_PPC_NUM		95
+
+/* The remaining relocs are from the Embedded ELF ABI, and are not
+   in the SVR4 ELF ABI.  */
+#define R_PPC_EMB_NADDR32	101
+#define R_PPC_EMB_NADDR16	102
+#define R_PPC_EMB_NADDR16_LO	103
+#define R_PPC_EMB_NADDR16_HI	104
+#define R_PPC_EMB_NADDR16_HA	105
+#define R_PPC_EMB_SDAI16	106
+#define R_PPC_EMB_SDA2I16	107
+#define R_PPC_EMB_SDA2REL	108
+#define R_PPC_EMB_SDA21		109	/* 16 bit offset in SDA */
+#define R_PPC_EMB_MRKREF	110
+#define R_PPC_EMB_RELSEC16	111
+#define R_PPC_EMB_RELST_LO	112
+#define R_PPC_EMB_RELST_HI	113
+#define R_PPC_EMB_RELST_HA	114
+#define R_PPC_EMB_BIT_FLD	115
+#define R_PPC_EMB_RELSDA	116	/* 16 bit relative offset in SDA */
+
+/* Diab tool relocations.  */
+#define R_PPC_DIAB_SDA21_LO	180	/* like EMB_SDA21, but lower 16 bit */
+#define R_PPC_DIAB_SDA21_HI	181	/* like EMB_SDA21, but high 16 bit */
+#define R_PPC_DIAB_SDA21_HA	182	/* like EMB_SDA21, adjusted high 16 */
+#define R_PPC_DIAB_RELSDA_LO	183	/* like EMB_RELSDA, but lower 16 bit */
+#define R_PPC_DIAB_RELSDA_HI	184	/* like EMB_RELSDA, but high 16 bit */
+#define R_PPC_DIAB_RELSDA_HA	185	/* like EMB_RELSDA, adjusted high 16 */
+
+/* GNU relocs used in PIC code sequences.  */
+#define R_PPC_REL16		249	/* word32   (sym-.) */
+#define R_PPC_REL16_LO		250	/* half16   (sym-.)@l */
+#define R_PPC_REL16_HI		251	/* half16   (sym-.)@h */
+#define R_PPC_REL16_HA		252	/* half16   (sym-.)@ha */
+
+/* This is a phony reloc to handle any old fashioned TOC16 references
+   that may still be in object files.  */
+#define R_PPC_TOC16		255
+
+/* PowerPC specific values for the Dyn d_tag field.  */
+#define DT_PPC_GOT		(DT_LOPROC + 0)
+#define DT_PPC_NUM		1
+
+/* PowerPC64 relocations defined by the ABIs */
+#define R_PPC64_NONE		R_PPC_NONE
+#define R_PPC64_ADDR32		R_PPC_ADDR32 /* 32bit absolute address */
+#define R_PPC64_ADDR24		R_PPC_ADDR24 /* 26bit address, word aligned */
+#define R_PPC64_ADDR16		R_PPC_ADDR16 /* 16bit absolute address */
+#define R_PPC64_ADDR16_LO	R_PPC_ADDR16_LO	/* lower 16bits of address */
+#define R_PPC64_ADDR16_HI	R_PPC_ADDR16_HI	/* high 16bits of address. */
+#define R_PPC64_ADDR16_HA	R_PPC_ADDR16_HA /* adjusted high 16bits.  */
+#define R_PPC64_ADDR14		R_PPC_ADDR14 /* 16bit address, word aligned */
+#define R_PPC64_ADDR14_BRTAKEN	R_PPC_ADDR14_BRTAKEN
+#define R_PPC64_ADDR14_BRNTAKEN	R_PPC_ADDR14_BRNTAKEN
+#define R_PPC64_REL24		R_PPC_REL24 /* PC-rel. 26 bit, word aligned */
+#define R_PPC64_REL14		R_PPC_REL14 /* PC relative 16 bit */
+#define R_PPC64_REL14_BRTAKEN	R_PPC_REL14_BRTAKEN
+#define R_PPC64_REL14_BRNTAKEN	R_PPC_REL14_BRNTAKEN
+#define R_PPC64_GOT16		R_PPC_GOT16
+#define R_PPC64_GOT16_LO	R_PPC_GOT16_LO
+#define R_PPC64_GOT16_HI	R_PPC_GOT16_HI
+#define R_PPC64_GOT16_HA	R_PPC_GOT16_HA
+
+#define R_PPC64_COPY		R_PPC_COPY
+#define R_PPC64_GLOB_DAT	R_PPC_GLOB_DAT
+#define R_PPC64_JMP_SLOT	R_PPC_JMP_SLOT
+#define R_PPC64_RELATIVE	R_PPC_RELATIVE
+
+#define R_PPC64_UADDR32		R_PPC_UADDR32
+#define R_PPC64_UADDR16		R_PPC_UADDR16
+#define R_PPC64_REL32		R_PPC_REL32
+#define R_PPC64_PLT32		R_PPC_PLT32
+#define R_PPC64_PLTREL32	R_PPC_PLTREL32
+#define R_PPC64_PLT16_LO	R_PPC_PLT16_LO
+#define R_PPC64_PLT16_HI	R_PPC_PLT16_HI
+#define R_PPC64_PLT16_HA	R_PPC_PLT16_HA
+
+#define R_PPC64_SECTOFF		R_PPC_SECTOFF
+#define R_PPC64_SECTOFF_LO	R_PPC_SECTOFF_LO
+#define R_PPC64_SECTOFF_HI	R_PPC_SECTOFF_HI
+#define R_PPC64_SECTOFF_HA	R_PPC_SECTOFF_HA
+#define R_PPC64_ADDR30		37 /* word30 (S + A - P) >> 2 */
+#define R_PPC64_ADDR64		38 /* doubleword64 S + A */
+#define R_PPC64_ADDR16_HIGHER	39 /* half16 #higher(S + A) */
+#define R_PPC64_ADDR16_HIGHERA	40 /* half16 #highera(S + A) */
+#define R_PPC64_ADDR16_HIGHEST	41 /* half16 #highest(S + A) */
+#define R_PPC64_ADDR16_HIGHESTA	42 /* half16 #highesta(S + A) */
+#define R_PPC64_UADDR64		43 /* doubleword64 S + A */
+#define R_PPC64_REL64		44 /* doubleword64 S + A - P */
+#define R_PPC64_PLT64		45 /* doubleword64 L + A */
+#define R_PPC64_PLTREL64	46 /* doubleword64 L + A - P */
+#define R_PPC64_TOC16		47 /* half16* S + A - .TOC */
+#define R_PPC64_TOC16_LO	48 /* half16 #lo(S + A - .TOC.) */
+#define R_PPC64_TOC16_HI	49 /* half16 #hi(S + A - .TOC.) */
+#define R_PPC64_TOC16_HA	50 /* half16 #ha(S + A - .TOC.) */
+#define R_PPC64_TOC		51 /* doubleword64 .TOC */
+#define R_PPC64_PLTGOT16	52 /* half16* M + A */
+#define R_PPC64_PLTGOT16_LO	53 /* half16 #lo(M + A) */
+#define R_PPC64_PLTGOT16_HI	54 /* half16 #hi(M + A) */
+#define R_PPC64_PLTGOT16_HA	55 /* half16 #ha(M + A) */
+
+#define R_PPC64_ADDR16_DS	56 /* half16ds* (S + A) >> 2 */
+#define R_PPC64_ADDR16_LO_DS	57 /* half16ds  #lo(S + A) >> 2 */
+#define R_PPC64_GOT16_DS	58 /* half16ds* (G + A) >> 2 */
+#define R_PPC64_GOT16_LO_DS	59 /* half16ds  #lo(G + A) >> 2 */
+#define R_PPC64_PLT16_LO_DS	60 /* half16ds  #lo(L + A) >> 2 */
+#define R_PPC64_SECTOFF_DS	61 /* half16ds* (R + A) >> 2 */
+#define R_PPC64_SECTOFF_LO_DS	62 /* half16ds  #lo(R + A) >> 2 */
+#define R_PPC64_TOC16_DS	63 /* half16ds* (S + A - .TOC.) >> 2 */
+#define R_PPC64_TOC16_LO_DS	64 /* half16ds  #lo(S + A - .TOC.) >> 2 */
+#define R_PPC64_PLTGOT16_DS	65 /* half16ds* (M + A) >> 2 */
+#define R_PPC64_PLTGOT16_LO_DS	66 /* half16ds  #lo(M + A) >> 2 */
+
+/* PowerPC64 relocations defined for the TLS access ABI.  */
+#define R_PPC64_TLS		67 /* none	(sym+add)@tls */
+#define R_PPC64_DTPMOD64	68 /* doubleword64 (sym+add)@dtpmod */
+#define R_PPC64_TPREL16		69 /* half16*	(sym+add)@tprel */
+#define R_PPC64_TPREL16_LO	70 /* half16	(sym+add)@tprel at l */
+#define R_PPC64_TPREL16_HI	71 /* half16	(sym+add)@tprel at h */
+#define R_PPC64_TPREL16_HA	72 /* half16	(sym+add)@tprel at ha */
+#define R_PPC64_TPREL64		73 /* doubleword64 (sym+add)@tprel */
+#define R_PPC64_DTPREL16	74 /* half16*	(sym+add)@dtprel */
+#define R_PPC64_DTPREL16_LO	75 /* half16	(sym+add)@dtprel at l */
+#define R_PPC64_DTPREL16_HI	76 /* half16	(sym+add)@dtprel at h */
+#define R_PPC64_DTPREL16_HA	77 /* half16	(sym+add)@dtprel at ha */
+#define R_PPC64_DTPREL64	78 /* doubleword64 (sym+add)@dtprel */
+#define R_PPC64_GOT_TLSGD16	79 /* half16*	(sym+add)@got at tlsgd */
+#define R_PPC64_GOT_TLSGD16_LO	80 /* half16	(sym+add)@got at tlsgd@l */
+#define R_PPC64_GOT_TLSGD16_HI	81 /* half16	(sym+add)@got at tlsgd@h */
+#define R_PPC64_GOT_TLSGD16_HA	82 /* half16	(sym+add)@got at tlsgd@ha */
+#define R_PPC64_GOT_TLSLD16	83 /* half16*	(sym+add)@got at tlsld */
+#define R_PPC64_GOT_TLSLD16_LO	84 /* half16	(sym+add)@got at tlsld@l */
+#define R_PPC64_GOT_TLSLD16_HI	85 /* half16	(sym+add)@got at tlsld@h */
+#define R_PPC64_GOT_TLSLD16_HA	86 /* half16	(sym+add)@got at tlsld@ha */
+#define R_PPC64_GOT_TPREL16_DS	87 /* half16ds*	(sym+add)@got at tprel */
+#define R_PPC64_GOT_TPREL16_LO_DS 88 /* half16ds (sym+add)@got at tprel@l */
+#define R_PPC64_GOT_TPREL16_HI	89 /* half16	(sym+add)@got at tprel@h */
+#define R_PPC64_GOT_TPREL16_HA	90 /* half16	(sym+add)@got at tprel@ha */
+#define R_PPC64_GOT_DTPREL16_DS	91 /* half16ds*	(sym+add)@got at dtprel */
+#define R_PPC64_GOT_DTPREL16_LO_DS 92 /* half16ds (sym+add)@got at dtprel@l */
+#define R_PPC64_GOT_DTPREL16_HI	93 /* half16	(sym+add)@got at dtprel@h */
+#define R_PPC64_GOT_DTPREL16_HA	94 /* half16	(sym+add)@got at dtprel@ha */
+#define R_PPC64_TPREL16_DS	95 /* half16ds*	(sym+add)@tprel */
+#define R_PPC64_TPREL16_LO_DS	96 /* half16ds	(sym+add)@tprel at l */
+#define R_PPC64_TPREL16_HIGHER	97 /* half16	(sym+add)@tprel at higher */
+#define R_PPC64_TPREL16_HIGHERA	98 /* half16	(sym+add)@tprel at highera */
+#define R_PPC64_TPREL16_HIGHEST	99 /* half16	(sym+add)@tprel at highest */
+#define R_PPC64_TPREL16_HIGHESTA 100 /* half16	(sym+add)@tprel at highesta */
+#define R_PPC64_DTPREL16_DS	101 /* half16ds* (sym+add)@dtprel */
+#define R_PPC64_DTPREL16_LO_DS	102 /* half16ds	(sym+add)@dtprel at l */
+#define R_PPC64_DTPREL16_HIGHER	103 /* half16	(sym+add)@dtprel at higher */
+#define R_PPC64_DTPREL16_HIGHERA 104 /* half16	(sym+add)@dtprel at highera */
+#define R_PPC64_DTPREL16_HIGHEST 105 /* half16	(sym+add)@dtprel at highest */
+#define R_PPC64_DTPREL16_HIGHESTA 106 /* half16	(sym+add)@dtprel at highesta */
+
+/* Keep this the last entry.  */
+#define R_PPC64_NUM		107
+
+/* PowerPC64 specific values for the Dyn d_tag field.  */
+#define DT_PPC64_GLINK  (DT_LOPROC + 0)
+#define DT_PPC64_OPD	(DT_LOPROC + 1)
+#define DT_PPC64_OPDSZ	(DT_LOPROC + 2)
+#define DT_PPC64_NUM    3
+
+
+/* ARM specific declarations */
+
+/* Processor specific flags for the ELF header e_flags field.  */
+#define EF_ARM_RELEXEC     0x01
+#define EF_ARM_HASENTRY    0x02
+#define EF_ARM_INTERWORK   0x04
+#define EF_ARM_APCS_26     0x08
+#define EF_ARM_APCS_FLOAT  0x10
+#define EF_ARM_PIC         0x20
+#define EF_ARM_ALIGN8      0x40		/* 8-bit structure alignment is in use */
+#define EF_ARM_NEW_ABI     0x80
+#define EF_ARM_OLD_ABI     0x100
+
+/* Other constants defined in the ARM ELF spec. version B-01.  */
+/* NB. These conflict with values defined above.  */
+#define EF_ARM_SYMSARESORTED	0x04
+#define EF_ARM_DYNSYMSUSESEGIDX 0x08
+#define EF_ARM_MAPSYMSFIRST	0x10
+#define EF_ARM_EABIMASK		0XFF000000
+
+#define EF_ARM_EABI_VERSION(flags) ((flags) & EF_ARM_EABIMASK)
+#define EF_ARM_EABI_UNKNOWN  0x00000000
+#define EF_ARM_EABI_VER1     0x01000000
+#define EF_ARM_EABI_VER2     0x02000000
+
+/* Additional symbol types for Thumb */
+#define STT_ARM_TFUNC      0xd
+
+/* ARM-specific values for sh_flags */
+#define SHF_ARM_ENTRYSECT  0x10000000   /* Section contains an entry point */
+#define SHF_ARM_COMDEF     0x80000000   /* Section may be multiply defined
+					   in the input to a link step */
+
+/* ARM-specific program header flags */
+#define PF_ARM_SB          0x10000000   /* Segment contains the location
+					   addressed by the static base */
+
+/* Processor specific values for the Phdr p_type field.  */
+#define PT_ARM_EXIDX	0x70000001	/* .ARM.exidx segment */
+
+/* ARM relocs.  */
+
+#define R_ARM_NONE		0	/* No reloc */
+#define R_ARM_PC24		1	/* PC relative 26 bit branch */
+#define R_ARM_ABS32		2	/* Direct 32 bit  */
+#define R_ARM_REL32		3	/* PC relative 32 bit */
+#define R_ARM_PC13		4
+#define R_ARM_ABS16		5	/* Direct 16 bit */
+#define R_ARM_ABS12		6	/* Direct 12 bit */
+#define R_ARM_THM_ABS5		7
+#define R_ARM_ABS8		8	/* Direct 8 bit */
+#define R_ARM_SBREL32		9
+#define R_ARM_THM_PC22		10
+#define R_ARM_THM_PC8		11
+#define R_ARM_AMP_VCALL9	12
+#define R_ARM_SWI24		13
+#define R_ARM_THM_SWI8		14
+#define R_ARM_XPC25		15
+#define R_ARM_THM_XPC22		16
+#define R_ARM_TLS_DTPMOD32	17	/* ID of module containing symbol */
+#define R_ARM_TLS_DTPOFF32	18	/* Offset in TLS block */
+#define R_ARM_TLS_TPOFF32	19	/* Offset in static TLS block */
+#define R_ARM_COPY		20	/* Copy symbol at runtime */
+#define R_ARM_GLOB_DAT		21	/* Create GOT entry */
+#define R_ARM_JUMP_SLOT		22	/* Create PLT entry */
+#define R_ARM_RELATIVE		23	/* Adjust by program base */
+#define R_ARM_GOTOFF		24	/* 32 bit offset to GOT */
+#define R_ARM_GOTPC		25	/* 32 bit PC relative offset to GOT */
+#define R_ARM_GOT32		26	/* 32 bit GOT entry */
+#define R_ARM_PLT32		27	/* 32 bit PLT address */
+#define R_ARM_ALU_PCREL_7_0	32
+#define R_ARM_ALU_PCREL_15_8	33
+#define R_ARM_ALU_PCREL_23_15	34
+#define R_ARM_LDR_SBREL_11_0	35
+#define R_ARM_ALU_SBREL_19_12	36
+#define R_ARM_ALU_SBREL_27_20	37
+#define R_ARM_GNU_VTENTRY	100
+#define R_ARM_GNU_VTINHERIT	101
+#define R_ARM_THM_PC11		102	/* thumb unconditional branch */
+#define R_ARM_THM_PC9		103	/* thumb conditional branch */
+#define R_ARM_TLS_GD32		104	/* PC-rel 32 bit for global dynamic
+					   thread local data */
+#define R_ARM_TLS_LDM32		105	/* PC-rel 32 bit for local dynamic
+					   thread local data */
+#define R_ARM_TLS_LDO32		106	/* 32 bit offset relative to TLS
+					   block */
+#define R_ARM_TLS_IE32		107	/* PC-rel 32 bit for GOT entry of
+					   static TLS block offset */
+#define R_ARM_TLS_LE32		108	/* 32 bit offset relative to static
+					   TLS block */
+#define R_ARM_RXPC25		249
+#define R_ARM_RSBREL32		250
+#define R_ARM_THM_RPC22		251
+#define R_ARM_RREL32		252
+#define R_ARM_RABS22		253
+#define R_ARM_RPC24		254
+#define R_ARM_RBASE		255
+/* Keep this the last entry.  */
+#define R_ARM_NUM		256
+
+/* IA-64 specific declarations.  */
+
+/* Processor specific flags for the Ehdr e_flags field.  */
+#define EF_IA_64_MASKOS		0x0000000f	/* os-specific flags */
+#define EF_IA_64_ABI64		0x00000010	/* 64-bit ABI */
+#define EF_IA_64_ARCH		0xff000000	/* arch. version mask */
+
+/* Processor specific values for the Phdr p_type field.  */
+#define PT_IA_64_ARCHEXT	(PT_LOPROC + 0)	/* arch extension bits */
+#define PT_IA_64_UNWIND		(PT_LOPROC + 1)	/* ia64 unwind bits */
+#define PT_IA_64_HP_OPT_ANOT	(PT_LOOS + 0x12)
+#define PT_IA_64_HP_HSL_ANOT	(PT_LOOS + 0x13)
+#define PT_IA_64_HP_STACK	(PT_LOOS + 0x14)
+
+/* Processor specific flags for the Phdr p_flags field.  */
+#define PF_IA_64_NORECOV	0x80000000	/* spec insns w/o recovery */
+
+/* Processor specific values for the Shdr sh_type field.  */
+#define SHT_IA_64_EXT		(SHT_LOPROC + 0) /* extension bits */
+#define SHT_IA_64_UNWIND	(SHT_LOPROC + 1) /* unwind bits */
+
+/* Processor specific flags for the Shdr sh_flags field.  */
+#define SHF_IA_64_SHORT		0x10000000	/* section near gp */
+#define SHF_IA_64_NORECOV	0x20000000	/* spec insns w/o recovery */
+
+/* Processor specific values for the Dyn d_tag field.  */
+#define DT_IA_64_PLT_RESERVE	(DT_LOPROC + 0)
+#define DT_IA_64_NUM		1
+
+/* IA-64 relocations.  */
+#define R_IA64_NONE		0x00	/* none */
+#define R_IA64_IMM14		0x21	/* symbol + addend, add imm14 */
+#define R_IA64_IMM22		0x22	/* symbol + addend, add imm22 */
+#define R_IA64_IMM64		0x23	/* symbol + addend, mov imm64 */
+#define R_IA64_DIR32MSB		0x24	/* symbol + addend, data4 MSB */
+#define R_IA64_DIR32LSB		0x25	/* symbol + addend, data4 LSB */
+#define R_IA64_DIR64MSB		0x26	/* symbol + addend, data8 MSB */
+#define R_IA64_DIR64LSB		0x27	/* symbol + addend, data8 LSB */
+#define R_IA64_GPREL22		0x2a	/* @gprel(sym + add), add imm22 */
+#define R_IA64_GPREL64I		0x2b	/* @gprel(sym + add), mov imm64 */
+#define R_IA64_GPREL32MSB	0x2c	/* @gprel(sym + add), data4 MSB */
+#define R_IA64_GPREL32LSB	0x2d	/* @gprel(sym + add), data4 LSB */
+#define R_IA64_GPREL64MSB	0x2e	/* @gprel(sym + add), data8 MSB */
+#define R_IA64_GPREL64LSB	0x2f	/* @gprel(sym + add), data8 LSB */
+#define R_IA64_LTOFF22		0x32	/* @ltoff(sym + add), add imm22 */
+#define R_IA64_LTOFF64I		0x33	/* @ltoff(sym + add), mov imm64 */
+#define R_IA64_PLTOFF22		0x3a	/* @pltoff(sym + add), add imm22 */
+#define R_IA64_PLTOFF64I	0x3b	/* @pltoff(sym + add), mov imm64 */
+#define R_IA64_PLTOFF64MSB	0x3e	/* @pltoff(sym + add), data8 MSB */
+#define R_IA64_PLTOFF64LSB	0x3f	/* @pltoff(sym + add), data8 LSB */
+#define R_IA64_FPTR64I		0x43	/* @fptr(sym + add), mov imm64 */
+#define R_IA64_FPTR32MSB	0x44	/* @fptr(sym + add), data4 MSB */
+#define R_IA64_FPTR32LSB	0x45	/* @fptr(sym + add), data4 LSB */
+#define R_IA64_FPTR64MSB	0x46	/* @fptr(sym + add), data8 MSB */
+#define R_IA64_FPTR64LSB	0x47	/* @fptr(sym + add), data8 LSB */
+#define R_IA64_PCREL60B		0x48	/* @pcrel(sym + add), brl */
+#define R_IA64_PCREL21B		0x49	/* @pcrel(sym + add), ptb, call */
+#define R_IA64_PCREL21M		0x4a	/* @pcrel(sym + add), chk.s */
+#define R_IA64_PCREL21F		0x4b	/* @pcrel(sym + add), fchkf */
+#define R_IA64_PCREL32MSB	0x4c	/* @pcrel(sym + add), data4 MSB */
+#define R_IA64_PCREL32LSB	0x4d	/* @pcrel(sym + add), data4 LSB */
+#define R_IA64_PCREL64MSB	0x4e	/* @pcrel(sym + add), data8 MSB */
+#define R_IA64_PCREL64LSB	0x4f	/* @pcrel(sym + add), data8 LSB */
+#define R_IA64_LTOFF_FPTR22	0x52	/* @ltoff(@fptr(s+a)), imm22 */
+#define R_IA64_LTOFF_FPTR64I	0x53	/* @ltoff(@fptr(s+a)), imm64 */
+#define R_IA64_LTOFF_FPTR32MSB	0x54	/* @ltoff(@fptr(s+a)), data4 MSB */
+#define R_IA64_LTOFF_FPTR32LSB	0x55	/* @ltoff(@fptr(s+a)), data4 LSB */
+#define R_IA64_LTOFF_FPTR64MSB	0x56	/* @ltoff(@fptr(s+a)), data8 MSB */
+#define R_IA64_LTOFF_FPTR64LSB	0x57	/* @ltoff(@fptr(s+a)), data8 LSB */
+#define R_IA64_SEGREL32MSB	0x5c	/* @segrel(sym + add), data4 MSB */
+#define R_IA64_SEGREL32LSB	0x5d	/* @segrel(sym + add), data4 LSB */
+#define R_IA64_SEGREL64MSB	0x5e	/* @segrel(sym + add), data8 MSB */
+#define R_IA64_SEGREL64LSB	0x5f	/* @segrel(sym + add), data8 LSB */
+#define R_IA64_SECREL32MSB	0x64	/* @secrel(sym + add), data4 MSB */
+#define R_IA64_SECREL32LSB	0x65	/* @secrel(sym + add), data4 LSB */
+#define R_IA64_SECREL64MSB	0x66	/* @secrel(sym + add), data8 MSB */
+#define R_IA64_SECREL64LSB	0x67	/* @secrel(sym + add), data8 LSB */
+#define R_IA64_REL32MSB		0x6c	/* data 4 + REL */
+#define R_IA64_REL32LSB		0x6d	/* data 4 + REL */
+#define R_IA64_REL64MSB		0x6e	/* data 8 + REL */
+#define R_IA64_REL64LSB		0x6f	/* data 8 + REL */
+#define R_IA64_LTV32MSB		0x74	/* symbol + addend, data4 MSB */
+#define R_IA64_LTV32LSB		0x75	/* symbol + addend, data4 LSB */
+#define R_IA64_LTV64MSB		0x76	/* symbol + addend, data8 MSB */
+#define R_IA64_LTV64LSB		0x77	/* symbol + addend, data8 LSB */
+#define R_IA64_PCREL21BI	0x79	/* @pcrel(sym + add), 21bit inst */
+#define R_IA64_PCREL22		0x7a	/* @pcrel(sym + add), 22bit inst */
+#define R_IA64_PCREL64I		0x7b	/* @pcrel(sym + add), 64bit inst */
+#define R_IA64_IPLTMSB		0x80	/* dynamic reloc, imported PLT, MSB */
+#define R_IA64_IPLTLSB		0x81	/* dynamic reloc, imported PLT, LSB */
+#define R_IA64_COPY		0x84	/* copy relocation */
+#define R_IA64_SUB		0x85	/* Addend and symbol difference */
+#define R_IA64_LTOFF22X		0x86	/* LTOFF22, relaxable.  */
+#define R_IA64_LDXMOV		0x87	/* Use of LTOFF22X.  */
+#define R_IA64_TPREL14		0x91	/* @tprel(sym + add), imm14 */
+#define R_IA64_TPREL22		0x92	/* @tprel(sym + add), imm22 */
+#define R_IA64_TPREL64I		0x93	/* @tprel(sym + add), imm64 */
+#define R_IA64_TPREL64MSB	0x96	/* @tprel(sym + add), data8 MSB */
+#define R_IA64_TPREL64LSB	0x97	/* @tprel(sym + add), data8 LSB */
+#define R_IA64_LTOFF_TPREL22	0x9a	/* @ltoff(@tprel(s+a)), imm2 */
+#define R_IA64_DTPMOD64MSB	0xa6	/* @dtpmod(sym + add), data8 MSB */
+#define R_IA64_DTPMOD64LSB	0xa7	/* @dtpmod(sym + add), data8 LSB */
+#define R_IA64_LTOFF_DTPMOD22	0xaa	/* @ltoff(@dtpmod(sym + add)), imm22 */
+#define R_IA64_DTPREL14		0xb1	/* @dtprel(sym + add), imm14 */
+#define R_IA64_DTPREL22		0xb2	/* @dtprel(sym + add), imm22 */
+#define R_IA64_DTPREL64I	0xb3	/* @dtprel(sym + add), imm64 */
+#define R_IA64_DTPREL32MSB	0xb4	/* @dtprel(sym + add), data4 MSB */
+#define R_IA64_DTPREL32LSB	0xb5	/* @dtprel(sym + add), data4 LSB */
+#define R_IA64_DTPREL64MSB	0xb6	/* @dtprel(sym + add), data8 MSB */
+#define R_IA64_DTPREL64LSB	0xb7	/* @dtprel(sym + add), data8 LSB */
+#define R_IA64_LTOFF_DTPREL22	0xba	/* @ltoff(@dtprel(s+a)), imm22 */
+
+/* SH specific declarations */
+
+/* SH relocs.  */
+#define	R_SH_NONE		0
+#define	R_SH_DIR32		1
+#define	R_SH_REL32		2
+#define	R_SH_DIR8WPN		3
+#define	R_SH_IND12W		4
+#define	R_SH_DIR8WPL		5
+#define	R_SH_DIR8WPZ		6
+#define	R_SH_DIR8BP		7
+#define	R_SH_DIR8W		8
+#define	R_SH_DIR8L		9
+#define	R_SH_SWITCH16		25
+#define	R_SH_SWITCH32		26
+#define	R_SH_USES		27
+#define	R_SH_COUNT		28
+#define	R_SH_ALIGN		29
+#define	R_SH_CODE		30
+#define	R_SH_DATA		31
+#define	R_SH_LABEL		32
+#define	R_SH_SWITCH8		33
+#define	R_SH_GNU_VTINHERIT	34
+#define	R_SH_GNU_VTENTRY	35
+#define	R_SH_TLS_GD_32		144
+#define	R_SH_TLS_LD_32		145
+#define	R_SH_TLS_LDO_32		146
+#define	R_SH_TLS_IE_32		147
+#define	R_SH_TLS_LE_32		148
+#define	R_SH_TLS_DTPMOD32	149
+#define	R_SH_TLS_DTPOFF32	150
+#define	R_SH_TLS_TPOFF32	151
+#define	R_SH_GOT32		160
+#define	R_SH_PLT32		161
+#define	R_SH_COPY		162
+#define	R_SH_GLOB_DAT		163
+#define	R_SH_JMP_SLOT		164
+#define	R_SH_RELATIVE		165
+#define	R_SH_GOTOFF		166
+#define	R_SH_GOTPC		167
+/* Keep this the last entry.  */
+#define	R_SH_NUM		256
+
+/* Additional s390 relocs */
+
+#define R_390_NONE		0	/* No reloc.  */
+#define R_390_8			1	/* Direct 8 bit.  */
+#define R_390_12		2	/* Direct 12 bit.  */
+#define R_390_16		3	/* Direct 16 bit.  */
+#define R_390_32		4	/* Direct 32 bit.  */
+#define R_390_PC32		5	/* PC relative 32 bit.	*/
+#define R_390_GOT12		6	/* 12 bit GOT offset.  */
+#define R_390_GOT32		7	/* 32 bit GOT offset.  */
+#define R_390_PLT32		8	/* 32 bit PC relative PLT address.  */
+#define R_390_COPY		9	/* Copy symbol at runtime.  */
+#define R_390_GLOB_DAT		10	/* Create GOT entry.  */
+#define R_390_JMP_SLOT		11	/* Create PLT entry.  */
+#define R_390_RELATIVE		12	/* Adjust by program base.  */
+#define R_390_GOTOFF32		13	/* 32 bit offset to GOT.	 */
+#define R_390_GOTPC		14	/* 32 bit PC relative offset to GOT.  */
+#define R_390_GOT16		15	/* 16 bit GOT offset.  */
+#define R_390_PC16		16	/* PC relative 16 bit.	*/
+#define R_390_PC16DBL		17	/* PC relative 16 bit shifted by 1.  */
+#define R_390_PLT16DBL		18	/* 16 bit PC rel. PLT shifted by 1.  */
+#define R_390_PC32DBL		19	/* PC relative 32 bit shifted by 1.  */
+#define R_390_PLT32DBL		20	/* 32 bit PC rel. PLT shifted by 1.  */
+#define R_390_GOTPCDBL		21	/* 32 bit PC rel. GOT shifted by 1.  */
+#define R_390_64		22	/* Direct 64 bit.  */
+#define R_390_PC64		23	/* PC relative 64 bit.	*/
+#define R_390_GOT64		24	/* 64 bit GOT offset.  */
+#define R_390_PLT64		25	/* 64 bit PC relative PLT address.  */
+#define R_390_GOTENT		26	/* 32 bit PC rel. to GOT entry >> 1. */
+#define R_390_GOTOFF16		27	/* 16 bit offset to GOT. */
+#define R_390_GOTOFF64		28	/* 64 bit offset to GOT. */
+#define R_390_GOTPLT12		29	/* 12 bit offset to jump slot.	*/
+#define R_390_GOTPLT16		30	/* 16 bit offset to jump slot.	*/
+#define R_390_GOTPLT32		31	/* 32 bit offset to jump slot.	*/
+#define R_390_GOTPLT64		32	/* 64 bit offset to jump slot.	*/
+#define R_390_GOTPLTENT		33	/* 32 bit rel. offset to jump slot.  */
+#define R_390_PLTOFF16		34	/* 16 bit offset from GOT to PLT. */
+#define R_390_PLTOFF32		35	/* 32 bit offset from GOT to PLT. */
+#define R_390_PLTOFF64		36	/* 16 bit offset from GOT to PLT. */
+#define R_390_TLS_LOAD		37	/* Tag for load insn in TLS code.  */
+#define R_390_TLS_GDCALL	38	/* Tag for function call in general
+					   dynamic TLS code. */
+#define R_390_TLS_LDCALL	39	/* Tag for function call in local
+					   dynamic TLS code. */
+#define R_390_TLS_GD32		40	/* Direct 32 bit for general dynamic
+					   thread local data.  */
+#define R_390_TLS_GD64		41	/* Direct 64 bit for general dynamic
+					  thread local data.  */
+#define R_390_TLS_GOTIE12	42	/* 12 bit GOT offset for static TLS
+					   block offset.  */
+#define R_390_TLS_GOTIE32	43	/* 32 bit GOT offset for static TLS
+					   block offset.  */
+#define R_390_TLS_GOTIE64	44	/* 64 bit GOT offset for static TLS
+					   block offset. */
+#define R_390_TLS_LDM32		45	/* Direct 32 bit for local dynamic
+					   thread local data in LE code.  */
+#define R_390_TLS_LDM64		46	/* Direct 64 bit for local dynamic
+					   thread local data in LE code.  */
+#define R_390_TLS_IE32		47	/* 32 bit address of GOT entry for
+					   negated static TLS block offset.  */
+#define R_390_TLS_IE64		48	/* 64 bit address of GOT entry for
+					   negated static TLS block offset.  */
+#define R_390_TLS_IEENT		49	/* 32 bit rel. offset to GOT entry for
+					   negated static TLS block offset.  */
+#define R_390_TLS_LE32		50	/* 32 bit negated offset relative to
+					   static TLS block.  */
+#define R_390_TLS_LE64		51	/* 64 bit negated offset relative to
+					   static TLS block.  */
+#define R_390_TLS_LDO32		52	/* 32 bit offset relative to TLS
+					   block.  */
+#define R_390_TLS_LDO64		53	/* 64 bit offset relative to TLS
+					   block.  */
+#define R_390_TLS_DTPMOD	54	/* ID of module containing symbol.  */
+#define R_390_TLS_DTPOFF	55	/* Offset in TLS block.	 */
+#define R_390_TLS_TPOFF		56	/* Negated offset in static TLS
+					   block.  */
+#define R_390_20		57	/* Direct 20 bit.  */
+#define R_390_GOT20		58	/* 20 bit GOT offset.  */
+#define R_390_GOTPLT20		59	/* 20 bit offset to jump slot.  */
+#define R_390_TLS_GOTIE20	60	/* 20 bit GOT offset for static TLS
+					   block offset.  */
+/* Keep this the last entry.  */
+#define R_390_NUM		61
+
+
+/* CRIS relocations.  */
+#define R_CRIS_NONE		0
+#define R_CRIS_8		1
+#define R_CRIS_16		2
+#define R_CRIS_32		3
+#define R_CRIS_8_PCREL		4
+#define R_CRIS_16_PCREL		5
+#define R_CRIS_32_PCREL		6
+#define R_CRIS_GNU_VTINHERIT	7
+#define R_CRIS_GNU_VTENTRY	8
+#define R_CRIS_COPY		9
+#define R_CRIS_GLOB_DAT		10
+#define R_CRIS_JUMP_SLOT	11
+#define R_CRIS_RELATIVE		12
+#define R_CRIS_16_GOT		13
+#define R_CRIS_32_GOT		14
+#define R_CRIS_16_GOTPLT	15
+#define R_CRIS_32_GOTPLT	16
+#define R_CRIS_32_GOTREL	17
+#define R_CRIS_32_PLT_GOTREL	18
+#define R_CRIS_32_PLT_PCREL	19
+
+#define R_CRIS_NUM		20
+
+
+/* AMD x86-64 relocations.  */
+#define R_X86_64_NONE		0	/* No reloc */
+#define R_X86_64_64		1	/* Direct 64 bit  */
+#define R_X86_64_PC32		2	/* PC relative 32 bit signed */
+#define R_X86_64_GOT32		3	/* 32 bit GOT entry */
+#define R_X86_64_PLT32		4	/* 32 bit PLT address */
+#define R_X86_64_COPY		5	/* Copy symbol at runtime */
+#define R_X86_64_GLOB_DAT	6	/* Create GOT entry */
+#define R_X86_64_JUMP_SLOT	7	/* Create PLT entry */
+#define R_X86_64_RELATIVE	8	/* Adjust by program base */
+#define R_X86_64_GOTPCREL	9	/* 32 bit signed PC relative
+					   offset to GOT */
+#define R_X86_64_32		10	/* Direct 32 bit zero extended */
+#define R_X86_64_32S		11	/* Direct 32 bit sign extended */
+#define R_X86_64_16		12	/* Direct 16 bit zero extended */
+#define R_X86_64_PC16		13	/* 16 bit sign extended pc relative */
+#define R_X86_64_8		14	/* Direct 8 bit sign extended  */
+#define R_X86_64_PC8		15	/* 8 bit sign extended pc relative */
+#define R_X86_64_DTPMOD64	16	/* ID of module containing symbol */
+#define R_X86_64_DTPOFF64	17	/* Offset in module's TLS block */
+#define R_X86_64_TPOFF64	18	/* Offset in initial TLS block */
+#define R_X86_64_TLSGD		19	/* 32 bit signed PC relative offset
+					   to two GOT entries for GD symbol */
+#define R_X86_64_TLSLD		20	/* 32 bit signed PC relative offset
+					   to two GOT entries for LD symbol */
+#define R_X86_64_DTPOFF32	21	/* Offset in TLS block */
+#define R_X86_64_GOTTPOFF	22	/* 32 bit signed PC relative offset
+					   to GOT entry for IE symbol */
+#define R_X86_64_TPOFF32	23	/* Offset in initial TLS block */
+
+#define R_X86_64_NUM		24
+
+
+/* AM33 relocations.  */
+#define R_MN10300_NONE		0	/* No reloc.  */
+#define R_MN10300_32		1	/* Direct 32 bit.  */
+#define R_MN10300_16		2	/* Direct 16 bit.  */
+#define R_MN10300_8		3	/* Direct 8 bit.  */
+#define R_MN10300_PCREL32	4	/* PC-relative 32-bit.  */
+#define R_MN10300_PCREL16	5	/* PC-relative 16-bit signed.  */
+#define R_MN10300_PCREL8	6	/* PC-relative 8-bit signed.  */
+#define R_MN10300_GNU_VTINHERIT	7	/* Ancient C++ vtable garbage... */
+#define R_MN10300_GNU_VTENTRY	8	/* ... collection annotation.  */
+#define R_MN10300_24		9	/* Direct 24 bit.  */
+#define R_MN10300_GOTPC32	10	/* 32-bit PCrel offset to GOT.  */
+#define R_MN10300_GOTPC16	11	/* 16-bit PCrel offset to GOT.  */
+#define R_MN10300_GOTOFF32	12	/* 32-bit offset from GOT.  */
+#define R_MN10300_GOTOFF24	13	/* 24-bit offset from GOT.  */
+#define R_MN10300_GOTOFF16	14	/* 16-bit offset from GOT.  */
+#define R_MN10300_PLT32		15	/* 32-bit PCrel to PLT entry.  */
+#define R_MN10300_PLT16		16	/* 16-bit PCrel to PLT entry.  */
+#define R_MN10300_GOT32		17	/* 32-bit offset to GOT entry.  */
+#define R_MN10300_GOT24		18	/* 24-bit offset to GOT entry.  */
+#define R_MN10300_GOT16		19	/* 16-bit offset to GOT entry.  */
+#define R_MN10300_COPY		20	/* Copy symbol at runtime.  */
+#define R_MN10300_GLOB_DAT	21	/* Create GOT entry.  */
+#define R_MN10300_JMP_SLOT	22	/* Create PLT entry.  */
+#define R_MN10300_RELATIVE	23	/* Adjust by program base.  */
+
+#define R_MN10300_NUM		24
+
+
+/* M32R relocs.  */
+#define R_M32R_NONE		0	/* No reloc. */
+#define R_M32R_16		1	/* Direct 16 bit. */
+#define R_M32R_32		2	/* Direct 32 bit. */
+#define R_M32R_24		3	/* Direct 24 bit. */
+#define R_M32R_10_PCREL		4	/* PC relative 10 bit shifted. */
+#define R_M32R_18_PCREL		5	/* PC relative 18 bit shifted. */
+#define R_M32R_26_PCREL		6	/* PC relative 26 bit shifted. */
+#define R_M32R_HI16_ULO		7	/* High 16 bit with unsigned low. */
+#define R_M32R_HI16_SLO		8	/* High 16 bit with signed low. */
+#define R_M32R_LO16		9	/* Low 16 bit. */
+#define R_M32R_SDA16		10	/* 16 bit offset in SDA. */
+#define R_M32R_GNU_VTINHERIT	11
+#define R_M32R_GNU_VTENTRY	12
+/* M32R relocs use SHT_RELA.  */
+#define R_M32R_16_RELA		33	/* Direct 16 bit. */
+#define R_M32R_32_RELA		34	/* Direct 32 bit. */
+#define R_M32R_24_RELA		35	/* Direct 24 bit. */
+#define R_M32R_10_PCREL_RELA	36	/* PC relative 10 bit shifted. */
+#define R_M32R_18_PCREL_RELA	37	/* PC relative 18 bit shifted. */
+#define R_M32R_26_PCREL_RELA	38	/* PC relative 26 bit shifted. */
+#define R_M32R_HI16_ULO_RELA	39	/* High 16 bit with unsigned low */
+#define R_M32R_HI16_SLO_RELA	40	/* High 16 bit with signed low */
+#define R_M32R_LO16_RELA	41	/* Low 16 bit */
+#define R_M32R_SDA16_RELA	42	/* 16 bit offset in SDA */
+#define R_M32R_RELA_GNU_VTINHERIT	43
+#define R_M32R_RELA_GNU_VTENTRY	44
+#define R_M32R_REL32		45	/* PC relative 32 bit.  */
+
+#define R_M32R_GOT24		48	/* 24 bit GOT entry */
+#define R_M32R_26_PLTREL	49	/* 26 bit PC relative to PLT shifted */
+#define R_M32R_COPY		50	/* Copy symbol at runtime */
+#define R_M32R_GLOB_DAT		51	/* Create GOT entry */
+#define R_M32R_JMP_SLOT		52	/* Create PLT entry */
+#define R_M32R_RELATIVE		53	/* Adjust by program base */
+#define R_M32R_GOTOFF		54	/* 24 bit offset to GOT */
+#define R_M32R_GOTPC24		55	/* 24 bit PC relative offset to GOT */
+#define R_M32R_GOT16_HI_ULO	56	/* High 16 bit GOT entry with unsigned
+					   low */
+#define R_M32R_GOT16_HI_SLO	57	/* High 16 bit GOT entry with signed
+					   low */
+#define R_M32R_GOT16_LO		58	/* Low 16 bit GOT entry */
+#define R_M32R_GOTPC_HI_ULO	59	/* High 16 bit PC relative offset to
+					   GOT with unsigned low */
+#define R_M32R_GOTPC_HI_SLO	60	/* High 16 bit PC relative offset to
+					   GOT with signed low */
+#define R_M32R_GOTPC_LO		61	/* Low 16 bit PC relative offset to
+					   GOT */
+#define R_M32R_GOTOFF_HI_ULO	62	/* High 16 bit offset to GOT
+					   with unsigned low */
+#define R_M32R_GOTOFF_HI_SLO	63	/* High 16 bit offset to GOT
+					   with signed low */
+#define R_M32R_GOTOFF_LO	64	/* Low 16 bit offset to GOT */
+#define R_M32R_NUM		256	/* Keep this the last entry. */
+
+
+#endif	/* elf.h */


Property changes on: trunk/coreboot-v2/util/cbfstool/elf.h
___________________________________________________________________
Added: svn:mergeinfo
   + 

Deleted: trunk/coreboot-v2/util/cbfstool/extract.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/extract.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/extract.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,74 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2009 Myles Watson <mylesgw at gmail.com>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <ctype.h>
-#include <stdlib.h>
-#include <sys/stat.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include "cbfstool.h"
-
-static int extract_blob(struct rom *rom, const char *filename, const char *name)
-{
-	void *buf;
-	int fd, ret;
-	int size;
-
-	ret = rom_extract(rom, name, &buf, &size);
-
-	if (ret == -1) 
-		return -1;
-
-	fd = open(filename, O_RDWR | O_CREAT | O_TRUNC, S_IRUSR | S_IWUSR);
-
-	if (fd == -1) {
-		ERROR("Could not open %s: %m\n", filename);
-		return -1;
-	}
-
-	if (write(fd, buf, size) != size) {
-		ERROR("Couldn't write %d bytes!\n", size);
-		ret = -1;
-	}
-
-	close(fd);
-
-	return ret;
-}
-
-void extract_usage(void)
-{
-	printf("extract [FILE] [NAME] \textract a component\n");
-}
-
-int extract_handler(struct rom *rom, int argc, char **argv)
-{
-	if (argc < 2) {
-		extract_usage();
-		return -1;
-	}
-
-	if (!rom_exists(rom)) {
-		ERROR("Can't find the ROM!\n");
-		return -1;
-	}
-
-	return extract_blob(rom, argv[0], argv[1]);
-}
-

Deleted: trunk/coreboot-v2/util/cbfstool/fs.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/fs.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/fs.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,479 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <string.h>
-#include <stdlib.h>
-#include "cbfstool.h"
-
-int namelen(const char *name)
-{
-	return ALIGN(strlen(name) + 1, 16);
-}
-
-/**
- * Given a name, return the header size for that name. 
- * @param name The name
- * @returns The header size given that name
- */
-int headersize(const char *name)
-{
-	return sizeof(struct cbfs_file) + namelen(name);
-}
-
-/**
- * Given a name, set it into the header in a standard way
- * @param file the cbfs file
- * @param name The name
- */
-void setname(struct cbfs_file *file, const char *name)
-{
-	memset(CBFS_NAME(file), 0, namelen(name));
-	strcpy((char *)CBFS_NAME(file), name);
-}
-
-/**
- * Given a name, size, and type, set them into the header in a standard way. 
- * Special case of size of -1: set the size to all of ROM
- * @param rom The rom
- * @param c The cbfs file
- * @param name The name
- * @param size The size
- * @param type The type
- * @returns Always 0 for now
- */
-int rom_set_header(struct rom *rom, struct cbfs_file *c, const char *name, int size, int type)
-{
-	unsigned int csize;
-	csize = headersize(name);
-
-	strcpy(c->magic, COMPONENT_MAGIC);
-
-	/* special case -- if size is -1, means "as much as you can"
-	 * it's usually only used in init. 
-	 */
-	if (size < 0)
-		size = rom->fssize - csize;
-	c->len = htonl(size);
-	c->offset = htonl(csize);
-	c->type = htonl(type);
-
-	setname(c, name);
-	return 0;
-}
-
-int nextfile(struct rom *rom, struct cbfs_file *c, int offset)
-{
-	return ALIGN(offset + ntohl(c->len),
-					ntohl(rom->header->align));
-}
-
-
-/* split
- * split is a basic primitive in cbfs. Over time, it should be the main operator
- * used to allocate space. For now for testing we are only using it in the 
- * fixed-address allocation. 
- * Split takes a cbfs_file and splits it into two pieces, as determined 
- * by the size of the file desired. Split only makes sense on CBFS_COMPONENT_NULL
- * files -- splitting real files is an error, but no checking is done. 
- * @param file cbfs_file to split
- * @param size Size of the file desired. 
- * @returns pointer to a cbfs_file stuct. 
- */
-static struct cbfs_file *split(struct rom *rom, struct cbfs_file *file, int size)
-{
-	struct cbfs_file *newfile = NULL;
-	unsigned long align = ntohl(rom->header->align);
-	unsigned long nextoffset, truncoffset;
-	unsigned long offset = ROM_OFFSET(rom, file);
-	/* figure out the real end of this file, and hence the size */
-	/* compute where the next file is */
-	nextoffset = ALIGN(offset + ntohl(file->len) + headersize(""), align);
-	/* compute where the end of this new file might be */
-	truncoffset = ALIGN(offset + size + headersize(""), align);
-	/* If there is more than align bytes difference, create a new empty file */
-	/* later, we can add code to merge all empty files. */
-	if (nextoffset - truncoffset > align) {
-		unsigned int csize;
-		csize = headersize("");
-		newfile = (struct cbfs_file *)ROM_PTR(rom, truncoffset);
-		rom_set_header(rom, newfile, "", 
-			nextoffset - truncoffset - csize, CBFS_COMPONENT_NULL);
-		file->len = htonl(size);
-	}
-	return newfile;
-}
-
-
-/**
- * rom_alloc_fixed
- * Given a rom, walk the headers and find the first header of type 
- * CBFS_COMPONENT_NULL that is >= the desired size and 
- * contains the (address, length) desired. 
- * If the CBFS_COMPONENT_NULL is 'align' bytes > size, 
- * create a new header of CBFS_COMPONENT_NULL following the file. 
- * The 'len' structure member of the desired file is initialized, but 
- * nothing else is. 
- * Simple algorithm: walk until we find an empty file that contains our area, 
- * and then allocate out of it. 
- * @param rom The rom
- * @param size the size of the file needed
- * @returns pointer to a cbfs_file struct. 
- */
-struct cbfs_file * rom_alloc_fixed(struct rom *rom, const char *name, unsigned long start, unsigned long size, int type)
-{
-	/* walk the rom and find an empty file with a base > base, 
-	 * and a large enough size
-	 */
-	unsigned long base, end, alen, baseoff;
-	unsigned int offset = ntohl(rom->header->offset);
-	int ret = -1;
-	struct cbfs_file *c = NULL;
-	unsigned long align = ntohl(rom->header->align);
-
-	/* compute a base that is aligned to align */
-	base = TRUNCATE(start, align);
-	/* have to leave room for a header! */
-	base -= headersize(name);
-	/* get an offset for that base */
-	baseoff = base - rom->rombase;
-	end = ALIGN(start + size, align);
-	alen = end - base;
-	while (offset < rom->fssize) {
-
-		c = (struct cbfs_file *)ROM_PTR(rom, offset);
-
-		if (!strcmp(c->magic, COMPONENT_MAGIC)) {
-			if (c->type != CBFS_COMPONENT_NULL) {
-				offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
-					align);
-				continue;
-			}
-			/* could turn this into a function. */
-			/* is the start of this file < our desired start? */
-			if (offset > baseoff)
-				break;
-			/* Is this file big enough for our needs? */
-			if (ntohl(c->len) >= alen){
-				ret = offset;
-				break;
-			}
-			offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
-					align);
-		} else {
-			fprintf(stderr, "Corrupt rom -- found no header at %d\n", offset);
-			exit(1);
-		}
-	}
-
-	if (ret < 0)
-		return NULL;
-
-	/* we have the base offset of our location, and we have the offset for the file we are going to 
-	 * split. Split it. 
-	 */
-	if (baseoff > offset)
-		c = split(rom, c, baseoff - offset - headersize(""));
-	/* split off anything left at the end that we don't need */
-	split(rom, c, size);
-
-	c->len = htonl(size);
-
-	strcpy(c->magic, COMPONENT_MAGIC);
-
-	c->offset = htonl(headersize(name));
-
-	c->type = htonl(type);
-
-	setname(c, name);
-
-	return ((struct cbfs_file *)ROM_PTR(rom, ret));
-}
-
-
-/**
- * rom_alloc
- * Given a rom, walk the headers and find the first header of type 
- * CBFS_COMPONENT_NULL that is >= the desired size. 
- * If the CBFS_COMPONENT_NULL is 'align' bytes > size, 
- * create a new header of CBFS_COMPONENT_NULL following the file. 
- * The 'len' structure member of the desired file is initialized, but 
- * nothing else is. 
- * @param rom The rom
- * @param size the size of the file needed
- * @returns pointer to a cbfs_file struct. 
- */
-struct cbfs_file * rom_alloc(struct rom *rom, const char *name, unsigned long size, int type)
-{
-	/* walk the rom and find an empty file with a base > base, and a large enough size */
-	unsigned int offset = ntohl(rom->header->offset);
-	int ret = -1;
-	struct cbfs_file *c = NULL;
-	unsigned long nextoffset, truncoffset;
-	struct cbfs_file *newfile = NULL;
-
-	while ((offset + size) < rom->fssize) {
-
-		c = (struct cbfs_file *)ROM_PTR(rom, offset);
-
-		if (!strcmp(c->magic, COMPONENT_MAGIC)) {
-			if (c->type != CBFS_COMPONENT_NULL) {
-				offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
-					ntohl(rom->header->align));
-				continue;
-			}
-			/* Is this file big enough for our needs? */
-			if (ntohl(c->len) >= size){
-				ret = offset;
-				break;
-			}
-			offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
-					ntohl(rom->header->align));
-		} else {
-			fprintf(stderr, "Corrupt rom -- found no header at %d\n", offset);
-			exit(1);
-		}
-	}
-
-	if (ret < 0)
-		return NULL;
-
-	/* figure out the real end of this file, and hence the size */
-	/* compute where the next file is */
-	nextoffset = ALIGN(ret + ntohl(c->len) + headersize(name),
-				ntohl(rom->header->align));
-	/* compute where the end of this new file might be */
-	truncoffset = ALIGN(ret + size + headersize(name),
-				ntohl(rom->header->align));
-	/* If there is more than align bytes difference, create a new empty file */
-	/* later, we can add code to merge all empty files. */
-	if (nextoffset - truncoffset > ntohl(rom->header->align)) {
-		unsigned int csize;
-		csize = headersize("");
-		newfile = (struct cbfs_file *)ROM_PTR(rom, truncoffset);
-		rom_set_header(rom, newfile, "", 
-			nextoffset - truncoffset - csize, CBFS_COMPONENT_NULL);
-	} else truncoffset = nextoffset;
-
-	c->len = htonl(size);
-
-	strcpy(c->magic, COMPONENT_MAGIC);
-
-	c->offset = htonl(headersize(name));
-
-	c->type = htonl(type);
-
-	setname(c, name);
-
-	return ((struct cbfs_file *)ROM_PTR(rom, ret));
-}
-
-struct cbfs_file *rom_find(struct rom *rom, int offset)
-{
-	while (offset < rom->fssize) {
-		struct cbfs_file *c =
-		    (struct cbfs_file *)ROM_PTR(rom, offset);
-
-		if (!strcmp(c->magic, COMPONENT_MAGIC))
-			return c;
-
-		offset += ntohl(rom->header->align);
-	}
-
-	return NULL;
-}
-
-struct cbfs_file *rom_find_first(struct rom *rom)
-{
-	return rom_find(rom, ntohl(rom->header->offset));
-}
-
-struct cbfs_file *rom_find_next(struct rom *rom, struct cbfs_file *prev)
-{
-	unsigned int offset = ROM_OFFSET(rom, prev);
-
-	return rom_find(rom, offset +
-			ALIGN(ntohl(prev->offset) + ntohl(prev->len),
-			      ntohl(rom->header->align)));
-}
-
-struct cbfs_file *rom_find_empty(struct rom *rom)
-{
-	unsigned int offset = ntohl(rom->header->offset);
-	unsigned int ret = ntohl(rom->header->offset);
-
-	while (offset < rom->fssize) {
-
-		struct cbfs_file *c =
-		    (struct cbfs_file *)ROM_PTR(rom, offset);
-
-		if (!strcmp(c->magic, COMPONENT_MAGIC)) {
-			offset += ALIGN(ntohl(c->offset) + ntohl(c->len),
-					ntohl(rom->header->align));
-
-			ret = offset;
-		} else
-			offset += ntohl(rom->header->align);
-	}
-
-	return (ret < rom->fssize) ?
-	    (struct cbfs_file *)ROM_PTR(rom, ret) : NULL;
-}
-
-struct cbfs_file *rom_find_by_name(struct rom *rom, const char *name)
-{
-	struct cbfs_file *c = rom_find_first(rom);
-
-	while (c) {
-		if (!strcmp((char *)CBFS_NAME(c), name))
-			return c;
-
-		c = rom_find_next(rom, c);
-	}
-
-	return NULL;
-}
-
-int rom_used_space(struct rom *rom)
-{
-	struct cbfs_file *c = rom_find_first(rom);
-	unsigned int ret = 0;
-
-	while (c) {
-		int type;
-		type = ntohl(c->type);
-		if ((c->type == CBFS_COMPONENT_DELETED) ||
-			(c->type == CBFS_COMPONENT_NULL))
-			continue;
-		ret += ROM_OFFSET(rom, c) + ntohl(c->offset) + ntohl(c->len);
-		c = rom_find_next(rom, c);
-	}
-
-	return ret;
-}
-
-/** 
- * delete an item. This is a flash-friendly version -- it just blows the 
- * type to 0. Nothing else is changed. 
- * N.B. We no longer shuffle contents of ROM. That will come later. 
- * @param rom The rom
- * @param name Name of file to remove. 
- * @return -1 on error, 0 if a file was set to deleted. 
- */
-int rom_remove(struct rom *rom, const char *name)
-{
-	struct cbfs_file *c = rom_find_by_name(rom, name);
-
-	if (c == NULL) {
-		ERROR("Component %s does not exist\n", name);
-		return -1;
-	}
-
-	c->type = CBFS_COMPONENT_DELETED; 
-
-	void *n = rom_find_next(rom, c);
-	int clear;
-	
-	if (n != NULL) {
-		memcpy(c, n, rom->fssize - ROM_OFFSET(rom, n));
-		clear = ROM_OFFSET(rom, n) - ROM_OFFSET(rom, c);
-	}
-	else { /* No component after this one. */
-		unsigned int csize;
-		csize = sizeof(struct cbfs_file) + ALIGN(strlen(name) + 1, 16);
-		clear = ntohl(c->len) + csize;
-		memcpy(c, ((void*)c) + clear, 
-		       rom->fssize - (ROM_OFFSET(rom, c)+clear));
-	}
-
-	/* Zero the new space, which is always at the end. */
-	memset(ROM_PTR(rom, rom->fssize - clear), 0, clear);
-
-	return 0;
-}
-
-int rom_extract(struct rom *rom, const char *name, void** buf, int *size )
-{
-	struct cbfs_file *c = rom_find_by_name(rom, name);
-
-	if (c == NULL) {
-		ERROR("Component %s does not exist\n", name);
-		return -1;
-	}
-
-	*size = ntohl(c->len);
-	*buf = ((unsigned char *)c) + headersize(name);
-	return 0;
-}
-
-/**
- * Add a new file named 'name', of type 'type', size 'size'. Initialize that file
- * with the contents of 'buffer'. 
- * @param rom The rom
- * @param name file name
- * @param buffer file data
- * @param address base address. 0 means 'whereever it fits'
- * @param size Amount of data
- * @param type File type
- * @returns -1 on failure, 0 on success
- */
-int rom_add(struct rom *rom, const char *name, void *buffer, unsigned long address, int size, int type)
-{
-	struct cbfs_file *c;
-	int csize;
-
-	if (rom_find_by_name(rom, name)) {
-		ERROR("Component %s already exists in this rom\n", name);
-		return -1;
-	}
-
-	if (address)
-		c = rom_alloc_fixed(rom, name, address, size, type);
-	else
-		c = rom_alloc(rom, name, size, type);
-
-	if (c == NULL) {
-		ERROR("There is not enough room in this ROM\n");
-		return -1;
-	}
-
-	csize = sizeof(struct cbfs_file) + ALIGN(strlen(name) + 1, 16);
-
-	int offset = ROM_OFFSET(rom, c);
-
-	if (offset + csize + size > rom->fssize) {
-		ERROR("There is not enough room in this ROM for this\n");
-		ERROR("component. I need %d bytes, only have %d bytes avail\n",
-		      csize + size, rom->fssize - offset);
-
-		return -1;
-	}
-
-	strcpy(c->magic, COMPONENT_MAGIC);
-
-	c->len = htonl(size);
-	c->offset = htonl(csize);
-	c->type = htonl(type);
-
-	memset(CBFS_NAME(c), 0, ALIGN(strlen(name) + 1, 16));
-	strcpy((char *)CBFS_NAME(c), name);
-
-	memcpy(((unsigned char *)c) + csize, buffer, size);
-	return 0;
-}
-


Property changes on: trunk/coreboot-v2/util/cbfstool/lzma
___________________________________________________________________
Added: svn:mergeinfo
   + 

Deleted: trunk/coreboot-v2/util/cbfstool/print.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/print.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/print.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,75 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <string.h>
-#include "cbfstool.h"
-
-void print_usage(void)
-{
-	printf("print\t\t\t\tShow the contents of the ROM\n");
-}
-
-int print_handler(struct rom *rom, int argc, char **argv)
-{
-	if ( argc > 0 ) {
-		ERROR("print %s? print takes no arguments.\n", argv[0]);
-		print_usage();
-		return -1;
-	}
-
-	printf("%s: %d kB, bootblocksize %d, romsize %d, offset 0x%x\n", rom->name, rom->size / 1024, 
-				ntohl(rom->header->bootblocksize), ntohl(rom->header->romsize), ntohl(rom->header->offset));
-	printf("Alignment: %d bytes\n\n", ntohl(rom->header->align));
-
-	struct cbfs_file *c = rom_find_first(rom);
-
-	printf("%-30s Offset     %-12s Size\n", "Name", "Type");
-
-	while (c) {
-		char type[12];
-
-		switch (htonl(c->type)) {
-		case CBFS_COMPONENT_STAGE:
-			strcpy(type, "stage");
-			break;
-		case CBFS_COMPONENT_PAYLOAD:
-			strcpy(type, "payload");
-			break;
-		case CBFS_COMPONENT_OPTIONROM:
-			strcpy(type, "optionrom");
-			break;
-		case CBFS_COMPONENT_NULL:
-			strcpy(type, "free");
-			break;
-		case CBFS_COMPONENT_DELETED:
-			strcpy(type, "deleted");
-			break;
-		default:
-			sprintf(type, "0x%8.8x", htonl(c->type));
-			break;
-		}
-
-		printf("%-30s 0x%-8x %-12s %d\n", CBFS_NAME(c),
-		       ROM_OFFSET(rom, c), type, htonl(c->len));
-
-		c = rom_find_next(rom, c);
-	}
-
-	return 0;
-}

Deleted: trunk/coreboot-v2/util/cbfstool/resize.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/resize.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/resize.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,168 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <ctype.h>
-#include <string.h>
-#include <stdlib.h>
-#include <unistd.h>
-#include <sys/mman.h>
-
-#include "cbfstool.h"
-
-void resize_usage(void)
-{
-	printf("resize [SIZE] [ERASEBLOCK]\tResize the ROM\n");
-}
-
-int resize_handler(struct rom *rom, int argc, char **argv)
-{
-	unsigned int align, offset;
-	int size;
-	char null = '\0';
-	int bootblocksize = ntohl(rom->header->bootblocksize);
-
-	if (argc < 1) {
-		resize_usage();
-		return -1;
-	}
-
-	if (rom->fd <= 0) {
-		ERROR("ROM file %s does not exist\n", rom->name);
-		return -1;
-	}
-
-	align = ntohl(rom->header->align);
-	size = get_size(argv[0]);
-
-	if (argc >= 2)
-		align = strtoul(argv[1], NULL, 0);
-
-	if (size == rom->size && align == ntohl(rom->header->align)) {
-		ERROR("New parameters are the same as the old\n");
-		return 0;
-	}
-
-	if (size < bootblocksize) {
-		ERROR("The new size is smaller then the bootblock size\n");
-		return -1;
-	}
-
-	/* if the current ROM is too big for the new size, then complain */
-
-	if (rom_used_space(rom) > size -  bootblocksize) {
-		ERROR("The new size is too small for the current ROM\n");
-		return -1;
-	}
-
-	/* Grow the rom if we need to */
-
-	if (size > rom->size) {
-		munmap(rom->ptr, rom->size);
-
-		lseek(rom->fd, size - 1, SEEK_SET);
-		write(rom->fd, &null, 1);
-
-		rom->ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED,
-				rom->fd, 0);
-
-		if (rom->ptr == MAP_FAILED) {
-			ERROR("Unable to grow the ROM\n");
-			return -1;
-		}
-	}
-
-	/* We only have to rewrite the entries if the alignment changed */
-
-	if (align != ntohl(rom->header->align)) {
-		struct cbfs_file *c;
-
-		/* The first entry doesn't have to move */
-
-		c = rom_find(rom, rom->header->offset);
-
-		while (c) {
-			struct cbfs_file *n = rom_find_next(rom, c);
-			unsigned int next;
-
-			if (n == NULL)
-				break;
-
-			/* Calculate a new location for the entry */
-			next = ROM_OFFSET(rom, c) + 
-				ALIGN(ntohl(c->offset) + ntohl(c->len), align);
-
-			/* Copy the next entry there */
-			memmove(ROM_PTR(rom, next), n,
-				ntohl(n->offset) + ntohl(n->len));
-
-			c = (struct cbfs_file *)ROM_PTR(rom, next);
-
-			/* If the previous header wasn't overwritten by 
-			 * the change, corrupt the header so we don't 
-			 * accidently find it
-			 */
-
-			if (ROM_OFFSET(rom, n) >
-			    next + ntohl(c->len) + ntohl(c->offset))
-				memset(n->magic, 0, sizeof(n->magic));
-		}
-	}
-
-	/* Copy the bootblock */
-
-	memmove(rom->ptr + size -  bootblocksize,
-		rom->ptr + rom->size -  bootblocksize,  bootblocksize);
-
-	/* Recacluate the location of the header */
-
-	offset = ROM_READL(rom, size - 12);
-
-	rom->header = (struct cbfs_header *)
-	    ROM_PTR(rom, size - (0xFFFFFFFF - offset) - 1);
-
-	/* Put the new values in the header */
-	rom->header->romsize = htonl(size);
-	rom->header->align = htonl(align);
-
-	/* Truncate the file if we have to */
-
-	if (size < rom->size) {
-		munmap(rom->ptr, rom->size);
-
-		rom->ptr = NULL;
-
-		if (ftruncate(rom->fd, size)) {
-			ERROR("Unable to truncate the ROM\n");
-			return -1;
-		}
-
-		rom->ptr = mmap(0, size, PROT_READ | PROT_WRITE, MAP_SHARED,
-				rom->fd, 0);
-
-		if (rom->ptr == MAP_FAILED) {
-			ERROR("Unable to truncate the ROM\n");
-			return -1;
-		}
-	}
-
-	rom->size = size;
-	rom->fssize = size -  bootblocksize;
-
-	return 0;
-}

Deleted: trunk/coreboot-v2/util/cbfstool/types.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/types.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/types.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,84 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <string.h>
-#include "cbfstool.h"
-
-static const struct {
-	char *type;
-	unsigned int value;
-	int (*detect) (const char *filename);
-	int (*handler) (const char *filename, const char *name);
-} component_types[] = {
-	{
-NULL, 0xFF, NULL, NULL},};
-
-int parse_type(const char *str, unsigned int *type)
-{
-	int i;
-	for (i = 0; component_types[i].type != NULL; i++) {
-		if (!strncmp(str, component_types[i].type,
-			     strlen(compoent_types[i].type))) {
-			*type = component_types[i].value;
-			return 0;
-		}
-	}
-
-	return -1;
-}
-
-int detect_type(const char *filename)
-{
-
-	int i;
-
-	for (i = 0; component_types[i].type != NULL; i++) {
-		if (component_types[i].detect &&
-		    !component_types[i].detect(filename))
-			return component_types[i].value;
-
-	}
-}
-
-int handle_type(const char *filename, int type, int *ret)
-{
-	/* Now send the file to the required handler */
-	for (i = 0; component_types[i].type != NULL; i++) {
-		if (type == component_types[i].value) {
-			*ret = component_types[i].handler(config,
-							  argv[0], argv[1]);
-			return 0;
-		}
-	}
-
-	return -1;
-}
-
-void get_type(int type, char *buffer, int len)
-{
-	for (i = 0; component_types[i].type != NULL; i++) {
-		if (type == component_types[i].value) {
-			strncpy(buffer, component_types[i].type, len - 1);
-			buffer[len - 1] = '\0';
-			return;
-		}
-	}
-
-	snprintf(buffer, len, "%x\n", type);
-}

Deleted: trunk/coreboot-v2/util/cbfstool/util.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/util.c	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/cbfstool/util.c	2009-09-14 13:29:27 UTC (rev 4630)
@@ -1,276 +0,0 @@
-/*
- * cbfstool
- *
- * Copyright (C) 2008 Jordan Crouse <jordan at cosmicpenguin.net>
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; version 2 of the License.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA, 02110-1301 USA
- */
-
-#include <stdlib.h>
-#include <string.h>
-#include <unistd.h>
-#include <fcntl.h>
-#include <sys/stat.h>
-#include <sys/mman.h>
-#include "cbfstool.h"
-
-int uninitialized_flash_value = 0xff;
-
-void flashinit(void *ptr, size_t len)
-{
-	memset(ptr, uninitialized_flash_value, len);
-}
-
-int get_size(const char *size)
-{
-	char *next;
-	int val = strtoul(size, &next, 0);
-
-	/* Support modifiers for the size kK and mM for kbytes and 
-	   mbytes respectfully */
-
-	if (next != NULL) {
-		if (*next == 'k' || *next == 'K')
-			val *= 1024;
-		else if (*next == 'm' || *next == 'M')
-			val *= (1024 * 1024);
-	}
-
-	return val;
-}
-
-int copy_from_fd(int fd, void *ptr, int size)
-{
-	unsigned char *p = ptr;
-
-	while (size > 0) {
-		int ret = read(fd, p, size);
-
-		if (ret == -1) {
-			ERROR("Error while reading: %m\n");
-			return -1;
-		}
-
-		if (ret == 0) {
-			ERROR("Unexpected end of file\n");
-			return -1;
-		}
-
-		p += ret;
-		size -= ret;
-	}
-
-	return 0;
-}
-
-int size_and_open(const char *filename, unsigned int *size)
-{
-	struct stat s;
-
-	int fd = open(filename, O_RDONLY);
-
-	if (fd == -1) {
-		ERROR("Unable to open %s: %m\n", filename);
-		return -1;
-	}
-
-	if (fstat(fd, &s)) {
-		ERROR("Unable to stat %s: %m\n", filename);
-		close(fd);
-		return -1;
-	}
-
-	*size = s.st_size;
-	return fd;
-}
-
-int map_rom(struct rom *rom, int size)
-{
-	rom->ptr = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED,
-			rom->fd, 0);
-
-	if (rom->ptr == MAP_FAILED) {
-		ERROR("Could not map the rom: %m\n");
-		rom->ptr = NULL;
-		return -1;
-	}
-
-	return 0;
-}
-
-int open_rom(struct rom *rom, const char *filename)
-{
-	struct stat s;
-	unsigned long offset;
-
-	if (stat(filename, &s)) {
-		ERROR("Could not stat %s: %m\n", filename);
-		return -1;
-	}
-
-	rom->fd = open(filename, O_RDWR);
-
-	if (rom->fd == -1) {
-		ERROR("Could not open %s: %m\n", filename);
-		rom->fd = 0;
-		return -1;
-	}
-
-	if (map_rom(rom, s.st_size))
-		goto err;
-
-	/* Find the master header */
-
-	offset = ROM_READL(rom, s.st_size - 4);
-
-	rom->header = (struct cbfs_header *)
-	    ROM_PTR(rom, s.st_size - (0xFFFFFFFF - offset) - 1);
-
-	if (ntohl(rom->header->magic) != HEADER_MAGIC) {
-		ERROR("This does not appear to be a valid ROM\n");
-		goto err;
-	}
-
-	/* Check that the alignment is correct */
-	if (ntohl(rom->header->align) == 0) {
-		ERROR("The alignment in the ROM is 0 - probably malformed\n");
-		goto err;
-	}
-
-	/* Sanity check that the size matches the file size */
-
-	if (ntohl(rom->header->romsize) != s.st_size) {
-		ERROR("The ROM size in the header does not match the file\n");
-		ERROR("ROM size is %d bytes, file size is %d bytes\n",
-		      ntohl(rom->header->romsize), (unsigned int)s.st_size);
-		goto err;
-	}
-
-	rom->size = ntohl(rom->header->romsize);
-	/* compute a 32-bit value of rombase. 
-	 * This does the right thing on 64-bit machines. 
-	 */
-	rom->rombase = 0-rom->size;
-	rom->rombase &= 0xffffffff;
-	rom->fssize = rom->size - ntohl(rom->header->bootblocksize);
-
-	return 0;
-
-err:
-	if (rom->ptr != NULL)
-		munmap(rom->ptr, s.st_size);
-
-	if (rom->fd > 0)
-		close(rom->fd);
-
-	rom->ptr = NULL;
-	rom->fd = 0;
-	return -1;
-}
-
-int create_rom(struct rom *rom, const unsigned char *filename,
-	       int romsize, const char *bootblockname,
-	       int bootblocksize, int align)
-{
-	unsigned char null = '\0';
-
-	if (rom->fd != 0) {
-		ERROR("%s already exists - cannot create\n", filename);
-		return -1;
-	}
-
-	/* Remember the size of the entire ROM */
-	rom->size = romsize;
-
-	/* The size of the archive section is everything but the bootblock and
-	 * the cbfs master header. */
-	rom->fssize = romsize - bootblocksize - sizeof(struct cbfs_header);
-
-	/* Open the file descriptor */
-
-	rom->fd = open((char *)filename, O_RDWR | O_CREAT, S_IRUSR | S_IWUSR);
-
-	if (rom->fd == -1) {
-		ERROR("Could not create %s: %m\n", filename);
-		return -1;
-	}
-
-	/* Size the new file appropriately */
-	lseek(rom->fd, romsize - 1, SEEK_SET);
-	write(rom->fd, &null, 1);
-
-	if (map_rom(rom, romsize)) {
-		close(rom->fd);
-		return -1;
-	}
-
-	/* mmap'ed pages are by default zero-filled. Fix that. */
-	flashinit(rom->ptr, romsize);
-
-	/* This is a pointer to the header for easy access */
-	rom->header = (struct cbfs_header *)
-	    ROM_PTR(rom, rom->size - bootblocksize - sizeof(struct cbfs_header));
-	rom->header->magic = htonl(HEADER_MAGIC);
-	rom->header->romsize = htonl(romsize);
-	rom->header->bootblocksize = htonl(bootblocksize);
-	rom->header->align = htonl(align);
-	rom->header->offset = htonl(0);
-
-	if (add_bootblock(rom, bootblockname) == -1)
-		return -1;
-
-	/* Write the cbfs master header address at the end of the ROM. */
-
-	ROM_WRITEL(rom, rom->size - 4,
-		   0xFFFFFFFF - bootblocksize - sizeof(struct cbfs_header) + 1);
-
-	/* write the empty header */
-	rom_set_header(rom, (struct cbfs_file *)rom->ptr, "", -1, CBFS_COMPONENT_NULL);
-	return 0;
-}
-
-int add_bootblock(struct rom *rom, const char *filename)
-{
-	unsigned int size;
-	int fd = size_and_open(filename, &size);
-	int ret;
-
-	if (fd == -1)
-		return -1;
-
-	if (size > ntohl(rom->header->bootblocksize)) {
-		ERROR("The bootblock size is not correct (%d vs %d)\n",
-		      size, ntohl(rom->header->bootblocksize));
-		return -1;
-	}
-
-	/* Copy the bootblock into place at the end of the file */
-	ret = copy_from_fd(fd, ROM_PTR(rom, rom->size - size), size);
-
-	close(fd);
-
-	if (ret) {
-		ERROR("Unable to add %s to the bootblock\n", filename);
-		return -1;
-	}
-
-	return 0;
-}
-
-int rom_exists(struct rom *rom)
-{
-	if (rom->fd <= 0)
-		return 0;
-	return 1;
-}

Modified: trunk/coreboot-v2/util/newconfig/config.g
===================================================================
--- trunk/coreboot-v2/util/newconfig/config.g	2009-09-10 11:21:48 UTC (rev 4629)
+++ trunk/coreboot-v2/util/newconfig/config.g	2009-09-14 13:29:27 UTC (rev 4630)
@@ -2257,7 +2257,7 @@
 	file.write("\n")
 
 	# cbfstool rules
-	file.write("\ncbfstool:\n\tmkdir -p cbfs/tools/lzma\n\t$(MAKE) -C $(TOP)/util/cbfstool obj=$(shell pwd)/cbfs\n")
+	file.write("\ncbfstool:\n\tmkdir -p cbfs\n\t$(MAKE) -C $(TOP)/util/cbfstool obj=$(shell pwd)/cbfs\n")
 	file.write("\ncbfstool-clean:\n\t$(MAKE) -C $(TOP)/util/cbfstool obj=$(shell pwd)/cbfs clean\n\n")
 
 	file.write("include Makefile.settings\n\n")




From info at coresystems.de  Mon Sep 14 15:51:42 2009
From: info at coresystems.de (coreboot information)
Date: Mon, 14 Sep 2009 15:51:42 +0200
Subject: [coreboot] build service results for r4630
Message-ID: <E1MnBy2-0003Rc-4c@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "oxygene" checked in revision 4630 to
the coreboot repository. This caused the following 
changes:

Change Log:
New cbfstool. Works without mmap or fork/exec and
supports fixed location files. Some parts are salvaged
from the pre-commit version (esp. stage and payload creation),
others are completely rewritten (eg. the main loop that handles
file addition)

Also adapt newconfig (we don't need cbfs/tools anymore) and fix
some minor issues in the cbfstool-README.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of a-trend:atc-6220 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=atc-6220&vendor=a-trend&num=2
Compilation of a-trend:atc-6240 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=atc-6240&vendor=a-trend&num=2
Compilation of abit:be6-ii_v2_0 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=be6-ii_v2_0&vendor=abit&num=2
Compilation of advantech:pcm-5820 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=pcm-5820&vendor=advantech&num=2
Compilation of amd:db800 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=db800&vendor=amd&num=2
Compilation of amd:dbm690t has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dbm690t&vendor=amd&num=2
Compilation of amd:norwich has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=norwich&vendor=amd&num=2
Compilation of amd:pistachio has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=pistachio&vendor=amd&num=2
Compilation of amd:rumba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=rumba&vendor=amd&num=2
Compilation of amd:serengeti_cheetah has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=serengeti_cheetah&vendor=amd&num=2
Compilation of amd:serengeti_cheetah_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=serengeti_cheetah_fam10&vendor=amd&num=2
Compilation of arima:hdama has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=hdama&vendor=arima&num=2
Compilation of artecgroup:dbe61 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dbe61&vendor=artecgroup&num=2
Compilation of asi:mb_5blgp has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=mb_5blgp&vendor=asi&num=2
Compilation of asi:mb_5blmp has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=mb_5blmp&vendor=asi&num=2
Compilation of asus:a8n_e has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=a8n_e&vendor=asus&num=2
Compilation of asus:a8v-e_se has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=a8v-e_se&vendor=asus&num=2
Compilation of asus:m2v-mx_se has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=m2v-mx_se&vendor=asus&num=2
Compilation of asus:mew-am has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=mew-am&vendor=asus&num=2
Compilation of asus:mew-vm has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=mew-vm&vendor=asus&num=2
Compilation of asus:p2b has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=p2b&vendor=asus&num=2
Compilation of asus:p2b-d has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=p2b-d&vendor=asus&num=2
Compilation of asus:p2b-ds has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=p2b-ds&vendor=asus&num=2
Compilation of asus:p2b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=p2b-f&vendor=asus&num=2
Compilation of asus:p3b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=p3b-f&vendor=asus&num=2
Compilation of axus:tc320 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=tc320&vendor=axus&num=2
Compilation of azza:pt-6ibd has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=pt-6ibd&vendor=azza&num=2
Compilation of bcom:winnet100 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=winnet100&vendor=bcom&num=2
Compilation of bcom:winnetp680 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=winnetp680&vendor=bcom&num=2
Compilation of biostar:m6tba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=m6tba&vendor=biostar&num=2
Compilation of broadcom:blast has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=blast&vendor=broadcom&num=2
Compilation of compaq:deskpro_en_sff_p600 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=deskpro_en_sff_p600&vendor=compaq&num=2
Compilation of dell:s1850 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s1850&vendor=dell&num=2
Compilation of digitallogic:adl855pc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=adl855pc&vendor=digitallogic&num=2
Compilation of digitallogic:msm586seg has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=msm586seg&vendor=digitallogic&num=2
Compilation of digitallogic:msm800sev has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=msm800sev&vendor=digitallogic&num=2
Compilation of eaglelion:5bcm has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=5bcm&vendor=eaglelion&num=2
Compilation of embeddedplanet:ep405pc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of emulation:qemu-x86 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=qemu-x86&vendor=emulation&num=2
Compilation of gigabyte:ga-6bxc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ga-6bxc&vendor=gigabyte&num=2
Compilation of gigabyte:ga_2761gxdk has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ga_2761gxdk&vendor=gigabyte&num=2
Compilation of gigabyte:m57sli has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=m57sli&vendor=gigabyte&num=2
Compilation of hp:dl145_g3 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dl145_g3&vendor=hp&num=2
Compilation of ibm:e325 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=e325&vendor=ibm&num=2
Compilation of ibm:e326 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=e326&vendor=ibm&num=2
Compilation of iei:juki-511p has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=juki-511p&vendor=iei&num=2
Compilation of iei:nova4899r has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=nova4899r&vendor=iei&num=2
Compilation of iei:pcisa-lx-800-r10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=pcisa-lx-800-r10&vendor=iei&num=2
Compilation of intel:eagleheights has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=eagleheights&vendor=intel&num=2
Compilation of intel:jarrell has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=jarrell&vendor=intel&num=2
Compilation of intel:mtarvon has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=mtarvon&vendor=intel&num=2
Compilation of intel:truxton has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=truxton&vendor=intel&num=2
Compilation of intel:xe7501devkit has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=xe7501devkit&vendor=intel&num=2
Compilation of iwill:dk8_htx has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dk8_htx&vendor=iwill&num=2
Compilation of iwill:dk8s2 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dk8s2&vendor=iwill&num=2
Compilation of iwill:dk8x has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=dk8x&vendor=iwill&num=2
Compilation of jetway:j7f24 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=j7f24&vendor=jetway&num=2
Compilation of kontron:986lcd-m has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=986lcd-m&vendor=kontron&num=2
Compilation of lippert:frontrunner has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=frontrunner&vendor=lippert&num=2
Compilation of lippert:roadrunner-lx has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=roadrunner-lx&vendor=lippert&num=2
Compilation of lippert:spacerunner-lx has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=spacerunner-lx&vendor=lippert&num=2
Compilation of mitac:6513wu has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=6513wu&vendor=mitac&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of msi:ms6119 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms6119&vendor=msi&num=2
Compilation of msi:ms6147 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms6147&vendor=msi&num=2
Compilation of msi:ms6178 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms6178&vendor=msi&num=2
Compilation of msi:ms7135 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms7135&vendor=msi&num=2
Compilation of msi:ms7260 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms7260&vendor=msi&num=2
Compilation of msi:ms9185 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms9185&vendor=msi&num=2
Compilation of msi:ms9282 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ms9282&vendor=msi&num=2
Compilation of nec:powermate2000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=powermate2000&vendor=nec&num=2
Compilation of newisys:khepri has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=khepri&vendor=newisys&num=2
Compilation of nvidia:l1_2pvv has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=l1_2pvv&vendor=nvidia&num=2
Compilation of olpc:btest has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=btest&vendor=olpc&num=2
Compilation of olpc:rev_a has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=rev_a&vendor=olpc&num=2
Compilation of pcengines:alix1c has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=alix1c&vendor=pcengines&num=2
Compilation of rca:rm4100 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=rm4100&vendor=rca&num=2
Compilation of soyo:sy-6ba-plus-iii has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=sy-6ba-plus-iii&vendor=soyo&num=2
Compilation of sunw:ultra40 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ultra40&vendor=sunw&num=2
Compilation of supermicro:h8dme has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=h8dme&vendor=supermicro&num=2
Compilation of supermicro:h8dmr has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=h8dmr&vendor=supermicro&num=2
Compilation of supermicro:x6dai_g has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=x6dai_g&vendor=supermicro&num=2
Compilation of supermicro:x6dhe_g has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=x6dhe_g&vendor=supermicro&num=2
Compilation of supermicro:x6dhe_g2 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=x6dhe_g2&vendor=supermicro&num=2
Compilation of supermicro:x6dhr_ig has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=x6dhr_ig&vendor=supermicro&num=2
Compilation of supermicro:x6dhr_ig2 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=x6dhr_ig2&vendor=supermicro&num=2
Compilation of technexion:tim8690 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=tim8690&vendor=technexion&num=2
Compilation of technologic:ts5300 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ts5300&vendor=technologic&num=2
Compilation of televideo:tc7020 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=tc7020&vendor=televideo&num=2
Compilation of thomson:ip1000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=ip1000&vendor=thomson&num=2
Compilation of totalimpact:briq has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=briq&vendor=totalimpact&num=2
Compilation of tyan:s1846 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s1846&vendor=tyan&num=2
Compilation of tyan:s2735 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2735&vendor=tyan&num=2
Compilation of tyan:s2850 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2850&vendor=tyan&num=2
Compilation of tyan:s2875 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2875&vendor=tyan&num=2
Compilation of tyan:s2880 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2880&vendor=tyan&num=2
Compilation of tyan:s2881 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2881&vendor=tyan&num=2
Compilation of tyan:s2882 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2882&vendor=tyan&num=2
Compilation of tyan:s2885 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2885&vendor=tyan&num=2
Compilation of tyan:s2891 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2891&vendor=tyan&num=2
Compilation of tyan:s2892 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2892&vendor=tyan&num=2
Compilation of tyan:s2895 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2895&vendor=tyan&num=2
Compilation of tyan:s2912 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2912&vendor=tyan&num=2
Compilation of tyan:s2912_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s2912_fam10&vendor=tyan&num=2
Compilation of tyan:s4880 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s4880&vendor=tyan&num=2
Compilation of tyan:s4882 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=s4882&vendor=tyan&num=2
Compilation of via:epia has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=epia&vendor=via&num=2
Compilation of via:epia-cn has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=epia-cn&vendor=via&num=2
Compilation of via:epia-m has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=epia-m&vendor=via&num=2
Compilation of via:epia-m700 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=epia-m700&vendor=via&num=2
Compilation of via:epia-n has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=epia-n&vendor=via&num=2
Compilation of via:pc2500e has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=pc2500e&vendor=via&num=2
Compilation of via:vt8454c has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4630&device=vt8454c&vendor=via&num=2


If something broke during this checkin please be a pain 
in oxygene's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Mon Sep 14 16:13:13 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 14 Sep 2009 16:13:13 +0200
Subject: [coreboot] [v2] r4631 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3695.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-14 16:13:13 +0200 (Mon, 14 Sep 2009)
New Revision: 4631

Modified:
   trunk/coreboot-v2/util/cbfstool/Makefile
   trunk/coreboot-v2/util/cbfstool/Makefile.inc
Log:
Build cbfstool with native data size. Trivial change.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/util/cbfstool/Makefile
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-14 13:29:27 UTC (rev 4630)
+++ trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-14 14:13:13 UTC (rev 4631)
@@ -42,9 +42,9 @@
 tags: 
 	ctags *.[ch]
 
-CXXFLAGS=-DCOMPACT -m32
-CFLAGS=-m32
-LDFLAGS=-m32
+CXXFLAGS=-DCOMPACT
+CFLAGS=
+LDFLAGS=
 
 $(obj)/cbfstool:$(COMMON)
 	$(HOSTCXX) $(LDFLAGS) -o $@ $^

Modified: trunk/coreboot-v2/util/cbfstool/Makefile.inc
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-14 13:29:27 UTC (rev 4630)
+++ trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-14 14:13:13 UTC (rev 4631)
@@ -16,7 +16,7 @@
 cbfsobj += cbfs-mkpayload.o
 cbfsobj += cbfstool.o
 
-CBFSTOOLFLAGS=-m32 -DCOMPACT
+CBFSTOOLFLAGS=-DCOMPACT
 
 $(obj)/util/cbfstool:
 	mkdir -p $@




From svn at coreboot.org  Mon Sep 14 16:15:43 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 14 Sep 2009 16:15:43 +0200
Subject: [coreboot] [v2] r4632 - trunk/coreboot-v2/util/kconfig
Message-ID: <mailman.3696.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-14 16:15:43 +0200 (Mon, 14 Sep 2009)
New Revision: 4632

Modified:
   trunk/coreboot-v2/util/kconfig/mconf.c
Log:
In the mainboard selection, the selected mainboard is printed twice in
certain cases, this patch eliminates the second mention.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>


Modified: trunk/coreboot-v2/util/kconfig/mconf.c
===================================================================
--- trunk/coreboot-v2/util/kconfig/mconf.c	2009-09-14 14:13:13 UTC (rev 4631)
+++ trunk/coreboot-v2/util/kconfig/mconf.c	2009-09-14 14:15:43 UTC (rev 4632)
@@ -506,11 +506,14 @@
 			if (def_menu) {
 				item_add_str(" (%s)", _(menu_get_prompt(def_menu)));
 				item_add_str("  --->");
+#if 0 
+/* coreboot doesn't need this representation */
 				if (def_menu->list) {
 					indent += 2;
 					build_conf(def_menu);
 					indent -= 2;
 				}
+#endif
 			}
 			return;
 		}




From info at coresystems.de  Mon Sep 14 16:39:10 2009
From: info at coresystems.de (coreboot information)
Date: Mon, 14 Sep 2009 16:39:10 +0200
Subject: [coreboot] build service results for r4631
Message-ID: <E1MnChy-0001Q6-MO@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "oxygene" checked in revision 4631 to
the coreboot repository. This caused the following 
changes:

Change Log:
Build cbfstool with native data size. Trivial change.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Build Log:
Compilation of a-trend:atc-6220 has been fixed
Compilation of a-trend:atc-6240 has been fixed
Compilation of abit:be6-ii_v2_0 has been fixed
Compilation of advantech:pcm-5820 has been fixed
Compilation of amd:db800 has been fixed
Compilation of amd:dbm690t has been fixed
Compilation of amd:norwich has been fixed
Compilation of amd:pistachio has been fixed
Compilation of amd:rumba has been fixed
Compilation of amd:serengeti_cheetah has been fixed
Compilation of amd:serengeti_cheetah_fam10 has been fixed
Compilation of arima:hdama has been fixed
Compilation of artecgroup:dbe61 has been fixed
Compilation of asi:mb_5blgp has been fixed
Compilation of asi:mb_5blmp has been fixed
Compilation of asus:a8n_e has been fixed
Compilation of asus:a8v-e_se has been fixed
Compilation of asus:m2v-mx_se has been fixed
Compilation of asus:mew-am has been fixed
Compilation of asus:mew-vm has been fixed
Compilation of asus:p2b has been fixed
Compilation of asus:p2b-d has been fixed
Compilation of asus:p2b-ds has been fixed
Compilation of asus:p2b-f has been fixed
Compilation of asus:p3b-f has been fixed
Compilation of axus:tc320 has been fixed
Compilation of azza:pt-6ibd has been fixed
Compilation of bcom:winnet100 has been fixed
Compilation of bcom:winnetp680 has been fixed
Compilation of biostar:m6tba has been fixed
Compilation of broadcom:blast has been fixed
Compilation of compaq:deskpro_en_sff_p600 has been fixed
Compilation of dell:s1850 has been fixed
Compilation of digitallogic:adl855pc has been fixed
Compilation of digitallogic:msm586seg has been fixed
Compilation of digitallogic:msm800sev has been fixed
Compilation of eaglelion:5bcm has been fixed
Compilation of embeddedplanet:ep405pc has been fixed
Compilation of emulation:qemu-x86 has been fixed
Compilation of gigabyte:ga-6bxc has been fixed
Compilation of gigabyte:ga_2761gxdk has been fixed
Compilation of gigabyte:m57sli has been fixed
Compilation of hp:dl145_g3 has been fixed
Compilation of ibm:e325 has been fixed
Compilation of ibm:e326 has been fixed
Compilation of iei:juki-511p has been fixed
Compilation of iei:nova4899r has been fixed
Compilation of iei:pcisa-lx-800-r10 has been fixed
Compilation of intel:eagleheights has been fixed
Compilation of intel:jarrell has been fixed
Compilation of intel:mtarvon has been fixed
Compilation of intel:truxton has been fixed
Compilation of intel:xe7501devkit has been fixed
Compilation of iwill:dk8_htx has been fixed
Compilation of iwill:dk8s2 has been fixed
Compilation of iwill:dk8x has been fixed
Compilation of jetway:j7f24 has been fixed
Compilation of kontron:986lcd-m has been fixed
Compilation of lippert:frontrunner has been fixed
Compilation of lippert:roadrunner-lx has been fixed
Compilation of lippert:spacerunner-lx has been fixed
Compilation of mitac:6513wu has been fixed
Compilation of motorola:sandpointx3_altimus_mpc7410 has been fixed
Compilation of msi:ms6119 has been fixed
Compilation of msi:ms6147 has been fixed
Compilation of msi:ms6178 has been fixed
Compilation of msi:ms7135 has been fixed
Compilation of msi:ms7260 has been fixed
Compilation of msi:ms9185 has been fixed
Compilation of msi:ms9282 has been fixed
Compilation of nec:powermate2000 has been fixed
Compilation of newisys:khepri has been fixed
Compilation of nvidia:l1_2pvv has been fixed
Compilation of olpc:btest has been fixed
Compilation of olpc:rev_a has been fixed
Compilation of pcengines:alix1c has been fixed
Compilation of rca:rm4100 has been fixed
Compilation of soyo:sy-6ba-plus-iii has been fixed
Compilation of sunw:ultra40 has been fixed
Compilation of supermicro:h8dme has been fixed
Compilation of supermicro:h8dmr has been fixed
Compilation of supermicro:x6dai_g has been fixed
Compilation of supermicro:x6dhe_g has been fixed
Compilation of supermicro:x6dhe_g2 has been fixed
Compilation of supermicro:x6dhr_ig has been fixed
Compilation of supermicro:x6dhr_ig2 has been fixed
Compilation of technexion:tim8690 has been fixed
Compilation of technologic:ts5300 has been fixed
Compilation of televideo:tc7020 has been fixed
Compilation of thomson:ip1000 has been fixed
Compilation of totalimpact:briq has been fixed
Compilation of tyan:s1846 has been fixed
Compilation of tyan:s2735 has been fixed
Compilation of tyan:s2850 has been fixed
Compilation of tyan:s2875 has been fixed
Compilation of tyan:s2880 has been fixed
Compilation of tyan:s2881 has been fixed
Compilation of tyan:s2882 has been fixed
Compilation of tyan:s2885 has been fixed
Compilation of tyan:s2891 has been fixed
Compilation of tyan:s2892 has been fixed
Compilation of tyan:s2895 has been fixed
Compilation of tyan:s2912 has been fixed
Compilation of tyan:s2912_fam10 has been fixed
Compilation of tyan:s4880 has been fixed
Compilation of tyan:s4882 has been fixed
Compilation of via:epia has been fixed
Compilation of via:epia-cn has been fixed
Compilation of via:epia-m has been fixed
Compilation of via:epia-m700 has been fixed
Compilation of via:epia-n has been fixed
Compilation of via:pc2500e has been fixed
Compilation of via:vt8454c has been fixed


If something broke during this checkin please be a pain 
in oxygene's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Mon Sep 14 17:21:39 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 14 Sep 2009 09:21:39 -0600
Subject: [coreboot] SMP Linux on QEMU
In-Reply-To: <1519b3fb0909111641p1aed40ebhf82fde0162d8156f@mail.gmail.com>
References: <1519b3fb0909101726y133dd361xd3569a11470ee66f@mail.gmail.com>
	<2831fecf0909111541i1de1d252x688be053644d674a@mail.gmail.com>
	<1519b3fb0909111610x2b573ffcke41fbd98b0a42028@mail.gmail.com>
	<13426df10909111615mff99e48oe4bc166e5afa30db@mail.gmail.com>
	<1519b3fb0909111640g5d0da184v37c546f15749f444@mail.gmail.com>
	<1519b3fb0909111641p1aed40ebhf82fde0162d8156f@mail.gmail.com>
Message-ID: <2831fecf0909140821r286eb1bboc1b2defabf780d67@mail.gmail.com>

On Fri, Sep 11, 2009 at 5:41 PM, Jen-Cheng(Tommy) Huang
<tommy24 at gatech.edu>wrote:

>
> Thanks for the info.
>
> coreboot v2 rev. 4629qemu 0.10.5
> filo 0.6
> gcc 4.2.4
>
Ubuntu
coreboot v2 4629
qemu 0.9.1
gcc 4.2.3 (Ubuntu)

The reason I didn't think it was a toolchain issue is that it was looking
for normal/coreboot_ram, which shouldn't exist at all anymore.  I thought
qemu had been fallback only for a while now.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090914/544c7cbd/attachment.html>

From svn at coreboot.org  Mon Sep 14 18:12:50 2009
From: svn at coreboot.org (coreboot)
Date: Mon, 14 Sep 2009 16:12:50 -0000
Subject: [coreboot] #16: I2C driver and mainboard Config.lb
In-Reply-To: <042.195f4ef97c45fba21898f9914a491509@coreboot.org>
References: <042.195f4ef97c45fba21898f9914a491509@coreboot.org>
Message-ID: <051.652e111e2a1a01725a1cc8a718ae1b0a@coreboot.org>

#16: I2C driver and mainboard Config.lb
----------------------+-----------------------------------------------------
 Reporter:  stepan    |          Owner:  ollie
     Type:  defect    |         Status:  new  
 Priority:  minor     |      Milestone:       
Component:  coreboot  |        Version:  v2   
 Keywords:            |   Dependencies:       
----------------------+-----------------------------------------------------

Comment(by JohnMlkolkzzbvvfa):

 http://gologle.com, <a href=gologle.com>goolgle</a>

-- 
Ticket URL: <http://tracker.coreboot.org/trac/coreboot/ticket/16#comment:1>
coreboot <http://www.coreboot.org/>


From marcj303 at gmail.com  Mon Sep 14 18:45:07 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 14 Sep 2009 10:45:07 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz> <4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
Message-ID: <534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>

I am not sure what I was thinking last night. This is really simple...
There is no address manipulation to be done before calling the
coreboot pci functions. Thanks Patrick....

Marc

-- 
http://marcjonesconsulting.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pci_rw.patch
Type: application/octet-stream
Size: 976 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090914/6a6c151e/attachment.obj>

From mylesgw at gmail.com  Mon Sep 14 18:49:39 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 14 Sep 2009 10:49:39 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
Message-ID: <2831fecf0909140949i6d4eee8do4a8cfc6e728b4745@mail.gmail.com>

On Mon, Sep 14, 2009 at 10:45 AM, Marc Jones <marcj303 at gmail.com> wrote:

> I am not sure what I was thinking last night. This is really simple...
> There is no address manipulation to be done before calling the
> coreboot pci functions. Thanks Patrick....
>

It looks like GetNB and SetNB should die.  Is there a purpose for having the
extra indirection?

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090914/cd4f88f8/attachment.html>

From patrick at georgi-clan.de  Mon Sep 14 18:50:07 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Mon, 14 Sep 2009 18:50:07 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz> <4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de> <20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de> <20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
Message-ID: <1252947008.4785.1.camel@tetris>

Am Montag, den 14.09.2009, 10:45 -0600 schrieb Marc Jones:
> I am not sure what I was thinking last night. This is really simple...
> There is no address manipulation to be done before calling the
> coreboot pci functions. Thanks Patrick....
The board boots much more reliable now, thank you!


Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>




From peter at stuge.se  Mon Sep 14 18:52:47 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 14 Sep 2009 18:52:47 +0200
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <2831fecf0909140949i6d4eee8do4a8cfc6e728b4745@mail.gmail.com>
References: <13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
	<2831fecf0909140949i6d4eee8do4a8cfc6e728b4745@mail.gmail.com>
Message-ID: <20090914165247.9051.qmail@stuge.se>

Myles Watson wrote:
> It looks like GetNB and SetNB should die.

+1


//Peter



From marcj303 at gmail.com  Mon Sep 14 18:58:15 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 14 Sep 2009 10:58:15 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <20090914165247.9051.qmail@stuge.se>
References: <13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
	<2831fecf0909140949i6d4eee8do4a8cfc6e728b4745@mail.gmail.com>
	<20090914165247.9051.qmail@stuge.se>
Message-ID: <534e5dc20909140958saf97814o9cd7cf7ae7ce5e93@mail.gmail.com>

On Mon, Sep 14, 2009 at 10:52 AM, Peter Stuge <peter at stuge.se> wrote:
> Myles Watson wrote:
>> It looks like GetNB and SetNB should die.
>
> +1

I guess it should. The only reason to keep it is for easily diffing
against the AMD AGESA reference code, but I am not certain if or when
that will happen again.

Marc

-- 
http://marcjonesconsulting.com



From svn at coreboot.org  Mon Sep 14 19:00:04 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Mon, 14 Sep 2009 19:00:04 +0200
Subject: [coreboot] [v2] r4633 -
	trunk/coreboot-v2/src/northbridge/amd/amdmct/mct
Message-ID: <mailman.3697.1355071618.16123.coreboot@coreboot.org>

Author: mjones
Date: 2009-09-14 19:00:04 +0200 (Mon, 14 Sep 2009)
New Revision: 4633

Modified:
   trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c
Log:
Use the coreboot pci config read/write functions instead of direct cf8/cfc
access. The fam10 pci functions will use mmio and do not have SMP pci access
issues.

Signed-off-by: Marc Jones <marcj303 at gmail.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



Modified: trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c	2009-09-14 14:15:43 UTC (rev 4632)
+++ trunk/coreboot-v2/src/northbridge/amd/amdmct/mct/mct_d.c	2009-09-14 17:00:04 UTC (rev 4633)
@@ -2472,22 +2472,13 @@
 
 u32 Get_NB32(u32 dev, u32 reg)
 {
-	u32 addr;
-
-	addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16);
-	outl((1<<31) | (addr & ~3), 0xcf8);
-
-	return inl(0xcfc);
+	return pci_read_config32(dev, reg);
 }
 
 
 void Set_NB32(u32 dev, u32 reg, u32 val)
 {
-	u32 addr;
-
-	addr = (dev>>4) | (reg & 0xFF) | ((reg & 0xf00)<<16);
-	outl((1<<31) | (addr & ~3), 0xcf8);
-	outl(val, 0xcfc);
+	pci_write_config32(dev, reg, val);
 }
 
 




From marcj303 at gmail.com  Mon Sep 14 19:00:28 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Mon, 14 Sep 2009 11:00:28 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <1252947008.4785.1.camel@tetris>
References: <4AA1496A.5030206@assembler.cz> <4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<20090906201347.16045.qmail@stuge.se>
	<13426df10909061532y11b103afl7ade981fe2f844f7@mail.gmail.com>
	<534e5dc20909081002k7d62252ajdaf738aeadc2e52f@mail.gmail.com>
	<534e5dc20909131746s27fdac9bube60b3fec2535d8@mail.gmail.com>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
	<1252947008.4785.1.camel@tetris>
Message-ID: <534e5dc20909141000q5e0ccdbdj71903743af038215@mail.gmail.com>

On Mon, Sep 14, 2009 at 10:50 AM, Patrick Georgi <patrick at georgi-clan.de> wrote:
> Am Montag, den 14.09.2009, 10:45 -0600 schrieb Marc Jones:
>> I am not sure what I was thinking last night. This is really simple...
>> There is no address manipulation to be done before calling the
>> coreboot pci functions. Thanks Patrick....
> The board boots much more reliable now, thank you!
>
>
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>
>
>

Thanks Patrick.

r4633

-- 
http://marcjonesconsulting.com



From rminnich at gmail.com  Mon Sep 14 22:42:18 2009
From: rminnich at gmail.com (ron minnich)
Date: Mon, 14 Sep 2009 13:42:18 -0700
Subject: [coreboot] finding the flash write enable.
Message-ID: <13426df10909141342q7793cba2tf6d3d5df41a75dc4@mail.gmail.com>

we just had the need to find a flash write enable on some servers.
These are Dell S1850s and we're tired of having a non-Linux-based
Flash tool, and, still worse, one to which we do not have source.
Flashrom would be great, save that it can't get the flash to write. We
decided to see if it was the classic GPIO-enabled FLASH write pin,
which is the standard it seems in PC hardware.

In this note I am just describing a program that I wrote long ago at
LANL and have used from time to time when I could not get the info I
needed on enabling FLASH write.

One thing we have found over the past 10 years: the single most common
write enable control is a GPIO attached to
a southbridge. Don't know why it always seems to be this way, but there it is.

This leads to a simple strategy to test for a GPIO enable, and to find
which one it is.

First, we find the southbridge, which in this case is an ICH5. The
GPIO programming on this part is little changed from earlier parts.

Then we find the pci function which has the GPIOs. It's usually the LPC bridge.

So for ICH5:
00:1f.0 ISA bridge: Intel Corporation 82801EB/ER (ICH5/ICH5R) LPC
Interface Bridge (rev 02)

it's that one.

So, to make it easy, rather than look at the BAR for the GPIO, just
cat /proc/ioports and find this:
 0880-08bf : 0000:00:1f.0
  0880-08bf : pnp 00:06

OK, we are about ready to go. The base address of the GPIOs is 0x880.
If you're paranoid confirm it with setpci:
[root at tn4 ~]# setpci -s 0:1f.0 58.l
00000881
[root at tn4 ~]#

You need to look up the IO space mappings of SOME of the registers,
but for this simple program, not ALL. In fact all we're going to do is
read in the GPIO data level register, complement it, write it out,
then run flashrom to see if it works.
But, you ask:
- what if you read inputs and write them out
   nothing, so don't worry. They're inputs.
- you change GPIO pins that do some other thing
  well, it gets harder in that case. For instance, some laptops use a
GPIO pin to enable DRAM power. Don't
  worry, you'll find out if they do. In that case, you'll have to do
32 boot/test cycles in the worst case, instead of the
  five we do here. It actually can be instructive on a laptop to
change output GPIO levels and see what happens,
  so this is a fun test to do anyway.

First, though, do this: flashrom -r factory.img

Then emacs factory.img, (Go into OVRWRT mode!) and look for a string like this:
F2 = Setup

I changed it to
F2 = FIXup

I may have used some other F-based words, as time went on, but that's
another story.

You want to make sure that if you really do rewrite it that it is easy
to tell! With this change, as soon as the
BIOS splash screen comes up, you will know.

OK, some code:
Just set a few things up we think we'll need.

#include <stdio.h>
#include <sys/io.h>

#define LVL 0xc

LVL is the level register for the GPIO.
Now let's go to work.

int main(int argc, char *argv[])
{
        unsigned long gpioport = 0x880;
        unsigned long gpioval;

        iopl(3);

        /* first simple test: read in all GPIOs, complement them,
         * output them, see if flashrom works */
        gpioval = inl(gpioport + LVL);
        printf("GPIO is 0x%x (default 0x1f1f0000)\n", gpioval);

        /* invert */
        gpioval = ~gpioval;
        printf("GPIO will be set to 0x%x \n", gpioval);
        outl(gpioval, gpioport + LVL);
        gpioval = inl(gpioport + LVL);
        printf("GPIO is 0x%x \n", gpioval);
}

OK, call this program 'one'. At this point, you want to try a flashrom
run. As it happens this works and is sufficient to allow us to use
flashrom!

How to finish the task? It's actually a fairly simple newtonian search.

First try gpioval ^= 0xffff0000;

If that works, then try 0xff000000, etc. etc. Even if you get it
wrong, which I did, it still doesn't take long to find it.

Warning, though: each time you try, be sure to change the FIXup string
in the rom image, to be very very sure that you really did rewrite it.
You need to be careful about this step.

Anyway, hope that is a little useful. It really is a very simple
process to find a GPIO enable. That's one reason that vendors are
going to make this much, much harder on future systems. GPIO enables
are not a security feature, in spite of what you may have heard; they
are really accident protection in case some piece of software goes
insane and starts writing to random memory locations.

ron



From Zheng.Bao at amd.com  Tue Sep 15 03:51:57 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 15 Sep 2009 09:51:57 +0800
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
References: <4AA1496A.5030206@assembler.cz>
	<4AA2B862.3070409@coresystems.de><13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com><4AA379C7.1090508@coresystems.de><20090906123941.27507.qmail@stuge.se><4AA41016.6010501@coresystems.de><20090906201347
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703072973@sbjgexmb1.amd.com>

Are you sure the pci functions will cover the case that the address is
more than 0x100?


Zheng

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Marc Jones
Sent: Tuesday, September 15, 2009 12:45 AM
To: ron minnich
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] unstable AMD Fam10h boot

I am not sure what I was thinking last night. This is really simple...
There is no address manipulation to be done before calling the
coreboot pci functions. Thanks Patrick....

Marc

-- 
http://marcjonesconsulting.com




From Zheng.Bao at amd.com  Tue Sep 15 05:00:40 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Tue, 15 Sep 2009 11:00:40 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
Message-ID: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>

I am using FC10. GCC 4.3.2.

 

 

...............................

make[1]: Leaving directory
`/home/baozheng/LinuxBIOS/coreboot-v2-org/util/cbfstool'

make -C fallback coreboot.rom

cat: ../../VERSION: No such file or directory

make[1]: Entering directory
`/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_
fam10/serengeti_cheetah_fam10/fallback'

gcc -m32 -x assembler-with-cpp -DASSEMBLY -E
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/include
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/arch/i386/include
-I/usr/lib/gcc/i386-redhat-linux/4.3.2/include -include
/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_f
am10/serengeti_cheetah_fam10/fallback/settings.h
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/util/x86emu/include -I.
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src  crt0.S > crt0.s.new &&
mv crt0.s.new crt0.s

gcc -m32 -Wa,-acdlns -c  -o crt0.o crt0.s >crt0.disasm

gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -static -o coreboot
-T ldscript.ld crt0.o  src/lib/lzma.o src/lib/cbfs.o
src/arch/i386/lib/cbfs_and_run.o src/lib/uart8250.o src/lib/memcmp.o
src/lib/memcpy.o src/lib/memset.o src/console/vtxprintf.o
src/arch/i386/lib/printk_init.o

nm -n coreboot | sort > coreboot.map

objdump -dS coreboot > coreboot.disasm

objcopy --gap-fill 0xff -O binary coreboot coreboot.strip

PAYLOAD=payload; if [ 1 -eq 1 ]; then PAYLOAD=/dev/null; touch
cbfs-support; fi; ./buildrom coreboot.strip coreboot.rom $PAYLOAD
0x7f000 0x7f000

Payload: 0 coreboot: 520192 ROM size: 520192 Left space: 0

if [ 0 -eq 1 -a 1 -eq 1 ]; then echo l > cbfs-support; fi

make[1]: Leaving directory
`/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_
fam10/serengeti_cheetah_fam10/fallback'

make -C failover coreboot.rom

cat: ../../VERSION: No such file or directory

make[1]: Entering directory
`/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_
fam10/serengeti_cheetah_fam10/failover'

gcc -m32 -x assembler-with-cpp -DASSEMBLY -E
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/include
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src/arch/i386/include
-I/usr/lib/gcc/i386-redhat-linux/4.3.2/include -include
/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_f
am10/serengeti_cheetah_fam10/failover/settings.h
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/util/x86emu/include -I.
-I/home/baozheng/LinuxBIOS/coreboot-v2-org/src  crt0.S > crt0.s.new &&
mv crt0.s.new crt0.s

gcc -m32 -Wa,-acdlns -c  -o crt0.o crt0.s >crt0.disasm

gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -static -o coreboot
-T ldscript.ld crt0.o  src/lib/uart8250.o src/lib/memcmp.o
src/lib/memcpy.o src/lib/memset.o src/console/vtxprintf.o
src/arch/i386/lib/printk_init.o

nm -n coreboot | sort > coreboot.map

objdump -dS coreboot > coreboot.disasm

objcopy --gap-fill 0xff -O binary coreboot coreboot.strip

cp coreboot.strip coreboot.rom

make[1]: Leaving directory
`/home/baozheng/LinuxBIOS/coreboot-v2-org/targets/amd/serengeti_cheetah_
fam10/serengeti_cheetah_fam10/failover'

rm -f ./coreboot.rom

cat fallback/coreboot.rom  failover/coreboot.rom >
./coreboot.rom.bootblock

./cbfs/cbfstool ./coreboot.rom create 1048576 528384
./coreboot.rom.bootblock

./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
fallback/payload 

make: *** [coreboot.rom] Segmentation fault

make: *** Deleting file `coreboot.rom'

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090915/ca469a9b/attachment.html>

From svn at coreboot.org  Tue Sep 15 10:21:46 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 15 Sep 2009 10:21:46 +0200
Subject: [coreboot] [v2] r4634 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3698.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-15 10:21:46 +0200 (Tue, 15 Sep 2009)
New Revision: 4634

Modified:
   trunk/coreboot-v2/util/cbfstool/cbfstool.c
   trunk/coreboot-v2/util/cbfstool/common.c
Log:
More error checking when trying to open files in
cbfstool. (trivial)

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/util/cbfstool/cbfstool.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-14 17:00:04 UTC (rev 4633)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-15 08:21:46 UTC (rev 4634)
@@ -57,6 +57,10 @@
 	}
 
 	void *rom = loadrom(romname);
+	if (rom == NULL) {
+		printf("Could not load ROM image '%s'.\n", romname);
+		return 1;
+	}
 
 	if (strcmp(cmd, "print") == 0) {
 		print_cbfs_directory(romname);
@@ -68,11 +72,15 @@
 		return 1;
 	}
 
-	void *filename = argv[3];
-	void *cbfsname = argv[4];
+	char *filename = argv[3];
+	char *cbfsname = argv[4];
 
 	uint32_t filesize = 0;
 	void *filedata = loadfile(filename, &filesize, 0, SEEK_SET);
+	if (filedata == NULL) {
+		printf("Could not load file '%s'.\n", filename);
+		return 1;
+	}
 
 	uint32_t base = 0;
 	void *cbfsfile;

Modified: trunk/coreboot-v2/util/cbfstool/common.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/common.c	2009-09-14 17:00:04 UTC (rev 4633)
+++ trunk/coreboot-v2/util/cbfstool/common.c	2009-09-15 08:21:46 UTC (rev 4634)
@@ -31,6 +31,8 @@
 	       int place)
 {
 	FILE *file = fopen(filename, "rb");
+	if (file == NULL)
+		return NULL;
 	fseek(file, 0, SEEK_END);
 	*romsize_p = ftell(file);
 	fseek(file, 0, SEEK_SET);
@@ -65,6 +67,8 @@
 void *loadrom(const char *filename)
 {
 	void *romarea = loadfile(filename, &romsize, 0, SEEK_SET);
+	if (romarea == NULL)
+		return NULL;
 	recalculate_rom_geometry(romarea);
 	return romarea;
 }




From patrick at georgi-clan.de  Tue Sep 15 10:25:41 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Tue, 15 Sep 2009 10:25:41 +0200
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
Message-ID: <1253003141.12121.12.camel@tetris>

Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng:

> ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
> fallback/payload 
> 
> make: *** [coreboot.rom] Segmentation fault

r4634 fixes segmentation faults when the file cannot be found.
"../payload.elf" is suspicious - are you sure that is the right path?

If you're certain that this file should exist at that place, and if the
segmentation fault still occurs with r4634, some more information is
necessary:
- which payload is this (so I can try to reproduce it, a copy of the
payload binary would help the most)
- is your build machine 32bit or 64bit?


Regards,
Patrick




From svn at coreboot.org  Tue Sep 15 17:00:02 2009
From: svn at coreboot.org (coreboot tracker)
Date: Tue, 15 Sep 2009 17:00:02 +0200
Subject: [coreboot] Trac reminder: list of new ticket(s)
Message-ID: <E1MnZVi-0002sA-FC@ra.coresystems.de>

An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090915/ed71889a/attachment.html>

From marcj303 at gmail.com  Tue Sep 15 18:10:38 2009
From: marcj303 at gmail.com (Marc Jones)
Date: Tue, 15 Sep 2009 10:10:38 -0600
Subject: [coreboot] unstable AMD Fam10h boot
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703072973@sbjgexmb1.amd.com>
References: <4AA1496A.5030206@assembler.cz> <4AA2B862.3070409@coresystems.de>
	<13426df10909052200l20cfaa0he10833711b109b57@mail.gmail.com>
	<4AA379C7.1090508@coresystems.de>
	<20090906123941.27507.qmail@stuge.se>
	<4AA41016.6010501@coresystems.de>
	<534e5dc20909140945t1c2dda6dr248887816d915df1@mail.gmail.com>
	<DD1CC71B621B004FA76856E5129D6B1703072973@sbjgexmb1.amd.com>
Message-ID: <534e5dc20909150910g36237ae1u2dba4c63688b93c7@mail.gmail.com>

On Mon, Sep 14, 2009 at 7:51 PM, Bao, Zheng <Zheng.Bao at amd.com> wrote:
> Are you sure the pci functions will cover the case that the address is
> more than 0x100?

It should, unless you know something I don't (bug?). Using the MMIO
config access is the preferred method since it enforces the ordering.
See 2.11 Configuration Space in the BKDG.

Marc

-- 
http://marcjonesconsulting.com



From svn at coreboot.org  Tue Sep 15 22:40:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 15 Sep 2009 22:40:31 +0200
Subject: [coreboot] [v2] r4635 - trunk/coreboot-v2/src/cpu/amd/socket_S1G1
Message-ID: <mailman.3699.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-15 22:40:31 +0200 (Tue, 15 Sep 2009)
New Revision: 4635

Modified:
   trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig
Log:
Don't mix int and boolean for kconfig variables. It might work, it might not.
trivial change.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig	2009-09-15 08:21:46 UTC (rev 4634)
+++ trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig	2009-09-15 20:40:31 UTC (rev 4635)
@@ -3,8 +3,8 @@
 	default false
 
 config K8_REV_F_SUPPORT
-	int
-	default 1
+	bool
+	default true
 	depends on CPU_AMD_SOCKET_S1G1
 
 config CPU_SOCKET_TYPE




From svn at coreboot.org  Wed Sep 16 01:38:27 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 16 Sep 2009 01:38:27 +0200
Subject: [coreboot] [v2] r4636 - in trunk/coreboot-v2:
	src/mainboard/dell/s1850 targets/dell/s1850
Message-ID: <mailman.3700.1355071618.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2009-09-16 01:38:27 +0200 (Wed, 16 Sep 2009)
New Revision: 4636

Modified:
   trunk/coreboot-v2/src/mainboard/dell/s1850/Config.lb
   trunk/coreboot-v2/src/mainboard/dell/s1850/Options.lb
   trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
   trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c
   trunk/coreboot-v2/targets/dell/s1850/Config.lb
Log:
This is an otherwise dead platform. I'm just committing the basics that 
let it build. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>




Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/Config.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/Config.lb	2009-09-15 20:40:31 UTC (rev 4635)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/Config.lb	2009-09-15 23:38:27 UTC (rev 4636)
@@ -138,8 +138,8 @@
 			device pci 1f.2 on end
 			device pci 1f.3 on end
 
-			register "pirq_a_d" = "0x8a07030b"
-			register "pirq_e_h" = "0x85808080"
+			register "pirq_a_d" = "0x8e8b8f80"
+			register "pirq_e_h" = "0x80808080"
 		end
 		device pci 00.0 on end 
 		device pci 00.1 on end

Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/Options.lb	2009-09-15 20:40:31 UTC (rev 4635)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/Options.lb	2009-09-15 23:38:27 UTC (rev 4636)
@@ -84,7 +84,7 @@
 ## Build code to export a programmable irq routing table
 ##
 default CONFIG_HAVE_PIRQ_TABLE=1
-default CONFIG_IRQ_SLOT_COUNT=16
+default CONFIG_IRQ_SLOT_COUNT=9
 
 ##
 ## Build code to export an x86 MP table

Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-15 20:40:31 UTC (rev 4635)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-15 23:38:27 UTC (rev 4636)
@@ -123,13 +123,13 @@
 #if 0
 	display_cpuid_update_microcode();
 #endif
-#if 0
+#if 1
 	print_pci_devices();
 #endif
 #if 1
 	enable_smbus();
 #endif
-#if 0
+#if 1
 //	dump_spd_registers(&cpu[0]);
 	int i;
 	for(i = 0; i < 1; i++) {
@@ -141,15 +141,15 @@
 	mainboard_set_e7520_leds();	
 //	memreset_setup();
 	sdram_initialize(ARRAY_SIZE(mch), mch);
-#if 0
+#if 1
 	dump_pci_devices();
 #endif
-#if 0
+#if 1
 	dump_pci_device(PCI_DEV(0, 0x00, 0));
 	dump_bar14(PCI_DEV(0, 0x00, 0));
 #endif
 
-#if 0 // temporarily disabled 
+#if 1 // temporarily disabled 
 	/* Check the first 1M */
 //	ram_check(0x00000000, 0x000100000);
 //	ram_check(0x00000000, 0x000a0000);

Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c	2009-09-15 20:40:31 UTC (rev 4635)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c	2009-09-15 23:38:27 UTC (rev 4636)
@@ -1,48 +1,53 @@
-/* This file was generated by getpir.c, do not modify! 
-   (but if you do, please run checkpir on it to verify)
- * Contains the IRQ Routing Table dumped directly from your memory, which BIOS sets up
+/*
+ * This file is part of the coreboot project.
  *
- * Documentation at : http://www.microsoft.com/hwdev/busbios/PCIIRQ.HTM
-*/
+ * Copyright (C) 2008 VIA Technologies, Inc.
+ * (Written by Aaron Lwe <aaron.lwe at gmail.com> for VIA)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+ */
 
 #include <arch/pirq_routing.h>
 
 const struct irq_routing_table intel_irq_routing_table = {
-	PIRQ_SIGNATURE,  /* u32 signature */
-	PIRQ_VERSION,    /* u16 version   */
-	32+16*17,	 /* there can be total 17 devices on the bus */
-	0x00,		 /* Where the interrupt router lies (bus) */
-	(0x1f<<3)|0x0,   /* Where the interrupt router lies (dev) */
-	0,		 /* IRQs devoted exclusively to PCI usage */
-	0x8086,		 /* Vendor */
-	0x24d0,		 /* Device */
-	0,		 /* Crap (miniport) */
+	PIRQ_SIGNATURE,
+	PIRQ_VERSION,
+	32 + 16 * 9,/* Max. number of devices on the bus */
+	0x00,			/* Interrupt router bus */
+	(0x11 << 3) | 0x0,	/* Interrupt router device */
+	0xc20,			/* IRQs devoted exclusively to PCI usage */
+	0x1106,			/* Vendor */
+	0x596,			/* Device */
+	0,			/* Crap (miniport) */
 	{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, /* u8 rfu[11] */
-	0xc4,         /*  u8 checksum , this hase to set to some value that would give 0 after the sum of all bytes for this structure (including checksum) */
+	0x66,			/* Checksum */
 	{
 		/* bus,     dev|fn,   {link, bitmap}, {link, bitmap}, {link, bitmap}, {link, bitmap},  slot, rfu */
-		{0x00,(0x02<<3)|0x0, {{0x60, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x00,(0x04<<3)|0x0, {{0x60, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x00,(0x05<<3)|0x0, {{0x60, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x00,(0x06<<3)|0x0, {{0x60, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x05,(0x00<<3)|0x0, {{0x60, 0xccf8}, {0x61, 0xccf8}, {0x62, 0xccf8}, {0x63, 0x0ccf8}}, 0x0, 0x0},
-		{0x01,(0x00<<3)|0x0, {{0x60, 0xccf8}, {0x61, 0xccf8}, {0x62, 0xccf8}, {0x63, 0x0ccf8}}, 0x0, 0x0},
-		{0x00,(0x1d<<3)|0x0, {{0x60, 0xccf8}, {0x63, 0xccf8}, {0x62, 0xccf8}, {0x6b, 0x0ccf8}}, 0x0, 0x0},
-		{0x09,(0x05<<3)|0x0, {{0x68, 0xccf8}, {0x69, 0xccf8}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x09,(0x06<<3)|0x0, {{0x6b, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x09,(0x0d<<3)|0x0, {{0x62, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x09,(0x03<<3)|0x0, {{0x63, 0xccf8}, {0x63, 0xccf8}, {0x63, 0xccf8}, {0x63, 0x0ccf8}}, 0x0, 0x0},
-		{0x06,(0x07<<3)|0x0, {{0x60, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x07,(0x08<<3)|0x0, {{0x61, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x02,(0x05<<3)|0x0, {{0x62, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
-		{0x04,(0x00<<3)|0x0, {{0x60, 0xccf8}, {0x61, 0xccf8}, {0x62, 0xccf8}, {0x63, 0x0ccf8}}, 0x1, 0x0},
-		{0x08,(0x00<<3)|0x0, {{0x60, 0xccf8}, {0x61, 0xccf8}, {0x62, 0xccf8}, {0x63, 0x0ccf8}}, 0x2, 0x0},
-		{0x02,(0x0e<<3)|0x0, {{0x62, 0xccf8}, {0x00, 0x0000}, {0x00, 0x0000}, {0x00, 0x00000}}, 0x0, 0x0},
+		{0x00,(0x14<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x1, 0x0},
+		{0x00,(0x0d<<3)|0x0, {{0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0x0deb8}}, 0x2, 0x0},
+		{0x00,(0x0e<<3)|0x0, {{0x03, 0xdeb8}, {0x04, 0xdeb8}, {0x01, 0xdeb8}, {0x02, 0x0deb8}}, 0x3, 0x0},
+		{0x00,(0x13<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x4, 0x0},
+		{0x00,(0x11<<3)|0x0, {{0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x0f<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x01<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x10<<3)|0x0, {{0x01, 0xdeb8}, {0x02, 0xdeb8}, {0x03, 0xdeb8}, {0x04, 0x0deb8}}, 0x0, 0x0},
+		{0x00,(0x12<<3)|0x0, {{0x01, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0xdeb8}, {0x00, 0x0deb8}}, 0x0, 0x0},
 	}
 };
 
 unsigned long write_pirq_routing_table(unsigned long addr)
 {
-        return copy_pirq_routing_table(addr);
+	return copy_pirq_routing_table(addr);
 }
-

Modified: trunk/coreboot-v2/targets/dell/s1850/Config.lb
===================================================================
--- trunk/coreboot-v2/targets/dell/s1850/Config.lb	2009-09-15 20:40:31 UTC (rev 4635)
+++ trunk/coreboot-v2/targets/dell/s1850/Config.lb	2009-09-15 23:38:27 UTC (rev 4636)
@@ -5,13 +5,13 @@
 option CONFIG_MAXIMUM_CONSOLE_LOGLEVEL=9
 option CONFIG_DEFAULT_CONSOLE_LOGLEVEL=9
 
-romimage "normal"
-	option CONFIG_USE_FALLBACK_IMAGE=0
-	option CONFIG_ROM_IMAGE_SIZE=0x16000
-	option COREBOOT_EXTRA_VERSION=".0Normal"
-#	payload ../../../payloads/filo.elf
-	payload /tmp/filo.elf
-end
+#romimage "normal"
+#	option CONFIG_USE_FALLBACK_IMAGE=0
+#	option CONFIG_ROM_IMAGE_SIZE=0x16000
+#	option COREBOOT_EXTRA_VERSION=".0Normal"
+##	payload ../../../payloads/filo.elf
+#	payload /tmp/filo.elf
+#end
 
 romimage "fallback" 
 	option CONFIG_USE_FALLBACK_IMAGE=1
@@ -21,4 +21,5 @@
 	payload /tmp/filo.elf
 end
 
-buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback"
+#buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback"
+buildrom ./coreboot.rom CONFIG_ROM_SIZE "fallback"




From kevin at koconnor.net  Wed Sep 16 04:11:14 2009
From: kevin at koconnor.net (Kevin O'Connor)
Date: Tue, 15 Sep 2009 22:11:14 -0400
Subject: [coreboot] Geode LX VGA BIOS Patch
In-Reply-To: <4AAD4CAA.9050905@umbc.edu>
References: <4A829320.4020606@umbc.edu> <4A943378.7010000@umbc.edu>
	<20090909133345.GA5979@morn.localdomain>
	<4AAD4CAA.9050905@umbc.edu>
Message-ID: <20090916021114.GB18131@morn.localdomain>

Hi Chris,

On Sun, Sep 13, 2009 at 03:48:58PM -0400, Chris Kindt wrote:
> Kevin O'Connor wrote:
>> As before, the main seabios patch looks good to me.  The "modehack"
>> patch, of course, needs to be cleaned up before committing.  Are you
>> still working on this?
>>
> Yes, it is on my todo list. I was thinking about using a device
> operations structure or macros to replace the "if(hw_type)"
> statements. This might be overkill at the moment, however it would
> be helpful for any future hardware specific expansion. I am lacking  
> insight on what such a struct should be. The following example is  
> crafted mostly to fix the current problems I am having.

Is the intent to support multiple hardware backends with the same
option rom binary?

The "if(hw_type)" scheme has the benefit that gcc can remove the
unused code from the resulting binary.  I think that will be harder
for gcc if function pointers are used.

-Kevin



From Zheng.Bao at amd.com  Wed Sep 16 04:56:23 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 16 Sep 2009 10:56:23 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <1253003141.12121.12.camel@tetris>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>

It was fixed.


Zheng

-----Original Message-----
From: Patrick Georgi [mailto:patrick at georgi-clan.de] 
Sent: Tuesday, September 15, 2009 4:26 PM
To: Bao, Zheng
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng:

> ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
> fallback/payload 
> 
> make: *** [coreboot.rom] Segmentation fault

r4634 fixes segmentation faults when the file cannot be found.
"../payload.elf" is suspicious - are you sure that is the right path?

If you're certain that this file should exist at that place, and if the
segmentation fault still occurs with r4634, some more information is
necessary:
- which payload is this (so I can try to reproduce it, a copy of the
payload binary would help the most)
- is your build machine 32bit or 64bit?


Regards,
Patrick






From rminnich at gmail.com  Wed Sep 16 07:30:53 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Sep 2009 22:30:53 -0700
Subject: [coreboot] patch: always build cbfstool -g; problem with segv.
Message-ID: <13426df10909152230q8a6f744g662070788a447293@mail.gmail.com>

I'm getting this on dell s1850:

rm -f ./coreboot.rom
cat fallback/coreboot.rom > ./coreboot.rom.bootblock
./cbfs/cbfstool ./coreboot.rom create 1048576 90112 ./coreboot.rom.bootblock
./cbfs/cbfstool ./coreboot.rom add-payload /tmp/filo.elf fallback/payload
make: *** [coreboot.rom] Segmentation fault
make: *** Deleting file `coreboot.rom'

And gdb is unhappy. So here's a patch to make our life easier:
You might care about performance but in fact there's not enough of a
difference to matter or even be measured. And, when I get a segv, it's
nice to have it debuggable. And there's certainly no need to strip the
binary ...

Index: util/cbfstool/Makefile
===================================================================
--- util/cbfstool/Makefile	(revision 4636)
+++ util/cbfstool/Makefile	(working copy)
@@ -2,7 +2,9 @@

 HOSTCXX ?= g++
 HOSTCC ?= gcc
+CFLAGS ?= -g

+
 BINARY:=$(obj)/cbfstool

 COMMON:=common.o compress.o minilzma.o
@@ -43,9 +45,8 @@
 	ctags *.[ch]

 CXXFLAGS=-DCOMPACT
-CFLAGS=
-LDFLAGS=
+CFLAGS=-g
+LDFLAGS=-g

 $(obj)/cbfstool:$(COMMON)
 	$(HOSTCXX) $(LDFLAGS) -o $@ $^
-	strip $@



From rminnich at gmail.com  Wed Sep 16 07:36:17 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Sep 2009 22:36:17 -0700
Subject: [coreboot] patch: disable IPMI on the dell s1850
Message-ID: <13426df10909152236r3df6ff86g29810b5aa2ad4cff@mail.gmail.com>

attached.

ron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipmi.diff
Type: text/x-patch
Size: 2646 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090915/e18500bd/attachment.diff>

From Zheng.Bao at amd.com  Wed Sep 16 07:37:39 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 16 Sep 2009 13:37:39 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com><1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>

The latest filo crashes if CBFS is enabled.

The CBFS can not work on my Fam10 board for a long time. I have to
disable it all the time.

Can you guys test it?

Zheng

Log:
.........................
PCI: 00:18.4 links 0 child on link 0 NULL
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 00
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 bridge ctrl <- 000b
PCI: 00:01.0 cmd <- 07
PCI: 01:05.0 subsystem <- 1022/2b80
PCI: 01:05.0 cmd <- 03
PCI: 00:04.0 bridge ctrl <- 0003
PCI: 00:04.0 cmd <- 00
PCI: 00:09.0 bridge ctrl <- 0003
PCI: 00:09.0 cmd <- 00
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 06
PCI: 04:00.0 cmd <- 02
PCI: 00:11.0 cmd <- 03
PCI: 00:12.0 subsystem <- 1022/2b80
PCI: 00:12.0 cmd <- 02
PCI: 00:12.1 subsystem <- 1022/2b80
PCI: 00:12.1 cmd <- 02
PCI: 00:12.2 subsystem <- 1022/2b80
PCI: 00:12.2 cmd <- 02
PCI: 00:13.0 subsystem <- 1022/2b80
PCI: 00:13.0 cmd <- 02
PCI: 00:13.1 subsystem <- 1022/2b80
PCI: 00:13.1 cmd <- 02
PCI: 00:13.2 subsystem <- 1022/2b80
PCI: 00:13.2 cmd <- 02
PCI: 00:14.0 subsystem <- 1022/2b80
PCI: 00:14.0 cmd <- 403
PCI: 00:14.1 subsystem <- 1022/2b80
PCI: 00:14.1 cmd <- 01
PCI: 00:14.2 subsystem <- 1022/2b80
PCI: 00:14.2 cmd <- 02
PCI: 00:14.3 subsystem <- 1022/2b80
PCI: 00:14.3 cmd <- 0f
sb700 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
sb700 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000067
sb700 lpc decode:PNP: 002e.5, base=0x00000064, end=0x0000006b
PNP: 002e.6 missing enable_resources
PCI: 00:14.4 bridge ctrl <- 0003
PCI: 00:14.4 cmd <- 07
PCI: 05:05.0 cmd <- 02
PCI: 00:14.5 subsystem <- 1022/2b80
PCI: 00:14.5 cmd <- 02
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 00
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 00
PCI: 00:18.3 cmd <- 00
PCI: 00:18.4 subsystem <- 1022/2b80
PCI: 00:18.4 cmd <- 00
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x0000e000, offset=0x00200000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 100f42
CPU: family 10, model 04, stepping 02
nodeid = 00, coreid = 00
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
ADDRESS_MASK_HIGH=0xffff
DONE variable MTRRs
Clear out the extra MTRR's
call enable_var_mtrr()
Leave x86_setup_var_mtrrs

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Setting up local apic... apic_id: 0x00 done.
CPU model: AMD Processor model unknown
siblings = 03, CPU #0 initialized
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 1.
After apic_write.
Initializing CPU #1
Startup point 1.
Waiting for send to finish...
+CPU: vendor AMD device 100f42
Sending STARTUP #2 to 1.
After apic_write.
CPU: family 10, model 04, stepping 02
Startup point 1.
Waiting for send to finish...
+nodeid = 00, coreid = 01
After Startup.
Enabling cache
Asserting INIT.

Setting fixed MTRRs(0-88) type: UC
Waiting for send to finish...
+Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Deasserting INIT.
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 2.
After apic_write.
DONE fixed MTRRs
Startup point 1.
Waiting for send to finish...
+Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
Sending STARTUP #2 to 2.
After apic_write.
ADDRESS_MASK_HIGH=0xffff
Startup point 1.
Waiting for send to finish...
+Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
After Startup.
ADDRESS_MASK_HIGH=0xffff
Asserting INIT.
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
Waiting for send to finish...
+ADDRESS_MASK_HIGH=0xffff
Initializing CPU #2
DONE variable MTRRs
Clear out the extra MTRR's
CPU: vendor AMD device 100f42
Deasserting INIT.
call enable_var_mtrr()
Waiting for send to finish...
+Leave x86_setup_var_mtrrs
#startup loops: 2.
Sending STARTUP #1 to 3.
After apic_write.

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Startup point 1.
Waiting for send to finish...
+Setting up local apic...Sending STARTUP #2 to 3.
After apic_write.
 apic_id: 0x01 done.
Startup point 1.
Waiting for send to finish...
+CPU model: AMD Processor model unknown
After Startup.
Waiting for 3 CPUS to stop
siblings = 03, CPU: family 10, model 04, stepping 02
CPU #1 initialized
Initializing CPU #3
Waiting for 2 CPUS to stop
nodeid = 00, coreid = 02
CPU: vendor AMD device 100f42
Enabling cache
CPU: family 10, model 04, stepping 02

Setting fixed MTRRs(0-88) type: UC
nodeid = 00, coreid = 03
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE fixed MTRRs
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
ADDRESS_MASK_HIGH=0xffff
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
ADDRESS_MASK_HIGH=0xffff
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's
ADDRESS_MASK_HIGH=0xffff
DONE variable MTRRs
Clear out the extra MTRR's
call enable_var_mtrr()
Leave x86_setup_var_mtrrs
call enable_var_mtrr()

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Leave x86_setup_var_mtrrs
Setting up local apic...
MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

 apic_id: 0x02 done.
Setting up local apic...CPU model: AMD Processor model unknown
 apic_id: 0x03 done.
siblings = 03, CPU model: AMD Processor model unknown
CPU #2 initialized
siblings = 03, Waiting for 1 CPUS to stop
CPU #3 initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:00.0 init
pcie_init in rs780_ht.c
PCI: 01:05.0 init
internal_gfx_pci_dev_init device=9615, vendor=1002,
vga_rom_address=0xfff00000.
BTDC: MEMCLK = 0
BTDC: NB HT speed = 1c750b60.
BTDC: CPU HT speed = 8ff50b60.
BTDC: HT width = 11110020.
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1002,9615.rom
In cbfs, rom address for PCI: 01:05.0 = 00000000
On mainboard, rom address for PCI: 01:05.0 = fff00000
PCI Expansion ROM, signature 0x414c, INIT size 0xa400, data ptr 0x6166
Incorrect Expansion ROM Header Signature 414c
PCI: 00:11.0 init
sata_bar0=2020
sata_bar1=2040
sata_bar2=2028
sata_bar3=2044
sata_bar4=2000
sata_bar5=d0309000
SATA port 0 status = 13
drive detection done after 0 ms
Primary Master device is ready after 1 tries
SATA port 1 status = 0
No Primary Slave SATA drive on Slot1
SATA port 2 status = 0
No Secondary Master SATA drive on Slot2
SATA port 3 status = 0
No Secondary Slave SATA drive on Slot3
PCI: 00:12.0 init
PCI: 00:12.1 init
PCI: 00:12.2 init
usb2_bar0=d0309400
PCI: 00:13.0 init
PCI: 00:13.1 init
PCI: 00:13.2 init
usb2_bar0=d0309500
PCI: 00:14.5 init
PCI: 00:14.0 init
sm_init().
lapicid = 0000000000000000
set power on after power fail
++++++++++no set NMI+++++
RTC Init
Invalid CMOS LB checksum
sm_init() end
PCI: 00:14.1 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1002,439c.rom
In cbfs, rom address for PCI: 00:14.1 = 00000000
On mainboard, rom address for PCI: 00:14.1 = 0
PCI: 00:14.2 init
base = d0300000
codec_mask = 08
PCI: 00:14.3 init
PNP: 002e.1 init
PNP: 002e.5 init
Keyboard init...
Keyboard controller output buffer result timeout
Timeout while enabling keyboard. (No keyboard present?)
Keyboard controller output buffer result timeout
Timeout waiting for keyboard after reset.
PCI: 00:14.4 init
PCI: 00:18.1 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1201.rom
In cbfs, rom address for PCI: 00:18.1 = 00000000
On mainboard, rom address for PCI: 00:18.1 = 0
PCI: 00:18.2 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1202.rom
In cbfs, rom address for PCI: 00:18.2 = 00000000
On mainboard, rom address for PCI: 00:18.2 = 0
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:18.4 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1204.rom
In cbfs, rom address for PCI: 00:18.4 = 00000000
On mainboard, rom address for PCI: 00:18.4 = 0
PCI: 04:00.0 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci14e4,167b.rom
In cbfs, rom address for PCI: 04:00.0 = 00000000
On card, rom address for PCI: 04:00.0 = 0
PCI: 05:05.0 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci104c,8025.rom
In cbfs, rom address for PCI: 05:05.0 = 00000000
On card, rom address for PCI: 05:05.0 = 0
Devices initialized
Show all devs...After init.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: 0000: enabled 1, 4 resources
PCI: 00:18.0: enabled 1, 3 resources
PCI: 00:00.0: enabled 1, 1 resources
PCI: 00:01.0: enabled 1, 3 resources
PCI: 01:05.0: enabled 1, 4 resources
PCI: 00:02.0: enabled 0, 0 resources
PCI: 00:03.0: enabled 0, 0 resources
PCI: 00:04.0: enabled 1, 3 resources
PCI: 00:05.0: enabled 0, 0 resources
PCI: 00:06.0: enabled 0, 0 resources
PCI: 00:07.0: enabled 0, 0 resources
PCI: 00:08.0: enabled 0, 0 resources
PCI: 00:09.0: enabled 1, 3 resources
PCI: 00:0a.0: enabled 1, 3 resources
PCI: 00:11.0: enabled 1, 6 resources
PCI: 00:12.0: enabled 1, 1 resources
PCI: 00:12.1: enabled 1, 1 resources
PCI: 00:12.2: enabled 1, 1 resources
PCI: 00:13.0: enabled 1, 1 resources
PCI: 00:13.1: enabled 1, 1 resources
PCI: 00:13.2: enabled 1, 1 resources
PCI: 00:14.5: enabled 1, 1 resources
PCI: 00:14.0: enabled 1, 2 resources
I2C: 01:50: enabled 1, 0 resources
I2C: 01:51: enabled 1, 0 resources
I2C: 01:52: enabled 1, 0 resources
I2C: 01:53: enabled 1, 0 resources
PCI: 00:14.1: enabled 1, 5 resources
PCI: 00:14.2: enabled 1, 1 resources
PCI: 00:14.3: enabled 1, 4 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 1, 2 resources
PNP: 002e.2: enabled 0, 4 resources
PNP: 002e.3: enabled 0, 2 resources
PNP: 002e.4: enabled 0, 0 resources
PNP: 002e.5: enabled 1, 3 resources
PNP: 002e.6: enabled 1, 1 resources
PNP: 002e.7: enabled 0, 0 resources
PNP: 002e.8: enabled 0, 2 resources
PNP: 002e.9: enabled 0, 1 resources
PNP: 002e.a: enabled 0, 0 resources
PCI: 00:14.4: enabled 1, 3 resources
PCI: 00:18.1: enabled 1, 0 resources
PCI: 00:18.2: enabled 1, 0 resources
PCI: 00:18.3: enabled 1, 1 resources
PCI: 00:18.4: enabled 1, 0 resources
APIC: 01: enabled 1, 0 resources
APIC: 02: enabled 1, 0 resources
APIC: 03: enabled 1, 0 resources
PCI: 04:00.0: enabled 1, 1 resources
PCI: 05:05.0: enabled 1, 2 resources
High Tables Base is 3fff0000.
Writing IRQ routing tables to 0xf0000...done.
Writing IRQ routing tables to 0x3fff0000...done.
ACPI: Writing ACPI tables at 3fff0400...
ACPI:    * HPET at 3fff04e8
ACPI: added table 1/40 Length now 40
ACPI:    * MADT at 3fff0520
ACPI: added table 2/40 Length now 44
ACPI:    * SRAT at 3fff0590
SRAT: lapic cpu_index=00, node_id=00, apic_id=00
SRAT: lapic cpu_index=01, node_id=00, apic_id=01
SRAT: lapic cpu_index=02, node_id=00, apic_id=02
SRAT: lapic cpu_index=03, node_id=00, apic_id=03
set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0010 startk=00000000,
sizek=00000280
set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300,
sizek=000ffd00
ACPI: added table 3/40 Length now 48
ACPI:   * SLIT at 3fff0650
ACPI: added table 4/40 Length now 52
ACPI:    * SSDT at 3fff0680
ACPI: added table 5/40 Length now 56
ACPI:    * SSDT for PState at 3fff0cb5
ACPI:    * DSDT at 3fff0cb8
ACPI:    * DSDT @ 3fff0cb8 Length 298b
ACPI:   * FACS at 3fff3648
ACPI:    * FADT at 3fff3688
pm_base: 0x0800
ACPI: added table 6/40 Length now 60
ACPI: done.
Wrote the mp table end at: 000f0440 - 000f057c
Wrote the mp table end at: 3fff3810 - 3fff394c
Moving GDT to 0x3fff3c00...ok
Multiboot Information structure has been written.
Writing high table forward entry at 0x00000500
Wrote coreboot table at: 00000500 - 00000518  checksum 7fdf
New low_table_end: 0x00000518
Now going to write high coreboot table at 0x3fff4000
rom_table_end = 0x3fff4000
Adjust low_table_end from 0x00000518 to 0x00001000
Adjust rom_table_end from 0x3fff4000 to 0x40000000
Adding high table area
uma_memory_start=0x30000000, uma_memory_size=0x0
Wrote coreboot table at: 3fff4000 - 3fff4918  checksum c71b
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
Got a payload
Loading segment from rom address 0xfff00038
  parameter section (skipped)
Loading segment from rom address 0xfff00054
  data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d57c
malloc 0023d57c
  New segment dstaddr 0x100000 memsize 0x1650b0 srcaddr 0xfff000d8
filesize 0x15960
  (cleaned up) New segment addr 0x100000 size 0x1650b0 offset 0xfff000d8
filesize 0x15960
Loading segment from rom address 0xfff00070
  data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d5a0
malloc 0023d5a0
  New segment dstaddr 0x2650b0 memsize 0x48 srcaddr 0xfff15a38 filesize
0x48
  (cleaned up) New segment addr 0x2650b0 size 0x48 offset 0xfff15a38
filesize 0x48
Loading segment from rom address 0xfff0008c
  Entry Point 0x0010008c
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000001650b0
filesz: 0x0000000000015960
lb: [0x0000000000200000, 0x00000000002fc000)
segment: [0x0000000000100000, 0x0000000000115960, 0x00000000002650b0)
malloc Enter, size 36, free_mem_ptr 0023d5c4
malloc 0023d5c4
   early: [0x0000000000100000, 0x0000000000115960, 0x0000000000200000)
 bounce: [0x000000002fe08000, 0x000000002fe08000, 0x000000002fe6d0b0)
Post relocation: addr: 0x000000002fe08000 memsz: 0x00000000000650b0
filesz: 0x0000000000000000
Loading Segment: addr: 0x00000000002650b0 memsz: 0x0000000000000048
filesz: 0x0000000000000048
lb: [0x0000000000200000, 0x00000000002fc000)
segment: [0x00000000002650b0, 0x00000000002650f8, 0x00000000002650f8)
 bounce: [0x000000002fe6d0b0, 0x000000002fe6d0f8, 0x000000002fe6d0f8)
Post relocation: addr: 0x000000002fe6d0b0 memsz: 0x0000000000000048
filesz: 0x0000000000000048
it's not compressed!
[ 0x000000002fe6d0b0, 000000002fe6d0f8, 0x000000002fe6d0f8) <-
00000000fff15a38
Loaded segments
Jumping to boot code at 10008c
entry    = 0x0010008c
lb_start = 0x00200000
lb_size  = 0x000fc000
adjust   = 0x2fc08000
buffer   = 0x2fe08000
     elf_boot_notes = 0x002318d0
adjusted_boot_notes = 0x2fe398d0



INIT detected from  --- {        APICID = 00 NODEID = 00 COREID = 00}
---

Issuing SOFT_RESET...

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Bao, Zheng
Sent: Wednesday, September 16, 2009 10:56 AM
To: Patrick Georgi
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

It was fixed.


Zheng

-----Original Message-----
From: Patrick Georgi [mailto:patrick at georgi-clan.de] 
Sent: Tuesday, September 15, 2009 4:26 PM
To: Bao, Zheng
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng:

> ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
> fallback/payload 
> 
> make: *** [coreboot.rom] Segmentation fault

r4634 fixes segmentation faults when the file cannot be found.
"../payload.elf" is suspicious - are you sure that is the right path?

If you're certain that this file should exist at that place, and if the
segmentation fault still occurs with r4634, some more information is
necessary:
- which payload is this (so I can try to reproduce it, a copy of the
payload binary would help the most)
- is your build machine 32bit or 64bit?


Regards,
Patrick




-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot





From Zheng.Bao at amd.com  Wed Sep 16 07:47:21 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 16 Sep 2009 13:47:21 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com><1253003141.12121.12.camel@tetris><DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17030C7F7B@sbjgexmb1.amd.com>

The whole log is attached.

Zheng

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Bao, Zheng
Sent: Wednesday, September 16, 2009 1:38 PM
To: Patrick Georgi
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

The latest filo crashes if CBFS is enabled.

The CBFS can not work on my Fam10 board for a long time. I have to
disable it all the time.

Can you guys test it?

Zheng

Log:
.........................
PCI: 00:18.4 links 0 child on link 0 NULL
Done allocating resources.
Enabling resources...
PCI: 00:18.0 cmd <- 00
PCI: 00:00.0 subsystem <- 1022/2b80
PCI: 00:00.0 cmd <- 06
PCI: 00:01.0 bridge ctrl <- 000b
PCI: 00:01.0 cmd <- 07
PCI: 01:05.0 subsystem <- 1022/2b80
PCI: 01:05.0 cmd <- 03
PCI: 00:04.0 bridge ctrl <- 0003
PCI: 00:04.0 cmd <- 00
PCI: 00:09.0 bridge ctrl <- 0003
PCI: 00:09.0 cmd <- 00
PCI: 00:0a.0 bridge ctrl <- 0003
PCI: 00:0a.0 cmd <- 06
PCI: 04:00.0 cmd <- 02
PCI: 00:11.0 cmd <- 03
PCI: 00:12.0 subsystem <- 1022/2b80
PCI: 00:12.0 cmd <- 02
PCI: 00:12.1 subsystem <- 1022/2b80
PCI: 00:12.1 cmd <- 02
PCI: 00:12.2 subsystem <- 1022/2b80
PCI: 00:12.2 cmd <- 02
PCI: 00:13.0 subsystem <- 1022/2b80
PCI: 00:13.0 cmd <- 02
PCI: 00:13.1 subsystem <- 1022/2b80
PCI: 00:13.1 cmd <- 02
PCI: 00:13.2 subsystem <- 1022/2b80
PCI: 00:13.2 cmd <- 02
PCI: 00:14.0 subsystem <- 1022/2b80
PCI: 00:14.0 cmd <- 403
PCI: 00:14.1 subsystem <- 1022/2b80
PCI: 00:14.1 cmd <- 01
PCI: 00:14.2 subsystem <- 1022/2b80
PCI: 00:14.2 cmd <- 02
PCI: 00:14.3 subsystem <- 1022/2b80
PCI: 00:14.3 cmd <- 0f
sb700 lpc decode:PNP: 002e.1, base=0x000003f8, end=0x000003ff
sb700 lpc decode:PNP: 002e.5, base=0x00000060, end=0x00000067
sb700 lpc decode:PNP: 002e.5, base=0x00000064, end=0x0000006b
PNP: 002e.6 missing enable_resources
PCI: 00:14.4 bridge ctrl <- 0003
PCI: 00:14.4 cmd <- 07
PCI: 05:05.0 cmd <- 02
PCI: 00:14.5 subsystem <- 1022/2b80
PCI: 00:14.5 cmd <- 02
PCI: 00:18.1 subsystem <- 1022/2b80
PCI: 00:18.1 cmd <- 00
PCI: 00:18.2 subsystem <- 1022/2b80
PCI: 00:18.2 cmd <- 00
PCI: 00:18.3 cmd <- 00
PCI: 00:18.4 subsystem <- 1022/2b80
PCI: 00:18.4 cmd <- 00
done.
Initializing devices...
Root Device init
APIC_CLUSTER: 0 init
start_eip=0x0000e000, offset=0x00200000, code_size=0x0000005b
Initializing CPU #0
CPU: vendor AMD device 100f42
CPU: family 10, model 04, stepping 02
nodeid = 00, coreid = 00
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
ADDRESS_MASK_HIGH=0xffff
DONE variable MTRRs
Clear out the extra MTRR's
call enable_var_mtrr()
Leave x86_setup_var_mtrrs

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Setting up local apic... apic_id: 0x00 done.
CPU model: AMD Processor model unknown
siblings = 03, CPU #0 initialized
Asserting INIT.
Waiting for send to finish...
+Deasserting INIT.
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 1.
After apic_write.
Initializing CPU #1
Startup point 1.
Waiting for send to finish...
+CPU: vendor AMD device 100f42
Sending STARTUP #2 to 1.
After apic_write.
CPU: family 10, model 04, stepping 02
Startup point 1.
Waiting for send to finish...
+nodeid = 00, coreid = 01
After Startup.
Enabling cache
Asserting INIT.

Setting fixed MTRRs(0-88) type: UC
Waiting for send to finish...
+Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Deasserting INIT.
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Waiting for send to finish...
+#startup loops: 2.
Sending STARTUP #1 to 2.
After apic_write.
DONE fixed MTRRs
Startup point 1.
Waiting for send to finish...
+Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
Sending STARTUP #2 to 2.
After apic_write.
ADDRESS_MASK_HIGH=0xffff
Startup point 1.
Waiting for send to finish...
+Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
After Startup.
ADDRESS_MASK_HIGH=0xffff
Asserting INIT.
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
Waiting for send to finish...
+ADDRESS_MASK_HIGH=0xffff
Initializing CPU #2
DONE variable MTRRs
Clear out the extra MTRR's
CPU: vendor AMD device 100f42
Deasserting INIT.
call enable_var_mtrr()
Waiting for send to finish...
+Leave x86_setup_var_mtrrs
#startup loops: 2.
Sending STARTUP #1 to 3.
After apic_write.

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Startup point 1.
Waiting for send to finish...
+Setting up local apic...Sending STARTUP #2 to 3.
After apic_write.
 apic_id: 0x01 done.
Startup point 1.
Waiting for send to finish...
+CPU model: AMD Processor model unknown
After Startup.
Waiting for 3 CPUS to stop
siblings = 03, CPU: family 10, model 04, stepping 02
CPU #1 initialized
Initializing CPU #3
Waiting for 2 CPUS to stop
nodeid = 00, coreid = 02
CPU: vendor AMD device 100f42
Enabling cache
CPU: family 10, model 04, stepping 02

Setting fixed MTRRs(0-88) type: UC
nodeid = 00, coreid = 03
Enabling cache

Setting fixed MTRRs(0-88) type: UC
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Setting fixed MTRRs(0-16) Type: WB, RdMEM, WrMEM
DONE fixed MTRRs
Setting fixed MTRRs(24-88) Type: WB, RdMEM, WrMEM
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
DONE fixed MTRRs
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 0, base:    0MB, range: 1024MB, type WB
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
ADDRESS_MASK_HIGH=0xffff
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 1, base: 1024MB, range:  256MB, type WB
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
ADDRESS_MASK_HIGH=0xffff
ADDRESS_MASK_HIGH=0xffff
Setting variable MTRR 2, base:  768MB, range:  256MB, type UC
DONE variable MTRRs
Clear out the extra MTRR's
ADDRESS_MASK_HIGH=0xffff
DONE variable MTRRs
Clear out the extra MTRR's
call enable_var_mtrr()
Leave x86_setup_var_mtrrs
call enable_var_mtrr()

MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

Leave x86_setup_var_mtrrs
Setting up local apic...
MTRR check
Fixed MTRRs   : Enabled
Variable MTRRs: Enabled

 apic_id: 0x02 done.
Setting up local apic...CPU model: AMD Processor model unknown
 apic_id: 0x03 done.
siblings = 03, CPU model: AMD Processor model unknown
CPU #2 initialized
siblings = 03, Waiting for 1 CPUS to stop
CPU #3 initialized
All AP CPUs stopped
PCI: 00:18.0 init
PCI: 00:00.0 init
pcie_init in rs780_ht.c
PCI: 01:05.0 init
internal_gfx_pci_dev_init device=9615, vendor=1002,
vga_rom_address=0xfff00000.
BTDC: MEMCLK = 0
BTDC: NB HT speed = 1c750b60.
BTDC: CPU HT speed = 8ff50b60.
BTDC: HT width = 11110020.
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1002,9615.rom
In cbfs, rom address for PCI: 01:05.0 = 00000000
On mainboard, rom address for PCI: 01:05.0 = fff00000
PCI Expansion ROM, signature 0x414c, INIT size 0xa400, data ptr 0x6166
Incorrect Expansion ROM Header Signature 414c
PCI: 00:11.0 init
sata_bar0=2020
sata_bar1=2040
sata_bar2=2028
sata_bar3=2044
sata_bar4=2000
sata_bar5=d0309000
SATA port 0 status = 13
drive detection done after 0 ms
Primary Master device is ready after 1 tries
SATA port 1 status = 0
No Primary Slave SATA drive on Slot1
SATA port 2 status = 0
No Secondary Master SATA drive on Slot2
SATA port 3 status = 0
No Secondary Slave SATA drive on Slot3
PCI: 00:12.0 init
PCI: 00:12.1 init
PCI: 00:12.2 init
usb2_bar0=d0309400
PCI: 00:13.0 init
PCI: 00:13.1 init
PCI: 00:13.2 init
usb2_bar0=d0309500
PCI: 00:14.5 init
PCI: 00:14.0 init
sm_init().
lapicid = 0000000000000000
set power on after power fail
++++++++++no set NMI+++++
RTC Init
Invalid CMOS LB checksum
sm_init() end
PCI: 00:14.1 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1002,439c.rom
In cbfs, rom address for PCI: 00:14.1 = 00000000
On mainboard, rom address for PCI: 00:14.1 = 0
PCI: 00:14.2 init
base = d0300000
codec_mask = 08
PCI: 00:14.3 init
PNP: 002e.1 init
PNP: 002e.5 init
Keyboard init...
Keyboard controller output buffer result timeout
Timeout while enabling keyboard. (No keyboard present?)
Keyboard controller output buffer result timeout
Timeout waiting for keyboard after reset.
PCI: 00:14.4 init
PCI: 00:18.1 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1201.rom
In cbfs, rom address for PCI: 00:18.1 = 00000000
On mainboard, rom address for PCI: 00:18.1 = 0
PCI: 00:18.2 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1202.rom
In cbfs, rom address for PCI: 00:18.2 = 00000000
On mainboard, rom address for PCI: 00:18.2 = 0
PCI: 00:18.3 init
NB: Function 3 Misc Control.. done.
PCI: 00:18.4 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci1022,1204.rom
In cbfs, rom address for PCI: 00:18.4 = 00000000
On mainboard, rom address for PCI: 00:18.4 = 0
PCI: 04:00.0 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci14e4,167b.rom
In cbfs, rom address for PCI: 04:00.0 = 00000000
On card, rom address for PCI: 04:00.0 = 0
PCI: 05:05.0 init
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
CBFS: follow chain: fff00000 + 38 + 15a48 + align -> fff15a80
Check fallback/coreboot_ram
CBFS: follow chain: fff15a80 + 38 + 3801c + align -> fff4db00
Check
CBFS: follow chain: fff4db00 + 28 + 314b8 + align -> fff7f000
CBFS:  Could not find file pci104c,8025.rom
In cbfs, rom address for PCI: 05:05.0 = 00000000
On card, rom address for PCI: 05:05.0 = 0
Devices initialized
Show all devs...After init.
Root Device: enabled 1, 0 resources
APIC_CLUSTER: 0: enabled 1, 0 resources
APIC: 00: enabled 1, 0 resources
PCI_DOMAIN: 0000: enabled 1, 4 resources
PCI: 00:18.0: enabled 1, 3 resources
PCI: 00:00.0: enabled 1, 1 resources
PCI: 00:01.0: enabled 1, 3 resources
PCI: 01:05.0: enabled 1, 4 resources
PCI: 00:02.0: enabled 0, 0 resources
PCI: 00:03.0: enabled 0, 0 resources
PCI: 00:04.0: enabled 1, 3 resources
PCI: 00:05.0: enabled 0, 0 resources
PCI: 00:06.0: enabled 0, 0 resources
PCI: 00:07.0: enabled 0, 0 resources
PCI: 00:08.0: enabled 0, 0 resources
PCI: 00:09.0: enabled 1, 3 resources
PCI: 00:0a.0: enabled 1, 3 resources
PCI: 00:11.0: enabled 1, 6 resources
PCI: 00:12.0: enabled 1, 1 resources
PCI: 00:12.1: enabled 1, 1 resources
PCI: 00:12.2: enabled 1, 1 resources
PCI: 00:13.0: enabled 1, 1 resources
PCI: 00:13.1: enabled 1, 1 resources
PCI: 00:13.2: enabled 1, 1 resources
PCI: 00:14.5: enabled 1, 1 resources
PCI: 00:14.0: enabled 1, 2 resources
I2C: 01:50: enabled 1, 0 resources
I2C: 01:51: enabled 1, 0 resources
I2C: 01:52: enabled 1, 0 resources
I2C: 01:53: enabled 1, 0 resources
PCI: 00:14.1: enabled 1, 5 resources
PCI: 00:14.2: enabled 1, 1 resources
PCI: 00:14.3: enabled 1, 4 resources
PNP: 002e.0: enabled 0, 3 resources
PNP: 002e.1: enabled 1, 2 resources
PNP: 002e.2: enabled 0, 4 resources
PNP: 002e.3: enabled 0, 2 resources
PNP: 002e.4: enabled 0, 0 resources
PNP: 002e.5: enabled 1, 3 resources
PNP: 002e.6: enabled 1, 1 resources
PNP: 002e.7: enabled 0, 0 resources
PNP: 002e.8: enabled 0, 2 resources
PNP: 002e.9: enabled 0, 1 resources
PNP: 002e.a: enabled 0, 0 resources
PCI: 00:14.4: enabled 1, 3 resources
PCI: 00:18.1: enabled 1, 0 resources
PCI: 00:18.2: enabled 1, 0 resources
PCI: 00:18.3: enabled 1, 1 resources
PCI: 00:18.4: enabled 1, 0 resources
APIC: 01: enabled 1, 0 resources
APIC: 02: enabled 1, 0 resources
APIC: 03: enabled 1, 0 resources
PCI: 04:00.0: enabled 1, 1 resources
PCI: 05:05.0: enabled 1, 2 resources
High Tables Base is 3fff0000.
Writing IRQ routing tables to 0xf0000...done.
Writing IRQ routing tables to 0x3fff0000...done.
ACPI: Writing ACPI tables at 3fff0400...
ACPI:    * HPET at 3fff04e8
ACPI: added table 1/40 Length now 40
ACPI:    * MADT at 3fff0520
ACPI: added table 2/40 Length now 44
ACPI:    * SRAT at 3fff0590
SRAT: lapic cpu_index=00, node_id=00, apic_id=00
SRAT: lapic cpu_index=01, node_id=00, apic_id=01
SRAT: lapic cpu_index=02, node_id=00, apic_id=02
SRAT: lapic cpu_index=03, node_id=00, apic_id=03
set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0010 startk=00000000,
sizek=00000280
set_srat_mem: dev PCI_DOMAIN: 0000, res->index=0020 startk=00000300,
sizek=000ffd00
ACPI: added table 3/40 Length now 48
ACPI:   * SLIT at 3fff0650
ACPI: added table 4/40 Length now 52
ACPI:    * SSDT at 3fff0680
ACPI: added table 5/40 Length now 56
ACPI:    * SSDT for PState at 3fff0cb5
ACPI:    * DSDT at 3fff0cb8
ACPI:    * DSDT @ 3fff0cb8 Length 298b
ACPI:   * FACS at 3fff3648
ACPI:    * FADT at 3fff3688
pm_base: 0x0800
ACPI: added table 6/40 Length now 60
ACPI: done.
Wrote the mp table end at: 000f0440 - 000f057c
Wrote the mp table end at: 3fff3810 - 3fff394c
Moving GDT to 0x3fff3c00...ok
Multiboot Information structure has been written.
Writing high table forward entry at 0x00000500
Wrote coreboot table at: 00000500 - 00000518  checksum 7fdf
New low_table_end: 0x00000518
Now going to write high coreboot table at 0x3fff4000
rom_table_end = 0x3fff4000
Adjust low_table_end from 0x00000518 to 0x00001000
Adjust rom_table_end from 0x3fff4000 to 0x40000000
Adding high table area
uma_memory_start=0x30000000, uma_memory_size=0x0
Wrote coreboot table at: 3fff4000 - 3fff4918  checksum c71b
Check CBFS header at fff7efe0
magic is 4f524243
Found CBFS header at fff7efe0
Check fallback/payload
Got a payload
Loading segment from rom address 0xfff00038
  parameter section (skipped)
Loading segment from rom address 0xfff00054
  data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d57c
malloc 0023d57c
  New segment dstaddr 0x100000 memsize 0x1650b0 srcaddr 0xfff000d8
filesize 0x15960
  (cleaned up) New segment addr 0x100000 size 0x1650b0 offset 0xfff000d8
filesize 0x15960
Loading segment from rom address 0xfff00070
  data (compression=0)
malloc Enter, size 36, free_mem_ptr 0023d5a0
malloc 0023d5a0
  New segment dstaddr 0x2650b0 memsize 0x48 srcaddr 0xfff15a38 filesize
0x48
  (cleaned up) New segment addr 0x2650b0 size 0x48 offset 0xfff15a38
filesize 0x48
Loading segment from rom address 0xfff0008c
  Entry Point 0x0010008c
Loading Segment: addr: 0x0000000000100000 memsz: 0x00000000001650b0
filesz: 0x0000000000015960
lb: [0x0000000000200000, 0x00000000002fc000)
segment: [0x0000000000100000, 0x0000000000115960, 0x00000000002650b0)
malloc Enter, size 36, free_mem_ptr 0023d5c4
malloc 0023d5c4
   early: [0x0000000000100000, 0x0000000000115960, 0x0000000000200000)
 bounce: [0x000000002fe08000, 0x000000002fe08000, 0x000000002fe6d0b0)
Post relocation: addr: 0x000000002fe08000 memsz: 0x00000000000650b0
filesz: 0x0000000000000000
Loading Segment: addr: 0x00000000002650b0 memsz: 0x0000000000000048
filesz: 0x0000000000000048
lb: [0x0000000000200000, 0x00000000002fc000)
segment: [0x00000000002650b0, 0x00000000002650f8, 0x00000000002650f8)
 bounce: [0x000000002fe6d0b0, 0x000000002fe6d0f8, 0x000000002fe6d0f8)
Post relocation: addr: 0x000000002fe6d0b0 memsz: 0x0000000000000048
filesz: 0x0000000000000048
it's not compressed!
[ 0x000000002fe6d0b0, 000000002fe6d0f8, 0x000000002fe6d0f8) <-
00000000fff15a38
Loaded segments
Jumping to boot code at 10008c
entry    = 0x0010008c
lb_start = 0x00200000
lb_size  = 0x000fc000
adjust   = 0x2fc08000
buffer   = 0x2fe08000
     elf_boot_notes = 0x002318d0
adjusted_boot_notes = 0x2fe398d0



INIT detected from  --- {        APICID = 00 NODEID = 00 COREID = 00}
---

Issuing SOFT_RESET...

-----Original Message-----
From: coreboot-bounces at coreboot.org
[mailto:coreboot-bounces at coreboot.org] On Behalf Of Bao, Zheng
Sent: Wednesday, September 16, 2009 10:56 AM
To: Patrick Georgi
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

It was fixed.


Zheng

-----Original Message-----
From: Patrick Georgi [mailto:patrick at georgi-clan.de] 
Sent: Tuesday, September 15, 2009 4:26 PM
To: Bao, Zheng
Cc: coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

Am Dienstag, den 15.09.2009, 11:00 +0800 schrieb Bao, Zheng:

> ./cbfs/cbfstool ./coreboot.rom add-payload ../payload.elf
> fallback/payload 
> 
> make: *** [coreboot.rom] Segmentation fault

r4634 fixes segmentation faults when the file cannot be found.
"../payload.elf" is suspicious - are you sure that is the right path?

If you're certain that this file should exist at that place, and if the
segmentation fault still occurs with r4634, some more information is
necessary:
- which payload is this (so I can try to reproduce it, a copy of the
payload binary would help the most)
- is your build machine 32bit or 64bit?


Regards,
Patrick




-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot



-- 
coreboot mailing list: coreboot at coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbfs_fail.log
Type: application/octet-stream
Size: 101383 bytes
Desc: cbfs_fail.log
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090916/e6cb5cdb/attachment.obj>

From rminnich at gmail.com  Wed Sep 16 07:52:44 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Sep 2009 22:52:44 -0700
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17030C7F7B@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F7B@sbjgexmb1.amd.com>
Message-ID: <13426df10909152252g77208ecfrc5ee8aed31e01d30@mail.gmail.com>

can you recommend a fam10 board that I could try to get and test on?

ron



From rminnich at gmail.com  Wed Sep 16 07:55:00 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 15 Sep 2009 22:55:00 -0700
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <13426df10909152252g77208ecfrc5ee8aed31e01d30@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F7B@sbjgexmb1.amd.com>
	<13426df10909152252g77208ecfrc5ee8aed31e01d30@mail.gmail.com>
Message-ID: <13426df10909152255i657ed4eel67b53a8c223aa646@mail.gmail.com>

Also, is there any way at all to test this under simnow?

ron



From Zheng.Bao at amd.com  Wed Sep 16 08:34:51 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Wed, 16 Sep 2009 14:34:51 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <13426df10909152252g77208ecfrc5ee8aed31e01d30@mail.gmail.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F7B@sbjgexmb1.amd.com>
	<13426df10909152252g77208ecfrc5ee8aed31e01d30@mail.gmail.com>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17030C7FAB@sbjgexmb1.amd.com>

I use the fam10+RS780+SB7x0. That is why I doubt it is my problem.

Anyone who has the Serengeti_cheetah could try it. If it is ok, I will
check my board and code.

Zheng

-----Original Message-----
From: ron minnich [mailto:rminnich at gmail.com] 
Sent: Wednesday, September 16, 2009 1:53 PM
To: Bao, Zheng
Cc: Patrick Georgi; coreboot at coreboot.org
Subject: Re: [coreboot] r4633 building error of serengeti_cheetah_fam10

can you recommend a fam10 board that I could try to get and test on?

ron





From intorders at cox.net  Wed Sep 16 01:17:34 2009
From: intorders at cox.net (intorders at cox.net)
Date: Tue, 15 Sep 2009 19:17:34 -0400
Subject: [coreboot] supported laptops
Message-ID: <20090915191734.8A2FM.209529.imail@fed1rmwml45>

Hello, I'm very interested on flashing my laptop, even though the chipset/southbridge appear to be supported in version 2, I would really like to know if this can be done, being a laptop, it would be very difficult for me to recover it from a failed flash attempt. Thank You for your help and information. Alan

Step 1: 
I have a laptop Acer Aspire AS5515-5879, It lists a motherboard name of  ?Acer Nile? made by Compal model number KAW60. It originally came with an AMD Athlon 64 2650E that I upgraded to an AMD Athlon 64 X2 5050E. The chipset lists as ATI RS690/RS690M, Southbridge is ATI SB600. It comes with embedded ATI Radeon X1200 graphics. 

STEP 2:
lspci -tvnn output
-[0000:00]-+-00.0  ATI Technologies Inc RS690 Host Bridge [1002:7910] 
           +-01.0-[0000:01]----05.0  ATI Technologies Inc RS690M [Radeon X1200 Series] [1002:791f] 
           +-06.0-[0000:02-04]----00.0  Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter [168c:001c] 
           +-07.0-[0000:05-07]----00.0  Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] 
           +-12.0  ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] 
           +-13.0  ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] 
           +-13.1  ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] 
           +-13.4  ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] 
           +-13.5  ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] 
           +-14.0  ATI Technologies Inc SBx00 SMBus Controller [1002:4385] 
           +-14.1  ATI Technologies Inc SB600 IDE [1002:438c] 
           +-14.2  ATI Technologies Inc SBx00 Azalia (Intel HDA) [1002:4383] 
           +-14.3  ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] 
           +-14.4-[0000:08-0a]-- 
           +-18.0  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 
           +-18.1  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 
           +-18.2  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 
           \-18.3  Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103]

STEP 3:
superiotool -dV does not report any i/o chip

STEP 4:
Unknown type device, flashrom -V  hangs  needing a hard power cycle.

STEP 5:
Unknown

STEP 6:
No further information available.



From xiangy at lemote.com  Wed Sep 16 09:59:57 2009
From: xiangy at lemote.com (=?gb2312?Q?=CF=EE=D3=EE?=)
Date: Wed, 16 Sep 2009 15:59:57 +0800 (CST)
Subject: [coreboot] coreboot Digest, Vol 55, Issue 26
Message-ID: <13991.222.92.8.142.1253087997.squirrel@mail.lemote.com>

hi,
   I am porting coreboot to an amd dbm690t-like platform recently, but the
vga is not work?
   My board have no video memory onboard, i am not sure whether coreboot
support vga output in amd dbm690t board if there is no video memory(use
main memory only),can anyone tell me this?
BTW: I test my vbios in another dbm690t board use coreboot, the vga output
is ok.
   Thanks!




From svn at coreboot.org  Wed Sep 16 10:19:07 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 16 Sep 2009 10:19:07 +0200
Subject: [coreboot] [v2] r4637 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3701.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-16 10:19:07 +0200 (Wed, 16 Sep 2009)
New Revision: 4637

Modified:
   trunk/coreboot-v2/util/cbfstool/Makefile
   trunk/coreboot-v2/util/cbfstool/Makefile.inc
Log:
Build cbfstool with debug flags and don't strip the executable
from any symbol information.

Variant of Ron's patch.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/util/cbfstool/Makefile
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-15 23:38:27 UTC (rev 4636)
+++ trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-16 08:19:07 UTC (rev 4637)
@@ -42,10 +42,9 @@
 tags: 
 	ctags *.[ch]
 
-CXXFLAGS=-DCOMPACT
-CFLAGS=
-LDFLAGS=
+CXXFLAGS=-DCOMPACT -g
+CFLAGS=-g
+LDFLAGS=-g
 
 $(obj)/cbfstool:$(COMMON)
 	$(HOSTCXX) $(LDFLAGS) -o $@ $^
-	strip $@

Modified: trunk/coreboot-v2/util/cbfstool/Makefile.inc
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-15 23:38:27 UTC (rev 4636)
+++ trunk/coreboot-v2/util/cbfstool/Makefile.inc	2009-09-16 08:19:07 UTC (rev 4637)
@@ -16,7 +16,7 @@
 cbfsobj += cbfs-mkpayload.o
 cbfsobj += cbfstool.o
 
-CBFSTOOLFLAGS=-DCOMPACT
+CBFSTOOLFLAGS=-DCOMPACT -g
 
 $(obj)/util/cbfstool:
 	mkdir -p $@




From patrick at georgi-clan.de  Wed Sep 16 10:22:26 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 16 Sep 2009 10:22:26 +0200
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
Message-ID: <1253089346.9771.1.camel@tetris>

Am Mittwoch, den 16.09.2009, 13:37 +0800 schrieb Bao, Zheng:
> The latest filo crashes if CBFS is enabled.
Just to make sure, this is FILO 0.6, the one that uses libpayload?

FILO 0.5 (without libpayload) wasn't tested for a loooong time.

> Can you guys test it?
Could you provide the filo binary (filo.elf) somewhere for testing?


Regards,
Patrick




From coreboot at humilis.net  Wed Sep 16 13:34:34 2009
From: coreboot at humilis.net (Sander)
Date: Wed, 16 Sep 2009 13:34:34 +0200
Subject: [coreboot] Supermicro X7SLA-H supported? (Intel 945GC + ICH7R)
Message-ID: <20090916113434.GA6160@cumulus>

Hello all,

I'm planning on building an adsl2+ server with a Traverse Solos PCI
ADSL2+ card[1] on a Supermicro X7SLA-H motherboard[2].

The chipsets of the X7SLA-H are Intel 945GC + ICH7R which are listed as
WIP on "Devices supported in coreboot v3"[3]

What are the changes of getting Coreboot v3 to work on this motherboard?

What makes v3 'alpha'? I can't seem to figure it out from reading the
wiki.

I consider myself an experienced Linux user but I have no hardware tools
for flash or debug. Would I be able to play with Coreboot and be of any
use to the community?

Btw, I am open for any suggestions regarding a better motherboard with
possible (future) Coreboot support. I'm looking for a small size,
relative low power, two core, 64bit system with a pci slot for the Solos
card. I've read the 'Supported Motherboard' section but it was last
modified at 6 July 2009 so that might be outdated.

	Sander


[1] http://www.traverse.com.au/productview.php?product_id=116
[2] http://www.supermicro.com/products/motherboard/ATOM/945/X7SLA.cfm
[3] http://www.coreboot.org/Supported_Chipsets_and_Devices

-- 
Humilis IT Services and Solutions
http://www.humilis.net



From coreboot at humilis.net  Wed Sep 16 13:34:34 2009
From: coreboot at humilis.net (Sander)
Date: Wed, 16 Sep 2009 13:34:34 +0200
Subject: [coreboot] Supermicro X7SLA-H supported? (Intel 945GC + ICH7R)
Message-ID: <20090916113434.GA6160@cumulus>

Hello all,

I'm planning on building an adsl2+ server with a Traverse Solos PCI
ADSL2+ card[1] on a Supermicro X7SLA-H motherboard[2].

The chipsets of the X7SLA-H are Intel 945GC + ICH7R which are listed as
WIP on "Devices supported in coreboot v3"[3]

What are the changes of getting Coreboot v3 to work on this motherboard?

What makes v3 'alpha'? I can't seem to figure it out from reading the
wiki.

I consider myself an experienced Linux user but I have no hardware tools
for flash or debug. Would I be able to play with Coreboot and be of any
use to the community?

Btw, I am open for any suggestions regarding a better motherboard with
possible (future) Coreboot support. I'm looking for a small size,
relative low power, two core, 64bit system with a pci slot for the Solos
card. I've read the 'Supported Motherboard' section but it was last
modified at 6 July 2009 so that might be outdated.

	Sander


[1] http://www.traverse.com.au/productview.php?product_id=116
[2] http://www.supermicro.com/products/motherboard/ATOM/945/X7SLA.cfm
[3] http://www.coreboot.org/Supported_Chipsets_and_Devices

-- 
Humilis IT Services and Solutions
http://www.humilis.net



From uwe at hermann-uwe.de  Wed Sep 16 15:22:37 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Wed, 16 Sep 2009 15:22:37 +0200
Subject: [coreboot] Kconfig status
In-Reply-To: <20090910140412.GT7448@greenwood>
References: <4AA40F30.9080608@coresystems.de> <4AA8A6FE.7010803@coresystems.de>
	<20090910140412.GT7448@greenwood>
Message-ID: <20090916132237.GA1314@greenwood>

On Thu, Sep 10, 2009 at 04:04:12PM +0200, Uwe Hermann wrote:
> On Thu, Sep 10, 2009 at 09:13:02AM +0200, Stefan Reinauer wrote:
> > Stefan Reinauer wrote:
> > > Hi developers!
> > >
> > > I started creating a Kconfig status page in the Wiki at
> > >
> > > http://www.coreboot.org/Kconfig
> > >
> > > Currently all boards in there are marked "Unsupported". If you worked on
> > > a Kconfig port of a board, please change the status on that page, so we
> > > can see what's still missing. Please also use the Status/ Comments field
> > > to mention issues or hints.
> > >
> > > Thanks a lot,
> > >
> > > Stefan
> > >
> > >   
> > Any takers?
> 
> Yep, I'll have a look and update the table soonish.o

Done. This should be the current status AFAIK, please update as
required.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From peter at stuge.se  Wed Sep 16 21:17:11 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 Sep 2009 21:17:11 +0200
Subject: [coreboot] supported laptops
In-Reply-To: <20090915191734.8A2FM.209529.imail@fed1rmwml45>
References: <20090915191734.8A2FM.209529.imail@fed1rmwml45>
Message-ID: <20090916191711.8191.qmail@stuge.se>

Hi Alan,

intorders at cox.net wrote:
> Hello, I'm very interested on flashing my laptop,
..

> The chipset lists as ATI RS690/RS690M, Southbridge is ATI SB600.

This combination is supported by coreboot. There is a lot of code and
it works well on at least a couple of boards.

..

> STEP 3:
> superiotool -dV does not report any i/o chip
> 
> STEP 4:
> Unknown type device, flashrom -V  hangs  needing a hard power cycle.
> 
> STEP 5:
> Unknown
> 
> STEP 6:
> No further information available.

Now, the lack of information here suggests that you have some work to
do, to create a development environment for this system.

And yes, you will need to find a way to recover from images that
don't work. Presumably this has an SPI flash chip. You could go for
an SPI flash emulator, some developers are using the Dediprog SF-100
with success. You would de-solder the current flash chip, and solder
wires to the SF-100 instead.

So, the laptop could possibly be made to work with coreboot, but it
is nowhere near as simple as just flashing a new firmware. You will
need to dig in and do some development.

You could run into catastrophic trouble with the EC, but it could
also be simple to deal with. You would have to try, to know.


//Peter



From peter at stuge.se  Wed Sep 16 21:28:20 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 Sep 2009 21:28:20 +0200
Subject: [coreboot] patch: disable IPMI on the dell s1850
In-Reply-To: <13426df10909152236r3df6ff86g29810b5aa2ad4cff@mail.gmail.com>
References: <13426df10909152236r3df6ff86g29810b5aa2ad4cff@mail.gmail.com>
Message-ID: <20090916192820.14035.qmail@stuge.se>

ron minnich wrote:
> attached.

This looks great - but if it applies in general for all BMCs then
maybe it should be outside the dell/s1850 directory?

Otherwise fine;

Acked-by: Peter Stuge <peter at stuge.se>



From rminnich at gmail.com  Wed Sep 16 21:53:04 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 16 Sep 2009 12:53:04 -0700
Subject: [coreboot] patch: disable IPMI on the dell s1850
In-Reply-To: <20090916192820.14035.qmail@stuge.se>
References: <13426df10909152236r3df6ff86g29810b5aa2ad4cff@mail.gmail.com>
	<20090916192820.14035.qmail@stuge.se>
Message-ID: <13426df10909161253o7e27946w8c0e985ff34d353f@mail.gmail.com>

On Wed, Sep 16, 2009 at 12:28 PM, Peter Stuge <peter at stuge.se> wrote:
> ron minnich wrote:
>> attached.
>
> This looks great - but if it applies in general for all BMCs then
> maybe it should be outside the dell/s1850 directory?

Not yet. We need to do a lot more testing. This code is very specific
to the 1850 for now.

I agree with you in principal however!

thanks

ron



From patrick at georgi-clan.de  Wed Sep 16 22:07:54 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 16 Sep 2009 22:07:54 +0200
Subject: [coreboot] kbuildall utility
Message-ID: <1253131675.17115.4.camel@tetris>

Hi,

attached file is a utility that generates default configs for all
boards, builds them, and keeps the config and build logs around and
creates a roster of all boards and their build status.

abuild does this for the newconfig based buildsystem, kbuildall does
this for kconfig/kbuild.

It's supposed to be put in the tree as util/kbuildall/kbuildall, and
called like that (ie. from the top level directory).

The results can be found in kbuildall.results/ in the toplevel
directory, the roster is called _overview.txt ("_" to make sure it's
sorted before or after all the board files)


Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kbuildall
Type: application/x-shellscript
Size: 1827 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090916/551aa7d7/attachment.sh>

From stepan at coresystems.de  Wed Sep 16 22:12:44 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 16 Sep 2009 22:12:44 +0200
Subject: [coreboot] kbuildall utility
In-Reply-To: <1253131675.17115.4.camel@tetris>
References: <1253131675.17115.4.camel@tetris>
Message-ID: <4AB146BC.40400@coresystems.de>

Patrick Georgi wrote:
> Hi,
>
> attached file is a utility that generates default configs for all
> boards, builds them, and keeps the config and build logs around and
> creates a roster of all boards and their build status.
>
> abuild does this for the newconfig based buildsystem, kbuildall does
> this for kconfig/kbuild.
>
> It's supposed to be put in the tree as util/kbuildall/kbuildall, and
> called like that (ie. from the top level directory).
>
> The results can be found in kbuildall.results/ in the toplevel
> directory, the roster is called _overview.txt ("_" to make sure it's
> sorted before or after all the board files)
>
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   

Awesome!

Acked-by: Stefan Reinauer <stepan at coresystems.de>



From svn at coreboot.org  Wed Sep 16 22:18:03 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 16 Sep 2009 22:18:03 +0200
Subject: [coreboot] [v2] r4638 - in trunk/coreboot-v2/util: . kbuildall
Message-ID: <mailman.3702.1355071618.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-16 22:18:03 +0200 (Wed, 16 Sep 2009)
New Revision: 4638

Added:
   trunk/coreboot-v2/util/kbuildall/
   trunk/coreboot-v2/util/kbuildall/kbuildall
Log:
kbuildall is a utility that generates default configs for all
boards, builds them, and keeps the config and build logs around and
creates a roster of all boards and their build status.

abuild does this for the newconfig based buildsystem, kbuildall does
this for kconfig/kbuild.

It's supposed to be put in the tree as util/kbuildall/kbuildall, and
called like that (ie. from the top level directory).

The results can be found in kbuildall.results/ in the toplevel
directory, the roster is called _overview.txt ("_" to make sure it's
sorted before or after all the board files)

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Added: trunk/coreboot-v2/util/kbuildall/kbuildall
===================================================================
--- trunk/coreboot-v2/util/kbuildall/kbuildall	                        (rev 0)
+++ trunk/coreboot-v2/util/kbuildall/kbuildall	2009-09-16 20:18:03 UTC (rev 4638)
@@ -0,0 +1,57 @@
+#!/bin/sh
+#
+#  coreboot autobuilder for kconfig
+#
+#  This script builds coreboot images for all available targets.
+#
+#  (C) 2009 coresystems GmbH 
+#      written by Patrick Georgi <patrick.georgi at coresystems.de>
+#
+#  This file is subject to the terms and conditions of the GNU General
+#  Public License, version 2. See the file COPYING in the main directory
+#  of this archive for more details.
+
+TARGETDIR=kbuildall.results
+
+if [ ! -f util/kbuildall/kbuildall ]; then
+	echo "This application must be run from the"
+	echo "toplevel directory of a coreboot checkout."
+	exit 1
+fi
+
+for make in make gmake gnumake; do
+	if [ "`$make --version 2>/dev/null | grep -c GNU`" -gt 0 ]; then
+		MAKE=$make
+		break
+	fi
+done
+
+builddefconfig() {
+# $1: mainboarddir
+	$MAKE distclean
+	grep "depends[\t ]on[\t ]*VENDOR" src/mainboard/$1/../Kconfig | sed "s,^.*\(VENDOR_.*\)[^A-Z0-9_]*,CONFIG_\1=y," > .config
+	grep "config[\t ]*BOARD" src/mainboard/$1/Kconfig | sed "s,^.*\(BOARD_.*\)[^A-Z0-9_]*,CONFIG_\1=y," >> .config
+	grep "select[\t ]*ARCH" src/mainboard/$1/Kconfig | sed "s,^.*\(ARCH_.*\)[^A-Z0-9_]*,CONFIG_\1=y," >> .config
+	echo "CONFIG_MAINBOARD_DIR=$1" >> .config
+	yes "" | $MAKE oldconfig
+}
+
+rm -rf $TARGETDIR
+mkdir -p $TARGETDIR
+ALLTARGETS=`(cd src/mainboard; ls */*/Config.lb | sed s,/Config.lb,,)`
+TARGETCOUNT=`echo $ALLTARGETS | wc -w`
+CURRENTARGET=0
+for dir in $ALLTARGETS; do
+	i=`expr $i + 1`
+	if [ ! -f src/mainboard/$dir/Kconfig ]; then
+		echo "[$i/$TARGETCOUNT] ($dir) no Kconfig"
+		echo "$dir nokconfig" >> $TARGETDIR/_overview.txt
+		continue
+	fi
+	name=`echo $dir | sed s,/,_,g`
+	printf "[$i/$TARGETCOUNT] $dir "
+	builddefconfig $dir > $TARGETDIR/$name.buildconfig.log 2>&1
+	result=`$MAKE > $TARGETDIR/$name.buildcoreboot.log 2>&1 && echo ok || echo fail`
+	echo "$result."
+	echo "$dir $result" >> $TARGETDIR/_overview.txt
+done


Property changes on: trunk/coreboot-v2/util/kbuildall/kbuildall
___________________________________________________________________
Added: svn:executable
   + *




From c-d.hailfinger.devel.2006 at gmx.net  Wed Sep 16 22:39:19 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 16 Sep 2009 22:39:19 +0200
Subject: [coreboot] kbuildall utility
In-Reply-To: <1253131675.17115.4.camel@tetris>
References: <1253131675.17115.4.camel@tetris>
Message-ID: <4AB14CF7.3020601@gmx.net>

On 16.09.2009 22:07, Patrick Georgi wrote:
> attached file is a utility that generates default configs for all
> boards, builds them, and keeps the config and build logs around and
> creates a roster of all boards and their build status.
>
> abuild does this for the newconfig based buildsystem, kbuildall does
> this for kconfig/kbuild.
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>   

Very impressive! This would have been a great help for v3, and I'm
confident it will push v2 testing forward as well.
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From joe at settoplinux.org  Wed Sep 16 23:14:40 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Sep 2009 17:14:40 -0400
Subject: [coreboot] #16: I2C driver and mainboard Config.lb
In-Reply-To: <051.652e111e2a1a01725a1cc8a718ae1b0a@coreboot.org>
References: <042.195f4ef97c45fba21898f9914a491509@coreboot.org>
	<051.652e111e2a1a01725a1cc8a718ae1b0a@coreboot.org>
Message-ID: <01dcff7dfa14353a408e9916cf600c1a@imap.1and1.com>




On Mon, 14 Sep 2009 16:12:50 -0000, "coreboot" <svn at coreboot.org> wrote:
> #16: I2C driver and mainboard Config.lb
>
----------------------+-----------------------------------------------------
>  Reporter:  stepan    |          Owner:  ollie
>      Type:  defect    |         Status:  new
>  Priority:  minor     |      Milestone:
> Component:  coreboot  |        Version:  v2
>  Keywords:            |   Dependencies:
>
----------------------+-----------------------------------------------------
> 
> Comment(by JohnMlkolkzzbvvfa):
> 
What kind of i2c driver are we looking for? Generic bit banger?

I have one in progress for Intel northbrides that could be adapted into a
generic bit banger, it is pretty simple.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Sep 16 23:33:04 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Sep 2009 17:33:04 -0400
Subject: [coreboot] Embedded Systems Event Boston, MA
Message-ID: <746c825f5fe35664d61892d70393634f@imap.1and1.com>


http://esc-boston.techinsightsevents.com/

Too bad I didn't see this sooner, I would have loved to show off coreboot
on the Kontron 986LCD-M/mITX seeing how Kontron is going to be there. Maybe
next time.

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From joe at settoplinux.org  Wed Sep 16 23:42:35 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Wed, 16 Sep 2009 17:42:35 -0400
Subject: [coreboot] #16: I2C driver and mainboard Config.lb
In-Reply-To: <01dcff7dfa14353a408e9916cf600c1a@imap.1and1.com>
References: <042.195f4ef97c45fba21898f9914a491509@coreboot.org>
	<051.652e111e2a1a01725a1cc8a718ae1b0a@coreboot.org>
	<01dcff7dfa14353a408e9916cf600c1a@imap.1and1.com>
Message-ID: <5ced64ba0f6e3dfc69f592007f924caa@imap.1and1.com>




On Wed, 16 Sep 2009 17:14:40 -0400, Joseph Smith <joe at settoplinux.org>
wrote:
> 
> 
> 
> On Mon, 14 Sep 2009 16:12:50 -0000, "coreboot" <svn at coreboot.org> wrote:
>> #16: I2C driver and mainboard Config.lb
>>
>
----------------------+-----------------------------------------------------
>>  Reporter:  stepan    |          Owner:  ollie
>>      Type:  defect    |         Status:  new
>>  Priority:  minor     |      Milestone:
>> Component:  coreboot  |        Version:  v2
>>  Keywords:            |   Dependencies:
>>
>
----------------------+-----------------------------------------------------
>>
>> Comment(by JohnMlkolkzzbvvfa):
>>
> What kind of i2c driver are we looking for? Generic bit banger?
> 
> I have one in progress for Intel northbrides that could be adapted into a
> generic bit banger, it is pretty simple.
> 
It is actually fairly close to some of the SuperIO bit banging routines we
do....

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From peter at stuge.se  Wed Sep 16 23:44:11 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 Sep 2009 23:44:11 +0200
Subject: [coreboot] Embedded Systems Event Boston, MA
In-Reply-To: <746c825f5fe35664d61892d70393634f@imap.1and1.com>
References: <746c825f5fe35664d61892d70393634f@imap.1and1.com>
Message-ID: <20090916214411.5520.qmail@stuge.se>

Joseph Smith wrote:
> Too bad I didn't see this sooner, I would have loved to show off
> coreboot on the Kontron 986LCD-M/mITX seeing how Kontron is going
> to be there. Maybe next time.

Still a few days.. I find it useful to go even as a visitor and just
talk to everyone about coreboot. There are usually more than one pair
of raised eyebrows. :)


//Peter



From rminnich at gmail.com  Thu Sep 17 02:08:37 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 16 Sep 2009 17:08:37 -0700
Subject: [coreboot] new cbfstool has an allocation bug of some sort
Message-ID: <13426df10909161708j43211594h82834f0af339021@mail.gmail.com>

There is unquestionably a bug in the allocation in int
parse_elf_to_payload that is resulting in a trashed malloc arena.

I'm not quite sure I understand it yet but this happens: I have a filo
payload which has 47516 bytes of data in two segments. The code
parse_elf_to_payload computes the amount of memory to allocate and
computes 47628. But the code then goes on to overwrite 47676 bytes of
data. There is some simple calculation going wrong, starting me in the
face ... I don't see it yet, but one of you might.

The result is this:

*** glibc detected *** ./cbfs/cbfstool: malloc: top chunk is corrupt:
0x0000000000d4fd60 ***

I have fixed this for now: I allocate 1048576 more bytes then needed :-)

ron



From rminnich at gmail.com  Thu Sep 17 02:22:03 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 16 Sep 2009 17:22:03 -0700
Subject: [coreboot] patch: fix cbfstool malloc arena corruption
Message-ID: <13426df10909161722pca23abep2c3d781df1f0d8f6@mail.gmail.com>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbfstoolfix.diff
Type: text/x-patch
Size: 1263 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090916/e97717a1/attachment.diff>

From svn at coreboot.org  Thu Sep 17 02:24:52 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 02:24:52 +0200
Subject: [coreboot] [v2] r4639 - trunk/coreboot-v2/src/mainboard/dell/s1850
Message-ID: <mailman.3703.1355071618.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2009-09-17 02:24:52 +0200 (Thu, 17 Sep 2009)
New Revision: 4639

Modified:
   trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c
Log:
copyright name error. 
I don't know what else to do for files generated by programs ...
Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c	2009-09-16 20:18:03 UTC (rev 4638)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/irq_tables.c	2009-09-17 00:24:52 UTC (rev 4639)
@@ -1,8 +1,8 @@
 /*
  * This file is part of the coreboot project.
  *
- * Copyright (C) 2008 VIA Technologies, Inc.
- * (Written by Aaron Lwe <aaron.lwe at gmail.com> for VIA)
+ * Copyright (C) by the coreboot pirq tool. 
+ * This file was programatically generated. 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by




From svn at coreboot.org  Thu Sep 17 02:28:29 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 02:28:29 +0200
Subject: [coreboot] [v2] r4640 - trunk/coreboot-v2/src/mainboard/dell/s1850
Message-ID: <mailman.3704.1355071618.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2009-09-17 02:28:29 +0200 (Thu, 17 Sep 2009)
New Revision: 4640

Modified:
   trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
Log:
This is a patch for killing IPMI on the s1850 -- or at least geting the BMC
out of the way of the serial port. Tested extensively in user mode.
Works and gets the BMC out of my way, which is good, because there
are few more useless things than IPMI and the BMC.
The BMC, all by itself, is the cause of most of our problems in booting
and talking to these nodes. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>




Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-17 00:24:52 UTC (rev 4639)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-17 00:28:29 UTC (rev 4640)
@@ -74,6 +74,107 @@
 #include "sdram/generic_sdram.c"
 
 
+/* IPMI garbage. This is all test stuff, if it really works we'll move it somewhere
+ */
+
+#define nftransport  0xc
+
+#define OBF  0
+#define IBF 1
+
+#define ipmidata  0xca0
+#define ipmicsr  0xca4
+
+
+static inline void  ibfzero(void)
+{
+	while(inb(ipmicsr) &  (1<<IBF)) 
+		;
+}
+static inline void  clearobf(void)
+{
+	(void) inb(ipmidata);
+}
+
+static inline void  waitobf(void)
+{
+	while((inb(ipmicsr) &  (1<<OBF)) == 0) 
+		;
+}
+/* quite possibly the stupidest interface ever designed. */
+static inline void  first_cmd_byte(unsigned char byte)
+{
+	ibfzero();
+	clearobf();
+	outb(0x61, ipmicsr);
+	ibfzero();
+	clearobf();
+	outb(byte, ipmidata);
+}
+
+static inline void  next_cmd_byte(unsigned char byte)
+{
+
+	ibfzero();
+	clearobf();
+	outb(byte, ipmidata);
+}
+
+static inline void  last_cmd_byte(unsigned char byte)
+{
+	outb(0x62, ipmicsr);
+
+	ibfzero();
+	clearobf();
+	outb(byte,  ipmidata);
+}
+
+static inline void read_response_byte(void)
+{
+	int val = -1;
+	if ((inb(ipmicsr)>>6) != 1)
+		return;
+
+	ibfzero();
+	waitobf();
+	val = inb(ipmidata);
+	outb(0x68, ipmidata);
+
+	/* see if it is done */
+	if ((inb(ipmicsr)>>6) != 1){
+		/* wait for the dummy read. Which describes this protocol */
+		waitobf();
+		(void)inb(ipmidata);
+	}
+}
+
+static inline void ipmidelay(void)
+{
+	int i;
+	for(i = 0; i < 1000; i++) {
+		inb(0x80);
+	}
+}
+
+static inline void bmc_foad(void)
+{
+	unsigned char c;
+	/* be safe; make sure it is really ready */
+	while ((inb(ipmicsr)>>6)) {
+		outb(0x60, ipmicsr);
+		inb(ipmidata);
+	}
+	first_cmd_byte(nftransport << 2);
+	ipmidelay();
+	next_cmd_byte(0x12);
+	ipmidelay();
+	next_cmd_byte(2);
+	ipmidelay();
+	last_cmd_byte(3);
+	ipmidelay();
+}
+
+/* end IPMI garbage */
 static void main(unsigned long bist)
 {
 	/*
@@ -100,6 +201,7 @@
 		}
 	}
 	/* Setup the console */
+	bmc_foad();
 	outb(0x87,0x2e);
 	outb(0x87,0x2e);
 	pnp_write_config(CONSOLE_SERIAL_DEV, 0x24, 0x84 | (1 << 6));




From Zheng.Bao at amd.com  Thu Sep 17 04:21:37 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Thu, 17 Sep 2009 10:21:37 +0800
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <1253089346.9771.1.camel@tetris>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
	<1253089346.9771.1.camel@tetris>
Message-ID: <DD1CC71B621B004FA76856E5129D6B17030C8147@sbjgexmb1.amd.com>

It is Filo 0.6 with libpayload.

The attached file is the binary.

With Ron's patch "fix cbfstool malloc arena corruption", the SOFT_RESET
is still there.

Zheng

-----Original Message-----
From: Patrick Georgi [mailto:patrick at georgi-clan.de] 
Sent: Wednesday, September 16, 2009 4:22 PM
To: Bao, Zheng
Cc: coreboot at coreboot.org
Subject: RE: [coreboot] r4633 building error of serengeti_cheetah_fam10

Am Mittwoch, den 16.09.2009, 13:37 +0800 schrieb Bao, Zheng:
> The latest filo crashes if CBFS is enabled.
Just to make sure, this is FILO 0.6, the one that uses libpayload?

FILO 0.5 (without libpayload) wasn't tested for a loooong time.

> Can you guys test it?
Could you provide the filo binary (filo.elf) somewhere for testing?


Regards,
Patrick


-------------- next part --------------
A non-text attachment was scrubbed...
Name: filo.elf
Type: application/octet-stream
Size: 89232 bytes
Desc: filo.elf
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/bdf12ff3/attachment.obj>

From peter at stuge.se  Thu Sep 17 08:35:02 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 08:35:02 +0200
Subject: [coreboot] patch: fix cbfstool malloc arena corruption
In-Reply-To: <13426df10909161722pca23abep2c3d781df1f0d8f6@mail.gmail.com>
References: <13426df10909161722pca23abep2c3d781df1f0d8f6@mail.gmail.com>
Message-ID: <20090917063502.29705.qmail@stuge.se>

ron minnich wrote:
> There was a missing addition of the size of the .notes.pinfo 
> section header which could lead to corrupted malloc arena. 
> 
> Also, make cbfstool always build with debugging on. Performance
> is not an issue here. Don't strip it either. 
> 
> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From peter at stuge.se  Thu Sep 17 08:40:39 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 08:40:39 +0200
Subject: [coreboot] Move VGA BIOS settings from payload menu into a menu of
	it's own
Message-ID: <20090917064039.30879.qmail@stuge.se>

Patch attached.


//Peter
-------------- next part --------------
Move VGA BIOS settings from payload menu into a menu of it's own.

Depending on PAYLOAD_ELF also stopped the config items from being shown.
Build tested, with this coreboot.rom correctly includes the VGA BIOS.

Signed-off-by: Peter Stuge <peter at stuge.se>

Index: src/Kconfig
===================================================================
--- src/Kconfig	(revision 4640)
+++ src/Kconfig	(working copy)
@@ -238,17 +238,6 @@
 
 	  You will be able to specify the location and file name of the
 	  payload image later.
-
-config VGA_BIOS
-	bool "Add a VGA BIOS image"
-	depends on PAYLOAD_ELF
-	help
-	  Select this option if you have a VGA BIOS image that you would
-	  like to add to your ROM.
-
-	  You will be able to specify the location and file name of the
-	  image later.
-
 config PAYLOAD_NONE
 	bool "No payload"
 	help
@@ -268,6 +257,30 @@
 	help
 	  The path and filename of the ELF executable file to use as payload.
 
+endmenu
+
+menu "VGA BIOS"
+
+choice
+	prompt "VGA BIOS"
+	default VGA_NONE
+
+config VGA_NONE
+	bool "None"
+	help
+	  Select this option if you don't want to include a VGA BIOS in
+	  the coreboot image.
+config VGA_BIOS
+	bool "Add a VGA BIOS image"
+	depends on PAYLOAD_ELF
+	help
+	  Select this option if you have a VGA BIOS image that you would
+	  like to add to your ROM.
+
+	  You will be able to specify the location and file name of the
+	  image later.
+endchoice
+
 config FALLBACK_VGA_BIOS_FILE
 	string "VGA BIOS path and filename"
 	depends on VGA_BIOS

From peter at stuge.se  Thu Sep 17 10:02:12 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 10:02:12 +0200
Subject: [coreboot] Move VGA BIOS settings from payload menu into a	menu
	of it's own
In-Reply-To: <20090917064039.30879.qmail@stuge.se>
References: <20090917064039.30879.qmail@stuge.se>
Message-ID: <20090917080212.12049.qmail@stuge.se>

Peter Stuge wrote:
> Patch attached.

Revised patch attached. This time actually remove the dependency on
PAYLOAD_ELF. Oops.


//Peter
-------------- next part --------------
Move VGA BIOS settings from payload menu into it's own menu

Remove dependency on PAYLOAD_ELF to actually show these config items.
Build tested. With this, coreboot.rom has a VGA BIOS optionrom added.

Signed-off-by: Peter Stuge <peter at stuge.se>

Index: src/Kconfig
===================================================================
--- src/Kconfig	(revision 4640)
+++ src/Kconfig	(working copy)
@@ -238,17 +238,6 @@
 
 	  You will be able to specify the location and file name of the
 	  payload image later.
-
-config VGA_BIOS
-	bool "Add a VGA BIOS image"
-	depends on PAYLOAD_ELF
-	help
-	  Select this option if you have a VGA BIOS image that you would
-	  like to add to your ROM.
-
-	  You will be able to specify the location and file name of the
-	  image later.
-
 config PAYLOAD_NONE
 	bool "No payload"
 	help
@@ -268,6 +257,19 @@
 	help
 	  The path and filename of the ELF executable file to use as payload.
 
+endmenu
+
+menu "VGA BIOS"
+
+config VGA_BIOS
+	bool "Add a VGA BIOS image"
+	help
+	  Select this option if you have a VGA BIOS image that you would
+	  like to add to your ROM.
+
+	  You will be able to specify the location and file name of the
+	  image later.
+
 config FALLBACK_VGA_BIOS_FILE
 	string "VGA BIOS path and filename"
 	depends on VGA_BIOS

From patrick.georgi at coresystems.de  Thu Sep 17 16:54:10 2009
From: patrick.georgi at coresystems.de (Patrick Georgi)
Date: Thu, 17 Sep 2009 16:54:10 +0200
Subject: [coreboot] Move VGA BIOS settings from payload menu into a	menu
	of it's own
In-Reply-To: <20090917080212.12049.qmail@stuge.se>
References: <20090917064039.30879.qmail@stuge.se>
	<20090917080212.12049.qmail@stuge.se>
Message-ID: <1253199250.29976.23.camel@tetris>

Am Donnerstag, den 17.09.2009, 10:02 +0200 schrieb Peter Stuge:
> Peter Stuge wrote:
> > Patch attached.
> 
> Revised patch attached. This time actually remove the dependency on
> PAYLOAD_ELF. Oops.
Thanks,

Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Patrick




From svn at coreboot.org  Thu Sep 17 17:35:09 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 17:35:09 +0200
Subject: [coreboot] [v2] r4641 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3705.1355071618.16123.coreboot@coreboot.org>

Author: rminnich
Date: 2009-09-17 17:35:08 +0200 (Thu, 17 Sep 2009)
New Revision: 4641

Modified:
   trunk/coreboot-v2/util/cbfstool/Makefile
   trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c
Log:
There was a missing addition of the size of the .notes.pinfo 
section header which could lead to corrupted malloc arena. 

Also, make cbfstool always build with debugging on. Performance
is not an issue here. Don't strip it either. 

Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/util/cbfstool/Makefile
===================================================================
--- trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-17 00:28:29 UTC (rev 4640)
+++ trunk/coreboot-v2/util/cbfstool/Makefile	2009-09-17 15:35:08 UTC (rev 4641)
@@ -2,7 +2,9 @@
 
 HOSTCXX ?= g++
 HOSTCC ?= gcc
+CFLAGS ?= -g
 
+
 BINARY:=$(obj)/cbfstool
 
 COMMON:=common.o compress.o minilzma.o

Modified: trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c	2009-09-17 00:28:29 UTC (rev 4640)
+++ trunk/coreboot-v2/util/cbfstool/cbfs-mkpayload.c	2009-09-17 15:35:08 UTC (rev 4641)
@@ -75,8 +75,10 @@
 
 		name = (char *)(strtab + shdr[i].sh_name);
 
-		if (!strcmp(name, ".note.pinfo"))
+		if (!strcmp(name, ".note.pinfo")) {
 			segments++;
+			isize += (unsigned int)shdr[i].sh_size;
+		}
 	}
 
 	/* Now, regular headers - we only care about PT_LOAD headers,




From rminnich at gmail.com  Thu Sep 17 17:35:50 2009
From: rminnich at gmail.com (ron minnich)
Date: Thu, 17 Sep 2009 08:35:50 -0700
Subject: [coreboot] patch: fix cbfstool malloc arena corruption
In-Reply-To: <20090917063502.29705.qmail@stuge.se>
References: <13426df10909161722pca23abep2c3d781df1f0d8f6@mail.gmail.com>
	<20090917063502.29705.qmail@stuge.se>
Message-ID: <13426df10909170835v65f12836s85aa2c52c05d423e@mail.gmail.com>

On Wed, Sep 16, 2009 at 11:35 PM, Peter Stuge <peter at stuge.se> wrote:
> ron minnich wrote:
>> There was a missing addition of the size of the .notes.pinfo
>> section header which could lead to corrupted malloc arena.
>>
>> Also, make cbfstool always build with debugging on. Performance
>> is not an issue here. Don't strip it either.
>>
>> Signed-off-by: Ronald G. Minnich <rminnich at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se>

Thanks! This may fix other SEGV reports.

Committed revision 4641.



From patrick at georgi-clan.de  Thu Sep 17 17:53:23 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 17 Sep 2009 17:53:23 +0200
Subject: [coreboot] r4633 building error of serengeti_cheetah_fam10
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B17030C8147@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B17030729DE@sbjgexmb1.amd.com>
	<1253003141.12121.12.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B1703072CAD@sbjgexmb1.amd.com>
	<DD1CC71B621B004FA76856E5129D6B17030C7F71@sbjgexmb1.amd.com>
	<1253089346.9771.1.camel@tetris>
	<DD1CC71B621B004FA76856E5129D6B17030C8147@sbjgexmb1.amd.com>
Message-ID: <1253202803.29976.31.camel@tetris>

Am Donnerstag, den 17.09.2009, 10:21 +0800 schrieb Bao, Zheng:
> It is Filo 0.6 with libpayload.
> 
> The attached file is the binary.
> 
> With Ron's patch "fix cbfstool malloc arena corruption", the SOFT_RESET
> is still there.
I could reproduce the issue and will work on fixing it.

As a workaround, you can set RAMBASE to 4mb (it is at 2mb now), so
coreboot_ram doesn't overlap with the payload (which has a .bss section
reaching well to 2.5mb or so), or set it to 1mb (as is the case for most
other boards), so the payload and the overlap region are aligned.


Regards,
Patrick




From mylesgw at gmail.com  Thu Sep 17 18:07:32 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Sep 2009 10:07:32 -0600
Subject: [coreboot] Kconfig VGA console
In-Reply-To: <2831fecf0908280932n5e8f87d0k6c5e1b11583091bd@mail.gmail.com>
References: <2831fecf0908280932n5e8f87d0k6c5e1b11583091bd@mail.gmail.com>
Message-ID: <2831fecf0909170907i2c581453m11f291dee9a40dcd@mail.gmail.com>

On Fri, Aug 28, 2009 at 10:32 AM, Myles Watson <mylesgw at gmail.com> wrote:

> Separate CONFIG_CONSOLE_VGA from CONFIG_VGA_BRIDGE_SETUP.
>
> CONSOLE_VGA means use VGA for the boot console.
> VGA_BRIDGE_SETUP means set the bits so that VGA can be used.
>
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
>

Ping.

I realize it no longer applies cleanly since Peter implemented part of it.
There haven't been any comments on the rest of it, though.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/aa8cb833/attachment.html>

From svn at coreboot.org  Thu Sep 17 18:21:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 18:21:31 +0200
Subject: [coreboot] [v2] r4642 - trunk/coreboot-v2/src
Message-ID: <mailman.3706.1355071618.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-09-17 18:21:31 +0200 (Thu, 17 Sep 2009)
New Revision: 4642

Modified:
   trunk/coreboot-v2/src/Kconfig
Log:
Move VGA BIOS settings from the payload menu into it's own menu

Remove dependency on PAYLOAD_ELF so that config items are shown.
Build tested. With this, coreboot.rom has a VGA BIOS optionrom added.

Signed-off-by: Peter Stuge <peter at stuge.se>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/src/Kconfig
===================================================================
--- trunk/coreboot-v2/src/Kconfig	2009-09-17 15:35:08 UTC (rev 4641)
+++ trunk/coreboot-v2/src/Kconfig	2009-09-17 16:21:31 UTC (rev 4642)
@@ -238,17 +238,6 @@
 
 	  You will be able to specify the location and file name of the
 	  payload image later.
-
-config VGA_BIOS
-	bool "Add a VGA BIOS image"
-	depends on PAYLOAD_ELF
-	help
-	  Select this option if you have a VGA BIOS image that you would
-	  like to add to your ROM.
-
-	  You will be able to specify the location and file name of the
-	  image later.
-
 config PAYLOAD_NONE
 	bool "No payload"
 	help
@@ -268,6 +257,19 @@
 	help
 	  The path and filename of the ELF executable file to use as payload.
 
+endmenu
+
+menu "VGA BIOS"
+
+config VGA_BIOS
+	bool "Add a VGA BIOS image"
+	help
+	  Select this option if you have a VGA BIOS image that you would
+	  like to add to your ROM.
+
+	  You will be able to specify the location and file name of the
+	  image later.
+
 config FALLBACK_VGA_BIOS_FILE
 	string "VGA BIOS path and filename"
 	depends on VGA_BIOS




From peter at stuge.se  Thu Sep 17 18:21:44 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 18:21:44 +0200
Subject: [coreboot] Move VGA BIOS settings from payload menu into a	menu
	of it's own
In-Reply-To: <1253199250.29976.23.camel@tetris>
References: <20090917064039.30879.qmail@stuge.se>
	<20090917080212.12049.qmail@stuge.se>
	<1253199250.29976.23.camel@tetris>
Message-ID: <20090917162144.7479.qmail@stuge.se>

Patrick Georgi wrote:
> > Revised patch attached. This time actually remove the dependency on
> > PAYLOAD_ELF. Oops.
> 
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Thanks, r4642.


//Peter



From peter at stuge.se  Thu Sep 17 18:35:14 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 18:35:14 +0200
Subject: [coreboot] Kconfig VGA console
In-Reply-To: <2831fecf0909170907i2c581453m11f291dee9a40dcd@mail.gmail.com>
References: <2831fecf0908280932n5e8f87d0k6c5e1b11583091bd@mail.gmail.com>
	<2831fecf0909170907i2c581453m11f291dee9a40dcd@mail.gmail.com>
Message-ID: <20090917163515.9814.qmail@stuge.se>

Myles Watson wrote:
> > Separate CONFIG_CONSOLE_VGA from CONFIG_VGA_BRIDGE_SETUP.
> >
> > CONSOLE_VGA means use VGA for the boot console.
> > VGA_BRIDGE_SETUP means set the bits so that VGA can be used.
> >
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> 
> Ping.

Acked-by: Peter Stuge <peter at stuge.se>


> I realize it no longer applies cleanly since Peter implemented part
> of it. There haven't been any comments on the rest of it, though.

I think I only touched another part? I only moved CONFIG_VGABIOS out
of the payload menu.

Anyway, please go ahead with this fine patch! :)


//Peter



From svn at coreboot.org  Thu Sep 17 18:54:46 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 18:54:46 +0200
Subject: [coreboot] [v2] r4643 - in trunk/coreboot-v2/src: . console devices
Message-ID: <mailman.3707.1355071618.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-17 18:54:46 +0200 (Thu, 17 Sep 2009)
New Revision: 4643

Modified:
   trunk/coreboot-v2/src/Kconfig
   trunk/coreboot-v2/src/console/Kconfig
   trunk/coreboot-v2/src/devices/Kconfig
   trunk/coreboot-v2/src/devices/device.c
Log:
Separate CONFIG_VGA_CONSOLE from CONFIG_VGA_BRIDGE_SETUP.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: trunk/coreboot-v2/src/Kconfig
===================================================================
--- trunk/coreboot-v2/src/Kconfig	2009-09-17 16:21:31 UTC (rev 4642)
+++ trunk/coreboot-v2/src/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
@@ -282,7 +282,8 @@
 	depends on VGA_BIOS
 	default "1106,3230"
 	help
-	 The ID that would associate your VGA BIOS to your video card.
+	  The ID that would associate your VGA BIOS to your video card.
+	  (PCI VendorID, PCI Device ID)
 
 endmenu
 

Modified: trunk/coreboot-v2/src/console/Kconfig
===================================================================
--- trunk/coreboot-v2/src/console/Kconfig	2009-09-17 16:21:31 UTC (rev 4642)
+++ trunk/coreboot-v2/src/console/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
@@ -29,7 +29,7 @@
 	# TODO: FIX DEPENDENCY HERE
 
 config CONSOLE_VGA
-	bool
+	bool "Use VGA console, once initialized."
 	default n
 
 config MAXIMUM_CONSOLE_LOGLEVEL

Modified: trunk/coreboot-v2/src/devices/Kconfig
===================================================================
--- trunk/coreboot-v2/src/devices/Kconfig	2009-09-17 16:21:31 UTC (rev 4642)
+++ trunk/coreboot-v2/src/devices/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
@@ -20,6 +20,13 @@
 
 menu "Devices"
 
+config VGA_BRIDGE_SETUP
+	bool "Setup bridges on path to VGA adapter"
+	default y
+	help
+	  Allow bridges to set up legacy decoding ranges for VGA.  Don't disable
+	  this unless you're sure you don't want the briges setup for VGA.
+
 config VGA_ROM_RUN
 	bool "Run VGA Option ROMs"
 	help
@@ -32,11 +39,11 @@
 	  Execute non-VGA PCI option ROMs if found.
 
 choice
-        prompt "Option ROM Execution"
-        default  PCI_OPTION_ROM_RUN_REALMODE
+	prompt "Option ROM Execution"
+	default  PCI_OPTION_ROM_RUN_REALMODE
 	depends on PCI_ROM_RUN || VGA_ROM_RUN
-        help
-          You can choose to execute PCI option ROMs natively (32bit x86 system
+	help
+	  You can choose to execute PCI option ROMs natively (32bit x86 system
 	  required) or in an emulator (x86emu or YABEL).
 
 	config PCI_OPTION_ROM_RUN_REALMODE
@@ -62,6 +69,10 @@
 
 endmenu
 
+config CONSOLE_VGA_MULTI
+	bool
+	default n
+
 config PCI_64BIT_PREF_MEM
 	bool
 	default n
@@ -85,6 +96,3 @@
 config CARDBUS_PLUGIN_SUPPORT
 	bool
 	default n
-
-
-

Modified: trunk/coreboot-v2/src/devices/device.c
===================================================================
--- trunk/coreboot-v2/src/devices/device.c	2009-09-17 16:21:31 UTC (rev 4642)
+++ trunk/coreboot-v2/src/devices/device.c	2009-09-17 16:54:46 UTC (rev 4643)
@@ -667,7 +667,7 @@
 	}
 }
 
-#if CONFIG_CONSOLE_VGA == 1
+#if CONFIG_VGA_BRIDGE_SETUP == 1
 device_t vga_pri = 0;
 static void set_vga_bridge_bits(void)
 {
@@ -926,7 +926,7 @@
 	struct device *child;
 	int i;
 
-#if CONFIG_CONSOLE_VGA == 1
+#if CONFIG_VGA_BRIDGE_SETUP == 1
 	set_vga_bridge_bits();
 #endif
 




From mylesgw at gmail.com  Thu Sep 17 18:55:31 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Sep 2009 10:55:31 -0600
Subject: [coreboot] Kconfig VGA console
In-Reply-To: <20090917163515.9814.qmail@stuge.se>
References: <2831fecf0908280932n5e8f87d0k6c5e1b11583091bd@mail.gmail.com>
	<2831fecf0909170907i2c581453m11f291dee9a40dcd@mail.gmail.com>
	<20090917163515.9814.qmail@stuge.se>
Message-ID: <2831fecf0909170955t5859568ve27dae11bd1873bc@mail.gmail.com>

On Thu, Sep 17, 2009 at 10:35 AM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > > Separate CONFIG_CONSOLE_VGA from CONFIG_VGA_BRIDGE_SETUP.
> > >
> > > CONSOLE_VGA means use VGA for the boot console.
> > > VGA_BRIDGE_SETUP means set the bits so that VGA can be used.
> > >
> > > Signed-off-by: Myles Watson <mylesgw at gmail.com>
> >
> > Ping.
>
> Acked-by: Peter Stuge <peter at stuge.se>
>
>
> > I realize it no longer applies cleanly since Peter implemented part
> > of it. There haven't been any comments on the rest of it, though.
>
> I think I only touched another part? I only moved CONFIG_VGABIOS out
> of the payload menu. <http://www.coreboot.org/mailman/listinfo/coreboot>
>
You're right.  The overlap was smaller than I remembered.  I must have
wanted to do what you did, but not gotten around to it :)

Rev 4643.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/eb580a43/attachment.html>

From svn at coreboot.org  Thu Sep 17 18:59:08 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 18:59:08 +0200
Subject: [coreboot] [v2] r4644 - in trunk/coreboot-v2/src:
	cpu/amd/socket_940 cpu/amd/socket_AM2 cpu/amd/socket_F
	cpu/amd/socket_S1G1 mainboard/amd/serengeti_cheetah
	mainboard/asus/m2v-mx_se
Message-ID: <mailman.3708.1355071618.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-17 18:59:07 +0200 (Thu, 17 Sep 2009)
New Revision: 4644

Modified:
   trunk/coreboot-v2/src/cpu/amd/socket_940/Kconfig
   trunk/coreboot-v2/src/cpu/amd/socket_AM2/Kconfig
   trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig
   trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
   trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/Kconfig
Log:
Remove warnings from Kconfig.  Trivial.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: trunk/coreboot-v2/src/cpu/amd/socket_940/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_940/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/cpu/amd/socket_940/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -9,8 +9,8 @@
 
 #Opteron K8 1G HT Support
 config K8_HT_FREQ_1G_SUPPORT
-	hex
-	default 1
+	bool
+	default y
 	depends on CPU_AMD_SOCKET_940
 
 config CPU_AMD_MODEL_FXX

Modified: trunk/coreboot-v2/src/cpu/amd/socket_AM2/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_AM2/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/cpu/amd/socket_AM2/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -14,8 +14,8 @@
 
 # Opteron K8 1G HT support
 config K8_HT_FREQ_1G_SUPPORT
-	hex
-	default 1
+	bool
+	default y
 	depends on CPU_AMD_SOCKET_AM2
 
 # DDR2 and REG

Modified: trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -14,8 +14,8 @@
 
 # Opteron K8 1G HT support
 config K8_HT_FREQ_1G_SUPPORT
-	hex
-	default 1
+	bool
+	default y
 	depends on CPU_AMD_SOCKET_F
 
 # DDR2 and REG

Modified: trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/cpu/amd/socket_S1G1/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -13,8 +13,8 @@
 	depends on CPU_AMD_SOCKET_S1G1
 
 config K8_HT_FREQ_1G_SUPPORT
-	hex
-	default 1
+	bool
+	default y
 	depends on CPU_AMD_SOCKET_S1G1
 
 #DDR2 and REG, S1G1

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -35,8 +35,8 @@
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config APIC_ID_OFFSET
-	int
-	default 8
+	hex
+	default 0x8
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config HAVE_HARD_RESET

Modified: trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/Kconfig	2009-09-17 16:54:46 UTC (rev 4643)
+++ trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/Kconfig	2009-09-17 16:59:07 UTC (rev 4644)
@@ -89,13 +89,13 @@
 	depends on BOARD_ASUS_M2V_MX_SE
 
 config STACK_SIZE
-	int
-	default 8192
+	hex
+	default 0x2000
 	depends on BOARD_ASUS_M2V_MX_SE
 
 config HEAP_SIZE
-	int
-	default 262144
+	hex
+	default 0x40000
 	depends on BOARD_ASUS_M2V_MX_SE
 
 config HAVE_OPTION_TABLE




From peter at stuge.se  Thu Sep 17 19:01:21 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 19:01:21 +0200
Subject: [coreboot] Kconfig defaults per chipset, or mainboard?
Message-ID: <20090917170121.14363.qmail@stuge.se>

In src/Kconfig there is this:

config FALLBACK_VGA_BIOS_ID
        string "VGA BIOS ID"
        depends on VGA_BIOS
        default "1106,3230"
        help
          The ID that would associate your VGA BIOS to your video card.
          (PCI VendorID, PCI Device ID)

How does a component (nb, sb, sio) or mainboard provide an override
for this default?


//Peter



From peter at stuge.se  Thu Sep 17 19:04:21 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 19:04:21 +0200
Subject: [coreboot] Kconfig defaults per chipset, or mainboard?
In-Reply-To: <20090917170121.14363.qmail@stuge.se>
References: <20090917170121.14363.qmail@stuge.se>
Message-ID: <20090917170421.14813.qmail@stuge.se>

Peter Stuge wrote:
> How does a component (nb, sb, sio) or mainboard provide an override
> for this default?

Another thing I ran into. Can we deal with something like
CONFIG_VIDEO_MB in a smarter way than letting it be int? Different
boards will have different permitted options.

One thought is to have a single list with all possible options and
have each option depend on the list of components/boards that applies
- but that will get REALLY verbose, no?


//Peter



From patrick at georgi-clan.de  Thu Sep 17 19:07:25 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 17 Sep 2009 19:07:25 +0200
Subject: [coreboot] Kconfig defaults per chipset, or mainboard?
In-Reply-To: <20090917170121.14363.qmail@stuge.se>
References: <20090917170121.14363.qmail@stuge.se>
Message-ID: <1253207245.29976.32.camel@tetris>

Am Donnerstag, den 17.09.2009, 19:01 +0200 schrieb Peter Stuge:
> In src/Kconfig there is this:
> 
> config FALLBACK_VGA_BIOS_ID
>         string "VGA BIOS ID"
>         depends on VGA_BIOS
>         default "1106,3230"
>         help
>           The ID that would associate your VGA BIOS to your video card.
>           (PCI VendorID, PCI Device ID)
> 
> How does a component (nb, sb, sio) or mainboard provide an override
> for this default?
> 
config FALLBACK_VGA_BIOS_ID
	string
	default "1234,5678"
	depends on NB_OR_SB_OR_SIO_OR_BOARD_ID

should work




From info at coresystems.de  Thu Sep 17 19:17:07 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 17 Sep 2009 19:17:07 +0200
Subject: [coreboot] build service results for r4643
Message-ID: <E1MoKbT-0001tz-OR@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4643 to
the coreboot repository. This caused the following 
changes:

Change Log:
Separate CONFIG_VGA_CONSOLE from CONFIG_VGA_BRIDGE_SETUP.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>



Build Log:
Compilation of a-trend:atc-6220 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=atc-6220&vendor=a-trend&num=2
Compilation of a-trend:atc-6240 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=atc-6240&vendor=a-trend&num=2
Compilation of abit:be6-ii_v2_0 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=be6-ii_v2_0&vendor=abit&num=2
Compilation of amd:dbm690t has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=dbm690t&vendor=amd&num=2
Compilation of amd:pistachio has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=pistachio&vendor=amd&num=2
Compilation of amd:serengeti_cheetah has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=serengeti_cheetah&vendor=amd&num=2
Compilation of amd:serengeti_cheetah_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=serengeti_cheetah_fam10&vendor=amd&num=2
Compilation of arima:hdama has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=hdama&vendor=arima&num=2
Compilation of asus:a8n_e has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=a8n_e&vendor=asus&num=2
Compilation of asus:a8v-e_se has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=a8v-e_se&vendor=asus&num=2
Compilation of asus:mew-am has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=mew-am&vendor=asus&num=2
Compilation of asus:p2b has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=p2b&vendor=asus&num=2
Compilation of asus:p2b-d has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=p2b-d&vendor=asus&num=2
Compilation of asus:p2b-ds has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=p2b-ds&vendor=asus&num=2
Compilation of asus:p2b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=p2b-f&vendor=asus&num=2
Compilation of asus:p3b-f has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=p3b-f&vendor=asus&num=2
Compilation of azza:pt-6ibd has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=pt-6ibd&vendor=azza&num=2
Compilation of biostar:m6tba has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=m6tba&vendor=biostar&num=2
Compilation of compaq:deskpro_en_sff_p600 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=deskpro_en_sff_p600&vendor=compaq&num=2
Compilation of gigabyte:ga-6bxc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ga-6bxc&vendor=gigabyte&num=2
Compilation of gigabyte:ga_2761gxdk has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ga_2761gxdk&vendor=gigabyte&num=2
Compilation of gigabyte:m57sli has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=m57sli&vendor=gigabyte&num=2
Compilation of ibm:e326 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=e326&vendor=ibm&num=2
Compilation of iei:nova4899r has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=nova4899r&vendor=iei&num=2
Compilation of iwill:dk8_htx has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=dk8_htx&vendor=iwill&num=2
Compilation of kontron:986lcd-m has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=986lcd-m&vendor=kontron&num=2
Compilation of mitac:6513wu has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=6513wu&vendor=mitac&num=2
Compilation of msi:ms6119 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms6119&vendor=msi&num=2
Compilation of msi:ms6147 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms6147&vendor=msi&num=2
Compilation of msi:ms6178 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms6178&vendor=msi&num=2
Compilation of msi:ms7135 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms7135&vendor=msi&num=2
Compilation of msi:ms7260 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms7260&vendor=msi&num=2
Compilation of msi:ms9185 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms9185&vendor=msi&num=2
Compilation of msi:ms9282 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ms9282&vendor=msi&num=2
Compilation of nec:powermate2000 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=powermate2000&vendor=nec&num=2
Compilation of newisys:khepri has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=khepri&vendor=newisys&num=2
Compilation of nvidia:l1_2pvv has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=l1_2pvv&vendor=nvidia&num=2
Compilation of soyo:sy-6ba-plus-iii has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=sy-6ba-plus-iii&vendor=soyo&num=2
Compilation of sunw:ultra40 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=ultra40&vendor=sunw&num=2
Compilation of supermicro:h8dme has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=h8dme&vendor=supermicro&num=2
Compilation of supermicro:h8dmr has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=h8dmr&vendor=supermicro&num=2
Compilation of technexion:tim8690 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=tim8690&vendor=technexion&num=2
Compilation of tyan:s1846 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s1846&vendor=tyan&num=2
Compilation of tyan:s2850 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2850&vendor=tyan&num=2
Compilation of tyan:s2875 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2875&vendor=tyan&num=2
Compilation of tyan:s2880 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2880&vendor=tyan&num=2
Compilation of tyan:s2881 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2881&vendor=tyan&num=2
Compilation of tyan:s2882 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2882&vendor=tyan&num=2
Compilation of tyan:s2885 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2885&vendor=tyan&num=2
Compilation of tyan:s2891 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2891&vendor=tyan&num=2
Compilation of tyan:s2892 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2892&vendor=tyan&num=2
Compilation of tyan:s2895 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2895&vendor=tyan&num=2
Compilation of tyan:s2912 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2912&vendor=tyan&num=2
Compilation of tyan:s2912_fam10 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s2912_fam10&vendor=tyan&num=2
Compilation of tyan:s4880 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4643&device=s4880&vendor=tyan&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From peter at stuge.se  Thu Sep 17 19:19:23 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 17 Sep 2009 19:19:23 +0200
Subject: [coreboot] Kconfig defaults per chipset, or mainboard?
In-Reply-To: <1253207245.29976.32.camel@tetris>
References: <20090917170121.14363.qmail@stuge.se>
	<1253207245.29976.32.camel@tetris>
Message-ID: <20090917171923.17439.qmail@stuge.se>

Patrick Georgi wrote:
> > In src/Kconfig there is this:
> > 
> > config FALLBACK_VGA_BIOS_ID
> >         string "VGA BIOS ID"
> >         depends on VGA_BIOS
> >         default "1106,3230"
> > 
> > How does a component (nb, sb, sio) or mainboard provide an override
> > for this default?
> 
> config FALLBACK_VGA_BIOS_ID
> 	string
> 	default "1234,5678"
> 	depends on NB_OR_SB_OR_SIO_OR_BOARD_ID
> 
> should work

Cool. How does the precedence work?


//Peter



From patrick at georgi-clan.de  Thu Sep 17 19:33:18 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 17 Sep 2009 19:33:18 +0200
Subject: [coreboot] Kconfig defaults per chipset, or mainboard?
In-Reply-To: <20090917171923.17439.qmail@stuge.se>
References: <20090917170121.14363.qmail@stuge.se>
	<1253207245.29976.32.camel@tetris>
	<20090917171923.17439.qmail@stuge.se>
Message-ID: <1253208798.29976.34.camel@tetris>

Am Donnerstag, den 17.09.2009, 19:19 +0200 schrieb Peter Stuge:
> Patrick Georgi wrote:
> > > In src/Kconfig there is this:
> > > 
> > > config FALLBACK_VGA_BIOS_ID
> > >         string "VGA BIOS ID"
> > >         depends on VGA_BIOS
> > >         default "1106,3230"
> > > 
> > > How does a component (nb, sb, sio) or mainboard provide an override
> > > for this default?
> > 
> > config FALLBACK_VGA_BIOS_ID
> > 	string
> > 	default "1234,5678"
> > 	depends on NB_OR_SB_OR_SIO_OR_BOARD_ID
> > 
> > should work
> 
> Cool. How does the precedence work?
No idea. Either it's "last one wins" in reading order, or - that's what
I hope, it's "most specific wins".

And for that, there should always be only the global default and one
that applies for each configuration (eg. by making sure that these
values are defined by the same class of devices, ie. SBs, NBs, SIOs or
boards)


Patrick




From info at coresystems.de  Thu Sep 17 19:41:03 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 17 Sep 2009 19:41:03 +0200
Subject: [coreboot] build service results for r4644
Message-ID: <E1MoKyd-00032l-Sp@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4644 to
the coreboot repository. This caused the following 
changes:

Change Log:
Remove warnings from Kconfig.  Trivial.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Build Log:
Compilation of a-trend:atc-6220 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=atc-6220&vendor=a-trend&num=2
Compilation of a-trend:atc-6240 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=atc-6240&vendor=a-trend&num=2
Compilation of abit:be6-ii_v2_0 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=be6-ii_v2_0&vendor=abit&num=2
Compilation of amd:dbm690t is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=dbm690t&vendor=amd&num=2
Compilation of amd:pistachio is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=pistachio&vendor=amd&num=2
Compilation of amd:serengeti_cheetah is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=serengeti_cheetah&vendor=amd&num=2
Compilation of amd:serengeti_cheetah_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=serengeti_cheetah_fam10&vendor=amd&num=2
Compilation of arima:hdama is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=hdama&vendor=arima&num=2
Compilation of asus:a8n_e is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=a8n_e&vendor=asus&num=2
Compilation of asus:a8v-e_se is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=a8v-e_se&vendor=asus&num=2
Compilation of asus:mew-am is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=mew-am&vendor=asus&num=2
Compilation of asus:p2b is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=p2b&vendor=asus&num=2
Compilation of asus:p2b-d is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=p2b-d&vendor=asus&num=2
Compilation of asus:p2b-ds is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=p2b-ds&vendor=asus&num=2
Compilation of asus:p2b-f is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=p2b-f&vendor=asus&num=2
Compilation of asus:p3b-f is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=p3b-f&vendor=asus&num=2
Compilation of azza:pt-6ibd is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=pt-6ibd&vendor=azza&num=2
Compilation of biostar:m6tba is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=m6tba&vendor=biostar&num=2
Compilation of compaq:deskpro_en_sff_p600 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=deskpro_en_sff_p600&vendor=compaq&num=2
Compilation of gigabyte:ga-6bxc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ga-6bxc&vendor=gigabyte&num=2
Compilation of gigabyte:ga_2761gxdk is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ga_2761gxdk&vendor=gigabyte&num=2
Compilation of gigabyte:m57sli is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=m57sli&vendor=gigabyte&num=2
Compilation of ibm:e326 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=e326&vendor=ibm&num=2
Compilation of iei:nova4899r is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=nova4899r&vendor=iei&num=2
Compilation of iwill:dk8_htx is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=dk8_htx&vendor=iwill&num=2
Compilation of kontron:986lcd-m is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=986lcd-m&vendor=kontron&num=2
Compilation of mitac:6513wu is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=6513wu&vendor=mitac&num=2
Compilation of msi:ms6119 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms6119&vendor=msi&num=2
Compilation of msi:ms6147 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms6147&vendor=msi&num=2
Compilation of msi:ms6178 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms6178&vendor=msi&num=2
Compilation of msi:ms7135 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms7135&vendor=msi&num=2
Compilation of msi:ms7260 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms7260&vendor=msi&num=2
Compilation of msi:ms9185 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms9185&vendor=msi&num=2
Compilation of msi:ms9282 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ms9282&vendor=msi&num=2
Compilation of nec:powermate2000 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=powermate2000&vendor=nec&num=2
Compilation of newisys:khepri is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=khepri&vendor=newisys&num=2
Compilation of nvidia:l1_2pvv is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=l1_2pvv&vendor=nvidia&num=2
Compilation of soyo:sy-6ba-plus-iii is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=sy-6ba-plus-iii&vendor=soyo&num=2
Compilation of sunw:ultra40 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=ultra40&vendor=sunw&num=2
Compilation of supermicro:h8dme is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=h8dme&vendor=supermicro&num=2
Compilation of supermicro:h8dmr is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=h8dmr&vendor=supermicro&num=2
Compilation of technexion:tim8690 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=tim8690&vendor=technexion&num=2
Compilation of tyan:s1846 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s1846&vendor=tyan&num=2
Compilation of tyan:s2850 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2850&vendor=tyan&num=2
Compilation of tyan:s2875 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2875&vendor=tyan&num=2
Compilation of tyan:s2880 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2880&vendor=tyan&num=2
Compilation of tyan:s2881 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2881&vendor=tyan&num=2
Compilation of tyan:s2882 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2882&vendor=tyan&num=2
Compilation of tyan:s2885 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2885&vendor=tyan&num=2
Compilation of tyan:s2891 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2891&vendor=tyan&num=2
Compilation of tyan:s2892 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2892&vendor=tyan&num=2
Compilation of tyan:s2895 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2895&vendor=tyan&num=2
Compilation of tyan:s2912 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2912&vendor=tyan&num=2
Compilation of tyan:s2912_fam10 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s2912_fam10&vendor=tyan&num=2
Compilation of tyan:s4880 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4644&device=s4880&vendor=tyan&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Thu Sep 17 20:30:23 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 17 Sep 2009 20:30:23 +0200
Subject: [coreboot] [v2] r4645 - trunk/coreboot-v2/src/config
Message-ID: <mailman.3709.1355071619.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-17 20:30:23 +0200 (Thu, 17 Sep 2009)
New Revision: 4645

Modified:
   trunk/coreboot-v2/src/config/Options.lb
Log:
I forgot to add CONFIG_VGA_BRIDGE_SETUP to the old build system.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: trunk/coreboot-v2/src/config/Options.lb
===================================================================
--- trunk/coreboot-v2/src/config/Options.lb	2009-09-17 16:59:07 UTC (rev 4644)
+++ trunk/coreboot-v2/src/config/Options.lb	2009-09-17 18:30:23 UTC (rev 4645)
@@ -426,6 +426,11 @@
 	export always
 	comment "Enable x86emu debugging code"
 end
+define CONFIG_VGA_BRIDGE_SETUP
+	default 1
+	export always
+	comment "Set bridge bits to enable legacy VGA ranges"
+end
 define CONFIG_CONSOLE_VGA
 	default 0
 	export always




From info at coresystems.de  Thu Sep 17 20:53:25 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 17 Sep 2009 20:53:25 +0200
Subject: [coreboot] build service results for r4645
Message-ID: <E1MoM6f-00005A-Kz@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4645 to
the coreboot repository. This caused the following 
changes:

Change Log:
I forgot to add CONFIG_VGA_BRIDGE_SETUP to the old build system.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Build Log:
Compilation of a-trend:atc-6220 has been fixed
Compilation of a-trend:atc-6240 has been fixed
Compilation of abit:be6-ii_v2_0 has been fixed
Compilation of amd:dbm690t has been fixed
Compilation of amd:pistachio has been fixed
Compilation of amd:serengeti_cheetah has been fixed
Compilation of amd:serengeti_cheetah_fam10 has been fixed
Compilation of arima:hdama has been fixed
Compilation of asus:a8n_e has been fixed
Compilation of asus:a8v-e_se has been fixed
Compilation of asus:mew-am has been fixed
Compilation of asus:p2b has been fixed
Compilation of asus:p2b-d has been fixed
Compilation of asus:p2b-ds has been fixed
Compilation of asus:p2b-f has been fixed
Compilation of asus:p3b-f has been fixed
Compilation of azza:pt-6ibd has been fixed
Compilation of biostar:m6tba has been fixed
Compilation of compaq:deskpro_en_sff_p600 has been fixed
Compilation of gigabyte:ga-6bxc has been fixed
Compilation of gigabyte:ga_2761gxdk has been fixed
Compilation of gigabyte:m57sli has been fixed
Compilation of ibm:e326 has been fixed
Compilation of iei:nova4899r has been fixed
Compilation of iwill:dk8_htx has been fixed
Compilation of kontron:986lcd-m has been fixed
Compilation of mitac:6513wu has been fixed
Compilation of msi:ms6119 has been fixed
Compilation of msi:ms6147 has been fixed
Compilation of msi:ms6178 has been fixed
Compilation of msi:ms7135 has been fixed
Compilation of msi:ms7260 has been fixed
Compilation of msi:ms9185 has been fixed
Compilation of msi:ms9282 has been fixed
Compilation of nec:powermate2000 has been fixed
Compilation of newisys:khepri has been fixed
Compilation of nvidia:l1_2pvv has been fixed
Compilation of soyo:sy-6ba-plus-iii has been fixed
Compilation of sunw:ultra40 has been fixed
Compilation of supermicro:h8dme has been fixed
Compilation of supermicro:h8dmr has been fixed
Compilation of technexion:tim8690 has been fixed
Compilation of tyan:s1846 has been fixed
Compilation of tyan:s2850 has been fixed
Compilation of tyan:s2875 has been fixed
Compilation of tyan:s2880 has been fixed
Compilation of tyan:s2881 has been fixed
Compilation of tyan:s2882 has been fixed
Compilation of tyan:s2885 has been fixed
Compilation of tyan:s2891 has been fixed
Compilation of tyan:s2892 has been fixed
Compilation of tyan:s2895 has been fixed
Compilation of tyan:s2912 has been fixed
Compilation of tyan:s2912_fam10 has been fixed
Compilation of tyan:s4880 has been fixed


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From antonio.exposito at ono.com  Thu Sep 17 21:13:29 2009
From: antonio.exposito at ono.com (=?iso-8859-1?Q?Antonio_Exp=F3sito?=)
Date: Thu, 17 Sep 2009 21:13:29 +0200
Subject: [coreboot] BIOS POST codes monitoring in real time from other
	computer
Message-ID: <000e01ca37ca$f3c780a0$db5681e0$@exposito@ono.com>

Hi all,

 

I don?t want to disturb you with ?newbie things?, but this is a way to start
like another.

 

I am trying to monitor the boot process of a computer, mainly BIOS POST
codes and linux kernel boot process. I know how to do it for the linux
kernel using a serial port, but I am not able to imagine how to monitor the
BIOS POST codes.

 

I know that almost every BIOS sends them to the ISA I/O address 0080h, but,
how can I get that codes using another computer? I mean,  without POST
ISA/PCI card, using another computer connected to it via SMBUS, LPC or
serial?

 

Is there any way to convert LPC to serial and monitor that port?

 

I want to do this with a VIA P700 motherboard, is this board supported by
the coreboot v3?

 

Could be easy to redirect BIOS POST codes to a serial port using a coreboot
implementation?

 

Thanks in advance,

 

Antonio

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/aaf854b7/attachment.html>

From mylesgw at gmail.com  Thu Sep 17 21:23:02 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Sep 2009 13:23:02 -0600
Subject: [coreboot] BIOS POST codes monitoring in real time from other
	computer
In-Reply-To: <-3604913777543925274@unknownmsgid>
References: <-3604913777543925274@unknownmsgid>
Message-ID: <2831fecf0909171223t8abe706v9f0ba9f78bbea114@mail.gmail.com>

2009/9/17 Antonio Exp?sito <antonio.exposito at ono.com>

>  I am trying to monitor the boot process of a computer, mainly BIOS POST
> codes and linux kernel boot process. I know how to do it for the linux
> kernel using a serial port, but I am not able to imagine how to monitor the
> BIOS POST codes.
>
> I know that almost every BIOS sends them to the ISA I/O address 0080h, but,
> how can I get that codes using another computer? I mean,  without POST
> ISA/PCI card, using another computer connected to it via SMBUS, LPC or
> serial?
>
> Is there any way to convert LPC to serial and monitor that port?
>
I don't know of an easy way.

> I want to do this with a VIA P700 motherboard, is this board supported by
> the coreboot v3?
>
 http://www.coreboot.org/Supported_Motherboards
I don't think so.  Coreboot v2 is the most active branch.

> Could be easy to redirect BIOS POST codes to a serial port using a coreboot
> implementation?
>
Coreboot sends debug information to the serial port, so there is no need for
monitoring the POST codes except very early in the boot process.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/3ae71714/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Thu Sep 17 21:49:14 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Thu, 17 Sep 2009 21:49:14 +0200
Subject: [coreboot] BIOS POST codes monitoring in real time from other
 computer
In-Reply-To: <000e01ca37ca$f3c780a0$db5681e0$@exposito@ono.com>
References: <000e01ca37ca$f3c780a0$db5681e0$@exposito@ono.com>
Message-ID: <4AB292BA.7000805@gmx.net>

Hi,

On 17.09.2009 21:13, Antonio Exp?sito wrote:
> I know that almost every BIOS sends them to the ISA I/O address 0080h, but,
> how can I get that codes using another computer? I mean,  without POST
> ISA/PCI card, using another computer connected to it via SMBUS, LPC or
> serial?
>   

There are some POST cards which convert the POST codes to serial, but
they are really expensive (>50 EUR).

> Is there any way to convert LPC to serial and monitor that port?
>   

You can convert LPC to usb-serial (a virtual serial device which appears
once you plug in the USB side into the monitoring computer) with the
Artec FlexyIce (formerly known as the Artec Dongle). The FlexyIce is
also usable as LPC/FWH ROM emulator and ideal for firmware/coreboot
development.

> Could be easy to redirect BIOS POST codes to a serial port using a coreboot
> implementation?
>   

If you have coreboot, you don't need POST codes because you get detailed
messages (similar to Linux kernel messages) from coreboot on the serial
port.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From stepan at coresystems.de  Thu Sep 17 21:51:10 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 17 Sep 2009 21:51:10 +0200
Subject: [coreboot] Move VGA BIOS settings from payload menu into a	menu
 of it's own
In-Reply-To: <20090917080212.12049.qmail@stuge.se>
References: <20090917064039.30879.qmail@stuge.se>
	<20090917080212.12049.qmail@stuge.se>
Message-ID: <4AB2932E.3030007@coresystems.de>

Peter Stuge wrote:
> Peter Stuge wrote:
>   
>> Patch attached.
>>     
>
> Revised patch attached. This time actually remove the dependency on
> PAYLOAD_ELF. Oops.
>
>
> //Peter
>   
Should the menu maybe be called "Option ROMs" or some such?

Acked-by: Stefan Reinauer <stepan at coresystems.de>



From antonio.exposito at ono.com  Thu Sep 17 21:52:27 2009
From: antonio.exposito at ono.com (=?iso-8859-1?Q?Antonio_Exp=F3sito?=)
Date: Thu, 17 Sep 2009 21:52:27 +0200
Subject: [coreboot] BIOS POST codes monitoring in real time from other
	computer
In-Reply-To: <2831fecf0909171223t8abe706v9f0ba9f78bbea114@mail.gmail.com>
References: <-3604913777543925274@unknownmsgid>
	<2831fecf0909171223t8abe706v9f0ba9f78bbea114@mail.gmail.com>
Message-ID: <002201ca37d0$65d12110$31736330$@exposito@ono.com>

I have seen the supported motherboard list/status, and there are several VIA
motherboards with chipsets of the same family but different models.

 

Is it difficult to adapt one of them to my motherboard? (AMOS-3000 embedded
computer with P700 motherboard)

 

I have located the following chips:

 

VIA NOR/SOUTH BRIDGE VX700

VIA SUPER I/O LITE VT1212

VIA HD AUDIO VT1708B

VIA ETHERNET CONTROLLER VT6107 /VT6122 

TI RS-232 MAX3243

ANALOG DEVICES HW MONITOR ADM1032

ICS CLOCK SYNTHESIZER ICS952906 (I don?t know what is this)

 

Perhaps I can help, which are the first steps?

 

Any doc for a new guy?

 

This is my hobby, but I am really enthusiastic.

 

Thanks,

 

Antonio

 

 

De: Myles Watson [mailto:mylesgw at gmail.com] 
Enviado el: jueves, 17 de septiembre de 2009 21:23
Para: Antonio Exp?sito
CC: coreboot at coreboot.org
Asunto: Re: [coreboot] BIOS POST codes monitoring in real time from other
computer

 

 

2009/9/17 Antonio Exp?sito <antonio.exposito at ono.com>

I am trying to monitor the boot process of a computer, mainly BIOS POST
codes and linux kernel boot process. I know how to do it for the linux
kernel using a serial port, but I am not able to imagine how to monitor the
BIOS POST codes.

I know that almost every BIOS sends them to the ISA I/O address 0080h, but,
how can I get that codes using another computer? I mean,  without POST
ISA/PCI card, using another computer connected to it via SMBUS, LPC or
serial?

Is there any way to convert LPC to serial and monitor that port?

I don't know of an easy way. 

I want to do this with a VIA P700 motherboard, is this board supported by
the coreboot v3?

 http://www.coreboot.org/Supported_Motherboards
I don't think so.  Coreboot v2 is the most active branch.

Could be easy to redirect BIOS POST codes to a serial port using a coreboot
implementation?

Coreboot sends debug information to the serial port, so there is no need for
monitoring the POST codes except very early in the boot process. 

Thanks,
Myles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/e57d82b9/attachment.html>

From ciffery at gmail.com  Thu Sep 17 21:58:28 2009
From: ciffery at gmail.com (Ciffo)
Date: Thu, 17 Sep 2009 21:58:28 +0200
Subject: [coreboot] Request for EPIA-LN BIOS
Message-ID: <226be6770909171258t6199e68fp76b650fe89e3413b@mail.gmail.com>

Dear Sirs,
I would like to ask you for full implementation of EPIA-LN BIOS. I haven't
time for study all COREBOOT system.

We will need to jump into system boot (GRUB/LILO) as soon as possible. For
our device will we need only support for IDE flash disks, USB ports, VGA and
audio.

Could you send me complete ROM for this board, which will reach our needs?

Thank you very much for you fast answer.

Best regards,
Jaroslav.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/3c5b105e/attachment.html>

From mylesgw at gmail.com  Thu Sep 17 23:21:55 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 17 Sep 2009 15:21:55 -0600
Subject: [coreboot] BIOS POST codes monitoring in real time from other
	computer
In-Reply-To: <9093716948700549637@unknownmsgid>
References: <-3604913777543925274@unknownmsgid>
	<2831fecf0909171223t8abe706v9f0ba9f78bbea114@mail.gmail.com>
	<9093716948700549637@unknownmsgid>
Message-ID: <2831fecf0909171421x5910b59chcd97e28566834973@mail.gmail.com>

2009/9/17 Antonio Exp?sito <antonio.exposito at ono.com>

>  I have seen the supported motherboard list/status, and there are several
> VIA motherboards with chipsets of the same family but different models.
>
> Is it difficult to adapt one of them to my motherboard? (AMOS-3000 embedded
> computer with P700 motherboard)
>
I would think it would be difficult without documentation.  You can always
try the closest one (as long as you can recover from a bad image!)

Look for the most similar supported board, modify the device tree in
src/mainboard/via/(closest_one)/Config.lb to match your SuperIO,
Northbridge, Southbridge, etc.

> Perhaps I can help, which are the first steps?
>
> Any doc for a new guy?
>
http://www.coreboot.org/FAQ
http://www.coreboot.org/Development_Guidelines

It takes some time to find everything you'll need on the wiki, but it's
worth reading.

Good luck,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090917/4066e80b/attachment.html>

From antonio.exposito at ono.com  Fri Sep 18 09:14:03 2009
From: antonio.exposito at ono.com (=?iso-8859-1?Q?Antonio_Exp=F3sito?=)
Date: Fri, 18 Sep 2009 09:14:03 +0200
Subject: [coreboot] COREBOOT for VIA EPIA P700 (from - BIOS POST codes
	monitoring in real time from other computer)
In-Reply-To: <2831fecf0909171421x5910b59chcd97e28566834973@mail.gmail.com>
References: <-3604913777543925274@unknownmsgid>	
	<2831fecf0909171223t8abe706v9f0ba9f78bbea114@mail.gmail.com>	
	<9093716948700549637@unknownmsgid>
	<2831fecf0909171421x5910b59chcd97e28566834973@mail.gmail.com>
Message-ID: <000001ca382f$9daefdf0$d90cf9d0$@exposito@ono.com>

In the Laptop section of the Coreboot wiki I have seen that VIA is
developing coreboot support for vx700 and vx800 (vx700 drives P700
motherboard).  May I wait some time to see if they get results? Anyone can
give some clues about developing state (ongoing, halted, abandoned,
)

 

Also, I read that VIA is helping the coreboot community support posting
programming guides for CX700M/VX700 and VX800 at the VIA Linux Download
Portal, but I cannot find them!

 

One more thing, how can I know that I am not  going to do something that is
under developing right now by someone? The supported motherboard list is up
to date and people use to report their ongoing work or ideas?

 

Regards,

 

Antonio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090918/045cd05c/attachment.html>

From dangongli at tom.com  Fri Sep 18 11:15:31 2009
From: dangongli at tom.com (=?gb2312?B?ZGFuZ2w=?=)
Date: Fri, 18 Sep 2009 17:15:31 +0800 (CST)
Subject: [coreboot] =?gb2312?b?aG93IHRvIGJ1aWxkIGJpb3MuYmluIHVzZSBxZW11?=
	=?gb2312?b?IGZvciBsaW51eA==?=
Message-ID: <4AB34FB3.00004D.28982@bjapp51>

Hi guys:
   I'am first use this mailing list.
   Now I want to verity the coreboot.So I build a bios.bin,and then I will run it under qemu(for linux),but there are many problems.
   So Can someone give me a guide about how to build the qemu,and then use this qemu to run the bios(bios.bin).
                   Best regards!!!!!
                    Tim dan 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090918/7193de98/attachment.html>

From stepan at coresystems.de  Fri Sep 18 11:52:28 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Fri, 18 Sep 2009 11:52:28 +0200
Subject: [coreboot] how to build bios.bin use qemu for linux
In-Reply-To: <4AB34FB3.00004D.28982@bjapp51>
References: <4AB34FB3.00004D.28982@bjapp51>
Message-ID: <4AB3585C.4040902@coresystems.de>

dangl wrote:
> Hi guys:
> I'am first use this mailing list.
> Now I want to verity the coreboot.So I build a bios.bin,and then I
> will run it under qemu(for linux),but there are many problems.

What problems?


Stefan



From peter at stuge.se  Fri Sep 18 14:32:17 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 18 Sep 2009 14:32:17 +0200
Subject: [coreboot] COREBOOT for VIA EPIA P700 (from - BIOS POST
	codes	monitoring in real time from other computer)
Message-ID: <20090918123217.25248.qmail@stuge.se>

Hi Antonio,

Antonio Exp?sito wrote:
> coreboot support for vx700 and vx800 (vx700 drives P700 motherboard).
> May I wait some time to see if they get results?

vx800 code is supported in coreboot since earlier this year. vx700 I
don't know - but I believe it has many similarities with cx700 which
is supported.


> Anyone can give some clues about developing state (ongoing, halted,
> abandoned,)

Noone is working on the existing code as far as I know. I'm working a
little bit on explicit VX855 support, but there is a lot of
redundancy with VX800. Are you using VX855?


> programming guides for CX700M/VX700 and VX800 at the VIA Linux
> Download Portal, but I cannot find them!

Links are on http://www.coreboot.org/Datasheets


> One more thing, how can I know that I am not going to do something
> that is under developing right now by someone?

Talk to us. The mailing list is a good start, you're also very
welcome to join the IRC channel #coreboot on irc.freenode.net.


> The supported motherboard list is up to date and people use to
> report their ongoing work or ideas?

No, that page is unfortunately not a great progress tracker.


//Peter



From peter at stuge.se  Fri Sep 18 14:58:57 2009
From: peter at stuge.se (Peter Stuge)
Date: Fri, 18 Sep 2009 14:58:57 +0200
Subject: [coreboot] how to build bios.bin use qemu for linux
In-Reply-To: <4AB34FB3.00004D.28982@bjapp51>
References: <4AB34FB3.00004D.28982@bjapp51>
Message-ID: <20090918125857.29929.qmail@stuge.se>

dangl wrote:
> So Can someone give me a guide about how to build the qemu,

How to build QEMU is not a topic for this mailing list.


> and then use this qemu to run the bios(bios.bin).

That should be covered in detail on http://www.coreboot.org/QEMU


If you find omissions or can suggest improvements, you will of course
make them known immediately, so that the next person in your
situation can succeed easier.


//Peter



From mylesgw at gmail.com  Fri Sep 18 19:36:36 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 18 Sep 2009 11:36:36 -0600
Subject: [coreboot] Infinite loop in cbfstool
Message-ID: <9DCFAED3AEBB40FBA8F5D2DACCF432FF@chimp>

If you try to add a payload that is larger than the available space, and not
at a specific location (location == 0), it hangs in an infinite loop.  It's
something like:

if contentsize <= length or location is right {
	insert record
}
if location == 0
	continue.

I wasn't sure where the best place to put the increment of current was.  Do
you have any suggestions?

Thanks,
Myles




From patrick.georgi at coresystems.de  Fri Sep 18 20:04:58 2009
From: patrick.georgi at coresystems.de (Patrick Georgi)
Date: Fri, 18 Sep 2009 20:04:58 +0200
Subject: [coreboot] Infinite loop in cbfstool
In-Reply-To: <9DCFAED3AEBB40FBA8F5D2DACCF432FF@chimp>
References: <9DCFAED3AEBB40FBA8F5D2DACCF432FF@chimp>
Message-ID: <1253297098.29976.116.camel@tetris>

Am Freitag, den 18.09.2009, 11:36 -0600 schrieb Myles Watson:
> If you try to add a payload that is larger than the available space, and not
> at a specific location (location == 0), it hangs in an infinite loop.  It's
> something like:
Good find, thanks!

> if contentsize <= length or location is right {
> 	insert record
> }
> if location == 0
> 	continue.
> 
> I wasn't sure where the best place to put the increment of current was.  Do
> you have any suggestions?
Primitive solution: duplicate the increment? (see patch)

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20090918-1-endless-loop
Type: text/x-patch
Size: 578 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090918/f858e3cb/attachment.diff>

From mylesgw at gmail.com  Fri Sep 18 20:15:04 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Fri, 18 Sep 2009 12:15:04 -0600
Subject: [coreboot] Infinite loop in cbfstool
In-Reply-To: <1253297098.29976.116.camel@tetris>
References: <9DCFAED3AEBB40FBA8F5D2DACCF432FF@chimp>
	<1253297098.29976.116.camel@tetris>
Message-ID: <983F89A8EE484441AEF6B2BE566FA54D@chimp>


> > I wasn't sure where the best place to put the increment of current was.
> Do
> > you have any suggestions?
> Primitive solution: duplicate the increment? (see patch)
That stops the infinite loop, but silently fails to add the payload.  That's
where I first thought of putting it too.

Thanks,
Myles




From technoboy85 at gmail.com  Fri Sep 18 16:42:14 2009
From: technoboy85 at gmail.com (Matteo Croce)
Date: Fri, 18 Sep 2009 16:42:14 +0200
Subject: [coreboot] Alix 3d2
Message-ID: <40101cc30909180742g7bbbf874n328c570895acfb1e@mail.gmail.com>

Hi.
I have an ALIX 3d2: http://pcengines.ch/alix3d2.htm.
I wish to flash it but I fear to brick it as I guess it differs a bit
from the ALIX 2CX on your Wiki.
Anyone had experience with such motherboard?



From svn at coreboot.org  Fri Sep 18 21:26:26 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 18 Sep 2009 21:26:26 +0200
Subject: [coreboot] [BuildROM] r273 - buildrom-devel/packages/mkelfimage
Message-ID: <mailman.3710.1355071619.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-18 21:26:26 +0200 (Fri, 18 Sep 2009)
New Revision: 273

Modified:
   buildrom-devel/packages/mkelfimage/mkelfimage.mk
Log:
Bump the revision of mkelfimage to include high table support.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: buildrom-devel/packages/mkelfimage/mkelfimage.mk
===================================================================
--- buildrom-devel/packages/mkelfimage/mkelfimage.mk	2009-09-04 13:06:59 UTC (rev 272)
+++ buildrom-devel/packages/mkelfimage/mkelfimage.mk	2009-09-18 19:26:26 UTC (rev 273)
@@ -4,7 +4,7 @@
 MKELFIMAGE_LOG_DIR=$(MKELFIMAGE_DIR)/logs
 MKELFIMAGE_PATCHES=
 
-MKELFIMAGE_TAG=3473
+MKELFIMAGE_TAG=4015
 MKELFIMAGE_TARBALL=mkelfimage-svn-$(MKELFIMAGE_TAG).tar.gz
 MKELFIMAGE_URL=svn://coreboot.org/repos/trunk/util/mkelfImage
 




From svn at coreboot.org  Fri Sep 18 21:47:07 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Fri, 18 Sep 2009 21:47:07 +0200
Subject: [coreboot] [BuildROM] r274 - buildrom-devel/packages/mkelfimage
Message-ID: <mailman.3711.1355071619.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-18 21:47:06 +0200 (Fri, 18 Sep 2009)
New Revision: 274

Modified:
   buildrom-devel/packages/mkelfimage/mkelfimage.mk
Log:
Bump the revision of mkelfimage to include support for more sections.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: buildrom-devel/packages/mkelfimage/mkelfimage.mk
===================================================================
--- buildrom-devel/packages/mkelfimage/mkelfimage.mk	2009-09-18 19:26:26 UTC (rev 273)
+++ buildrom-devel/packages/mkelfimage/mkelfimage.mk	2009-09-18 19:47:06 UTC (rev 274)
@@ -4,7 +4,7 @@
 MKELFIMAGE_LOG_DIR=$(MKELFIMAGE_DIR)/logs
 MKELFIMAGE_PATCHES=
 
-MKELFIMAGE_TAG=4015
+MKELFIMAGE_TAG=4645
 MKELFIMAGE_TARBALL=mkelfimage-svn-$(MKELFIMAGE_TAG).tar.gz
 MKELFIMAGE_URL=svn://coreboot.org/repos/trunk/util/mkelfImage
 




From rminnich at gmail.com  Fri Sep 18 22:45:13 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 18 Sep 2009 13:45:13 -0700
Subject: [coreboot] linuxcon 2009
Message-ID: <13426df10909181345n686b14c8ra7207f3b5973a0ea@mail.gmail.com>

if anyone is going, might be fun to have a coreboot install-a-thon. I
can bring some nodes if there's going to be more there than just me.

ron



From rminnich at gmail.com  Sat Sep 19 02:03:46 2009
From: rminnich at gmail.com (ron minnich)
Date: Fri, 18 Sep 2009 17:03:46 -0700
Subject: [coreboot] dell s1850 progress
Message-ID: <13426df10909181703wff4a1d2k1672d702eb6f3fb2@mail.gmail.com>

Well, we're getting serial out now.

coreboot-2.0.0-r.0Fallback Fri Sep 18 16:51:15 PDT 2009 starting...
PCI: 00:00.00
PCI: 00:10.00
PCI: 0f:00.00
PCI: 0f:10.00
SMBus controller enabled

so we own it. There's a missing smbus controller, a few more bits to
work out, but given that we support this chipset, I've only bricked  6
nodes, there are 4500 left to go, this ought to be doable.

I can't wait to get rid of this factory bios. There is just so much it
does wrong ...

ron



From oregon.mick at gmail.com  Sun Sep 20 01:42:07 2009
From: oregon.mick at gmail.com (Mick Reed)
Date: Sat, 19 Sep 2009 16:42:07 -0700
Subject: [coreboot] Build question - coreboot v2 - filo - buildrom tree
	relationship
Message-ID: <d0bd00bf0909191642i805a282x8d8c004d33f81bdb@mail.gmail.com>

I'm trying to build a coreboot-filo-grub bios for my Tyan s2885.  I
downloaded svn trees of coreboot-v2, filo-trunk, and buildrom-devel.
I followed the tutorial for the Tyan s2882.  I'm having some build
problems, and I wonder if I was supposed to put the filo tree or the
buildrom tree inside the coreboot tree in order to get it build.

I can give more details of my issues, but I would like to straighten
this question out first, and RTFM some more before asking for more
newbie help.  Thanks for any input!

Mick Reed



From peter at stuge.se  Sun Sep 20 03:51:24 2009
From: peter at stuge.se (Peter Stuge)
Date: Sun, 20 Sep 2009 03:51:24 +0200
Subject: [coreboot] Build question - coreboot v2 - filo - buildrom
	tree	relationship
In-Reply-To: <d0bd00bf0909191642i805a282x8d8c004d33f81bdb@mail.gmail.com>
References: <d0bd00bf0909191642i805a282x8d8c004d33f81bdb@mail.gmail.com>
Message-ID: <20090920015124.18718.qmail@stuge.se>

Mick Reed wrote:
> I wonder if I was supposed to put the filo tree or the buildrom
> tree inside the coreboot tree in order to get it build.

Aha. Two ways to move forward:

Either using buildrom only, it will download trees into directories,
configure and build automatically.

Or manually building each component. For current FILO you also need
libpayload. FILO and coreboot can be built separately, but libpayload
goes in a subdirectory in the main FILO directory. Build FILO first,
to get filo.elf. Then reference this in coreboot
targets/vendor/board/Config.lb, then run ./buildtarget vendor/board
in targets/, then run make in
targets/vendor/board/vendorboarddiretorycreatedbybuildtarget
This make step will create coreboot.rom

Or if your board is supported, you can use Kconfig. Build FILO as per
above. Then cd into coreboot-v2, and run make menuconfig. Make
settings, exit, then run make, which creates build/coreboot.rom

Kconfig is brand new and not working for many boards, but maybe yours
is one of the lucky ones - and if not - maybe you can help with
getting it to work? :)


//Peter



From joe at settoplinux.org  Mon Sep 21 13:08:26 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 21 Sep 2009 07:08:26 -0400
Subject: [coreboot] dell s1850 progress
In-Reply-To: <13426df10909181703wff4a1d2k1672d702eb6f3fb2@mail.gmail.com>
References: <13426df10909181703wff4a1d2k1672d702eb6f3fb2@mail.gmail.com>
Message-ID: <cdddc83c18bea1b6721914be3f328f39@imap.1and1.com>




On Fri, 18 Sep 2009 17:03:46 -0700, ron minnich <rminnich at gmail.com> wrote:
> Well, we're getting serial out now.
> 
> coreboot-2.0.0-r.0Fallback Fri Sep 18 16:51:15 PDT 2009 starting...
> PCI: 00:00.00
> PCI: 00:10.00
> PCI: 0f:00.00
> PCI: 0f:10.00
> SMBus controller enabled
> 
> so we own it. There's a missing smbus controller, a few more bits to
> work out, but given that we support this chipset, I've only bricked  6
> nodes, there are 4500 left to go, this ought to be doable.
> 
> I can't wait to get rid of this factory bios. There is just so much it
> does wrong ...
> 

Sweet, great work Ron :-)

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Mon Sep 21 17:12:19 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 21 Sep 2009 09:12:19 -0600
Subject: [coreboot] USB POST card
Message-ID: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>

http://www.nowthatsit.nl/?c=447&i=8877

Has anyone used one of these?  I'm wondering how well they work, if they
could replace the serial port on a board that didn't have one, etc.

You can find them for about $10 on ebay.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090921/55bb293d/attachment.html>

From joe at settoplinux.org  Mon Sep 21 17:41:52 2009
From: joe at settoplinux.org (Joseph Smith)
Date: Mon, 21 Sep 2009 11:41:52 -0400
Subject: [coreboot] USB POST card
In-Reply-To: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
Message-ID: <b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>




On Mon, 21 Sep 2009 09:12:19 -0600, Myles Watson <mylesgw at gmail.com> wrote:
> http://www.nowthatsit.nl/?c=447&i=8877
> 
> Has anyone used one of these?  I'm wondering how well they work, if they
> could replace the serial port on a board that didn't have one, etc.
> 
> You can find them for about $10 on ebay.
> 
Myles,
I have one similar, and the USB is just used as power for the the LPT port.
-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org




From mylesgw at gmail.com  Mon Sep 21 17:44:20 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 21 Sep 2009 09:44:20 -0600
Subject: [coreboot] USB POST card
In-Reply-To: <b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
Message-ID: <3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>

> > http://www.nowthatsit.nl/?c=447&i=8877
> >
> > Has anyone used one of these?  I'm wondering how well they work, if they
> > could replace the serial port on a board that didn't have one, etc.
> >
> > You can find them for about $10 on ebay.
> >
> Myles,
> I have one similar, and the USB is just used as power for the the LPT
> port.
Too bad.  I was afraid of that.  Thanks for saving me $10.

Myles




From peter at stuge.se  Mon Sep 21 17:48:46 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Sep 2009 17:48:46 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
Message-ID: <20090921154846.1414.qmail@stuge.se>

Myles Watson wrote:
> Thanks for saving me $10.

The only USB option is a Debug Class device. The Debug Class specs a
USB->USB device, but it would also be possible to just implement the
USB side which connects to the target, and have a different host
interface.

The only Debug Class device I know of is the little blue NET20DC from
PLX.


//Peter



From mylesgw at gmail.com  Mon Sep 21 17:55:43 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Mon, 21 Sep 2009 09:55:43 -0600
Subject: [coreboot] USB POST card
In-Reply-To: <20090921154846.1414.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
Message-ID: <2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>

On Mon, Sep 21, 2009 at 9:48 AM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > Thanks for saving me $10.
>
> The only USB option is a Debug Class device. The Debug Class specs a
> USB->USB device, but it would also be possible to just implement the
> USB side which connects to the target, and have a different host
> interface.
>
> The only Debug Class device I know of is the little blue NET20DC from
> PLX.
>
I was hoping for a PCI POST card that buffered codes so that they could be
read from another computer by USB.  Then it wouldn't depend on working USB
or serial, just port 0x80.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090921/f2955f43/attachment.html>

From bari at onelabs.com  Mon Sep 21 17:56:48 2009
From: bari at onelabs.com (bari)
Date: Mon, 21 Sep 2009 10:56:48 -0500
Subject: [coreboot] USB POST card
In-Reply-To: <20090921154846.1414.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
Message-ID: <4AB7A240.7070908@onelabs.com>

Peter Stuge wrote:

> The only Debug Class device I know of is the little blue NET20DC from
> PLX.
> 

It appears that Ajays Technology, LLC now makes the Net20

http://www.ajaystech.com/net20dc.htm

http://www.semiconductorstore.com/cart/pc/viewPrd.asp?idproduct=12083

In case anyone is still trying to find them.

-Bari



From andrew.goodbody at tadpole.com  Mon Sep 21 18:02:44 2009
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Mon, 21 Sep 2009 17:02:44 +0100
Subject: [coreboot] USB POST card
In-Reply-To: <20090921154846.1414.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
Message-ID: <4AB7A3A4.1040503@tadpole.com>

Peter Stuge wrote:
> The only Debug Class device I know of is the little blue NET20DC from
> PLX.

AMI Debug Rx, info on the AMI site, direct links don't work. You're
supposed to be able to buy it without the enhanced debug transport
enabled so you just get the generic debug class device when in that
mode. It's probably very pricey, well out of range of most hobbyists
though. I have not seen any public specs on how the POST codes work either.

Andrew




From andrew.goodbody at tadpole.com  Mon Sep 21 18:10:01 2009
From: andrew.goodbody at tadpole.com (Andrew Goodbody)
Date: Mon, 21 Sep 2009 17:10:01 +0100
Subject: [coreboot] USB POST card
In-Reply-To: <2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>	<20090921154846.1414.qmail@stuge.se>
	<2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>
Message-ID: <4AB7A559.9040808@tadpole.com>

Myles Watson wrote:
> I was hoping for a PCI POST card that buffered codes so that they could 
> be read from another computer by USB.  Then it wouldn't depend on 
> working USB or serial, just port 0x80.

The USB debug port requires much less support than full blown USB and so 
can be used in restricted environments. PCI seems to be going away and 
even when it is present port 80h does not always work by default, it can 
need configuring.

Support for passing POST codes or even progress strings over USB debug 
devices would be very useful indeed.

Andrew



From peter at stuge.se  Mon Sep 21 18:57:38 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Sep 2009 18:57:38 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <4AB7A559.9040808@tadpole.com>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
	<2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>
	<4AB7A559.9040808@tadpole.com>
Message-ID: <20090921165738.15256.qmail@stuge.se>

Andrew Goodbody wrote:
> Support for passing POST codes or even progress strings over USB
> debug devices would be very useful indeed.

coreboot does support this since a few years already.


//Peter



From stepan at coresystems.de  Mon Sep 21 19:59:52 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 21 Sep 2009 19:59:52 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <20090921154846.1414.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
Message-ID: <4AB7BF18.6070902@coresystems.de>

Peter Stuge wrote:
> Myles Watson wrote:
>   
>> Thanks for saving me $10.
>>     
>
> The only USB option is a Debug Class device. The Debug Class specs a
> USB->USB device, but it would also be possible to just implement the
> USB side which connects to the target, and have a different host
> interface.
>   
Or the Artec LPC dongle - it can transport POST codes via usb-serial
from the target... For someone with VHDL knowledge it might be possible
to add a "fake serial port" to the dongle.






From stepan at coresystems.de  Mon Sep 21 20:02:20 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 21 Sep 2009 20:02:20 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <20090921165738.15256.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>	<20090921154846.1414.qmail@stuge.se>	<2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>	<4AB7A559.9040808@tadpole.com>
	<20090921165738.15256.qmail@stuge.se>
Message-ID: <4AB7BFAC.4010509@coresystems.de>

Peter Stuge wrote:
> Andrew Goodbody wrote:
>   
>> Support for passing POST codes or even progress strings over USB
>> debug devices would be very useful indeed.
>>     
>
> coreboot does support this since a few years already.
>   
On some chipsets... There is a certain amount of (non-trivial) chipset
specific setup.




From peter at stuge.se  Mon Sep 21 20:19:14 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Sep 2009 20:19:14 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <4AB7BFAC.4010509@coresystems.de>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
	<2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>
	<4AB7A559.9040808@tadpole.com>
	<20090921165738.15256.qmail@stuge.se>
	<4AB7BFAC.4010509@coresystems.de>
Message-ID: <20090921181914.31593.qmail@stuge.se>

Stefan Reinauer wrote:
> > coreboot does support this since a few years already.
> 
> On some chipsets... There is a certain amount of (non-trivial)
> chipset specific setup.

What's that?

EHCI is always the same, but is there stuff to do so the EHC is
reachable?


//Peter



From peter at stuge.se  Mon Sep 21 20:26:34 2009
From: peter at stuge.se (Peter Stuge)
Date: Mon, 21 Sep 2009 20:26:34 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <4AB7BF18.6070902@coresystems.de>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>
	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>
	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>
	<20090921154846.1414.qmail@stuge.se>
	<4AB7BF18.6070902@coresystems.de>
Message-ID: <20090921182634.1402.qmail@stuge.se>

Stefan Reinauer wrote:
> > The only USB option is a Debug Class device.
> 
> Or the Artec LPC dongle - 

Sorry, I meant for USB connection to system being debugged. :)


> it can transport POST codes via usb-serial from the target... For
> someone with VHDL knowledge it might be possible to add a "fake
> serial port" to the dongle.

The way to get data out that I like the best is to use
reads-mean-write, where a sequence of reading from certain addresses
sends the lowest byte of the last read address via USB to the host
and the user.

Unfortunately, the dongle is already a serial device so it is
difficult to create another serial port. That would be done using a
kernel line discipline.

Ideally, the USB descriptors and USB firmware in the dongle could be
changed instead, which would allow for more channels besides the
current communication.

But I don't think it's doable with the FTDI USB chips, they are much
too simple.

It would of course be possible to use the existing USB-serial
channel, just that the dongle would need to be reset before the next
reprogram, once it has entered the reads-mean-write mode. That might
be OK.


//Peter



From stepan at coresystems.de  Mon Sep 21 23:27:15 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Mon, 21 Sep 2009 23:27:15 +0200
Subject: [coreboot] USB POST card
In-Reply-To: <20090921181914.31593.qmail@stuge.se>
References: <2831fecf0909210812x3e36d6adybdd85b9086f7a9e@mail.gmail.com>	<b3adcfdf03b04b1c69cd8fd272712575@imap.1and1.com>	<3BD9DB0E4BDD423FBF2814664FF5CA92@chimp>	<20090921154846.1414.qmail@stuge.se>	<2831fecf0909210855w5669a664ncdef499bd5f94395@mail.gmail.com>	<4AB7A559.9040808@tadpole.com>	<20090921165738.15256.qmail@stuge.se>	<4AB7BFAC.4010509@coresystems.de>
	<20090921181914.31593.qmail@stuge.se>
Message-ID: <4AB7EFB3.2090507@coresystems.de>

Peter Stuge wrote:
> Stefan Reinauer wrote:
>   
>>> coreboot does support this since a few years already.
>>>       
>> On some chipsets... There is a certain amount of (non-trivial)
>> chipset specific setup.
>>     
>
> What's that?
>
> EHCI is always the same, but is there stuff to do so the EHC is
> reachable?
>   

I have not figured it out yet. Our code is not working on Intel ICH,
however. Grep the southbridge directories for usbdebug...

Stefan




From svn at coreboot.org  Tue Sep 22 02:09:41 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 02:09:41 +0200
Subject: [coreboot] [v2] r4646 - in trunk/coreboot-v2/src: arch/i386/lib
	devices include/device
Message-ID: <mailman.3712.1355071619.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-09-22 02:09:41 +0200 (Tue, 22 Sep 2009)
New Revision: 4646

Modified:
   trunk/coreboot-v2/src/arch/i386/lib/pci_ops_auto.c
   trunk/coreboot-v2/src/devices/pci_ops.c
   trunk/coreboot-v2/src/include/device/pci.h
   trunk/coreboot-v2/src/include/device/pci_ops.h
Log:
If no pci access method has been set for the device tree so far (e.g.
during early coreboot_ram), pci_{read,write}_config{8,16,32} will die().
This patch changes pci_{read,write}_config{8,16,32} to use the existing
PCI access method autodetection infrastructure instead of die()ing.

Until r4340, any usage of pci_{read,write}_config{8,16,32} in
coreboot_ram before the device tree was set up resulted in either a
silent hang or a NULL pointer dereference. I changed the code in r4340
to die() properly with a loud error message. That still was not perfect,
but at least it allowed people to see why their new ports died.
Still, die() is not something developers like to see, and thus a patch
to automatically pick a sensible default instead of dying was created.
Of course, handling PCI access method selection automatically for
fallback purposes has certain limitations before the device tree is set
up. We only check if conf1 works and use conf2 as fallback. No further
tests are done.

This patch enables cleanups and readability improvements in early
coreboot_ram code:
Without this patch:
dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
        sm_dev->path.pci.devfn, 0x64);
With this patch:
dword = pci_read_config32(sm_dev, 0x64);

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/arch/i386/lib/pci_ops_auto.c
===================================================================
--- trunk/coreboot-v2/src/arch/i386/lib/pci_ops_auto.c	2009-09-17 18:30:23 UTC (rev 4645)
+++ trunk/coreboot-v2/src/arch/i386/lib/pci_ops_auto.c	2009-09-22 00:09:41 UTC (rev 4646)
@@ -41,6 +41,8 @@
 	return 0;
 }
 
+struct pci_bus_operations *pci_bus_fallback_ops = NULL;
+
 const struct pci_bus_operations *pci_check_direct(void)
 {
 	unsigned int tmp;
@@ -81,11 +83,18 @@
 	return NULL;
 }
 
+const struct pci_bus_operations *pci_remember_direct(void)
+{
+	if (!pci_bus_fallback_ops)
+		pci_bus_fallback_ops = pci_check_direct();
+	return pci_bus_fallback_ops;
+}
+
 /** Set the method to be used for PCI, type I or type II
  */
 void pci_set_method(device_t dev)
 {
 	printk_info("Finding PCI configuration type.\n");
-	dev->ops->ops_pci_bus = pci_check_direct();
+	dev->ops->ops_pci_bus = pci_remember_direct();
 	post_code(0x5f);
 }

Modified: trunk/coreboot-v2/src/devices/pci_ops.c
===================================================================
--- trunk/coreboot-v2/src/devices/pci_ops.c	2009-09-17 18:30:23 UTC (rev 4645)
+++ trunk/coreboot-v2/src/devices/pci_ops.c	2009-09-22 00:09:41 UTC (rev 4646)
@@ -25,6 +25,9 @@
 #include <device/pci_ids.h>
 #include <device/pci_ops.h>
 
+/* The only consumer of the return value of get_pbus() is ops_pci_bus().
+ * ops_pci_bus() can handle being passed NULL and auto-picks working ops.
+ */
 static struct bus *get_pbus(device_t dev)
 {
 	struct bus *pbus = NULL;
@@ -44,8 +47,9 @@
 		pbus = pbus->dev->bus;
 	}
 	if (!pbus || !pbus->dev || !pbus->dev->ops || !pbus->dev->ops->ops_pci_bus) {
-		printk_emerg("%s: Cannot find pci bus operations.\n", dev_path(dev));
-		die("");
+		/* This can happen before the device tree is set up completely. */
+		//printk_emerg("%s: Cannot find pci bus operations.\n", dev_path(dev));
+		pbus = NULL;
 	}
 	return pbus;
 }

Modified: trunk/coreboot-v2/src/include/device/pci.h
===================================================================
--- trunk/coreboot-v2/src/include/device/pci.h	2009-09-17 18:30:23 UTC (rev 4645)
+++ trunk/coreboot-v2/src/include/device/pci.h	2009-09-22 00:09:41 UTC (rev 4646)
@@ -97,6 +97,8 @@
 	if (bus && bus->dev && bus->dev->ops) {
 		bops = bus->dev->ops->ops_pci_bus;
 	}
+	if (!bops)
+		bops = pci_remember_direct();
 	return bops;
 }
 

Modified: trunk/coreboot-v2/src/include/device/pci_ops.h
===================================================================
--- trunk/coreboot-v2/src/include/device/pci_ops.h	2009-09-17 18:30:23 UTC (rev 4645)
+++ trunk/coreboot-v2/src/include/device/pci_ops.h	2009-09-22 00:09:41 UTC (rev 4646)
@@ -21,4 +21,7 @@
 void pci_mmio_write_config32(device_t dev, unsigned where, uint32_t val);
 #endif
 
+/* This function lives in pci_ops_auto.c */
+const struct pci_bus_operations *pci_remember_direct(void);
+
 #endif /* PCI_OPS_H */




From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 02:12:25 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 02:12:25 +0200
Subject: [coreboot] [PATCH] Auto-pick working PCI ops if none are set
In-Reply-To: <4A9716B5.1000503@gmx.net>
References: <4A9716B5.1000503@gmx.net>
Message-ID: <4AB81669.9000603@gmx.net>

On 28.08.2009 01:28, Carl-Daniel Hailfinger wrote:
> Until r4340, any usage of pci_{read,write}_config{8,16,32} in
> coreboot_ram before the device tree was set up resulted in either a
> silent hang or a NULL pointer dereference. I changed the code in r4340
> to die() properly with a loud error message. That still was not perfect,
> but at least it allowed people to see why their new ports died.
> Still, die() is not something developers like to see, and thus a patch
> to automatically pick a sensible default instead of dying was created.
> Of course, handling PCI access method selection automatically for
> fallback purposes has certain limitations before the device tree is set
> up. We only check if conf1 works and use conf2 as fallback. No further
> tests are done.
>
> This patch enables cleanups and readability improvements in early
> coreboot_ram code:
> Without this patch:
> dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
> sm_dev->path.pci.devfn, 0x64);
> With this patch:
> dword = pci_read_config32(sm_dev, 0x64);
> The advantage is obvious.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Peter asked for a short summary what the patch does. This it it:
If no pci access method has been set for the device tree so far (e.g.
during early coreboot_ram), pci_{read,write}_config{8,16,32} will die().
This patch changes pci_{read,write}_config{8,16,32} to use the existing
PCI access method autodetection infrastructure instead of die()ing.

Acked-by: Peter Stuge <peter at stuge.se>

and committed in r4646.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From info at coresystems.de  Tue Sep 22 02:32:40 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 02:32:40 +0200
Subject: [coreboot] build service results for r4646
Message-ID: <E1MptJA-00039I-51@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "hailfinger" checked in revision 4646 to
the coreboot repository. This caused the following 
changes:

Change Log:
If no pci access method has been set for the device tree so far (e.g.
during early coreboot_ram), pci_{read,write}_config{8,16,32} will die().
This patch changes pci_{read,write}_config{8,16,32} to use the existing
PCI access method autodetection infrastructure instead of die()ing.

Until r4340, any usage of pci_{read,write}_config{8,16,32} in
coreboot_ram before the device tree was set up resulted in either a
silent hang or a NULL pointer dereference. I changed the code in r4340
to die() properly with a loud error message. That still was not perfect,
but at least it allowed people to see why their new ports died.
Still, die() is not something developers like to see, and thus a patch
to automatically pick a sensible default instead of dying was created.
Of course, handling PCI access method selection automatically for
fallback purposes has certain limitations before the device tree is set
up. We only check if conf1 works and use conf2 as fallback. No further
tests are done.

This patch enables cleanups and readability improvements in early
coreboot_ram code:
Without this patch:
dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
        sm_dev->path.pci.devfn, 0x64);
With this patch:
dword = pci_read_config32(sm_dev, 0x64);

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of embeddedplanet:ep405pc has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4646&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4646&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq has been broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4646&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 02:46:52 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 02:46:52 +0200
Subject: [coreboot] Patchwork update script
Message-ID: <4AB81E7C.1040903@gmx.net>

Hi,

here's the script I'm using to set the status of flashrom patches in
patchwork to "Accepted".
The web interface only allows you to set the status, but it does not
allow you to set a commit ID. With pwclient (part of patchwork) you can
do that.

My script simply retrieves a patch (-p0) for a given numeric commit ID
(without leading r), hashes it with the special patchwork hash (which is
somewhat tolerant of context and order changes), then uses pwclient to
set the patch status for that hash to "Accepted" and the commit ID to "r$1".
If the patch (-p0) can't be found, it retrieves a patch (-p1) for the
commit ID.

Usage:
update-patchwork 1234

You might want to adjust a few paths for coreboot usage and for your
local installation.

Requirements for this script:
- A local patchwork source (or installation)
- ~/.pwclientrc (downloaded from the patchwork web interface)

Where can you get .pwclientrc?
Go to http://patchwork.coreboot.org/project/ and log in. Then click on
your preferred project, then click on "project info". There you find:
"Sample patchwork client configuration for this project: .pwclientrc."
Download .pwclientrc and fill in your patchwork password, then store it
in your $HOME.

I hope this helps others reduce patchwork maintenance efforts.

Regards,
Carl-Daniel

#!/bin/bash
# Install this script as update-patchwork in your $PATH
# and call it with the revision number as parameter.
test -z "$1" && { echo "No revision provided."; exit 1; }
revision="$1"
hashcand=$(svn diff -c $revision svn://coreboot.org/flashrom/trunk/|python /sources/tmptrees/patchwork/apps/patchwork/parser.py --hash)
/sources/tmptrees/patchwork/apps/patchwork/bin/pwclient update -s Accepted -c r$revision -h $hashcand && { echo "done"; exit 0; }
echo
hashcand=$(svn diff -c $revision svn://coreboot.org/flashrom/|python /sources/tmptrees/patchwork/apps/patchwork/parser.py --hash)
/sources/tmptrees/patchwork/apps/patchwork/bin/pwclient update -s Accepted -c r$revision -h $hashcand && { echo "done"; exit 0; }
echo "No matching patch in patchwork found."
exit 1


-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 02:58:10 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 02:58:10 +0200
Subject: [coreboot] [PATCH] amd/pistachio and
 technexion/tim8960	devicetree.cb comments
In-Reply-To: <4A982B65.9000400@gmx.net>
References: <4A982B65.9000400@gmx.net>
Message-ID: <4AB82122.1040704@gmx.net>

On 28.08.2009 21:09, Carl-Daniel Hailfinger wrote:
> r4534 introduced devicetree.cb in every mainboard directory, but didn't
> copy any comment lines before the start of the device tree.
> Fix up amd/pistachio and technexion/tim8960.
>
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>   

Ping?
This is a documentation-only patch and should be safe.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 03:41:56 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 03:41:56 +0200
Subject: [coreboot] [PATCH] Clean up PCI ops in AMD 690 boards
Message-ID: <4AB82B64.1020004@gmx.net>

r4646 enabled early usage of pci_{read,write}_config{8,16,32}

This allows us to change
dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
        sm_dev->path.pci.devfn, 0x64);

to the much more readable
dword = pci_read_config32(sm_dev, 0x64);

Clean up all PCI operations in mainboards based on AMD 690.

Boot tested on Asus M2A-VM which is a slightly modified AMD DBM690T.
Build tested on all targets. (cbfstool hangs in an endless loop for
the technexion board.)

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/mainboard.c	(Revision 4646)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/pistachio/mainboard.c	(Arbeitskopie)
@@ -83,7 +83,6 @@
 	u16 word;
 	u32 dword;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set adt7475 */
 	ADT7475_write_byte(0x40, 0x04);
@@ -167,28 +166,19 @@
 
 	/* GPM5 as GPIO not USB OC */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	dword =
-	    pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x64);
+	dword = pci_read_config32(sm_dev, 0x64);
 	dword |= 1 << 19;
-	pci_cf8_conf1.write32(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x64, dword);
+	pci_write_config32(sm_dev, 0x64, dword);
 
 	/* Enable Client Management Index/Data registers */
-	dword =
-	    pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x78);
+	dword = pci_read_config32(sm_dev, 0x78);
 	dword |= 1 << 11;	/* Cms_enable */
-	pci_cf8_conf1.write32(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x78, dword);
+	pci_write_config32(sm_dev, 0x78, dword);
 
 	/* MiscfuncEnable */
-	byte =
-	    pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary,
-				sm_dev->path.pci.devfn, 0x41);
+	byte = pci_read_config8(sm_dev, 0x41);
 	byte |= (1 << 5);
-	pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary,
-			     sm_dev->path.pci.devfn, 0x41, byte);
+	pci_write_config8(sm_dev, 0x41, byte);
 
 	/* set GPM5 as input */
 	/* set index register 0C50h to 13h (miscellaneous control) */
@@ -228,12 +218,9 @@
 	pm2_iowrite(0x42, byte);
 
 	/* set GPIO 64 to input */
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c	(Revision 4646)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/amd/dbm690t/mainboard.c	(Arbeitskopie)
@@ -97,32 +97,24 @@
 static void get_ide_dma66()
 {
 	u8 byte;
-	/*u32 sm_dev, ide_dev; */
-	device_t sm_dev, ide_dev;
-	struct bus pbus;
+	struct device *sm_dev;
+	struct device *ide_dev;
 
+	printk_info("%s.\n", __func__);
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
 
-	byte =
-	    pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary,
-				sm_dev->path.pci.devfn, 0xA9);
+	byte = pci_read_config8(sm_dev, 0xA9);
 	byte |= (1 << 5);	/* Set Gpio9 as input */
-	pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary,
-			     sm_dev->path.pci.devfn, 0xA9, byte);
+	pci_write_config8(sm_dev, 0xA9, byte);
 
 	ide_dev = dev_find_slot(0, PCI_DEVFN(0x14, 1));
-	byte =
-	    pci_cf8_conf1.read8(&pbus, ide_dev->bus->secondary,
-				ide_dev->path.pci.devfn, 0x56);
+	byte = pci_read_config8(ide_dev, 0x56);
 	byte &= ~(7 << 0);
-	if ((1 << 5) & pci_cf8_conf1.
-	    read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn,
-		  0xAA))
+	if ((1 << 5) & pci_read_config8(sm_dev, 0xAA))
 		byte |= 2 << 0;	/* mode 2 */
 	else
 		byte |= 5 << 0;	/* mode 5 */
-	pci_cf8_conf1.write8(&pbus, ide_dev->bus->secondary,
-			     ide_dev->path.pci.devfn, 0x56, byte);
+	pci_write_config8(ide_dev, 0x56, byte);
 }
 
 /*
@@ -133,7 +125,6 @@
 	u8 byte;
 	u16 word;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set ADT 7461 */
 	ADT7461_write_byte(0x0B, 0x50);	/* Local Temperature Hight limit */
@@ -156,12 +147,9 @@
 
 	/* set GPIO 64 to input */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);
--- LinuxBIOSv2-asus_m2a-vm/src/mainboard/technexion/tim8690/mainboard.c	(Revision 4646)
+++ LinuxBIOSv2-asus_m2a-vm/src/mainboard/technexion/tim8690/mainboard.c	(Arbeitskopie)
@@ -59,16 +59,15 @@
 
        u8 byte;
        device_t sm_dev;
-       struct bus pbus;
 
 
        printk_info("enable_onboard_nic.\n");
 
        sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
 
-       byte= pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0x9a);
+       byte = pci_read_config8(sm_dev, 0x9a);
        byte |= ( 1 << 7);
-       pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0x9a,byte);
+       pci_write_config8(sm_dev, 0x9a, byte);
 
 
        byte=pm_ioread(0x59);
@@ -76,10 +75,10 @@
        pm_iowrite(0x59,byte);
 
 
-       byte = pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0xA8);
+       byte = pci_read_config8(sm_dev, 0xA8);
 
        byte |= (1 << 1); //set bit 1 to high
-       pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0xA8, byte);
+       pci_write_config8(sm_dev, 0xA8, byte);
 }
 
 /* set thermal config
@@ -89,7 +88,6 @@
 	u8 byte;
 	u16 word;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set ADT 7461 */
 	ADT7461_write_byte(0x0B, 0x50);	/* Local Temperature Hight limit */
@@ -112,12 +110,9 @@
 
 	/* set GPIO 64 to input */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);


-- 
http://www.hailfinger.org/




From peter at stuge.se  Tue Sep 22 04:10:36 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Sep 2009 04:10:36 +0200
Subject: [coreboot] [PATCH] amd/pistachio and
	technexion/tim8960	devicetree.cb comments
In-Reply-To: <4AB82122.1040704@gmx.net>
References: <4A982B65.9000400@gmx.net> <4AB82122.1040704@gmx.net>
Message-ID: <20090922021036.23265.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> Ping?
> This is a documentation-only patch and should be safe.

It's trivial. Go ahead and commit. Use my ack if you want.


//Peter



From peter at stuge.se  Tue Sep 22 04:13:45 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Sep 2009 04:13:45 +0200
Subject: [coreboot] [PATCH] Clean up PCI ops in AMD 690 boards
In-Reply-To: <4AB82B64.1020004@gmx.net>
References: <4AB82B64.1020004@gmx.net>
Message-ID: <20090922021345.23809.qmail@stuge.se>

Carl-Daniel Hailfinger wrote:
> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Tue Sep 22 11:43:25 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 11:43:25 +0200
Subject: [coreboot] [v2] r4647 - in trunk/coreboot-v2/src/mainboard:
	amd/dbm690t amd/pistachio technexion/tim8690
Message-ID: <mailman.3713.1355071619.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-09-22 11:43:25 +0200 (Tue, 22 Sep 2009)
New Revision: 4647

Modified:
   trunk/coreboot-v2/src/mainboard/amd/dbm690t/mainboard.c
   trunk/coreboot-v2/src/mainboard/amd/pistachio/mainboard.c
   trunk/coreboot-v2/src/mainboard/technexion/tim8690/mainboard.c
Log:
r4646 enabled early usage of pci_{read,write}_config{8,16,32}

This allows us to change
dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
        sm_dev->path.pci.devfn, 0x64);

to the much more readable
dword = pci_read_config32(sm_dev, 0x64);

Clean up all PCI operations in mainboards based on AMD 690:
amd/pistachio
amd/dbm690t
technexion/tim8690

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/mainboard/amd/dbm690t/mainboard.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/dbm690t/mainboard.c	2009-09-22 00:09:41 UTC (rev 4646)
+++ trunk/coreboot-v2/src/mainboard/amd/dbm690t/mainboard.c	2009-09-22 09:43:25 UTC (rev 4647)
@@ -97,32 +97,24 @@
 static void get_ide_dma66()
 {
 	u8 byte;
-	/*u32 sm_dev, ide_dev; */
-	device_t sm_dev, ide_dev;
-	struct bus pbus;
+	struct device *sm_dev;
+	struct device *ide_dev;
 
+	printk_info("%s.\n", __func__);
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
 
-	byte =
-	    pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary,
-				sm_dev->path.pci.devfn, 0xA9);
+	byte = pci_read_config8(sm_dev, 0xA9);
 	byte |= (1 << 5);	/* Set Gpio9 as input */
-	pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary,
-			     sm_dev->path.pci.devfn, 0xA9, byte);
+	pci_write_config8(sm_dev, 0xA9, byte);
 
 	ide_dev = dev_find_slot(0, PCI_DEVFN(0x14, 1));
-	byte =
-	    pci_cf8_conf1.read8(&pbus, ide_dev->bus->secondary,
-				ide_dev->path.pci.devfn, 0x56);
+	byte = pci_read_config8(ide_dev, 0x56);
 	byte &= ~(7 << 0);
-	if ((1 << 5) & pci_cf8_conf1.
-	    read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn,
-		  0xAA))
+	if ((1 << 5) & pci_read_config8(sm_dev, 0xAA))
 		byte |= 2 << 0;	/* mode 2 */
 	else
 		byte |= 5 << 0;	/* mode 5 */
-	pci_cf8_conf1.write8(&pbus, ide_dev->bus->secondary,
-			     ide_dev->path.pci.devfn, 0x56, byte);
+	pci_write_config8(ide_dev, 0x56, byte);
 }
 
 /*
@@ -133,7 +125,6 @@
 	u8 byte;
 	u16 word;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set ADT 7461 */
 	ADT7461_write_byte(0x0B, 0x50);	/* Local Temperature Hight limit */
@@ -156,12 +147,9 @@
 
 	/* set GPIO 64 to input */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);

Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/mainboard.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/mainboard.c	2009-09-22 00:09:41 UTC (rev 4646)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/mainboard.c	2009-09-22 09:43:25 UTC (rev 4647)
@@ -83,7 +83,6 @@
 	u16 word;
 	u32 dword;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set adt7475 */
 	ADT7475_write_byte(0x40, 0x04);
@@ -167,28 +166,19 @@
 
 	/* GPM5 as GPIO not USB OC */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	dword =
-	    pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x64);
+	dword = pci_read_config32(sm_dev, 0x64);
 	dword |= 1 << 19;
-	pci_cf8_conf1.write32(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x64, dword);
+	pci_write_config32(sm_dev, 0x64, dword);
 
 	/* Enable Client Management Index/Data registers */
-	dword =
-	    pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x78);
+	dword = pci_read_config32(sm_dev, 0x78);
 	dword |= 1 << 11;	/* Cms_enable */
-	pci_cf8_conf1.write32(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x78, dword);
+	pci_write_config32(sm_dev, 0x78, dword);
 
 	/* MiscfuncEnable */
-	byte =
-	    pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary,
-				sm_dev->path.pci.devfn, 0x41);
+	byte = pci_read_config8(sm_dev, 0x41);
 	byte |= (1 << 5);
-	pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary,
-			     sm_dev->path.pci.devfn, 0x41, byte);
+	pci_write_config8(sm_dev, 0x41, byte);
 
 	/* set GPM5 as input */
 	/* set index register 0C50h to 13h (miscellaneous control) */
@@ -228,12 +218,9 @@
 	pm2_iowrite(0x42, byte);
 
 	/* set GPIO 64 to input */
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);

Modified: trunk/coreboot-v2/src/mainboard/technexion/tim8690/mainboard.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/technexion/tim8690/mainboard.c	2009-09-22 00:09:41 UTC (rev 4646)
+++ trunk/coreboot-v2/src/mainboard/technexion/tim8690/mainboard.c	2009-09-22 09:43:25 UTC (rev 4647)
@@ -59,16 +59,15 @@
 
        u8 byte;
        device_t sm_dev;
-       struct bus pbus;
 
 
        printk_info("enable_onboard_nic.\n");
 
        sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
 
-       byte= pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0x9a);
+       byte = pci_read_config8(sm_dev, 0x9a);
        byte |= ( 1 << 7);
-       pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0x9a,byte);
+       pci_write_config8(sm_dev, 0x9a, byte);
 
 
        byte=pm_ioread(0x59);
@@ -76,10 +75,10 @@
        pm_iowrite(0x59,byte);
 
 
-       byte = pci_cf8_conf1.read8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0xA8);
+       byte = pci_read_config8(sm_dev, 0xA8);
 
        byte |= (1 << 1); //set bit 1 to high
-       pci_cf8_conf1.write8(&pbus, sm_dev->bus->secondary, sm_dev->path.pci.devfn, 0xA8, byte);
+       pci_write_config8(sm_dev, 0xA8, byte);
 }
 
 /* set thermal config
@@ -89,7 +88,6 @@
 	u8 byte;
 	u16 word;
 	device_t sm_dev;
-	struct bus pbus;
 
 	/* set ADT 7461 */
 	ADT7461_write_byte(0x0B, 0x50);	/* Local Temperature Hight limit */
@@ -112,12 +110,9 @@
 
 	/* set GPIO 64 to input */
 	sm_dev = dev_find_slot(0, PCI_DEVFN(0x14, 0));
-	word =
-	    pci_cf8_conf1.read16(&pbus, sm_dev->bus->secondary,
-				 sm_dev->path.pci.devfn, 0x56);
+	word = pci_read_config16(sm_dev, 0x56);
 	word |= 1 << 7;
-	pci_cf8_conf1.write16(&pbus, sm_dev->bus->secondary,
-			      sm_dev->path.pci.devfn, 0x56, word);
+	pci_write_config16(sm_dev, 0x56, word);
 
 	/* set GPIO 64 internal pull-up */
 	byte = pm2_ioread(0xf0);




From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 11:47:52 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 11:47:52 +0200
Subject: [coreboot] [PATCH] Clean up PCI ops in AMD 690 boards
In-Reply-To: <20090922021345.23809.qmail@stuge.se>
References: <4AB82B64.1020004@gmx.net> <20090922021345.23809.qmail@stuge.se>
Message-ID: <4AB89D48.5000605@gmx.net>

On 22.09.2009 04:13, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
>>     
>
> Acked-by: Peter Stuge <peter at stuge.se>
>   

Thanks, r4647.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From svn at coreboot.org  Tue Sep 22 12:03:15 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 12:03:15 +0200
Subject: [coreboot] [v2] r4648 - in trunk/coreboot-v2/src/mainboard:
	amd/pistachio technexion/tim8690
Message-ID: <mailman.3714.1355071619.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-09-22 12:03:15 +0200 (Tue, 22 Sep 2009)
New Revision: 4648

Modified:
   trunk/coreboot-v2/src/mainboard/amd/pistachio/devicetree.cb
   trunk/coreboot-v2/src/mainboard/technexion/tim8690/devicetree.cb
Log:
r4534 introduced devicetree.cb in every mainboard directory, but didn't
copy any comment lines before the start of the device tree.
Fix up amd/pistachio and technexion/tim8960.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/devicetree.cb
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/devicetree.cb	2009-09-22 09:43:25 UTC (rev 4647)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/devicetree.cb	2009-09-22 10:03:15 UTC (rev 4648)
@@ -1,3 +1,14 @@
+#Define gpp_configuration,	A=0, B=1, C=2, D=3, E=4(default)
+#Define vga_rom_address = 0xfff0000
+#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
+#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or Dev3,
+#			1: the system allows a PCIE link to be established on Dev2 or Dev3.
+#Define gfx_dual_slot, 0: single slot, 1: dual slot
+#Define gfx_lane_reversal, 0: disable lane reversal, 1: enable
+#Define gfx_tmds, 0: didn't support TMDS, 1: support
+#Define gfx_compliance, 0: didn't support compliance, 1: support
+#Define gfx_reconfiguration, 0: short reconfiguration, 1(default): long reconfiguration
+#Define gfx_link_width, 0: x16, 1: x1, 2: x2, 3: x4, 4: x8, 5: x12 (not supported), 6: x16
 chip northbridge/amd/amdk8/root_complex
 	device apic_cluster 0 on
 		chip cpu/amd/socket_AM2

Modified: trunk/coreboot-v2/src/mainboard/technexion/tim8690/devicetree.cb
===================================================================
--- trunk/coreboot-v2/src/mainboard/technexion/tim8690/devicetree.cb	2009-09-22 09:43:25 UTC (rev 4647)
+++ trunk/coreboot-v2/src/mainboard/technexion/tim8690/devicetree.cb	2009-09-22 10:03:15 UTC (rev 4648)
@@ -1,3 +1,14 @@
+#Define gpp_configuration,	A=0, B=1, C=2, D=3, E=4(default)
+#Define vga_rom_address = 0xfff80000
+#Define port_enable, (bit map): GFX(2,3), GPP(4,5,6,7)
+#Define gfx_dev2_dev3, 0: a link will never be established on Dev2 or Dev3,
+#			1: the system allows a PCIE link to be established on Dev2 or Dev3.
+#Define gfx_dual_slot, 0: single slot, 1: dual slot
+#Define gfx_lane_reversal, 0: disable lane reversal, 1: enable
+#Define gfx_tmds, 0: didn't support TMDS, 1: support
+#Define gfx_compliance, 0: didn't support compliance, 1: support
+#Define gfx_reconfiguration, 0: short reconfiguration, 1(default): long reconfiguration
+#Define gfx_link_width, 0: x16, 1: x1, 2: x2, 3: x4, 4: x8, 5: x12 (not supported), 6: x16
 chip northbridge/amd/amdk8/root_complex
 	device apic_cluster 0 on
 		chip cpu/amd/socket_S1G1




From c-d.hailfinger.devel.2006 at gmx.net  Tue Sep 22 12:05:12 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Tue, 22 Sep 2009 12:05:12 +0200
Subject: [coreboot] [PATCH] amd/pistachio
 and	technexion/tim8960	devicetree.cb comments
In-Reply-To: <20090922021036.23265.qmail@stuge.se>
References: <4A982B65.9000400@gmx.net> <4AB82122.1040704@gmx.net>
	<20090922021036.23265.qmail@stuge.se>
Message-ID: <4AB8A158.6040804@gmx.net>

On 22.09.2009 04:10, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>   
>> Ping?
>> This is a documentation-only patch and should be safe.
>>     
>
> It's trivial. Go ahead and commit. Use my ack if you want.
>   

Thanks, r4648.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From info at coresystems.de  Tue Sep 22 12:07:03 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 12:07:03 +0200
Subject: [coreboot] build service results for r4647
Message-ID: <E1Mq2H1-0006N5-1P@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "hailfinger" checked in revision 4647 to
the coreboot repository. This caused the following 
changes:

Change Log:
r4646 enabled early usage of pci_{read,write}_config{8,16,32}

This allows us to change
dword = pci_cf8_conf1.read32(&pbus, sm_dev->bus->secondary,
        sm_dev->path.pci.devfn, 0x64);

to the much more readable
dword = pci_read_config32(sm_dev, 0x64);

Clean up all PCI operations in mainboards based on AMD 690:
amd/pistachio
amd/dbm690t
technexion/tim8690

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4647&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4647&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4647&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Tue Sep 22 12:35:46 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 12:35:46 +0200
Subject: [coreboot] build service results for r4648
Message-ID: <E1Mq2io-0008OX-Qf@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "hailfinger" checked in revision 4648 to
the coreboot repository. This caused the following 
changes:

Change Log:
r4534 introduced devicetree.cb in every mainboard directory, but didn't
copy any comment lines before the start of the device tree.
Fix up amd/pistachio and technexion/tim8960.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4648&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4648&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4648&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From daniel at caiaq.de  Tue Sep 22 13:45:28 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Tue, 22 Sep 2009 13:45:28 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
Message-ID: <20090922114528.GA9361@buzzloop.caiaq.de>

Hi,

I'm developing on a CS5536 based board (ALIX.2D) and I'm trying to get
access to the GPIO registers in order to set the LEDs on bootup.

However, I seem to miss an mandatory point when trying so. As a quick
hack, I added these lines to the end of southbridge_init() in
coreboot-v3/southbridge/amd/cs5536/cs5536.c:

  outl(GPIOL_6_SET, GPIO_IO_BASE + GPIOL_OUTPUT_ENABLE);
  outl(GPIOL_6_CLEAR, GPIO_IO_BASE + GPIOL_OUTPUT_VALUE);

According to the schematics, GPIO6 is connected to one of the LEDs found
on the board, but the GPIO level does not change. I tried reading back
another GPIO but the READ_BACK register reads 0xffffffff, even though
the uppermost 16 bits are supposed to be 0 always. So I assume I missed
some basic point.

The MSR mapping should be set up at this point, as there are accesses to
other GPIO related registers called from the same function.

Any pointers, anyone?

Thanks,
Daniel




From peter at stuge.se  Tue Sep 22 13:56:53 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Sep 2009 13:56:53 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090922114528.GA9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
Message-ID: <20090922115653.3513.qmail@stuge.se>

Daniel Mack wrote:
> I'm developing on a CS5536 based board (ALIX.2D) and I'm trying to
> get access to the GPIO registers in order to set the LEDs on
> bootup.

Check out the 5536 data book on "Atomic Bit Programming" and/or look
at the Linux LED driver for reference. To program the GPIOs you have
to follow the algorithm outlined in 6.16.1.


//Peter



From svn at coreboot.org  Tue Sep 22 14:22:35 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 14:22:35 +0200
Subject: [coreboot] [v2] r4649 - trunk/coreboot-v2/src/console
Message-ID: <mailman.3715.1355071619.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-09-22 14:22:35 +0200 (Tue, 22 Sep 2009)
New Revision: 4649

Modified:
   trunk/coreboot-v2/src/console/Kconfig
Log:
Help text for maximum and default console loglevel in Kconfig.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/coreboot-v2/src/console/Kconfig
===================================================================
--- trunk/coreboot-v2/src/console/Kconfig	2009-09-22 10:03:15 UTC (rev 4648)
+++ trunk/coreboot-v2/src/console/Kconfig	2009-09-22 12:22:35 UTC (rev 4649)
@@ -33,11 +33,11 @@
 	default n
 
 config MAXIMUM_CONSOLE_LOGLEVEL
-	int
+	int "Maximum console loglevel"
 	default 9
 
 config DEFAULT_CONSOLE_LOGLEVEL
-	int
+	int "Default console loglevel"
 	default 9
 
 endmenu




From svn at coreboot.org  Tue Sep 22 14:31:57 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 14:31:57 +0200
Subject: [coreboot] [v2] r4650 -
	trunk/coreboot-v2/src/mainboard/amd/pistachio
Message-ID: <mailman.3716.1355071619.16123.coreboot@coreboot.org>

Author: hailfinger
Date: 2009-09-22 14:31:57 +0200 (Tue, 22 Sep 2009)
New Revision: 4650

Modified:
   trunk/coreboot-v2/src/mainboard/amd/pistachio/Options.lb
Log:
Kill dead comment.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/Options.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/Options.lb	2009-09-22 12:22:35 UTC (rev 4649)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/Options.lb	2009-09-22 12:31:57 UTC (rev 4650)
@@ -106,8 +106,6 @@
 ##
 ## CONFIG_FALLBACK_SIZE is the amount of the ROM the complete fallback image will use
 ##
-#default CONFIG_FALLBACK_SIZE = CONFIG_ROM_IMAGE_SIZE
-#256K
 default CONFIG_FALLBACK_SIZE = CONFIG_ROM_IMAGE_SIZE
 
 ##




From info at coresystems.de  Tue Sep 22 14:48:07 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 14:48:07 +0200
Subject: [coreboot] build service results for r4649
Message-ID: <E1Mq4mt-0000sP-EM@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "hailfinger" checked in revision 4649 to
the coreboot repository. This caused the following 
changes:

Change Log:
Help text for maximum and default console loglevel in Kconfig.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4649&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4649&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4649&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From ward at gnu.org  Tue Sep 22 15:17:15 2009
From: ward at gnu.org (Ward Vandewege)
Date: Tue, 22 Sep 2009 09:17:15 -0400
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
Message-ID: <20090922131715.GA16574@countzero.vandewege.net>

Ping - can I get an ack please? I've got a machine running this port for
almost 2 months now, so it's at least somewhat useable. The outstanding
issues below are not related to this port as such.

Thanks,
Ward.

---------------------------------

See attached.

There are a number of outstanding issues:

* we don't have the mc_patch_01000086.h CPU ucode file yet which is
referenced in a comment in src/mainboard/supermicro/h8dmr_fam10/Options.lb.
AMD has not released it yet. This is not a problem specific to this port.

* I'm seeing toolchain issues. I can't get this tree to compile correctly with
gcc 4.3 (32 bit) - there is an optimization issue where certain parts of the
CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
disappears. This is probably not a problem related to this port specifically.

* setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the boot
shortly after the warm reset triggered by the MCP55 code. I think this too
might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).

* during startup, the CPU cores talk through each other on serial for a
while. Again, not an issue specific to this port.

* to avoid very slow LZMA decompression I use this port with LZMA compression
disabled in CBFS. I'm not sure what's causing this particular slowness.

Thanks,
Ward.

-- 
Ward Vandewege <ward at gnu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: add-h8dmr-fam10.patch
Type: text/x-diff
Size: 84424 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/8d28ab09/attachment.bin>

From info at coresystems.de  Tue Sep 22 15:17:05 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 15:17:05 +0200
Subject: [coreboot] build service results for r4650
Message-ID: <E1Mq5Ev-00039c-BK@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "hailfinger" checked in revision 4650 to
the coreboot repository. This caused the following 
changes:

Change Log:
Kill dead comment.

Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>
Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4650&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4650&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4650&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in hailfinger's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From peter at stuge.se  Tue Sep 22 15:29:05 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Sep 2009 15:29:05 +0200
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
In-Reply-To: <20090922131715.GA16574@countzero.vandewege.net>
References: <20090922131715.GA16574@countzero.vandewege.net>
Message-ID: <20090922132906.22600.qmail@stuge.se>

Ward Vandewege wrote:
> Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912
> fam10 and h8dmr k8 targets.
> 
> Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with
> this, and to Arne for doing the s2912 fam10 port.
> 
> Build and boot tested.
> 
> Signed-off-by: Ward Vandewege <ward at gnu.org>

Acked-by: Peter Stuge <peter at stuge.se>



From rminnich at gmail.com  Tue Sep 22 15:42:49 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Sep 2009 06:42:49 -0700
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
In-Reply-To: <20090922131715.GA16574@countzero.vandewege.net>
References: <20090922131715.GA16574@countzero.vandewege.net>
Message-ID: <13426df10909220642x7b22a1ecs436b8d5c42a93595@mail.gmail.com>

On Tue, Sep 22, 2009 at 6:17 AM, Ward Vandewege <ward at gnu.org> wrote:
> Ping - can I get an ack please? I've got a machine running this port for
> almost 2 months now, so it's at least somewhat useable. The outstanding
> issues below are not related to this port as such.
>
> Thanks,
> Ward.
>
> ---------------------------------
>
> See attached.
>
> There are a number of outstanding issues:
>
> * we don't have the mc_patch_01000086.h CPU ucode file yet which is
> referenced in a comment in src/mainboard/supermicro/h8dmr_fam10/Options.lb.
> AMD has not released it yet. This is not a problem specific to this port.
>
> * I'm seeing toolchain issues. I can't get this tree to compile correctly with
> gcc 4.3 (32 bit) - there is an optimization issue where certain parts of the
> CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
> disappears. This is probably not a problem related to this port specifically.

I don't think it's toolchain, with this description. This sounds more
like a cache issue.

>
> * setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the boot
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).

There ought to be a warning in the target .config to this effect, else
others will be confused.

>
> * during startup, the CPU cores talk through each other on serial for a
> while. Again, not an issue specific to this port.

Geez, I thought all the discussion had fixed that :-)

>
> * to avoid very slow LZMA decompression I use this port with LZMA compression
> disabled in CBFS. I'm not sure what's causing this particular slowness.

This and the other problem sure sound like a few weird possibilities.
What do the MTRRs look like once booted? Is there any chance you are
somehow running on a core that is not set up correctly (this used to
really happen sometimes).

I think this description of problems with the port ought to be in the
target file in a README.

ron



From rminnich at gmail.com  Tue Sep 22 15:43:10 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Sep 2009 06:43:10 -0700
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
In-Reply-To: <13426df10909220642x7b22a1ecs436b8d5c42a93595@mail.gmail.com>
References: <20090922131715.GA16574@countzero.vandewege.net>
	<13426df10909220642x7b22a1ecs436b8d5c42a93595@mail.gmail.com>
Message-ID: <13426df10909220643s5676b883n3cc84c4737f84c6f@mail.gmail.com>

On Tue, Sep 22, 2009 at 6:42 AM, ron minnich <rminnich at gmail.com> wrote:

> I think this description of problems with the port ought to be in the
> target file in a README.

  ^^directory, sorry

ron



From rminnich at gmail.com  Tue Sep 22 15:44:29 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Sep 2009 06:44:29 -0700
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090922115653.3513.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
Message-ID: <13426df10909220644x33c944dcue0c319fda19ad6b0@mail.gmail.com>

On Tue, Sep 22, 2009 at 4:56 AM, Peter Stuge <peter at stuge.se> wrote:
> Daniel Mack wrote:

> Check out the 5536 data book on "Atomic Bit Programming" and/or look
> at the Linux LED driver for reference. To program the GPIOs you have
> to follow the algorithm outlined in 6.16.1.

Yes, this is a pretty elegant idea the Geode guys created that is,
sadly, not in anything else.

ron



From mansoor at iwavesystems.com  Tue Sep 22 16:04:32 2009
From: mansoor at iwavesystems.com (mansoor at iwavesystems.com)
Date: Tue, 22 Sep 2009 19:34:32 +0530 (IST)
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
In-Reply-To: <20090922131715.GA16574@countzero.vandewege.net>
References: <20090922131715.GA16574@countzero.vandewege.net>
Message-ID: <48251.59.92.147.61.1253628272.squirrel@iwavesystems.com>

> Ping - can I get an ack please? I've got a machine running this port for
> almost 2 months now, so it's at least somewhat useable. The outstanding
> issues below are not related to this port as such.
>
> Thanks,
> Ward.
>
> ---------------------------------
>
> See attached.
>
> There are a number of outstanding issues:
>
> * we don't have the mc_patch_01000086.h CPU ucode file yet which is
> referenced in a comment in
> src/mainboard/supermicro/h8dmr_fam10/Options.lb.
> AMD has not released it yet. This is not a problem specific to this port.
>
> * I'm seeing toolchain issues. I can't get this tree to compile correctly
> with
> gcc 4.3 (32 bit) - there is an optimization issue where certain parts of
> the
> CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
> disappears. This is probably not a problem related to this port
> specifically.
>
> * setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the
> boot
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).
>
> * during startup, the CPU cores talk through each other on serial for a
> while. Again, not an issue specific to this port.
>
> * to avoid very slow LZMA decompression I use this port with LZMA
> compression
> disabled in CBFS. I'm not sure what's causing this particular slowness.
>

Try enabling CONFIG_XIP_ROM_BASE.
It solved the same problem for me in my board.

> Thanks,
> Ward.
>
> --
> Ward Vandewege <ward at gnu.org>
>
> -------------------------------------------------------------------------------
> DISCLAIMER: This e-mail and any attachment (s) is for authorised use by
> the
> intended recipient (s) only. It may contain proprietary material,
> confidential
> information and/or be subject to the legal privilege of iWave Systems
> Technologies Private Limited. If you have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly prohibited from
> retaining,
> using, copying, alerting or disclosing the content of this message. Thank
> you
> for your co-operation.
> ------------------------------------------------------------------------------
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot



------------------------------------------------------------------------------- 
DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
intended recipient (s) only. It may contain proprietary material, confidential
information and/or be subject to the legal privilege of iWave Systems
Technologies Private Limited. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from retaining,
using, copying, alerting or disclosing the content of this message. Thank you
for your co-operation. 
------------------------------------------------------------------------------




From mylesgw at gmail.com  Tue Sep 22 17:04:53 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 09:04:53 -0600
Subject: [coreboot] Resend: [PATCH] add h8dmr fam10 target
In-Reply-To: <20090922131715.GA16574@countzero.vandewege.net>
References: <20090922131715.GA16574@countzero.vandewege.net>
Message-ID: <B61E20E0590943F49BDC8446912541A3@chimp>

> * setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the
> boot
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).
Could it be a side effect of one of the writes, or a race condition?

Thanks,
Myles




From stepan at coresystems.de  Tue Sep 22 17:31:56 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Tue, 22 Sep 2009 17:31:56 +0200
Subject: [coreboot] [PATCHes] cbfstool fixes
Message-ID: <4AB8EDEC.90001@coresystems.de>

See attachments
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cbfstool1.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/35ae9045/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cbfstool2.diff
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/35ae9045/attachment-0001.ksh>

From peter at stuge.se  Tue Sep 22 17:34:39 2009
From: peter at stuge.se (Peter Stuge)
Date: Tue, 22 Sep 2009 17:34:39 +0200
Subject: [coreboot] [PATCHes] cbfstool fixes
In-Reply-To: <4AB8EDEC.90001@coresystems.de>
References: <4AB8EDEC.90001@coresystems.de>
Message-ID: <20090922153439.4253.qmail@stuge.se>

Stefan Reinauer wrote:
> * guard all mallocs in cbfstool
> * fix an issue that could lead to cbfstool writing outside of its allocated
>   memory 
> 
> Signed-off-by: Stefan Reinauer <stepan at coresystems.de>

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Tue Sep 22 17:53:02 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 17:53:02 +0200
Subject: [coreboot] [v2] r4651 - trunk/coreboot-v2/util/newconfig
Message-ID: <mailman.3717.1355071620.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-22 17:53:02 +0200 (Tue, 22 Sep 2009)
New Revision: 4651

Modified:
   trunk/coreboot-v2/util/newconfig/config.g
Log:
back out some overzealous renames 

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/util/newconfig/config.g
===================================================================
--- trunk/coreboot-v2/util/newconfig/config.g	2009-09-22 12:31:57 UTC (rev 4650)
+++ trunk/coreboot-v2/util/newconfig/config.g	2009-09-22 15:53:02 UTC (rev 4651)
@@ -1647,7 +1647,7 @@
     token ACTION:		'action'
     token ADDACTION:		'addaction'
     token ALWAYS:		'always'
-    token CONFIG_ARCH:			'arch'
+    token ARCH:			'arch'
     token BUILDROM:		'buildrom'
     token COMMENT:		'comment'
     token CONFIG:		'config'
@@ -1677,7 +1677,7 @@
     token IRQ:			'irq'
     token LDSCRIPT:		'ldscript'
     token LOADOPTIONS:		'loadoptions'
-    token CONFIG_MAINBOARD:		'mainboard'
+    token MAINBOARD:		'mainboard'
     token MAINBOARDINIT:	'mainboardinit'
     token MAKEDEFINE:		'makedefine'
     token MAKERULE:		'makerule'
@@ -1777,7 +1777,7 @@
 			]                       {{ if (C): part(parttype, partid, 'Config.lb', name) }}
 			partend<<C>> 		
 
-    rule arch<<C>>:	CONFIG_ARCH ID			{{ if (C): setarch(ID) }}
+    rule arch<<C>>:	ARCH ID			{{ if (C): setarch(ID) }}
 			partend<<C>>
     
     rule mainboardinit<<C>>:
@@ -1969,7 +1969,7 @@
     rule payload<<C>>:	PAYLOAD DIRPATH		{{ if (C): payload(DIRPATH) }}
 
     rule mainboard:
-			CONFIG_MAINBOARD PATH		{{ mainboardsetup(PATH) }}
+			MAINBOARD PATH		{{ mainboardsetup(PATH) }}
 
     rule romif<<C>>:	IF ID			{{ c = lookup(ID) }}
 			(romstmt<<C and c>>)* 




From svn at coreboot.org  Tue Sep 22 17:53:55 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 17:53:55 +0200
Subject: [coreboot] [v2] r4652 - trunk/coreboot-v2/util/abuild
Message-ID: <mailman.3718.1355071620.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-22 17:53:54 +0200 (Tue, 22 Sep 2009)
New Revision: 4652

Modified:
   trunk/coreboot-v2/util/abuild/abuild
Log:
.. make abuild Kconfig proof for the time being.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/util/abuild/abuild
===================================================================
--- trunk/coreboot-v2/util/abuild/abuild	2009-09-22 15:53:02 UTC (rev 4651)
+++ trunk/coreboot-v2/util/abuild/abuild	2009-09-22 15:53:54 UTC (rev 4652)
@@ -103,7 +103,7 @@
 {
 	# make this a function so we can easily select
 	# without breaking readability
-	ls -1 "$LBROOT/src/mainboard" | grep -v Kconfig
+	ls -1 "$LBROOT/src/mainboard" | grep -v Kconfig | grep -v Makefile
 }
 
 function mainboards




From svn at coreboot.org  Tue Sep 22 17:55:02 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 17:55:02 +0200
Subject: [coreboot] [v2] r4653 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3719.1355071620.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-22 17:55:01 +0200 (Tue, 22 Sep 2009)
New Revision: 4653

Modified:
   trunk/coreboot-v2/util/cbfstool/common.c
   trunk/coreboot-v2/util/cbfstool/common.h
Log:
* guard all mallocs in cbfstool
* fix an issue that could lead to cbfstool writing outside of its allocated
  memory 

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: trunk/coreboot-v2/util/cbfstool/common.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/common.c	2009-09-22 15:53:54 UTC (rev 4652)
+++ trunk/coreboot-v2/util/cbfstool/common.c	2009-09-22 15:55:01 UTC (rev 4653)
@@ -36,10 +36,16 @@
 	fseek(file, 0, SEEK_END);
 	*romsize_p = ftell(file);
 	fseek(file, 0, SEEK_SET);
-	if (!content)
+	if (!content) {
 		content = malloc(*romsize_p);
-	else if (place == SEEK_END)
+		if (!content) {
+			printf("Could not get %d bytes for file %s\n",
+					*romsize_p, filename);
+			exit(1);
+		}
+	} else if (place == SEEK_END)
 		content -= *romsize_p;
+
 	if (!fread(content, *romsize_p, 1, file)) {
 		printf("failed to read %s\n", filename);
 		return NULL;
@@ -255,6 +261,11 @@
 		*location -= headersize;
 	}
 	void *newdata = malloc(*datasize + headersize);
+	if (!newdata) {
+		printf("Could not get %d bytes for CBFS file.\n", *datasize +
+				headersize);
+		exit(1);
+	}
 	struct cbfs_file *nextfile = (struct cbfs_file *)newdata;
 	strncpy(nextfile->magic, "LARCHIVE", 8);
 	nextfile->len = htonl(*datasize);
@@ -272,9 +283,16 @@
 {
 	romsize = _romsize;
 	unsigned char *romarea = malloc(romsize);
+	if (!romarea) {
+		printf("Could not get %d bytes of memory for CBFS image.\n",
+				romsize);
+		exit(1);
+	}
 	memset(romarea, 0xff, romsize);
-	recalculate_rom_geometry(romarea);
 
+	// Set up physical/virtual mapping
+	offset = romarea + romsize - 0x100000000ULL;
+
 	if (align == 0)
 		align = 64;
 
@@ -291,6 +309,9 @@
 	master_header->offset = htonl(0);
 	((uint32_t *) phys_to_virt(0xfffffffc))[0] =
 	    virt_to_phys(master_header);
+
+	recalculate_rom_geometry(romarea);
+
 	struct cbfs_file *one_empty_file =
 	    cbfs_create_empty_file((0 - romsize) & 0xffffffff,
 				   romsize - bootblocksize -

Modified: trunk/coreboot-v2/util/cbfstool/common.h
===================================================================
--- trunk/coreboot-v2/util/cbfstool/common.h	2009-09-22 15:53:54 UTC (rev 4652)
+++ trunk/coreboot-v2/util/cbfstool/common.h	2009-09-22 15:55:01 UTC (rev 4653)
@@ -29,7 +29,7 @@
 
 static uint32_t virt_to_phys(void *addr)
 {
-	return (long)(addr - offset) & 0xffffffff;
+	return (unsigned long)(addr - offset) & 0xffffffff;
 }
 
 #define ALIGN(val, by) (((val) + (by)-1)&~((by)-1))
@@ -61,3 +61,5 @@
 
 int add_file_to_cbfs(void *content, uint32_t contentsize, uint32_t location);
 void print_cbfs_directory(const char *filename);
+
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))




From svn at coreboot.org  Tue Sep 22 17:58:19 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 17:58:19 +0200
Subject: [coreboot] [v2] r4654 - trunk/coreboot-v2/util/cbfstool
Message-ID: <mailman.3720.1355071620.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-22 17:58:19 +0200 (Tue, 22 Sep 2009)
New Revision: 4654

Modified:
   trunk/coreboot-v2/util/cbfstool/cbfstool.c
Log:
This separates the code for each command in cbfstool. For the good and for the
bad: It brings a certain amount of code duplication (some of which can be
cleaned up again, or get rid of by proper refactoring).
On the other hand now there's a very simple code flow for each command, rather
than for each operation. ie.

adding a file to a cbfs means:
 - open the cbfs
 - add the file
 - close the cbfs

rather than

open the cbfs:
 - do this for add, remove, but not for create

create a new lar
 - if we don't have an open one yet

add a file:
 - if we didn't bail out before

close the file:
 - if we didn't bail out before


The short term benefit is that this fixes a problem where cbfstool was trying
to add a file if you gave a non-existing command because it bailed out on
known, not on unknown commands.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Modified: trunk/coreboot-v2/util/cbfstool/cbfstool.c
===================================================================
--- trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-22 15:55:01 UTC (rev 4653)
+++ trunk/coreboot-v2/util/cbfstool/cbfstool.c	2009-09-22 15:58:19 UTC (rev 4654)
@@ -23,50 +23,79 @@
 #include "common.h"
 #include "cbfs.h"
 
-int main(int argc, char **argv)
+typedef enum {
+	CMD_ADD,
+	CMD_ADD_PAYLOAD,
+	CMD_ADD_STAGE,
+	CMD_CREATE,
+	CMD_PRINT
+} cmd_t;
+
+struct command {
+	cmd_t id;
+	const char *name;
+	int (*function) (int argc, char **argv);
+};
+
+static int cbfs_add(int argc, char **argv)
 {
-	if (argc < 3) {
-		printf
-		    ("cbfstool: Management utility for CBFS formatted ROM images\n"
-		     "USAGE:\n" "cbfstool [-h]\n"
-		     "cbfstool FILE COMMAND [PARAMETERS]...\n\n" "OPTIONs:\n"
-		     " -h		Display this help message\n\n"
-		     "COMMANDs:\n"
-		     "add FILE NAME TYPE [base address]    Add a component\n"
-		     "add-payload FILE NAME [COMP] [base]  Add a payload to the ROM\n"
-		     "add-stage FILE NAME [COMP] [base]    Add a stage to the ROM\n"
-		     "create SIZE BSIZE BOOTBLOCK [ALIGN]  Create a ROM file\n"
-		     "print                                Show the contents of the ROM\n");
-		return 1;
-	}
 	char *romname = argv[1];
 	char *cmd = argv[2];
+	void *rom = loadrom(romname);
 
-	if (strcmp(cmd, "create") == 0) {
-		if (argc < 6) {
-			printf("not enough arguments to 'create'.\n");
-			return 1;
-		}
-		uint32_t size = strtoul(argv[3], NULL, 0);
-		/* ignore bootblock size. we use whatever we get and won't allocate any larger */
-		char *bootblock = argv[5];
-		uint32_t align = 0;
-		if (argc > 6)
-			align = strtoul(argv[6], NULL, 0);
-		return create_cbfs_image(romname, size, bootblock, align);
+	if (rom == NULL) {
+		printf("Could not load ROM image '%s'.\n", romname);
+		return 1;
 	}
 
+	if (argc < 5) {
+		printf("not enough arguments to '%s'.\n", cmd);
+		return 1;
+	}
+
+	char *filename = argv[3];
+	char *cbfsname = argv[4];
+
+	uint32_t filesize = 0;
+	void *filedata = loadfile(filename, &filesize, 0, SEEK_SET);
+	if (filedata == NULL) {
+		printf("Could not load file '%s'.\n", filename);
+		return 1;
+	}
+
+	uint32_t base = 0;
+	void *cbfsfile = NULL;
+
+	if (argc < 6) {
+		printf("not enough arguments to 'add'.\n");
+		return 1;
+	}
+	uint32_t type;
+	if (intfiletype(argv[5]) != ((uint64_t) - 1))
+		type = intfiletype(argv[5]);
+	else
+		type = strtoul(argv[5], NULL, 0);
+	if (argc > 6) {
+		base = strtoul(argv[6], NULL, 0);
+	}
+	cbfsfile =
+	    create_cbfs_file(cbfsname, filedata, &filesize, type, &base);
+	add_file_to_cbfs(cbfsfile, filesize, base);
+	writerom(romname, rom, romsize);
+	return 0;
+}
+
+static int cbfs_add_payload(int argc, char **argv)
+{
+	char *romname = argv[1];
+	char *cmd = argv[2];
 	void *rom = loadrom(romname);
+
 	if (rom == NULL) {
 		printf("Could not load ROM image '%s'.\n", romname);
 		return 1;
 	}
 
-	if (strcmp(cmd, "print") == 0) {
-		print_cbfs_directory(romname);
-		return 0;
-	}
-
 	if (argc < 5) {
 		printf("not enough arguments to '%s'.\n", cmd);
 		return 1;
@@ -83,59 +112,150 @@
 	}
 
 	uint32_t base = 0;
-	void *cbfsfile;
+	void *cbfsfile = NULL;
 
-	if (strcmp(cmd, "add") == 0) {
-		if (argc < 6) {
-			printf("not enough arguments to 'add'.\n");
-			return 1;
-		}
-		uint32_t type;
-		if (intfiletype(argv[5]) != ((uint64_t) - 1))
-			type = intfiletype(argv[5]);
-		else
-			type = strtoul(argv[5], NULL, 0);
-		if (argc > 6) {
-			base = strtoul(argv[6], NULL, 0);
-		}
-		cbfsfile =
-		    create_cbfs_file(cbfsname, filedata, &filesize, type,
-				     &base);
+	comp_algo algo = CBFS_COMPRESS_NONE;
+	if (argc > 5) {
+		if (argv[5][0] == 'l')
+			algo = CBFS_COMPRESS_LZMA;
 	}
+	if (argc > 6) {
+		base = strtoul(argv[6], NULL, 0);
+	}
+	unsigned char *payload;
+	filesize = parse_elf_to_payload(filedata, &payload, algo);
+	cbfsfile =
+	    create_cbfs_file(cbfsname, payload, &filesize,
+			     CBFS_COMPONENT_PAYLOAD, &base);
+	add_file_to_cbfs(cbfsfile, filesize, base);
+	writerom(romname, rom, romsize);
+	return 0;
+}
 
-	if (strcmp(cmd, "add-payload") == 0) {
-		comp_algo algo = CBFS_COMPRESS_NONE;
-		if (argc > 5) {
-			if (argv[5][0] == 'l')
-				algo = CBFS_COMPRESS_LZMA;
-		}
-		if (argc > 6) {
-			base = strtoul(argv[6], NULL, 0);
-		}
-		unsigned char *payload;
-		filesize = parse_elf_to_payload(filedata, &payload, algo);
-		cbfsfile =
-		    create_cbfs_file(cbfsname, payload, &filesize,
-				     CBFS_COMPONENT_PAYLOAD, &base);
+static int cbfs_add_stage(int argc, char **argv)
+{
+	char *romname = argv[1];
+	char *cmd = argv[2];
+	void *rom = loadrom(romname);
+
+	if (rom == NULL) {
+		printf("Could not load ROM image '%s'.\n", romname);
+		return 1;
 	}
 
-	if (strcmp(cmd, "add-stage") == 0) {
-		comp_algo algo = CBFS_COMPRESS_NONE;
-		if (argc > 5) {
-			if (argv[5][0] == 'l')
-				algo = CBFS_COMPRESS_LZMA;
-		}
-		if (argc > 6) {
-			base = strtoul(argv[6], NULL, 0);
-		}
-		unsigned char *stage;
-		filesize = parse_elf_to_stage(filedata, &stage, algo, &base);
-		cbfsfile =
-		    create_cbfs_file(cbfsname, stage, &filesize,
-				     CBFS_COMPONENT_STAGE, &base);
+	if (argc < 5) {
+		printf("not enough arguments to '%s'.\n", cmd);
+		return 1;
 	}
 
+	char *filename = argv[3];
+	char *cbfsname = argv[4];
+
+	uint32_t filesize = 0;
+	void *filedata = loadfile(filename, &filesize, 0, SEEK_SET);
+	if (filedata == NULL) {
+		printf("Could not load file '%s'.\n", filename);
+		return 1;
+	}
+
+	uint32_t base = 0;
+	void *cbfsfile = NULL;
+
+	comp_algo algo = CBFS_COMPRESS_NONE;
+	if (argc > 5) {
+		if (argv[5][0] == 'l')
+			algo = CBFS_COMPRESS_LZMA;
+	}
+	if (argc > 6) {
+		base = strtoul(argv[6], NULL, 0);
+	}
+	unsigned char *stage;
+	filesize = parse_elf_to_stage(filedata, &stage, algo, &base);
+	cbfsfile =
+	    create_cbfs_file(cbfsname, stage, &filesize,
+			     CBFS_COMPONENT_STAGE, &base);
+
 	add_file_to_cbfs(cbfsfile, filesize, base);
 	writerom(romname, rom, romsize);
 	return 0;
 }
+
+static int cbfs_create(int argc, char **argv)
+{
+	char *romname = argv[1];
+	char *cmd = argv[2];
+	if (argc < 6) {
+		printf("not enough arguments to 'create'.\n");
+		return 1;
+	}
+
+	uint32_t size = strtoul(argv[3], NULL, 0);
+	/* ignore bootblock size. we use whatever we get and won't allocate any larger */
+	char *bootblock = argv[5];
+	uint32_t align = 0;
+
+	if (argc > 6)
+		align = strtoul(argv[6], NULL, 0);
+
+	return create_cbfs_image(romname, size, bootblock, align);
+}
+
+static int cbfs_print(int argc, char **argv)
+{
+	char *romname = argv[1];
+	char *cmd = argv[2];
+	void *rom = loadrom(romname);
+
+	if (rom == NULL) {
+		printf("Could not load ROM image '%s'.\n", romname);
+		return 1;
+	}
+
+	print_cbfs_directory(romname);
+	return 0;
+}
+
+struct command commands[] = {
+	{CMD_ADD, "add", cbfs_add},
+	{CMD_ADD_PAYLOAD, "add-payload", cbfs_add_payload},
+	{CMD_ADD_STAGE, "add-stage", cbfs_add_stage},
+	{CMD_CREATE, "create", cbfs_create},
+	{CMD_PRINT, "print", cbfs_print}
+};
+
+void usage(void)
+{
+	printf
+	    ("cbfstool: Management utility for CBFS formatted ROM images\n"
+	     "USAGE:\n" "cbfstool [-h]\n"
+	     "cbfstool FILE COMMAND [PARAMETERS]...\n\n" "OPTIONs:\n"
+	     " -h		Display this help message\n\n"
+	     "COMMANDs:\n"
+	     "add FILE NAME TYPE [base address]    Add a component\n"
+	     "add-payload FILE NAME [COMP] [base]  Add a payload to the ROM\n"
+	     "add-stage FILE NAME [COMP] [base]    Add a stage to the ROM\n"
+	     "create SIZE BSIZE BOOTBLOCK [ALIGN]  Create a ROM file\n"
+	     "print                                Show the contents of the ROM\n");
+}
+
+int main(int argc, char **argv)
+{
+	int i;
+
+	if (argc < 3) {
+		usage();
+		return 1;
+	}
+
+	char *cmd = argv[2];
+
+	for (i = 0; i < ARRAY_SIZE(commands); i++) {
+		if (strcmp(cmd, commands[i].name) != 0)
+			continue;
+		return commands[i].function(argc, argv);
+	}
+
+	printf("Unknown command '%s'.\n", cmd);
+	usage();
+	return 1;
+}




From info at coresystems.de  Tue Sep 22 18:18:14 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 18:18:14 +0200
Subject: [coreboot] build service results for r4651
Message-ID: <E1Mq84E-0005Xs-1b@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4651 to
the coreboot repository. This caused the following 
changes:

Change Log:
back out some overzealous renames

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4651&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4651&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4651&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Tue Sep 22 18:47:51 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 18:47:51 +0200
Subject: [coreboot] build service results for r4652
Message-ID: <E1Mq8Wt-0007mZ-6C@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4652 to
the coreboot repository. This caused the following 
changes:

Change Log:
.. make abuild Kconfig proof for the time being.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4652&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4652&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4652&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Tue Sep 22 18:51:30 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 10:51:30 -0600
Subject: [coreboot] Kconfig patches
Message-ID: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>

I'm still trying to update my Tyan boards so they don't get pruned.  They're
pretty close, there is still an issue with ACPI that I'm working on, but I'd
like to start shrinking my patch stack.

tables.diff: Add Kconfig dialogues for ACPI, MP_TABLE, ...
Kconfig_bools.diff: Change some more ints to bools, change some default
values.
xip_size.diff: Make XIP_SIZE + XIP_BASE add up to 4GB so that the end of the
ROM gets cached (speeds up booting immensely.)
failoverR.diff: Revert my failover change from before since Kconfig only
supports fallback.
kconfig_s2892.dif: Add support for Tyan s2891, s2892, and s2895 to Kconfig.
smp.diff: set CONFIG_SMP based on MAX_CPUS.  I think maybe CONFIG_SMP should
just die and test for CONFIG_MAX_CPUS.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tables.diff
Type: text/x-patch
Size: 1793 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kconfig_bools.diff
Type: text/x-patch
Size: 4196 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment-0001.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xip_size.diff
Type: text/x-patch
Size: 262 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment-0002.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: failoverR.diff
Type: text/x-patch
Size: 11694 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment-0003.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kconfig_s2892.diff
Type: text/x-patch
Size: 16807 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment-0004.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smp.diff
Type: text/x-patch
Size: 283 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/16892759/attachment-0005.diff>

From info at coresystems.de  Tue Sep 22 19:20:00 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 19:20:00 +0200
Subject: [coreboot] build service results for r4653
Message-ID: <E1Mq920-0002Gd-H5@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4653 to
the coreboot repository. This caused the following 
changes:

Change Log:
* guard all mallocs in cbfstool
* fix an issue that could lead to cbfstool writing outside of its allocated
  memory

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4653&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4653&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4653&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From rminnich at gmail.com  Tue Sep 22 19:36:29 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Sep 2009 10:36:29 -0700
Subject: [coreboot] Kconfig patches
In-Reply-To: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>
References: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>
Message-ID: <13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>

All are
Acked-by: Ronald G. Minnich <rminnich at gmail.com>

I really like the tables cleanup too.

We do need to get some of those k8 options out of mainboards, but
that's a future fix. These patches are a big improvement.

ron



From info at coresystems.de  Tue Sep 22 19:53:14 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 19:53:14 +0200
Subject: [coreboot] build service results for r4654
Message-ID: <E1Mq9YA-000549-24@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4654 to
the coreboot repository. This caused the following 
changes:

Change Log:
This separates the code for each command in cbfstool. For the good and for the
bad: It brings a certain amount of code duplication (some of which can be
cleaned up again, or get rid of by proper refactoring).
On the other hand now there's a very simple code flow for each command, rather
than for each operation. ie.

adding a file to a cbfs means:
 - open the cbfs
 - add the file
 - close the cbfs

rather than

open the cbfs:
 - do this for add, remove, but not for create

create a new lar
 - if we don't have an open one yet

add a file:
 - if we didn't bail out before

close the file:
 - if we didn't bail out before


The short term benefit is that this fixes a problem where cbfstool was trying
to add a file if you gave a non-existing command because it bailed out on
known, not on unknown commands.

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Peter Stuge <peter at stuge.se>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4654&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4654&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4654&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From Cristi.Magherusan at net.utcluj.ro  Tue Sep 22 20:40:29 2009
From: Cristi.Magherusan at net.utcluj.ro (Cristi Magherusan)
Date: Tue, 22 Sep 2009 21:40:29 +0300
Subject: [coreboot] Kconfig patches
In-Reply-To: <13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>
References: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>
	<13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>
Message-ID: <1253644829.16192.5.camel@ufo>

On Tue, 2009-09-22 at 10:36 -0700, ron minnich wrote:
> All are
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
> 
> I really like the tables cleanup too.
> 
> We do need to get some of those k8 options out of mainboards, but
> that's a future fix. These patches are a big improvement.
> 
> ron
> 
Great work! 

Kconfig_bools.diff defines LOGICAL_CPUS as bool, shouldn't it be left as
int instead?

Regards,
Cristi

-- 
Ing. Cristi M?gheru?an, System/Network Engineer
Technical University of Cluj-Napoca, Romania
http://cc.utcluj.ro  +40264 401247
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/069ca28f/attachment.sig>

From mylesgw at gmail.com  Tue Sep 22 20:45:07 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 12:45:07 -0600
Subject: [coreboot] Kconfig patches
In-Reply-To: <1253644829.16192.5.camel@ufo>
References: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>
	<13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>
	<1253644829.16192.5.camel@ufo>
Message-ID: <2831fecf0909221145q318d4fc4va3e387fd6b4270fd@mail.gmail.com>

>
> Great work!
>
> Kconfig_bools.diff defines LOGICAL_CPUS as bool, shouldn't it be left as
> int instead?


It is used as either true or false.  The way to tell how many logical CPUs
there might be is dividing CONFIG_MAX_CPUS and CONFIG_MAX_PHYSICAL_CPUS.

from  src/northbridge/amd/amdk8/.svn/text-base/northbridge.c.svn-base:
    disable_siblings = !CONFIG_LOGICAL_CPUS;

Thanks for the review,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/faf04184/attachment.html>

From svn at coreboot.org  Tue Sep 22 20:49:08 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 20:49:08 +0200
Subject: [coreboot] [v2] r4655 - in trunk/coreboot-v2/src: . console cpu
	cpu/x86 mainboard mainboard/amd/rumba
	mainboard/amd/serengeti_cheetah northbridge/intel/i82810
Message-ID: <mailman.3721.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-22 20:49:08 +0200 (Tue, 22 Sep 2009)
New Revision: 4655

Modified:
   trunk/coreboot-v2/src/Kconfig
   trunk/coreboot-v2/src/console/Kconfig
   trunk/coreboot-v2/src/cpu/Kconfig
   trunk/coreboot-v2/src/cpu/x86/Kconfig
   trunk/coreboot-v2/src/mainboard/Kconfig
   trunk/coreboot-v2/src/mainboard/amd/rumba/Kconfig
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
   trunk/coreboot-v2/src/northbridge/intel/i82810/Kconfig
Log:
tables.diff: Add Kconfig dialogues for ACPI, MP_TABLE, ...
Kconfig_bools.diff: Change some more ints to bools, change some default values.
xip_size.diff: Make XIP_SIZE + XIP_BASE add up to 4GB.
smp.diff: set CONFIG_SMP based on MAX_CPUS.


Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: trunk/coreboot-v2/src/Kconfig
===================================================================
--- trunk/coreboot-v2/src/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -40,14 +40,10 @@
 	bool
 	default y
 
-config HAVE_HIGH_TABLES
+config PCI_BUS_SEGN_BITS
 	bool
-	default y
+	default n
 
-config PCI_BUS_SEGN_BITS
-	int
-	default 0
-
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0
@@ -81,20 +77,20 @@
 	default 126
 
 config LOGICAL_CPUS
-	int
-	default 1
+	bool
+	default y
 
 config PCI_ROM_RUN
 	bool
 	default n
 
 config HT_CHAIN_UNITID_BASE
-	int
+	hex
 	default 1
 
 config HT_CHAIN_END_UNITID_BASE
-	int
-	default 32
+	hex
+	default 0x20
 
 config HEAP_SIZE
 	hex
@@ -136,10 +132,6 @@
 	int
 	default 2048
 
-config MULTIBOOT
-	bool
-	default n
-
 config COMPRESSED_PAYLOAD_LZMA
 	bool
 	default y
@@ -158,10 +150,6 @@
 	int
 	default 0
 
-config HAVE_ACPI_TABLES
-	bool
-	default n
-
 config HAVE_FALLBACK_BOOT
 	bool
 	default y
@@ -186,18 +174,10 @@
 	bool
 	default y
 
-config HAVE_MP_TABLE
-	bool
-	default n
-
 config HAVE_OPTION_TABLE
 	bool
 	default y
 
-config HAVE_PIRQ_TABLE
-	bool
-	default n
-
 config PIRQ_ROUTE
 	bool
 	default n
@@ -214,11 +194,55 @@
 	bool
 	default n
 
+config USE_WATCHDOG_ON_BOOT
+	bool
+	default n
+
+config VGA
+	bool
+	default n
+	help
+	  Build board-specific VGA code.
+
+config GFXUMA
+	bool
+	default n
+	help
+	  Enable Unified Memory Architecture for graphics.
+
 # TODO
 # menu "Drivers"
 # 
 # endmenu
 
+menu "Generated System Tables"
+
+config HAVE_LOW_TABLES
+	bool
+	default y
+
+config HAVE_HIGH_TABLES
+	bool "Write 'high' tables to avoid being overwritten in F segment"
+	default y
+
+config MULTIBOOT
+	bool "Add Multiboot tables (for grub2)"
+	default n
+
+config HAVE_ACPI_TABLES
+	bool "Generate ACPI tables"
+	default n
+
+config HAVE_MP_TABLE
+	bool "Generate an MP table"
+	default n
+
+config HAVE_PIRQ_TABLE
+	bool "Generate a PIRQ table"
+	default n
+
+endmenu
+
 menu "Payload"
 
 config COMPRESSED_PAYLOAD_LZMA

Modified: trunk/coreboot-v2/src/console/Kconfig
===================================================================
--- trunk/coreboot-v2/src/console/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/console/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -32,6 +32,12 @@
 	bool "Use VGA console, once initialized."
 	default n
 
+config CONSOLE_VGA_ONBOARD_AT_FIRST
+	bool "Use onboard VGA as primary"
+	default n
+	help
+	  If not selected, the last adapter found will be used.
+
 config MAXIMUM_CONSOLE_LOGLEVEL
 	int "Maximum console loglevel"
 	default 9

Modified: trunk/coreboot-v2/src/cpu/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/cpu/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -19,7 +19,7 @@
 
 config SMP
 	bool
-	default n
+	default y if MAX_CPUS != 1
 
 config CPU_SOCKET_TYPE
 	hex

Modified: trunk/coreboot-v2/src/cpu/x86/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/x86/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/cpu/x86/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -16,4 +16,4 @@
 
 config XIP_ROM_SIZE
 	hex
-	default 0x2000
+	default 0x20000

Modified: trunk/coreboot-v2/src/mainboard/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/mainboard/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -331,6 +331,11 @@
 	default "Tyan"
 	depends on VENDOR_TYAN
 
+config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
+	hex
+	default 0x10f1
+	depends on VENDOR_TYAN
+
 config MAINBOARD_VENDOR
 	string
 	default "VIA"

Modified: trunk/coreboot-v2/src/mainboard/amd/rumba/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/rumba/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/mainboard/amd/rumba/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -52,6 +52,6 @@
 	depends on BOARD_AMD_RUMBA
 
 config USE_INIT
-	int
-	default 0
+	bool
+	default n
 	depends on BOARD_AMD_RUMBA

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -69,30 +69,24 @@
 	default "Serengeti-Cheetah"
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
-
-config USE_FAILOVER_IMAGE
-	int
-	default 0
-	depends on BOARD_AMD_SERENGETI_CHEETAH
-
 config HW_MEM_HOLE_SIZEK
 	hex
 	default 0x100000
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config MEM_TRAIN_SEQ
-	int
-	default 1
+	bool
+	default y
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config HAVE_FAILOVER_BOOT
-	int
-	default 0
+	bool
+	default n
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config USE_FAILOVER_IMAGE
-	int
-	default 0
+	bool
+	default n
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config MAX_CPUS
@@ -106,28 +100,28 @@
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config MEM_TRAIN_SEQ
-	int
-	default 1
+	bool
+	default y
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config AP_CODE_IN_CAR
-	int
-	default 1
+	bool
+	default y
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config HW_MEM_HOLE_SIZE_AUTO_INC
-	int
-	default 0
+	bool
+	default n
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config HT_CHAIN_END_UNITID_BASE
-	int
+	hex
 	default 0x6
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config USE_INIT
-	int
-	default 0
+	bool
+	default n
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config SERIAL_CPU_INIT
@@ -136,13 +130,13 @@
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config AP_CODE_IN_CAR
-	int
-	default 1
+	bool
+	default y
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config WAIT_BEFORE_CPUS_INIT
-	int
-	default 1
+	bool
+	default y
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
 config SB_HT_CHAIN_ON_BUS0

Modified: trunk/coreboot-v2/src/northbridge/intel/i82810/Kconfig
===================================================================
--- trunk/coreboot-v2/src/northbridge/intel/i82810/Kconfig	2009-09-22 15:58:19 UTC (rev 4654)
+++ trunk/coreboot-v2/src/northbridge/intel/i82810/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
@@ -18,11 +18,6 @@
 ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 ##
 
-config HAVE_HIGH_TABLES
-	bool "Do we have high tables"
-	default y
-
 config NORTHBRIDGE_INTEL_I82810
 	bool
 	default n
-




From svn at coreboot.org  Tue Sep 22 20:53:50 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 20:53:50 +0200
Subject: [coreboot] [v2] r4656 - in trunk/coreboot-v2: src/mainboard/tyan
	src/mainboard/tyan/s2891 src/mainboard/tyan/s2892
	src/mainboard/tyan/s2895 src/southbridge/nvidia/ck804
	targets/tyan/s2895
Message-ID: <mailman.3722.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-22 20:53:50 +0200 (Tue, 22 Sep 2009)
New Revision: 4656

Added:
   trunk/coreboot-v2/src/mainboard/tyan/Makefile.s289x.inc
   trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc
   trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2892/Makefile.inc
   trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2895/Makefile.inc
Modified:
   trunk/coreboot-v2/src/mainboard/tyan/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb
   trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
   trunk/coreboot-v2/src/southbridge/nvidia/ck804/Kconfig
   trunk/coreboot-v2/targets/tyan/s2895/Config-abuild.lb
   trunk/coreboot-v2/targets/tyan/s2895/Config.lb
Log:
failoverR.diff: Revert my failover change since Kconfig only supports fallback.
kconfig_s2892.dif: Add support for Tyan s2891, s2892, and s2895 to Kconfig.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: trunk/coreboot-v2/src/mainboard/tyan/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/src/mainboard/tyan/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
@@ -23,6 +23,9 @@
 	depends on VENDOR_TYAN
 	
 source "src/mainboard/tyan/s1846/Kconfig"
+source "src/mainboard/tyan/s2891/Kconfig"
+source "src/mainboard/tyan/s2892/Kconfig"
+source "src/mainboard/tyan/s2895/Kconfig"
 
 endchoice
 

Copied: trunk/coreboot-v2/src/mainboard/tyan/Makefile.s289x.inc (from rev 4611, trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Makefile.inc)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/Makefile.s289x.inc	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/Makefile.s289x.inc	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1,73 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2007-2008 coresystems GmbH
+##
+## This program is free software; you can redistribute it and/or
+## modify it under the terms of the GNU General Public License as
+## published by the Free Software Foundation; version 2 of
+## the License.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+## MA 02110-1301 USA
+##
+
+##
+## This mainboard requires DCACHE_AS_RAM enabled. It won't work without.
+##
+
+driver-y +=  mainboard.o
+
+#needed by irq_tables and mptable and acpi_tables
+obj-y += get_bus_conf.o
+obj-$(CONFIG_HAVE_MP_TABLE) += mptable.o
+obj-$(CONFIG_HAVE_PIRQ_TABLE) += irq_tables.o
+obj-$(CONFIG_HAVE_ACPI_TABLES) +=  dsdt.o
+obj-$(CONFIG_HAVE_ACPI_TABLES) +=  acpi_tables.o
+
+#driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o
+
+# This is part of the conversion to init-obj and away from included code.
+
+initobj-y += crt0.o
+# FIXME in $(top)/Makefile
+crt0-y += ../../../../src/cpu/x86/16bit/entry16.inc
+crt0-y += ../../../../src/cpu/x86/32bit/entry32.inc
+crt0-y += ../../../../src/cpu/x86/16bit/reset16.inc
+crt0-y += ../../../../src/southbridge/nvidia/ck804/id.inc
+crt0-y += ../../../../src/southbridge/nvidia/ck804/romstrap.inc
+crt0-y += ../../../../src/cpu/amd/car/cache_as_ram.inc
+crt0-y += auto.inc
+
+ldscript-y += ../../../../src/arch/i386/init/ldscript_fallback_cbfs.lb
+ldscript-y += ../../../../src/cpu/x86/16bit/entry16.lds
+ldscript-y += ../../../../src/cpu/x86/16bit/reset16.lds
+ldscript-y += ../../../../src/southbridge/nvidia/ck804/id.lds
+ldscript-y += ../../../../src/southbridge/nvidia/ck804/romstrap.lds
+ldscript-y += ../../../../src/arch/i386/lib/failover.lds
+
+ifdef POST_EVALUATION
+
+MAINBOARD_OPTIONS= -DCONFIG_AP_IN_SIPI_WAIT=0
+
+$(obj)/dsdt.c: $(src)/mainboard/$(MAINBOARDDIR)/dsdt.dsl
+	iasl -p dsdt -tc $(src)/mainboard/$(MAINBOARDDIR)/dsdt.dsl
+	mv dsdt.hex $@
+
+$(obj)/mainboard/$(MAINBOARDDIR)/dsdt.o: $(obj)/dsdt.c
+	$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c $< -o $@
+
+$(obj)/mainboard/$(MAINBOARDDIR)/auto.inc: $(src)/mainboard/$(MAINBOARDDIR)/cache_as_ram_auto.c $(obj)/option_table.h
+	$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(src) -I. -c -S  $(src)/mainboard/$(MAINBOARDDIR)/cache_as_ram_auto.c -o $@
+	perl -e 's/\.rodata/.rom.data/g' -pi $@
+	perl -e 's/\.text/.section .rom.text/g' -pi $@
+
+endif
+


Property changes on: trunk/coreboot-v2/src/mainboard/tyan/Makefile.s289x.inc
___________________________________________________________________
Added: svn:mergeinfo
   + 

Copied: trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig (from rev 4611, trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1,142 @@
+config BOARD_TYAN_S2891
+	bool "Tyan Thunder K8SRE S2891"
+	select ARCH_X86
+	select CPU_AMD_K8
+	select CPU_AMD_SOCKET_940
+	select NORTHBRIDGE_AMD_AMDK8
+	select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX
+	select SOUTHBRIDGE_NVIDIA_CK804
+	select SOUTHBRIDGE_AMD_AMD8131
+	select SUPERIO_WINBOND_W83627HF
+	select PIRQ_TABLE
+
+config MAINBOARD_DIR
+	string
+	default tyan/s2891
+	depends on BOARD_TYAN_S2891
+
+config APIC_ID_OFFSET
+	hex
+	default 8
+	depends on BOARD_TYAN_S2891
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2891
+
+config LB_CKS_RANGE_END
+	int
+	default 122
+	depends on BOARD_TYAN_S2891
+
+config LB_CKS_LOC
+	int
+        default 123
+	depends on BOARD_TYAN_S2891
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "s2891"
+	depends on BOARD_TYAN_S2891
+
+config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	default 0x2891
+	depends on BOARD_TYAN_S2891
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config HW_MEM_HOLE_SIZEK
+	hex
+	default 0x100000
+	depends on BOARD_TYAN_S2891
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config HAVE_FAILOVER_BOOT
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config MAX_CPUS
+	int
+	default 4
+	depends on BOARD_TYAN_S2891
+
+config MAX_PHYSICAL_CPUS
+	int
+	default 2
+	depends on BOARD_TYAN_S2891
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config AP_CODE_IN_CAR
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config HW_MEM_HOLE_SIZE_AUTO_INC
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0
+	depends on BOARD_TYAN_S2891
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x20
+	depends on BOARD_TYAN_S2891
+
+config USE_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config SERIAL_CPU_INIT
+	bool
+	default y
+	depends on BOARD_TYAN_S2891
+
+config AP_CODE_IN_CAR
+	bool
+	default y
+	depends on BOARD_TYAN_S2891
+
+config WAIT_BEFORE_CPUS_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2891
+
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY
+	bool
+	default n
+	depends on BOARD_TYAN_S2891
+
+config HAVE_ACPI_TABLES
+	bool "Generate ACPI tables"
+	default y
+	depends on BOARD_TYAN_S2891
+


Property changes on: trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig
___________________________________________________________________
Added: svn:mergeinfo
   + 

Added: trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1 @@
+include $(src)/mainboard/tyan/Makefile.s289x.inc

Copied: trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig (from rev 4611, trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1,142 @@
+config BOARD_TYAN_S2892
+	bool "Tyan Thunder K8SE S2892"
+	select ARCH_X86
+	select CPU_AMD_K8
+	select CPU_AMD_SOCKET_940
+	select NORTHBRIDGE_AMD_AMDK8
+	select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX
+	select SOUTHBRIDGE_NVIDIA_CK804
+	select SOUTHBRIDGE_AMD_AMD8131
+	select SUPERIO_WINBOND_W83627HF
+	select PIRQ_TABLE
+
+config MAINBOARD_DIR
+	string
+	default tyan/s2892
+	depends on BOARD_TYAN_S2892
+
+config APIC_ID_OFFSET
+	hex
+	default 8
+	depends on BOARD_TYAN_S2892
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2892
+
+config LB_CKS_RANGE_END
+	int
+	default 122
+	depends on BOARD_TYAN_S2892
+
+config LB_CKS_LOC
+	int
+        default 123
+	depends on BOARD_TYAN_S2892
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "s2892"
+	depends on BOARD_TYAN_S2892
+
+config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	default 0x2892
+	depends on BOARD_TYAN_S2892
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config HW_MEM_HOLE_SIZEK
+	hex
+	default 0x100000
+	depends on BOARD_TYAN_S2892
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config HAVE_FAILOVER_BOOT
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config MAX_CPUS
+	int
+	default 4
+	depends on BOARD_TYAN_S2892
+
+config MAX_PHYSICAL_CPUS
+	int
+	default 2
+	depends on BOARD_TYAN_S2892
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config AP_CODE_IN_CAR
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config HW_MEM_HOLE_SIZE_AUTO_INC
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0
+	depends on BOARD_TYAN_S2892
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x20
+	depends on BOARD_TYAN_S2892
+
+config USE_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config SERIAL_CPU_INIT
+	bool
+	default y
+	depends on BOARD_TYAN_S2892
+
+config AP_CODE_IN_CAR
+	bool
+	default y
+	depends on BOARD_TYAN_S2892
+
+config WAIT_BEFORE_CPUS_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2892
+
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY
+	bool
+	default n
+	depends on BOARD_TYAN_S2892
+
+config HAVE_ACPI_TABLES
+	bool "Generate ACPI tables"
+	default y
+	depends on BOARD_TYAN_S2892
+


Property changes on: trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig
___________________________________________________________________
Added: svn:mergeinfo
   + 

Added: trunk/coreboot-v2/src/mainboard/tyan/s2892/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2892/Makefile.inc	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2892/Makefile.inc	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1,3 @@
+include $(src)/mainboard/tyan/Makefile.s289x.inc
+
+driver-y += ../../../drivers/i2c/adm1027/adm1027.o

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/Config.lb	2009-09-22 18:53:50 UTC (rev 4656)
@@ -29,25 +29,10 @@
 end
 
 if CONFIG_USE_INIT
-if CONFIG_USE_FAILOVER_IMAGE
 	makerule ./auto.o
-		depends "$(CONFIG_MAINBOARD)/failover.c option_table.h"
-		action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/failover.c -o $@"
-	end
-else
-	makerule ./auto.o
 		depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h"
 		action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) -I$(TOP)/src -I. -c $(CONFIG_MAINBOARD)/cache_as_ram_auto.c -o $@"
 	end
-end
-else #CONFIG_USE_INIT
-if CONFIG_USE_FAILOVER_IMAGE
-	makerule ./auto.inc
-		depends "$(CONFIG_MAINBOARD)/failover.c option_table.h"
-		action "$(CC) $(DISTRO_CFLAGS) $(CFLAGS) $(CPPFLAGS) $(DEBUG_CFLAGS) -I$(TOP)/src -I. -c -S $(CONFIG_MAINBOARD)/failover.c -o $@"
-		action "perl -e 's/\.rodata/.rom.data/g' -pi $@"
-		action "perl -e 's/\.text/.section .rom.text/g' -pi $@"
-	end
 else
 	makerule ./auto.inc
 		depends "$(CONFIG_MAINBOARD)/cache_as_ram_auto.c option_table.h"
@@ -56,32 +41,51 @@
 		action "perl -e 's/\.text/.section .rom.text/g' -pi $@"
 	end
 end
-end #CONFIG_USE_INIT
 
 ##
 ## Build our 16 bit and 32 bit coreboot entry code
 ##
-if CONFIG_USE_FAILOVER_IMAGE
-	mainboardinit cpu/x86/16bit/entry16.inc
-	ldscript /cpu/x86/16bit/entry16.lds
+if CONFIG_HAVE_FAILOVER_BOOT
+	if CONFIG_USE_FAILOVER_IMAGE
+		mainboardinit cpu/x86/16bit/entry16.inc
+		ldscript /cpu/x86/16bit/entry16.lds
+	end
+else
+	if CONFIG_USE_FALLBACK_IMAGE
+		mainboardinit cpu/x86/16bit/entry16.inc
+		ldscript /cpu/x86/16bit/entry16.lds
+	end
 end
 
 mainboardinit cpu/x86/32bit/entry32.inc
 
 	if CONFIG_USE_INIT
 		ldscript /cpu/x86/32bit/entry32.lds
+	end
+
+	if CONFIG_USE_INIT
 		ldscript /cpu/amd/car/cache_as_ram.lds
 	end
 
 ##
 ## Build our reset vector (This is where coreboot is entered)
 ##
-if CONFIG_USE_FAILOVER_IMAGE
+if CONFIG_HAVE_FAILOVER_BOOT
+    if CONFIG_USE_FAILOVER_IMAGE
 	mainboardinit cpu/x86/16bit/reset16.inc
 	ldscript /cpu/x86/16bit/reset16.lds
+    else
+	mainboardinit cpu/x86/32bit/reset32.inc
+	ldscript /cpu/x86/32bit/reset32.lds
+    end
 else
+    if CONFIG_USE_FALLBACK_IMAGE
+	mainboardinit cpu/x86/16bit/reset16.inc
+	ldscript /cpu/x86/16bit/reset16.lds
+    else
 	mainboardinit cpu/x86/32bit/reset32.inc
 	ldscript /cpu/x86/32bit/reset32.lds
+    end
 end
 
 ##
@@ -93,9 +97,16 @@
 ##
 ## ROMSTRAP table for CK804
 ##
-if CONFIG_USE_FAILOVER_IMAGE
-	mainboardinit southbridge/nvidia/ck804/romstrap.inc
-	ldscript /southbridge/nvidia/ck804/romstrap.lds
+if CONFIG_HAVE_FAILOVER_BOOT
+	if CONFIG_USE_FAILOVER_IMAGE
+		mainboardinit southbridge/nvidia/ck804/romstrap.inc
+		ldscript /southbridge/nvidia/ck804/romstrap.lds
+	end
+else
+	if CONFIG_USE_FALLBACK_IMAGE
+		mainboardinit southbridge/nvidia/ck804/romstrap.inc
+		ldscript /southbridge/nvidia/ck804/romstrap.lds
+	end
 end
 
 ##
@@ -108,8 +119,14 @@
 ### Things are delicate and we test to see if we should
 ### failover to another image.
 ###
-if CONFIG_USE_FAILOVER_IMAGE
-	ldscript /arch/i386/lib/failover_failover.lds
+if CONFIG_HAVE_FAILOVER_BOOT
+	if CONFIG_USE_FAILOVER_IMAGE
+			ldscript /arch/i386/lib/failover_failover.lds
+	end
+else
+	if CONFIG_USE_FALLBACK_IMAGE
+			ldscript /arch/i386/lib/failover.lds
+	end
 end
 
 ##

Copied: trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig (from rev 4611, trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1,142 @@
+config BOARD_TYAN_S2895
+	bool "Tyan Thunder K8WE S2895"
+	select ARCH_X86
+	select CPU_AMD_K8
+	select CPU_AMD_SOCKET_940
+	select NORTHBRIDGE_AMD_AMDK8
+	select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX
+	select SOUTHBRIDGE_NVIDIA_CK804
+	select SOUTHBRIDGE_AMD_AMD8131
+	select SUPERIO_SMSC_LPC47B397
+	select PIRQ_TABLE
+
+config MAINBOARD_DIR
+	string
+	default tyan/s2895
+	depends on BOARD_TYAN_S2895
+
+config APIC_ID_OFFSET
+	hex
+	default 8
+	depends on BOARD_TYAN_S2895
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2895
+
+config LB_CKS_RANGE_END
+	int
+	default 122
+	depends on BOARD_TYAN_S2895
+
+config LB_CKS_LOC
+	int
+        default 123
+	depends on BOARD_TYAN_S2895
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "s2895"
+	depends on BOARD_TYAN_S2895
+
+config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	default 0x2895
+	depends on BOARD_TYAN_S2895
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config HW_MEM_HOLE_SIZEK
+	hex
+	default 0x100000
+	depends on BOARD_TYAN_S2895
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config HAVE_FAILOVER_BOOT
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config MAX_CPUS
+	int
+	default 4
+	depends on BOARD_TYAN_S2895
+
+config MAX_PHYSICAL_CPUS
+	int
+	default 2
+	depends on BOARD_TYAN_S2895
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config AP_CODE_IN_CAR
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config HW_MEM_HOLE_SIZE_AUTO_INC
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0
+	depends on BOARD_TYAN_S2895
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x20
+	depends on BOARD_TYAN_S2895
+
+config USE_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config SERIAL_CPU_INIT
+	bool
+	default y
+	depends on BOARD_TYAN_S2895
+
+config AP_CODE_IN_CAR
+	bool
+	default y
+	depends on BOARD_TYAN_S2895
+
+config WAIT_BEFORE_CPUS_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2895
+
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY
+	bool
+	default n
+	depends on BOARD_TYAN_S2895
+
+config HAVE_ACPI_TABLES
+	bool "Generate ACPI tables"
+	default y
+	depends on BOARD_TYAN_S2895
+


Property changes on: trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig
___________________________________________________________________
Added: svn:mergeinfo
   + 

Added: trunk/coreboot-v2/src/mainboard/tyan/s2895/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/Makefile.inc	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/Makefile.inc	2009-09-22 18:53:50 UTC (rev 4656)
@@ -0,0 +1 @@
+include $(src)/mainboard/tyan/Makefile.s289x.inc

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c	2009-09-22 18:53:50 UTC (rev 4656)
@@ -1,3 +1,4 @@
+#define ASSEMBLY 1
 #define __ROMCC__
 
 #define K8_ALLOCATE_IO_RANGE 1
@@ -20,12 +21,11 @@
 #include "option_table.h"
 #include "pc80/mc146818rtc_early.c"
 
-#define post_code(x) outb(x, 0x80)
+#if CONFIG_USE_FAILOVER_IMAGE==0
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
 #include "ram/ramtest.c"
 
-
 #include <cpu/amd/model_fxx_rev.h>
 
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -34,6 +34,8 @@
 #include "cpu/amd/model_fxx/apic_timer.c"
 #include "lib/delay.c"
 
+#endif
+
 #include "cpu/x86/lapic/boot_cpu.c"
 #include "northbridge/amd/amdk8/reset_test.c"
 #include "superio/smsc/lpc47b397/lpc47b397_early_serial.c"
@@ -42,6 +44,8 @@
 
 #define SUPERIO_GPIO_IO_BASE 0x400
 
+#if CONFIG_USE_FAILOVER_IMAGE==0
+
 #include "cpu/x86/bist.h"
 
 #include "northbridge/amd/amdk8/debug.c"
@@ -114,8 +118,117 @@
 
 #include "cpu/amd/model_fxx/init_cpus.c"
 
+#endif
+
+#if ((CONFIG_HAVE_FAILOVER_BOOT==1) && (CONFIG_USE_FAILOVER_IMAGE == 1)) || ((CONFIG_HAVE_FAILOVER_BOOT==0) && (CONFIG_USE_FALLBACK_IMAGE == 1))
+
+#include "southbridge/nvidia/ck804/ck804_enable_rom.c"
+#include "northbridge/amd/amdk8/early_ht.c"
+
+static void sio_setup(void)
+{
+
+	unsigned value;
+	uint32_t dword;
+	uint8_t byte;
+
+	pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1, 0), 0xac, 0x047f0400);
+
+	byte = pci_read_config8(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0x7b);
+	byte |= 0x20;
+	pci_write_config8(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0x7b, byte);
+
+	dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa0);
+	dword |= (1<<29)|(1<<0);
+	pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa0, dword);
+
+	dword = pci_read_config32(PCI_DEV(0, CK804_DEVN_BASE+1, 0), 0xa4);
+	dword |= (1<<16);
+	pci_write_config32(PCI_DEV(0, CK804_DEVN_BASE+1 , 0), 0xa4, dword);
+
+	lpc47b397_enable_serial(SUPERIO_GPIO_DEV, SUPERIO_GPIO_IO_BASE);
+	value = lpc47b397_gpio_offset_in(SUPERIO_GPIO_IO_BASE, 0x77);
+	value &= 0xbf;
+	lpc47b397_gpio_offset_out(SUPERIO_GPIO_IO_BASE, 0x77, value);
+
+}
+
+void failover_process(unsigned long bist, unsigned long cpu_init_detectedx)
+{
+	unsigned last_boot_normal_x = last_boot_normal();
+
+	/* Is this a cpu only reset? or Is this a secondary cpu? */
+	if ((cpu_init_detectedx) || (!boot_cpu())) {
+	if (last_boot_normal_x) {
+	goto normal_image;
+	} else {
+	goto fallback_image;
+	}
+	}
+
+	/* Nothing special needs to be done to find bus 0 */
+	/* Allow the HT devices to be found */
+
+	enumerate_ht_chain();
+
+	sio_setup();
+
+	/* Setup the ck804 */
+	ck804_enable_rom();
+
+	/* Is this a deliberate reset by the bios */
+//	post_code(0x22);
+	if (bios_reset_detected() && last_boot_normal_x) {
+	goto normal_image;
+	}
+	/* This is the primary cpu how should I boot? */
+	else if (do_normal_boot()) {
+	goto normal_image;
+	}
+	else {
+	goto fallback_image;
+	}
+ normal_image:
+//	post_code(0x23);
+	__asm__ volatile ("jmp __normal_image"
+	: /* outputs */
+	: "a" (bist), "b"(cpu_init_detectedx) /* inputs */
+	);
+
+ fallback_image:
+//	post_code(0x25);
+#if CONFIG_HAVE_FAILOVER_BOOT==1
+	__asm__ volatile ("jmp __fallback_image"
+	: /* outputs */
+	: "a" (bist), "b" (cpu_init_detectedx) /* inputs */
+	)
+#endif
+	;
+}
+#endif
+
+void real_main(unsigned long bist, unsigned long cpu_init_detectedx);
+
 void cache_as_ram_main(unsigned long bist, unsigned long cpu_init_detectedx)
 {
+#if CONFIG_HAVE_FAILOVER_BOOT==1
+	#if CONFIG_USE_FAILOVER_IMAGE==1
+	failover_process(bist, cpu_init_detectedx);
+	#else
+	real_main(bist, cpu_init_detectedx);
+	#endif
+#else
+	#if CONFIG_USE_FALLBACK_IMAGE == 1
+	failover_process(bist, cpu_init_detectedx);
+	#endif
+	real_main(bist, cpu_init_detectedx);
+#endif
+}
+
+#if CONFIG_USE_FAILOVER_IMAGE==0
+
+void real_main(unsigned long bist, unsigned long cpu_init_detectedx)
+{
 	static const uint16_t spd_addr [] = {
 		(0xa<<3)|0, (0xa<<3)|2, 0, 0,
 		(0xa<<3)|1, (0xa<<3)|3, 0, 0,
@@ -135,7 +248,7 @@
 		bsp_apicid = init_cpus(cpu_init_detectedx);
 	}
 
-	post_code(0x32);
+//	post_code(0x32);
 
 	lpc47b397_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE);
 	uart_init();
@@ -197,3 +310,4 @@
 
 	post_cache_as_ram();
 }
+#endif

Modified: trunk/coreboot-v2/src/southbridge/nvidia/ck804/Kconfig
===================================================================
--- trunk/coreboot-v2/src/southbridge/nvidia/ck804/Kconfig	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/src/southbridge/nvidia/ck804/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
@@ -1,3 +1,14 @@
 config SOUTHBRIDGE_NVIDIA_CK804
 	bool
 	default n
+
+config HAVE_HARD_RESET
+	bool
+	default y
+	depends on SOUTHBRIDGE_NVIDIA_CK804
+
+config IOAPIC
+	bool
+	default y
+	depends on SOUTHBRIDGE_NVIDIA_CK804
+

Modified: trunk/coreboot-v2/targets/tyan/s2895/Config-abuild.lb
===================================================================
--- trunk/coreboot-v2/targets/tyan/s2895/Config-abuild.lb	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/targets/tyan/s2895/Config-abuild.lb	2009-09-22 18:53:50 UTC (rev 4656)
@@ -24,11 +24,4 @@
 	payload __PAYLOAD__
 end
 
-romimage "failover"
-	option CONFIG_USE_FAILOVER_IMAGE=1
-	option CONFIG_USE_FALLBACK_IMAGE=0
-	option CONFIG_ROM_IMAGE_SIZE=CONFIG_FAILOVER_SIZE
-	option CONFIG_XIP_ROM_SIZE=CONFIG_FAILOVER_SIZE
-end
-
-buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback" "failover"
+buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback"

Modified: trunk/coreboot-v2/targets/tyan/s2895/Config.lb
===================================================================
--- trunk/coreboot-v2/targets/tyan/s2895/Config.lb	2009-09-22 18:49:08 UTC (rev 4655)
+++ trunk/coreboot-v2/targets/tyan/s2895/Config.lb	2009-09-22 18:53:50 UTC (rev 4656)
@@ -7,80 +7,21 @@
 
 # Tyan s2895
 romimage "normal"
-#       48K for SCSI FW
-#        option CONFIG_ROM_SIZE = 475136
-#       48K for SCSI FW and 48K for ATI ROM
-#       option CONFIG_ROM_SIZE = 425984 
-#       64K for Etherboot
-#        option CONFIG_ROM_SIZE = 458752 
-#	64K for NIC option 48K for Raid option rom
-#	option CONFIG_ROM_SIZE = 409600
 	option CONFIG_USE_FAILOVER_IMAGE=0
 	option CONFIG_USE_FALLBACK_IMAGE=0
-#	option CONFIG_ROM_IMAGE_SIZE=0x11800
-#	option CONFIG_ROM_IMAGE_SIZE=0x13800
-#	option CONFIG_ROM_IMAGE_SIZE=0x15000
 	option CONFIG_ROM_IMAGE_SIZE=0x20000
-#	option CONFIG_ROM_IMAGE_SIZE=0x17800
 	option CONFIG_XIP_ROM_SIZE=0x20000
 	option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Normal"
-#       payload ../../../payloads/tg3--ide_disk.zelf
-#        payload ../../../payloads/filo.elf
-#        payload ../../../payloads/filo_mem.elf
-#       payload ../../../payloads/filo.zelf
-#	payload ../../../payloads/tg3.zelf
-#	payload ../../../payloads/tg3--filo_hda2_vga.zelf
-#	payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf
-#	payload ../../../payloads/forcedeth_vga.zelf
-#	payload ../../../payloads/forcedeth--filo_hda2_vga_5_4.zelf
-#	payload ../../../../../../elf/ram0_2.5_2.6.11.tiny.elf
-#	payload ../../../../../../elf/ram0_2.5_2.6.12.tiny.elf
-#	payload ../../../payloads/tg3--filo_hda2_vga_5_4.zelf
-#	 payload ../../../payloads/tg3_vga.zelf
-#	payload ../../../payloads/tg3--filo_hda2_vgax.zelf
-#        payload ../../../payloads/tg3--filo_hda2_com2.zelf
-#       payload ../../../payloads/e1000--filo.zelf
-#        payload ../../../payloads/tg3--e1000--filo.zelf
-#        payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf
 	payload ../payload.elf
 end
 
 romimage "fallback" 
 	option CONFIG_USE_FAILOVER_IMAGE=0
 	option CONFIG_USE_FALLBACK_IMAGE=1
-#	option CONFIG_ROM_IMAGE_SIZE=0x11800
-#	option CONFIG_ROM_IMAGE_SIZE=0x13800
-#	option CONFIG_ROM_IMAGE_SIZE=0x15000
 	option CONFIG_ROM_IMAGE_SIZE=0x20000
-#	option CONFIG_ROM_IMAGE_SIZE=0x17800
 	option CONFIG_XIP_ROM_SIZE=0x20000
 	option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Fallback"
-#       payload ../../../payloads/tg3--ide_disk.zelf
-#        payload ../../../payloads/filo.elf
-#        payload ../../../payloads/filo_mem.elf
-#       payload ../../../payloads/filo.zelf
-#	payload ../../../payloads/tg3.zelf
-#	payload ../../../payloads/tg3--filo_hda2_vga.zelf
-#	payload ../../../../payloads/forcedeth--filo_hda2_vga.zelf
-#	payload ../../../payloads/forcedeth_vga.zelf
-#	payload ../../../payloads/tg3--filo_hda2_vga_5_4.zelf
-#	payload ../../../payloads/tg3_vga.zelf
-#	payload ../../../payloads/tg3--filo_hda2_vgax.zelf
-#        payload ../../../payloads/tg3--filo_hda2_com2.zelf
-#       payload ../../../payloads/e1000--filo.zelf
-#        payload ../../../payloads/tg3--e1000--filo.zelf
-#        payload ../../../payloads/tg3--eepro100--e1000--filo_hda2.zelf
 	payload ../payload.elf
 end
 
-romimage "failover"
-	option CONFIG_USE_FAILOVER_IMAGE=1
-        option CONFIG_USE_FALLBACK_IMAGE=0
-        option CONFIG_ROM_IMAGE_SIZE=CONFIG_FAILOVER_SIZE
-        option CONFIG_XIP_ROM_SIZE=CONFIG_FAILOVER_SIZE
-        option COREBOOT_EXTRA_VERSION="$(shell cat ../../VERSION)_Failover"
-end
-
-
-buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback" "failover"
-#buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback" 
+buildrom ./coreboot.rom CONFIG_ROM_SIZE "normal" "fallback"




From mylesgw at gmail.com  Tue Sep 22 20:56:27 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 12:56:27 -0600
Subject: [coreboot] Kconfig patches
In-Reply-To: <13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>
References: <2831fecf0909220951i40c96683na8e2f699bd82d47b@mail.gmail.com>
	<13426df10909221036p2a13b5cdt6cb39c3329e57db3@mail.gmail.com>
Message-ID: <2831fecf0909221156q59e47863vd7a65d42904db2af@mail.gmail.com>

On Tue, Sep 22, 2009 at 11:36 AM, ron minnich <rminnich at gmail.com> wrote:

> All are
> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
> I really like the tables cleanup too.
>
Thanks.


> We do need to get some of those k8 options out of mainboards, but
> that's a future fix.
>
I'm not sure where they should go.  I guess we'd have to go through them one
by one and suggest places.

General Kconfig patches committed in Rev 4655.  Tyan-specific patches in Rev
4656.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/fbfab418/attachment.html>

From info at coresystems.de  Tue Sep 22 21:14:18 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 21:14:18 +0200
Subject: [coreboot] build service results for r4655
Message-ID: <E1MqAoc-00036I-Fr@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4655 to
the coreboot repository. This caused the following 
changes:

Change Log:
tables.diff: Add Kconfig dialogues for ACPI, MP_TABLE, ...
Kconfig_bools.diff: Change some more ints to bools, change some default values.
xip_size.diff: Make XIP_SIZE + XIP_BASE add up to 4GB.
smp.diff: set CONFIG_SMP based on MAX_CPUS.


Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4655&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4655&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4655&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Tue Sep 22 21:51:57 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 21:51:57 +0200
Subject: [coreboot] build service results for r4656
Message-ID: <E1MqBP3-0007b8-MF@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4656 to
the coreboot repository. This caused the following 
changes:

Change Log:
failoverR.diff: Revert my failover change since Kconfig only supports fallback.
kconfig_s2892.dif: Add support for Tyan s2891, s2892, and s2895 to Kconfig.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4656&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4656&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4656&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Tue Sep 22 23:18:56 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 15:18:56 -0600
Subject: [coreboot] Another Kconfig patch
Message-ID: <2831fecf0909221418m733e8112o1deca881cb4e331e@mail.gmail.com>

This one lets me boot my s2895 to Linux.  The problem was that the AMD 8131
southbridge Makefile.inc depended on a typo and never got built.

This patch changes a few things that may be controversial, thanks for
reviewing.

src/Kconfig: Remove HT-specific options.
src/cpu/amd/socket_F/Kconfig: Remove second occurrence of CPU_SOCKET_TYPE.
src/mainboard/amd/serengeti_cheetah/Kconfig: Add HT_CHAIN_UNITID_BASE here,
since it is board specific.
src/mainboard/tyan/s289X/Kconfig: Fix typo and change APIC_ID_OFFSET to
match old config.
src/devices/Kconfig: Change default value of *_PLUGIN_SUPPORT to match old
config.
src/southbridge/amd/amd8131/Makefile.inc: Remove check since it was a typo,
and the correct variable is checked in the parent directory.
src/Makefile:Use devicetree.cb instead of Config.lb to generate static.c.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/0bd674a2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Kconfig_fixes.diff
Type: text/x-patch
Size: 4602 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/0bd674a2/attachment.diff>

From rminnich at gmail.com  Tue Sep 22 23:23:16 2009
From: rminnich at gmail.com (ron minnich)
Date: Tue, 22 Sep 2009 14:23:16 -0700
Subject: [coreboot] Another Kconfig patch
In-Reply-To: <2831fecf0909221418m733e8112o1deca881cb4e331e@mail.gmail.com>
References: <2831fecf0909221418m733e8112o1deca881cb4e331e@mail.gmail.com>
Message-ID: <13426df10909221423g1ab71468p23a5c898812b5729@mail.gmail.com>

On Tue, Sep 22, 2009 at 2:18 PM, Myles Watson <mylesgw at gmail.com> wrote:
> This one lets me boot my s2895 to Linux.? The problem was that the AMD 8131
> southbridge Makefile.inc depended on a typo and never got built.
>
> This patch changes a few things that may be controversial, thanks for
> reviewing.
>
> src/Kconfig: Remove HT-specific options.

Good!

> src/cpu/amd/socket_F/Kconfig: Remove second occurrence of CPU_SOCKET_TYPE.

good.

> src/mainboard/amd/serengeti_cheetah/Kconfig: Add HT_CHAIN_UNITID_BASE here,
> since it is board specific.

makes sense. There seems to be no reasonable default.

> src/mainboard/tyan/s289X/Kconfig: Fix typo and change APIC_ID_OFFSET to
> match old config.

fine.

> src/devices/Kconfig: Change default value of *_PLUGIN_SUPPORT to match old
> config.

fine.

> src/southbridge/amd/amd8131/Makefile.inc: Remove check since it was a typo,
> and the correct variable is checked in the parent directory.

yes, I thought we had killed all these; guess not.

> src/Makefile:Use devicetree.cb instead of Config.lb to generate static.c.
>

oops.

Acked-by: Ronald G. Minnich <rminnich at gmail.com>

Thanks

ron



From svn at coreboot.org  Tue Sep 22 23:29:32 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Tue, 22 Sep 2009 23:29:32 +0200
Subject: [coreboot] [v2] r4657 - in trunk/coreboot-v2: . src
	src/cpu/amd/socket_F src/devices
	src/mainboard/amd/serengeti_cheetah src/mainboard/tyan/s2891
	src/mainboard/tyan/s2892 src/mainboard/tyan/s2895
	src/southbridge/amd/amd8131
Message-ID: <mailman.3723.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-22 23:29:32 +0200 (Tue, 22 Sep 2009)
New Revision: 4657

Modified:
   trunk/coreboot-v2/Makefile
   trunk/coreboot-v2/src/Kconfig
   trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig
   trunk/coreboot-v2/src/devices/Kconfig
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig
   trunk/coreboot-v2/src/southbridge/amd/amd8131/Makefile.inc
Log:
src/Kconfig: Remove HT-specific options.
src/cpu/amd/socket_F/Kconfig: Remove second occurrence of CPU_SOCKET_TYPE.
src/mainboard/amd/serengeti_cheetah/Kconfig: Add HT_CHAIN_UNITID_BASE here, since it is board specific.
src/mainboard/tyan/s289X/Kconfig: Fix typo and change APIC_ID_OFFSET to match old config.
src/devices/Kconfig: Change default value of *_PLUGIN_SUPPORT to match old config.
src/southbridge/amd/amd8131/Makefile.inc: Remove check since it was a typo, and the correct variable is checked in the parent directory.
src/Makefile:Use devicetree.cb instead of Config.lb to generate static.c.


Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Modified: trunk/coreboot-v2/Makefile
===================================================================
--- trunk/coreboot-v2/Makefile	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/Makefile	2009-09-22 21:29:32 UTC (rev 4657)
@@ -111,7 +111,7 @@
 
 # needed objects that every mainboard uses 
 # Creation of these is architecture and mainboard independent
-$(obj)/mainboard/$(MAINBOARDDIR)/static.c: $(src)/mainboard/$(MAINBOARDDIR)/Config.lb  $(obj)/mainboard/$(MAINBOARDDIR)/config.py
+$(obj)/mainboard/$(MAINBOARDDIR)/static.c: $(src)/mainboard/$(MAINBOARDDIR)/devicetree.cb  $(obj)/mainboard/$(MAINBOARDDIR)/config.py
 	mkdir -p $(obj)/mainboard/$(MAINBOARDDIR)
 	(cd $(obj)/mainboard/$(MAINBOARDDIR) ; PYTHONPATH=$(top)/util/sconfig export PYTHONPATH; python config.py  $(MAINBOARDDIR) $(top) $(obj)/mainboard/$(MAINBOARDDIR))
 

Modified: trunk/coreboot-v2/src/Kconfig
===================================================================
--- trunk/coreboot-v2/src/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -84,14 +84,6 @@
 	bool
 	default n
 
-config HT_CHAIN_UNITID_BASE
-	hex
-	default 1
-
-config HT_CHAIN_END_UNITID_BASE
-	hex
-	default 0x20
-
 config HEAP_SIZE
 	hex
 	default 0x2000

Modified: trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/cpu/amd/socket_F/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -24,8 +24,3 @@
 	default 0x0104
 	depends on CPU_AMD_SOCKET_F
 
-config CPU_SOCKET_TYPE
-	hex
-	default 0x10
-	depends on CPU_AMD_SOCKET_F
-

Modified: trunk/coreboot-v2/src/devices/Kconfig
===================================================================
--- trunk/coreboot-v2/src/devices/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/devices/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -79,20 +79,20 @@
 
 config HYPERTRANSPORT_PLUGIN_SUPPORT
 	bool
-	default n
+	default y
 
 config PCIX_PLUGIN_SUPPORT
 	bool
-	default n
+	default y
 
 config PCIEXP_PLUGIN_SUPPORT
 	bool
-	default n
+	default y
 
 config AGP_PLUGIN_SUPPORT
 	bool
-	default n
+	default y
 
 config CARDBUS_PLUGIN_SUPPORT
 	bool
-	default n
+	default y

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -119,6 +119,11 @@
 	default 0x6
 	depends on BOARD_AMD_SERENGETI_CHEETAH
 
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0x1
+	depends on BOARD_AMD_SERENGETI_CHEETAH
+
 config USE_INIT
 	bool
 	default n

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -17,7 +17,7 @@
 
 config APIC_ID_OFFSET
 	hex
-	default 8
+	default 0x10
 	depends on BOARD_TYAN_S2891
 
 config SB_HT_CHAIN_ON_BUS0
@@ -40,7 +40,7 @@
 	default "s2891"
 	depends on BOARD_TYAN_S2891
 
-config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x2891
 	depends on BOARD_TYAN_S2891

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2892/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -17,7 +17,7 @@
 
 config APIC_ID_OFFSET
 	hex
-	default 8
+	default 0x10
 	depends on BOARD_TYAN_S2892
 
 config SB_HT_CHAIN_ON_BUS0
@@ -40,7 +40,7 @@
 	default "s2892"
 	depends on BOARD_TYAN_S2892
 
-config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x2892
 	depends on BOARD_TYAN_S2892

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/Kconfig	2009-09-22 21:29:32 UTC (rev 4657)
@@ -17,7 +17,7 @@
 
 config APIC_ID_OFFSET
 	hex
-	default 8
+	default 0x10
 	depends on BOARD_TYAN_S2895
 
 config SB_HT_CHAIN_ON_BUS0
@@ -40,7 +40,7 @@
 	default "s2895"
 	depends on BOARD_TYAN_S2895
 
-config CONFIG_MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
 	hex
 	default 0x2895
 	depends on BOARD_TYAN_S2895

Modified: trunk/coreboot-v2/src/southbridge/amd/amd8131/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/southbridge/amd/amd8131/Makefile.inc	2009-09-22 18:53:50 UTC (rev 4656)
+++ trunk/coreboot-v2/src/southbridge/amd/amd8131/Makefile.inc	2009-09-22 21:29:32 UTC (rev 4657)
@@ -1 +1 @@
-driver-$(SOUTHBRIDGE_AMD_AMD8131) += amd8131_bridge.o
\ No newline at end of file
+driver-y += amd8131_bridge.o




From mylesgw at gmail.com  Tue Sep 22 23:31:31 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 15:31:31 -0600
Subject: [coreboot] Another Kconfig patch
In-Reply-To: <13426df10909221423g1ab71468p23a5c898812b5729@mail.gmail.com>
References: <2831fecf0909221418m733e8112o1deca881cb4e331e@mail.gmail.com>
	<13426df10909221423g1ab71468p23a5c898812b5729@mail.gmail.com>
Message-ID: <2831fecf0909221431s567eacd9h2900f0dd7b23199e@mail.gmail.com>

> > src/southbridge/amd/amd8131/Makefile.inc: Remove check since it was a
> typo,
> > and the correct variable is checked in the parent directory.
>
> yes, I thought we had killed all these; guess not.
>
I looked and can't find any more.

Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
Rev 4657.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090922/696f6654/attachment.html>

From info at coresystems.de  Tue Sep 22 23:53:31 2009
From: info at coresystems.de (coreboot information)
Date: Tue, 22 Sep 2009 23:53:31 +0200
Subject: [coreboot] build service results for r4657
Message-ID: <E1MqDIh-0001Yc-Sv@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4657 to
the coreboot repository. This caused the following 
changes:

Change Log:
src/Kconfig: Remove HT-specific options.
src/cpu/amd/socket_F/Kconfig: Remove second occurrence of CPU_SOCKET_TYPE.
src/mainboard/amd/serengeti_cheetah/Kconfig: Add HT_CHAIN_UNITID_BASE here, since it is board specific.
src/mainboard/tyan/s289X/Kconfig: Fix typo and change APIC_ID_OFFSET to match old config.
src/devices/Kconfig: Change default value of *_PLUGIN_SUPPORT to match old config.
src/southbridge/amd/amd8131/Makefile.inc: Remove check since it was a typo, and the correct variable is checked in the parent directory.
src/Makefile:Use devicetree.cb instead of Config.lb to generate static.c.


Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4657&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4657&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4657&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Wed Sep 23 00:08:48 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 00:08:48 +0200
Subject: [coreboot] [v2] r4658 -
	trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah
Message-ID: <mailman.3724.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-23 00:08:47 +0200 (Wed, 23 Sep 2009)
New Revision: 4658

Modified:
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Makefile.inc
Log:
Fix compilation for serengeti when HAVE_ACPI_TABLES is set.  Trivial.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Makefile.inc	2009-09-22 21:29:32 UTC (rev 4657)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/Makefile.inc	2009-09-22 22:08:47 UTC (rev 4658)
@@ -32,7 +32,7 @@
 # ./ssdt.o is in northbridge/amd/amdk8/Config.lb
 obj-$(CONFIG_ACPI_SSDTX_NUM) += ssdt2.o
 obj-$(CONFIG_ACPI_SSDTX_NUM) += ssdt3.o
-obj-$(CONFIG_HAVE_ACPI_TABLES) += ssdt4.o
+obj-$(CONFIG_ACPI_SSDTX_NUM) += ssdt4.o
 driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o
 
 # This is part of the conversion to init-obj and away from included code.
@@ -59,8 +59,8 @@
 	-DCONFIG_USE_PRINTK_IN_CAR=1 \
 	-DCONFIG_HAVE_HIGH_TABLES=1
 
-$(obj)/dsdt.c: $(src)/mainboard/$(MAINBOARDDIR)/dsdt.asl
-	iasl -p dsdt -tc $(src)/mainboard/$(MAINBOARDDIR)/dsdt.asl
+$(obj)/dsdt.c: $(src)/mainboard/$(MAINBOARDDIR)/dx/dsdt_lb.dsl
+	iasl -p dsdt -tc $(src)/mainboard/$(MAINBOARDDIR)/dx/dsdt_lb.dsl
 	mv dsdt.hex $@
 
 $(obj)/mainboard/$(MAINBOARDDIR)/dsdt.o: $(obj)/dsdt.c




From info at coresystems.de  Wed Sep 23 00:33:19 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 00:33:19 +0200
Subject: [coreboot] build service results for r4658
Message-ID: <E1MqDvD-0004oB-20@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4658 to
the coreboot repository. This caused the following 
changes:

Change Log:
Fix compilation for serengeti when HAVE_ACPI_TABLES is set.  Trivial.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4658&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4658&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4658&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From daniel at caiaq.de  Wed Sep 23 03:54:13 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 03:54:13 +0200
Subject: [coreboot] [PATCH] buildrom/filo build fix
Message-ID: <20090923015413.GC9361@buzzloop.caiaq.de>

buildrom does not currently build filo due to a missing include path.
This fixes it.

---

Index: Makefile
===================================================================
--- Makefile	(revision 94)
+++ Makefile	(working copy)
@@ -76,7 +76,7 @@
 LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
 
 OBJS     := $(patsubst %,$(obj)/%,$(TARGETS-y))
-INCLUDES := -I$(INCPAYLOAD) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
+INCLUDES := -I$(INCPAYLOAD) -I$(INCPAYLOAD)/$(ARCHDIR-y) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
 INCLUDES += -I$(GCCINCDIR)
 
 try-run= $(shell set -e; \



From svn at coreboot.org  Wed Sep 23 05:07:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 05:07:31 +0200
Subject: [coreboot] [BuildROM] r275 - buildrom-devel/packages/filo
Message-ID: <mailman.3725.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-23 05:07:31 +0200 (Wed, 23 Sep 2009)
New Revision: 275

Modified:
   buildrom-devel/packages/filo/filo.mk
Log:
Bump the revision of filo to include CBFS support.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Myles Watson <mylesgw at gmail.com>



Modified: buildrom-devel/packages/filo/filo.mk
===================================================================
--- buildrom-devel/packages/filo/filo.mk	2009-09-18 19:47:06 UTC (rev 274)
+++ buildrom-devel/packages/filo/filo.mk	2009-09-23 03:07:31 UTC (rev 275)
@@ -1,5 +1,5 @@
 FILO_URL=svn://coreboot.org/filo/trunk/filo
-FILO_TAG=94
+FILO_TAG=105
 
 FILO_DIR=$(BUILD_DIR)/filo
 FILO_SRC_DIR=$(FILO_DIR)/svn




From mylesgw at gmail.com  Wed Sep 23 05:09:32 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Tue, 22 Sep 2009 21:09:32 -0600
Subject: [coreboot] [PATCH] buildrom/filo build fix
In-Reply-To: <20090923015413.GC9361@buzzloop.caiaq.de>
References: <20090923015413.GC9361@buzzloop.caiaq.de>
Message-ID: <B6BE4EE7815E4BB89E863E46DDDB5D95@chimp>

> buildrom does not currently build filo due to a missing include path.

> --- Makefile	(revision 94)
I just bumped the revision in buildrom to 105.  I'd been using 104
successfully, and 105 still builds, so I bumped it to 105.  Hopefully you
can build and use filo without changing it now.

Thanks,
Myles




From daniel at caiaq.de  Wed Sep 23 06:03:38 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 06:03:38 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090922115653.3513.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
Message-ID: <20090923040338.GE9361@buzzloop.caiaq.de>

On Tue, Sep 22, 2009 at 01:56:53PM +0200, Peter Stuge wrote:
> Daniel Mack wrote:
> > I'm developing on a CS5536 based board (ALIX.2D) and I'm trying to
> > get access to the GPIO registers in order to set the LEDs on
> > bootup.
> 
> Check out the 5536 data book on "Atomic Bit Programming" and/or look
> at the Linux LED driver for reference. To program the GPIOs you have
> to follow the algorithm outlined in 6.16.1.

Hmm. I followed that guideline, and did the same thing than the Linux
driver, but it still doesn't work. I only found one location from where
I could successfully write to the GPIO registers, and that is
hardware_stage1() in mainboard/pcengines/alix2c3/stage.c.

When moving the same code to southbridge_init() in
southbridge/amd/cs5536/cs5536.c, the register accesses fail.

Also, when booting Linux, the LED driver does not work with coreboot
for me. The register space mapping seems to be given up at some point
on the way, but I can't figure out where and why yet. As I don't know
coreboot's internals, I'd appreciate any pointer.

Thanks,
Daniel



From daniel at caiaq.de  Wed Sep 23 09:03:17 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 09:03:17 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923040338.GE9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
Message-ID: <20090923070317.GF9361@buzzloop.caiaq.de>

On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote:
> On Tue, Sep 22, 2009 at 01:56:53PM +0200, Peter Stuge wrote:
> > 
> > Check out the 5536 data book on "Atomic Bit Programming" and/or look
> > at the Linux LED driver for reference. To program the GPIOs you have
> > to follow the algorithm outlined in 6.16.1.
> 
> Hmm. I followed that guideline, and did the same thing than the Linux
> driver, but it still doesn't work. I only found one location from where
> I could successfully write to the GPIO registers, and that is
> hardware_stage1() in mainboard/pcengines/alix2c3/stage.c.
> 
> When moving the same code to southbridge_init() in
> southbridge/amd/cs5536/cs5536.c, the register accesses fail.
> 
> Also, when booting Linux, the LED driver does not work with coreboot
> for me. The register space mapping seems to be given up at some point
> on the way, but I can't figure out where and why yet. As I don't know
> coreboot's internals, I'd appreciate any pointer.

I traced a little further and implemented a cs5536_set_resources() which
simply wraps the call to pci_set_resources(). GPIO registers are
accessed ok before pci_set_resources() but fail after.

This is the output of print_resource_tree() of the device used:

(CB)  PCI: 00:0f.0 links 0 child on link 0 NULL
(CB)  PCI: 00:0f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags e0000100 index 0
(CB)  PCI: 00:0f.0 resource base 20b0 size 8 align 3 gran 3 limit ffff flags 40000100 index 10
(CB)  PCI: 00:0f.0 resource base 1800 size 100 align 8 gran 8 limit ffff flags 40000100 index 14
(CB)  PCI: 00:0f.0 resource base 2000 size 40 align 6 gran 6 limit ffff flags 40000100 index 18
(CB)  PCI: 00:0f.0 resource base 2080 size 20 align 5 gran 5 limit ffff flags 40000100 index 1c
(CB)  PCI: 00:0f.0 resource base 1c00 size 80 align 7 gran 7 limit ffff flags 40000100 index 20
(CB)  PCI: 00:0f.0 resource base 2040 size 40 align 6 gran 6 limit ffff flags 40000100 index 24


Any ideas?

Daniel



From stepan at coresystems.de  Wed Sep 23 11:43:02 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Wed, 23 Sep 2009 11:43:02 +0200
Subject: [coreboot] [PATCH] buildrom/filo build fix
In-Reply-To: <20090923015413.GC9361@buzzloop.caiaq.de>
References: <20090923015413.GC9361@buzzloop.caiaq.de>
Message-ID: <4AB9EDA6.1050908@coresystems.de>

Daniel Mack wrote:
> buildrom does not currently build filo due to a missing include path.
> This fixes it.
>
> ---
>
> Index: Makefile
> ===================================================================
> --- Makefile	(revision 94)
> +++ Makefile	(working copy)
> @@ -76,7 +76,7 @@
>  LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
>  
>  OBJS     := $(patsubst %,$(obj)/%,$(TARGETS-y))
> -INCLUDES := -I$(INCPAYLOAD) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
> +INCLUDES := -I$(INCPAYLOAD) -I$(INCPAYLOAD)/$(ARCHDIR-y) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
>  INCLUDES += -I$(GCCINCDIR)
>  
>  try-run= $(shell set -e; \
>
>   
What's your error without this? Is that a patch against FILO?

Stefan



From daniel at caiaq.de  Wed Sep 23 11:54:32 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 11:54:32 +0200
Subject: [coreboot] [PATCH] buildrom/filo build fix
In-Reply-To: <4AB9EDA6.1050908@coresystems.de>
References: <20090923015413.GC9361@buzzloop.caiaq.de>
	<4AB9EDA6.1050908@coresystems.de>
Message-ID: <20090923095432.GD18340@buzzloop.caiaq.de>

On Wed, Sep 23, 2009 at 11:43:02AM +0200, Stefan Reinauer wrote:
> Daniel Mack wrote:
> > buildrom does not currently build filo due to a missing include path.
> > This fixes it.
> >
> > ---
> >
> > Index: Makefile
> > ===================================================================
> > --- Makefile	(revision 94)
> > +++ Makefile	(working copy)
> > @@ -76,7 +76,7 @@
> >  LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> >  
> >  OBJS     := $(patsubst %,$(obj)/%,$(TARGETS-y))
> > -INCLUDES := -I$(INCPAYLOAD) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
> > +INCLUDES := -I$(INCPAYLOAD) -I$(INCPAYLOAD)/$(ARCHDIR-y) -Iinclude -I$(ARCHDIR-y)/include -Ibuild
> >  INCLUDES += -I$(GCCINCDIR)
> >  
> >  try-run= $(shell set -e; \
> >
> >   
> What's your error without this? Is that a patch against FILO?

It couldn't find arch specific includes. But it was all due to an old
version of filo - the fix went in upstream with r98.
Buildrom uses r104 now, so it's all fine.

Sorry for the noise.

Daniel



From daniel at caiaq.de  Wed Sep 23 12:31:01 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 12:31:01 +0200
Subject: [coreboot] [PATCH] FILO: parse old ext2 revisions correctly
Message-ID: <20090923103101.GN9410@buzzloop.caiaq.de>

This patch applies against r104 of filo and allows older versions of
ext2 file systems to be accessed. The problem with the current code is
that EXT2_INODE_SIZE() returns 0 for these file systems and the
EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a
div0 and sends the machine to reboot.

Below is a fix for that.

Signed-off-by: Daniel Mack <daniel at caiaq.de>

Index: fs/fsys_ext2fs.c
===================================================================
--- fs/fsys_ext2fs.c	(revision 105)
+++ fs/fsys_ext2fs.c	(working copy)
@@ -253,10 +253,18 @@
     ((char *)((char *)DATABLOCK1 + EXT2_BLOCK_SIZE(SUPERBLOCK)))
 
 /* linux/ext2_fs.h */
+
+#define EXT2_OLD_REV		0	/* The good old (original) format */
+#define EXT2_DYNAMIC_REV	1	/* V2 format w/ dynamic inode sizes */
+
+#define EXT2_OLD_INODE_SIZE	128
+
 #define EXT2_ADDR_PER_BLOCK(s)          (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
 #define EXT2_ADDR_PER_BLOCK_BITS(s)	(log2(EXT2_ADDR_PER_BLOCK(s)))
 
-#define EXT2_INODE_SIZE(s)             (SUPERBLOCK->s_inode_size)
+#define EXT2_INODE_SIZE(s)		(((s)->s_rev_level == EXT2_OLD_REV) ? \
+					EXT2_OLD_INODE_SIZE : (s)->s_inode_size)
+
 #define EXT2_INODES_PER_BLOCK(s)       (EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
 
 /* linux/ext2_fs.h */
@@ -287,6 +295,7 @@
     printf("  b_free=%d\n", le32_to_cpu(s->s_free_blocks_count));
     printf("  first=%d\n", le32_to_cpu(s->s_first_data_block));
     printf("  log_b_size=%d, b_size=%d\n", le32_to_cpu(s->s_log_block_size), EXT2_BLOCK_SIZE(s));
+    printf("  inode_size=%d\n", le32_to_cpu(EXT2_INODE_SIZE(s)));
     printf("  log_f_size=%d\n", le32_to_cpu(s->s_log_frag_size));
     printf("  bpg=%d\n", le32_to_cpu(s->s_blocks_per_group));
     printf("  fpg=%d\n", le32_to_cpu(s->s_frags_per_group));

----- End forwarded message -----



From fishbaoz at hotmail.com  Wed Sep 23 15:29:40 2009
From: fishbaoz at hotmail.com (Zheng Bao)
Date: Wed, 23 Sep 2009 13:29:40 +0000
Subject: [coreboot] Coreboot or UEFI, who will be the winner.
Message-ID: <COL112-W13D2CF2632309BF57FB808CDDB0@phx.gbl>


I got a brief UEFI introduction. It seems that it is pretty close to coreboot.

They have same goal and face same problem. Any idea?

 

Zheng
 		 	   		  
_________________________________________________________________
Windows Live?: Keep your life in sync. Check it out!
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/6daafc2d/attachment.html>

From c-d.hailfinger.devel.2006 at gmx.net  Wed Sep 23 15:54:47 2009
From: c-d.hailfinger.devel.2006 at gmx.net (Carl-Daniel Hailfinger)
Date: Wed, 23 Sep 2009 15:54:47 +0200
Subject: [coreboot] Coreboot or UEFI, who will be the winner.
In-Reply-To: <COL112-W13D2CF2632309BF57FB808CDDB0@phx.gbl>
References: <COL112-W13D2CF2632309BF57FB808CDDB0@phx.gbl>
Message-ID: <4ABA28A7.8080302@gmx.net>

On 23.09.2009 15:29, Zheng Bao wrote:
> I got a brief UEFI introduction. It seems that it is pretty close to coreboot.
>
> They have same goal and face same problem. Any idea?
>   

I think there are quite some differences which make coreboot the better
solution:
- The lowlevel parts of UEFI are closed source.
- UEFI is bigger/bloated.
- UEFI stays resident in memory.
- UEFI has to provide network/disk/video drivers which can/should be
used by the OS.

And if someone really wants EFI functionality, it is possible to run
UEFI as a coreboot payload. Besides that, if you want a completely
opensource firmware with UEFI, you have to use coreboot+UEFI because the
chipset/CPU init in UEFI is not open source.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/




From mylesgw at gmail.com  Wed Sep 23 15:58:47 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 07:58:47 -0600
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923070317.GF9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de><20090922115653.3513.qmail@stuge.se><20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923070317.GF9361@buzzloop.caiaq.de>
Message-ID: <861D838AF19D458E9138B67E3BF0225F@chimp>

> I traced a little further and implemented a cs5536_set_resources() which
> simply wraps the call to pci_set_resources(). GPIO registers are
> accessed ok before pci_set_resources() but fail after.
Sounds like the address where you access the resource is changing after
resource allocation.  You have a couple of options:
1. Use the new address after pci_set_resources
2. Don't use pci_set_resources to allocate that resource
	(Set up that resource as fixed)

I think #1 is the best, unless you have to have that address at a specific
location.

> This is the output of print_resource_tree() of the device used:

I don't know enough about it to know which of these resources is the one
you're looking for, but you can look through the code to see where the GPIO
registers are set up.

> (CB)  PCI: 00:0f.0 links 0 child on link 0 NULL
> (CB)  PCI: 00:0f.0 resource base 0 size 1000 align 0 gran 0 limit 0 flags
> e0000100 index 0
> (CB)  PCI: 00:0f.0 resource base 20b0 size 8 align 3 gran 3 limit ffff
> flags 40000100 index 10
> (CB)  PCI: 00:0f.0 resource base 1800 size 100 align 8 gran 8 limit ffff
> flags 40000100 index 14
> (CB)  PCI: 00:0f.0 resource base 2000 size 40 align 6 gran 6 limit ffff
> flags 40000100 index 18
> (CB)  PCI: 00:0f.0 resource base 2080 size 20 align 5 gran 5 limit ffff
> flags 40000100 index 1c
> (CB)  PCI: 00:0f.0 resource base 1c00 size 80 align 7 gran 7 limit ffff
> flags 40000100 index 20
> (CB)  PCI: 00:0f.0 resource base 2040 size 40 align 6 gran 6 limit ffff
> flags 40000100 index 24

Good luck,
Myles




From svn at coreboot.org  Wed Sep 23 16:12:31 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 16:12:31 +0200
Subject: [coreboot] [FILO] r106 - trunk/filo/fs
Message-ID: <mailman.3726.1355071620.16123.coreboot@coreboot.org>

Author: stuge
Date: 2009-09-23 16:12:31 +0200 (Wed, 23 Sep 2009)
New Revision: 106

Modified:
   trunk/filo/fs/fsys_ext2fs.c
Log:
Fix EXT2_INODE_SIZE() for original format ext2 filesystems

This patch applies against r104 of filo and allows older versions of
ext2 file systems to be accessed. The problem with the current code is
that EXT2_INODE_SIZE() returns 0 for these file systems and the
EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a
div0 and sends the machine to reboot.

Below is a fix for that.

Signed-off-by: Daniel Mack <daniel at caiaq.de>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/filo/fs/fsys_ext2fs.c
===================================================================
--- trunk/filo/fs/fsys_ext2fs.c	2009-08-27 22:52:37 UTC (rev 105)
+++ trunk/filo/fs/fsys_ext2fs.c	2009-09-23 14:12:31 UTC (rev 106)
@@ -253,10 +253,16 @@
     ((char *)((char *)DATABLOCK1 + EXT2_BLOCK_SIZE(SUPERBLOCK)))
 
 /* linux/ext2_fs.h */
+#define EXT2_OLD_REV           0       /* The good old (original) format */
+#define EXT2_DYNAMIC_REV       1       /* V2 format w/ dynamic inode sizes */
+
+#define EXT2_OLD_INODE_SIZE    128
+
 #define EXT2_ADDR_PER_BLOCK(s)          (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
 #define EXT2_ADDR_PER_BLOCK_BITS(s)	(log2(EXT2_ADDR_PER_BLOCK(s)))
 
-#define EXT2_INODE_SIZE(s)             (SUPERBLOCK->s_inode_size)
+#define EXT2_INODE_SIZE(s)             (((s)->s_rev_level == EXT2_OLD_REV) ? \
+                                       EXT2_OLD_INODE_SIZE : (s)->s_inode_size)
 #define EXT2_INODES_PER_BLOCK(s)       (EXT2_BLOCK_SIZE(s)/EXT2_INODE_SIZE(s))
 
 /* linux/ext2_fs.h */
@@ -287,6 +293,7 @@
     printf("  b_free=%d\n", le32_to_cpu(s->s_free_blocks_count));
     printf("  first=%d\n", le32_to_cpu(s->s_first_data_block));
     printf("  log_b_size=%d, b_size=%d\n", le32_to_cpu(s->s_log_block_size), EXT2_BLOCK_SIZE(s));
+    printf("  inode_size=%d\n", le32_to_cpu(EXT2_INODE_SIZE(s)));
     printf("  log_f_size=%d\n", le32_to_cpu(s->s_log_frag_size));
     printf("  bpg=%d\n", le32_to_cpu(s->s_blocks_per_group));
     printf("  fpg=%d\n", le32_to_cpu(s->s_frags_per_group));




From peter at stuge.se  Wed Sep 23 16:12:44 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 16:12:44 +0200
Subject: [coreboot] [PATCH] FILO: parse old ext2 revisions correctly
In-Reply-To: <20090923103101.GN9410@buzzloop.caiaq.de>
References: <20090923103101.GN9410@buzzloop.caiaq.de>
Message-ID: <20090923141244.25726.qmail@stuge.se>

Daniel Mack wrote:
> This patch applies against r104 of filo and allows older versions of
> ext2 file systems to be accessed. The problem with the current code is
> that EXT2_INODE_SIZE() returns 0 for these file systems and the
> EXT2_INODES_PER_BLOCK() uses that value in a calculation which causes a
> div0 and sends the machine to reboot.
> 
> Below is a fix for that.
> 
> Signed-off-by: Daniel Mack <daniel at caiaq.de>

Thanks. r106



From mansoor at iwavesystems.com  Wed Sep 23 16:20:14 2009
From: mansoor at iwavesystems.com (Mansoor)
Date: Wed, 23 Sep 2009 19:50:14 +0530
Subject: [coreboot] getpir patch
Message-ID: <200909231422.n8NEM1UV008828@mail.iwavesystems.com>

This patch changes following in getpir application.

 

1 - Moved the check sum validation to probe_table function.

2 - Proper handling of resources allocated.

3 - Signature check is done in 16 byte boundaries.

4 - irq_tables.c file is created only if a valid PIRQ table is found.

5 - Makefile and README file are modified accordingly.

 

Signed-off-by: Mohamed Mansoor <mansoor at iwavesystems.com> 

 

 


------------------------------------------------------------------------------- 
DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
intended recipient (s) only. It may contain proprietary material, confidential
information and/or be subject to the legal privilege of iWave Systems
Technologies Private Limited. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from retaining,
using, copying, alerting or disclosing the content of this message. Thank you
for your co-operation. 
------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/e52cce84/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: getpir.patch
Type: application/octet-stream
Size: 3850 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/e52cce84/attachment.obj>

From rminnich at gmail.com  Wed Sep 23 16:39:18 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Sep 2009 07:39:18 -0700
Subject: [coreboot] Coreboot or UEFI, who will be the winner.
In-Reply-To: <4ABA28A7.8080302@gmx.net>
References: <COL112-W13D2CF2632309BF57FB808CDDB0@phx.gbl>
	<4ABA28A7.8080302@gmx.net>
Message-ID: <13426df10909230739v1d103cbfv5142d1a4f1ab94b5@mail.gmail.com>

The killer for uefi for me are the security concerns.

For many outfits, nowadays, the closed nature, and the limited
control, of UEFI is worrisome.

Here's a simple rule: open source almost always wins. I've seen almost
no exceptions save maybe in compilers, and that only in special cases.
Open source is the water that wears down the rock.

There's more and more interest in the last two years in coreboot.
Customers really want it.

It's just that PC vendors are worried about providing it for some reason.

PC vendors need to be careful, they're building closed ecosystems now
around the PC platform. It's quite amazing how much more closed the PC
platform is than it was in 1994 or even 1999.

Closed ecosystems die.

Here at linuxcon and other recent conferences, all the real innovation
and cool stuff is ARM-based. PCs are those big, expensive, hot, closed
things that you're not allowed to hack. Really wonderful stuff being
done on OMAP 35.

ron



From ward at gnu.org  Wed Sep 23 17:52:26 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 23 Sep 2009 11:52:26 -0400
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923040338.GE9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
Message-ID: <20090923155226.GA29110@countzero.vandewege.net>

On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote:
> Also, when booting Linux, the LED driver does not work with coreboot
> for me. 

Yeah, known issue. The linux kernel driver stupidly assumes that all firmware
sets up the GPIOs at the same IO port. The kernel driver should look up the
msr and then do the right thing, but it does not.

I think Peter Stuge may have a patch for the LED driver...

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From peter at stuge.se  Wed Sep 23 17:52:35 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 17:52:35 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923040338.GE9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
Message-ID: <20090923155235.13441.qmail@stuge.se>

Daniel Mack wrote:
> Also, when booting Linux, the LED driver does not work with
> coreboot for me.

The issue is that the driver is using a hard coded base address
rather than finding out what is actually programmed into the device,
and because coreboot doesn't assign resources exactly like the
factory BIOS, the driver can't find the hardware.

The driver should be improved to read the base address from the MSR,
then it would work everywhere.

Another sad fact is that the driver scans the BIOS 0xf0000 segment
for a particular string which is present in the factory BIOS, but not
in coreboot. I believe there is an override.

You may find msrtool helpful since it knows a bit about Geode,
although not nearly everything. It's good with the DIVIL and
interrupts.


boot factory BIOS
# msrtool -l -s file
this saves a list of known MSRs along with their values into file

boot coreboot
# msrtool -d file
this shows decoded MSR differences between saved and current values


//Peter



From peter at stuge.se  Wed Sep 23 17:54:23 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 17:54:23 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923155226.GA29110@countzero.vandewege.net>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155226.GA29110@countzero.vandewege.net>
Message-ID: <20090923155424.13827.qmail@stuge.se>

Ward Vandewege wrote:
> I think Peter Stuge may have a patch for the LED driver...

If I do it's on a hard drive that I can't find anymore. It's not a
terribly complex change, but the mere thought of cloning the led-2.6
tree is a little exhausting.


//Peter



From mylesgw at gmail.com  Wed Sep 23 18:01:21 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 10:01:21 -0600
Subject: [coreboot] Tyan s2881 Kconfig
Message-ID: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>

I realize that these boards are old.  If I were new to coreboot and wanted
to experiment with it, I might be looking at boards like this one.  You can
get them for $39 with 2 CPUs (refurbished).

Build tested but not boot tested.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/5133ac2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tyan.diff
Type: text/x-patch
Size: 4065 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/5133ac2b/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i2c.diff
Type: text/x-patch
Size: 1698 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/5133ac2b/attachment-0001.diff>

From mylesgw at gmail.com  Wed Sep 23 18:02:49 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 10:02:49 -0600
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923155235.13441.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
Message-ID: <2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>

On Wed, Sep 23, 2009 at 9:52 AM, Peter Stuge <peter at stuge.se> wrote:

> Daniel Mack wrote:
> > Also, when booting Linux, the LED driver does not work with
> > coreboot for me.
>
> The issue is that the driver is using a hard coded base address
> rather than finding out what is actually programmed into the device,
> and because coreboot doesn't assign resources exactly like the
> factory BIOS, the driver can't find the hardware.
>
Depending on the address, that could be easy to fix.  If it is below 0x1000
it is almost trivial.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/68a265e0/attachment.html>

From peter at stuge.se  Wed Sep 23 18:04:57 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 18:04:57 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
	<2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
Message-ID: <20090923160457.15745.qmail@stuge.se>

Myles Watson wrote:
> > > Also, when booting Linux, the LED driver does not work with
> > > coreboot for me.
> >
> > The issue is that the driver is using a hard coded base address
> > rather than finding out what is actually programmed into the device,
> > and because coreboot doesn't assign resources exactly like the
> > factory BIOS, the driver can't find the hardware.
> 
> Depending on the address, that could be easy to fix.  If it is
> below 0x1000 it is almost trivial.

It's at 6000 something, and I don't like to. I would much prefer the
driver not make assumptions for no da^Wreason.


//Peter



From mylesgw at gmail.com  Wed Sep 23 18:08:20 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 10:08:20 -0600
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923160457.15745.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
	<2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
	<20090923160457.15745.qmail@stuge.se>
Message-ID: <2831fecf0909230908m3d890265o5dca0e916936cbd2@mail.gmail.com>

On Wed, Sep 23, 2009 at 10:04 AM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > > > Also, when booting Linux, the LED driver does not work with
> > > > coreboot for me.
> > >
> > > The issue is that the driver is using a hard coded base address
> > > rather than finding out what is actually programmed into the device,
> > > and because coreboot doesn't assign resources exactly like the
> > > factory BIOS, the driver can't find the hardware.
> >
> > Depending on the address, that could be easy to fix.  If it is
> > below 0x1000 it is almost trivial.
>
> It's at 6000 something,

So that would be easy too.


> and I don't like to. I would much prefer the
> driver not make assumptions for no da^Wreason.
>
Agreed.  I guess it comes down to making changes where you can.  Have you
filed a bug report with the driver's authors?

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/23d8fdc9/attachment.html>

From ward at gnu.org  Wed Sep 23 18:09:49 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 23 Sep 2009 12:09:49 -0400
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923160457.15745.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
	<2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
	<20090923160457.15745.qmail@stuge.se>
Message-ID: <20090923160949.GA30646@countzero.vandewege.net>

On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote:
> Myles Watson wrote:
> > > > Also, when booting Linux, the LED driver does not work with
> > > > coreboot for me.
> > >
> > > The issue is that the driver is using a hard coded base address
> > > rather than finding out what is actually programmed into the device,
> > > and because coreboot doesn't assign resources exactly like the
> > > factory BIOS, the driver can't find the hardware.
> > 
> > Depending on the address, that could be easy to fix.  If it is
> > below 0x1000 it is almost trivial.
> 
> It's at 6000 something, and I don't like to. I would much prefer the
> driver not make assumptions for no da^Wreason.

I think the driver assumes

  CS5536_BASE = 0x06100

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From rminnich at gmail.com  Wed Sep 23 18:56:31 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Sep 2009 09:56:31 -0700
Subject: [coreboot] Tyan s2881 Kconfig
In-Reply-To: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
References: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
Message-ID: <13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>

Currently, because they are so simple, we don't have makefile.inc
files for i2c drivers. see serengeti_cheetah:
driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o

This is admittedly inconsistent, but it saves a lot of unnecessary
makefile.inc stuff.

So I don't think we need the Makefile.inc for the i2c parts.

$39 for those boards is pretty attractive, do you have a link?

ron



From daniel at caiaq.de  Wed Sep 23 19:10:02 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 23 Sep 2009 19:10:02 +0200
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923160457.15745.qmail@stuge.se>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
	<2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
	<20090923160457.15745.qmail@stuge.se>
Message-ID: <20090923171002.GH9361@buzzloop.caiaq.de>

On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote:
> Myles Watson wrote:
> > > > Also, when booting Linux, the LED driver does not work with
> > > > coreboot for me.
> > >
> > > The issue is that the driver is using a hard coded base address
> > > rather than finding out what is actually programmed into the device,
> > > and because coreboot doesn't assign resources exactly like the
> > > factory BIOS, the driver can't find the hardware.
> > 
> > Depending on the address, that could be easy to fix.  If it is
> > below 0x1000 it is almost trivial.
> 
> It's at 6000 something, and I don't like to. I would much prefer the
> driver not make assumptions for no da^Wreason.

Could you outline which steps would need to be taken in order to find
out the correct address to use? Any maybe a way to sany detect the
precence of that function on the board? I might go ahead and send a
patch for the driver then.

Thanks,
Daniel



From mylesgw at gmail.com  Wed Sep 23 19:13:11 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 11:13:11 -0600
Subject: [coreboot] Tyan s2881 Kconfig
In-Reply-To: <13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
References: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
	<13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
Message-ID: <2831fecf0909231013l6c8eae25t6600e7389c8befa8@mail.gmail.com>

On Wed, Sep 23, 2009 at 10:56 AM, ron minnich <rminnich at gmail.com> wrote:

> Currently, because they are so simple, we don't have makefile.inc
> files for i2c drivers. see serengeti_cheetah:
> driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o
>
Should it be a driver? In the old config it was just an object.


> This is admittedly inconsistent, but it saves a lot of unnecessary
> makefile.inc stuff.
>
No problem.  I just missed it.


> $39 for those boards is pretty attractive, do you have a link?
>
http://www.pacificgeek.com/product.asp?id=847374

$35 if you buy 100 or more :)

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/94d2272f/attachment.html>

From tsylla at gmail.com  Wed Sep 23 19:25:21 2009
From: tsylla at gmail.com (Tom Sylla)
Date: Wed, 23 Sep 2009 13:25:21 -0400
Subject: [coreboot] GPIOs on CS5536 based boards
In-Reply-To: <20090923171002.GH9361@buzzloop.caiaq.de>
References: <20090922114528.GA9361@buzzloop.caiaq.de>
	<20090922115653.3513.qmail@stuge.se>
	<20090923040338.GE9361@buzzloop.caiaq.de>
	<20090923155235.13441.qmail@stuge.se>
	<2831fecf0909230902o2a08995fi48a9fcaea49916fd@mail.gmail.com>
	<20090923160457.15745.qmail@stuge.se>
	<20090923171002.GH9361@buzzloop.caiaq.de>
Message-ID: <57947bf80909231025j6de313b3ob9e7942cc58783ec@mail.gmail.com>

On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack <daniel at caiaq.de> wrote:
> Could you outline which steps would need to be taken in order to find
> out the correct address to use? Any maybe a way to sany detect the
> precence of that function on the board? I might go ahead and send a
> patch for the driver then.

Not really an outline; it is just one MSR read. Take a look at the
GPIO kernel driver:

http://lxr.linux.no/#linux+v2.6.31/drivers/char/cs5535_gpio.c#L188

Also, to correct the 0xF0000 scan ickiness, the proper way to detect a
board revision is usually done by reading a PCI subvendor/subdevice ID
too. I don't know if alix's non-coreboot BIOS does that properly.



From mylesgw at gmail.com  Wed Sep 23 19:38:11 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 11:38:11 -0600
Subject: [coreboot] Tyan s2881 Kconfig
In-Reply-To: <13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
References: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
	<13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
Message-ID: <2831fecf0909231038y5bfa5edejb4fa39b46ea472ce@mail.gmail.com>

On Wed, Sep 23, 2009 at 10:56 AM, ron minnich <rminnich at gmail.com> wrote:

> Currently, because they are so simple, we don't have makefile.inc
> files for i2c drivers. see serengeti_cheetah:
> driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o
>
Second try.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/b5a913f6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tyan.diff
Type: text/x-patch
Size: 4399 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/b5a913f6/attachment.diff>

From mylesgw at gmail.com  Wed Sep 23 19:41:42 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 11:41:42 -0600
Subject: [coreboot] [PATCH] Compression fix
Message-ID: <2831fecf0909231041h4bbb3fdh2938ea492fe4784e@mail.gmail.com>

Separate payload compression from stage compression.  I figured out why
sometimes my coreboot_ram was 40K and sometimes it was 250K.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/21e99d6c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compression.diff
Type: text/x-patch
Size: 1453 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/21e99d6c/attachment.diff>

From peter at stuge.se  Wed Sep 23 19:44:50 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 19:44:50 +0200
Subject: [coreboot] [PATCH] Compression fix
In-Reply-To: <2831fecf0909231041h4bbb3fdh2938ea492fe4784e@mail.gmail.com>
References: <2831fecf0909231041h4bbb3fdh2938ea492fe4784e@mail.gmail.com>
Message-ID: <20090923174450.2045.qmail@stuge.se>

Myles Watson wrote:
> Separate payload compression from stage compression.  I figured out why
> sometimes my coreboot_ram was 40K and sometimes it was 250K.
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>

Acked-by: Peter Stuge <peter at stuge.se>



From svn at coreboot.org  Wed Sep 23 19:48:28 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 19:48:28 +0200
Subject: [coreboot] [v2] r4659 - in trunk/coreboot-v2: . src/arch/i386
Message-ID: <mailman.3727.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-23 19:48:28 +0200 (Wed, 23 Sep 2009)
New Revision: 4659

Modified:
   trunk/coreboot-v2/Makefile
   trunk/coreboot-v2/src/arch/i386/Makefile.inc
Log:
Separate payload compression from stage compression.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Modified: trunk/coreboot-v2/Makefile
===================================================================
--- trunk/coreboot-v2/Makefile	2009-09-22 22:08:47 UTC (rev 4658)
+++ trunk/coreboot-v2/Makefile	2009-09-23 17:48:28 UTC (rev 4659)
@@ -236,9 +236,10 @@
 CFLAGS += -Werror-implicit-function-declaration -Wstrict-aliasing -Wshadow 
 CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
 
-CBFS_COMPRESS_FLAG:=
+CBFS_COMPRESS_FLAG:=l
+CBFS_PAYLOAD_COMPRESS_FLAG:=
 ifeq ($(CONFIG_COMPRESSED_PAYLOAD_LZMA),y)
-CBFS_COMPRESS_FLAG:=l
+CBFS_PAYLOAD_COMPRESS_FLAG:=l
 endif
 
 coreboot: prepare prepare2 $(obj)/coreboot.rom

Modified: trunk/coreboot-v2/src/arch/i386/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/arch/i386/Makefile.inc	2009-09-22 22:08:47 UTC (rev 4658)
+++ trunk/coreboot-v2/src/arch/i386/Makefile.inc	2009-09-23 17:48:28 UTC (rev 4659)
@@ -25,7 +25,7 @@
 	@printf "    PAYLOAD    none (as specified by user)\n"
 else
 	@printf "    PAYLOAD    $(CONFIG_FALLBACK_PAYLOAD_FILE) $(COMPRESSFLAG)\n"
-	$(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE)  fallback/payload $(CBFS_COMPRESS_FLAG)
+	$(CBFSTOOL) ./build/coreboot.rom add-payload $(CONFIG_FALLBACK_PAYLOAD_FILE)  fallback/payload $(CBFS_PAYLOAD_COMPRESS_FLAG)
 ifeq ($(CONFIG_VGA_BIOS),y)
 	@printf "    VGABIOS    $(CONFIG_FALLBACK_VGA_BIOS_FILE) $(CONFIG_FALLBACK_VGA_BIOS_ID)\n"
 	$(CBFSTOOL) ./build/coreboot.rom add $(CONFIG_FALLBACK_VGA_BIOS_FILE) "pci$(CONFIG_FALLBACK_VGA_BIOS_ID).rom" optionrom 




From mylesgw at gmail.com  Wed Sep 23 19:49:38 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 11:49:38 -0600
Subject: [coreboot] [PATCH] Compression fix
In-Reply-To: <20090923174450.2045.qmail@stuge.se>
References: <2831fecf0909231041h4bbb3fdh2938ea492fe4784e@mail.gmail.com>
	<20090923174450.2045.qmail@stuge.se>
Message-ID: <2831fecf0909231049l4bdfa529ja1d188a9bfd83ac7@mail.gmail.com>

On Wed, Sep 23, 2009 at 11:44 AM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > Separate payload compression from stage compression.  I figured out why
> > sometimes my coreboot_ram was 40K and sometimes it was 250K.
> >
> > Signed-off-by: Myles Watson <mylesgw at gmail.com>
>
> Acked-by: Peter Stuge <peter at stuge.se><http://www.coreboot.org/mailman/listinfo/coreboot>

Rev 4659.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/3be78c19/attachment.html>

From ward at gnu.org  Wed Sep 23 19:51:51 2009
From: ward at gnu.org (Ward Vandewege)
Date: Wed, 23 Sep 2009 13:51:51 -0400
Subject: [coreboot] Tyan s2881 Kconfig
In-Reply-To: <2831fecf0909231013l6c8eae25t6600e7389c8befa8@mail.gmail.com>
References: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
	<13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
	<2831fecf0909231013l6c8eae25t6600e7389c8befa8@mail.gmail.com>
Message-ID: <20090923175151.GA5291@countzero.vandewege.net>

On Wed, Sep 23, 2009 at 11:13:11AM -0600, Myles Watson wrote:
> On Wed, Sep 23, 2009 at 10:56 AM, ron minnich <rminnich at gmail.com> wrote:
> 
> > Currently, because they are so simple, we don't have makefile.inc
> > files for i2c drivers. see serengeti_cheetah:
> > driver-y += ../../../drivers/i2c/i2cmux/i2cmux.o
> >
> Should it be a driver? In the old config it was just an object.
> 
> 
> > This is admittedly inconsistent, but it saves a lot of unnecessary
> > makefile.inc stuff.
> >
> No problem.  I just missed it.
> 
> 
> > $39 for those boards is pretty attractive, do you have a link?
> >
> http://www.pacificgeek.com/product.asp?id=847374

Argh, can not resist. Ordered :) Good for spare parts, too - I've still got a
couple of those out in the field...

Thanks,
Ward.

-- 
Ward Vandewege <ward at fsf.org>
Free Software Foundation - Senior Systems Administrator



From svn at coreboot.org  Wed Sep 23 19:59:57 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 19:59:57 +0200
Subject: [coreboot] [v2] r4660 - in trunk/coreboot-v2/src/mainboard/tyan: .
	s2881
Message-ID: <mailman.3728.1355071620.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-23 19:59:56 +0200 (Wed, 23 Sep 2009)
New Revision: 4660

Added:
   trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig
   trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc
Modified:
   trunk/coreboot-v2/src/mainboard/tyan/Kconfig
Log:
Add Kconfig support for Tyan s2881.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: trunk/coreboot-v2/src/mainboard/tyan/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/Kconfig	2009-09-23 17:48:28 UTC (rev 4659)
+++ trunk/coreboot-v2/src/mainboard/tyan/Kconfig	2009-09-23 17:59:56 UTC (rev 4660)
@@ -23,6 +23,7 @@
 	depends on VENDOR_TYAN
 	
 source "src/mainboard/tyan/s1846/Kconfig"
+source "src/mainboard/tyan/s2881/Kconfig"
 source "src/mainboard/tyan/s2891/Kconfig"
 source "src/mainboard/tyan/s2892/Kconfig"
 source "src/mainboard/tyan/s2895/Kconfig"

Copied: trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig (from rev 4658, trunk/coreboot-v2/src/mainboard/tyan/s2891/Kconfig)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2881/Kconfig	2009-09-23 17:59:56 UTC (rev 4660)
@@ -0,0 +1,142 @@
+config BOARD_TYAN_S2881
+	bool "Tyan Thunder K8SR S2881"
+	select ARCH_X86
+	select CPU_AMD_K8
+	select CPU_AMD_SOCKET_940
+	select NORTHBRIDGE_AMD_AMDK8
+	select NORTHBRIDGE_AMD_AMDK8_ROOT_COMPLEX
+	select SOUTHBRIDGE_AMD_AMD8131
+	select SOUTHBRIDGE_AMD_AMD8111
+	select SUPERIO_WINBOND_W83627HF
+	select PIRQ_TABLE
+
+config MAINBOARD_DIR
+	string
+	default tyan/s2881
+	depends on BOARD_TYAN_S2881
+
+config APIC_ID_OFFSET
+	hex
+	default 0x10
+	depends on BOARD_TYAN_S2881
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 2
+	depends on BOARD_TYAN_S2881
+
+config LB_CKS_RANGE_END
+	int
+	default 122
+	depends on BOARD_TYAN_S2881
+
+config LB_CKS_LOC
+	int
+        default 123
+	depends on BOARD_TYAN_S2881
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "s2881"
+	depends on BOARD_TYAN_S2881
+
+config MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID
+	hex
+	default 0x2881
+	depends on BOARD_TYAN_S2881
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config HW_MEM_HOLE_SIZEK
+	hex
+	default 0x100000
+	depends on BOARD_TYAN_S2881
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config HAVE_FAILOVER_BOOT
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config USE_FAILOVER_IMAGE
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config MAX_CPUS
+	int
+	default 4
+	depends on BOARD_TYAN_S2881
+
+config MAX_PHYSICAL_CPUS
+	int
+	default 2
+	depends on BOARD_TYAN_S2881
+
+config MEM_TRAIN_SEQ
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config AP_CODE_IN_CAR
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config HW_MEM_HOLE_SIZE_AUTO_INC
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0xa
+	depends on BOARD_TYAN_S2881
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x6
+	depends on BOARD_TYAN_S2881
+
+config USE_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config SERIAL_CPU_INIT
+	bool
+	default y
+	depends on BOARD_TYAN_S2881
+
+config AP_CODE_IN_CAR
+	bool
+	default y
+	depends on BOARD_TYAN_S2881
+
+config WAIT_BEFORE_CPUS_INIT
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config SB_HT_CHAIN_ON_BUS0
+	int
+	default 0
+	depends on BOARD_TYAN_S2881
+
+config SB_HT_CHAIN_UNITID_OFFSET_ONLY
+	bool
+	default n
+	depends on BOARD_TYAN_S2881
+
+config HAVE_ACPI_TABLES
+	bool "Generate ACPI tables"
+	default n
+	depends on BOARD_TYAN_S2881
+

Copied: trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc (from rev 4658, trunk/coreboot-v2/src/mainboard/tyan/s2891/Makefile.inc)
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc	2009-09-23 17:59:56 UTC (rev 4660)
@@ -0,0 +1,2 @@
+include $(src)/mainboard/tyan/Makefile.s289x.inc
+driver-$(CONFIG_BOARD_TYAN_S2881) += ../../../drivers/i2c/adm1027/adm1027.o


Property changes on: trunk/coreboot-v2/src/mainboard/tyan/s2881/Makefile.inc
___________________________________________________________________
Added: svn:mergeinfo
   + 




From mylesgw at gmail.com  Wed Sep 23 20:02:13 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 12:02:13 -0600
Subject: [coreboot] Tyan s2881 Kconfig
In-Reply-To: <13426df10909231054u30e67da4pd6d703505e2cb83@mail.gmail.com>
References: <2831fecf0909230901t6378b848h3598a05daa8372e0@mail.gmail.com>
	<13426df10909230956q6d191a43hbe0a928ad12dbf51@mail.gmail.com>
	<2831fecf0909231038y5bfa5edejb4fa39b46ea472ce@mail.gmail.com>
	<13426df10909231054u30e67da4pd6d703505e2cb83@mail.gmail.com>
Message-ID: <2831fecf0909231102g7abce900l4a2f1aac71a219c9@mail.gmail.com>

On Wed, Sep 23, 2009 at 11:54 AM, ron minnich <rminnich at gmail.com> wrote:

> great. Is it  a driver or not? I'm too distracted with another but to
> tell. If you're sure it's a driver,
>
I thought it should be, and serengeti_cheetah says it is.  If it's wrong I
guess we can change both in a separate commit.


> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
Rev 4660.
Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/cbf7fb61/attachment.html>

From mylesgw at gmail.com  Wed Sep 23 20:04:51 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 12:04:51 -0600
Subject: [coreboot] Drivers vs. Objects
Message-ID: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>

Drivers and objects seem interchangeable to me except that drivers get
registered and checked against devices that are found during enumeration,
that weren't mentioned in devicetree.cb.  Either one seems to get linked
into the correct place if the device is mentioned in the device tree.

Are there other differences?  Should I2C devices use objects, since you
can't scan for them?

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/143c2a29/attachment.html>

From peter at stuge.se  Wed Sep 23 20:12:56 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 20:12:56 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
Message-ID: <20090923181256.7913.qmail@stuge.se>

Myles Watson wrote:
> Are there other differences?

That's how I understand it too.


> Should I2C devices use objects, since you can't scan for them?

Makes sense. Either way I strongly favor having a policy for this,
so that the tree is consistent.


//Peter



From info at coresystems.de  Wed Sep 23 20:13:39 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 20:13:39 +0200
Subject: [coreboot] build service results for r4659
Message-ID: <E1MqWLT-0002S3-60@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4659 to
the coreboot repository. This caused the following 
changes:

Change Log:
Separate payload compression from stage compression.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Peter Stuge <peter at stuge.se>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4659&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Wed Sep 23 20:26:14 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 12:26:14 -0600
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <20090923181256.7913.qmail@stuge.se>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
Message-ID: <0E0F6A1D2DC14AC694536B54782A7DBA@chimp>

> > Should I2C devices use objects, since you can't scan for them?
> 
> Makes sense. Either way I strongly favor having a policy for this,
> so that the tree is consistent.

Making it a driver seems easier to enforce/explain since it provides an
*_ops struct.

Thanks,
Myles




From peter at stuge.se  Wed Sep 23 20:42:29 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 20:42:29 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
Message-ID: <20090923184229.14543.qmail@stuge.se>

Myles Watson wrote:
> > > Should I2C devices use objects, since you can't scan for them?
> > 
> > Makes sense. Either way I strongly favor having a policy for this,
> > so that the tree is consistent.
> 
> Making it a driver seems easier to enforce/explain since it provides an
> *_ops struct.

On the other hand a phony ops struct is bad in so many ways. Less is
more, no?


//Peter



From info at coresystems.de  Wed Sep 23 20:45:00 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 20:45:00 +0200
Subject: [coreboot] build service results for r4660
Message-ID: <E1MqWpo-0005KK-Sq@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4660 to
the coreboot repository. This caused the following 
changes:

Change Log:
Add Kconfig support for Tyan s2881.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4660&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Wed Sep 23 20:46:08 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 12:46:08 -0600
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <20090923184229.14543.qmail@stuge.se>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
	<20090923184229.14543.qmail@stuge.se>
Message-ID: <2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>

On Wed, Sep 23, 2009 at 12:42 PM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > > > Should I2C devices use objects, since you can't scan for them?
>
> > Making it a driver seems easier to enforce/explain since it provides an
> > *_ops struct.
>
> On the other hand a phony ops struct is bad in so many ways. Less is
> more, no?
>
My impression was that the ops struct works fine, but you can't scan for it
because I2C is missing the equivalent of PCI vendor/device IDs.  In what way
is the ops struct phony?

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/29763df7/attachment.html>

From svn at coreboot.org  Wed Sep 23 20:51:03 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 20:51:03 +0200
Subject: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: . lib
	mainboard/a-trend/atc-6220 mainboard/a-trend/atc-6240
	mainboard/abit/be6-ii_v2_0 mainboard/advantech/pcm-5820
	mainboard/amd/db800 mainboard/amd/dbm690t
	mainboard/amd/norwich mainboard/amd/pistachio
	mainboard/amd/rumba mainboard/amd/serengeti_cheetah
	mainboard/amd/serengeti_cheetah_fam10 mainboard/arima/hdama
	mainboard/artecgroup/dbe61 mainboard/asi/mb_5blgp
	mainboard/asi/mb_5blmp mainboard/asus/a8n_e
	mainboard/asus/a8v-e_se mainboard/asus/m2v-mx_se
	mainboard/asus/mew-am mainboard/asus/mew-vm
	mainboard/asus/p2b mainboard/asus/p2b-d mainboard/asus/p2b-ds
	mainboard/asus/p2b-f mainboard/asus/p3b-f
	mainboard/axus/tc320 mainboard/azza/pt-6ibd
	mainboard/bcom/winnet100 mainboard/bcom/winnetp680
	mainboard/biostar/m6tba mainboard/broadcom/blast
	mainboard/compaq/deskpro_en_sff_p600 mainboard/dell/s1850
	mainboard/digitallogic/adl855pc mainboard/digitallogic/msm586seg
	mainboard/digitallogic/msm800sev mainboard/eaglelion/5bcm
	mainboard/gigabyte/ga-6bxc mainboard/gigabyte/ga_2761gxdk
	mainboard/gigabyte/m57sli mainboard/hp/dl145_g3
	mainboard/ibm/e325 mainboard/ibm/e326 mainboard/iei/juki-511p
	mainboard/iei/nova4899r mainboard/iei/pcisa-lx-800-r10
	mainboard/intel/eagleheights mainboard/intel/jarrell
	mainboard/intel/mtarvon mainboard/intel/truxton
	mainboard/intel/xe7501devkit mainboard/iwill/dk8_htx
	mainboard/iwill/dk8s2 mainboard/iwill/dk8x
	mainboard/jetway/j7f24 mainboard/kontron/986lcd-m
	mainboard/lippert/frontrunner mainboard/lippert/roadrunner-lx
	mainboard/lippert/spacerunner-lx mainboard/mitac/6513wu
	mainboard/msi/ms6119 mainboard/msi/ms6147
	mainboard/msi/ms6178 mainboard/msi/ms7135
	mainboard/msi/ms7260 mainboard/msi/ms9185
	mainboard/msi/ms9282 mainboard/nec/powermate2000
	mainboard/newisys/khepri mainboard/nvidia/l1_2pvv
	mainboard/olpc/btest mainboard/olpc/rev_a
	mainboard/pcengines/alix1c mainboard/rca/rm4100
	mainboard/soyo/sy-6ba-plus-iii mainboard/sunw/ultra40
	mainboard/supermicro/h8dme mainboard/supermicro/h8dmr
	mainboard/supermicro/x6dai_g mainboard/supermicro/x6dhe_g
	mainboard/supermicro/x6dhe_g2 mainboard/supermicro/x6dhr_ig
	mainboard/supermicro/x6dhr_ig2 mainboard/technexion/tim8690
	mainboard/technologic/ts5300 mainboard/televideo/tc7020
	mainboard/thomson/ip1000 mainboard/tyan/s1846
	mainboard/tyan/s2735 mainboard/tyan/s2850
	mainboard/tyan/s2875 mainboard/tyan/s2880
	mainboard/tyan/s2881 mainboard/tyan/s2882
	mainboard/tyan/s2885 mainboard/tyan/s2891
	mainboard/tyan/s2892 mainboard/tyan/s2895
	mainboard/tyan/s2912 mainboard/tyan/s2912_fam10
	mainboard/tyan/s4880 mainboard/tyan/s4882 mainboard/via/epia
	mainboard/via/epia-cn mainboard/via/epia-m
	mainboard/via/epia-m700 mainboard/via/epia-n
	mainboard/via/pc2500e mainboard/via/vt8454c
	northbridge/amd/amdk8 northbridge/intel/e7520
	northbridge/intel/e7525 northbridge/via/vx800/examples
Message-ID: <mailman.3729.1355071620.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-23 20:51:03 +0200 (Wed, 23 Sep 2009)
New Revision: 4661

Added:
   trunk/coreboot-v2/src/lib/generic_dump_spd.c
   trunk/coreboot-v2/src/lib/generic_sdram.c
   trunk/coreboot-v2/src/lib/ramtest.c
Removed:
   trunk/coreboot-v2/src/ram/
   trunk/coreboot-v2/src/sdram/
Modified:
   trunk/coreboot-v2/src/mainboard/a-trend/atc-6220/auto.c
   trunk/coreboot-v2/src/mainboard/a-trend/atc-6240/auto.c
   trunk/coreboot-v2/src/mainboard/abit/be6-ii_v2_0/auto.c
   trunk/coreboot-v2/src/mainboard/advantech/pcm-5820/auto.c
   trunk/coreboot-v2/src/mainboard/amd/db800/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/norwich/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/rumba/auto.c
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/arima/hdama/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/asi/mb_5blgp/auto.c
   trunk/coreboot-v2/src/mainboard/asi/mb_5blmp/auto.c
   trunk/coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/asus/mew-am/auto.c
   trunk/coreboot-v2/src/mainboard/asus/mew-vm/auto.c
   trunk/coreboot-v2/src/mainboard/asus/p2b-d/auto.c
   trunk/coreboot-v2/src/mainboard/asus/p2b-ds/auto.c
   trunk/coreboot-v2/src/mainboard/asus/p2b-f/auto.c
   trunk/coreboot-v2/src/mainboard/asus/p2b/auto.c
   trunk/coreboot-v2/src/mainboard/asus/p3b-f/auto.c
   trunk/coreboot-v2/src/mainboard/axus/tc320/auto.c
   trunk/coreboot-v2/src/mainboard/azza/pt-6ibd/auto.c
   trunk/coreboot-v2/src/mainboard/bcom/winnet100/auto.c
   trunk/coreboot-v2/src/mainboard/bcom/winnetp680/auto.c
   trunk/coreboot-v2/src/mainboard/biostar/m6tba/auto.c
   trunk/coreboot-v2/src/mainboard/broadcom/blast/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/auto.c
   trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
   trunk/coreboot-v2/src/mainboard/digitallogic/adl855pc/auto.c
   trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg/auto.c
   trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/auto.c
   trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/eaglelion/5bcm/auto.c
   trunk/coreboot-v2/src/mainboard/gigabyte/ga-6bxc/auto.c
   trunk/coreboot-v2/src/mainboard/gigabyte/ga_2761gxdk/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/hp/dl145_g3/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/ibm/e325/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/ibm/e326/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/iei/juki-511p/auto.c
   trunk/coreboot-v2/src/mainboard/iei/nova4899r/auto.c
   trunk/coreboot-v2/src/mainboard/iei/pcisa-lx-800-r10/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/intel/eagleheights/auto.c
   trunk/coreboot-v2/src/mainboard/intel/jarrell/auto.c
   trunk/coreboot-v2/src/mainboard/intel/mtarvon/auto.c
   trunk/coreboot-v2/src/mainboard/intel/truxton/auto.c
   trunk/coreboot-v2/src/mainboard/intel/xe7501devkit/auto.c
   trunk/coreboot-v2/src/mainboard/iwill/dk8_htx/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/iwill/dk8s2/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/iwill/dk8x/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/jetway/j7f24/auto.c
   trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/auto.c
   trunk/coreboot-v2/src/mainboard/lippert/frontrunner/auto.c
   trunk/coreboot-v2/src/mainboard/lippert/roadrunner-lx/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/mitac/6513wu/auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms6119/auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms6147/auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms6178/auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms7260/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms9185/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/msi/ms9282/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/nec/powermate2000/auto.c
   trunk/coreboot-v2/src/mainboard/newisys/khepri/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/nvidia/l1_2pvv/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/olpc/btest/auto.c
   trunk/coreboot-v2/src/mainboard/olpc/rev_a/auto.c
   trunk/coreboot-v2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/rca/rm4100/auto.c
   trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/auto.c
   trunk/coreboot-v2/src/mainboard/sunw/ultra40/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/h8dme/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/h8dmr/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dai_g/auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g/auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.updated.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig/auto.c
   trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig2/auto.c
   trunk/coreboot-v2/src/mainboard/technexion/tim8690/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/technologic/ts5300/auto.c
   trunk/coreboot-v2/src/mainboard/televideo/tc7020/auto.c
   trunk/coreboot-v2/src/mainboard/thomson/ip1000/auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s1846/auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2735/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2850/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2875/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2880/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2881/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2882/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2885/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2891/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2892/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2912/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s4880/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/tyan/s4882/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/via/epia-cn/auto.c
   trunk/coreboot-v2/src/mainboard/via/epia-m/auto.c
   trunk/coreboot-v2/src/mainboard/via/epia-m700/cache_as_ram_auto.c
   trunk/coreboot-v2/src/mainboard/via/epia-n/auto.c
   trunk/coreboot-v2/src/mainboard/via/epia/auto.c
   trunk/coreboot-v2/src/mainboard/via/pc2500e/auto.c
   trunk/coreboot-v2/src/mainboard/via/vt8454c/auto.c
   trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_test.c
   trunk/coreboot-v2/src/northbridge/intel/e7520/raminit_test.c
   trunk/coreboot-v2/src/northbridge/intel/e7525/raminit_test.c
   trunk/coreboot-v2/src/northbridge/via/vx800/examples/cache_as_ram_auto.c
Log:
simplify source tree hierarchy: move files from sdram/ and ram/ to lib/
It's only three files. Also fix up all the paths (Gotta love included C files)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Copied: trunk/coreboot-v2/src/lib/generic_dump_spd.c (from rev 4660, trunk/coreboot-v2/src/sdram/generic_dump_spd.c)
===================================================================
--- trunk/coreboot-v2/src/lib/generic_dump_spd.c	                        (rev 0)
+++ trunk/coreboot-v2/src/lib/generic_dump_spd.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -0,0 +1,93 @@
+/*
+ * This code is derived from the Opteron boards' debug.c.
+ * It should go away either there or here, depending what fits better.
+ */
+
+static void dump_spd_registers(const struct mem_controller *ctrl)
+{
+	int i;
+	print_debug("\r\n");
+	for(i = 0; i < 4; i++) {
+		unsigned device;
+		device = ctrl->channel0[i];
+		if (device) {
+			int j;
+			print_debug("dimm: "); 
+			print_debug_hex8(i); 
+			print_debug(".0: ");
+			print_debug_hex8(device);
+			for(j = 0; j < 256; j++) {
+				int status;
+				unsigned char byte;
+				if ((j & 0xf) == 0) {
+					print_debug("\r\n");
+					print_debug_hex8(j);
+					print_debug(": ");
+				}
+				status = spd_read_byte(device, j);
+				if (status < 0) {
+					print_debug("bad device\r\n");
+					break;
+				}
+				byte = status & 0xff;
+				print_debug_hex8(byte);
+				print_debug_char(' ');
+			}
+			print_debug("\r\n");
+		}
+		device = ctrl->channel1[i];
+		if (device) {
+			int j;
+			print_debug("dimm: "); 
+			print_debug_hex8(i); 
+			print_debug(".1: ");
+			print_debug_hex8(device);
+			for(j = 0; j < 256; j++) {
+				int status;
+				unsigned char byte;
+				if ((j & 0xf) == 0) {
+					print_debug("\r\n");
+					print_debug_hex8(j);
+					print_debug(": ");
+				}
+				status = spd_read_byte(device, j);
+				if (status < 0) {
+					print_debug("bad device\r\n");
+					break;
+				}
+				byte = status & 0xff;
+				print_debug_hex8(byte);
+				print_debug_char(' ');
+			}
+			print_debug("\r\n");
+		}
+	}
+}
+
+#if 0
+void dump_spd_registers(void)
+{
+	unsigned device;
+	device = SMBUS_MEM_DEVICE_START;
+	printk_debug("\n");
+	while(device <= SMBUS_MEM_DEVICE_END) {
+		int status = 0;
+		int i;
+		printk_debug("dimm %02x", device);
+		for(i = 0; (i < 256) && (status == 0); i++) {
+			unsigned char byte;
+			if ((i % 20) == 0) {
+				printk_debug("\n%3d: ", i);
+			}
+			status = smbus_read_byte(device, i, &byte);
+			if (status != 0) {
+				printk_debug("bad device\n");
+				continue;
+			}
+			printk_debug("%02x ", byte);
+		}
+		device += SMBUS_MEM_DEVICE_INC;
+		printk_debug("\n");
+	}
+}
+#endif

Copied: trunk/coreboot-v2/src/lib/generic_sdram.c (from rev 4660, trunk/coreboot-v2/src/sdram/generic_sdram.c)
===================================================================
--- trunk/coreboot-v2/src/lib/generic_sdram.c	                        (rev 0)
+++ trunk/coreboot-v2/src/lib/generic_sdram.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -0,0 +1,67 @@
+
+#ifndef RAMINIT_SYSINFO
+        #define RAMINIT_SYSINFO 0
+#endif
+
+static inline void print_debug_sdram_8(const char *strval, uint32_t val)
+{
+#if CONFIG_USE_INIT
+        printk_debug("%s%02x\r\n", strval, val);
+#else
+        print_debug(strval); print_debug_hex8(val); print_debug("\r\n");
+#endif
+}
+
+void sdram_no_memory(void)
+{
+	print_err("No memory!!\r\n");
+	while(1) { 
+		hlt(); 
+	}
+}
+
+/* Setup SDRAM */
+#if RAMINIT_SYSINFO == 1
+void sdram_initialize(int controllers, const struct mem_controller *ctrl, void *sysinfo)
+#else
+void sdram_initialize(int controllers, const struct mem_controller *ctrl)
+#endif
+{
+	int i;
+	/* Set the registers we can set once to reasonable values */
+	for(i = 0; i < controllers; i++) {
+		print_debug_sdram_8("Ram1.",i);
+
+	#if RAMINIT_SYSINFO == 1
+		sdram_set_registers(ctrl + i , sysinfo);
+	#else
+		sdram_set_registers(ctrl + i);
+	#endif
+	}
+
+	/* Now setup those things we can auto detect */
+	for(i = 0; i < controllers; i++) {
+                print_debug_sdram_8("Ram2.",i);
+
+	#if RAMINIT_SYSINFO == 1
+		sdram_set_spd_registers(ctrl + i , sysinfo);
+	#else
+                sdram_set_spd_registers(ctrl + i);
+	#endif
+
+	}
+
+	/* Now that everything is setup enable the SDRAM.
+	 * Some chipsets do the work for us while on others 
+	 * we need to it by hand.
+	 */
+	print_debug("Ram3\r\n");
+
+	#if RAMINIT_SYSINFO == 1
+	sdram_enable(controllers, ctrl, sysinfo);
+	#else
+	sdram_enable(controllers, ctrl);
+	#endif
+
+	print_debug("Ram4\r\n");
+}

Copied: trunk/coreboot-v2/src/lib/ramtest.c (from rev 4660, trunk/coreboot-v2/src/ram/ramtest.c)
===================================================================
--- trunk/coreboot-v2/src/lib/ramtest.c	                        (rev 0)
+++ trunk/coreboot-v2/src/lib/ramtest.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -0,0 +1,161 @@
+static void write_phys(unsigned long addr, unsigned long value)
+{
+#if CONFIG_HAVE_MOVNTI
+	asm volatile(
+		"movnti %1, (%0)"
+		: /* outputs */
+		: "r" (addr), "r" (value) /* inputs */
+#ifndef __GNUC__
+		: /* clobbers */
+#endif
+		);
+#else
+	volatile unsigned long *ptr;
+	ptr = (void *)addr;
+	*ptr = value;
+#endif
+}
+
+static unsigned long read_phys(unsigned long addr)
+{
+	volatile unsigned long *ptr;
+	ptr = (void *)addr;
+	return *ptr;
+}
+
+static void ram_fill(unsigned long start, unsigned long stop)
+{
+	unsigned long addr;
+	/* 
+	 * Fill.
+	 */
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("DRAM fill: 0x%08x-0x%08x\r\n", start, stop);
+#else
+	print_debug("DRAM fill: ");
+	print_debug_hex32(start);
+	print_debug("-");
+	print_debug_hex32(stop);
+	print_debug("\r\n");
+#endif
+	for(addr = start; addr < stop ; addr += 4) {
+		/* Display address being filled */
+		if (!(addr & 0xfffff)) {
+#if CONFIG_USE_PRINTK_IN_CAR
+			printk_debug("%08x \r", addr);
+#else
+			print_debug_hex32(addr);
+			print_debug(" \r");
+#endif
+		}
+		write_phys(addr, addr);
+	};
+	/* Display final address */
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("%08x\r\nDRAM filled\r\n", addr);
+#else
+	print_debug_hex32(addr);
+	print_debug("\r\nDRAM filled\r\n");
+#endif
+}
+
+static void ram_verify(unsigned long start, unsigned long stop)
+{
+	unsigned long addr;
+	int i = 0;
+	/* 
+	 * Verify.
+	 */
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("DRAM verify: 0x%08x-0x%08x\r\n", start, stop);
+#else
+	print_debug("DRAM verify: ");
+	print_debug_hex32(start);
+	print_debug_char('-');
+	print_debug_hex32(stop);
+	print_debug("\r\n");
+#endif
+	for(addr = start; addr < stop ; addr += 4) {
+		unsigned long value;
+		/* Display address being tested */
+		if (!(addr & 0xfffff)) {
+#if CONFIG_USE_PRINTK_IN_CAR
+			printk_debug("%08x \r", addr);
+#else
+			print_debug_hex32(addr);
+			print_debug(" \r");
+#endif
+		}
+		value = read_phys(addr);
+		if (value != addr) {
+			/* Display address with error */
+#if CONFIG_USE_PRINTK_IN_CAR
+			printk_err("Fail: @0x%08x Read value=0x%08x\r\n", addr, value);
+#else
+			print_err("Fail: @0x");
+			print_err_hex32(addr);
+			print_err(" Read value=0x");
+			print_err_hex32(value);
+			print_err("\r\n");
+#endif
+			i++;
+			if(i>256) {
+#if CONFIG_USE_PRINTK_IN_CAR
+				printk_debug("Aborting.\n\r");
+#else
+				print_debug("Aborting.\n\r");
+#endif
+				break;
+			}
+		}
+	}
+	/* Display final address */
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("%08x", addr);
+#else
+	print_debug_hex32(addr);
+#endif
+
+	if (i) {
+#if CONFIG_USE_PRINTK_IN_CAR
+		printk_debug("\r\nDRAM did _NOT_ verify!\r\n");
+#else
+		print_debug("\r\nDRAM did _NOT_ verify!\r\n");
+#endif
+		die("DRAM ERROR");
+	}
+	else {
+#if CONFIG_USE_PRINTK_IN_CAR
+		printk_debug("\r\nDRAM range verified.\r\n");
+#else
+		print_debug("\r\nDRAM range verified.\r\n");
+#endif
+	}
+}
+
+
+void ram_check(unsigned long start, unsigned long stop)
+{
+	/*
+	 * This is much more of a "Is my DRAM properly configured?"
+	 * test than a "Is my DRAM faulty?" test.  Not all bits
+	 * are tested.   -Tyson
+	 */
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("Testing DRAM : %08x - %08x\r\n", start, stop);
+#else
+	print_debug("Testing DRAM : ");
+	print_debug_hex32(start);
+	print_debug("-");	
+	print_debug_hex32(stop);
+	print_debug("\r\n");
+#endif
+	ram_fill(start, stop);
+	ram_verify(start, stop);
+#if CONFIG_USE_PRINTK_IN_CAR
+	printk_debug("Done.\r\n");
+#else
+	print_debug("Done.\r\n");
+#endif
+}
+

Modified: trunk/coreboot-v2/src/mainboard/a-trend/atc-6220/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/a-trend/atc-6220/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/a-trend/atc-6220/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/a-trend/atc-6240/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/a-trend/atc-6240/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/a-trend/atc-6240/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/abit/be6-ii_v2_0/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/abit/be6-ii_v2_0/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/abit/be6-ii_v2_0/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/advantech/pcm-5820/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/advantech/pcm-5820/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/advantech/pcm-5820/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -27,7 +27,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "cpu/x86/bist.h"
 #include "superio/winbond/w83977f/w83977f_early_serial.c"

Modified: trunk/coreboot-v2/src/mainboard/amd/db800/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/db800/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/db800/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -27,7 +27,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -55,7 +55,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/dbm690t/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -88,7 +88,7 @@
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "northbridge/amd/amdk8/raminit_f.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "resourcemap.c"
 
 #include "cpu/amd/dualcore/dualcore.c"

Modified: trunk/coreboot-v2/src/mainboard/amd/norwich/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/norwich/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/norwich/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -27,7 +27,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -53,7 +53,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/pistachio/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -82,7 +82,7 @@
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "northbridge/amd/amdk8/raminit_f.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "resourcemap.c"
 
 #include "cpu/amd/dualcore/dualcore.c"

Modified: trunk/coreboot-v2/src/mainboard/amd/rumba/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/rumba/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/rumba/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
@@ -93,7 +93,7 @@
 }
 
 #include "northbridge/amd/gx2/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #define PLLMSRhi 0x00001490
 #define PLLMSRlo 0x02000030

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -126,7 +126,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/amd/serengeti_cheetah_fam10/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -63,7 +63,7 @@
 #if (CONFIG_USE_FAILOVER_IMAGE == 0)
 #include "arch/i386/lib/console.c"
 #include "pc80/serial.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include <cpu/amd/model_10xxx_rev.h>
 #include "southbridge/amd/amd8111/amd8111_early_smbus.c"
 #include "northbridge/amd/amdfam10/raminit.h"

Modified: trunk/coreboot-v2/src/mainboard/arima/hdama/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/arima/hdama/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/arima/hdama/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -78,7 +78,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -72,7 +72,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/asi/mb_5blgp/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asi/mb_5blgp/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asi/mb_5blgp/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -27,7 +27,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "cpu/x86/bist.h"
 #include "superio/nsc/pc87351/pc87351_early_serial.c"

Modified: trunk/coreboot-v2/src/mainboard/asi/mb_5blmp/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asi/mb_5blmp/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asi/mb_5blmp/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "superio/nsc/pc87351/pc87351_early_serial.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/a8n_e/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -58,7 +58,7 @@
 #include <cpu/amd/model_fxx_rev.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "southbridge/nvidia/ck804/ck804_early_smbus.c"
 #include "northbridge/amd/amdk8/raminit.h"
@@ -92,7 +92,7 @@
 }
 
 #include "northbridge/amd/amdk8/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "southbridge/nvidia/ck804/ck804_early_setup_ss.h"
 #include "southbridge/nvidia/ck804/ck804_early_setup.c"
 #include "cpu/amd/car/copy_and_run.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/a8v-e_se/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -113,7 +113,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/dualcore/dualcore.c"
 #include "southbridge/via/k8t890/k8t890_early_car.c"
 #include "cpu/amd/car/copy_and_run.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/m2v-mx_se/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -100,7 +100,7 @@
 #include "northbridge/amd/amdk8/raminit_f.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/dualcore/dualcore.c"
 #include "cpu/amd/car/copy_and_run.c"
 #include "cpu/amd/car/post_cache_as_ram.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/mew-am/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/mew-am/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/mew-am/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801xx/i82801xx_early_smbus.c"
 #include "northbridge/intel/i82810/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/mew-vm/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/mew-vm/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/mew-vm/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/smsc/lpc47b272/lpc47b272_early_serial.c"
 #include "northbridge/intel/i82810/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/p2b/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/p2b/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/p2b/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/p2b-d/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/p2b-d/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/p2b-d/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <cpu/x86/lapic.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/p2b-ds/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/p2b-ds/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/p2b-ds/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <cpu/x86/lapic.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/p2b-f/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/p2b-f/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/p2b-f/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/asus/p3b-f/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/p3b-f/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/asus/p3b-f/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/axus/tc320/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/axus/tc320/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/axus/tc320/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "superio/nsc/pc97317/pc97317_early_serial.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/azza/pt-6ibd/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/azza/pt-6ibd/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/azza/pt-6ibd/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/bcom/winnet100/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/bcom/winnet100/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/bcom/winnet100/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "superio/nsc/pc97317/pc97317_early_serial.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/bcom/winnetp680/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/bcom/winnetp680/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/bcom/winnetp680/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cn700/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/biostar/m6tba/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/biostar/m6tba/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/biostar/m6tba/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/broadcom/blast/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/broadcom/blast/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/broadcom/blast/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -21,7 +21,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -89,7 +89,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/dell/s1850/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801er/i82801er_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -71,7 +71,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 /* IPMI garbage. This is all test stuff, if it really works we'll move it somewhere

Modified: trunk/coreboot-v2/src/mainboard/digitallogic/adl855pc/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/digitallogic/adl855pc/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/digitallogic/adl855pc/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -14,7 +14,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801dbm/i82801dbm_early_smbus.c"
 #include "northbridge/intel/i855pm/raminit.h"
 
@@ -59,7 +59,7 @@
 
 #include "northbridge/intel/i855pm/raminit.c"
 #include "northbridge/intel/i855pm/reset_test.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 static void main(unsigned long bist)
 {

Modified: trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/digitallogic/msm586seg/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -9,7 +9,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 //#include "lib/delay.c"
 
@@ -74,7 +74,7 @@
 //	return smbus_read_byte(device, address);
 }
 
-//#include "sdram/generic_sdram.c"
+//#include "lib/generic_sdram.c"
 
 static inline void dumpmem(void){
   int i, j;

Modified: trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 //#include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
@@ -82,7 +82,7 @@
 }
 
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 /* CPU and GLIU mult/div */
 #define PLLMSRhi 0x0000039C

Modified: trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/digitallogic/msm800sev/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -35,7 +35,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/eaglelion/5bcm/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/eaglelion/5bcm/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/eaglelion/5bcm/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -9,7 +9,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 //#include "southbridge/intel/i440bx/i440bx_early_smbus.c"
 #include "superio/nsc/pc97317/pc97317_early_serial.c"
 //#include "northbridge/intel/i440bx/raminit.h"

Modified: trunk/coreboot-v2/src/mainboard/gigabyte/ga-6bxc/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/gigabyte/ga-6bxc/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/ga-6bxc/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/gigabyte/ga_2761gxdk/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/gigabyte/ga_2761gxdk/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/ga_2761gxdk/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -65,7 +65,7 @@
 #include "southbridge/sis/sis966/sis966_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -121,7 +121,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c"
 

Modified: trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/gigabyte/m57sli/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -63,7 +63,7 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -119,7 +119,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c" 
 

Modified: trunk/coreboot-v2/src/mainboard/hp/dl145_g3/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/hp/dl145_g3/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/hp/dl145_g3/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -65,7 +65,7 @@
 #if CONFIG_USE_FAILOVER_IMAGE==0
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -128,7 +128,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 //#include "resourcemap.c"
 

Modified: trunk/coreboot-v2/src/mainboard/ibm/e325/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/ibm/e325/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/ibm/e325/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -75,7 +75,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/ibm/e326/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/ibm/e326/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/ibm/e326/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -75,7 +75,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/iei/juki-511p/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iei/juki-511p/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iei/juki-511p/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83977f/w83977f_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "pc80/udelay_io.c"

Modified: trunk/coreboot-v2/src/mainboard/iei/nova4899r/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iei/nova4899r/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iei/nova4899r/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83977tf/w83977tf_early_serial.c"
 #include "cpu/x86/bist.h"
 

Modified: trunk/coreboot-v2/src/mainboard/iei/pcisa-lx-800-r10/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iei/pcisa-lx-800-r10/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iei/pcisa-lx-800-r10/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -27,7 +27,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -60,7 +60,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/intel/eagleheights/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/intel/eagleheights/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/intel/eagleheights/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -38,7 +38,7 @@
 #include "arch/i386/lib/console.c"
 #include <cpu/x86/bist.h>
 
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i3100/i3100_early_smbus.c"
 #include "southbridge/intel/i3100/i3100_early_lpc.c"
 #include "reset.c"
@@ -117,7 +117,7 @@
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "northbridge/intel/i3100/memory_initialized.c"
 #include "northbridge/intel/i3100/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "northbridge/intel/i3100/reset_test.c"
 #include "debug.c"
 

Modified: trunk/coreboot-v2/src/mainboard/intel/jarrell/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/intel/jarrell/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/intel/jarrell/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801er/i82801er_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/nsc/pc87427/pc87427.h"
@@ -49,7 +49,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "debug.c"
 
 

Modified: trunk/coreboot-v2/src/mainboard/intel/mtarvon/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/intel/mtarvon/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/intel/mtarvon/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i3100/i3100_early_smbus.c"
 #include "southbridge/intel/i3100/i3100_early_lpc.c"
 #include "northbridge/intel/i3100/raminit.h"
@@ -57,7 +57,7 @@
 }
 
 #include "northbridge/intel/i3100/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "../jarrell/debug.c"
 
 

Modified: trunk/coreboot-v2/src/mainboard/intel/truxton/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/intel/truxton/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/intel/truxton/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -31,7 +31,7 @@
 #include "pc80/serial.c"
 #include "pc80/udelay_io.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i3100/i3100_early_smbus.c"
 #include "southbridge/intel/i3100/i3100_early_lpc.c"
 #include "northbridge/intel/i3100/raminit_ep80579.h"
@@ -57,7 +57,7 @@
 }
 
 #include "northbridge/intel/i3100/raminit_ep80579.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "../../intel/jarrell/debug.c"
 
 /* #define TRUXTON_DEBUG */

Modified: trunk/coreboot-v2/src/mainboard/intel/xe7501devkit/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/intel/xe7501devkit/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/intel/xe7501devkit/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801ca/i82801ca_early_smbus.c"
 #include "northbridge/intel/e7501/raminit.h"
 #include "cpu/x86/lapic/boot_cpu.c"
@@ -41,7 +41,7 @@
 
 #include "northbridge/intel/e7501/raminit.c"
 #include "northbridge/intel/e7501/reset_test.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 // This function MUST appear last (ROMCC limitation)

Modified: trunk/coreboot-v2/src/mainboard/iwill/dk8_htx/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iwill/dk8_htx/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iwill/dk8_htx/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -106,8 +106,8 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 
-#include "sdram/generic_sdram.c"
-#include "ram/ramtest.c"
+#include "lib/generic_sdram.c"
+#include "lib/ramtest.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/iwill/dk8s2/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iwill/dk8s2/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iwill/dk8s2/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -106,8 +106,8 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 
-#include "sdram/generic_sdram.c"
-#include "ram/ramtest.c"
+#include "lib/generic_sdram.c"
+#include "lib/ramtest.c"
 
  /* tyan does not want the default */
 #include "northbridge/amd/amdk8/resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/iwill/dk8x/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/iwill/dk8x/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/iwill/dk8x/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -106,8 +106,8 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 
-#include "sdram/generic_sdram.c"
-#include "ram/ramtest.c"
+#include "lib/generic_sdram.c"
+#include "lib/ramtest.c"
 
  /* tyan does not want the default */
 #include "northbridge/amd/amdk8/resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/jetway/j7f24/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/jetway/j7f24/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/jetway/j7f24/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cn700/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -45,7 +45,7 @@
 #include "pc80/usbdebug_direct_serial.c"
 #endif
 
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801gx/i82801gx_early_smbus.c"
 #include "reset.c"
 #include "superio/winbond/w83627thg/w83627thg_early_serial.c"

Modified: trunk/coreboot-v2/src/mainboard/lippert/frontrunner/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/frontrunner/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/lippert/frontrunner/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
@@ -40,7 +40,7 @@
 }
 
 #include "northbridge/amd/gx2/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #define PLLMSRhi 0x00000226
 #define PLLMSRlo 0x00000008

Modified: trunk/coreboot-v2/src/mainboard/lippert/roadrunner-lx/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/roadrunner-lx/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/lippert/roadrunner-lx/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -31,7 +31,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -61,7 +61,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/lippert/spacerunner-lx/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -32,7 +32,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -123,7 +123,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/mitac/6513wu/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/mitac/6513wu/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/mitac/6513wu/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801xx/i82801xx_early_smbus.c"
 #include "northbridge/intel/i82810/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms6119/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms6119/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms6119/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms6147/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms6147/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms6147/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms6178/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms6178/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms6178/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "northbridge/intel/i82810/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms7135/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -60,7 +60,7 @@
 #include <cpu/amd/model_fxx_rev.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "southbridge/nvidia/ck804/ck804_early_smbus.c"
 #include "northbridge/amd/amdk8/raminit.h"
@@ -94,7 +94,7 @@
 }
 
 #include "northbridge/amd/amdk8/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "southbridge/nvidia/ck804/ck804_early_setup_ss.h"
 #include "southbridge/nvidia/ck804/ck804_early_setup_car.c"
 #include "cpu/amd/car/copy_and_run.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms7260/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms7260/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms7260/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -68,7 +68,7 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include <cpu/amd/model_fxx_rev.h>
 #include "southbridge/nvidia/mcp55/mcp55_early_smbus.c"
 #include "northbridge/amd/amdk8/raminit.h"
@@ -107,7 +107,7 @@
 #include "northbridge/amd/amdk8/coherent_ht.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "northbridge/amd/amdk8/raminit_f.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "resourcemap.c"
 #include "cpu/amd/dualcore/dualcore.c"
 

Modified: trunk/coreboot-v2/src/mainboard/msi/ms9185/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms9185/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms9185/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -130,7 +130,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* msi does not want the default */
 #include "resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/msi/ms9282/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/msi/ms9282/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/msi/ms9282/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -111,7 +111,7 @@
 #include "northbridge/amd/amdk8/raminit_f.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
 #include "northbridge/amd/amdk8/incoherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* msi does not want the default */
 #include "resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/nec/powermate2000/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/nec/powermate2000/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/nec/powermate2000/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/smsc/smscsuperio/smscsuperio_early_serial.c"
 #include "northbridge/intel/i82810/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"

Modified: trunk/coreboot-v2/src/mainboard/newisys/khepri/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/newisys/khepri/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/newisys/khepri/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -17,7 +17,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -90,7 +90,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* newisys khepri does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/nvidia/l1_2pvv/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/nvidia/l1_2pvv/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/nvidia/l1_2pvv/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -63,7 +63,7 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -118,7 +118,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c"
 

Modified: trunk/coreboot-v2/src/mainboard/olpc/btest/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/olpc/btest/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/olpc/btest/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
@@ -129,7 +129,7 @@
 }
 
 #include "northbridge/amd/gx2/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #define PLLMSRhi 0x00001490
 #define PLLMSRlo 0x02000030

Modified: trunk/coreboot-v2/src/mainboard/olpc/rev_a/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/olpc/rev_a/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/olpc/rev_a/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -8,7 +8,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/winbond/w83627hf/w83627hf_early_serial.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
@@ -129,7 +129,7 @@
 }
 
 #include "northbridge/amd/gx2/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #define PLLMSRhi 0x00001490
 #define PLLMSRlo 0x02000030

Modified: trunk/coreboot-v2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/pcengines/alix1c/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 #include "cpu/x86/msr.h"
 #include <cpu/amd/lxdef.h>
@@ -115,7 +115,7 @@
 #include "northbridge/amd/lx/raminit.h"
 #include "northbridge/amd/lx/pll_reset.c"
 #include "northbridge/amd/lx/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "cpu/amd/model_lx/cpureginit.c"
 #include "cpu/amd/model_lx/syspreinit.c"
 

Modified: trunk/coreboot-v2/src/mainboard/rca/rm4100/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/rca/rm4100/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/rca/rm4100/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include "pc80/serial.c"
 #include "pc80/udelay_io.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/smsc/smscsuperio/smscsuperio_early_serial.c"
 #include "northbridge/intel/i82830/raminit.h"
 #include "northbridge/intel/i82830/memory_initialized.c"
@@ -69,7 +69,7 @@
 }
 
 #include "northbridge/intel/i82830/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 /**
  * The AC'97 Audio Controller I/O space registers are read only by default

Modified: trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/sunw/ultra40/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/sunw/ultra40/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/sunw/ultra40/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -24,7 +24,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -83,7 +83,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/supermicro/h8dme/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/h8dme/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/h8dme/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -56,7 +56,7 @@
 #if CONFIG_USE_FAILOVER_IMAGE==0
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -169,7 +169,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c"
 

Modified: trunk/coreboot-v2/src/mainboard/supermicro/h8dmr/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/h8dmr/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/h8dmr/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -60,7 +60,7 @@
 #if CONFIG_USE_FAILOVER_IMAGE==0
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -116,7 +116,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c" 
 

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dai_g/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dai_g/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dai_g/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/esb6300/esb6300_early_smbus.c"
 #include "northbridge/intel/e7525/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -52,7 +52,7 @@
 }
 
 #include "northbridge/intel/e7525/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/esb6300/esb6300_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -70,7 +70,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801er/i82801er_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/nsc/pc87427/pc87427.h"
@@ -70,7 +70,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.updated.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.updated.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dhe_g2/auto.updated.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/esb6300/esb6300_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -70,7 +70,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801er/i82801er_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -71,7 +71,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig2/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig2/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/supermicro/x6dhr_ig2/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -10,7 +10,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82801er/i82801er_early_smbus.c"
 #include "northbridge/intel/e7520/raminit.h"
 #include "superio/winbond/w83627hf/w83627hf.h"
@@ -71,7 +71,7 @@
 }
 
 #include "northbridge/intel/e7520/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 static void main(unsigned long bist)

Modified: trunk/coreboot-v2/src/mainboard/technexion/tim8690/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/technexion/tim8690/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/technexion/tim8690/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -88,7 +88,7 @@
 #include "northbridge/amd/amdk8/incoherent_ht.c"
 #include "northbridge/amd/amdk8/raminit_f.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "resourcemap.c"
 
 #include "cpu/amd/dualcore/dualcore.c"

Modified: trunk/coreboot-v2/src/mainboard/technologic/ts5300/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/technologic/ts5300/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/technologic/ts5300/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -15,7 +15,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "cpu/x86/bist.h"
 
 #define TS5300_LED_OFF outb((inb(0x77)&0xfe), 0x77)

Modified: trunk/coreboot-v2/src/mainboard/televideo/tc7020/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/televideo/tc7020/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/televideo/tc7020/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -28,7 +28,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/amd/gx1/raminit.c"
 #include "superio/nsc/pc97317/pc97317_early_serial.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/thomson/ip1000/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/thomson/ip1000/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/thomson/ip1000/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include "pc80/serial.c"
 #include "pc80/udelay_io.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "superio/smsc/smscsuperio/smscsuperio_early_serial.c"
 #include "northbridge/intel/i82830/raminit.h"
 #include "northbridge/intel/i82830/memory_initialized.c"
@@ -69,7 +69,7 @@
 }
 
 #include "northbridge/intel/i82830/raminit.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 /**
  * The AC'97 Audio Controller I/O space registers are read only by default

Modified: trunk/coreboot-v2/src/mainboard/tyan/s1846/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s1846/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s1846/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -29,7 +29,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "southbridge/intel/i82371eb/i82371eb_early_smbus.c"
 #include "northbridge/intel/i440bx/raminit.h"
 #include "lib/debug.c"

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2735/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2735/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2735/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -74,7 +74,7 @@
 
 #include "northbridge/intel/e7501/raminit.c"
 #include "northbridge/intel/e7501/reset_test.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 
 #include "cpu/x86/car/copy_and_run.c"

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2850/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2850/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2850/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -80,7 +80,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2875/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2875/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2875/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -70,7 +70,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 #include "northbridge/amd/amdk8/resourcemap.c"
 
 #if CONFIG_LOGICAL_CPUS==1

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2880/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2880/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2880/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 
 #include <cpu/amd/model_fxx_rev.h>
@@ -72,7 +72,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2881/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2881/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2881/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -18,7 +18,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -87,7 +87,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "cpu/amd/dualcore/dualcore.c"
 

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2882/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2882/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2882/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -71,7 +71,7 @@
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/resourcemap.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #if CONFIG_LOGICAL_CPUS==1
 #define SET_NB_CFG_54 1

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2885/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2885/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2885/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #if 0
 static void post_code(uint8_t value) {
@@ -81,7 +81,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2891/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2891/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2891/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -19,7 +19,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -60,7 +60,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2892/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2892/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2892/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -56,7 +56,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2895/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -24,7 +24,7 @@
 #if CONFIG_USE_FAILOVER_IMAGE==0
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -87,7 +87,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c"

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2912/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2912/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2912/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -63,7 +63,7 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 
@@ -118,7 +118,7 @@
 
 #include "northbridge/amd/amdk8/raminit_f.c"
 
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
 #include "resourcemap.c"
 

Modified: trunk/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s2912_fam10/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -60,7 +60,7 @@
 #include "southbridge/nvidia/mcp55/mcp55_enable_usbdebug_direct.c"
 #include "pc80/usbdebug_direct_serial.c"
 #endif
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_10xxx_rev.h>
 

Modified: trunk/coreboot-v2/src/mainboard/tyan/s4880/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s4880/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s4880/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -85,7 +85,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/tyan/s4882/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/tyan/s4882/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/tyan/s4882/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -12,7 +12,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 
 #include <cpu/amd/model_fxx_rev.h>
 #include "northbridge/amd/amdk8/incoherent_ht.c"
@@ -93,7 +93,7 @@
 
 #include "northbridge/amd/amdk8/raminit.c"
 #include "northbridge/amd/amdk8/coherent_ht.c"
-#include "sdram/generic_sdram.c"
+#include "lib/generic_sdram.c"
 
  /* tyan does not want the default */
 #include "resourcemap.c" 

Modified: trunk/coreboot-v2/src/mainboard/via/epia/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/epia/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -9,7 +9,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/vt8601/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"
@@ -37,7 +37,7 @@
 
 #include "northbridge/via/vt8601/raminit.c"
 /*
-  #include "sdram/generic_sdram.c"
+  #include "lib/generic_sdram.c"
 */
 
 static void enable_mainboard_devices(void) 

Modified: trunk/coreboot-v2/src/mainboard/via/epia-cn/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-cn/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/epia-cn/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cn700/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/via/epia-m/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-m/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/epia-m/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -13,7 +13,7 @@
 #include <stdlib.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/vt8623/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/via/epia-m700/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-m700/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/epia-m700/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -36,7 +36,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/vx800/vx800.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/via/epia-n/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-n/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/epia-n/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cn400/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/via/pc2500e/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/pc2500e/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/pc2500e/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -31,7 +31,7 @@
 #include "pc80/mc146818rtc_early.c"
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cn700/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/mainboard/via/vt8454c/auto.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/vt8454c/auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/mainboard/via/vt8454c/auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -30,7 +30,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/cx700/raminit.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"

Modified: trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_test.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_test.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/northbridge/amd/amdk8/raminit_test.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -305,7 +305,7 @@
 }
 
 #include "raminit.c"
-#include "../../../sdram/generic_sdram.c"
+#include "../../../lib/generic_sdram.c"
 
 #define FIRST_CPU  1
 #define SECOND_CPU 1

Modified: trunk/coreboot-v2/src/northbridge/intel/e7520/raminit_test.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/intel/e7520/raminit_test.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/northbridge/intel/e7520/raminit_test.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -305,7 +305,7 @@
 }
 
 #include "raminit.c"
-#include "../../../sdram/generic_sdram.c"
+#include "../../../lib/generic_sdram.c"
 
 #define FIRST_CPU  1
 #define SECOND_CPU 1

Modified: trunk/coreboot-v2/src/northbridge/intel/e7525/raminit_test.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/intel/e7525/raminit_test.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/northbridge/intel/e7525/raminit_test.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -276,7 +276,7 @@
 }
 
 #include "raminit.c"
-#include "../../../sdram/generic_sdram.c"
+#include "../../../lib/generic_sdram.c"
 
 #define FIRST_CPU  1
 #define SECOND_CPU 1

Modified: trunk/coreboot-v2/src/northbridge/via/vx800/examples/cache_as_ram_auto.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/via/vx800/examples/cache_as_ram_auto.c	2009-09-23 17:59:56 UTC (rev 4660)
+++ trunk/coreboot-v2/src/northbridge/via/vx800/examples/cache_as_ram_auto.c	2009-09-23 18:51:03 UTC (rev 4661)
@@ -32,7 +32,7 @@
 #include <arch/hlt.h>
 #include "pc80/serial.c"
 #include "arch/i386/lib/console.c"
-#include "ram/ramtest.c"
+#include "lib/ramtest.c"
 #include "northbridge/via/vx800/vx800.h"
 #include "cpu/x86/mtrr/earlymtrr.c"
 #include "cpu/x86/bist.h"




From svn at coreboot.org  Wed Sep 23 20:54:18 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 20:54:18 +0200
Subject: [coreboot] [v2] r4662 - trunk/coreboot-v2/src
Message-ID: <mailman.3730.1355071621.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-23 20:54:18 +0200 (Wed, 23 Sep 2009)
New Revision: 4662

Removed:
   trunk/coreboot-v2/src/pmc/
Log:
Looks like this should have become cpu init code after growing up. The
remaining questions are:

- Why was it never used?
- Why is it in /src and not in /src/cpu/ppc?

Given this is dead code and part of an unmaintained powerpc port, I consider
removing it trivial. (The code really does not do much)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>







From info at coresystems.de  Wed Sep 23 21:19:49 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 21:19:49 +0200
Subject: [coreboot] build service results for r4661
Message-ID: <E1MqXNV-0001aG-Fe@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4661 to
the coreboot repository. This caused the following 
changes:

Change Log:
simplify source tree hierarchy: move files from sdram/ and ram/ to lib/
It's only three files. Also fix up all the paths (Gotta love included C files)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4661&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Wed Sep 23 21:52:30 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 21:52:30 +0200
Subject: [coreboot] build service results for r4662
Message-ID: <E1MqXt8-0005LN-Bb@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4662 to
the coreboot repository. This caused the following 
changes:

Change Log:
Looks like this should have become cpu init code after growing up. The
remaining questions are:

- Why was it never used?
- Why is it in /src and not in /src/cpu/ppc?

Given this is dead code and part of an unmaintained powerpc port, I consider
removing it trivial. (The code really does not do much)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>




Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4662&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Wed Sep 23 22:23:05 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 14:23:05 -0600
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
Message-ID: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>

src/boot/selfboot.c: In function 'get_bounce_buffer':
src/boot/ssrc/boot/selfboot.c: In function 'get_bounce_buffer':
src/boot/selfboot.c:113: warning: declaration of 'bounce_size' shadows a
global elfboot.c:113: warning: declaration of 'bounce_size' shadows a global



The global never got initialized, so I couldn't boot a kernel.  Now I can,
but I'm not sure this is the most elegant fix, or even that it is 100%
correct.

While I was there I changed another bounce_size to size to avoid confusion
with the global, and made selfboot static to get rid of this warning:

src/boot/selfboot.c:508: warning: no previous prototype for 'selfboot'

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/2aefcea9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbfs_bounce.diff
Type: text/x-patch
Size: 3459 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/2aefcea9/attachment.diff>

From rminnich at gmail.com  Wed Sep 23 22:28:27 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Sep 2009 13:28:27 -0700
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
Message-ID: <13426df10909231328q77169873s8101c591f6c7c6bf@mail.gmail.com>

Acked-by: Ronald G. Minnich <rminnich at gmail.com>



From patrick at georgi-clan.de  Wed Sep 23 22:30:34 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 23 Sep 2009 22:30:34 +0200
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
Message-ID: <1253737835.16990.1.camel@tetris>

Am Mittwoch, den 23.09.2009, 14:23 -0600 schrieb Myles Watson:
> The global never got initialized, so I couldn't boot a kernel.  Now I
> can, but I'm not sure this is the most elegant fix, or even that it is
> 100% correct.
Looks good to me. I had similar changes here already, but messed around
with That Other Selfboot Bug[tm] and thus have nothing finished yet.

> src/boot/selfboot.c:508: warning: no previous prototype for 'selfboot'
> 
> Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Regards,
Patrick




From svn at coreboot.org  Wed Sep 23 22:32:21 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 22:32:21 +0200
Subject: [coreboot] [v2] r4663 - in trunk/coreboot-v2/src: arch/i386/boot
	boot
Message-ID: <mailman.3731.1355071621.16123.coreboot@coreboot.org>

Author: myles
Date: 2009-09-23 22:32:21 +0200 (Wed, 23 Sep 2009)
New Revision: 4663

Modified:
   trunk/coreboot-v2/src/arch/i386/boot/boot.c
   trunk/coreboot-v2/src/boot/selfboot.c
Log:
Fix the bounce_size global so that the bounce buffer works with CBFS.

Make self_boot() static.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Modified: trunk/coreboot-v2/src/arch/i386/boot/boot.c
===================================================================
--- trunk/coreboot-v2/src/arch/i386/boot/boot.c	2009-09-23 18:54:18 UTC (rev 4662)
+++ trunk/coreboot-v2/src/arch/i386/boot/boot.c	2009-09-23 20:32:21 UTC (rev 4663)
@@ -68,7 +68,7 @@
 	
 }
 
-void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long bounce_size)
+void jmp_to_elf_entry(void *entry, unsigned long buffer, unsigned long size)
 {
 	extern unsigned char _ram_seg, _eram_seg;
 	unsigned long lb_start, lb_size;
@@ -79,7 +79,7 @@
 
 	lb_start = (unsigned long)&_ram_seg;
 	lb_size = (unsigned long)(&_eram_seg - &_ram_seg);
-	adjust = buffer + bounce_size - lb_start;
+	adjust = buffer +  size - lb_start;
 
 	adjusted_boot_notes = (unsigned long)&elf_boot_notes;
 	adjusted_boot_notes += adjust; 

Modified: trunk/coreboot-v2/src/boot/selfboot.c
===================================================================
--- trunk/coreboot-v2/src/boot/selfboot.c	2009-09-23 18:54:18 UTC (rev 4662)
+++ trunk/coreboot-v2/src/boot/selfboot.c	2009-09-23 20:32:21 UTC (rev 4663)
@@ -71,9 +71,10 @@
 	unsigned short ip_checksum;
 };
 
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
+
 void * cbfs_load_payload(struct lb_memory *lb_mem, const char *name)
 {
-	int selfboot(struct lb_memory *mem, struct cbfs_payload *payload);
 	struct cbfs_payload *payload;
 
 	payload = (struct cbfs_payload *)cbfs_find_file(name, CBFS_TYPE_PAYLOAD);
@@ -110,7 +111,7 @@
 
 static unsigned long bounce_size, bounce_buffer;
 
-static void get_bounce_buffer(struct lb_memory *mem, unsigned long bounce_size)
+static void get_bounce_buffer(struct lb_memory *mem, unsigned long req_size)
 {
 	unsigned long lb_size;
 	unsigned long mem_entries;
@@ -118,7 +119,7 @@
 	int i;
 	lb_size = (unsigned long)(&_eram_seg - &_ram_seg);
 	/* Double coreboot size so I have somewhere to place a copy to return to */
-	lb_size = bounce_size + lb_size;
+	lb_size = req_size + lb_size;
 	mem_entries = (mem->size - sizeof(*mem))/sizeof(mem->map[0]);
 	buffer = 0;
 	for(i = 0; i < mem_entries; i++) {
@@ -142,6 +143,7 @@
 		buffer = tbuffer;
 	}
 	bounce_buffer = buffer;
+	bounce_size = req_size;
 }
 
 static int valid_area(struct lb_memory *mem, unsigned long buffer,
@@ -424,7 +426,8 @@
 	for(ptr = head->next; ptr != head; ptr = ptr->next) {
 		if (!overlaps_coreboot(ptr)) continue;
 		unsigned long bounce = ptr->s_dstaddr + ptr->s_memsz - lb_start;
-		if (bounce > required_bounce_size) required_bounce_size = bounce;
+		if (bounce > required_bounce_size)
+			required_bounce_size = bounce;
 	}
 	get_bounce_buffer(mem, required_bounce_size);
 	if (!bounce_buffer) {
@@ -458,14 +461,12 @@
 			size_t len;
 			len = ptr->s_filesz;
 			switch(ptr->compression) {
-#if CONFIG_COMPRESSED_PAYLOAD_LZMA==1
 				case CBFS_COMPRESS_LZMA: {
 					printk_debug("using LZMA\n");
 					unsigned long ulzma(unsigned char *src, unsigned char *dst);		
 					len = ulzma(src, dest);
 					break;
 				}
-#endif
 #if CONFIG_COMPRESSED_PAYLOAD_NRV2B==1
 				case CBFS_COMPRESS_NRV2B: {
 					printk_debug("using NRV2B\n");
@@ -505,7 +506,7 @@
 	return 1;
 }
 
-int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
+static int selfboot(struct lb_memory *mem, struct cbfs_payload *payload)
 {
 	u32 entry=0;
 	struct segment head;




From mylesgw at gmail.com  Wed Sep 23 22:33:58 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 14:33:58 -0600
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <13426df10909231328q77169873s8101c591f6c7c6bf@mail.gmail.com>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
	<13426df10909231328q77169873s8101c591f6c7c6bf@mail.gmail.com>
Message-ID: <2831fecf0909231333k59cfd239sd94ab11ae7f6f2d1@mail.gmail.com>

On Wed, Sep 23, 2009 at 2:28 PM, ron minnich <rminnich at gmail.com> wrote:

> Acked-by: Ronald G. Minnich <rminnich at gmail.com>
>
Rev 4663.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/6cbcd95c/attachment.html>

From mylesgw at gmail.com  Wed Sep 23 22:35:02 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 14:35:02 -0600
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <1253737835.16990.1.camel@tetris>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
	<1253737835.16990.1.camel@tetris>
Message-ID: <2831fecf0909231335y7620ad2elaed6422ea1e64429@mail.gmail.com>

On Wed, Sep 23, 2009 at 2:30 PM, Patrick Georgi <patrick at georgi-clan.de>wrote:

> Am Mittwoch, den 23.09.2009, 14:23 -0600 schrieb Myles Watson:
> > The global never got initialized, so I couldn't boot a kernel.  Now I
> > can, but I'm not sure this is the most elegant fix, or even that it is
> > 100% correct.
> Looks good to me.

Thanks for the review.


> I had similar changes here already, but messed around
> with That Other Selfboot Bug[tm] and thus have nothing finished yet
>
I hope you get the fix committed before I find it the hard way :)

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/b2d65468/attachment.html>

From patrick at georgi-clan.de  Wed Sep 23 22:42:43 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Wed, 23 Sep 2009 22:42:43 +0200
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <2831fecf0909231335y7620ad2elaed6422ea1e64429@mail.gmail.com>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
	<1253737835.16990.1.camel@tetris>
	<2831fecf0909231335y7620ad2elaed6422ea1e64429@mail.gmail.com>
Message-ID: <1253738563.16990.12.camel@tetris>

Am Mittwoch, den 23.09.2009, 14:35 -0600 schrieb Myles Watson:
>         I had similar changes here already, but messed around
>         with That Other Selfboot Bug[tm] and thus have nothing
>         finished yet
> I hope you get the fix committed before I find it the hard way :)
The issue is that the loader doesn't properly cope with the case that
the payload overlaps with coreboot and starts at a lower address.

That happens on some AMD boards (with RAMBASE at 2MB, for whatever
reason) and FILO (which has a huge .bss section that moves well into
coreboot's memory).

Any other configuration should not run into this issue, and for AMD, it
should be enough to move RAMBASE to somewhere else (both 1MB and 4MB
worked for me) as a workaround.


Regards,
Patrick




From peter at stuge.se  Wed Sep 23 22:48:50 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 22:48:50 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
	<20090923184229.14543.qmail@stuge.se>
	<2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>
Message-ID: <20090923204850.3292.qmail@stuge.se>

Myles Watson wrote:
> In what way is the ops struct phony?

The device can not be discovered so code must know that the device is
there, and if code does, the ops provide no benefit but add
confusion and undesirable indirection.


//Peter



From peter at stuge.se  Wed Sep 23 22:51:08 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 22:51:08 +0200
Subject: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
Message-ID: <20090923205108.3787.qmail@stuge.se>

svn at coreboot.org wrote:
> simplify source tree hierarchy: move files from sdram/ and ram/ to lib/
> It's only three files. Also fix up all the paths (Gotta love included
> C files)

Definately a good change!

Do we have a strategy for the included C files? Will that be trivial
once Kconfig has settled in?


//Peter



From mylesgw at gmail.com  Wed Sep 23 22:55:13 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 14:55:13 -0600
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <20090923204850.3292.qmail@stuge.se>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
	<20090923184229.14543.qmail@stuge.se>
	<2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>
	<20090923204850.3292.qmail@stuge.se>
Message-ID: <2831fecf0909231355y5a95f8d0n64ba0244b4c207a5@mail.gmail.com>

On Wed, Sep 23, 2009 at 2:48 PM, Peter Stuge <peter at stuge.se> wrote:

> Myles Watson wrote:
> > In what way is the ops struct phony?
>
> The device can not be discovered so code must know that the device is
> there, and if code does, the ops provide no benefit but add
> confusion and undesirable indirection.
>

I'd be interested to see the alternative code.  Devices that can't be probed
for can still have resources that need to be read and set and init functions
to call.

Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/63f549c4/attachment.html>

From rminnich at gmail.com  Wed Sep 23 22:55:32 2009
From: rminnich at gmail.com (ron minnich)
Date: Wed, 23 Sep 2009 13:55:32 -0700
Subject: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
In-Reply-To: <20090923205108.3787.qmail@stuge.se>
References: <20090923205108.3787.qmail@stuge.se>
Message-ID: <13426df10909231355n1655416ak4ee151950ef202af@mail.gmail.com>

On Wed, Sep 23, 2009 at 1:51 PM, Peter Stuge <peter at stuge.se> wrote:

> Do we have a strategy for the included C files? Will that be trivial
> once Kconfig has settled in?

it's going to be a bit longer than that. I've done complete seperate
compilation for a few targets but, remember, if you're using romcc
you're including .c files.

ron



From info at coresystems.de  Wed Sep 23 22:56:15 2009
From: info at coresystems.de (coreboot information)
Date: Wed, 23 Sep 2009 22:56:15 +0200
Subject: [coreboot] build service results for r4663
Message-ID: <E1MqYsp-0003Dy-Te@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "myles" checked in revision 4663 to
the coreboot repository. This caused the following 
changes:

Change Log:
Fix the bounce_size global so that the bounce buffer works with CBFS.

Make self_boot() static.

Signed-off-by: Myles Watson <mylesgw at gmail.com>
Acked-by: Ronald G. Minnich <rminnich at gmail.com>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4663&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in myles's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From mylesgw at gmail.com  Wed Sep 23 23:00:11 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 15:00:11 -0600
Subject: [coreboot] [PATCH] CBFS bounce buffer fix
In-Reply-To: <1253738563.16990.12.camel@tetris>
References: <2831fecf0909231323o7f7d5045hf7375730908936e4@mail.gmail.com>
	<1253737835.16990.1.camel@tetris>
	<2831fecf0909231335y7620ad2elaed6422ea1e64429@mail.gmail.com>
	<1253738563.16990.12.camel@tetris>
Message-ID: <2831fecf0909231400o3db5b743tcdfe143e57332f1f@mail.gmail.com>

On Wed, Sep 23, 2009 at 2:42 PM, Patrick Georgi <patrick at georgi-clan.de>wrote:

> Am Mittwoch, den 23.09.2009, 14:35 -0600 schrieb Myles Watson:
> >         I had similar changes here already, but messed around
> >         with That Other Selfboot Bug[tm] and thus have nothing
> >         finished yet
> > I hope you get the fix committed before I find it the hard way :)
>


>  Any other configuration should not run into this issue, and for AMD, it
> should be enough to move RAMBASE to somewhere else (both 1MB and 4MB
> worked for me) as a workaround.
>
Great.  I'd forgotten that one, probably because it won't affect me.

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090923/85fba5d8/attachment.html>

From peter at stuge.se  Wed Sep 23 23:04:36 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 23:04:36 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <2831fecf0909231355y5a95f8d0n64ba0244b4c207a5@mail.gmail.com>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
	<20090923181256.7913.qmail@stuge.se>
	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>
	<20090923184229.14543.qmail@stuge.se>
	<2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>
	<20090923204850.3292.qmail@stuge.se>
	<2831fecf0909231355y5a95f8d0n64ba0244b4c207a5@mail.gmail.com>
Message-ID: <20090923210436.6047.qmail@stuge.se>

Myles Watson wrote:
> I'd be interested to see the alternative code.

Fair enough. I have none, but if it works as an object without ops
then is any more code needed?


> Devices that can't be probed for can still have resources that need
> to be read and set and init functions to call.

Yes, but wouldn't that all need to be done by code with knowledge of
the device (ie. just use static functions in the file) anyway?


//Peter



From peter at stuge.se  Wed Sep 23 23:07:40 2009
From: peter at stuge.se (Peter Stuge)
Date: Wed, 23 Sep 2009 23:07:40 +0200
Subject: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
In-Reply-To: <13426df10909231355n1655416ak4ee151950ef202af@mail.gmail.com>
References: <20090923205108.3787.qmail@stuge.se>
	<13426df10909231355n1655416ak4ee151950ef202af@mail.gmail.com>
Message-ID: <20090923210740.6748.qmail@stuge.se>

ron minnich wrote:
> > Do we have a strategy for the included C files? Will that be
> > trivial once Kconfig has settled in?
> 
> it's going to be a bit longer than that. I've done complete seperate
> compilation for a few targets but, remember, if you're using romcc
> you're including .c files.

Yes! Thanks! CAR is the key to that. But where there is CAR and
Kconfig, maybe it could be fixed up fairly easily.

I hope we can support both CAR and romcc use of the same source
without having to mess much with Kconfig.


//Peter



From mylesgw at gmail.com  Wed Sep 23 23:10:50 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Wed, 23 Sep 2009 15:10:50 -0600
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <20090923210436.6047.qmail@stuge.se>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com><20090923181256.7913.qmail@stuge.se><0E0F6A1D2DC14AC694536B54782A7DBA@chimp><20090923184229.14543.qmail@stuge.se><2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com><20090923204850.3292.qmail@stuge.se><2831fecf0909231355y5a95f8d0n64ba0244b4c207a5@mail.gmail.com>
	<20090923210436.6047.qmail@stuge.se>
Message-ID: <4FFDF591670B47FAAEDC13CF0A95943B@chimp>

> Myles Watson wrote:
> > I'd be interested to see the alternative code.
> Fair enough. I have none,
It wasn't supposed to be a challenge.  Just that I could tell we weren't
understanding each other somehow.  Pseudo code would have been fine.

> but if it works as an object without ops
> then is any more code needed?
Ah.  There's the point I've been missing in your argument.  It works _with_
ops in the object.  The ops get linked in to the device tree, so they get
used by the correct device even though it can't be discovered.

> > Devices that can't be probed for can still have resources that need
> > to be read and set and init functions to call.
> 
> Yes, but wouldn't that all need to be done by code with knowledge of
> the device (ie. just use static functions in the file) anyway?
Yes.  The problem is how to call them if you don't have an ops structure
somewhere.

Thanks,
Myles




From svn at coreboot.org  Wed Sep 23 23:52:45 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 23:52:45 +0200
Subject: [coreboot] [v2] r4664 - in trunk/coreboot-v2: src/cpu/amd/model_gx2
	src/cpu/amd/model_lx src/lib src/mainboard/artecgroup/dbe61/realmode
	src/mainboard/via/epia-m src/northbridge/via/cn400
	src/northbridge/via/cn700 src/northbridge/via/vx800 util/ADLO
	util/ADLO/bochs/bios util/cbfstool util/cbfstool/lzma/C util/x86emu
Message-ID: <mailman.3732.1355071621.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-23 23:52:45 +0200 (Wed, 23 Sep 2009)
New Revision: 4664

Modified:
   trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c
   trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c
   trunk/coreboot-v2/src/lib/xmodem.c
   trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c
   trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c
   trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c
   trunk/coreboot-v2/src/northbridge/via/cn700/vgabios.c
   trunk/coreboot-v2/src/northbridge/via/vx800/vgabios.c
   trunk/coreboot-v2/util/ADLO/COPYING
   trunk/coreboot-v2/util/ADLO/bochs/bios/Makefile
   trunk/coreboot-v2/util/cbfstool/elf.h
   trunk/coreboot-v2/util/cbfstool/lzma/C/LGPL.txt
   trunk/coreboot-v2/util/x86emu/x86.c
   trunk/coreboot-v2/util/x86emu/x86_asm.S
   trunk/coreboot-v2/util/x86emu/x86_interrupts.c
Log:
fix some wrong versions of the FSF's address (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/cpu/amd/model_gx2/vsmsetup.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -19,7 +19,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * LA-CC is the Los Alamos Control and Compliance Number, see also:
  * http://supply.lanl.gov/property/customs/eximguide/default.shtml

Modified: trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c
===================================================================
--- trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/cpu/amd/model_lx/vsmsetup.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -38,7 +38,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/src/lib/xmodem.c
===================================================================
--- trunk/coreboot-v2/src/lib/xmodem.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/lib/xmodem.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -14,7 +14,7 @@
 
     You should have received a copy of the GNU Lesser General Public License
     along with this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #include <string.h>

Modified: trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/mainboard/artecgroup/dbe61/realmode/vgabios.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -32,7 +32,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/mainboard/via/epia-m/vgabios.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -32,7 +32,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/northbridge/via/cn400/vgabios.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -32,7 +32,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/src/northbridge/via/cn700/vgabios.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/via/cn700/vgabios.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/northbridge/via/cn700/vgabios.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -32,7 +32,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/src/northbridge/via/vx800/vgabios.c
===================================================================
--- trunk/coreboot-v2/src/northbridge/via/vx800/vgabios.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/src/northbridge/via/vx800/vgabios.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -30,7 +30,7 @@
  *
  *  You should have received a copy of the GNU General Public License
  *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  *
  * Portions related to the alpha architecture are:
  *

Modified: trunk/coreboot-v2/util/ADLO/COPYING
===================================================================
--- trunk/coreboot-v2/util/ADLO/COPYING	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/ADLO/COPYING	2009-09-23 21:52:45 UTC (rev 4664)
@@ -2,7 +2,7 @@
 		       Version 2, June 1991
 
  Copyright (C) 1989, 1991 Free Software Foundation, Inc.
-                       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+                       51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
@@ -305,7 +305,7 @@
 
     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 
 
 Also add information on how to contact you by electronic and paper mail.

Modified: trunk/coreboot-v2/util/ADLO/bochs/bios/Makefile
===================================================================
--- trunk/coreboot-v2/util/ADLO/bochs/bios/Makefile	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/ADLO/bochs/bios/Makefile	2009-09-23 21:52:45 UTC (rev 4664)
@@ -18,7 +18,7 @@
 #
 # You should have received a copy of the GNU Lesser General Public
 # License along with this library; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 
 # Makefile for the BIOS component of bochs
 

Modified: trunk/coreboot-v2/util/cbfstool/elf.h
===================================================================
--- trunk/coreboot-v2/util/cbfstool/elf.h	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/cbfstool/elf.h	2009-09-23 21:52:45 UTC (rev 4664)
@@ -14,8 +14,8 @@
 
    You should have received a copy of the GNU Lesser General Public
    License along with the GNU C Library; if not, write to the Free
-   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
-   02111-1307 USA.  */
+   Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+   02110-1301 USA.  */
 
 #ifndef _ELF_H
 #define	_ELF_H 1

Modified: trunk/coreboot-v2/util/cbfstool/lzma/C/LGPL.txt
===================================================================
--- trunk/coreboot-v2/util/cbfstool/lzma/C/LGPL.txt	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/cbfstool/lzma/C/LGPL.txt	2009-09-23 21:52:45 UTC (rev 4664)
@@ -2,7 +2,7 @@
            Version 2.1, February 1999
 
  Copyright (C) 1991, 1999 Free Software Foundation, Inc.
-     59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+     51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 
@@ -485,7 +485,7 @@
 
     You should have received a copy of the GNU Lesser General Public
     License along with this library; if not, write to the Free Software
-    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 
 Also add information on how to contact you by electronic and paper mail.
 

Modified: trunk/coreboot-v2/util/x86emu/x86.c
===================================================================
--- trunk/coreboot-v2/util/x86emu/x86.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/x86emu/x86.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -14,7 +14,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  */
 
 #include <device/pci.h>

Modified: trunk/coreboot-v2/util/x86emu/x86_asm.S
===================================================================
--- trunk/coreboot-v2/util/x86emu/x86_asm.S	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/x86emu/x86_asm.S	2009-09-23 21:52:45 UTC (rev 4664)
@@ -14,7 +14,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  */
 
 #define REALMODE_BASE		0x500

Modified: trunk/coreboot-v2/util/x86emu/x86_interrupts.c
===================================================================
--- trunk/coreboot-v2/util/x86emu/x86_interrupts.c	2009-09-23 20:32:21 UTC (rev 4663)
+++ trunk/coreboot-v2/util/x86emu/x86_interrupts.c	2009-09-23 21:52:45 UTC (rev 4664)
@@ -16,7 +16,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
  */
 
 #include <device/pci.h>




From svn at coreboot.org  Wed Sep 23 23:53:25 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Wed, 23 Sep 2009 23:53:25 +0200
Subject: [coreboot] [v2] r4665 - trunk/util/nvramtool
Message-ID: <mailman.3733.1355071621.16123.coreboot@coreboot.org>

Author: stepan
Date: 2009-09-23 23:53:25 +0200 (Wed, 23 Sep 2009)
New Revision: 4665

Modified:
   trunk/util/nvramtool/DISCLAIMER
   trunk/util/nvramtool/cmos_lowlevel.c
   trunk/util/nvramtool/cmos_lowlevel.h
   trunk/util/nvramtool/cmos_ops.c
   trunk/util/nvramtool/cmos_ops.h
   trunk/util/nvramtool/common.c
   trunk/util/nvramtool/common.h
   trunk/util/nvramtool/input_file.c
   trunk/util/nvramtool/input_file.h
   trunk/util/nvramtool/layout.c
   trunk/util/nvramtool/layout.h
   trunk/util/nvramtool/layout_file.c
   trunk/util/nvramtool/layout_file.h
   trunk/util/nvramtool/lbtable.c
   trunk/util/nvramtool/lbtable.h
   trunk/util/nvramtool/nvramtool.8
   trunk/util/nvramtool/nvramtool.c
   trunk/util/nvramtool/opts.c
   trunk/util/nvramtool/opts.h
   trunk/util/nvramtool/reg_expr.c
   trunk/util/nvramtool/reg_expr.h
Log:
fix some wrong occurences of the FSF's address (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Modified: trunk/util/nvramtool/DISCLAIMER
===================================================================
--- trunk/util/nvramtool/DISCLAIMER	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/DISCLAIMER	2009-09-23 21:53:25 UTC (rev 4665)
@@ -23,7 +23,7 @@
 
 You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc.,
-59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 
 This work was produced at the University of California, Lawrence Livermore
 National Laboratory (UC LLNL) under contract no. W-7405-ENG-48 (Contract 48)

Modified: trunk/util/nvramtool/cmos_lowlevel.c
===================================================================
--- trunk/util/nvramtool/cmos_lowlevel.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/cmos_lowlevel.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #if defined(__FreeBSD__)

Modified: trunk/util/nvramtool/cmos_lowlevel.h
===================================================================
--- trunk/util/nvramtool/cmos_lowlevel.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/cmos_lowlevel.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef NVRAMTOOL_CMOS_LOWLEVEL_H

Modified: trunk/util/nvramtool/cmos_ops.c
===================================================================
--- trunk/util/nvramtool/cmos_ops.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/cmos_ops.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/cmos_ops.h
===================================================================
--- trunk/util/nvramtool/cmos_ops.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/cmos_ops.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef CMOS_OPS_H

Modified: trunk/util/nvramtool/common.c
===================================================================
--- trunk/util/nvramtool/common.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/common.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/common.h
===================================================================
--- trunk/util/nvramtool/common.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/common.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef COMMON_H

Modified: trunk/util/nvramtool/input_file.c
===================================================================
--- trunk/util/nvramtool/input_file.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/input_file.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/input_file.h
===================================================================
--- trunk/util/nvramtool/input_file.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/input_file.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef INPUT_FILE_H

Modified: trunk/util/nvramtool/layout.c
===================================================================
--- trunk/util/nvramtool/layout.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/layout.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/layout.h
===================================================================
--- trunk/util/nvramtool/layout.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/layout.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef LAYOUT_H

Modified: trunk/util/nvramtool/layout_file.c
===================================================================
--- trunk/util/nvramtool/layout_file.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/layout_file.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/layout_file.h
===================================================================
--- trunk/util/nvramtool/layout_file.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/layout_file.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef LAYOUT_FILE_H

Modified: trunk/util/nvramtool/lbtable.c
===================================================================
--- trunk/util/nvramtool/lbtable.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/lbtable.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -26,7 +26,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include <string.h>

Modified: trunk/util/nvramtool/lbtable.h
===================================================================
--- trunk/util/nvramtool/lbtable.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/lbtable.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef LBTABLE_H

Modified: trunk/util/nvramtool/nvramtool.8
===================================================================
--- trunk/util/nvramtool/nvramtool.8	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/nvramtool.8	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
 .\"
 .\"  You should have received a copy of the GNU General Public License along
 .\"  with this program; if not, write to the Free Software Foundation, Inc.,
-.\"  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+.\"  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 .\"***************************************************************************/
 .TH NVRAMTOOL 8 "September 2008"
 .SH NAME

Modified: trunk/util/nvramtool/nvramtool.c
===================================================================
--- trunk/util/nvramtool/nvramtool.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/nvramtool.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/opts.c
===================================================================
--- trunk/util/nvramtool/opts.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/opts.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include "common.h"

Modified: trunk/util/nvramtool/opts.h
===================================================================
--- trunk/util/nvramtool/opts.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/opts.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef OPTS_H

Modified: trunk/util/nvramtool/reg_expr.c
===================================================================
--- trunk/util/nvramtool/reg_expr.c	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/reg_expr.c	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #include <stdarg.h>

Modified: trunk/util/nvramtool/reg_expr.h
===================================================================
--- trunk/util/nvramtool/reg_expr.h	2009-09-23 21:52:45 UTC (rev 4664)
+++ trunk/util/nvramtool/reg_expr.h	2009-09-23 21:53:25 UTC (rev 4665)
@@ -25,7 +25,7 @@
  *
  *  You should have received a copy of the GNU General Public License along
  *  with this program; if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ *  51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 \*****************************************************************************/
 
 #ifndef REG_EXPR_H




From info at coresystems.de  Thu Sep 24 00:18:21 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 24 Sep 2009 00:18:21 +0200
Subject: [coreboot] build service results for r4664
Message-ID: <E1MqaAH-0001Lt-5R@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4664 to
the coreboot repository. This caused the following 
changes:

Change Log:
fix some wrong versions of the FSF's address (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4664&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From info at coresystems.de  Thu Sep 24 00:48:53 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 24 Sep 2009 00:48:53 +0200
Subject: [coreboot] build service results for r4665
Message-ID: <E1Mqadp-0003gR-TP@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "stepan" checked in revision 4665 to
the coreboot repository. This caused the following 
changes:

Change Log:
fix some wrong occurences of the FSF's address (trivial)

Signed-off-by: Stefan Reinauer <stepan at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4665&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in stepan's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From Zheng.Bao at amd.com  Thu Sep 24 05:15:08 2009
From: Zheng.Bao at amd.com (Bao, Zheng)
Date: Thu, 24 Sep 2009 11:15:08 +0800
Subject: [coreboot] duplicated code in Coreboot
Message-ID: <DD1CC71B621B004FA76856E5129D6B1703116C8D@sbjgexmb1.amd.com>

Since I started to work on the coreboot, I always sense that the much
code is duplicated. By duplicated, it doesn't mean the code in different
folders is almost same. As a matter of fact, it should be same. For
example, the most feature of it871(2,6,8) should be the same. But
it8712f_enable_serial doesn't use the first parameter dev, while
it8716f_enable_serial does. When the board changes the super io, you can
not just change the 2 to 6. You should also change the parameters. That
makes me confused.

This also happens on some chips which are close. Is it possible to fix
this in future?

Zheng




From peter at stuge.se  Thu Sep 24 05:52:19 2009
From: peter at stuge.se (Peter Stuge)
Date: Thu, 24 Sep 2009 05:52:19 +0200
Subject: [coreboot] duplicated code in Coreboot
In-Reply-To: <DD1CC71B621B004FA76856E5129D6B1703116C8D@sbjgexmb1.amd.com>
References: <DD1CC71B621B004FA76856E5129D6B1703116C8D@sbjgexmb1.amd.com>
Message-ID: <20090924035219.9285.qmail@stuge.se>

Bao, Zheng wrote:
> Is it possible to fix this in future?

I hope so! I would love to see it improve.

It's possible to start fixing it immediately. Please do!


So far not a lot of time has been spent on improving the state of the
codebase, because the typical procedure of major contribution to
coreboot is that the contributor sends several hundred kilobytes of
(working) source code to the mailing list, with very little if any
followup communication.

This way of contributing to an open source project places an
unneccessarily heavy burden on the project.

It is a contribution, and all contributions are valuable, but in the
long term this procedure leads to unneccessary extra work for
everyone who is involved in coreboot, and everyone who wishes to
benefit from coreboot.

I understand very much the desire to only send code when it is
working, and working well. But it is too late when the code is
"finished".

I would like to request that any contributors who work with coreboot
code send their lines of code as early as possible!


The ideal way to contribute to an open source project, such as
coreboot, is to send small changes very often over a long period of
time.

I think it is even OK to add a new, empty, file to the repository -
under the condition that code will be added to the file in a
following patch which is sent a few days later.

This allows small problems to be fixed in one place before they turn
into big problems existing in many places.

It also allows other developers to immediately benefit from the work
that has already been done. If someone is using the code that is
being developed, they can also help with development.


The key, which I myself struggle with, is to strive for letting as
many developers as possible benefit as much as possible as soon as
possible from what you develop. You will be thanked.


//Peter



From stepan at coresystems.de  Thu Sep 24 08:52:49 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 24 Sep 2009 08:52:49 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>
Message-ID: <4ABB1741.8020903@coresystems.de>

Myles Watson wrote:
> Drivers and objects seem interchangeable to me except that drivers get
> registered and checked against devices that are found during
> enumeration, that weren't mentioned in devicetree.cb.  Either one
> seems to get linked into the correct place if the device is mentioned
> in the device tree.
>
> Are there other differences?  Should I2C devices use objects, since
> you can't scan for them?

Some structures defined in the code are put in an extra section in the
binary for enumeration. Those are:

#define __console    __attribute__((used, __section__
(".rodata.console_drivers")))
#define __cpu_driver __attribute__
((used,__section__(".rodata.cpu_driver")))
#define __pci_driver __attribute__
((used,__section__(".rodata.pci_driver")))

All others don't need to be "drivers"

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From stepan at coresystems.de  Thu Sep 24 08:57:14 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 24 Sep 2009 08:57:14 +0200
Subject: [coreboot] Drivers vs. Objects
In-Reply-To: <20090923204850.3292.qmail@stuge.se>
References: <2831fecf0909231104m4ae0e645m5c1bbf8e2e3f739f@mail.gmail.com>	<20090923181256.7913.qmail@stuge.se>	<0E0F6A1D2DC14AC694536B54782A7DBA@chimp>	<20090923184229.14543.qmail@stuge.se>	<2831fecf0909231146l3c93049ekb361f432934f8e3a@mail.gmail.com>
	<20090923204850.3292.qmail@stuge.se>
Message-ID: <4ABB184A.5060907@coresystems.de>

Peter Stuge wrote:
> Myles Watson wrote:
>   
>> In what way is the ops struct phony?
>>     
>
> The device can not be discovered so code must know that the device is
> there, and if code does, the ops provide no benefit but add
> confusion and undesirable indirection.
>   
Not really.. It does not make much sense to go away from an object
oriented interface used for all other devices just because the one
device can not be autodetected...

Stefan




From patrick at georgi-clan.de  Thu Sep 24 08:58:52 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 24 Sep 2009 08:58:52 +0200
Subject: [coreboot] [PATCH]some kconfig fixes
Message-ID: <1253775532.4164.5.camel@tetris>

Hi,

attached patch fixes most Kconfig boards (as tested with kbuildall).

Specifically:
- CONFIG_SMP is always set (to 'n' if MAX_CPUS==1)
- HT_CHAIN_{END,}_UNIT_BASE is defined (probably at the wrong location,
  but please move it later. src/Kconfig is a good generic place to put
  stuff in that should be moved, imho)
- via/c3 is hooked up to the build
- mitac and soyo boards are hooked up to the build
- emulation/qemu-x86 is "normal form" now, so kbuildall picks it up
- three via boards were missing some definitions. FALLBACK_SIZE is a
  dummy until the via-specific vgabios handling code is either cleaned
  up or eliminated
- RAMBASE at 0x4000 for via boards is necessary due to the via-specific
  vgabios handling code. see above.
- kbuildall supports building a single board now, eg.
  util/kbuildall/kbuildall emulation/qemu-x86
  This is useful to quickly test changes to a board with the same
  default config that kbuildall usually uses.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>


Regards,
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20090924-1-kconfig
Type: text/x-patch
Size: 11401 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/f10d2bf0/attachment.diff>

From stepan at coresystems.de  Thu Sep 24 08:59:47 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 24 Sep 2009 08:59:47 +0200
Subject: [coreboot] [v2] r4661 - in trunk/coreboot-v2/src: ..
In-Reply-To: <20090923205108.3787.qmail@stuge.se>
References: <20090923205108.3787.qmail@stuge.se>
Message-ID: <4ABB18E3.3010204@coresystems.de>

Peter Stuge wrote:
> svn at coreboot.org wrote:
>   
>> simplify source tree hierarchy: move files from sdram/ and ram/ to lib/
>> It's only three files. Also fix up all the paths (Gotta love included
>> C files)
>>     
>
> Definately a good change!
>
> Do we have a strategy for the included C files? Will that be trivial
> once Kconfig has settled in?
>   
Not more trivial than today, but there is a way out of the misery :-)

Having Kconfig completed will at least keep us from doing these changes
in two different places. And they're an excellent excuse to drop the
non-Kconfig build method.

I know people are eager to get rid of this, but one step after another,
or the tree might fall apart..

Stefan

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From patrick at georgi-clan.de  Thu Sep 24 10:39:55 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 24 Sep 2009 10:39:55 +0200
Subject: [coreboot] [PATCH]more kconfig fixes
Message-ID: <1253781595.4164.8.camel@tetris>

Hi,

with this patch (and my previous one), all kconfig enabled boards build
for me.

Changes this time:
- Fix for superio/smsc/lpc47b272
- disable option table for asus/mew-vm
- change superio to use for compaq/deskpro_en_sff_p600 to be in line
  with what newconfig/buildtarget does


Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>

Regards,
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20090924-2-more-kconfig
Type: text/x-patch
Size: 1567 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/9c04349c/attachment.diff>

From stepan at coresystems.de  Thu Sep 24 10:53:57 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 24 Sep 2009 10:53:57 +0200
Subject: [coreboot] [PATCH]more kconfig fixes
In-Reply-To: <1253781595.4164.8.camel@tetris>
References: <1253781595.4164.8.camel@tetris>
Message-ID: <4ABB33A5.9040503@coresystems.de>

Patrick Georgi wrote:
> Hi,
>
> with this patch (and my previous one), all kconfig enabled boards build
> for me.
>
> Changes this time:
> - Fix for superio/smsc/lpc47b272
> - disable option table for asus/mew-vm
> - change superio to use for compaq/deskpro_en_sff_p600 to be in line
>   with what newconfig/buildtarget does
>
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>
> Regards,
> Patrick
>   
Acked-by: Stefan Reinauer <stepan at coresystems.de>

-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From stepan at coresystems.de  Thu Sep 24 10:59:14 2009
From: stepan at coresystems.de (Stefan Reinauer)
Date: Thu, 24 Sep 2009 10:59:14 +0200
Subject: [coreboot] [PATCH]some kconfig fixes
In-Reply-To: <1253775532.4164.5.camel@tetris>
References: <1253775532.4164.5.camel@tetris>
Message-ID: <4ABB34E2.3090508@coresystems.de>

Patrick Georgi wrote:
> Hi,
>
> attached patch fixes most Kconfig boards (as tested with kbuildall).
>
> Specifically:
> - CONFIG_SMP is always set (to 'n' if MAX_CPUS==1)
> - HT_CHAIN_{END,}_UNIT_BASE is defined (probably at the wrong location,
>   but please move it later. src/Kconfig is a good generic place to put
>   stuff in that should be moved, imho)
> - via/c3 is hooked up to the build
> - mitac and soyo boards are hooked up to the build
> - emulation/qemu-x86 is "normal form" now, so kbuildall picks it up
> - three via boards were missing some definitions. FALLBACK_SIZE is a
>   dummy until the via-specific vgabios handling code is either cleaned
>   up or eliminated
> - RAMBASE at 0x4000 for via boards is necessary due to the via-specific
>   vgabios handling code. see above.
> - kbuildall supports building a single board now, eg.
>   util/kbuildall/kbuildall emulation/qemu-x86
>   This is useful to quickly test changes to a board with the same
>   default config that kbuildall usually uses.
>
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
>
>   

Acked-by: Stefan Reinauer <stepan at coresystems.de>


-- 
coresystems GmbH ? Brahmsstr. 16 ? D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 ? Fax: +49 761 7664613
Email: info at coresystems.de  ? http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg ? HRB 7656
Gesch?ftsf?hrer: Stefan Reinauer ? Ust-IdNr.: DE245674866




From svn at coreboot.org  Thu Sep 24 11:03:06 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 24 Sep 2009 11:03:06 +0200
Subject: [coreboot] [v2] r4666 - in trunk/coreboot-v2: src src/cpu
	src/cpu/via src/mainboard src/mainboard/asus/mew-vm
	src/mainboard/compaq/deskpro_en_sff_p600
	src/mainboard/emulation src/mainboard/emulation/qemu-x86
	src/mainboard/mitac/6513wu src/mainboard/soyo/sy-6ba-plus-iii
	src/mainboard/via/epia-n src/mainboard/via/vt8454c
	src/northbridge/via/cn400 src/superio/smsc/lpc47b272 util/kbuildall
Message-ID: <mailman.3734.1355071621.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-24 11:03:06 +0200 (Thu, 24 Sep 2009)
New Revision: 4666

Added:
   trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Kconfig
   trunk/coreboot-v2/src/mainboard/mitac/6513wu/devicetree.cb
   trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb
Modified:
   trunk/coreboot-v2/src/Kconfig
   trunk/coreboot-v2/src/cpu/Kconfig
   trunk/coreboot-v2/src/cpu/via/Kconfig
   trunk/coreboot-v2/src/mainboard/Kconfig
   trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig
   trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig
   trunk/coreboot-v2/src/mainboard/emulation/Kconfig
   trunk/coreboot-v2/src/mainboard/via/epia-n/Kconfig
   trunk/coreboot-v2/src/mainboard/via/vt8454c/Kconfig
   trunk/coreboot-v2/src/northbridge/via/cn400/Kconfig
   trunk/coreboot-v2/src/superio/smsc/lpc47b272/Makefile.inc
   trunk/coreboot-v2/util/kbuildall/kbuildall
Log:
Make all Kconfig enabled boards build (tested with kbuildall).
Also enable building individual boards with kbuildall for
debugging.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Modified: trunk/coreboot-v2/src/Kconfig
===================================================================
--- trunk/coreboot-v2/src/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -44,6 +44,14 @@
 	bool
 	default n
 
+config HT_CHAIN_UNITID_BASE
+	hex
+	default 0x1
+
+config HT_CHAIN_END_UNITID_BASE
+	hex
+	default 0x20
+
 config MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID
 	hex
 	default 0

Modified: trunk/coreboot-v2/src/cpu/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/cpu/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -20,6 +20,7 @@
 config SMP
 	bool
 	default y if MAX_CPUS != 1
+	default n
 
 config CPU_SOCKET_TYPE
 	hex

Modified: trunk/coreboot-v2/src/cpu/via/Kconfig
===================================================================
--- trunk/coreboot-v2/src/cpu/via/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/cpu/via/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -1 +1,2 @@
+source src/cpu/via/model_c3/Kconfig
 source src/cpu/via/model_c7/Kconfig

Modified: trunk/coreboot-v2/src/mainboard/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -374,6 +374,7 @@
 source "src/mainboard/jetway/Kconfig"
 source "src/mainboard/kontron/Kconfig"
 source "src/mainboard/lippert/Kconfig"
+source "src/mainboard/mitac/Kconfig"
 source "src/mainboard/motorola/Kconfig"
 source "src/mainboard/msi/Kconfig"
 source "src/mainboard/nec/Kconfig"
@@ -382,6 +383,7 @@
 source "src/mainboard/olpc/Kconfig"
 source "src/mainboard/pcengines/Kconfig"
 source "src/mainboard/rca/Kconfig"
+source "src/mainboard/soyo/Kconfig"
 source "src/mainboard/sunw/Kconfig"
 source "src/mainboard/supermicro/Kconfig"
 source "src/mainboard/technexion/Kconfig"

Modified: trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -24,7 +24,7 @@
 	select CPU_INTEL_SOCKET_PGA370
 	select NORTHBRIDGE_INTEL_I82810
 	select SOUTHBRIDGE_INTEL_I82801XX
-	select SUPERIO_SMSC_SMSCSUPERIO
+	select SUPERIO_SMSC_LPC47B272
 	select HAVE_PIRQ_TABLE
 	select UDELAY_IO
 	select PCI_ROM_RUN
@@ -42,6 +42,11 @@
 	default "MEW-VM"
 	depends on BOARD_ASUS_MEW_VM
 
+config HAVE_OPTION_TABLE
+	bool
+	default n
+	depends on BOARD_ASUS_MEW_VM
+
 config IRQ_SLOT_COUNT
 	int
 	default 11

Modified: trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -24,7 +24,8 @@
 	select CPU_INTEL_SLOT_2
 	select NORTHBRIDGE_INTEL_I440BX
 	select SOUTHBRIDGE_INTEL_I82371EB
-	select SUPERIO_NSC_PC97307
+	# should be SUPERIO_NSC_PC97307!
+	select SUPERIO_NSC_PC97317
 	select HAVE_PIRQ_TABLE
 	select UDELAY_IO
 	select PCI_ROM_RUN

Modified: trunk/coreboot-v2/src/mainboard/emulation/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/emulation/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/emulation/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -2,24 +2,6 @@
 	prompt "Mainboard model"
 	depends on VENDOR_EMULATION
 
-config BOARD_EMULATION_QEMU_X86
-	bool "QEMU x86"
-	select ARCH_X86
-	select CPU_I586
-	select SOUTHBRIDGE_INTEL_I82371EB
-	select CPU_EMULATION_QEMU_X86
-	select CONSOLE_SERIAL8250
-	help
-	  x86 QEMU variant.
+source "src/mainboard/emulation/qemu-x86/Kconfig"
 
 endchoice
-
-config MAINBOARD_DIR
-	string
-	default emulation/qemu-x86
-	depends on BOARD_EMULATION_QEMU_X86
-
-config MAINBOARD_PART_NUMBER
-	string
-	default "QEMU-86"
-	depends on BOARD_EMULATION_QEMU_X86

Added: trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Kconfig	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/emulation/qemu-x86/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -0,0 +1,19 @@
+config BOARD_EMULATION_QEMU_X86
+	bool "QEMU x86"
+	select ARCH_X86
+	select CPU_I586
+	select SOUTHBRIDGE_INTEL_I82371EB
+	select CPU_EMULATION_QEMU_X86
+	select CONSOLE_SERIAL8250
+	help
+	  x86 QEMU variant.
+
+config MAINBOARD_DIR
+	string
+	default emulation/qemu-x86
+	depends on BOARD_EMULATION_QEMU_X86
+
+config MAINBOARD_PART_NUMBER
+	string
+	default "QEMU-86"
+	depends on BOARD_EMULATION_QEMU_X86

Added: trunk/coreboot-v2/src/mainboard/mitac/6513wu/devicetree.cb
===================================================================
--- trunk/coreboot-v2/src/mainboard/mitac/6513wu/devicetree.cb	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/mitac/6513wu/devicetree.cb	2009-09-24 09:03:06 UTC (rev 4666)
@@ -0,0 +1,87 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Michael Gold <mgold at ncf.ca>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+chip northbridge/intel/i82810           # Northbridge
+  device apic_cluster 0 on              # APIC cluster
+    chip cpu/intel/socket_PGA370        # CPU
+      device apic 0 on end              # APIC
+    end
+  end
+  device pci_domain 0 on                # PCI domain
+    device pci 0.0 on end               # Graphics Memory Controller Hub (GMCH)
+    chip drivers/pci/onboard
+      device pci 1.0 on end
+      register "rom_address" = "0xfff80000" # 512 KB image
+    end
+    chip southbridge/intel/i82801xx     # Southbridge
+      register "pirqa_routing" = "0x03"
+      register "pirqb_routing" = "0x05"
+      register "pirqc_routing" = "0x09"
+      register "pirqd_routing" = "0x0b"
+
+      register "ide0_enable" = "1"
+      register "ide1_enable" = "1"
+
+      device pci 1e.0 on                # PCI bridge
+        device pci 5.0 on end           # Audio controller (ESS ES1988)
+      end
+      device pci 1f.0 on                # ISA bridge
+        chip superio/smsc/smscsuperio   # Super I/O (SMSC LPC47U332)
+          device pnp 4e.0 on            # Floppy
+            io 0x60 = 0x3f0
+            irq 0x70 = 6
+            drq 0x74 = 2
+          end
+          device pnp 4e.3 on            # Parallel port
+            io 0x60 = 0x378
+            irq 0x70 = 7
+            drq 0x74 = 3
+          end
+          device pnp 4e.4 on            # COM1
+            io 0x60 = 0x3f8
+            irq 0x70 = 4
+          end
+          device pnp 4e.5 on            # MIDI port (MPU-401)
+            io 0x60 = 0x330
+            irq 0x70 = 10
+          end
+          device pnp 4e.7 on            # PS/2 keyboard / mouse
+            io 0x60 = 0x60              # XXX: not relocatable
+            io 0x62 = 0x64              # XXX: not relocatable
+            irq 0x70 = 1                # PS/2 keyboard interrupt
+            irq 0x72 = 12               # PS/2 mouse interrupt
+          end
+          device pnp 4e.9 on            # Game port
+            io 0x60 = 0x201
+          end
+          device pnp 4e.a on            # Runtime registers
+            io 0x60 = 0x400
+          end
+          device pnp 4e.b off end       # SMBus
+        end
+      end
+      device pci 1f.1 on end            # IDE
+      device pci 1f.2 on end            # USB
+      device pci 1f.3 on end            # SMbus
+      device pci 1f.5 off end           # Audio controller
+      device pci 1f.6 off end           # Modem
+    end
+  end
+end

Added: trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb
===================================================================
--- trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb	                        (rev 0)
+++ trunk/coreboot-v2/src/mainboard/soyo/sy-6ba-plus-iii/devicetree.cb	2009-09-24 09:03:06 UTC (rev 4666)
@@ -0,0 +1,73 @@
+##
+## This file is part of the coreboot project.
+##
+## Copyright (C) 2009 Uwe Hermann <uwe at hermann-uwe.de>
+##
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
+##
+
+chip northbridge/intel/i440bx		# Northbridge
+  device apic_cluster 0 on		# APIC cluster
+    chip cpu/intel/slot_2		# CPU (FIXME: It's slot 1, actually)
+      device apic 0 on end		# APIC
+    end
+  end
+  device pci_domain 0 on		# PCI domain
+    device pci 0.0 on end		# Host bridge
+    device pci 1.0 on end		# PCI/AGP bridge
+    chip southbridge/intel/i82371eb	# Southbridge
+      device pci 7.0 on			# ISA bridge
+        chip superio/ite/it8671f	# Super I/O
+          device pnp 370.0 on		# Floppy
+            io 0x60 = 0x3f0
+            irq 0x70 = 6
+            drq 0x74 = 2
+          end
+          device pnp 370.1 on		# COM1
+            io 0x60 = 0x3f8
+            irq 0x70 = 4
+          end
+          device pnp 370.2 on		# COM2
+            io 0x60 = 0x2f8
+            irq 0x70 = 3
+          end
+          device pnp 370.3 on		# Parallel port
+            io 0x60 = 0x378
+            irq 0x70 = 7
+          end
+          device pnp 370.5 on		# PS/2 keyboard
+            io 0x60 = 0x60
+            io 0x62 = 0x64
+            irq 0x70 = 1
+          end
+          device pnp 370.6 on           # PS/2 mouse
+            irq 0x70 = 12
+          end
+        end
+      end
+      device pci 7.1 on	end		# IDE
+      device pci 7.2 on	end		# USB
+      device pci 7.3 on end		# ACPI
+      register "ide0_enable" = "1"
+      register "ide1_enable" = "1"
+      register "ide_legacy_enable" = "1"
+      # Enable UDMA/33 for higher speed if your IDE device(s) support it.
+      register "ide0_drive0_udma33_enable" = "0"
+      register "ide0_drive1_udma33_enable" = "0"
+      register "ide1_drive0_udma33_enable" = "0"
+      register "ide1_drive1_udma33_enable" = "0"
+    end
+  end
+end

Modified: trunk/coreboot-v2/src/mainboard/via/epia-n/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/epia-n/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/via/epia-n/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -35,3 +35,7 @@
 	default 32
 	depends on BOARD_VIA_EPIA_N
 
+config RAMBASE
+	hex
+	default 0x4000
+	depends on BOARD_VIA_EPIA_N

Modified: trunk/coreboot-v2/src/mainboard/via/vt8454c/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/via/vt8454c/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/mainboard/via/vt8454c/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -30,3 +30,13 @@
 	string
 	default "VT8454C"
 	depends on BOARD_VIA_VT8454C
+
+config IRQ_SLOT_COUNT
+	int
+	default 15
+	depends on BOARD_VIA_VT8454C
+
+config RAMBASE
+	hex
+	default 0x4000
+	depends on BOARD_VIA_VT8454C

Modified: trunk/coreboot-v2/src/northbridge/via/cn400/Kconfig
===================================================================
--- trunk/coreboot-v2/src/northbridge/via/cn400/Kconfig	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/northbridge/via/cn400/Kconfig	2009-09-24 09:03:06 UTC (rev 4666)
@@ -1,3 +1,8 @@
 config NORTHBRIDGE_VIA_CN400
 	bool
 	default n
+
+config FALLBACK_SIZE
+	int
+	default 0
+	depends on NORTHBRIDGE_VIA_CN400

Modified: trunk/coreboot-v2/src/superio/smsc/lpc47b272/Makefile.inc
===================================================================
--- trunk/coreboot-v2/src/superio/smsc/lpc47b272/Makefile.inc	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/src/superio/smsc/lpc47b272/Makefile.inc	2009-09-24 09:03:06 UTC (rev 4666)
@@ -19,5 +19,5 @@
 ##
 
 #config chip.h
-obj-$(CONFIG_SUPERIO_SMSC_DEVICE) += superio.o
+obj-$(CONFIG_SUPERIO_SMSC_LPC47B272) += superio.o
 

Modified: trunk/coreboot-v2/util/kbuildall/kbuildall
===================================================================
--- trunk/coreboot-v2/util/kbuildall/kbuildall	2009-09-23 21:53:25 UTC (rev 4665)
+++ trunk/coreboot-v2/util/kbuildall/kbuildall	2009-09-24 09:03:06 UTC (rev 4666)
@@ -12,6 +12,7 @@
 #  of this archive for more details.
 
 TARGETDIR=kbuildall.results
+BOARD=$1
 
 if [ ! -f util/kbuildall/kbuildall ]; then
 	echo "This application must be run from the"
@@ -36,10 +37,16 @@
 	yes "" | $MAKE oldconfig
 }
 
-rm -rf $TARGETDIR
-mkdir -p $TARGETDIR
 ALLTARGETS=`(cd src/mainboard; ls */*/Config.lb | sed s,/Config.lb,,)`
 TARGETCOUNT=`echo $ALLTARGETS | wc -w`
+
+if [ -n "$BOARD" ]; then
+	TARGETCOUNT=1
+	ALLTARGETS=$BOARD
+else
+	rm -rf $TARGETDIR
+fi
+mkdir -p $TARGETDIR
 CURRENTARGET=0
 for dir in $ALLTARGETS; do
 	i=`expr $i + 1`




From cuneyt at entegra.com.sg  Thu Sep 24 11:15:28 2009
From: cuneyt at entegra.com.sg (Cuneyt M)
Date: Thu, 24 Sep 2009 17:15:28 +0800
Subject: [coreboot] How to get started - new system?
In-Reply-To: <mailman.367.1253782987.8809.coreboot@coreboot.org>
References: <mailman.367.1253782987.8809.coreboot@coreboot.org>
Message-ID: <4ABB38B0.509@entegra.com.sg>

Dear All,

I am looking to learn more about coreboot and start from somewhere.

Is there any netbook (Intel Atom based or other) or nettop (like Asus 
eePC Box or any other that can fit at the back of an LCD screen)
that You can advise; compatible with coreboot - tried and tested ?

I have a few VIA C7 based systems ( 
http://www.gigabyte.com.tw/Products/Barebone/Products_Spec.aspx?ProductID=2436 
) not sure about their compatibility.
I haven't check the mainboard but i presume the BIOS is soldered.

Do you have any inputs and/or reference systems for thinclient 
applications ?

all the best.






From info at coresystems.de  Thu Sep 24 11:26:24 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 24 Sep 2009 11:26:24 +0200
Subject: [coreboot] build service results for r4666
Message-ID: <E1Mqkam-0003Tx-Lt@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "oxygene" checked in revision 4666 to
the coreboot repository. This caused the following 
changes:

Change Log:
Make all Kconfig enabled boards build (tested with kbuildall).
Also enable building individual boards with kbuildall for
debugging.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Stefan Reinauer <stepan at coresystems.de>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4666&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4666&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4666&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in oxygene's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Thu Sep 24 11:28:42 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 24 Sep 2009 11:28:42 +0200
Subject: [coreboot] [v2] r4667 - trunk/coreboot-v2/util/kbuildall
Message-ID: <mailman.3735.1355071621.16123.coreboot@coreboot.org>

Author: oxygene
Date: 2009-09-24 11:28:41 +0200 (Thu, 24 Sep 2009)
New Revision: 4667

Modified:
   trunk/coreboot-v2/util/kbuildall/kbuildall
Log:
Trivial fix for kbuildall: initialize "i", not CURRENTARGET [sic]
that isn't used anywhere.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Modified: trunk/coreboot-v2/util/kbuildall/kbuildall
===================================================================
--- trunk/coreboot-v2/util/kbuildall/kbuildall	2009-09-24 09:03:06 UTC (rev 4666)
+++ trunk/coreboot-v2/util/kbuildall/kbuildall	2009-09-24 09:28:41 UTC (rev 4667)
@@ -47,7 +47,7 @@
 	rm -rf $TARGETDIR
 fi
 mkdir -p $TARGETDIR
-CURRENTARGET=0
+i=0
 for dir in $ALLTARGETS; do
 	i=`expr $i + 1`
 	if [ ! -f src/mainboard/$dir/Kconfig ]; then




From info at coresystems.de  Thu Sep 24 11:51:41 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 24 Sep 2009 11:51:41 +0200
Subject: [coreboot] build service results for r4667
Message-ID: <E1MqkzF-0005ET-Ke@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "oxygene" checked in revision 4667 to
the coreboot repository. This caused the following 
changes:

Change Log:
Trivial fix for kbuildall: initialize "i", not CURRENTARGET [sic]
that isn't used anywhere.

Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>


Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4667&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4667&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4667&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in oxygene's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From svn at coreboot.org  Thu Sep 24 14:17:07 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 24 Sep 2009 14:17:07 +0200
Subject: [coreboot] [v2] r4668 - trunk/util/superiotool
Message-ID: <mailman.3736.1355071621.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-09-24 14:17:07 +0200 (Thu, 24 Sep 2009)
New Revision: 4668

Modified:
   trunk/util/superiotool/smsc.c
Log:
Add detection support for the SMSC FDC37M602.

The ID was found on a Biostar M6TLD board (not mentioned in the
FDC37M60x datasheet, though).

Thanks Maciej Pijanka <maciej.pijanka at gmail.com> for the report.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Modified: trunk/util/superiotool/smsc.c
===================================================================
--- trunk/util/superiotool/smsc.c	2009-09-24 09:28:41 UTC (rev 4667)
+++ trunk/util/superiotool/smsc.c	2009-09-24 12:17:07 UTC (rev 4668)
@@ -276,6 +276,8 @@
 			{0x30,0x60,0x61,0x70,0xf0,EOT},
 			{0x00,0x00,0x00,NANA,NANA,EOT}},
 		{EOT}}},
+	{0x46, "FDC37M602", {	/* Found in Biostar M6TLD. */
+		{EOT}}},
 	{0x47, "FDC37M60x", {	/* TODO: Not yet in sensors-detect */
 		{EOT}}},
 	{0x4c, "FDC37B72x", {




From info at coresystems.de  Thu Sep 24 14:41:13 2009
From: info at coresystems.de (coreboot information)
Date: Thu, 24 Sep 2009 14:41:13 +0200
Subject: [coreboot] build service results for r4668
Message-ID: <E1MqndJ-0006mg-10@ra.coresystems.de>

Dear coreboot readers!

This is the automatic build system of coreboot.

The developer "uwe" checked in revision 4668 to
the coreboot repository. This caused the following 
changes:

Change Log:
Add detection support for the SMSC FDC37M602.

The ID was found on a Biostar M6TLD board (not mentioned in the
FDC37M60x datasheet, though).

Thanks Maciej Pijanka <maciej.pijanka at gmail.com> for the report.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Uwe Hermann <uwe at hermann-uwe.de>



Build Log:
Compilation of embeddedplanet:ep405pc is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4668&device=ep405pc&vendor=embeddedplanet&num=2
Compilation of motorola:sandpointx3_altimus_mpc7410 is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4668&device=sandpointx3_altimus_mpc7410&vendor=motorola&num=2
Compilation of totalimpact:briq is still broken
See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=4668&device=briq&vendor=totalimpact&num=2


If something broke during this checkin please be a pain 
in uwe's neck until the issue is fixed.

If this issue is not fixed within 24h the revision should 
be backed out.

   Best regards,
     coreboot automatic build system





From uwe at hermann-uwe.de  Thu Sep 24 14:52:41 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 24 Sep 2009 14:52:41 +0200
Subject: [coreboot] [PATCH] Re-enable option table for the ASUS MEW-VM and
	fix build
In-Reply-To: <1253781595.4164.8.camel@tetris>
References: <1253781595.4164.8.camel@tetris>
Message-ID: <20090924125241.GA18588@greenwood>

On Thu, Sep 24, 2009 at 10:39:55AM +0200, Patrick Georgi wrote:
> Hi,
> 
> with this patch (and my previous one), all kconfig enabled boards build
> for me.
> 
> Changes this time:
> - Fix for superio/smsc/lpc47b272
> - disable option table for asus/mew-vm
> - change superio to use for compaq/deskpro_en_sff_p600 to be in line
>   with what newconfig/buildtarget does
> 
> 
> Signed-off-by: Patrick Georgi <patrick.georgi at coresystems.de>

This was r4666.

Most of the patch looks good, but disabling HAVE_OPTION_TABLE is
incorrect I think, as the board _does_ have a cmos.layout file.

The bug which prevented a successful build was a typo in the
Makefile. Attached patch should fix it.


> Index: src/mainboard/compaq/deskpro_en_sff_p600/Kconfig
> ===================================================================
> --- src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	(Revision 4665)
> +++ src/mainboard/compaq/deskpro_en_sff_p600/Kconfig	(Arbeitskopie)
> @@ -24,7 +24,8 @@
>  	select CPU_INTEL_SLOT_2
>  	select NORTHBRIDGE_INTEL_I440BX
>  	select SOUTHBRIDGE_INTEL_I82371EB
> -	select SUPERIO_NSC_PC97307
> +	# should be SUPERIO_NSC_PC97307!
> +	select SUPERIO_NSC_PC97317
>  	select HAVE_PIRQ_TABLE
>  	select UDELAY_IO
>  	select PCI_ROM_RUN

Yep, the PC97307 doesn't properly build right now (if it ever did), will
look into it.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v2_kconfig_option_table_fix.patch
Type: text/x-diff
Size: 1238 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/1ba1a70a/attachment.bin>

From mylesgw at gmail.com  Thu Sep 24 15:02:09 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 24 Sep 2009 07:02:09 -0600
Subject: [coreboot] [PATCH]some kconfig fixes
In-Reply-To: <1253775532.4164.5.camel@tetris>
References: <1253775532.4164.5.camel@tetris>
Message-ID: <BF805A2C108C4CCDB3FF6EF9829D96C5@chimp>

> Specifically:
> - CONFIG_SMP is always set (to 'n' if MAX_CPUS==1)
Thanks. I didn't know how to do that correctly.

> - HT_CHAIN_{END,}_UNIT_BASE is defined (probably at the wrong location,
>   but please move it later. src/Kconfig is a good generic place to put
>   stuff in that should be moved, imho)
These are very board-specific.  The boards that were breaking should have
defined them.  Which boards were breaking because they weren't defined?

I think now is the time to get that kind of thing right.

Thanks,
Myles





From patrick at georgi-clan.de  Thu Sep 24 15:04:10 2009
From: patrick at georgi-clan.de (Patrick Georgi)
Date: Thu, 24 Sep 2009 15:04:10 +0200
Subject: [coreboot] [PATCH] Re-enable option table for the ASUS MEW-VM
 and fix build
In-Reply-To: <20090924125241.GA18588@greenwood>
References: <1253781595.4164.8.camel@tetris> <20090924125241.GA18588@greenwood>
Message-ID: <1253797450.16015.2.camel@tetris>

Am Donnerstag, den 24.09.2009, 14:52 +0200 schrieb Uwe Hermann:
> Most of the patch looks good, but disabling HAVE_OPTION_TABLE is
> incorrect I think, as the board _does_ have a cmos.layout file.
I simply made it correspond to the newconfig configuration:
Options.lb:default CONFIG_HAVE_OPTION_TABLE = 0

> The bug which prevented a successful build was a typo in the
> Makefile. Attached patch should fix it.
I don't care about any improvements over that at this time, but the
change in Makefile.romccboard.inc looks fine.
In case this is build tested by you (esp. that asus/mew-vm really
builds), this is

Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>




From svn at coreboot.org  Thu Sep 24 16:05:20 2009
From: svn at coreboot.org (svn at coreboot.org)
Date: Thu, 24 Sep 2009 16:05:20 +0200
Subject: [coreboot] [v2] r4669 - in trunk/coreboot-v2/src/mainboard: .
	asus/mew-vm
Message-ID: <mailman.3737.1355071621.16123.coreboot@coreboot.org>

Author: uwe
Date: 2009-09-24 16:05:19 +0200 (Thu, 24 Sep 2009)
New Revision: 4669

Modified:
   trunk/coreboot-v2/src/mainboard/Makefile.romccboard.inc
   trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig
Log:
Re-enable option table for the ASUS MEW-VM and fix build.

Signed-off-by: Uwe Hermann <uwe at hermann-uwe.de>
Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>



Modified: trunk/coreboot-v2/src/mainboard/Makefile.romccboard.inc
===================================================================
--- trunk/coreboot-v2/src/mainboard/Makefile.romccboard.inc	2009-09-24 12:17:07 UTC (rev 4668)
+++ trunk/coreboot-v2/src/mainboard/Makefile.romccboard.inc	2009-09-24 14:05:19 UTC (rev 4669)
@@ -47,7 +47,7 @@
 $(obj)/mainboard/$(MAINBOARDDIR)/failover.inc: $(obj)/romcc $(src)/arch/i386/lib/failover.c
 	$(obj)/romcc -mcpu=p2 -O2 --label-prefix=failover $(INCLUDES) $(src)/arch/i386/lib/failover.c -o $@
 
-ifeq ($(HAVE_OPTION_TABLE),y)
+ifeq ($(CONFIG_HAVE_OPTION_TABLE),y)
 $(obj)/mainboard/$(MAINBOARDDIR)/auto.inc: $(obj)/romcc $(src)/mainboard/$(MAINBOARDDIR)/auto.c $(obj)/option_table.h
 	$(obj)/romcc -mcpu=p2 -O2 $(INCLUDES) $(src)/mainboard/$(MAINBOARDDIR)/auto.c -o $@
 else

Modified: trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig
===================================================================
--- trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig	2009-09-24 12:17:07 UTC (rev 4668)
+++ trunk/coreboot-v2/src/mainboard/asus/mew-vm/Kconfig	2009-09-24 14:05:19 UTC (rev 4669)
@@ -42,11 +42,6 @@
 	default "MEW-VM"
 	depends on BOARD_ASUS_MEW_VM
 
-config HAVE_OPTION_TABLE
-	bool
-	default n
-	depends on BOARD_ASUS_MEW_VM
-
 config IRQ_SLOT_COUNT
 	int
 	default 11




From uwe at hermann-uwe.de  Thu Sep 24 16:08:42 2009
From: uwe at hermann-uwe.de (Uwe Hermann)
Date: Thu, 24 Sep 2009 16:08:42 +0200
Subject: [coreboot] [PATCH] Re-enable option table for the ASUS MEW-VM
 and fix build
In-Reply-To: <1253797450.16015.2.camel@tetris>
References: <1253781595.4164.8.camel@tetris> <20090924125241.GA18588@greenwood>
	<1253797450.16015.2.camel@tetris>
Message-ID: <20090924140842.GB4995@greenwood>

On Thu, Sep 24, 2009 at 03:04:10PM +0200, Patrick Georgi wrote:
> Am Donnerstag, den 24.09.2009, 14:52 +0200 schrieb Uwe Hermann:
> > Most of the patch looks good, but disabling HAVE_OPTION_TABLE is
> > incorrect I think, as the board _does_ have a cmos.layout file.
> I simply made it correspond to the newconfig configuration:
> Options.lb:default CONFIG_HAVE_OPTION_TABLE = 0

Hm, probably yet another copy-paste occurance in our tree, the
cmos.layout got copied and never enabled or so. Anyway, we should
fix this in another patch by (IMHO) making one or two "generic"
cmos.layout files which boards without special needs can use.

I estimate that 80% or so of all those files are identical and/or
blindly copy-pasted. Those boards that _do_ need a differing cmos.layout
should have their own custom file, but the "don't care" rest of the
boards can then use a global/common one.


> > The bug which prevented a successful build was a typo in the
> > Makefile. Attached patch should fix it.
> I don't care about any improvements over that at this time, but the
> change in Makefile.romccboard.inc looks fine.
> In case this is build tested by you (esp. that asus/mew-vm really
> builds), this is
> 
> Acked-by: Patrick Georgi <patrick.georgi at coresystems.de>

Thanks, r4669. I manually tested the board via menuconfig.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



From mylesgw at gmail.com  Thu Sep 24 16:14:15 2009
From: mylesgw at gmail.com (Myles Watson)
Date: Thu, 24 Sep 2009 08:14:15 -0600
Subject: [coreboot] [PATCH] Kconfig HT
Message-ID: <2831fecf0909240714h24a2e687ica185f5f448247f@mail.gmail.com>

There's no reason for a board without HyperTransport to compile it in.  This
patch removes it (saving 1K after compression.)

I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but
couldn't figure out how.  I don't think plugin support for HT makes sense...

kbuildall tested.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/af8b7d74/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HT.diff
Type: text/x-patch
Size: 1923 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/af8b7d74/attachment.diff>

From mylesgw at gmail.com  Thu Sep 24 16:18:50 2009
From: mylesgw at gmail.com (mylesgw)
Date: Thu, 24 Sep 2009 08:18:50 -0600
Subject: [coreboot] [PATCH] Kconfig HT
Message-ID: <2831fecf0909240718t5bb56e05kd569c0f2efab4636@mail.gmail.com>

There's no reason for a board without HyperTransport to compile it in.  This
patch removes it (saving 1K after compression.)

I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but
couldn't figure out how.  I don't think plugin support for HT makes sense...

kbuildall tested.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/834132bf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HT.diff
Type: text/x-patch
Size: 1923 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/834132bf/attachment.diff>

From mylesgw at gmail.com  Thu Sep 24 16:16:46 2009
From: mylesgw at gmail.com (mylesgw)
Date: Thu, 24 Sep 2009 08:16:46 -0600
Subject: [coreboot] [PATCH] Kconfig HT
Message-ID: <2831fecf0909240716h75c076dfg1687f92d2560e1e7@mail.gmail.com>

There's no reason for a board without HyperTransport to compile it in.  This
patch removes it (saving 1K after compression.)

I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but
couldn't figure out how.  I don't think plugin support for HT makes sense...

kbuildall tested.

Signed-off-by: Myles Watson <mylesgw at gmail.com>

Thanks,
Myles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/2e372228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HT.diff
Type: text/x-patch
Size: 1923 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090924/2e372228/attachment.diff>

From mylesgw at gmail.com  Thu Sep 24 16:19:02 2009
From: mylesgw at gmail.com (mylesgw)
Date: Thu, 24 Sep 2009 08:19:02 -0600
Subject: [coreboot] [PATCH] Kconfig HT
Message-ID: <2831fecf0909240719u63b8891ep2ba04b1316a96de4@mail.gmail.com>

There's no reason for a board without HyperTransport to compile it in.  This
patch removes it (saving 1K after compression.)

I would have liked to set HYPERTRANSPORT_PLUGIN_SUPPORT the same way, but
couldn't figure out how.  I don't think plugin