coreboot October 2008

coreboot@coreboot.org

84 participants
608 discussions

[PATCH] workaround v2 VIA ROMCC breakage
by Carl-Daniel Hailfinger 17 Oct '08

17 Oct '08

Workaround v2 VIA ROMCC breakage. Someone please tell me why the network adapter has to be handled by romcc compiled code. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r.h =================================================================== --- LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r.h (Revision 3660) +++ LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r.h (Arbeitskopie) @@ -29,7 +29,11 @@ #define VT8237R_SMBUS_IO_BASE 0x400 /* 0x0 disabled, 0x2 reserved, 0xf = IRQ15 */ #define VT8237R_ACPI_IRQ 0x9 +#if defined(__GNUC__) #define VT8237S_SPI_MEM_BASE 0xfed02000ULL +#else +#define VT8237S_SPI_MEM_BASE 0xfed02000UL +#endif #define VT8237R_HPET_ADDR 0xfed00000ULL #define VT8237R_APIC_BASE 0xfec00000ULL Index: LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c =================================================================== --- LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c (Revision 3660) +++ LinuxBIOSv2-tmp2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c (Arbeitskopie) @@ -354,9 +354,11 @@ pci_write_config32(dev, 0xbc, (VT8237S_SPI_MEM_BASE >> 8) | (tmp & 0xFF000000)); +#if 0 /* Set SPI clock to 33MHz. */ spireg = (u16 *) (VT8237S_SPI_MEM_BASE + 0x6c); (*spireg) &= 0xff00; +#endif } /* @@ -413,6 +415,7 @@ if (status == 3) return 0; +#if 0 if (rom == NULL) { print_err("No config data specified, using default MAC!\n"); n.mac_address[0] = 0x0; @@ -443,6 +446,7 @@ n.checksum = 0x0; rom = &n; } +#endif rom_write = (u16 *) rom; checksum = 0; -- http://www.hailfinger.org/

6 19

r3665 - trunk/coreboot-v2/src/southbridge/via/vt8237r
by svn＠coreboot.org 17 Oct '08

17 Oct '08

Author: cozzie Date: 2008-10-17 04:34:06 +0200 (Fri, 17 Oct 2008) New Revision: 3665 Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c Log: Final fix for C7 boards, which are still using ROMCC, to be able to build. As far as I know, no C7 boards currently in the tree use SPI flash. Signed-off-by: Corey Osgood <corey.osgood(a)gmail.com> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c =================================================================== --- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2008-10-17 00:06:50 UTC (rev 3664) +++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2008-10-17 02:34:06 UTC (rev 3665) @@ -336,6 +336,7 @@ pci_write_config8(dev, 0x41, 0x7f); } +#if defined(__GNUC__) void vt8237_early_spi_init(void) { device_t dev; @@ -358,6 +359,7 @@ spireg = (u16 *) (VT8237S_SPI_MEM_BASE + 0x6c); (*spireg) &= 0xff00; } +#endif /* This #if is special. ROMCC chokes on the (rom == NULL) comparison. * Since the whole function is only called for one target and that target

1 0

[PATCH] v3: Fix option table related makefile rules
by Carl-Daniel Hailfinger 17 Oct '08

17 Oct '08

