coreboot October 2009

coreboot@coreboot.org

63 participants
534 discussions

[FILO] r107 - trunk/filo/main
by svn＠coreboot.org 05 Oct '09

05 Oct '09

Author: stuge Date: 2009-10-06 05:10:00 +0200 (Tue, 06 Oct 2009) New Revision: 107 Modified: trunk/filo/main/filo.c Log: Fix build with CONFIG_AUTOBOOT_DELAY=0 ESC is always checked, so print the prompt even if there's no delay. Modified: trunk/filo/main/filo.c =================================================================== --- trunk/filo/main/filo.c 2009-09-23 14:12:31 UTC (rev 106) +++ trunk/filo/main/filo.c 2009-10-06 03:10:00 UTC (rev 107) @@ -156,7 +156,7 @@ #else // ! CONFIG_USE_GRUB #ifdef CONFIG_AUTOBOOT_FILE -#if CONFIG_AUTOBOOT_DELAY +#ifdef CONFIG_AUTOBOOT_DELAY static inline int autoboot_delay(void) { u64 timeout;

1 0

crossgcc build problem
by Joseph Smith 05 Oct '09

05 Oct '09

Hello, I keep getting stuck running the crossgcc shell script. It keeps getting stuck on GDB, complaining about no make rule for "install" and then exits. Attached is the log, any ideas? -- Thanks, Joseph Smith Set-Top-Linux www.settoplinux.org

1 1

about coreboot v3
by feng shu 05 Oct '09

05 Oct '09

Hello every: I find some words in coreboot wiki: >coreboot v3 was an experimental development tree of coreboot which should not be used anymore (there are only very few >exceptions)! Most features from v3 are gradually being merged back into v2. is it mean than the v3 will dispear after its features merge back into v2 and the default is v2 in long time? tumashu

2 1

Re: [coreboot] [Qemu-devel] Release plan for 0.12.0
by Carl-Daniel Hailfinger 05 Oct '09

05 Oct '09

[Adding the coreboot list to CC. Please ignore the moderation messages, your addresses will be whitelisted ASAP.] On 02.10.2009 20:53, Anthony Liguori wrote: > Carl-Daniel Hailfinger wrote: >> Given that you can easily pack coreboot+SeaBIOS+UEFI into one ROM and >> have coreboot boot either SeaBIOS (BIOS interface) or UEFI (EFI >> interface), wouldn't that solve all problems in one go? You get an >> unified stack and don't have to mess around with different firmware >> files because coreboot can read in a Qemu machine config option (or >> NVRAM/CMOS) and select the interface based on that. >> > > If you want to to work seamlessly, you need to check for the EFI > system partition to see whether it's an EFI capable OS and then > fallback gracefully to SeaBIOS boot. Hm. Wouldn't that be a layering violation (hw init != reading the disk) and also cause problems if you want to boot an EFI capable OS from SeaBIOS? I can think of someone having an EFI bootable disk image who wants to boot that disk image with EFI and BIOS without having to repartition. >> The hardware init part would be identical for all variants, only the >> interface would differ. coreboot works now and has the benefit of >> supporting real hardware as well, so the difference between a setup >> inside Qemu and a setup on real hardware is minimal. > > Tianocore's OVMF project should provide all the required > initialization for EFI on QEMU. Yes, but then we'd have two sets of hardware init: OVMF for EFI, SeaBIOS for SeaBIOS. That also means each hw init codebase has to support the new Q35 chipset proposed for Qemu. It's not any better if SeaBIOS gets changed into a CSM for EFI. Then you have SeaBIOS on top of EFI on top of OVMF. As I understand it, OVMF had less testing than the Bochs BIOS or SeaBIOS on Qemu. Jordan, I have to admit that I'm surprised OVMF was apparently created from scratch although quite a few (established) hardware init solutions already exist for Qemu: SeaBIOS, Bochs BIOS, coreboot, and some old hobbyist projects. I'd like to understand the reasons for that and fix them in coreboot (Kevin O'Connor will probably fix them in SeaBIOS). If you ported/modified existing code, I'd be interested in the original codebase to learn from it (especially what you had to change). >> The coreboot solution would also avoid converting SeaBIOS because >> SeaBIOS already works as coreboot payload (that's how coreboot >> developers call the CSM). >> > > I'll bite, what's the advantage of doing coreboot + SeaBIOS vs. > SeaBIOS alone? Forget about EFI for the moment, should be considering > switching to coreboot + SeaBIOS for 0.12? Advantages: - Code coverage increase: SeaBIOS is used with coreboot on real hardware, so the BIOS interface part of SeaBIOS gets a lot more testing than the Qemu hardware init part of SeaBIOS. - coreboot supports real 440BX hardware besides Qemu, so the coreboot init code is exercised more (and there is still a sizable number of such machines around (clusters), many of them running coreboot). - Only one ROM image needed. A coreboot ROM can pack the VGA BIOS into the ROM image and SeaBIOS will automatically load it from there. Same for network card ROMs (with gPXE etc.). - coreboot ROMs (including those with SeaBIOS and/or EFI and/or VGABIOS) are archives and can be listed/edited with cbfstool if you want to know what's in there. - coreboot ROMs use compression, so you can stuff more code (and PCI option ROMs) into smaller ROMs. - coreboot has pretty verbose hardware init messages (if you want that) and can be totally silent as well. The messages end up in a log buffer which can be read by the OS (experimental feature, not available by default). There are a lot more advantages, but I want to give other coreboot developers a chance to chime in. If you add EFI to the mix, the synergies increase. Regards, Carl-Daniel

