coreboot April 2012

coreboot@coreboot.org

39 participants
459 discussions

New patch to review for coreboot: beca17b amdfam10: add phenom II as known cpu
by Bernhard Urban 06 Apr '12

06 Apr '12

Bernhard Urban (lewurm(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/864 -gerrit commit beca17b9dc211fa2c8424083724c28c5f37d52bf Author: Bernhard Urban <lewurm(a)gmail.com> Date: Thu Apr 5 17:13:27 2012 +0200 amdfam10: add phenom II as known cpu Change-Id: I84a0f9e8e7a15c0aac8dc380de3ddf70b1decbd7 Signed-off-by: Bernhard Urban <lewurm(a)gmail.com> --- src/northbridge/amd/amdfam10/raminit_amdmct.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/src/northbridge/amd/amdfam10/raminit_amdmct.c b/src/northbridge/amd/amdfam10/raminit_amdmct.c index 0c01cf1..973384b 100644 --- a/src/northbridge/amd/amdfam10/raminit_amdmct.c +++ b/src/northbridge/amd/amdfam10/raminit_amdmct.c @@ -211,6 +211,9 @@ u32 mctGetLogicalCPUID(u32 Node) case 0x10081: ret = AMD_HY_D1; break; + case 0x100a0: + ret = AMD_PH_E0; + break; default: /* FIXME: mabe we should die() here. */ print_err("FIXME! CPU Version unknown or not supported! \n");

3 2

Re: [coreboot] GSoC project ideas
by Peter Stuge 06 Apr '12

06 Apr '12

Paul Geraedts wrote: > >> I will try to make my VHDL cores so they will be compatible with > >> both types of boards. I plan to start with UART over USB support > >> for the currently available Papilio boards. > > > > UART is stoneage idiotic useless. It's 2012, so please aim higher. > > Yet another opinion I guess; It's a bit more than opinion. > at the end of the day opinions should not matter. What a nice way to say that you reject my input. > >> Basically flashrom SPI access, POST code access and serial console > >> access. This 'playground' should eventually give me enough insight > >> in an optimal implementation when targeting future boards. > > > > Don't invent yet another packet protocol on top of a serial stream, > > do this right the first time. You're planning on implementing three > > different functions, and they really do need to use different > > interfaces. > > Do not worry. No need for assumptions. I was not planning to. SPI, port 80, and 16550 are the three functions you list, and which I refer to. These are good features, that's not the point, the point is that they are distinct features, so it makes sense to have them fall out the other side of the FPGA as such. > I will write a number of VHDL cores that plug in to a Wishbone > interface that will also be connected to a USB controller. Wishbone to some degree and USB for certain takes a lot of logic space, and I think they're both way overkill for this simple FPGA design. USB MAC core can make good sense if high speed is required, but that's not the case for either of these functions. Optimizing for design size allows cheaper and simpler implementation, ideally the LPC slave can even be made to fit into a CPLD. > In the first version that controller will be a (circuit-switched) > UART over USB controller (switched either manually or by means of > routing an extra GPIO pin of the FT2232D to the FPGA). You overlook or ignore my earlier point. Use something more structured than UART right from the start. > Future boards is expected to contain improved USB hardware in several > flavors ranging from a USB transceiver-only approach with USB stack in > FPGA, to an FT232H in MPSSE mode, to a dedicated microprocesser with > build-in USB and anything in between. Right, I've talked with Jack about these things quite a bit. > It should not matter what kind of hardware is used It matters a lot for implementability, design size and thus manufacturability based on possible usable parts. > as long as it contains a similar Wishbone interface it will be > transparant to the rest of the Wishbone cores. I don't see the need for Wishbone in this design. > > For the SPI flash emulator, suggest use IS61WV20488BLL-10TLI. > > The first prototype will not contain SRAM, but merely act as an SPI > master mux. Due to its complexity, cost and GPIO pin count, I will > only consider SRAM if absolutely necessary. SRAM is trivial to interface, but it does need lots of pins! It is in any case quite neccessary for the design to be useful for development and testing; I believe the third usecase you listed originally. Please tell some more about your background? Thanks //Peter

2 1

Re: [coreboot] New patch to review for coreboot: dc63ffb Fill out ChromeOS specific coreboot table extensions
by Peter Stuge 06 Apr '12

06 Apr '12

ron minnich wrote: > > Maybe it should be made clear also in the names that these tags are > > chromeos specific? > > I don't think we should. I am hoping that some other vendor will > figure out how neat these things are and use them too. It's good to collaborate on design rather than just run with something? //Peter

1 0

Patch merged into coreboot/master: d9462c6 Fix support for RAM-less multi-processor init
by gerrit＠coreboot.org 06 Apr '12

06 Apr '12

the following patch was just integrated into master: commit d9462c6dca942bed9a609cc40572912bb33f0558 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Fri Apr 6 04:03:50 2012 +0300 Fix support for RAM-less multi-processor init Fix regression after commit: 7dfe32c5408916b6cb23f1ec48e473e1c728d300 Only align 16-bit entry on platforms that really require it, indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig. Disable assertion test of AP_SIPI_VECTOR for platforms not depending on this feature. Build of romstage should be fixed to get the vector address from bootblock build automatically. Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Build-Tested: build bot (Jenkins) at Fri Apr 6 04:48:34 2012, giving +1 Reviewed-By: Stefan Reinauer <stefan.reinauer(a)coreboot.org> at Fri Apr 6 04:56:58 2012, giving +2 See http://review.coreboot.org/875 for details. -gerrit

1 0

New patch to review for coreboot: d9462c6 Fix support for RAM-less multi-processor init
by Kyösti Mälkki 06 Apr '12

06 Apr '12

Kyösti Mälkki (kyosti.malkki(a)gmail.com) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/875 -gerrit commit d9462c6dca942bed9a609cc40572912bb33f0558 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Fri Apr 6 04:03:50 2012 +0300 Fix support for RAM-less multi-processor init Fix regression after commit: 7dfe32c5408916b6cb23f1ec48e473e1c728d300 Only align 16-bit entry on platforms that really require it, indicated by selecting SIPI_VECTOR_IN_ROM in CPU Kconfig. Disable assertion test of AP_SIPI_VECTOR for platforms not depending on this feature. Build of romstage should be fixed to get the vector address from bootblock build automatically. Change-Id: Ide470833c0254df1a9ff708369ab1c095ccfb98d Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- src/arch/x86/Kconfig | 7 +++++++ src/arch/x86/init/ldscript_failover.lb | 14 +++++++++----- src/cpu/intel/socket_mPGA604/Kconfig | 1 + 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/src/arch/x86/Kconfig b/src/arch/x86/Kconfig index f49d09b..6d56ec6 100644 --- a/src/arch/x86/Kconfig +++ b/src/arch/x86/Kconfig @@ -8,6 +8,13 @@ config AP_IN_SIPI_WAIT default n depends on ARCH_X86 +# Aligns 16bit entry code in bootblock so that hyper-threading CPUs +# can boot AP CPUs to enable their shared caches. +config SIPI_VECTOR_IN_ROM + bool + default n + depends on ARCH_X86 + config RAMBASE hex default 0x100000 diff --git a/src/arch/x86/init/ldscript_failover.lb b/src/arch/x86/init/ldscript_failover.lb index 61c3d2a..d6940ee 100644 --- a/src/arch/x86/init/ldscript_failover.lb +++ b/src/arch/x86/init/ldscript_failover.lb @@ -30,10 +30,11 @@ TARGET(binary) SECTIONS { /* Symbol ap_sipi_vector must be aligned to 4kB to start AP CPUs - * with Startup IPI message without RAM. + * with Startup IPI message without RAM. Align .rom to next 4 byte + * boundary anyway, so no pad byte appears between _rom and _start. */ .bogus ROMLOC_MIN : { - . = ALIGN(4096); + . = CONFIG_SIPI_VECTOR_IN_ROM ? ALIGN(4096) : ALIGN(4); ROMLOC = .; } >rom = 0xff @@ -52,11 +53,14 @@ SECTIONS * may cause the total size of a section to change when the start * address gets applied. */ - ROMLOC_MIN = 0xffffff00 - (_erom - _rom + 16) - 4096; + ROMLOC_MIN = 0xffffff00 - (_erom - _rom + 16) - + (CONFIG_SIPI_VECTOR_IN_ROM ? 4096 : 0); /* Post-check proper SIPI vector. */ - _bogus = ASSERT(((ap_sipi_vector & 0x0fff) == 0x0), "Bad SIPI vector alignment"); - _bogus = ASSERT((ap_sipi_vector == CONFIG_AP_SIPI_VECTOR), "Address mismatch on AP_SIPI_VECTOR"); + _bogus = ASSERT(!CONFIG_SIPI_VECTOR_IN_ROM || ((ap_sipi_vector & 0x0fff) == 0x0), + "Bad SIPI vector alignment"); + _bogus = ASSERT(!CONFIG_SIPI_VECTOR_IN_ROM || (ap_sipi_vector == CONFIG_AP_SIPI_VECTOR), + "Address mismatch on AP_SIPI_VECTOR"); /DISCARD/ : { *(.comment) diff --git a/src/cpu/intel/socket_mPGA604/Kconfig b/src/cpu/intel/socket_mPGA604/Kconfig index 4fa7569..0d4d45f 100644 --- a/src/cpu/intel/socket_mPGA604/Kconfig +++ b/src/cpu/intel/socket_mPGA604/Kconfig @@ -11,6 +11,7 @@ config SOCKET_SPECIFIC_OPTIONS # dummy select MMX select SSE select UDELAY_TSC + select SIPI_VECTOR_IN_ROM # mPGA604 are usually Intel Netburst CPUs which should have SSE2 # but the ramtest.c code on the Dell S1850 seems to choke on

1 0

Re: [coreboot] GSoC project ideas
by Peter Stuge 06 Apr '12

06 Apr '12

Paul Geraedts wrote: > My hardware target is the Papilio platform in general For the SPI flash emulator, suggest use IS61WV20488BLL-10TLI. //Peter

2 1

Re: [coreboot] GSoC project ideas
by Paul Geraedts 06 Apr '12

06 Apr '12

Hi Svetoslav, On Wed Apr 4 23:17:46 CEST 2012, Svetoslav Trochev wrote: >>> - Flash ICE device with SPI support. >>> - Flash ICE device with LPC/FWH support. >>> - Serial emulation for LPC buses on a configurable I/O port with USB >>> output on the other side. >>> - Dual serial emulation for two LPC buses either on the same device or >>> with two identical devices and a fast bus in between. >>> - Serial emulation for PCI buses (i.e. PCI/serial card). >> >> Currently I am working towards items 1 and 3 of your list. Eventually I >> want to use this hardware to replace the flash content of my MSI Wind >> U100 netbook with free software (openec, coreboot, seabios, ipxe, grub2, >> etc). I want to keep my implementation sufficiently generic to allow for >> extensions like items 2, 4 and 5 of your list. > > I am also interested in item 1. [1] But looks like you are far ahead > of me. :) Currently I am waiting for my hardware to arrive. I ordered > Open Workbench Logic Sniffer [2]. Do you think I can help you in your > work? I am interested to see if we eventually can port the Papilio code base to the OLS. It may be challenging: the OLS has a rather limited power supply and not too many GPIO pins. I do not own one, so you could help me with this. For the time being I would recommend to learn more about writing proper RTL code in VHDL and play around with existing code examples [1]. You typically do not learn this stuff overnight, but I think it is worth the the effort. Regards, Paul [1] http://www.gadgetfactory.net/

1 0

Patch set updated for coreboot: ba45bea Add support for SMSC LPC47N207 SuperI/O chip
by Stefan Reinauer 06 Apr '12

06 Apr '12

Stefan Reinauer (stefan.reinauer(a)coreboot.org) just uploaded a new patch set to gerrit, which you can find at http://review.coreboot.org/823 -gerrit commit ba45bea96cc244284e13f74e7a4d760952904938 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Fri Mar 30 15:06:04 2012 -0700 Add support for SMSC LPC47N207 SuperI/O chip This includes only early serial support for now. Change-Id: I9a2a439e1d17a989428033fdb4a4b813553dab6d Signed-off-by: Vadim Bendebury <vbendeb(a)chromium.org> Signed-off-by: Stefan Reinauer <reinauer(a)google.com> --- src/superio/smsc/lpc47n207/early_serial.c | 97 +++++++++++++++++++++++++++++ src/superio/smsc/lpc47n207/lpc47n207.h | 25 ++++++++ 2 files changed, 122 insertions(+), 0 deletions(-) diff --git a/src/superio/smsc/lpc47n207/early_serial.c b/src/superio/smsc/lpc47n207/early_serial.c new file mode 100644 index 0000000..e2ae49d --- /dev/null +++ b/src/superio/smsc/lpc47n207/early_serial.c @@ -0,0 +1,97 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2012 The ChromiumOS Authors. All rights reserved. + * + * 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 + */ + +/* + * This code tries to discover the SMSC LPC47N207 superio chip which can be + * connected over an LPC dongle. The chip could be bootstrap mapped to one of + * four LPC addresses: 0x2e, 0x4e, 0x162e, and 0x164e. + * + * Initializing the UART requires accesses to a few control registers. This + * structure includes the register offset and the value to write (along with + * the mask). + */ +typedef struct { + u8 conf_reg; + u8 value; + u8 mask; +} uart_conf; + +/* All regs/values to write to initialize the LPC47N207 UART */ +static const uart_conf uart_conf_data [] = { + {2, (1 << 3), (1 << 3)}, /* cr02, enable Primary UART power */ + {0xc, (1 << 6), (1 << 6)}, /* cr0c, enable Primary UART high speed */ + {0x24, (CONFIG_TTYS0_BASE >> 3) << 1, 0xff}, /* cr24, base addr */ +}; + +void try_enabling_LPC47N207_uart(void) +{ + u8 reg_value; + const uart_conf* conf_item; + u16 lpc_ports[] = {0x2e, 0x4e, 0x162e, 0x164e}; + u16 lpc_port; + int i, j; + +#define CONFIG_ENABLE 0x55 +#define CONFIG_DISABLE 0xaa + + for (j = 0; j < ARRAY_SIZE(lpc_ports); j++) { + lpc_port = lpc_ports[j]; + + /* enable CONFIG mode */ + outb(CONFIG_ENABLE, lpc_port); + reg_value=inb(lpc_port); + if (reg_value != CONFIG_ENABLE) { + continue; /* There is no LPC device at this address */ + } + + do { + /* + * Registers 12 and 13 hold config address, look for a + * match. + */ + outb(0x12, lpc_port); + reg_value=inb(lpc_port + 1); + if (reg_value != (lpc_port & 0xff)) + break; + + outb(0x13, lpc_port); + reg_value=inb(lpc_port + 1); + if (reg_value != (lpc_port >> 8)) + break; + + /* This must be the SMSC LPC 47N207, enable the UART. */ + for (i = 0; i < ARRAY_SIZE(uart_conf_data); i++) { + u8 reg, value, mask; + + conf_item = uart_conf_data + i; + + reg = conf_item->conf_reg; + value = conf_item->value; + mask = conf_item->mask; + + outb(reg, lpc_port); + reg_value = inb(lpc_port + 1); + reg_value &= ~mask; + reg_value |= (value & mask); + outb(reg_value, lpc_port + 1); + } + } while (0); + outb(CONFIG_DISABLE, lpc_port); + } +} diff --git a/src/superio/smsc/lpc47n207/lpc47n207.h b/src/superio/smsc/lpc47n207/lpc47n207.h new file mode 100644 index 0000000..69689a4 --- /dev/null +++ b/src/superio/smsc/lpc47n207/lpc47n207.h @@ -0,0 +1,25 @@ +/* + * This file is part of the coreboot project. + * + * Copyright (C) 2012 The ChromiumOS Authors. All rights reserved. + * + * 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 SUPERIO_SMSC_LPC47N207_LPC47N207_H +#define SUPERIO_SMSC_LPC47N207_LPC47N207_H + +extern void try_enabling_LPC47N207_uart(void); + +#endif

1 0

Patch merged into coreboot/master: b16b60f Add Sandybridge/Cougar Point support to SMM relocation handler
by gerrit＠coreboot.org 06 Apr '12

06 Apr '12

the following patch was just integrated into master: commit b16b60fd585a776063526ccf589d6b21480ea174 Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Thu Apr 5 15:59:33 2012 -0700 Add Sandybridge/Cougar Point support to SMM relocation handler Previously this part of smmrelocate.S had to be omitted because the CONFIG_ options for those components did not exist yet. Add them back. Change-Id: I6ac94ca804e03062724401a08d1d174adac5e830 Signed-off-by: Stefan Reinauer <reinauer(a)google.com> Build-Tested: build bot (Jenkins) at Fri Apr 6 02:09:49 2012, giving +1 See http://review.coreboot.org/874 for details. -gerrit

1 0

Patch merged into coreboot/master: 6cacede Cache 8MB flash instead of 4MB
by gerrit＠coreboot.org 06 Apr '12

06 Apr '12

the following patch was just integrated into master: commit 6cacede10e33019d6cbf2486f51f11ecaf3a797b Author: Stefan Reinauer <reinauer(a)chromium.org> Date: Tue Apr 3 16:24:37 2012 -0700 Cache 8MB flash instead of 4MB Also fix the MTRR check to use the total_mtrrs variable instead of a hardcoded 8. Change-Id: I2c5ceb3910cd949f43ecf5b8aff857d6ffe0b1a5 Signed-off-by: Duncan Laurie <dlaurie(a)google.com> Build-Tested: build bot (Jenkins) at Fri Apr 6 01:54:21 2012, giving +1 See http://review.coreboot.org/873 for details. -gerrit

1 0

← Newer
1
...
31
32
33
34
35
36
37
...
46
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 April 2012