that have one.
Can we get rid of ap_romstage.c completely? It sounds like the wrong thing to
do.
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5278 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
pci_read_config32 overwrites the real value, use another variable for that.
Signed-off-by: Maximilian Thuermer <maximilian.thuermer@ziti.uni-heidelberg.de>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5277 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Joseph Smith <joe@settoplinux.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5276 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Joseph Smith <joe@settoplinux.org>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5275 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Interesting enough, console_printk was only used in a single place and
duplicated a large part of console.h which is included in the same place.
Thus, just drop console_printk.c and we're one down with console complexity
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5274 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Joseph Smith <joe@settoplinux.org>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5270 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Some other random warnings.
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5268 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Stefan Reinauer <stepan@coresystems.de>
Acked-by: Ronald G. Minnich <rminnich@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5266 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
CONFIG_CAR_FAM10 was renamed some time ago to
CONFIG_NORTHBRIDGE_AMD_AMDFAM10, and l3Cache() is actually defined as
l3_cache().
Signed-off-by: Ed Swierk <eswierk@aristanetworks.com>
Acked-by: Marc Jones <marcj303@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5262 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
memset(addr, value, size), right?
It is an obvious bug created at r5201. I am wondering
why it doesnt trouble you. I took a quick look at other
files and didnt find other calling error.
Trailing white spaces are also deleted.
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5261 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
1. Add some more prototypes to lib.h
2. Include console.h when not using romcc
3. Eliminate an unused function
4. Set a default for SSE2, since it is just for ramtest performance
Signed-off-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Patrick Georgi <patrick.georgi@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5260 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
better readability.
Also remove failover.c files in mainboards, as they're
not used anymore (and useless, too)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5258 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
romstage.c like r5255 did for failover/fallback/normal
mainboards.
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Myles Watson <mylesgw@gmail.com>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5257 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
romstage.c. That's newconfig stuff.
1. In failover_process(), I removed the fallback/normal selection logic
and kept the remaining hardware init in. The if-clauses' conditions are
reverted to match.
Remove #if failover||fallback guard.
2. Change cache_as_ram_main() to first call failover_process, then
real_main unconditionally.
3. Move failover_process's code to the beginning of real_main, remove
failover_process and its call in cache_as_ram_main.
4. Remove cache_as_ram_main, rename real_main to cache_as_ram_main (same
arguments, so no problem with that)
Signed-off-by: Patrick Georgi <patrick.georgi@coresystems.de>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5255 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Boot Tested (bootlog attached)
Signed-off-by: Joseph Smith <joe@settoplinux.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5244 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
area.
CONFIG_GFXUMA is used in src/cpu/x86/mtrr/mtrr.c which is called by the cpu.
Attached is a revised patch which works well.
Signed-off-by: Joseph Smith <joe@settoplinux.org>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
See boot snips below:
Root Device assign_resources, bus 0 link: 0
8MB IGD UMA
Available memory: 581632KB
PCI_DOMAIN: 0000 assign_resources, bus 0 link: 0
----------------------------
Adding high table area
Adding UMA memory area
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 0000000000100000-00000000237effff: RAM
3. 00000000237f0000-00000000237fffff: CONFIGURATION TABLES
4. 0000000023800000-0000000023ffffff: RESERVED
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5243 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
otherwise it will keeps reboot. The comment was also added in
detail to make less confusing when we debug SB600/SB700.
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5240 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
This patch implements a full SDRAM buffer strength programming algorithm in
set_dram_buffer_strength(), checked against my P2B-LS factory BIOS. With this
in place, I now have 133MHz (!) stability with three 256MB PC133 modules, and
can boot Fedora 11 all the way to the init daemon (actually upstart, but that's
another story). Not to login prompt yet. We'll find out why later.
This again assumes a 4-DIMM board because that's all I have. I need someone
with a 3-DIMM board to test it.
As a bonus, there's a big comment block within that illustrates the algorithm.
:-)
Signed-off-by: Keith Hui <buurin@gmail.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5238 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Acked-by: Stefan Reinauer <stepan@coresystems.de>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5230 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Stefan Reinauer