coreboot December 2008

coreboot@coreboot.org

77 participants
330 discussions

[PATCH][v2] mptable for pc2500e
by Jonathan A. Kollasch 20 Dec '08

20 Dec '08

Hi, This adds a mptable for the VIA pc2500e. I've tested with the devices in the VT8237R, and a card interrupting at Pin-A on either PCI slot. Signed-off-by: Jonathan A. Kollasch <jakllsch(a)kollasch.net> ---

2 1

r3826 - trunk/coreboot-v2/src/mainboard/via/pc2500e
by svn＠coreboot.org 20 Dec '08

20 Dec '08

Author: stuge Date: 2008-12-20 05:08:40 +0100 (Sat, 20 Dec 2008) New Revision: 3826 Added: trunk/coreboot-v2/src/mainboard/via/pc2500e/mptable.c Modified: trunk/coreboot-v2/src/mainboard/via/pc2500e/Options.lb Log: This adds a mptable for the VIA pc2500e. I've tested with the devices in the VT8237R, and a card interrupting at Pin-A on either PCI slot. Signed-off-by: Jonathan A. Kollasch <jakllsch(a)kollasch.net> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/coreboot-v2/src/mainboard/via/pc2500e/Options.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/via/pc2500e/Options.lb 2008-12-19 14:21:42 UTC (rev 3825) +++ trunk/coreboot-v2/src/mainboard/via/pc2500e/Options.lb 2008-12-20 04:08:40 UTC (rev 3826) @@ -18,6 +18,7 @@ ## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA ## +uses CONFIG_SMP uses HAVE_MP_TABLE uses HAVE_PIRQ_TABLE uses USE_FALLBACK_IMAGE @@ -80,7 +81,8 @@ default CONFIG_CONSOLE_VGA = 0 default CONFIG_CHIP_NAME = 1 default HAVE_FALLBACK_BOOT = 1 -default HAVE_MP_TABLE = 0 +default CONFIG_SMP = 1 +default HAVE_MP_TABLE = 1 default CONFIG_UDELAY_TSC = 1 default CONFIG_TSC_X86RDTSC_CALIBRATE_WITH_TIMER2 = 1 default HAVE_HARD_RESET = 0 Added: trunk/coreboot-v2/src/mainboard/via/pc2500e/mptable.c =================================================================== --- trunk/coreboot-v2/src/mainboard/via/pc2500e/mptable.c (rev 0) +++ trunk/coreboot-v2/src/mainboard/via/pc2500e/mptable.c 2008-12-20 04:08:40 UTC (rev 3826) @@ -0,0 +1,159 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2007 AMD + * (Written by Yinghai Lu <yinghailu(a)amd.com> for AMD) + * Copyright (C) 2007 Philipp Degler <pdegler(a)rumms.uni-mannheim.de> + * (Thanks to LSRA University of Mannheim for their support) + * Copyright (C) 2008 Jonathan A. Kollasch <jakllsch(a)kollasch.net> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include <console/console.h> +#include <arch/smp/mpspec.h> +#include <device/pci.h> +#include <string.h> +#include <stdint.h> +#include <../../../southbridge/via/vt8237r/vt8237r.h> + + +#define bus_isa 2 + +void *smp_write_config_table(void *v) +{ + static const char sig[4] = "PCMP"; + static const char oem[8] = "VIA "; + static const char productid[12] = "PC2500 "; + struct mp_config_table *mc; + + int bus_num; + int i; + + mc = (void *)(((char *)v) + SMP_FLOATING_TABLE_LEN); + memset(mc, 0, sizeof(*mc)); + + memcpy(mc->mpc_signature, sig, sizeof(sig)); + mc->mpc_length = sizeof(*mc); /* initially just the header */ + mc->mpc_spec = 0x04; + mc->mpc_checksum = 0; /* not yet computed */ + memcpy(mc->mpc_oem, oem, sizeof(oem)); + memcpy(mc->mpc_productid, productid, sizeof(productid)); + mc->mpc_oemptr = 0; + mc->mpc_oemsize = 0; + mc->mpc_entry_count = 0; /* No entries yet... */ + mc->mpc_lapic = LAPIC_ADDR; + mc->mpe_length = 0; + mc->mpe_checksum = 0; + mc->reserved = 0; + + smp_write_processors(mc); + + +/* Bus: Bus ID Type*/ + /* define numbers for pci and isa bus */ + for (bus_num = 0; bus_num < bus_isa; bus_num++) { + smp_write_bus(mc, bus_num, "PCI "); + } + smp_write_bus(mc, bus_isa, "ISA "); + + +/* I/O APICs: APIC ID Version State Address*/ + smp_write_ioapic(mc, VT8237R_APIC_ID, 0x20, VT8237R_APIC_BASE); + + /* Now, assemble the table. */ + + smp_write_intsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, + bus_isa, 0x0, VT8237R_APIC_ID, 0x0); + +#define ISA_INT(intr, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_EDGE|MP_IRQ_POLARITY_HIGH, \ + bus_isa, (intr), VT8237R_APIC_ID, (pin)) + + ISA_INT(1, 1); + ISA_INT(0, 2); + ISA_INT(3, 3); + ISA_INT(4, 4); + + ISA_INT(6, 6); + ISA_INT(7, 7); + ISA_INT(8, 8); + ISA_INT(9, 9); + + ISA_INT(0xc, 0xc); + ISA_INT(0xd, 0xd); + ISA_INT(0xe, 0xe); + ISA_INT(0xf, 0xf); + +#define PCI_INT(bus, dev, fn, pin) \ + smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, \ + bus, (((dev)<<2)|(fn)), VT8237R_APIC_ID, (pin)) + + // PCI slot 1 + PCI_INT(0, 8, 0, 16); + PCI_INT(0, 8, 1, 17); + PCI_INT(0, 8, 2, 18); + PCI_INT(0, 8, 3, 19); + + // PCI slot 2 + PCI_INT(0, 9, 0, 17); + PCI_INT(0, 9, 1, 18); + PCI_INT(0, 9, 2, 19); + PCI_INT(0, 9, 3, 16); + + // SATA + PCI_INT(0, 15, 1, 20); + + // USB + PCI_INT(0, 16, 0, 21); + PCI_INT(0, 16, 1, 21); + PCI_INT(0, 16, 2, 21); + PCI_INT(0, 16, 3, 21); + + // Audio + PCI_INT(0, 17, 2, 22); + + // Ethernet + PCI_INT(0, 18, 0, 23); + + /* Onboard VGA */ + PCI_INT(1, 0, 0, 16); + +/*Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN#*/ + smp_write_lintsrc(mc, mp_ExtINT, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + 0, 0x0, MP_APIC_ALL, 0x0); + smp_write_lintsrc(mc, mp_NMI, + MP_IRQ_TRIGGER_DEFAULT | MP_IRQ_POLARITY_DEFAULT, + 0, 0x0, MP_APIC_ALL, 0x1); + + /* There is no extension information... */ + + /* Compute the checksums */ + mc->mpe_checksum = + smp_compute_checksum(smp_next_mpc_entry(mc), mc->mpe_length); + mc->mpc_checksum = smp_compute_checksum(mc, mc->mpc_length); + printk_debug("Wrote the mp table end at: %p - %p\n", + mc, smp_next_mpe_entry(mc)); + return smp_next_mpe_entry(mc); +} + +unsigned long write_smp_table(unsigned long addr) +{ + void *v; + v = smp_write_floating_table(addr); + return (unsigned long)smp_write_config_table(v); +}

