coreboot January 2011

coreboot@coreboot.org

65 participants
299 discussions

[commit] r6322 - trunk/src/include/device
by repository service 31 Jan '11

31 Jan '11

Author: mjones Date: Mon Jan 31 22:14:02 2011 New Revision: 6322 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6322 Log: Add PCI ID's for VIA K8T800 and K8M800 northbridges. Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> Acked-by: Marc Jones <marcj303(a)gmail.com> Modified: trunk/src/include/device/pci_ids.h Modified: trunk/src/include/device/pci_ids.h ============================================================================== --- trunk/src/include/device/pci_ids.h Mon Jan 31 22:03:14 2011 (r6321) +++ trunk/src/include/device/pci_ids.h Mon Jan 31 22:14:02 2011 (r6322) @@ -1220,6 +1220,24 @@ #define PCI_DEVICE_ID_VIA_8505_1 0x8605 #define PCI_DEVICE_ID_VIA_8633_1 0xB091 #define PCI_DEVICE_ID_VIA_8367_1 0xB099 +#define PCI_DEVICE_ID_VIA_K8T800_HT_AGP_CTR 0x0282 +#define PCI_DEVICE_ID_VIA_K8T800_ERR 0x1282 +#define PCI_DEVICE_ID_VIA_K8T800_HOST_CTR 0x2282 +#define PCI_DEVICE_ID_VIA_K8T800_DRAM 0x3282 +#define PCI_DEVICE_ID_VIA_K8T800_PWR 0x4282 +#define PCI_DEVICE_ID_VIA_K8T800_5 0x5282 +#define PCI_DEVICE_ID_VIA_K8T800_6 0x6282 +#define PCI_DEVICE_ID_VIA_K8T800_NB_SB_CTR 0x7282 +#define PCI_DEVICE_ID_VIA_K8M800_HT_AGP_CTR 0x0204 +#define PCI_DEVICE_ID_VIA_K8M800_ERR 0x1204 +#define PCI_DEVICE_ID_VIA_K8M800_HOST_CTR 0x2204 +#define PCI_DEVICE_ID_VIA_K8M800_DRAM 0x3204 +#define PCI_DEVICE_ID_VIA_K8M800_PWR 0x4204 +#define PCI_DEVICE_ID_VIA_K8M800_5 0x5204 +#define PCI_DEVICE_ID_VIA_K8M800_6 0x6204 +#define PCI_DEVICE_ID_VIA_K8M800_NB_SB_CTR 0x7204 +#define PCI_DEVICE_ID_VIA_K8T800_AGP 0x3188 +#define PCI_DEVICE_ID_VIA_K8T800_BR 0xb188 #define PCI_DEVICE_ID_VIA_K8T890CE_0 0x0238 #define PCI_DEVICE_ID_VIA_K8T890CE_1 0x1238 #define PCI_DEVICE_ID_VIA_K8T890CE_2 0x2238

1 0

[commit] r6321 - trunk/src/pc80
by repository service 31 Jan '11

31 Jan '11

Author: stepan Date: Mon Jan 31 22:03:14 2011 New Revision: 6321 URL: https://tracker.coreboot.org/trac/coreboot/changeset/6321 Log: Build failure because of src/pc80/mc146818rtc_early.c unused variable Fixes #173 Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Acked-by: Stefan Reinauer <reinauer(a)google.com> Modified: trunk/src/pc80/mc146818rtc_early.c Modified: trunk/src/pc80/mc146818rtc_early.c ============================================================================== --- trunk/src/pc80/mc146818rtc_early.c Sun Jan 30 17:37:39 2011 (r6320) +++ trunk/src/pc80/mc146818rtc_early.c Mon Jan 31 22:03:14 2011 (r6321) @@ -61,12 +61,12 @@ static inline int do_normal_boot(void) { unsigned char byte; - int i; if (cmos_error() || !cmos_chksum_valid()) { #if CONFIG_USE_CMOS_RECOVERY char *cmos_default = cbfs_find_file("cmos.default", CBFS_COMPONENT_CMOS_DEFAULT); if (cmos_default) { + int i; printk_warning("WARNING - CMOS CORRUPTED. RESTORING DEFAULTS.\n"); /* First 14 bytes are reserved for RTC and ignored by nvramtool, too.

1 0

Fwd: Question about new_resource()
by Sven Schnelle 31 Jan '11

31 Jan '11