11 32

[v2] r4726 - in trunk/coreboot-v2: . src
by svn＠coreboot.org 05 Oct '09

05 Oct '09

Author: uwe Date: 2009-10-05 15:55:28 +0200 (Mon, 05 Oct 2009) New Revision: 4726 Modified: trunk/coreboot-v2/Makefile trunk/coreboot-v2/src/Kconfig Log: Backport facility to specify a local coreboot version suffix from v3. Tested on QEMU. Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/coreboot-v2/Makefile =================================================================== --- trunk/coreboot-v2/Makefile 2009-10-05 12:58:48 UTC (rev 4725) +++ trunk/coreboot-v2/Makefile 2009-10-05 13:55:28 UTC (rev 4726) @@ -93,6 +93,10 @@ BUILD-y += util/cbfstool BUILD-$(CONFIG_ARCH_X86) += src/pc80 +ifneq ($(CONFIG_LOCALVERSION),"") +COREBOOT_EXTRA_VERSION := -$(shell echo $(CONFIG_LOCALVERSION)) +endif + # The primary target needs to be here before we include the # other files @@ -241,7 +245,7 @@ CFLAGS = $(STACKPROTECT) $(INCLUDES) -Os -nostdinc CFLAGS += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -CFLAGS +=-Wwrite-strings -Wredundant-decls -Wno-trigraphs +CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs CFLAGS += -Wstrict-aliasing -Wshadow CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer Modified: trunk/coreboot-v2/src/Kconfig =================================================================== --- trunk/coreboot-v2/src/Kconfig 2009-10-05 12:58:48 UTC (rev 4725) +++ trunk/coreboot-v2/src/Kconfig 2009-10-05 13:55:28 UTC (rev 4726) @@ -27,6 +27,15 @@ mainmenu "Coreboot Configuration" +menu "General setup" + +config LOCALVERSION + string "Local version - append to coreboot release" + help + Append an extra string to the end of the coreboot version. + +endmenu + source src/mainboard/Kconfig source src/arch/i386/Kconfig source src/arch/ppc/Kconfig

1 0

unsubscribe
by Fernando Hernández 05 Oct '09

05 Oct '09

1 0

[v2] r4725 - trunk/coreboot-v2/util
by svn＠coreboot.org 05 Oct '09

05 Oct '09

Author: oxygene Date: 2009-10-05 14:58:48 +0200 (Mon, 05 Oct 2009) New Revision: 4725 Modified: trunk/coreboot-v2/util/ Log: Remove svn:externals that pull in all kinds of useful tools that are not needed for building coreboot. The website tells you where to get them individually. Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Peter Stuge <peter(a)stuge.se> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Property changes on: trunk/coreboot-v2/util ___________________________________________________________________ Deleted: svn:externals - nvramtool svn://coreboot.org/repos/trunk/util/nvramtool superiotool svn://coreboot.org/repos/trunk/util/superiotool getpir svn://coreboot.org/repos/trunk/util/getpir mptable svn://coreboot.org/repos/trunk/util/mptable inteltool svn://coreboot.org/repos/trunk/util/inteltool msrtool svn://coreboot.org/repos/trunk/util/msrtool ectool svn://coreboot.org/repos/trunk/util/ectool

1 0

[PATCH] fix for Winbond W83627DHG superio
by Stefan Reinauer 05 Oct '09

05 Oct '09

-- coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br. Tel.: +49 761 7668825 • Fax: +49 761 7664613 Email: info(a)coresystems.de • http://www.coresystems.de/ Registergericht: Amtsgericht Freiburg • HRB 7656 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866 Without these fixes the w83627dhg driver (which is currently not used by any mainboard in the tree) does neither compile nor work. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Index: src/superio/winbond/w83627dhg/superio.c =================================================================== --- src/superio/winbond/w83627dhg/superio.c (.../branches/upstream/coreboot-v2) +++ src/superio/winbond/w83627dhg/superio.c (.../trunk/coreboot-v2) @@ -103,7 +103,8 @@ { &ops, W83627DHG_SP1, PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, }, { &ops, W83627DHG_SP2, PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, }, { &ops, W83627DHG_KBC, PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0xfff, 0 }, { 0xfff, 0x4}, }, - { &ops, W83627DHG_SPI, PNP_IO1, { 0xff8, 0 }, }, + // the next line makes coreboot hang in pnp_enable_devices() + // { &ops, W83627DHG_SPI, PNP_IO1, { 0xff8, 0 }, }, { &ops, W83627DHG_GPIO6, }, { &ops, W83627DHG_WDTO_PLED, }, { &ops, W83627DHG_GPIO2345, }, Index: src/superio/winbond/w83627dhg/w83627dhg.h =================================================================== --- src/superio/winbond/w83627dhg/w83627dhg.h (.../branches/upstream/coreboot-v2) +++ src/superio/winbond/w83627dhg/w83627dhg.h (.../trunk/coreboot-v2) @@ -26,7 +26,7 @@ #define W83627DHG_SPI 6 /* Serial peripheral interface */ #define W83627DHG_GPIO6 7 /* GPIO6 */ #define W83627DHG_WDTO_PLED 8 /* WDTO#, PLED */ -#define W83627DHG_GPIO_SUSLED 9 /* GPIO2, GPIO3, GPIO4, GPIO5 */ +#define W83627DHG_GPIO2345 9 /* GPIO2, GPIO3, GPIO4, GPIO5 */ #define W83627DHG_ACPI 10 /* ACPI */ #define W83627DHG_HWM 11 /* Hardware monitor */ #define W83627DHG_PECI_SST 12 /* PECI, SST */