1 0

PATCH [2/2]: romtool
by Jordan Crouse 19 Dec '08

19 Dec '08

This is the userland component for creating ROMs: jordan@:romtool >./romtool -h romtool [OPTION] [[FILE] [COMMAND] [PARAMETERS]... Apply COMMANDS with PARAMETERS to FILE. If no COMMAND is given, run in interactive mode OPTIONs: -h Display this help message -C <dir> Change to the directory before operating COMMANDs: add [FILE] [NAME] [TYPE] Add a component add-payload [FILE] [NAME] [OPTIONS] Add a payload to the ROM add-stage [FILE] [NAME] [OPTIONS] Add a stage to the ROM bootblock [FILE] Add a bootblock to the ROM create SIZE [ALIGN] [BOOTBLOCK] Create a ROM file delete [NAME] ... Delete a component print Show the contents of the ROM resize [SIZE] [ERASEBLOCK] Resize the ROM Signed-off-by: Jordan Crouse <jordan(a)cosmicpenguin.net>

1 0

ROMFS
by Jordan Crouse 19 Dec '08

19 Dec '08

Greetings. I apologize for the incompleteness of what I am about to discuss. I was planning on working on it leisurely, but my employment circumstances changed and I've been trying to get it completed in a hurry before I had to leave it behind. I've been thinking a lot about LAR lately, and ways to make it more extensible and robust. Marc and I have been trading ideas back and forth for a number of months, and over time a clear idea of what I wanted to do started to take shape. My goal was to add small things to LAR while retaining the overall scheme. Over time, the scheme evolved slightly, but I think you'll find that it remains true to the original idea. Below is the beginnings of an architecture document - I did it in text form, but if met with aclaim, it should be wikified. This presents what I call ROMFS - the next generation LAR for next generation Coreboot. Its easier to describe what it is by describing what changed: A header has been added somewhere in the bootblock similar to Carl Daniel's scheme. In addition to the coreboot information, the header reports the size of the ROM, the alignment of the blocks, and the offset of the first component in the ROMFS. The master header provides all the information LAR needs plus the magic number information flashrom needs. Each "file" (or component, as I style them) now has a type associated with it. The type is used by coreboot to identify the type of file that it is loading, and it can also be used by payloads to group items in the ROMFS by type (i.e - bayou can ask for all components that are payloads). The header on each "file" (or component, as I like to style them) has been simplified - We now only store the length, the type, the checksum, and the offset to the data. The name scheme remains the same. The addtional information, which is component specific, has been moved to the component itself (see below). The components are arranged in the ROM aligned along the specified alignment from the master header - this is to facilitate partial re-write. Other then that, the LAR ideas remain pretty much the same. The plan for moving the metadata to the components is to allow many different kinds of components, not all of which are groked by coreboot. However, there are three essential component types that are groked by coreboot, and they are defined: stage - the stage is being parsed from the original ELF, and stored in the ROM as a single blob of binary data. The load address, start address, compression type and length are stored in the component sub-header. payload - this is essentially SELF in different clothing - same idea as SELF, with the sub-header as above. optionrom - This is in flux - right now, the optionrom is stored unadulterated and uncompressed, but that is likely to be changed. Following this email are two replies containing the v3 code and a new ROM tool to implement this respectively. I told you that I was trying to get this out before I disappear, and I'm not kidding - the code is compile tested and not run-tested. I hope that somebody will embrace this code and take it the rest of the way, otherwise it will die a pretty short death. I realize that this will start an awesome flamewar, and I'm looking forward to it. Thanks for listening to me over the years - and good luck with coreboot. When you all make a million dollars, send me a few bucks, will you? Jordan Coreboot ROMFS Specification Jordan Crouse <jordan(a)cosmicpenguin.net> = Introduction = This document describes the coreboot ROMFS specification (from here referred to as ROMFS). ROMFS is a scheme for managing independent chunks of data in a system ROM. Though not a true filesystem, the style and concepts are similar. = Architecture = The ROMFS architecture looks like the following: /---------------\ <-- Start of ROM | /-----------\ | --| | | Header | | | | |-----------| | | | | Name | | |-- Component | |-----------| | | | |Data | | | | |.. | | | | \-----------/ | --| | | | /-----------\ | | | Header | | | |-----------| | | | Name | | | |-----------| | | |Data | | | |.. | | | \-----------/ | | | | ... | | /-----------\ | | | | | | | Bootblock | | | | --------- | | | | Reset | | <- 0xFFFFFFF0 | \-----------/ | \---------------/ The ROMFS architecture consists of a binary associated with a physical ROM disk referred hereafter as the ROM. A number of independent of components, each with a header prepended on to data are located within the ROM. The components are nominally arranged sequentially, though they are aligned along a pre-defined boundary. The bootblock occupies the last 20k of the ROM. Within the bootblock is a master header containing information about the ROM including the size, alignment of the components, and the offset of the start of the first ROMFS component within the ROM. = Master Header = The master header contains essential information about the ROM that is used by both the ROMFS implementation within coreboot at runtime as well as host based utilities to create and manage the ROM. The master header will be located somewhere within the bootblock (last 20k of the ROM). A pointer to the location of the header will be located at offset -12 from the end of the ROM. This translates to address 0xFFFFFFF4 on a normal x86 system. The pointer will be to physical memory somewhere between - 0xFFFFB000 and 0xFFFFFFF0. This makes it easier for coreboot to locate the header at run time. Build time utilities will need to read the pointer and do the appropriate math to locate the header. The following is the structure of the master header: struct romfs_header { unsigned int magic; unsigned int size; unsigned int align; unsigned int offset; }; The meaning of each member is as follows: 'magic' is a 32 bit number that identifies the ROM as a ROMFS type. The magic number is 0x4F524243, which is 'ORBC' in ASCII. 'size' is the size of the ROM in bytes. Coreboot will subtract 'size' from 0xFFFFFFFF to locate the beginning of the ROM in memory. 'align' is the number of bytes that each component is aligned to within the ROM. This is used to make sure that each component is aligned correctly with regards to the erase block sizes on the ROM - allowing one to replace a component at runtime without disturbing the others. 'offset' is the offset of the the first ROMFS component (from the start of the ROM). This is to allow for arbitrary space to be left at the beginning of the ROM for things like embedded controller firmware. = Bootblock = The bootblock is a mandatory component in the ROM. It is located in the last 20k of the ROM space, and contains, among other things, the location of the master header and the entry point for the loader firmware. The bootblock does not have a component header attached to it. = Components = ROMFS components are placed in the ROM starting at 'offset' specified in the master header and ending at the bootblock. Thus the total size available for components in the ROM is (ROM size - 20k - 'offset'). Each ROMFS component is to be aligned according to the 'align' value in the header. Thus, if a component of size 1052 is located at offset 0 with an 'align' value of 1024, the next component will be located at offset 2048. Each ROMFS component will be indexed with a unique ASCII string name of unlimited size. Each ROMFS component starts with a header: struct ROMFS_file { char magic[8]; unsigned int len; unsigned int type; unsigned int checksum; unsigned int offset; }; 'magic' is a magic value used to identify the header. During runtime, coreboot will scan the ROM looking for this value. The default magic is the string 'LARCHIVE'. 'len' is the length of the data, not including the size of the header and the size of the name. 'type' is a 32 bit number indicating the type of data that is attached. The data type is used in a number of ways, as detailed in the section below. 'checksum' is a 32bit checksum of the entire component, including the header and name. 'offset' is the start of the component data, based off the start of the header. The difference between the size of the header and offset is the size of the component name. Immediately following the header will be the name of the component, which will null terminated and 16 byte aligned. The following picture shows the structure of the header: /--------\ <- start | Header | |--------| <- sizeof(struct romfs_file) | Name | |--------| <- 'offset' | Data | | ... | \--------/ <- start + 'offset' + 'len' == Searching Alogrithm == To locate a specific component in the ROM, one starts at the 'offset' specified in the ROMFS master header. For this example, the offset will be 0. From that offset, the code should search for the magic string on the component, jumping 'align' bytes each time. So, assuming that 'align' is 16, the code will search for the string 'LARCHIVE' at offset 0, 16, 32, etc. If the offset ever exceeds the allowable range for ROMFS components, then no component was found. Upon recognizing a component, the software then has to search for the specific name of the component. This is accomplished by comparing the desired name with the string on the component located at offset + sizeof(struct romfs_file). If the string matches, then the component has been located, otherwise the software should add 'offset' + 'len' to the offset and resume the search for the magic value. == Data Types == The 'type' member of struct romfs_file is used to identify the content of the component data, and is used by coreboot and other run-time entities to make decisions about how to handle the data. There are three component types that are essential to coreboot, and so are defined here. === Stages === Stages are code loaded by coreboot during the boot process. They are essential to a successful boot. Stages are comprised of a single blob of binary data that is to be loaded into a particular location in memory and executed. The uncompressed header contains information about how large the data is, and where it should be placed, and what additional memory needs to be cleared. Stages are assigned a component value of 0x10. When coreboot sees this component type, it knows that it should pass the data to a sub-function that will process the stage. The following is the format of a stage component: /--------\ | Header | |--------| | Binary | | .. | \--------/ The header is defined as: struct romfs_stage { unsigned int compression; unsigned long long entry; unsigned long long load; unsigned int len; unsigned int memlen; }; 'compression' is an integer defining how the data is compressed. There are three compression types defined by this version of the standard: none (0x0), lzma (0x1), and nrv2b (0x02), though additional types may be added assuming that coreboot understands how to handle the scheme. 'entry' is a 64 bit value indicating the location where the program counter should jump following the loading of the stage. This should be an absolute physical memory address. 'load' is a 64 bit value indicating where the subsequent data should be loaded. This should be an absolute physical memory address. 'len' is the length of the compressed data in the component. 'memlen' is the amount of memory that will be used by the component when it is loaded. The component data will start immediately following the header. When coreboot loads a stage, it will first zero the memory from 'load' to 'memlen'. It will then decompress the component data according to the specified scheme and place it in memory starting at 'load'. Following that, it will jump execution to the address specified by 'entry'. Some components are designed to execute directly from the ROM - coreboot knows which components must do that and will act accordingly. === Payloads === Payloads are loaded by coreboot following the boot process. Stages are assigned a component value of 0x20. When coreboot sees this component type, it knows that it should pass the data to a sub-function that will process the payload. Furthermore, other run time applications such as 'bayou' may easily index all available payloads on the system by searching for the payload type. The following is the format of a stage component: /-----------\ | Header | | Segment 1 | | Segment 2 | | ... | |-----------| | Binary | | .. | \-----------/ The header is as follows: struct romfs_payload { struct romfs_payload_segment segments; } The header contains a number of segments corresponding to the segments that need to be loaded for the payload. The following is the structure of each segment header: struct romfs_payload_segment { unsigned int type; unsigned int compression; unsigned int offset; unsigned long long load_addr; unsigned int len; unsigned int mem_len; }; 'type' is the type of segment, one of the following: PAYLOAD_SEGMENT_CODE 0x45444F43 The segment contains executable code PAYLOAD_SEGMENT_DATA 0x41544144 The segment contains data PAYLOAD_SEGMENT_BSS 0x20535342 The memory speicfied by the segment should be zeroed PAYLOAD_SEGMENT_PARAMS 0x41524150 The segment contains information for the payload PAYLOAD_SEGMENT_ENTRY 0x52544E45 The segment contains the entry point for the payload 'compression' is the compression scheme for the segment. Each segment can be independently compressed. There are three compression types defined by this version of the standard: none (0x0), lzma (0x1), and nrv2b (0x02), though additional types may be added assuming that coreboot understands how to handle the scheme. 'offset' is the address of the data within the component, starting from the component header. 'load_addr' is a 64 bit value indicating where the segment should be placed in memory. 'len' is a 32 bit value indicating the size of the segment within the component. 'mem_len' is the size of the data when it is placed into memory. The data will located immediately following the last segment. === Option ROMS === The third specified component type will be Option ROMs. Option ROMS will have component type '0x30'. They will have no additional header, the uncompressed binary data will be located in the data portion of the component. === NULL === There is a 4th component type ,defined as NULL (0xFFFFFFFF). This is the "don't care" component type. This can be used when the component type is not necessary (such as when the name of the component is unique. i.e. option_table). It is recommended that all components be assigned a unique type, but NULL can be used when the type does not matter.

1 0

bug in pgtbl.c ?
by Baski Kannan 19 Dec '08

19 Dec '08

I think there is a bug in the file " src/cpu/x86/pae/pgtbl.c" the pg_table struct should be struct pg_table { struct pde pd[2048]; struct pde pdp[4]; } __attribute__ ((packed)); instead of struct pg_table { struct pde pd[2048]; struct pde pdp[512]; } __attribute__ ((packed)); Thx - Baski

1 0

Re: [coreboot] [RFC] Here we go... the SLOF biosemu for coreboot-v3
by Pattrick Hueper 19 Dec '08

19 Dec '08

On Thu, Dec 4, 2008 at 10:14 PM, Pattrick Hueper <phueper(a)hueper.net> wrote: > On Thu, Dec 4, 2008 at 5:39 PM, Myles Watson <mylesgw(a)gmail.com> wrote: >> This is the same patch minus: >> - The typedefs in types.h and multiboot.h ( s/uintXX_t/uXX/g) >> - The -g in the Makefile >> - An unrelated comment in stage0.s Hi, here is an updated patch series, no changes in types.h / multiboot.h anymore. You can ignore 0011-enable-debug-g.patch. The change in stage0_common.S was not part of my changes, it seem that it was introduced by a svn update Jordan did? ( it was commited by Carl-Daniel, i think). Patty

8 21

2 keypoints to use coreboot+seabios to achieve WINDOWS-XP's s3 sleep/resume
by JasonZhao＠viatech.com.cn 19 Dec '08

19 Dec '08

Firstly, you need download two patchs:the Kevin's for using Seabios as payload, and Rudolf's for s3. http://www.coreboot.org/pipermail/coreboot/2008-September/038551.html www.coreboot.org/pipermail/coreboot/2008-January/028787.html Then there are two steps to do (Rudolf gave me much advice on IRC :-) , he is a good teacher) #1 Since OS put some realmode code to the s3 resume vector before it demands the mainboard to enter sleep, we need to backup the resume code before coreboot using real memory(may destroy the resume code) and recovery it before Coreboot jumps into the resume vector. In the main()of cache_as_ram_auto.c, just before the stack switching code, add this: if( (bootmode == 3){ print_debug("copy memory to high memory to protect s3 wakeup vector code \r\n"); memcpy((unsigned char *)(highmem_bakaddress),(unsigned char *)0, 0x100000);//highmem_bakaddress=512M-xxM } In the acpi_jump_wake() of wakeup.c, add this: memcpy((unsigned char *)(resumevector), (unsigned char *)(highmem_bakaddress+resumevector), 0x1000); //(ubuntu's vector=0x2000, XP's =0x1c000, but you should just get this from the FACS table as in Kevin's patch, even he move the FACS to the highend memory) #2 Since when resume from S3, coreboot do not go into payload, so in vga driver codes need be added to do vga init after it judged that this is a boot waked from s3. if(acpi_sleep_type==3) {printk_debug("Enable VGA console\n"); vga_enable_console();} if(acpi_sleep_type==3) {xxxxxx} if(acpi_sleep_type==3) {xxxxxx}

3 4

r3825 build service
by coreboot information 19 Dec '08

19 Dec '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "uwe" checked in revision 3825 to the coreboot source repository and caused the following changes: Change Log: Add some comments to make it easier to enable onboard VGA for different ROM chip sizes (trivial, tested with 256 KB chip). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Build Log: Compilation of dell:s1850 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=3825&device=s1850&vendor=d… If something broke during this checkin please be a pain in uwe's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

r3825 - in trunk/coreboot-v2: src/mainboard/kontron/986lcd-m targets/kontron/986lcd-m
by svn＠coreboot.org 19 Dec '08

19 Dec '08

Author: uwe Date: 2008-12-19 15:21:42 +0100 (Fri, 19 Dec 2008) New Revision: 3825 Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb Log: Add some comments to make it easier to enable onboard VGA for different ROM chip sizes (trivial, tested with 256 KB chip). Signed-off-by: Uwe Hermann <uwe(a)hermann-uwe.de> Acked-by: Uwe Hermann <uwe(a)hermann-uwe.de> Modified: trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb =================================================================== --- trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb 2008-12-19 05:53:30 UTC (rev 3824) +++ trunk/coreboot-v2/src/mainboard/kontron/986lcd-m/Config.lb 2008-12-19 14:21:42 UTC (rev 3825) @@ -180,7 +180,9 @@ device pci 01.0 off end # i945 PCIe root port chip drivers/pci/onboard device pci 02.0 on end # vga controller - register "rom_address" = "0xfff00000" + # register "rom_address" = "0xfffc0000" # 256 KB image + # register "rom_address" = "0xfff80000" # 512 KB image + register "rom_address" = "0xfff00000" # 1 MB image end device pci 02.1 on end # display controller Modified: trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb =================================================================== --- trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb 2008-12-19 05:53:30 UTC (rev 3824) +++ trunk/coreboot-v2/targets/kontron/986lcd-m/Config.lb 2008-12-19 14:21:42 UTC (rev 3825) @@ -3,14 +3,17 @@ ## ROM_SIZE is the total number of bytes allocated for coreboot use ## (normal AND fallback images and payloads). -option ROM_SIZE = 1024*1024 +option ROM_SIZE = 1024 * 1024 +# Use this line instead if you want to use onboard VGA: +# option ROM_SIZE = (1024 * 1024) - (64 * 1024) + ## ROM_IMAGE_SIZE is the maximum number of bytes allowed for a coreboot image, ## not including any payload. -option ROM_IMAGE_SIZE = 0x20000 +option ROM_IMAGE_SIZE = 128 * 1024 ## FALLBACK_SIZE is the amount of the ROM the complete fallback image -## (including payload) will use +## (including payload) will use. option FALLBACK_SIZE = ROM_SIZE romimage "fallback"

1 0

Tyan K8QS Pro
by David Melik 19 Dec '08

19 Dec '08

I would like to try Coreboot on a Tyan K8QSD Pro. When I run flashrom, it says the following, but dumps no ROM. flashrom -r backup.bin Calibrating delay loop... OK. No coreboot table found. Found chipset "AMD8111", enabling flash write... OK. Found chip "SST SST49LF004A/B" (512 KB) at physical address 0xfff80000. Can't mmap memory using /dev/mem: Invalid argument --David

2 3

← Newer
1
...
12
13
14
15
16
17
18
...
33
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 December 2008