coreboot April 2009

coreboot@coreboot.org

69 participants
583 discussions

[PATCH]Don't require executable bit for payload.sh
by Patrick Georgi 22 Apr '09

22 Apr '09

Hi, the attached patch removes the requirement for payload.sh files to be executable. That help if the file is generated from patches, esp. if that happens often (eg. with quilt) Signed-off-by: Patrick Georgi <patrick.georgi(a)coresystems.de>

2 1

[ANNOUNCE] EC dumping tool
by Stefan Reinauer 22 Apr '09

22 Apr '09

I wrote a small utility to dump the RAM of a laptop's Embedded/Environmental Controller. Nothing fancy, does not know any laptops, EC types, or what the values mean. It just dumps them. Attached as a tar, it should go to util/ Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> -- 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

2 2

[v2] r4163 - in trunk/util: . ectool
by svn＠coreboot.org 22 Apr '09

22 Apr '09

Author: stepan Date: 2009-04-22 09:23:00 +0200 (Wed, 22 Apr 2009) New Revision: 4163 Added: trunk/util/ectool/ trunk/util/ectool/Makefile trunk/util/ectool/ec.c trunk/util/ectool/ec.h trunk/util/ectool/ectool.c Log: A small utility to dump the RAM of a laptop's Embedded/Environmental Controller. Nothing fancy, does not know any laptops, EC types, or what the values mean. It just dumps them. For the dump method, have a look at the ACPI 3.0b spec. Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Added: trunk/util/ectool/Makefile =================================================================== --- trunk/util/ectool/Makefile (rev 0) +++ trunk/util/ectool/Makefile 2009-04-22 07:23:00 UTC (rev 4163) @@ -0,0 +1,34 @@ +# +# Makefile for ectool +# +# Copyright (C) 2009 by coresystems GmbH +# written by Stefan Reinauer <stepan(a)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; 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., 675 Mass Ave, Cambridge, MA 02139, USA. +# + +CC=gcc +CFLAGS=-O2 -Wall -W + +all: ectool + +ectool: ec.o ectool.o + $(CC) $(CFLAGS) -o $@ $^ + +clean: + rm *.o ectool + +%.o: %.c + $(CC) $(CFLAGS) -c $^ -I. -o $@ Added: trunk/util/ectool/ec.c =================================================================== --- trunk/util/ectool/ec.c (rev 0) +++ trunk/util/ectool/ec.c 2009-04-22 07:23:00 UTC (rev 4163) @@ -0,0 +1,119 @@ +/* + * This file is part of the ectool project. + * + * 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 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 <unistd.h> +#include <sys/io.h> +#include "ec.h" + +extern int verbose; + +#define debug(x...) if (verbose) printf(x) + +int send_ec_command(uint8_t command) +{ + int timeout; + + timeout = 0x7ff; + while ((inb(EC_SC) & EC_IBF) && --timeout) { + usleep(10); + if ((timeout & 0xff) == 0) + debug("."); + } + if (!timeout) { + printf("Timeout while sending command 0x%02x to EC!\n", + command); + // return -1; + } + + outb(command, EC_SC); + return 0; +} + +int send_ec_data(uint8_t data) +{ + int timeout; + + timeout = 0x7ff; + while ((inb(EC_SC) & EC_IBF) && --timeout) { // wait for IBF = 0 + usleep(10); + if ((timeout & 0xff) == 0) + debug("."); + } + if (!timeout) { + printf("Timeout while sending data 0x%02x to EC!\n", + data); + // return -1; + } + + outb(data, EC_DATA); + + return 0; +} + +int send_ec_data_nowait(uint8_t data) +{ + outb(data, EC_DATA); + + return 0; +} + +uint8_t recv_ec_data(void) +{ + int timeout; + uint8_t data; + + timeout = 0x7fff; + while (--timeout) { // Wait for OBF = 1 + if (inb(EC_SC) & EC_OBF) { + break; + } + usleep(10); + if ((timeout & 0xff) == 0) + debug("."); + } + if (!timeout) { + printf("\nTimeout while receiving data from EC!\n"); + // return -1; + } + + data = inb(EC_DATA); + debug("recv_ec_data: 0x%02x\n", data); + + return data; +} + +uint8_t ec_read(uint8_t addr) +{ + send_ec_command(0x80); + send_ec_data(addr); + + return recv_ec_data(); +} + +int ec_write(uint8_t addr, uint8_t data) +{ + send_ec_command(0x81); + send_ec_data(addr); + return send_ec_data(data); +} + Added: trunk/util/ectool/ec.h =================================================================== --- trunk/util/ectool/ec.h (rev 0) +++ trunk/util/ectool/ec.h 2009-04-22 07:23:00 UTC (rev 4163) @@ -0,0 +1,49 @@ +/* + * This file is part of the ectool project. + * + * 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 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 _EC_H +#define _EC_H +#include <stdint.h> +#define EC_DATA 0x62 +#define EC_SC 0x66 + +/* EC_SC input */ +#define EC_SMI_EVT (1 << 6) // 1: SMI event pending +#define EC_SCI_EVT (1 << 5) // 1: SCI event pending +#define EC_BURST (1 << 4) // controller is in burst mode +#define EC_CMD (1 << 3) // 1: byte in data register is command + // 0: byte in data register is data +#define EC_IBF (1 << 1) // 1: input buffer full (data ready for ec) +#define EC_OBF (1 << 0) // 1: output buffer full (data ready for host) +/* EC_SC output */ +#define RD_EC 0x80 // Read Embedded Controller +#define WR_EC 0x81 // Write Embedded Controller +#define BE_EC 0x82 // Burst Enable Embedded Controller +#define BD_EC 0x83 // Burst Disable Embedded Controller +#define QR_EC 0x84 // Query Embedded Controller + +int send_ec_command(uint8_t command); +int send_ec_data(uint8_t data); +int send_ec_data_nowait(uint8_t data); +uint8_t recv_ec_data(void); +uint8_t ec_read(uint8_t addr); +#endif + Added: trunk/util/ectool/ectool.c =================================================================== --- trunk/util/ectool/ectool.c (rev 0) +++ trunk/util/ectool/ectool.c 2009-04-22 07:23:00 UTC (rev 4163) @@ -0,0 +1,104 @@ +/* + * This file is part of the ectool project. + * + * 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 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 <stdlib.h> +#include <unistd.h> +#include <getopt.h> +#include <sys/io.h> +#include <ec.h> + +#define ECTOOL_VERSION "0.1" + +void print_version(void) +{ + printf("ectool v%s -- ", ECTOOL_VERSION); + printf("Copyright (C) 2008-2009 coresystems GmbH\n\n"); + printf( + "This program is free software: you can redistribute it and/or modify\n" + "it under the terms of the GNU General Public License as published by\n" + "the Free Software Foundation, version 2 of the License.\n\n" + "This program is distributed in the hope that it will be useful,\n" + "but WITHOUT ANY WARRANTY; without even the implied warranty of\n" + "MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\n" + "GNU General Public License for more details.\n\n" + "You should have received a copy of the GNU General Public License\n" + "along with this program. If not, see <http://www.gnu.org/licenses/>.\n\n"); +} + +void print_usage(const char *name) +{ + printf("usage: %s [-vh?V]\n", name); + printf("\n" + " -v | --version: print the version\n" + " -h | --help: print this help\n\n" + " -V | --verbose: print debug information\n" + "\n"); + exit(1); +} + +int verbose = 0; + +int main(int argc, char *argv[]) +{ + int i, opt, option_index = 0; + + static struct option long_options[] = { + {"version", 0, 0, 'v'}, + {"help", 0, 0, 'h'}, + {"verbose", 0, 0, 'V'}, + {0, 0, 0, 0} + }; + + while ((opt = getopt_long(argc, argv, "vh?V", + long_options, &option_index)) != EOF) { + switch (opt) { + case 'v': + print_version(); + exit(0); + break; + case 'V': + verbose = 1; + break; + case 'h': + case '?': + default: + print_usage(argv[0]); + exit(0); + break; + } + } + + if (iopl(3)) { + printf("You need to be root.\n"); + exit(1); + } + + printf("EC RAM:\n"); + for (i=0; i < 0x100; i++) { + if ((i % 0x10) == 0) + printf ("\n%02x: ", i); + printf("%02x ", ec_read(i)); + } + printf("\n\n"); + return 0; +}