Thanks to Ron for spotting this bug. The option table C file is a generated file and lives inside the build directory. Look for it there. Introduce the STAGE0_DYNAMIC_SRC makefile variable to handle this and other generated stage1 code. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: corebootv3-optiontable_makefile_stag0_dynamic/mainboard/amd/serengeti/Makefile =================================================================== --- corebootv3-optiontable_makefile_stag0_dynamic/mainboard/amd/serengeti/Makefile (Revision 934) +++ corebootv3-optiontable_makefile_stag0_dynamic/mainboard/amd/serengeti/Makefile (Arbeitskopie) @@ -22,7 +22,6 @@ STAGE0_MAINBOARD_SRC := $(src)/lib/clog2.c \ $(src)/mainboard/$(MAINBOARDDIR)/stage1.c \ - $(src)/mainboard/$(MAINBOARDDIR)/option_table.c \ $(src)/arch/x86/stage1_mtrr.c \ $(src)/arch/x86/amd/model_fxx/dualcore_id.c \ $(src)/arch/x86/amd/model_fxx/stage1.c \ @@ -33,6 +32,8 @@ $(src)/southbridge/amd/amd8111/stage1_ctrl.c \ $(src)/southbridge/amd/amd8111/stage1_enable_rom.c \ +STAGE0_DYNAMIC_SRC := $(obj)/mainboard/$(MAINBOARDDIR)/option_table.c + INITRAM_SRC= $(src)/mainboard/$(MAINBOARDDIR)/initram.c \ $(src)/northbridge/amd/k8/raminit.c \ $(src)/northbridge/amd/k8/dqs.c \ Index: corebootv3-optiontable_makefile_stag0_dynamic/mainboard/gigabyte/m57sli/Makefile =================================================================== --- corebootv3-optiontable_makefile_stag0_dynamic/mainboard/gigabyte/m57sli/Makefile (Revision 934) +++ corebootv3-optiontable_makefile_stag0_dynamic/mainboard/gigabyte/m57sli/Makefile (Arbeitskopie) @@ -21,7 +21,6 @@ STAGE0_MAINBOARD_SRC := $(src)/lib/clog2.c \ $(src)/mainboard/$(MAINBOARDDIR)/stage1.c \ - $(src)/mainboard/$(MAINBOARDDIR)/option_table.c \ $(src)/arch/x86/stage1_mtrr.c \ $(src)/arch/x86/amd/model_fxx/dualcore_id.c \ $(src)/arch/x86/amd/model_fxx/stage1.c \ @@ -31,6 +30,8 @@ $(src)/southbridge/nvidia/mcp55/stage1_smbus.c \ $(src)/southbridge/nvidia/mcp55/stage1_enable_rom.c \ +STAGE0_DYNAMIC_SRC := $(obj)/mainboard/$(MAINBOARDDIR)/option_table.c + INITRAM_SRC= $(src)/mainboard/$(MAINBOARDDIR)/initram.c \ $(src)/northbridge/amd/k8/raminit.c \ $(src)/northbridge/amd/k8/dqs.c \ Index: corebootv3-optiontable_makefile_stag0_dynamic/arch/x86/Makefile =================================================================== --- corebootv3-optiontable_makefile_stag0_dynamic/arch/x86/Makefile (Revision 934) +++ corebootv3-optiontable_makefile_stag0_dynamic/arch/x86/Makefile (Arbeitskopie) @@ -147,6 +147,7 @@ $(STAGE0_MAINBOARD_SRC) $(STAGE0_CHIPSET_SRC) STAGE0_OBJ := $(patsubst $(src)/%.c,$(obj)/%.o,$(STAGE0_SRC)) \ + $(patsubst $(obj)/%.c,$(obj)/%.o,$(STAGE0_DYNAMIC_SRC)) \ $(patsubst %,$(obj)/arch/x86/%,$(STAGE0_CAR_OBJ)) $(obj)/stage0.o $(obj)/stage0.init $(obj)/stage0-prefixed.o: $(STAGE0_OBJ) -- http://www.hailfinger.org/

3 4

r3664 - trunk/coreboot-v2/src/southbridge/via/vt8237r
by svn＠coreboot.org 17 Oct '08

17 Oct '08