2 2

[v2] r4724 - trunk/coreboot-v2/src/superio/winbond/w83627dhg
by svn＠coreboot.org 05 Oct '09

05 Oct '09

Author: stepan Date: 2009-10-05 14:08:37 +0200 (Mon, 05 Oct 2009) New Revision: 4724 Modified: trunk/coreboot-v2/src/superio/winbond/w83627dhg/superio.c trunk/coreboot-v2/src/superio/winbond/w83627dhg/w83627dhg.h Log: Without these fixes the w83627dhg driver (which is currently not used by any mainboard in the tree) does neither compile nor work. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Modified: trunk/coreboot-v2/src/superio/winbond/w83627dhg/superio.c =================================================================== --- trunk/coreboot-v2/src/superio/winbond/w83627dhg/superio.c 2009-10-05 10:23:36 UTC (rev 4723) +++ trunk/coreboot-v2/src/superio/winbond/w83627dhg/superio.c 2009-10-05 12:08:37 UTC (rev 4724) @@ -103,7 +103,8 @@ { &ops, W83627DHG_SP1, PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, }, { &ops, W83627DHG_SP2, PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, }, { &ops, W83627DHG_KBC, PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0xfff, 0 }, { 0xfff, 0x4}, }, - { &ops, W83627DHG_SPI, PNP_IO1, { 0xff8, 0 }, }, + // the next line makes coreboot hang in pnp_enable_devices() + // { &ops, W83627DHG_SPI, PNP_IO1, { 0xff8, 0 }, }, { &ops, W83627DHG_GPIO6, }, { &ops, W83627DHG_WDTO_PLED, }, { &ops, W83627DHG_GPIO2345, }, Modified: trunk/coreboot-v2/src/superio/winbond/w83627dhg/w83627dhg.h =================================================================== --- trunk/coreboot-v2/src/superio/winbond/w83627dhg/w83627dhg.h 2009-10-05 10:23:36 UTC (rev 4723) +++ trunk/coreboot-v2/src/superio/winbond/w83627dhg/w83627dhg.h 2009-10-05 12:08:37 UTC (rev 4724) @@ -26,7 +26,7 @@ #define W83627DHG_SPI 6 /* Serial peripheral interface */ #define W83627DHG_GPIO6 7 /* GPIO6 */ #define W83627DHG_WDTO_PLED 8 /* WDTO#, PLED */ -#define W83627DHG_GPIO_SUSLED 9 /* GPIO2, GPIO3, GPIO4, GPIO5 */ +#define W83627DHG_GPIO2345 9 /* GPIO2, GPIO3, GPIO4, GPIO5 */ #define W83627DHG_ACPI 10 /* ACPI */ #define W83627DHG_HWM 11 /* Hardware monitor */ #define W83627DHG_PECI_SST 12 /* PECI, SST */

1 0

XMM stack
by Rudolf Marek 05 Oct '09

05 Oct '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I made some fix for xmmstack.c found in SerialICE. leal (%esp), %ecx Its simple: - --- old.c 2009-05-14 15:43:45.000000000 +0200 +++ xmmstack.c 2009-10-02 00:19:52.755673296 +0200 @@ -547,9 +547,23 @@ getxmml:\n\ continue; } #endif + + fprintf(w,"#%s #ORIG\n", buf); + + /* leal is tricky */ + if (regexp("^leal\\s+(\\d*)\$\\%esp\$\\s*,\\s*(.*)$",buf,len,find)) + { + fprintf(w,"movl %%dr2,%%esp #NOSTACK\n"); + fprintf(w,"%s\n",buf); + fprintf(w,"movl %%esp,%%dr2 #NOSTACK\n"); + continue; + } + It makes things compile. Maybe there are other issues don't know. Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkrFLtYACgkQ3J9wPJqZRNUJoQCYpHICI6k4ZwECnwRrN/FDtEjm 1QCfUMWXts0lv7iH2W6n8dC7C9iNBKg= =xgZx -----END PGP SIGNATURE-----

4 6

← Newer
1
...
43
44
45
46
47
48
49
...
54
Older →

Jump to page:

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 2009