1 0

[v2] r4162 - in trunk/coreboot-v2/src: include lib
by svn＠coreboot.org 21 Apr '09

21 Apr '09

Author: stepan Date: 2009-04-22 01:05:13 +0200 (Wed, 22 Apr 2009) New Revision: 4162 Modified: trunk/coreboot-v2/src/include/usbdebug_direct.h trunk/coreboot-v2/src/lib/usbdebug_direct.c Log: - function prototypes do not need "extern" - fix up debug messages of usb debug console (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/include/usbdebug_direct.h =================================================================== --- trunk/coreboot-v2/src/include/usbdebug_direct.h 2009-04-21 23:03:20 UTC (rev 4161) +++ trunk/coreboot-v2/src/include/usbdebug_direct.h 2009-04-21 23:05:13 UTC (rev 4162) @@ -9,9 +9,10 @@ unsigned endpoint_out; unsigned endpoint_in; }; -extern int dbgp_bulk_write_x(struct ehci_debug_info *dbg_info, const char *bytes, int size); -extern int dbgp_bulk_read_x(struct ehci_debug_info *dbg_info, void *data, int size); -extern void set_ehci_base(unsigned ehci_base); -extern void set_ehci_debug(unsigned ehci_deug); -extern unsigned get_ehci_debug(void); +int dbgp_bulk_write_x(struct ehci_debug_info *dbg_info, const char *bytes, int size); +int dbgp_bulk_read_x(struct ehci_debug_info *dbg_info, void *data, int size); +void set_ehci_base(unsigned ehci_base); +void set_ehci_debug(unsigned ehci_deug); +unsigned get_ehci_debug(void); +void set_debug_port(unsigned port); #endif Modified: trunk/coreboot-v2/src/lib/usbdebug_direct.c =================================================================== --- trunk/coreboot-v2/src/lib/usbdebug_direct.c 2009-04-21 23:03:20 UTC (rev 4161) +++ trunk/coreboot-v2/src/lib/usbdebug_direct.c 2009-04-21 23:05:13 UTC (rev 4162) @@ -368,13 +368,14 @@ debug_port = HCS_DEBUG_PORT(hcs_params); n_ports = HCS_N_PORTS(hcs_params); + dbgp_printk("ehci_bar: 0x%x\n", ehci_bar); dbgp_printk("debug_port: %d\n", debug_port); dbgp_printk("n_ports: %d\n", n_ports); -#if 0 +#if 1 for (i = 1; i <= n_ports; i++) { portsc = readl(&ehci_regs->port_status[i-1]); - dbgp_printk("portstatus%d: %08x\n", i, portsc); + dbgp_printk("PORTSC #%d: %08x\n", i, portsc); } #endif @@ -396,10 +397,10 @@ } while ((cmd & CMD_RESET) && (--loop > 0)); if(!loop) { - dbgp_printk("can not reset ehci\n"); + dbgp_printk("Could not reset EHCI controller.\n"); return; } - dbgp_printk("ehci reset done\n"); + dbgp_printk("EHCI controller reset successfully.\n"); /* Claim ownership, but do not enable yet */ ctrl = readl(&ehci_debug->control); @@ -423,10 +424,10 @@ } while ((status & STS_HALT) && (--loop>0)); if(!loop) { - dbgp_printk("ehci can be started\n"); + dbgp_printk("EHCI could not be started.\n"); return; } - dbgp_printk("ehci started\n"); + dbgp_printk("EHCI started.\n"); /* Wait for a device to show up in the debug port */ ret = ehci_wait_for_port(ehci_regs, debug_port); @@ -434,7 +435,7 @@ dbgp_printk("No device found in debug port %d\n", debug_port); goto next_debug_port; } - dbgp_printk("ehci wait for port done\n"); + dbgp_printk("EHCI done waiting for port.\n"); /* Enable the debug port */ ctrl = readl(&ehci_debug->control); @@ -442,11 +443,11 @@ writel(ctrl, &ehci_debug->control); ctrl = readl(&ehci_debug->control); if ((ctrl & DBGP_CLAIM) != DBGP_CLAIM) { - dbgp_printk("No device in debug port\n"); + dbgp_printk("No device in EHCI debug port.\n"); writel(ctrl & ~DBGP_CLAIM, &ehci_debug->control); goto err; } - dbgp_printk("debug ported enabled\n"); + dbgp_printk("EHCI debug port enabled.\n"); /* Completely transfer the debug device to the debug controller */ portsc = readl(&ehci_regs->port_status[debug_port - 1]); @@ -465,11 +466,11 @@ break; } if (devnum > 127) { - dbgp_printk("Could not find attached debug device\n"); + dbgp_printk("Could not find attached debug device.\n"); goto err; } if (ret < 0) { - dbgp_printk("Attached device is not a debug device\n"); + dbgp_printk("Attached device is not a debug device.\n"); goto err; } dbgp_endpoint_out = dbgp_desc.bDebugOutEndpoint; @@ -481,12 +482,12 @@ USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, USB_REQ_SET_ADDRESS, USB_DEBUG_DEVNUM, 0, (void *)0, 0); if (ret < 0) { - dbgp_printk("Could not move attached device to %d\n", + dbgp_printk("Could not move attached device to %d.\n", USB_DEBUG_DEVNUM); goto err; } devnum = USB_DEBUG_DEVNUM; - dbgp_printk("debug device renamed to 127\n"); + dbgp_printk("EHCI debug device renamed to 127.\n"); } /* Enable the debug interface */ @@ -494,10 +495,10 @@ USB_DIR_OUT | USB_TYPE_STANDARD | USB_RECIP_DEVICE, USB_REQ_SET_FEATURE, USB_DEVICE_DEBUG_MODE, 0, (void *)0, 0); if (ret < 0) { - dbgp_printk(" Could not enable the debug device\n"); + dbgp_printk("Could not enable EHCI debug device.\n"); goto err; } - dbgp_printk("debug interface enabled\n"); + dbgp_printk("EHCI debug interface enabled.\n"); /* Perform a small write to get the even/odd data state in sync */ @@ -506,7 +507,7 @@ dbgp_printk("dbgp_bulk_write failed: %d\n", ret); goto err; } - dbgp_printk("small write doned\n"); + dbgp_printk("Test write done\n"); info->ehci_caps = ehci_caps; info->ehci_regs = ehci_regs;

1 0

[PATCH] flashrom: Add support for Gigabyte GA-MA790FX-DQ6
by Carl-Daniel Hailfinger 21 Apr '09

21 Apr '09

flashrom: Add support for Gigabyte GA-MA790FX-DQ6. This board uses IT8718F LPC->SPI translation for the flash chip. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-gigabyte_ma790fx_dq6/board_enable.c =================================================================== --- flashrom-gigabyte_ma790fx_dq6/board_enable.c (Revision 4146) +++ flashrom-gigabyte_ma790fx_dq6/board_enable.c (Arbeitskopie) @@ -661,6 +661,8 @@ {0x10de, 0x0360, 0, 0, 0, 0, 0, 0, "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash}, {0x10de, 0x03e0, 0, 0, 0, 0, 0, 0, "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash}, {0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385, NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash}, + /* SB600 LPC, RD790 North. Neither are specific to the GA-MA790FX-DQ6. The coreboot ID is here to be able to trigger the board enable more easily. */ + {0x1002, 0x438d, 0x1458, 0x5001, 0x1002, 0x5956, 0x1002, 0x5956, "gigabyte", "ma790fx-dq6", "GIGABYTE GA-MA790FX-DQ6", it87xx_probe_spi_flash}, {0x1039, 0x0761, 0, 0, 0, 0, 0, 0, "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash}, {0x1022, 0x7468, 0, 0, 0, 0, 0, 0, "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e}, {0x10de, 0x005e, 0, 0, 0, 0, 0, 0, "msi", "k8n-neo3", "MSI K8N Neo3", w83627thf_gpio4_4_raise_4e}, -- http://www.hailfinger.org/ Index: flashrom-gigabyte_ma790fx_dq6/board_enable.c =================================================================== --- flashrom-gigabyte_ma790fx_dq6/board_enable.c (Revision 4146) +++ flashrom-gigabyte_ma790fx_dq6/board_enable.c (Arbeitskopie) @@ -661,6 +661,8 @@ {0x10de, 0x0360, 0, 0, 0, 0, 0, 0, "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash}, {0x10de, 0x03e0, 0, 0, 0, 0, 0, 0, "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash}, {0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385, NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash}, + /* SB600 LPC, RD790 North. Neither are specific to the GA-MA790FX-DQ6. The coreboot ID is here to be able to trigger the board enable more easily. */ + {0x1002, 0x438d, 0x1458, 0x5001, 0x1002, 0x5956, 0x1002, 0x5956, "gigabyte", "ma790fx-dq6", "GIGABYTE GA-MA790FX-DQ6", it87xx_probe_spi_flash}, {0x1039, 0x0761, 0, 0, 0, 0, 0, 0, "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash}, {0x1022, 0x7468, 0, 0, 0, 0, 0, 0, "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e}, {0x10de, 0x005e, 0, 0, 0, 0, 0, 0, "msi", "k8n-neo3", "MSI K8N Neo3", w83627thf_gpio4_4_raise_4e},

