coreboot April 2012

coreboot@coreboot.org

39 participants
459 discussions

Re: [coreboot] coccinelle project for i915 graphics driver for coreboot
by Kevin O'Connor 18 Apr '12

18 Apr '12

On Mon, Apr 16, 2012 at 05:09:58PM -0700, ron minnich wrote: > On Mon, Apr 16, 2012 at 5:06 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote: > This has been done for Geode vga. I'm not familiar > > with the i915 chipset, but there's a chance that you just need to copy > > the C initialization code over. > > no, it's quite complex, especially when you take the aux/ddc channel > into account and all the other fun bits. It's not a simple > framebuffer. Is it a lot of initialization code to get the chip into a framebuffer mode, or is it that the chip can't be put into a framebuffer mode and all text writing is quite complex? If it's the former, then it's still C code that could be called from SeaVGABIOS. (Well, not quite, as the current SeaVGABIOS init runs in 16bit mode, but it wouldn't be hard to convert it to run in 32bit mode.) Anyway, just something to think about. -Kevin

1 0

Patch merged into coreboot/master: a99159b Leverage the Pstate table created by AGESA.
by gerrit＠coreboot.org 18 Apr '12

18 Apr '12

the following patch was just integrated into master: commit a99159bd88b984957714dc8f123a8126b5e9404a Author: zbao <fishbaozi(a)gmail.com> Date: Thu Apr 12 11:27:26 2012 +0800 Leverage the Pstate table created by AGESA. The name of processor created by AGESA is P00n, whose P is BLDCFG_PROCESSOR_SCOPE_NAME(is 'C' if it is undefined.) and n starts from 0. The dsdt should be aligned with that. This feature has only been tested on persimmon. The changes on all the other boards were propagated. Change-Id: I8c3fa4b94406d530d2bed8e9a1f42b433bbec3ec Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Signed-off-by: zbao <fishbaozi(a)gmail.com> Build-Tested: build bot (Jenkins) at Wed Apr 18 05:26:29 2012, giving +1 Reviewed-By: Marc Jones <marcj303(a)gmail.com> at Thu Apr 19 01:04:44 2012, giving +2 See http://review.coreboot.org/884 for details. -gerrit

1 0

Patch merged into coreboot/master: 060fba7 S3: Use old heap during normal boot
by gerrit＠coreboot.org 18 Apr '12

18 Apr '12

the following patch was just integrated into master: commit 060fba770b8e067defb91ed7ba266fced87e438a Author: zbao <fishbaozi(a)gmail.com> Date: Wed Apr 18 16:59:53 2012 +0800 S3: Use old heap during normal boot During normal boot, the cbmem is uninitialized. So it is illegal to find the heap in cbmem. Change-Id: I8b5e1dbf1124819ed91693a86a6dbe41aea109e5 Signed-off-by: Zheng Bao <zheng.bao(a)amd.com> Signed-off-by: zbao <fishbaozi(a)gmail.com> Build-Tested: build bot (Jenkins) at Wed Apr 18 09:56:53 2012, giving +1 Reviewed-By: Marc Jones <marcj303(a)gmail.com> at Thu Apr 19 01:02:45 2012, giving +2 See http://review.coreboot.org/904 for details. -gerrit

1 0

Re: [coreboot] blobs
by Svetoslav Trochev 18 Apr '12

18 Apr '12

Hi Everyone, [cut] > > We should probably have some best practices about the blobs. It would > be good if there was a text file to accompany a blob that had > important details. Where is came from, what it is for, license, etc. > Also, how difficult is to add footnote on the Wiki [1] when blob is required? If the footnote can also link to blob detail page would be even better. [cut] Best regards, Svetoslav Trochev

1 0

Re: [coreboot] blobs
by Carl-Daniel Hailfinger 18 Apr '12

18 Apr '12

Am 17.04.2012 18:08 schrieb ron minnich: > Please find here: > ssh://review.coreboot.org:29418/blobs.git > > blobs needed for the two google systems. > > I will be removing the blob from the coreboot tree today. > > I hope this helps bring the discussion to a close :-) Thanks for the fast response and for the source/blob separation. It is very much appreciated. Regards, Carl-Daniel