Hi Myles, sorry to bother you directly, but Peter suggested to send the question below to you directly, you may have an answer :) Regards, Sven. -------- Original Message -------- Subject: [coreboot] Question about new_resource() Date: Thu, 27 Jan 2011 18:38:55 +0100 From: Sven Schnelle <svens(a)stackframe.org> Organization: private To: coreboot(a)coreboot.org Hi List, while adding support for the Lenovo PMH7 Embedded Controller, i was wondering about the index parameter for new_resource(). >From looking at the coreboot source, it looks like it is an arbitrary number, depending on the device type for which the resource is allocated. What would be the corect number to use for an EC? Or should we add a new index for such devices? I'm attaching the pmh7 diff to this mail, i have chosen 0x77 as a temporary number. Thanks, Sven Index: ec/lenovo/Kconfig =================================================================== --- ec/lenovo/Kconfig (revision 0) +++ ec/lenovo/Kconfig (revision 0) @@ -0,0 +1 @@ +source src/ec/lenovo/pmh7/Kconfig Index: ec/lenovo/Makefile.inc =================================================================== --- ec/lenovo/Makefile.inc (revision 0) +++ ec/lenovo/Makefile.inc (revision 0) @@ -0,0 +1 @@ +subdirs-$(CONFIG_EC_LENOVO_PMH7) += pmh7 Index: ec/lenovo/pmh7/Kconfig =================================================================== --- ec/lenovo/pmh7/Kconfig (revision 0) +++ ec/lenovo/pmh7/Kconfig (revision 0) @@ -0,0 +1,2 @@ +config EC_LENOVO_PMH7 + bool Index: ec/lenovo/pmh7/pmh7.h =================================================================== --- ec/lenovo/pmh7/pmh7.h (revision 0) +++ ec/lenovo/pmh7/pmh7.h (revision 0) @@ -0,0 +1,13 @@ +#ifndef EC_LENOVO_PMH7_H +#define EC_LENOVO_PMH7_H + +#define EC_LENOVO_PMH7_BASE 0x15e0 +#define EC_LENOVO_PMH7_ADDR (EC_LENOVO_PMH7_BASE + 0x0c) +#define EC_LENOVO_PMH7_DATA (EC_LENOVO_PMH7_BASE + 0x0e) + +void pmh7_register_set_bit(int reg, int bit); +void pmh7_register_clear_bit(int reg, int bit); +char pmh7_register_read(int reg); +void pmh7_register_write(int reg, int val); + +#endif Index: ec/lenovo/pmh7/Makefile.inc =================================================================== --- ec/lenovo/pmh7/Makefile.inc (revision 0) +++ ec/lenovo/pmh7/Makefile.inc (revision 0) @@ -0,0 +1 @@ +driver-y += pmh7.c Index: ec/lenovo/pmh7/pmh7.c =================================================================== --- ec/lenovo/pmh7/pmh7.c (revision 0) +++ ec/lenovo/pmh7/pmh7.c (revision 0) @@ -0,0 +1,56 @@ +#include <arch/io.h> +#include <console/console.h> +#include <device/device.h> +#include <device/pnp.h> +#include <stdlib.h> + +#include "pmh7.h" + +void pmh7_register_set_bit(int reg, int bit) +{ + char val; + + outb(reg, EC_LENOVO_PMH7_ADDR); + val = inb(EC_LENOVO_PMH7_DATA); + outb(reg, EC_LENOVO_PMH7_ADDR); + outb(val | (1 << bit), EC_LENOVO_PMH7_DATA); +} + +void pmh7_register_clear_bit(int reg, int bit) +{ + char val; + + outb(reg, EC_LENOVO_PMH7_ADDR); + val = inb(EC_LENOVO_PMH7_DATA); + outb(reg, EC_LENOVO_PMH7_ADDR); + outb(val &= ~(1 << bit), EC_LENOVO_PMH7_DATA); +} + +char pmh7_register_read(int reg) +{ + outb(reg, EC_LENOVO_PMH7_ADDR); + return inb(EC_LENOVO_PMH7_DATA); +} + +void pmh7_register_write(int reg, int val) +{ + outb(reg, EC_LENOVO_PMH7_ADDR); + outb(val, EC_LENOVO_PMH7_DATA); +} + +static void enable_dev(device_t dev) +{ + struct resource *resource; + resource = new_resource(dev, 0x77); + resource->flags = IORESOURCE_IO | IORESOURCE_FIXED; + resource->base = EC_LENOVO_PMH7_BASE; + resource->size = 16; + resource->align = 5; + resource->gran = 5; + +} + +struct chip_operations ec_lenovo_pmh7_ops = { + CHIP_NAME("Lenovo Power Management Hardware Hub 7") + .enable_dev = enable_dev, +}; -- coreboot mailing list: coreboot(a)coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Trac reminder: list of new ticket(s)
by coreboot tracker 31 Jan '11