2 2

[v2] r4161 - trunk/util/flashrom
by svn＠coreboot.org 21 Apr '09

21 Apr '09

Author: hailfinger Date: 2009-04-22 01:03:20 +0200 (Wed, 22 Apr 2009) New Revision: 4161 Modified: trunk/util/flashrom/board_enable.c Log: flashrom: Add support for Gigabyte GA-MA790FX-DQ6. This board uses IT8718F LPC->SPI translation for the flash chip. Tested by Mateusz Murawski. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Mateusz Murawski <matowy(a)tlen.pl> Modified: trunk/util/flashrom/board_enable.c =================================================================== --- trunk/util/flashrom/board_enable.c 2009-04-21 23:02:40 UTC (rev 4160) +++ trunk/util/flashrom/board_enable.c 2009-04-21 23:03:20 UTC (rev 4161) @@ -661,6 +661,8 @@ {0x10de, 0x0360, 0, 0, 0, 0, 0, 0, "gigabyte", "m57sli", "GIGABYTE GA-M57SLI-S4", it87xx_probe_spi_flash}, {0x10de, 0x03e0, 0, 0, 0, 0, 0, 0, "gigabyte", "m61p", "GIGABYTE GA-M61P-S3", it87xx_probe_spi_flash}, {0x1002, 0x4398, 0x1458, 0x5004, 0x1002, 0x4385, 0x1458, 0x4385, NULL, NULL, "GIGABYTE GA-MA78G-DS3H", it87xx_probe_spi_flash}, + /* SB600 LPC, RD790 North. Neither are specific to the GA-MA790FX-DQ6. The coreboot ID is here to be able to trigger the board enable more easily. */ + {0x1002, 0x438d, 0x1458, 0x5001, 0x1002, 0x5956, 0x1002, 0x5956, "gigabyte", "ma790fx-dq6", "GIGABYTE GA-MA790FX-DQ6", it87xx_probe_spi_flash}, {0x1039, 0x0761, 0, 0, 0, 0, 0, 0, "gigabyte", "2761gxdk", "GIGABYTE GA-2761GXDK", it87xx_probe_spi_flash}, {0x1022, 0x7468, 0, 0, 0, 0, 0, 0, "iwill", "dk8_htx", "IWILL DK8-HTX", w83627hf_gpio24_raise_2e}, {0x10de, 0x005e, 0, 0, 0, 0, 0, 0, "msi", "k8n-neo3", "MSI K8N Neo3", w83627thf_gpio4_4_raise_4e},

1 0

[v2] r4160 - trunk/coreboot-v2/src/stream
by svn＠coreboot.org 21 Apr '09

21 Apr '09

Author: stepan Date: 2009-04-22 01:02:40 +0200 (Wed, 22 Apr 2009) New Revision: 4160 Modified: trunk/coreboot-v2/src/stream/rom_stream.c Log: remove a few warnings, and comments ?\195?\131?\194?\161 la #include <foo.h> // include file foo.h (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/stream/rom_stream.c =================================================================== --- trunk/coreboot-v2/src/stream/rom_stream.c 2009-04-21 23:01:10 UTC (rev 4159) +++ trunk/coreboot-v2/src/stream/rom_stream.c 2009-04-21 23:02:40 UTC (rev 4160) @@ -17,16 +17,14 @@ #if (CONFIG_COMPRESSED_PAYLOAD_NRV2B) #define HAVE_UNCOMPRESSER 1 -// include generic nrv2b #include "../lib/nrv2b.c" #endif #if (CONFIG_COMPRESSED_PAYLOAD_LZMA) #if HAVE_UNCOMPRESSER -#error "You're defining more than one compression type, which is not allowed (of course)" +#error "You're defining more than one compression type, which is not allowed." #endif #define HAVE_UNCOMPRESSER 1 -// include generic lzma #include "../lib/lzma.c" #endif @@ -43,13 +41,13 @@ */ /*XXXXXXXXXXXXXX */ -/*static const */unsigned char *rom_start = (unsigned char *)CONFIG_ROM_PAYLOAD_START; -/*static const */unsigned char *rom_end = (unsigned char *)(CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE - 1); +unsigned char *rom_start = (unsigned char *)CONFIG_ROM_PAYLOAD_START; +unsigned char *rom_end = (unsigned char *)(CONFIG_ROM_PAYLOAD_START + PAYLOAD_SIZE - 1); /*XXXXXXXXXXXXXX */ static const unsigned char *rom; -#if UNCOMPRESSER +#ifdef UNCOMPRESSER unsigned long uncompress(uint8_t * rom_start, uint8_t *dest ) { @@ -64,7 +62,7 @@ #endif int stream_init(void) { -#if (UNCOMPRESSER) +#ifdef UNCOMPRESSER unsigned char *dest; unsigned long olen; #endif @@ -73,7 +71,7 @@ (unsigned long)rom_start, (unsigned long)rom_end); -#if (UNCOMPRESSER) +#ifdef UNCOMPRESSER dest = &_eheap; /* need a good address on RAM */

1 0

[v2] r4159 - trunk/coreboot-v2/src/include/device
by svn＠coreboot.org 21 Apr '09

21 Apr '09