1 0

Re: [coreboot] blobs
by ron minnich 18 Apr '12

18 Apr '12

we had some discussion here and the feeling is it should not be automatic. ron

1 0

Re: [coreboot] blobs
by Marc Jones 18 Apr '12

18 Apr '12

On Tue, Apr 17, 2012 at 10:08 AM, ron minnich <rminnich(a)gmail.com> wrote: > Please find here: > ssh://review.coreboot.org:29418/blobs.git > > blobs needed for the two google systems. > > I will be removing the blob from the coreboot tree today. > > I hope this helps bring the discussion to a close :-) > > ron Hi Ron, We should probably have some best practices about the blobs. It would be good if there was a text file to accompany a blob that had important details. Where is came from, what it is for, license, etc. Also, we should talk about how this gets pulled in with the coreboot tree. Should/could the coreboot make/kconfig pull in the blobs repo? Should we use git submodules or subtree merge? Any git expert comments? Marc -- http://se-eng.com

1 0

New patch to review for coreboot: bde4191 Intel e7505: build as separate object file
by Kyösti Mälkki 18 Apr '12

18 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/906 -gerrit commit bde4191986a64775c2a4c5bfc53c3b22cf202276 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Wed Apr 18 21:13:33 2012 +0300 Intel e7505: build as separate object file No longer include northbridge files directly in the source for mainboard romstage.c and fix includes. Also make required adjustments to function declarations. Change-Id: Iafdcc0766ed44c64cc628e5935eef2c6372f5f22 Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- src/mainboard/aopen/dxplplusu/romstage.c | 13 +++------ src/northbridge/intel/e7505/Makefile.inc | 2 + src/northbridge/intel/e7505/debug.c | 42 ++++++++++++++++++----------- src/northbridge/intel/e7505/debug.h | 15 ++++++++++ src/northbridge/intel/e7505/raminit.c | 15 +++++++++- src/northbridge/intel/e7505/raminit.h | 5 +++ 6 files changed, 65 insertions(+), 27 deletions(-) diff --git a/src/mainboard/aopen/dxplplusu/romstage.c b/src/mainboard/aopen/dxplplusu/romstage.c index ee900e9..1b3e785 100644 --- a/src/mainboard/aopen/dxplplusu/romstage.c +++ b/src/mainboard/aopen/dxplplusu/romstage.c @@ -20,33 +20,28 @@ #include <stdint.h> #include <device/pci_def.h> #include <arch/io.h> -#include <device/pnp_def.h> #include <arch/romcc_io.h> -#include <cpu/x86/lapic.h> #include <arch/cpu.h> #include <stdlib.h> -#include <pc80/mc146818rtc.h> #include <console/console.h> #include <cpu/x86/bist.h> -#include <spd.h> #include "southbridge/intel/i82801dx/i82801dx.h" #include "southbridge/intel/i82801dx/early_smbus.c" #include "southbridge/intel/i82801dx/reset.c" #include "northbridge/intel/e7505/raminit.h" -#include "northbridge/intel/e7505/debug.c" + +#include <device/pnp_def.h> #include "superio/smsc/lpc47m10x/early_serial.c" #define SERIAL_DEV PNP_DEV(0x2e, LPC47M10X2_SP1) -static inline int spd_read_byte(unsigned device, unsigned address) +int spd_read_byte(unsigned device, unsigned address) { return smbus_read_byte(device, address); } -#include "northbridge/intel/e7505/raminit.c" - void main(unsigned long bist) { static const struct mem_controller memctrl[] = { @@ -66,7 +61,7 @@ void main(unsigned long bist) report_bist_failure(bist); // If this is a warm boot, some initialization can be skipped - if (!bios_reset_detected()) { + if (!e7505_mch_is_ready()) { enable_smbus(); /* The real MCH initialisation. */ diff --git a/src/northbridge/intel/e7505/Makefile.inc b/src/northbridge/intel/e7505/Makefile.inc index 23eada5..8c50e40 100644 --- a/src/northbridge/intel/e7505/Makefile.inc +++ b/src/northbridge/intel/e7505/Makefile.inc @@ -1 +1,3 @@ ramstage-y += northbridge.c +romstage-y += raminit.c +romstage-y += debug.c diff --git a/src/northbridge/intel/e7505/debug.c b/src/northbridge/intel/e7505/debug.c index 07f1596..87569a5 100644 --- a/src/northbridge/intel/e7505/debug.c +++ b/src/northbridge/intel/e7505/debug.c @@ -1,9 +1,20 @@ + +#include <device/pci_def.h> +#include <console/console.h> +#include <stdlib.h> +#include <arch/io.h> +#include <arch/romcc_io.h> +#include <spd.h> + +#include "raminit.h" +#include "debug.h" + /* * generic debug code, used by mainboard specific romstage.c * */ -#if 1 -static void print_debug_pci_dev(unsigned dev) + +void print_debug_pci_dev(unsigned dev) { print_debug("PCI: "); print_debug_hex8((dev >> 16) & 0xff); @@ -13,7 +24,7 @@ static void print_debug_pci_dev(unsigned dev) print_debug_hex8((dev >> 8) & 7); } -static inline void print_pci_devices(void) +void print_pci_devices(void) { device_t dev; for(dev = PCI_DEV(0, 0, 0); @@ -31,7 +42,7 @@ static inline void print_pci_devices(void) } } -static void dump_pci_device(unsigned dev) +void dump_pci_device(unsigned dev) { int i; print_debug_pci_dev(dev); @@ -58,7 +69,7 @@ static void dump_pci_device(unsigned dev) print_debug("\n"); } -static inline void dump_pci_devices(void) +void dump_pci_devices(void) { device_t dev; for(dev = PCI_DEV(0, 0, 0); @@ -75,7 +86,7 @@ static inline void dump_pci_devices(void) } } -static inline void dump_pci_devices_on_bus(unsigned busn) +void dump_pci_devices_on_bus(unsigned busn) { device_t dev; for(dev = PCI_DEV(busn, 0, 0); @@ -92,7 +103,7 @@ static inline void dump_pci_devices_on_bus(unsigned busn) } } -static inline void dump_spd_registers(const struct mem_controller *ctrl) +void dump_spd_registers(const struct mem_controller *ctrl) { int i; print_debug("\n"); @@ -121,7 +132,7 @@ static inline void dump_spd_registers(const struct mem_controller *ctrl) print_debug(": "); #endif } - status = smbus_read_byte(device, j); + status = spd_read_byte(device, j); if (status < 0) { break; } @@ -158,7 +169,7 @@ static inline void dump_spd_registers(const struct mem_controller *ctrl) print_debug(": "); #endif } - status = smbus_read_byte(device, j); + status = spd_read_byte(device, j); if (status < 0) { break; } @@ -174,13 +185,13 @@ static inline void dump_spd_registers(const struct mem_controller *ctrl) } } } -static inline void dump_smbus_registers(void) +void dump_smbus_registers(void) { unsigned device; print_debug("\n"); for(device = 1; device < 0x80; device++) { int j; - if( smbus_read_byte(device, 0) < 0 ) continue; + if( spd_read_byte(device, 0) < 0 ) continue; #if !defined(__ROMCC__) printk(BIOS_DEBUG, "smbus: %02x", device); #else @@ -190,7 +201,7 @@ static inline void dump_smbus_registers(void) for(j = 0; j < 256; j++) { int status; unsigned char byte; - status = smbus_read_byte(device, j); + status = spd_read_byte(device, j); if (status < 0) { break; } @@ -215,7 +226,7 @@ static inline void dump_smbus_registers(void) } } -static inline void dump_io_resources(unsigned port) +void dump_io_resources(unsigned port) { int i; @@ -249,7 +260,7 @@ static inline void dump_io_resources(unsigned port) } } -static inline void dump_mem(unsigned start, unsigned end) +void dump_mem(unsigned start, unsigned end) { unsigned i; print_debug("dump_mem:"); @@ -271,5 +282,4 @@ static inline void dump_mem(unsigned start, unsigned end) #endif } print_debug("\n"); - } -#endif +} diff --git a/src/northbridge/intel/e7505/debug.h b/src/northbridge/intel/e7505/debug.h new file mode 100644 index 0000000..a517fc0 --- /dev/null +++ b/src/northbridge/intel/e7505/debug.h @@ -0,0 +1,15 @@ +#ifndef E7505_DEBUG_H +#define E7505_DEBUG_H + +void print_debug_pci_dev(unsigned dev); +void print_pci_devices(void); +void dump_pci_device(unsigned dev); +void dump_pci_devices(void); +void dump_pci_devices_on_bus(unsigned busn); +void dump_spd_registers(const struct mem_controller *ctrl); +void dump_smbus_registers(void); +void dump_io_resources(unsigned port); +void dump_mem(unsigned start, unsigned end); + +#endif + diff --git a/src/northbridge/intel/e7505/raminit.c b/src/northbridge/intel/e7505/raminit.c index 1d10a8c..fd4e2d0 100644 --- a/src/northbridge/intel/e7505/raminit.c +++ b/src/northbridge/intel/e7505/raminit.c @@ -11,14 +11,25 @@ /* converted to C 6/2004 yhlu */ + +#include <stdint.h> +#include <device/pci_def.h> +#include <arch/io.h> +#include <arch/romcc_io.h> +#include <arch/cpu.h> +#include <stdlib.h> +#include <console/console.h> + #include <cpu/x86/mtrr.h> #include <cpu/x86/cache.h> #include <cpu/x86/msr.h> #include <assert.h> #include <spd.h> #include <sdram_mode.h> -#include <stdlib.h> + +#include "raminit.h" #include "e7505.h" +#include "debug.h" /*----------------------------------------------------------------------------- Definitions: @@ -1899,7 +1910,7 @@ void e7505_mch_done(const struct mem_controller *memctrl) DUMPNORTH(); } -static int bios_reset_detected(void) +int e7505_mch_is_ready(void) { uint32_t dword = pci_read_config32(MCHDEV, DRC); return !!(dword & DRC_DONE); diff --git a/src/northbridge/intel/e7505/raminit.h b/src/northbridge/intel/e7505/raminit.h index a38d722..8eb4990 100644 --- a/src/northbridge/intel/e7505/raminit.h +++ b/src/northbridge/intel/e7505/raminit.h @@ -18,5 +18,10 @@ struct mem_controller { void e7505_mch_init(const struct mem_controller *memctrl); void e7505_mch_scrub_ecc(unsigned long ret_addr); void e7505_mch_done(const struct mem_controller *memctrl); +int e7505_mch_is_ready(void); + + +/* Mainboard exports this. */ +int spd_read_byte(unsigned device, unsigned address); #endif /* RAMINIT_H */