Author: hailfinger Date: 2008-10-17 02:06:50 +0200 (Fri, 17 Oct 2008) New Revision: 3664 Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.h trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c Log: ROMCC chokes on vt8237_early_network_init(). Since that function is only called from one target and that target is compiled with GCC, make the function dependent on GCC. ROMCC also chokes on the ULL suffix for integer constants. Change the affected ones to UL for ROMCC compiled code. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.h =================================================================== --- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.h 2008-10-16 23:44:21 UTC (rev 3663) +++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r.h 2008-10-17 00:06:50 UTC (rev 3664) @@ -29,7 +29,11 @@ #define VT8237R_SMBUS_IO_BASE 0x400 /* 0x0 disabled, 0x2 reserved, 0xf = IRQ15 */ #define VT8237R_ACPI_IRQ 0x9 +#if defined(__GNUC__) #define VT8237S_SPI_MEM_BASE 0xfed02000ULL +#else +#define VT8237S_SPI_MEM_BASE 0xfed02000UL +#endif #define VT8237R_HPET_ADDR 0xfed00000ULL #define VT8237R_APIC_BASE 0xfec00000ULL Modified: trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c =================================================================== --- trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2008-10-16 23:44:21 UTC (rev 3663) +++ trunk/coreboot-v2/src/southbridge/via/vt8237r/vt8237r_early_smbus.c 2008-10-17 00:06:50 UTC (rev 3664) @@ -359,6 +359,11 @@ (*spireg) &= 0xff00; } +/* This #if is special. ROMCC chokes on the (rom == NULL) comparison. + * Since the whole function is only called for one target and that target + * is compiled with GCC, hide the function from ROMCC and be happy. + */ +#if defined(__GNUC__) /* * Offset 0x58: * 31:20 reserved @@ -481,3 +486,4 @@ /* We are done, config will be used after PCIRST#. */ return 1; } +#endif

1 0

Recent v2 abuild breakage
by Carl-Daniel Hailfinger 17 Oct '08

17 Oct '08

Hi! The recent v2 abuild breakage we're seeing since the move to a new massively multiprocessor server may have been caused way back by r3564. AFAICS it seems the dependency rules on romcc cause it to be compiled twice if certain race conditions happen. The v2 build system is sort of a mystery to me, so the following may or may not work. I think I can fix this by compiling romcc into a temp file and moving the temp file in the right place afterwards. That makes sure no two compiler processes try to output to the same file at the same time and it also makes sure that the romcc binary will always be runnable. Any hints or better fixes are appreciated. Regards, Carl-Daniel -- http://www.hailfinger.org/

3 4

r3663 - trunk/coreboot-v2/src/config
by svn＠coreboot.org 17 Oct '08

17 Oct '08

Author: hailfinger Date: 2008-10-17 01:44:21 +0200 (Fri, 17 Oct 2008) New Revision: 3663 Modified: trunk/coreboot-v2/src/config/Config.lb Log: Revision 3564 improved compilation time, but it also introduced a dependency bug which hit people running parallel make instances. With our current makefile architecture, the "right" fix is impossible. However, we can still kill the race conditions leading to arbitrary compilation failures. That trick depends on the atomicity of the mv command. Extensive comments explain what the workaround does. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/config/Config.lb =================================================================== --- trunk/coreboot-v2/src/config/Config.lb 2008-10-16 19:20:51 UTC (rev 3662) +++ trunk/coreboot-v2/src/config/Config.lb 2008-10-16 23:44:21 UTC (rev 3663) @@ -162,9 +162,16 @@ action "doxygen corebootDoc.config" end +# Yes, the rule doesn't seem to make sense, but multiple images could try to +# create a romcc binary at the same time, clobbering each other. +# Our makefile architecture won't allow us to easily have the romcc target +# in the main makefile, so keep it here and move the race condition winner +# in place. That way, romcc may get compiled twice, but the binary will always +# be in a correct and valid state if it exists because the move is atomic. makerule ../romcc depends "$(TOP)/util/romcc/romcc.c" - action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o $@" + action "$(HOSTCC) -g $(HOSTCFLAGS) $< -o romcc.tmpfile" + action "mv romcc.tmpfile $@" end makerule build_opt_tbl

1 0

r3662 build service
by coreboot information 16 Oct '08