Author: stepan Date: 2009-04-22 01:01:10 +0200 (Wed, 22 Apr 2009) New Revision: 4159 Modified: trunk/coreboot-v2/src/include/device/pci_def.h Log: add define for Role-Based Error Reporting to PCIe defines (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/include/device/pci_def.h =================================================================== --- trunk/coreboot-v2/src/include/device/pci_def.h 2009-04-21 23:00:14 UTC (rev 4158) +++ trunk/coreboot-v2/src/include/device/pci_def.h 2009-04-21 23:01:10 UTC (rev 4159) @@ -348,6 +348,7 @@ #define PCI_EXP_DEVCAP_ATN_BUT 0x1000 /* Attention Button Present */ #define PCI_EXP_DEVCAP_ATN_IND 0x2000 /* Attention Indicator Present */ #define PCI_EXP_DEVCAP_PWR_IND 0x4000 /* Power Indicator Present */ +#define PCI_EXP_DEVCAP_RBER 0x8000 /* Role-Based Error Reporting */ #define PCI_EXP_DEVCAP_PWR_VAL 0x3fc0000 /* Slot Power Limit Value */ #define PCI_EXP_DEVCAP_PWR_SCL 0xc000000 /* Slot Power Limit Scale */ #define PCI_EXP_DEVCTL 8 /* Device Control */

1 0

[v2] r4158 - trunk/coreboot-v2/src/arch/i386/smp
by svn＠coreboot.org 21 Apr '09

21 Apr '09

Author: stepan Date: 2009-04-22 01:00:14 +0200 (Wed, 22 Apr 2009) New Revision: 4158 Modified: trunk/coreboot-v2/src/arch/i386/smp/mpspec.c Log: fix a warning for a misnamed define, and make a debug message printk_debug (trivial) Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> Acked-by: Stefan Reinauer <stepan(a)coresystems.de> Modified: trunk/coreboot-v2/src/arch/i386/smp/mpspec.c =================================================================== --- trunk/coreboot-v2/src/arch/i386/smp/mpspec.c 2009-04-21 22:59:00 UTC (rev 4157) +++ trunk/coreboot-v2/src/arch/i386/smp/mpspec.c 2009-04-21 23:00:14 UTC (rev 4158) @@ -197,8 +197,8 @@ mpc->mpc_dstapic = dstapic; mpc->mpc_dstirq = dstirq; smp_add_mpc_entry(mc, sizeof(*mpc)); -#if CONFIG_DEBUG_MPTABLE == 1 - printk_info("add intsrc srcbus 0x%x srcbusirq 0x%x, dstapic 0x%x, dstirq 0x%x\n", +#ifdef DEBUG_MPTABLE + printk_debug("add intsrc srcbus 0x%x srcbusirq 0x%x, dstapic 0x%x, dstirq 0x%x\n", srcbus, srcbusirq, dstapic, dstirq); hexdump(__func__, mpc, sizeof(*mpc)); #endif

1 0

Re: [coreboot] [v2] r4155 - trunk/coreboot-v2/documentation
by Carl-Daniel Hailfinger 21 Apr '09

21 Apr '09

On 21.04.2009 23:45, svn(a)coreboot.org wrote: > Author: stepan > Date: 2009-04-21 23:45:11 +0200 (Tue, 21 Apr 2009) > New Revision: 4155 > > Added: > trunk/coreboot-v2/documentation/codeflow.svg > trunk/coreboot-v2/documentation/hypertransport.svg > Removed: > trunk/coreboot-v2/documentation/codeflow.eps > trunk/coreboot-v2/documentation/hypertransport.eps > Modified: > trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex > trunk/coreboot-v2/documentation/Makefile > Log: > Update to this very old document > > Signed-off-by: Stefan Reinauer <stepan(a)coresystems.de> > Acked-by: Stefan Reinauer <stepan(a)coresystems.de> > Thanks for updating this! I reviewed the commit and have a few minor comments. Would you mind addressing them? Regards, Carl-Daniel > Modified: trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex > =================================================================== > --- trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex 2009-04-21 20:34:36 UTC (rev 4154) > +++ trunk/coreboot-v2/documentation/LinuxBIOS-AMD64.tex 2009-04-21 21:45:11 UTC (rev 4155) > @@ -1,6 +1,6 @@ > % > % This document is released under the GPL > -% Initially written by Stefan Reinauer, <stepan(a)openbios.org> > +% Initially written by Stefan Reinauer, <stepan(a)coresystems.de> > % > > \documentclass[titlepage,12pt]{article} > @@ -18,10 +18,10 @@ > colorlinks=false, > % pdfpagemode=None, % PDF-Viewer starts without TOC > % pdfstartview=FitH, > - pdftitle={LinuxBIOS on AMD64}, > + pdftitle={coreboot on AMD64}, > pdfauthor={Stefan Reinauer}, > - pdfsubject={LinuxBIOS configuration and build process}, > - pdfkeywords={LinuxBIOS, Opteron, AMD64, Athlon64, Build} > + pdfsubject={coreboot configuration and build process}, > + pdfkeywords={coreboot, Opteron, AMD64, configuration, Build} > } > > > @@ -30,9 +30,9 @@ > > \setlength{\parindent}{0pt} > > -\title{LinuxBIOS on AMD64} > -\author{Stefan Reinauer $<$stepan(a)openbios.org$>$} > -\date{June 2nd, 2004} > +\title{coreboot on AMD64} > +\author{Stefan Reinauer $<$stepan(a)coresystems.de$>$} > +\date{April 19th, 2009} > > \begin{document} > > @@ -50,12 +50,12 @@ > > \section{Abstract} > > -This document targets porting LinuxBIOS to new mainboards and creating > -custom firmware images using LinuxBIOS. It describes how to build > -LinuxBIOS images for the AMD64 platform, including hypertransport > +This document targets porting coreboot to new mainboards and creating > +custom firmware images using coreboot. It describes how to build > +coreboot images for the AMD64 platform, including hypertransport > configuration and pertinent utilities. If you are missing information or > find errors in the following descriptions, contact > -\href{mailto:stepan@openbios.org}{\textit{Stefan Reinauer $<$stepan(a)openbios.org$>$}} > +\href{mailto:stepan@coresystems.de}{\textit{Stefan Reinauer $<$stepan(a)coresystems.de$>$}} > > > % > @@ -64,6 +64,7 @@ > > \section{Changes} > \begin{itemize} > + \item 2009/04/19 replace LinuxBIOS with coreboot > \item 2004/06/02 url and language fixes from Ken Fuchs $<$kfuchs(a)winternet.com$>$ > \item 2004/02/10 acpi and option rom updates > \item 2003/11/18 initial release > @@ -72,22 +73,22 @@ > > > % > -% 3 What is LinuxBIOS > +% 3 What is coreboot > % > > -\section{What is LinuxBIOS?} > +\section{What is coreboot?} > > -LinuxBIOS aims to replace the normal BIOS found on PCs, Alphas, and > -other machines with a Linux kernel that can boot Linux from a cold > -start. The startup code of an average LinuxBIOS port is about 500 lines > -of assembly and 5000 lines of C. It executes 16 instructions to get into > -32bit mode and then performs DRAM and other hardware initializations > +coreboot aims to replace the normal BIOS found on x86, AMD64, PPC, > +Alpha, and other machines with a Linux kernel that can boot Linux from a cold > +start. The startup code of an average coreboot port is about 500 lines of > +assembly and 5000 lines of C. It executes 16 instructions to get into 32bit > +protected mode and then performs DRAM and other hardware initializations > required before Linux can take over. > > The projects primary motivation initially was maintenance of large > clusters. Not surprisingly interest and contributions have come from > people with varying backgrounds. Nowadays a large and growing number of > -Systems can be booted with LinuxBIOS, including embedded systems, > +Systems can be booted with coreboot, including embedded systems, > Desktop PCs and Servers. > > % > @@ -95,7 +96,7 @@ > % > > \section{Build Requirements} > -To build LinuxBIOS for AMD64 from the sources you need a recent Linux > +To build coreboot for AMD64 from the sources you need a recent Linux > system for x86 or AMD64. SUSE Linux 8.2 or 9.0 are known to work fine. > The following toolchain is recommended: > > @@ -116,108 +117,100 @@ > > \section{Getting the Sources} > > -The latest LinuxBIOS sources are available via CVS. The CVS repository > -is maintained at SourceForge.net (the project name is \emph{FreeBIOS}). > -First you should create a directory for your LinuxBIOS trees: > +The latest coreboot sources are available via subversion. The subversion > +repository is maintained at SourceForge.net (the project name is > +\emph{FreeBIOS}). First you should create a directory for your > +coreboot trees: > > { \small > \begin{verbatim} > -$ mkdir linuxbios > -$ cd linuxbios > +$ mkdir coreboot > +$ cd coreboot > \end{verbatim} > } > > -You can get the entire source tree via CVS: > +You can get the entire source tree via SVN: > > { \small > \begin{verbatim} > -$ cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios login > +$ svn co svn://coreboot.org/repos/trunk/coreboot-v2 > \end{verbatim} > } > > -Hit return when you are asked for a password. Then checkout (or update) > -the freebios source tree as follows: > - > -{ \small > -\begin{verbatim} > -$ cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/freebios co freebios2 > -\end{verbatim} > -} > - > Once the source tree is checked out, it can be updated with: > > { \small > \begin{verbatim} > -% cvs update -Pd > +% svn update > \end{verbatim} > } > > -Due to recent problems with SourceForge's CVS infrastructure we set up a > -snapshot site that keeps hourly source trees of the last four days. It > -is available at \url{http://snapshots.linuxbios.org/}. > -Due to major structural enhancements to \hbox{LinuxBIOS}, AMD64 support > -is only available in the \texttt{freebios2} tree. This tree reflects (as > -of November 2003) LinuxBIOS version 1.1.5 and will lead to LinuxBIOS 2.0 > +For the case your corporate firewall blocks port 3690 (subversion) we set up a > +snapshot site that keeps the last few hundred source code revisions. It > +is available at \url{http://qa.coreboot.org/}. > +Due to major structural enhancements to \hbox{coreboot}, AMD64 support > +is only available in the \texttt{coreboot-v2} tree. This tree reflects (as > +of November 2003) coreboot version 1.1.5 and will lead to coreboot 2.0 > when finished. Most x86 hardware is currently only supported by the > -LinuxBIOS 1.0 tree. > +coreboot 1.0 tree. > > % > -% 6 LinuxBIOS configuration overview > +% 6 coreboot configuration overview > % > > -\section{LinuxBIOS configuration overview} > -To support a large variety of existing hardware LinuxBIOS allows for a > +\section{coreboot configuration overview} > +To support a large variety of existing hardware coreboot allows for a > lot of configuration options that can be tweaked in several ways: > > \begin{itemize} > \item > Firmware image specific configuration options can be set in the image > configuration file which is usually found in > -\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$/}. Such > +\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$/}. Such > options are the default amount of output verbosity during bootup, image > size, use of fallback mechanisms, firmware image size and payloads > (Linux Kernel, Bootloader...) The default configuration file name is > -\texttt{Config.lb}, but LinuxBIOS allows multiple configurations to > +\texttt{Config.lb}, but coreboot allows multiple configurations to > reside in that directory. > > \item Mainboard specific configuration options can be set in the > mainboard configuration file placed in > -\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$}. The > +\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$}. The > mainboard configuration file is always called \texttt{Config.lb}. It > contains information on the onboard components of the mainboard like > CPU type, northbridge, southbridge, hypertransport configuration and > SuperIO configuration. This configuration file also allows to include > -addon code to hook into the LinuxBIOS initialization mechanism at > +addon code to hook into the coreboot initialization mechanism at > basically any point. > > \end{itemize} > > This document describes different approaches of changing and configuring the > -LinuxBIOS source tree when building for AMD64. > +coreboot source tree when building for AMD64. > > % > -% 7 Building LinuxBIOS > +% 7 Building coreboot > % > > -\section{Building LinuxBIOS} > -One of the design goals for building LinuxBIOS was to keep object files > +\section{Building coreboot} > +One of the design goals for building coreboot was to keep object files > out of the source tree in a separate place. This is mandatory for > -building parallel LinuxBIOS images for several distinct mainboards > -and/or platforms. Therefore building LinuxBIOS consists of two steps: > +building parallel coreboot images for several distinct mainboards > +and/or platforms. Therefore building coreboot consists of two steps: > \begin{itemize} > \item > creating a build tree which holds all files automatically created by the > configuration utility and the object files > \item > -compiling the LinuxBIOS code and creating a flashable firmware image. > +compiling the coreboot code and creating a flashable firmware image. > \end{itemize} > > The first of these two steps is accomplished by the \texttt{buildtarget} > -script found in \texttt{freebios2/targets/}. To build LinuxBIOS for > +script found in \texttt{coreboot-v2/targets/}. To build coreboot for > instance for the AMD Solo Athlon64 mainboard enter: > > \begin{verbatim} > -% cd freebios2/targets > +% cd coreboot-v2/targets > % ./buildtarget amd/solo > \end{verbatim} > > @@ -225,23 +218,23 @@ > components needed for this build. The directory name is defined in the > firmware image specific configuration file. In the case of AMD's Solo > mainboard the default directory resides in > -\texttt{freebios2/targets/amd/solo/solo}. To build the LinuxBIOS image, do > +\texttt{coreboot-v2/targets/amd/solo/solo}. To build the coreboot image, do > > \begin{verbatim} > % cd amd/solo/solo > % make > \end{verbatim} > > -The LinuxBIOS image filename is specified in the firmware image specific > +The coreboot image filename is specified in the firmware image specific > configuration file. The default filename for AMD's Solo mainboard is > \texttt{solo.rom}. > > % > -% 8 Programming LinuxBIOS to flash memory > +% 8 Programming coreboot to flash memory > % > > -\section{Programming LinuxBIOS to flash memory} > -The image resulting from a LinuxBIOS build can be directly programmed to > +\section{Programming coreboot to flash memory} > +The image resulting from a coreboot build can be directly programmed to > a flash device, either using a hardware flash programmer or by using the > Linux flash driver devbios or mtd. This document assumes that you use a > hardware flash programmer. If you are interested in doing in-system > @@ -255,15 +248,15 @@ > \newpage > > % > -% 9 LinuxBIOS configuration > +% 9 coreboot configuration > % > > -\section{LinuxBIOS configuration} > -The following chapters will cope with configuring LinuxBIOS. All > +\section{coreboot configuration} > +The following chapters will cope with configuring coreboot. All > configuration files share some basic rules > \begin{itemize} > \item > -The default configuration file name in LinuxBIOS is \texttt{Config.lb}. > +The default configuration file name in coreboot is \texttt{Config.lb}. > \item > All variables used in a configuration file have to be declared in this > file with \texttt{uses VARNAME} before usage. > @@ -271,8 +264,8 @@ > Comments can be added on a new line by using the comment identifier > \texttt{\#} at the beginning of the line. > \item > -LinuxBIOS distinguishes between statements and options. Statements cause > -the LinuxBIOS configuration mechanism to act, whereas options set > +coreboot distinguishes between statements and options. Statements cause > +the coreboot configuration mechanism to act, whereas options set > variables that are used by the build scripts or source code. > \item > Default configuration values can be set in the mainboard configuration > @@ -280,7 +273,7 @@ > \item > Option overrides to the default configuration can only be specified in > the build target configuration file > -\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$/Config.lb} > +\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$/Config.lb} > (keyword option) > \end{itemize} > > @@ -297,8 +290,8 @@ > \end{verbatim} > > \textbf{NOTE:} Only configuration variables known to the configuration > -system can be used in configuration files. LinuxBIOS checks > -\texttt{freebios2/src/config/Options.lb} to see whether a configuration > +system can be used in configuration files. coreboot checks > +\texttt{coreboot-v2/src/config/Options.lb} to see whether a configuration > variable is known. > > \item \begin{verbatim}default\end{verbatim} > @@ -338,7 +331,7 @@ > The \texttt{option} statement basically behaves identically to the > \texttt{default} statement. But unlike default it can only be used in > build target configuration files > -(\texttt{freebios2/targets/$<$vendor$>$/$<$mainboard$>$}). The option > +(\texttt{coreboot-v2/targets/$<$vendor$>$/$<$mainboard$>$}). The option > statement allows either to set new options or to override default values > set with the default statement in a mainboard configuration file. > Syntax and application are the same as with default. > @@ -346,12 +339,12 @@ > \end{itemize} > > \subsection{Firmware image specific configuration} > -LinuxBIOS allows to create different firmware images for the same > +coreboot allows to create different firmware images for the same > hardware. Such images can differ in the amount of output they produce, > the payload, the number of subimages they consist of etc. > > The firmware image specific configuration file can be found in \\ > -\texttt{freebios2/targets/$<$vendor$>$/<mainboard$>$}. > +\texttt{coreboot-v2/targets/$<$vendor$>$/<mainboard$>$}. > > \subsubsection{Firmware image specific keywords} > In addition to the above described keywords the following statements are > @@ -361,13 +354,13 @@ > \item \begin{verbatim}romimage\end{verbatim} > > The \texttt{romimage} definition describes a single rom build within the > -final LinuxBIOS image. Normally there are two romimage definitions per > -LinuxBIOS build: \texttt{normal} and \texttt{fallback}. > +final coreboot image. Normally there are two romimage definitions per > +coreboot build: \texttt{normal} and \texttt{fallback}. > > Each \texttt{romimage} section needs to specify a mainboard directory and a > payload. The mainboard directory contains the mainboard specific > configuration file and source code. It is specified relatively to > -\texttt{freebios2/src/mainboard}. The payload definition is an absolute > +\texttt{coreboot-v2/src/mainboard}. The payload definition is an absolute > path to a static elf binary (i.e Linux kernel or etherboot) > > \begin{verbatim} > @@ -384,8 +377,8 @@ > \item \begin{verbatim}buildrom\end{verbatim} > > The \texttt{buildrom} statement is used to determine which of the > -LinuxBIOS image builds (created using \texttt{romimage}) are packed > -together to the final LinuxBIOS image. It also specifies the order of > +coreboot image builds (created using \texttt{romimage}) are packed > +together to the final coreboot image. It also specifies the order of > the images and the final image size: > > \begin{verbatim} > @@ -407,7 +400,7 @@ > \item \begin{verbatim}CC\end{verbatim} > > Target C Compiler. Default is \texttt{\$(CROSS\_COMPILE)gcc}. Set to > -\texttt{gcc -m32} for compiling AMD64 LinuxBIOS images on an AMD64 > +\texttt{gcc -m32} for compiling AMD64 coreboot images on an AMD64 > machine. > > \item \begin{verbatim}CONFIG_CHIP_CONFIGURE \end{verbatim} > @@ -444,7 +437,7 @@ > > Export CMOS option table. Default is \texttt{0}. Set to \texttt{1} if > your mainboard has CMOS memory and you want to use it to store > -LinuxBIOS parameters (Loglevel, serial line speed, ...) > +coreboot parameters (Loglevel, serial line speed, ...) > > \item \begin{verbatim}CONFIG_ROM_PAYLOAD\end{verbatim} > > @@ -473,8 +466,8 @@ > > \item \begin{verbatim}COREBOOT_EXTRA_VERSION\end{verbatim} > > -LinuxBIOS extra version. This option has an empty string as default. Set > -to any string to add an extra version string to your LinuxBIOS build. > +coreboot extra version. This option has an empty string as default. Set > +to any string to add an extra version string to your coreboot build. > > \end{itemize} > > @@ -521,7 +514,7 @@ > \item \begin{verbatim}driver\end{verbatim} > > The \texttt{driver} keyword adds an object file to the driver section of a > -LinuxBIOS image. This means it can be used by the PCI device > +coreboot�image. This means it can be used by the PCI device > The character after coreboot looks strange. Intentional? > initialization code. Example: > > \begin{verbatim} > @@ -530,7 +523,7 @@ > > \item \begin{verbatim}object\end{verbatim} > > -The \texttt{object} keyword adds an object file to the LinuxBIOS image. > +The \texttt{object} keyword adds an object file to the coreboot image. > Per default the object file will be compiled from a \texttt{.c} file > with the same name. Symbols defined in such an object file can be used > in other object files and drivers. Example: > @@ -543,7 +536,7 @@ > > This keyword can be used to extend the existing file creation rules > during the build process. This is useful if external utilities have to > -be used for the build. LinuxBIOS on AMD64 uses romcc for it's early > +be used for the build. coreboot on AMD64 uses romcc for it's early > startup code placed in auto.c. > > To tell the configuration mechanism how to build \texttt{romcc} files, > @@ -569,7 +562,7 @@ > \item \begin{verbatim}mainboardinit\end{verbatim} > > With the mainboardinit keyword it's possible to include assembler code > -directly into the LinuxBIOS image. This is used for early infrastructure > +directly into the coreboot image. This is used for early infrastructure > initialization, i.e. to switch to protected mode. Example: > > \begin{verbatim} > @@ -578,12 +571,12 @@ > > \item \begin{verbatim}ldscript\end{verbatim} > > -The GNU linker ld is used to link object files together to a LinuxBIOS > +The GNU linker ld is used to link object files together to a coreboot > ROM image. > > Since it is a lot more comfortable and flexible to use the GNU linker > with linker scripts (ldscripts) than to create complex command line > -calls, LinuxBIOS features including linker scripts to control image > +calls, coreboot features including linker scripts to control image > creation. Example: > > \begin{verbatim} > @@ -593,12 +586,12 @@ > > \item \begin{verbatim}dir\end{verbatim} > > -LinuxBIOS reuses as much code between the different ports as possible. > +coreboot reuses as much code between the different ports as possible. > To achieve this, commonly used code can be stored in a separate > directory. For a new mainboard, it is enough to know that the code in > that directory can be used as is. > > -LinuxBIOS will also read a \texttt{Config.lb} file stored in that > +coreboot will also read a \texttt{Config.lb} file stored in that > directory. This happens with: > > \begin{verbatim} > @@ -630,7 +623,7 @@ > The \texttt{northbridge} keyword describes a system northbridge. Some > systems, like AMD64, can have more than one northbridge, i.e. one per > CPU node. Each northbridge is described by the path to the northbridge > -code in LinuxBIOS (relative to \texttt{freebios2/src/northbridge}), i.e. > +code in coreboot (relative to \texttt{coreboot-v2/src/northbridge}), i.e. > \texttt{amd/amdk8} and a unique name (i.e \texttt{mc0}) \\ > Example: > > @@ -642,7 +635,7 @@ > > \item \begin{verbatim}southbridge\end{verbatim} > > -To simplify the handling of bus bridges in a LinuxBIOS system, all > +To simplify the handling of bus bridges in a coreboot system, all > bridges available in a system that are not northbridges (i.e AGP, IO, > PCIX) are seen as southbridges. > > @@ -672,7 +665,7 @@ > that are provided by the bridge. Generally all bridge sections have a > couple of \texttt{pci} keywords. > > -The first occurrence of the \texttt{pci} keyword tells LinuxBIOS where > +The first occurrence of the \texttt{pci} keyword tells coreboot where > the bridge devices start, relative to the PCI configuration space used > by the bridge. The following occurences of the \texttt{pci} keyword > describe the provided devices. > @@ -716,7 +709,7 @@ > \item \begin{verbatim}superio\end{verbatim} > > SuperIO devices are basically handled like brigdes. They are taking > -their driver code from \texttt{freebios2/src/superio/}. They don't > +their driver code from \texttt{coreboot-v2/src/superio/}. They don't > provide a PCI compatible configuration interface, but instead are ISA > PnP devices. Normally they are connected to a southbridge. If this is > the case, the \texttt{superio} section will be a subsection of the > @@ -796,23 +789,23 @@ > > \item \begin{verbatim}STACK_SIZE\end{verbatim} > > -LinuxBIOS stack size. The size of the function call stack defaults to > +coreboot stack size. The size of the function call stack defaults to > \texttt{0x2000} (8k). > > \item \begin{verbatim}HEAP_SIZE\end{verbatim} > > -LinuxBIOS heap size. The heap is used when LinuxBIOS allocates memory > +coreboot heap size. The heap is used when coreboot allocates memory > with malloc(). The default heap size is \texttt{0x2000}, but AMD64 boards > generally set it to \texttt{0x4000} (16k) > > \item \begin{verbatim}XIP_ROM_BASE\end{verbatim} > > -Start address of area to cache during LinuxBIOS execution directly from > +Start address of area to cache during coreboot execution directly from > ROM. > > \item \begin{verbatim}XIP_ROM_SIZE\end{verbatim} > > -Size of area to cache during LinuxBIOS execution directly from ROM > +Size of area to cache during coreboot execution directly from ROM > > \item \begin{verbatim}CONFIG_COMPRESS\end{verbatim} > > @@ -831,19 +824,19 @@ > > \section{Tweaking the source code} > Besides configuring the existing code it is sometimes necessary or > -desirable to tweak certain parts of LinuxBIOS by direct changes to the > +desirable to tweak certain parts of coreboot by direct changes to the > code. This chapter covers some possible enhancements and changes that > -are needed when porting LinuxBIOS to a new mainboard or just come > +are needed when porting coreboot to a new mainboard or just come > handy now and then. > > \subsection{Hypertransport configuration} > -Before LinuxBIOS is able to activate all CPUs and detect bridges > +Before coreboot is able to activate all CPUs and detect bridges > attached to these CPUs (and thus, see all devices attached to the > system) it has to initialize the coherent hypertransport devices. > > The current algorithms to do coherent hypertransport initialization are > not fully, automatically evaluating the hypertransport chain graph. > -Therefore the code needs to be adapted when porting LinuxBIOS to a new > +Therefore the code needs to be adapted when porting coreboot to a new > AMD64 mainboard. An example arrangement of hypertransport devices > looks like this: > > @@ -867,7 +860,7 @@ > \item Setting outgoing connections > The algorithm needs to know which outgoing port of a CPU node is > connected to the directly succeeding node. This is done in > -\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/auto.c} > +\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/auto.c} > with a number of preprocessor defines (one define for two-node systems, > three defines for four-node systems). > > @@ -895,7 +888,7 @@ > ports. The routing information is written to the AMD K8 routing table. > In an Nnode system this routing table consists of 3*N*N entries , one > for each message type and for each possible CPU --> CPU communication. For > -simplicity LinuxBIOS keeps the 3 routing entries for each CPU --> CPU > +simplicity coreboot keeps the 3 routing entries for each CPU --> CPU > communication in one machine word. The routing table of each node looks > like this: > > @@ -996,7 +989,7 @@ > > \subsection{DRAM configuration} > Setting up the RAM controller(s) is probably the most complex part of > -LinuxBIOS. Basically LinuxBIOS serially initializes all RAM controllers > +coreboot. Basically coreboot serially initializes all RAM controllers > in the system, using SPDROM (serial presence detect) data to set > timings, size and other properties. The SPD data is usually read > utilizing the I2C SMBUS interface of the southbridge. > @@ -1015,7 +1008,7 @@ > > Available mainboard implementations and CPUs create the need to add > special setup code to RAM initialization in a number of places. > -LinuxBIOS provides hooks to easily add code in these places without > +coreboot provides hooks to easily add code in these places without > having to change the generic code. Whether these hooks have to be used > depends on the mainboard design. In many cases the functions executed > by the hooks just carry out trivial default settings or they are even > @@ -1024,7 +1017,7 @@ > Some mainboard/CPU combinations need to trigger an additional memory > controller reset before the memory can be initialized properly. This is, > for example, used to get memory working on preC stepping AMD64 > -processors. LinuxBIOS provides two hooks for triggering onboard memory > +processors. coreboot provides two hooks for triggering onboard memory > reset logic: > > \begin{itemize} > @@ -1046,10 +1039,10 @@ > > The way SMBUS hub information is coded into the \texttt{mem\_controller} > structure is mainboard implementation specific and not > -described here. See \texttt{freebios2/src/mainboard/amd/quartet/auto.c} > +described here. See \texttt{coreboot-v2/src/mainboard/amd/quartet/auto.c} > for an example. > > -LinuxBIOS folks have agreed on SPD data being the central information > +coreboot folks have agreed on SPD data being the central information > source for RAM specific information. But not all mainboards/RAM > modules feature a physical SPD ROM. To still allow an easy to use SPD > driven setup, there is a hook that abstracts reading the SPD ROM > @@ -1086,9 +1079,9 @@ > default IRQ_SLOT_COUNT=7 > \end{verbatim} > > -This will make LinuxBIOS look for the file \\ > -\texttt{freebios2/src/mainboard/<vendor>/<mainboard>/irq\_tables.c} which > -contains the source code definition of the IRQ table. LinuxBIOS corrects > +This will make coreboot look for the file \\ > +\texttt{coreboot-v2/src/mainboard/<vendor>/<mainboard>/irq\_tables.c} which > +contains the source code definition of the IRQ table. coreboot corrects > small inconsistencies in the IRQ table during startup (checksum and > number of entries), but it is not yet writing IRQ tables in a completely > dynamic way. > @@ -1104,11 +1097,11 @@ > > \subsection {MP Tables} > > -LinuxBIOS contains code to create MP tables conforming the > -Multiprocessor Specification V1.4. To include an MP Table in a LinuxBIOS > +coreboot contains code to create MP tables conforming the > +Multiprocessor Specification V1.4. To include an MP Table in a coreboot > image, the following configuration variables have to be set (in the > mainboard specific configuration file > -\texttt{freebios2/src/mainboard/<vendor><mainboard>/Config.lb}): > +\texttt{coreboot-v2/src/mainboard/<vendor><mainboard>/Config.lb}): > > \begin{verbatim} > default CONFIG_SMP=1 > @@ -1116,8 +1109,8 @@ > default HAVE_MP_TABLE=1 > \end{verbatim} > > -LinuxBIOS will then look for a function for setting up the MP table in > -the file \texttt{freebios2/src/mainboard<vendor>/<mainboard>/mptable.c}: > +coreboot will then look for a function for setting up the MP table in > +the file \texttt{coreboot-v2/src/mainboard<vendor>/<mainboard>/mptable.c}: > > \begin{verbatim} > void *smp_write_config_table(void *v, unsigned long * processor_map) > @@ -1130,7 +1123,7 @@ > > \subsection {ACPI Tables} > > -There is initial ACPI support in LinuxBIOS now. Currently the only gain with > +There is initial ACPI support in coreboot now. Currently the only gain with > this is the ability to use HPET timers in Linux. To achieve this, there is a > framework that can generate the following tables: > \begin{itemize} > @@ -1140,7 +1133,7 @@ > \item HPET > \end{itemize} > > -To enable ACPI in your LinuxBIOS build, add the following lines to your > +To enable ACPI in your coreboot build, add the following lines to your > configuration files: > \begin{verbatim} > uses HAVE_ACPI_TABLES > @@ -1155,16 +1148,16 @@ > features. > > \subsection{POST} > -LinuxBIOS has three different methods of handling POST codes. They can > +coreboot has three different methods of handling POST codes. They can > be triggered using configuration file options. > \begin{itemize} > \item > \emph{Ignore POST completely}. No early code debugging is possible with > this setting. Set the configuration variable \texttt{NO\_POST} to > -\texttt{1} to switch off all POST handling in LinuxBIOS. > +\texttt{1} to switch off all POST handling in coreboot. > \item > \emph{Normal IO port 80 POST}. This is the default behavior of > -LinuxBIOS. No configuration variables have to be set. To be able to see > +coreboot. No configuration variables have to be set. To be able to see > port 80 POST output, you need a POST expansion card for ISA or PCI. Port > 80 POST allows simple debugging without any other output method > available (serial interface or VGA display) > @@ -1178,7 +1171,7 @@ > > > \subsection{HDT Debugging} > -If you are debugging your LinuxBIOS code with a Hardware Debug Tool > +If you are debugging your coreboot code with a Hardware Debug Tool > (HDT), you can find the source code line for a given physical EIP > address as follows: Look the address up in the file linuxbios.map. Then > search the label Lxx in the file auto.inc created by romcc. The original > @@ -1186,7 +1179,7 @@ > > > \subsection{Device Drivers} > -With only a few data structures LinuxBIOS features a simple but flexible > +With only a few data structures coreboot features a simple but flexible > device driver interface. This interface is not intended for autonomously > driving the devices but to initialize all system components so that they > can be used by the booted operating system. > @@ -1220,9 +1213,9 @@ > > By separating the two structures above, M:N relations between compatible > devices and drivers can be described. The driver source code containing > -above data structures and code have to be added to a LinuxBIOS image > +above data structures and code have to be added to a coreboot image > using the driver keyword in the mainboard specific configuration file \\ > -\texttt{freebios2/src/mainboard/<vendor>/<mainboard>/Config.lb}: > +\texttt{coreboot-v2/src/mainboard/<vendor>/<mainboard>/Config.lb}: > > \begin{verbatim} > driver lsi_scsi.o > @@ -1230,20 +1223,20 @@ > > \subsection{Bus Bridges} > > -Currently all bridges supported in the LinuxBIOS2 tree are transparent > +Currently all bridges supported in the coreboot-v2 tree are transparent > bridges. This means, once the bridge is initialized, it's remote devices > -are visible on one of the PCI buses without special probing. LinuxBIOS > +are visible on one of the PCI buses without special probing. coreboot > supports also bridges that are nontransparent. The driver support code > can provide a \texttt{scan\_bus} function to scan devices behind the bridge. > > \subsection{CPU Reset} > When changing speed and width of hypertransport chain connections > -LinuxBIOS has to either assert an LDTSTOP or a reset to make the changes > -become active. Additionally Linux can do a firmware reset, if LinuxBIOS > +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\_RESET} and add an object file specifying the > reset code in your mainboard specific configuration file > -\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}: > +\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/Config.lb}: > > \begin{verbatim} > default HAVE_HARD_RESET=1 > @@ -1258,41 +1251,41 @@ > void hard_reset(void); > \end{verbatim} > > -See \texttt{freebios2/src/mainboard/arima/hdama/reset.c} for an example > +See \texttt{coreboot-v2/src/mainboard/arima/hdama/reset.c} for an example > implementation. > > \newpage > > % > -% 11. LinuxBIOS Internals > +% 11. coreboot Internals > % > > -\section{LinuxBIOS Internals} > +\section{coreboot Internals} > This chapter covers some of the internal structures and algorithms of > -LinuxBIOS that have not been mentioned so far. > +coreboot that have not been mentioned so far. > > \subsection{Code Flow} > > \begin{figure}[htb] > \centering > \includegraphics[scale=0.7]{codeflow.pdf} > -\caption{LinuxBIOS rough Code Flow} > +\caption{coreboot rough Code Flow} > \label{fix:codeflow} > \end{figure} > > \newpage > > \subsection{Fallback mechanism} > -LinuxBIOS provides a mechanism to pack two different LinuxBIOS builds > -within one LinuxBIOS ROM image. Using the system CMOS memory LinuxBIOS > +coreboot provides a mechanism to pack two different coreboot builds > +within one coreboot ROM image. Using the system CMOS memory coreboot > determines whether the last boot with a default image succeeded and > boots a failsafe image on failure. This allows insystem testing without > the risk to render the system unusable. See > -\texttt{freebios2/src/mainboard/arima/hdama/failover.c} for example > +\texttt{coreboot-v2/src/mainboard/arima/hdama/failover.c} for example > code. The fallback mechanism can be used with the \texttt{cmos\_util}. > > \subsection{(Un) Supported Standards} > -LinuxBIOS supports the following standards > +coreboot supports the following standards > \begin{itemize} > \item Multiprocessing Specification (MPSPEC) 1.4 > \item IRQ Tables (PIRQ) > @@ -1305,18 +1298,18 @@ > \item APM > \end{itemize} > > -\subsection{LinuxBIOS table} > -LinuxBIOS stores information about the system in a data structure called > -the LinuxBIOS table. This table can be read under Linux using the tool > -lxbios from the Lawrence Livermore National Laboratory. > +\subsection{coreboot table} > +coreboot stores information about the system in a data structure called > +the coreboot table. This table can be read under Linux using the tool > +nvramtool from the Lawrence Livermore National Laboratory. > > Get more information about lxbios and the utility itself at > \url{http://www.llnl.gov/linux/lxbios/lxbios.html} > > \subsection{ROMCC limitations} > -ROMCC, part of the LinuxBIOS project, is a C compiler that translates to > +ROMCC, part of the coreboot project, is a C compiler that translates to > completely rommable code. This means the resulting code does not need > -any memory to work. This is one of the major improvements in LinuxBIOS > +any memory to work. This is one of the major improvements in coreboot > V2, since it allows almost all code to be written in C. DRAM > initialization can be factored and reused more easily among mainboards > and platforms. > @@ -1331,12 +1324,12 @@ > your code. > > \subsection{CMOS handling} > -LinuxBIOS can use the mainboard's CMOS memory to store information > +coreboot can use the mainboard's CMOS memory to store information > defined in a data structure called the CMOS table . This information > contains serial line speed, fallback boot control, output verbosity, > default boot device, ECC control, and more. It can be easily enhanced by > enhancing the CMOS table. This table, if present, is found at > -\texttt{freebios2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/cmos.layout}. > +\texttt{coreboot-v2/src/mainboard/$<$vendor$>$/$<$mainboard$>$/cmos.layout}. > It describes the available options, their possible values and their > position within the CMOS memory. The layout file looks as follows: > \begin{verbatim} > @@ -1358,16 +1351,16 @@ > \end{verbatim} > > To change CMOS values from a running Linux system, use the > -\texttt{cmos\_util}, provided by Linux Networks as part of the LinuxBIOS > +\texttt{cmos\_util}, provided by Linux Networks as part of the coreboot > utilities suite. Get it at > \textit{ftp://ftp.lnxi.com/pub/linuxbios/utilities/} > > \subsection {Booting Payloads} > -LinuxBIOS can load a payload binary from a Flash device or IDE. This > +coreboot can load a payload binary from a Flash device or IDE. This > payload can be a boot loader, like FILO or Etherboot, a kernel image, or > any other static ELF binary. > > -To create a Linux kernel image, that is bootable in LinuxBIOS, you have > +To create a Linux kernel image, that is bootable in coreboot, you have > to use mkelfImage. The command line I used, looks like follows: > > \begin{verbatim} > @@ -1436,9 +1429,9 @@ > operating system can not take advantage of the hardware, so there needs > to be a way to address this issue. There are several alternatives: > > -\subsection{Native LinuxBIOS Support} > +\subsection{Native coreboot Support} > > -For some devices (ie Trident Cyberblade 3d) there is native LinuxBIOS > +For some devices (ie Trident Cyberblade 3d) there is native coreboot > support This means there is a small driver bound to the PCI id of the > device that is called after PCI device ressources are allotted. > > @@ -1458,7 +1451,7 @@ > > \subsection{Using Native Linux Support} > > -A simple way of getting a whole lot of drivers available for LinuxBIOS > +A simple way of getting a whole lot of drivers available for coreboot > is to reuse Linux drivers by putting a Linux kernel to flash. This > works, because no drivers are needed to get the Linux kernel (as opposed > to store the kernel on a harddisk connected to isa/scsi/raid storage) > @@ -1510,7 +1503,7 @@ > an Open Firmware implementation. > > There is a free Open Firmware implementation available, called OpenBIOS, > -that runs on top of LinuxBIOS. See www.openbios.org > +that runs on top of coreboot. See www.openbios.org > > PROs: > \begin{itemize} > @@ -1529,7 +1522,7 @@ > % > > \section{Image types} > -There used to be one image type for LinuxBIOS, as described above. Since this paper was written (2004) there have been many changes. First, the name > +There used to be one image type for coreboot, as described above. Since this paper was written (2004) there have been many changes. First, the name > was changed to coreboot, for many reasons. Second, Ying-Hai Liu, then of AMD, now of Sun, added Cache As Ram support (CAR) for many AMD CPUs, which both simplified and complicated things. Simplification came with the removal of romcc; complication came with the addition of new ways to build. > I thought his name is Yinghai Lu, not Ying-Hai Liu. > > There are two big additions to the build process and, furthermore, more than two new CONFIG variables to control them. > @@ -1702,7 +1695,7 @@ > \begin{itemize} > \item payload > > -LinuxBIOS only cares about low level machine initialization, but also has > +coreboot only cares about low level machine initialization, but also has > very simple mechanisms to boot a file either from FLASHROM or IDE. That > file, possibly a Linux Kernel, a boot loader or Etherboot, are called > payload, since it is the first software executed that does not cope with > @@ -1721,14 +1714,11 @@ > % > > \section{Bibliography} > -\subsection{Additional Papers on LinuxBIOS} > +\subsection{Additional Papers on coreboot} > > \begin{itemize} > - \item { \small > - \textit{\url{http://www.linuxnetworx.com/products/linuxbios_white_paper.pdf}} > Do we have a copy of that doc anywhere? > - } > \item > - \textit{\url{http://www.linuxbios.org/papers/}} > + \textit{\url{http://www.coreboot.org/Documentation}} > \item > \textit{\url{http://www.lysator.liu.se/upplysning/fa/linuxbios.pdf}} > \item > @@ -1739,7 +1729,7 @@ > > \begin{itemize} > \item Etherboot: \textit{\url{http://www.etherboot.org/}} > - \item Filo: \textit{\url{http://te.to/~ts1/filo/}} > + \item Filo: \textit{\url{http://www.coreboot.org/FILO}} > \item OpenBIOS: \textit{\url{http://www.openbios.org/}} > \end{itemize} > > > -- http://www.hailfinger.org/

4 6

← Newer
1
...
20
21
22
23
24
25
26
...
59
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 April 2009