31 Jan '11

1 0

inteltool: added MCH register names for Intel NM10
by Антон Кочков 31 Jan '11

31 Jan '11

inteltool: added MCH register names for Intel NM10 Signed-off-by: Anton Kochkov <anton.kochkov(a)gmail.com> ---

1 0

Test SeaBIOS AHCI support
by Kevin O'Connor 30 Jan '11

30 Jan '11

Hi, One of the qemu developers added AHCI support to SeaBIOS. This support has been tested on qemu, but not on real hardware. It would be great if folks with coreboot supported hardware could also test it. (Unfortunately, my coreboot board doesn't have AHCI.) To test, grab the latest seabios git (see: http://seabios.org/Download ), edit src/config.h and enable CONFIG_AHCI. (Be sure to also set the other coreboot settings - see: http://www.coreboot.org/SeaBIOS .) Thanks, -Kevin

3 6

[PATCH] [sort of] multiplex console output from each core
by xdrudis 30 Jan '11

30 Jan '11

Hello. This patch works for me but needs a small function calc_id_buffer for each board/cpu/whatever. I only made one for amd quadcore because it is what I have. My board does not get to ramstage, so it might not work there. It works for my serial console but should work for net or usb if I'm not mistaken. Also my tree is not up to date with svn head. Likely things could be placed elsewhere or done better, so it is mostly an idea. But I'm unlikely to have more time for it and it works for me so far, so I'm sending it so that it does not get lost and in case somebody likes the idea and wants to commit or do it better. Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> My problem was with having serial output like [...] init node: 00 cores: 03 Start other core - nodeid: 00 cores: 03 start_other_cores() retuPPPrOOOnSSSeTTTd::: P000OxxxST3:330 00 0 x3 7cc cosootrrraeeexxxr:::t e d-- --a---p-- {{a{ p iAAAPPPcIIIiCCdCI:IID DD === 000231 NNNOOODDDEEEIIIDDD === 000000 CCCOOORRREEEIIIDDD === 000312}}} --------- [...] So I changed it because I like it better like this: [...] �� [...] which is ugly, slow, etc. but I can pipe it to a little script which turns it back into almost the original ("boooh!!!" :( ) or writes it a little nicer ( :) ) [...] core0:init node: 00 cores: 03 core0:Start other core - nodeid: 00 cores: 03 core0:start_other_cores() returned core1:POST: core2:POST: core3:POST: core0:POST: core1: 0x30 core2: 0x30 core3: 0x30 core0:0 core0:x37 core2: c core3: c core0:started ap apicid: core1:corex: --- { APICID = 01 NODEID = 00 COREID = 01} --- core2:orex: --- { APICID = 02 NODEID = 00 COREID = 02} --- core3:orex: --- { APICID = 03 NODEID = 00 COREID = 03} --- [...] or even ( :) ) [...] init node: 00 cores: 03| | | | | | Start other core - nodei| | | d: 00 cores: 03 | | | start_other_cores() retu|P |P |P rned |OST: |OST: |OST: POST: | 0x30 | 0x30 | 0x30 0 | | | | | | x37 | | c | c started ap apicid: |corex: --- { APICID = 0|orex: --- { APICID = 02|orex: --- { APICID = 03 |1 NODEID = 00 COREID = 0| NODEID = 00 COREID = 0 | NODEID = 00 COREID = 03 |1} --- |2} --- |} --- | | | [...] or other options to if you fancy. I observed characters from each core got mixed but bits from each character not, so the superIO or someone probably did alreday synchronize bytes correctly. So I could split each byte in two, add a 4 bit buffer id and pretend each core has a different serial port and I'm multiplexing up to 16 channels for up to 16 cores into one physical serial port, by sending together the channel/buffer id with the character (4 bits buffer id, 4 bits half character). Then a small perl script demultiplexes each channel into a different buffer and formats output. If someone has more than 16 cores does she really want to see ouput from all at a time? Redefining the weak function calc_id_buffer you can choose to have some of them mix into the same buffer or just filter out the output for some of them. Hope the patch is simple enough, else I can explain more later. I must leave now.

4 10

[PATCH] Fix LPC decode ranges on SB700
by Rudolf Marek 30 Jan '11

30 Jan '11

Hello, Attached patch fixes the LPC decode ranges of SB700. We enable early only Serial/SIO/RTC. Everything else needs to be done by lpc.c Problem was that early settings survived, because the lpc.c is doing ORs only... Hence we decode quite a lot and even strange ranges like IO port 0x4600 etc... Also, if some port which does not fit to predefined set is requested, like 0x290 for Hardware monitor, the wide port is done, but in our case it has range 512 bytes which means we decode in fact 0x290 - 0x490. And if we hit GPU in the 0x3bx range I receive MCE exception if I do isadump -f 0x300 which is bad. Therefore If I detect that the requested range is small (16 bytes) I additionally set the small wide io region so only 16 bytes is decoded. While at it, I fix spelling typos and I init the regs so we don't write random garbage to regs even if we don't enable them later. Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz> Thanks, Rudolf

3 4

ASRock 939A785GMH/128M trouble
by Dmitry Samoyloff 30 Jan '11

30 Jan '11

Hello! I've tried to install Coreboot/SeaBIOS on my ASRock 939A785GMH/128M motherboard [1], leaving it totally unbootable: no beeps, no VGA output :-( I followed installation instructions from coreboot.org with SVN checkout, "make menuconfig" and "make". The payload is SeaBIOS stable. BTW, what makes me suspicious is a build process, the first "make" failed with: <...> Compiling (16bit) out/code16.o Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth") Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth") Building ld scripts (version "0.6.1.2-20110129_195624-innsmouth") Traceback (most recent call last): File "./tools/layoutrom.py", line 436, in <module> main() File "./tools/layoutrom.py", line 428, in main keep16[0], keep32seg[0], keep32flat[0]) File "./tools/layoutrom.py", line 161, in doLayout locs16fixed, firstfixed = fitSections(fixedsections, textsections) File "./tools/layoutrom.py", line 141, in fitSections firstfixed = fixedsections[0][0] IndexError: list index out of range make[2]: *** [out/romlayout16.lds] Error 1 make[2]: *** Waiting for unfinished jobs.... Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 make[2]: *** wait: Нет дочерних процессов. Stop. make[1]: *** [seabios] Error 2 make: *** [seabios] Error 2 However, the subsequent "make clean" and "make" ended up with success: <...> Compiling (16bit) out/code16.o Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth") Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth") Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth") Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 Building ld scripts (version "0.6.1.2-20110129_200005-innsmouth") Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 Linking out/rom16.o Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 Linking out/rom32seg.o Stripping out/rom32seg.strip.o Stripping out/rom16.strip.o Fixed space: 0xe05b-0x10000 total: 8101 slack: 15 Percent slack: 0.2% 16bit size: 39872 32bit segmented size: 2529 32bit flat size: 54383 Linking out/rom.o Prepping out/bios.bin Total size: 96784 Free space: 34288 Percent used: 73.8% (128KiB rom) CBFS coreboot.rom PAYLOAD SeaBIOS (internal, compression: LZMA) CBFSPRINT coreboot.rom After that I copied build/coreboot.rom onto USB flash and installed it on motherboard's flash successfully using "flashrom -w coreboot.rom". The motherboard's chip is Winbond W25Q80, 1024 KB (this size is a default in menuconfig, so I didn't changed it). I will answer more questions if it's needed. I'd also appreciate any help or hints on recovery, because now I can't even boot. I tried that trick with AMIBOOT.ROM on USB flash and <Ctrl>+<Home>, but it didn't worked for me. Thanks in advance for your help! [1] http://www.coreboot.org/ASRock_939A785GMH-128M

3 6

build service results for r6320
by repository service 30 Jan '11

30 Jan '11

Dear coreboot readers! This is the automatic build system of coreboot. The developer "oxygene" checked in revision 6320 to the coreboot repository. This caused the following changes: Change Log: Replace special rules for auxiliary files by cbfs-files-y entries VGABIOS, Intel MBI and the bootsplash image were added with special build rules. These are replaced by generic cbfs-files-y entries now. Signed-off-by: Patrick Georgi <patrick.georgi(a)secunet.com> Acked-by: Peter Stuge <peter(a)stuge.se> Build Log: Compilation of compaq:deskpro_en_sff_p600 has been fixed If something broke during this checkin please be a pain in oxygene's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

← Newer
1
2
3
4
5
6
7
...
30
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 January 2011