GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
coreboot-kgpe-d16/src/southbridge/intel/i82371eb/acpi_tables.c

64 lines
1.7 KiB
C
Raw Normal View History

After finding the missing bit poweroff works now. I cleaned up the patch and moved most of the dsdt.dsl and acpi_tables.c into the southbrige/northbridge directory. Updated patch should fix abuild error and incorporates suggestions on irc by uwe (thanks for the comments). Thanks to Idwer Vollering <vidwer@gmail.com> for the original patch. Tested: Linux (poweroff, powerbutton event) XP (poweroff, powerbutton event) Abuild-tested Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6127 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-27 10:40:16 +01:00
/*
* This file is part of the coreboot project.
*
* Copyright (C) 2004 Stefan Reinauer <stepan@openbios.org>
* Copyright (C) 2005 Nick Barker <nick.barker9@btinternet.com>
* Copyright (C) 2007 Rudolf Marek <r.marek@assembler.cz>
*
* 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.
*/
#include <console/console.h>
#include <string.h>
#include <arch/acpi.h>
#include <arch/acpigen.h>
#include <arch/smp/mpspec.h>
#include <device/device.h>
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
#include "i82371eb.h"
After finding the missing bit poweroff works now. I cleaned up the patch and moved most of the dsdt.dsl and acpi_tables.c into the southbrige/northbridge directory. Updated patch should fix abuild error and incorporates suggestions on irc by uwe (thanks for the comments). Thanks to Idwer Vollering <vidwer@gmail.com> for the original patch. Tested: Linux (poweroff, powerbutton event) XP (poweroff, powerbutton event) Abuild-tested Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6127 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-27 10:40:16 +01:00
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
static int determine_total_number_of_cores(void)
{
sb/intel/i82371eb: Get rid of device_t Use of device_t has been abandoned in ramstage. Change-Id: Ie366a49045940747eb5cc1e38316cce31c5774cb Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26251 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-05-13 13:25:13 +02:00
struct device *cpu;
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
int count = 0;
src/southbridge: Code formating Change-Id: Icfc35b73bacb60b1f21e71e70ad4418ec3e644f6 Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/16291 Reviewed-by: Martin Roth <martinroth@google.com> Tested-by: build bot (Jenkins)
2016-08-31 19:22:16 +02:00
for (cpu = all_devices; cpu; cpu = cpu->next) {
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
if ((cpu->path.type != DEVICE_PATH_APIC) ||
sconfig: rename lapic_cluster -> cpu_cluster The name lapic_cluster is a bit misleading, since the construct is not local APIC specific by concept. As implementations and hardware change, be more generic about our naming. This will allow us to support non-x86 systems without adding new keywords. Change-Id: Icd7f5fcf6f54d242eabb5e14ee151eec8d6cceb1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/2377 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-02-13 00:20:54 +01:00
(cpu->bus->dev->path.type != DEVICE_PATH_CPU_CLUSTER)) {
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
continue;
}
if (!cpu->enabled) {
continue;
}
count++;
}
return count;
}
sb/intel/i82371eb: Get rid of device_t Use of device_t has been abandoned in ramstage. Change-Id: Ie366a49045940747eb5cc1e38316cce31c5774cb Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/26251 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-05-13 13:25:13 +02:00
void generate_cpu_entries(struct device *device)
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
{
int cpu, pcontrol_blk=DEFAULT_PMBASE+PCNTRL, plen=6;
int numcpus = determine_total_number_of_cores();
printk(BIOS_DEBUG, "Found %d CPU(s).\n", numcpus);
/* without the outer scope, furhter ssdt addition will end up
* within the processor statement */
i82371eb & qemu: Move to per-device ACPI. This one is special because qemu is really far from anything real but shares some common features. Change-Id: Ia1631611724a074780e1fece50166730b2ee94ae Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6939 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-01 22:18:01 +02:00
acpigen_write_scope("\\_PR");
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
for (cpu=0; cpu < numcpus; cpu++) {
i82371eb & qemu: Move to per-device ACPI. This one is special because qemu is really far from anything real but shares some common features. Change-Id: Ia1631611724a074780e1fece50166730b2ee94ae Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6939 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-01 22:18:01 +02:00
acpigen_write_processor(cpu, pcontrol_blk, plen);
acpigen_pop_len();
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
}
i82371eb & qemu: Move to per-device ACPI. This one is special because qemu is really far from anything real but shares some common features. Change-Id: Ia1631611724a074780e1fece50166730b2ee94ae Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/6939 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-09-01 22:18:01 +02:00
acpigen_pop_len();
Tobias Diedrich wrote: > Definitively a iasl problem, it can't even disassemble it's own > output back to something equivalent to the input file. > It seems to be generating Bytecode for the Add where it shouldn't. Here is a solution using the SSDT. Unfortunately iasl does not resolve simple arithmetic at compile time, so we can not use Add(DEFAULT_PMBASE, PCNTRL) in the Processor statement. This patch instead dynamically generates the processor statement. I can't use the speedstep generate_cpu_entries() directly since the cpu doesn't support speedstep. For now the code is in the southbridge directory, but maybe it should go into cpu/intel/ somewhere. IIRC notebook cpus of the era can already have speedstep, so it would probably be possible to pair the i82371eb with a speedstep-capable cpu... Also, I don't know if multiprocessor boards (abit bp6?) would need to be handled differently. Abuild-tested. Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Peter Stuge <peter@stuge.se> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6153 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-12-08 22:40:12 +01:00
}
i82371eb: Remove weak functions Change-Id: I593f7745f79e7b5dd0f2f0acb7eb6e1b629fc6ca Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/7376 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-11-09 16:15:00 +01:00
unsigned long acpi_fill_mcfg(unsigned long current)
After finding the missing bit poweroff works now. I cleaned up the patch and moved most of the dsdt.dsl and acpi_tables.c into the southbrige/northbridge directory. Updated patch should fix abuild error and incorporates suggestions on irc by uwe (thanks for the comments). Thanks to Idwer Vollering <vidwer@gmail.com> for the original patch. Tested: Linux (poweroff, powerbutton event) XP (poweroff, powerbutton event) Abuild-tested Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Acked-by: Stefan Reinauer <stepan@coreboot.org> git-svn-id: svn://svn.coreboot.org/coreboot/trunk@6127 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
2010-11-27 10:40:16 +01:00
{
/* chipset doesn't have mmconfig */
return current;
}
Reference in a new issue Copy permalink