1 0

Re: [coreboot] [geda-user] Re: Dual SPI Flash adapter
by Oliver Schinagl 18 Apr '12

18 Apr '12

On 04/18/12 15:38, Peter Stuge wrote: > Oliver Schinagl wrote: >>>> It's a mux on the CS/ line of two SPI flash chips. >>> >>> Oliver, I really think you should add a real mux to the PCB, and have >>> that be "remote controlled" by the jumper or mechanical switch. >> >> Why is that recommended? > > The point is to keep the signals on the PCB. Some flash chips are > extremely sensitive to noise even on the chip select line and they > will simply not work if the signals are too far away from the PCB. > Even a jumper could mess it up. Fair enough, makes sense. Well with the solder-bridge, a user could choose. If something like this where to be used and given away, like we saw posted on the coreboot list, this won't be an issue to have included I suppose. > > >> If using a jumper cap, it shouldn't be able to go wrong? Chip1 >> active, none active, chip2 active? To which I can't understand >> why that extra component would help. > > It's not about mistakenly activating both chips, although this is > also an important consideration, since if that happens and one chip > outputs 0 while the other outputs 1 then there's a short circuit > which could kill the output driver of both flash chips. Experienced users should thus use a jumper cap, since accidentally shortening the two outer pins. Others can use the version with the fet switch or an actual switch. > > >> Not that I don't believe you :p I know nothing of this stuff, but >> the goal was to make this board as simple as possible. > > Anything that requires soldering is already significant overhead for > many software people, so replacing two resistors with two other parts > isn't that bad IMO. But I do note that the SSOP package can be tricky > to solder for a beginner, while a 0603 is still much easier, even if > that is starting to get a bit small. True, which is why I like the giving away idea, to be used as give aways for example. > > >>> It's a small board but I think it can be done. The design I used on >> >> I think it would make the board a little bigger again, or actually the >> SOIC8 3306 could fit on top between the connector, so I think it may be >> possible using the same size :) Dunno if routing will be still >> possible :p > > Note that SN74CB3T3306 only comes in SSOP and VSSOP packages. > > SO8 is only available for SN74CBT3306 which is not usable here since > it requires a 5V supply. Absolute Maximum: VCC Supply voltage range (2) –0.5 7 Recommended Operating Conditions: VCC Supply voltage min: 2.3 max: 3.6 It reads in my datasheet, which matches the name of the part: DUAL FET BUS SWITCH 2.5-V/3.3-V LOW-VOLTAGE BUS SWITCH WITH 5-V TOLERANT LEVEL SHIFTER > > My symbol had the package set to SSOP8 already, sorry I didn't send > it separately, but it could also have been copied out of the > schematic. I just saw a big warning box 'part missing' and an empty spot, with 8 unconnected pins. > > >>> the M57SLI (see http://stuge.se/m57sli/ if curious) is shown in the >> >> Now the left schematic is what your motherboard does? The top right is >> what's the smallest component count and the ride side is with an easier >> switch, but higher component count? > > Exactly. The version with the SN74LVC1G14 has the advantage that > because it is only one contact, the jumper could be replaced with or > connected to a pushbutton. This means that there is a kind of dead > man's switch for selecting the backup flash chip, which makes it less > likely to overwrite the wrong flash chip by accident. That would increase the size and complexity of the PCB and schematic, but something to concider indeed. Would also drive price up unfortunatly. > > >> Even though I am sure that the 3306 method would be better, I don't >> understand quite how and why it's needed. > > There are two points satisfied by the bus switch: > > 1. Keep the CS# signal on the PCB at all times > 2. Remote control the switch by connecting a control signal to GND > > Point 1 is important because some flash chips are extremely sensitive > to noise on CS# and while just a jumper on the PCB should be OK > having the jumper there is inspirational for people to put a cable on > it, and that will not work. Using the bus switch the cable can be as > long as needed. With the circuit on the left I tested a 5 meter cable > across the room. > > Point 2 is important because GND is the prefered signal to use in > a switch. The chassis is often (though not always; see wikipedia on > floating ground) connected to ground on the mainboard and if suddenly > the switch cables came loose (e.g. in the schematic I used for the > M57SLI) then it would be really easy to end up with a short circuit > between 3V3 and GND, which is bad since the 3V3 rail is rather > powerful, so it would likely destroy several components on the > mainboard. > > >> Also I haven't found a 3306 on any of my pcb's to scavenge one off >> :) I'd reccon the simpler design would allow for easier adaption? > > See if you can sample the SN74CB3T3306 from TI/National. TI used to > have a vere generous sampling policy. I don't know if it has changed > since National. Advantage of the solderbridge, it can always be broken and this chip added later :D > > >> Finally, I notice you use 100k resistorpacks, but in a previous >> message I recall you mentioning anything between 1k and 10k should >> be good? (I happen to have a 103 resistor pack on a pcb here is my >> wondering :) > > The resistors are not neccessarily critical, but in this case weaker > is better, in order to not disturb the communication more than > neccessary. 10k may also work, but you should test it. Please also > test 4k7 so that you know that you have 2x margin. Well testing (bridge) resistor can always be done once I have finished designing the PCB's ;) IF huge quantities are actually ordered and build, 100k shouldn't be an issue to use. > > > //Peter I'll go on then to routing the PCB according to the new schematic and see if I can fit in.

1 0

New patch to review for coreboot: 639293d Intel e7505: enable ECC scrubbing
by Kyösti Mälkki 18 Apr '12

18 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/905 -gerrit commit 639293da17094e58b9ff95bb2c1b8fb738b01df3 Author: Kyösti Mälkki <kyosti.malkki(a)gmail.com> Date: Wed Apr 18 20:33:35 2012 +0300 Intel e7505: enable ECC scrubbing It takes about 3 seconds to scrub 8GiB DDR266 RAM. After ECC scrub XIP cache is disabled for system stability. There is very little to do in romstage after ECC scrub, especially when RAM debug messages are turned off. So the delay caused by this is hardly noticeable. Cache for complete ROM is re-enabled before ramstage is decompressed, and it has no unstability issues. So the code required to re-enable cache for ROM currently already exists in cache-as-ram_ht.inc. A Kconfig option HW_SCRUBBER enables the scrub to be run on hard reboots and power-ons. Change-Id: Icf27acf73240c06b58091f1229efc0f01cca3f85 Signed-off-by: Kyösti Mälkki <kyosti.malkki(a)gmail.com> --- src/mainboard/aopen/dxplplusu/Kconfig | 1 + src/mainboard/aopen/dxplplusu/romstage.c | 19 ++++- src/northbridge/intel/e7505/Kconfig | 29 ++++++ src/northbridge/intel/e7505/raminit.c | 146 ++++++++++++++++++++++-------- src/northbridge/intel/e7505/raminit.h | 6 +- 5 files changed, 160 insertions(+), 41 deletions(-) diff --git a/src/mainboard/aopen/dxplplusu/Kconfig b/src/mainboard/aopen/dxplplusu/Kconfig index da03491..b6fbf45 100644 --- a/src/mainboard/aopen/dxplplusu/Kconfig +++ b/src/mainboard/aopen/dxplplusu/Kconfig @@ -13,6 +13,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy select UDELAY_TSC select HAVE_ACPI_TABLES select BOARD_ROMSIZE_KB_512 + select HW_SCRUBBER config MAINBOARD_DIR string diff --git a/src/mainboard/aopen/dxplplusu/romstage.c b/src/mainboard/aopen/dxplplusu/romstage.c index 73e445b..ee900e9 100644 --- a/src/mainboard/aopen/dxplplusu/romstage.c +++ b/src/mainboard/aopen/dxplplusu/romstage.c @@ -68,8 +68,23 @@ void main(unsigned long bist) // If this is a warm boot, some initialization can be skipped if (!bios_reset_detected()) { enable_smbus(); - sdram_initialize(ARRAY_SIZE(memctrl), memctrl); + + /* The real MCH initialisation. */ + e7505_mch_init(memctrl); + + /* + * ECC scrub invalidates cache, so all stack in CAR + * is lost. Only return addresses from main() and + * scrub_ecc() are recovered to stack via xmm0-xmm3. + */ +#if CONFIG_HW_SCRUBBER + unsigned long ret_addr = (unsigned long)((unsigned long*)&bist - 1); + e7505_mch_scrub_ecc(ret_addr); +#endif + + /* Hook for post ECC scrub settings and debug. */ + e7505_mch_done(memctrl); } - print_debug("SDRAM is up.\n"); + printk(BIOS_DEBUG, "SDRAM is up.\n"); } diff --git a/src/northbridge/intel/e7505/Kconfig b/src/northbridge/intel/e7505/Kconfig index 578ab86..8ef1a36 100644 --- a/src/northbridge/intel/e7505/Kconfig +++ b/src/northbridge/intel/e7505/Kconfig @@ -1,4 +1,33 @@ +## +## This file is part of the coreboot project. +## +## Copyright (C) 2007-2012 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 +## + config NORTHBRIDGE_INTEL_E7505 bool + +if NORTHBRIDGE_INTEL_E7505 + +config NORTHBRIDGE_SPECIFIC_OPTIONS # dummy + def_bool y select HAVE_DEBUG_RAM_SETUP +config HW_SCRUBBER + bool + default n + +endif diff --git a/src/northbridge/intel/e7505/raminit.c b/src/northbridge/intel/e7505/raminit.c index b06f81d..1d10a8c 100644 --- a/src/northbridge/intel/e7505/raminit.c +++ b/src/northbridge/intel/e7505/raminit.c @@ -11,6 +11,9 @@ /* converted to C 6/2004 yhlu */ +#include <cpu/x86/mtrr.h> +#include <cpu/x86/cache.h> +#include <cpu/x86/msr.h> #include <assert.h> #include <spd.h> #include <sdram_mode.h> @@ -918,44 +921,93 @@ static void configure_e7501_ram_addresses(const struct mem_controller } /** - * If we're configured to use ECC, initialize the SDRAM and clear the E7501's - * ECC error flags. + * Execute ECC full-speed scrub once and leave scrubber disabled. + * + * NOTE: All cache and stack is lost during ECC scrub loop. */ -#ifdef __ROMCC__ -static void initialize_ecc(void) +static void __attribute__((always_inline)) + initialize_ecc(unsigned long ret_addr, unsigned long ret_addr2) { - uint32_t dram_controller_mode; - - /* Test to see if ECC support is enabled */ - dram_controller_mode = pci_read_config32(MCHDEV, DRC); - dram_controller_mode >>= 20; - dram_controller_mode &= 3; - if (dram_controller_mode == 2) { - uint8_t byte; + uint16_t scrubbed = pci_read_config16(MCHDEV, MCHCFGNS) & 0x08; + if (!scrubbed) { RAM_DEBUG_MESSAGE("Initializing ECC state...\n"); - pci_write_config8(MCHDEV, MCHCFGNS, 0x01); - // Wait for scrub cycle to complete + /* ECC scrub flushes cache-lines and stack, need to + * store return address from romstage.c:main(). + */ + asm volatile( + "movd %0, %%xmm0;" + "movd (%0), %%xmm1;" + "movd %1, %%xmm2;" + "movd (%1), %%xmm3;" + :: "r" (ret_addr), "r" (ret_addr2) : + ); + + /* NOTE: All cache is lost during this loop. + * Make sure PCI access does not use stack. + */ + + pci_write_config16(MCHDEV, MCHCFGNS, 0x01); do { - byte = - pci_read_config8(MCHDEV, MCHCFGNS); - } while ((byte & 0x08) == 0); + scrubbed = pci_read_config16(MCHDEV, MCHCFGNS); + } while (! (scrubbed & 0x08)); + pci_write_config16(MCHDEV, MCHCFGNS, (scrubbed & ~0x07) | 0x04); + + /* Some problem remains with XIP cache from ROM, so for + * now, I disable XIP and also invalidate cache (again) + * before the remaining small portion of romstage. + * + * Adding NOPs here has unexpected results, making + * the first do_printk()/vtxprintf() after ECC scrub + * fail midway. Sometimes vtxprintf() dumps strings + * completely but with every 4th (fourth) character as "/". + * + * An inlined dump to console of the same string, + * before vtxprintf() call, is successful. So the + * source string should be completely in cache already. + * + * I need to review this again with CPU microcode + * update applied pre-CAR. + */ + + /* Disable and invalidate all cache. */ + msr_t xip_mtrr = rdmsr(MTRRphysMask_MSR(1)); + xip_mtrr.lo &= ~MTRRphysMaskValid; + invd(); + wrmsr(MTRRphysMask_MSR(1), xip_mtrr); + invd(); - pci_write_config8(MCHDEV, MCHCFGNS, (byte & 0xfc) | 0x04); RAM_DEBUG_MESSAGE("ECC state initialized.\n"); - /* Clear the ECC error bits */ - pci_write_config8(RASDEV, DRAM_FERR, 0x03); - pci_write_config8(RASDEV, DRAM_NERR, 0x03); + /* Recover IP for return from main. */ + asm volatile( + "movd %%xmm0, %%edi;" + "movd %%xmm1, (%%edi);" + "movd %%xmm2, %%edi;" + "movd %%xmm3, (%%edi);" + ::: "edi" + ); - // Clear DRAM Interface error bits (write-one-clear) - pci_write_config32(RASDEV, FERR_GLOBAL, 1 << 18); - pci_write_config32(RASDEV, NERR_GLOBAL, 1 << 18); +#if CONFIG_DEBUG_RAM_SETUP + unsigned int a1, a2; + asm volatile("movd %%xmm2, %%eax;" : "=a" (a1) ::); + asm volatile("movd %%xmm3, %%eax;" : "=a" (a2) ::); + printk(BIOS_DEBUG, "return EIP @ %x = %x\n", a1, a2); + asm volatile("movd %%xmm0, %%eax;" : "=a" (a1) ::); + asm volatile("movd %%xmm1, %%eax;" : "=a" (a2) ::); + printk(BIOS_DEBUG, "return EIP @ %x = %x\n", a1, a2); +#endif } + /* Clear the ECC error bits. */ + pci_write_config8(RASDEV, DRAM_FERR, 0x03); + pci_write_config8(RASDEV, DRAM_NERR, 0x03); + + /* Clear DRAM Interface error bits. */ + pci_write_config32(RASDEV, FERR_GLOBAL, 1 << 18); + pci_write_config32(RASDEV, NERR_GLOBAL, 1 << 18); } -#endif /** * Program the DRAM Timing register (DRT) of the E7501 (except for CAS# @@ -1669,18 +1721,19 @@ static void sdram_enable(const struct mem_controller *ctrl) dram_controller_mode |= (1 << 29); pci_write_config32(MCHDEV, DRC, dram_controller_mode); EXTRA_DELAY; +} -#ifdef __ROMCC__ - /* Problems with cache-as-ram, disable for now */ - initialize_ecc(); -#endif - - dram_controller_mode = pci_read_config32(MCHDEV, DRC); /* FCS_EN */ - dram_controller_mode |= (1 << 17); // NOTE: undocumented reserved bit +/** + * @param ctrl PCI addresses of memory controller functions, and SMBus + * addresses of DIMM slots on the mainboard. + */ +static void sdram_post_ecc(const struct mem_controller *ctrl) +{ + /* Fast CS# Enable. */ + uint32_t dram_controller_mode = pci_read_config32(MCHDEV, DRC); + dram_controller_mode = pci_read_config32(MCHDEV, DRC); + dram_controller_mode |= (1 << 17); pci_write_config32(MCHDEV, DRC, dram_controller_mode); - - RAM_DEBUG_MESSAGE("Northbridge following SDRAM init:\n"); - DUMPNORTH(); } /** @@ -1815,7 +1868,7 @@ static void sdram_set_registers(const struct mem_controller *ctrl) * * */ -void sdram_initialize(int controllers, const struct mem_controller *memctrl) +void e7505_mch_init(const struct mem_controller *memctrl) { RAM_DEBUG_MESSAGE("Northbridge prior to SDRAM init:\n"); DUMPNORTH(); @@ -1825,6 +1878,27 @@ void sdram_initialize(int controllers, const struct mem_controller *memctrl) sdram_enable(memctrl); } +/** + * Scrub and reset error counts for ECC dimms. + * + * NOTE: this will invalidate cache and disable XIP cache for the + * short remaining part of romstage. + */ +void e7505_mch_scrub_ecc(unsigned long ret_addr) +{ + unsigned long ret_addr2 = (unsigned long)((unsigned long*)&ret_addr-1); + if ((pci_read_config32(MCHDEV, DRC)>>20 & 3) == 2) + initialize_ecc(ret_addr, ret_addr2); +} + +void e7505_mch_done(const struct mem_controller *memctrl) +{ + sdram_post_ecc(memctrl); + + RAM_DEBUG_MESSAGE("Northbridge following SDRAM init:\n"); + DUMPNORTH(); +} + static int bios_reset_detected(void) { uint32_t dword = pci_read_config32(MCHDEV, DRC); diff --git a/src/northbridge/intel/e7505/raminit.h b/src/northbridge/intel/e7505/raminit.h index df0e929..a38d722 100644 --- a/src/northbridge/intel/e7505/raminit.h +++ b/src/northbridge/intel/e7505/raminit.h @@ -15,8 +15,8 @@ struct mem_controller { uint16_t channel1[MAX_DIMM_SOCKETS_PER_CHANNEL]; }; -#ifndef __ROMCC__ -void sdram_initialize(int controllers, const struct mem_controller *ctrl); -#endif +void e7505_mch_init(const struct mem_controller *memctrl); +void e7505_mch_scrub_ecc(unsigned long ret_addr); +void e7505_mch_done(const struct mem_controller *memctrl); #endif /* RAMINIT_H */

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
46
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 2012