16 Oct '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "oxygene" checked in revision 3662 to the coreboot source repository and caused the following changes: Change Log: - reduced memory requirements a lot (from >100kb/controller to 560bytes/controller) - no need for the client of libpayload to implement usbdisk_{create,remove}, just because USB was compiled in. - usb hub support compiles, and works for some trivial cases (no device detach, trivial power management) - usb keyboard support works in qemu, though there are reports that it doesn't work on real hardware yet. - usb keyboard is integrated in both libc-getchar() and curses, if CONFIG_USB_HID is enabled Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Jordan Crouse <jordan.crouse(a)amd.com> Build Log: Compilation of a-trend:atc-6240 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=atc-6240&vendo… Compilation of amd:rumba has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=rumba&vendor=a… Compilation of asi:mb_5blmp has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=mb_5blmp&vendo… Compilation of asus:mew-am has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=mew-am&vendor=… Compilation of bcom:winnetp680 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=winnetp680&ven… Compilation of intel:jarrell has been fixed Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=j7f24&vendor=j… Compilation of olpc:btest has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=btest&vendor=o… Compilation of tyan:s1846 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=s1846&vendor=t… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=epia-cn&vendor… Compilation of via:pc2500e is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3662&device=pc2500e&vendor… 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

1 0

r3661 build service
by coreboot information 16 Oct '08

16 Oct '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "hawke" checked in revision 3661 to the coreboot source repository and caused the following changes: Change Log: * Add a new board, the BCom WinNET P680 * Add a function to change the 24/48Mhz clock input selector on the Winbond W83697 superio to 48Mhz, used by the WinNET P680 Signed-off-by: Alex Mauer <hawke(a)hawkesnest.net> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of bcom:winnetp680 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3661&device=winnetp680&ven… Compilation of intel:jarrell has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3661&device=jarrell&vendor… Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3661&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3661&device=epia-cn&vendor… Compilation of via:pc2500e is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3661&device=pc2500e&vendor… If something broke during this checkin please be a pain in hawke'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

1 0

Re: [coreboot] SimNOW VGA int 1a
by Myles Watson 16 Oct '08

16 Oct '08

> -----Original Message----- > From: ron minnich [mailto:rminnich@gmail.com] > Sent: Thursday, October 16, 2008 1:34 PM > To: Marc Jones > Cc: Myles Watson; Jordan Crouse > Subject: Re: [coreboot] SimNOW VGA int 1a > > On Thu, Oct 16, 2008 at 12:32 PM, Marc Jones <marc.jones(a)amd.com> wrote: > > > That gets us back to relocating or mutilple copies in the stages. I am > ok > > with multiple copies in the ROM but it should be on version in the > source. > > The problem with v2 is that there was ROMCC versions and main coreboot > > versions. > > The beauty of carl-daniel's redesign of the "call ROM" stuff is that > we can have the same printk code in stage2 as in ROM and there is no > symbol conflict. But we now have to pretty much put all stage0 stuff > in stage2 as well. no choice. > > Myles, caching won't help. I'm showing my ignorance here. Conceptually couldn't you have a small area set up like CAR for the shared portions? As long as it was all loaded before probing wouldn't it always be accessed before the ROM? Thanks, Myles

3 3

r3660 build service
by coreboot information 16 Oct '08

16 Oct '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "hailfinger" checked in revision 3660 to the coreboot source repository and caused the following changes: Change Log: Revision 3567 introduced __attribute__((packed)) for a structured which is also visible to ROMCC and ROMCC doesn't understand that. The fix is to use __attribute__((packed)) only for gcc compiled code. This has been unfixed for too long. There are more problems remaining, but at least this one is solvable easily. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Build Log: Compilation of compaq:deskpro_en_sff_p600 has been fixed Compilation of jetway:j7f24 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3660&device=j7f24&vendor=j… Compilation of via:epia-cn is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3660&device=epia-cn&vendor… Compilation of via:pc2500e is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3660&device=pc2500e&vendor… 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

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
61
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2008