stddef.h should be fairly generic across all platforms we'd want to
support, so let's move it to generic code.
Change-Id: I580c9c9b54f62fadd9ea97115933e16ea0b13ada
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2007
Tested-by: build bot (Jenkins)
Instead of adding regparm(0) to each assembler function called
by coreboot, add an asmlinkage macro (like the Linux kernel does)
that can be different per architecture (and that is empty on ARM
right now)
Change-Id: I7ad10c463f6c552f1201f77ae24ed354ac48e2d9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1973
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
to match src/include/device
Change-Id: I5d0e5b4361c34881a3b81347aac48738cb5b9af0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1960
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Change allows to override default bootblock_mainboard_init() with
mainboard-specific code.
If the default bootblock_mainboard_init() handler is replaced, with
one from file BOOTBLOCK_MAINBOARD_INIT, one needs to take care the
replacement calls all the necessary bootblock_x_init() functions.
Change-Id: Ie8c667cdba7cafe9ed2d4b19ab2bd21d941ad4ca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1845
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Makes it a bit easier to implement mainboard-specific behaviour
while executing the bootblock.
Change-Id: I04e87f89efb4fad1c0e20b62ea6a50329a286205
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1844
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As we move to supporting other systems we need to get rid of assembly
where we can. The log2 function in src/lib is identical to the assembly
one (tested for all 32-bit signed integers :-) and takes about 10 ns
to run as opposed to 5ns for the non-portable assembly version. While speed
is good, I think we can spare the 15 ns or so we add to boot time
by using the C version only.
Change-Id: Icafa565eae282c85fa5fc01b3bd1f110cd9aaa91
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1928
Tested-by: build bot (Jenkins)
- Optionally override FSB clock detection in generic
LAPIC code with constant value.
- Override on AMD Model fxx, 10xxx, agesa CPUs with 200MHz
- compile LAPIC code for romstage, too
- Remove #include ".../apic_timer.c" in AMD based mainboards
- Remove custom udelay implementation from intel northbridges' romstages
Future work:
- remove the compile time special case
(requires some cpuid based switching)
- drop northbridge udelay implementations (i945, i5000) if
not required anymore (eg. can SMM use the LAPIC timer?)
Change-Id: I25bacaa2163f5e96ab7f3eaf1994ab6899eff054
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1618
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This ensures that there's only one disable/enable cycle for
the entire rewrite instead for every single byte.
Change-Id: Ic06e6dcb08976d158ff784660838c0fbad875176
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1869
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
intel_irq_routing_table is a local structure that should not be used
globally, because it might not be there on all mainboards.
Instead, the API has to be corrected to allow passing a PIRQ table in
where needed.
Change-Id: Icf08928b67727a366639b648bf6aac8e1a87e765
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1862
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
YABEL's version of mainboard_interrupt_handlers() was hidden behind an
inline stub. This fixes it.
Change-Id: Ie53424a8ce074e93a720c0ef94cb39994cacd023
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The SMM GNVS pointer is normally updated only when the
ACPI tables are created, which does not happen in the
resume path.
In order to restore this pointer it needs to be available
at resume time. The method used to locate it at creation
time cannot be used again as that magic signature is
overwritten with the address itself. So a new CBMEM ID
is added to store the 32bit address so it can be found
again easily.
A new function is defined to save this pointer in CBMEM
which needs to be called when the ACPI tables are created
in each mainboard when write_acpi_tables() is called.
The cpu_index variable had to be renamed due to a conflict
when cpu/cpu.h is added for the smm_setup_structures()
prototype.
Change-Id: Ic764ff54525e12b617c1dd8d6a3e5c4f547c3e6b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1765
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This addition is in support of future multicore support in
coreboot. It also will allow us to remove some asssembly code.
The CPU "index" -- i.e., its order in the sequence in which
cores are brought up, NOT its APIC id -- is passed into the
secondary start. We modify the function to specify regparm(0).
We also take this opportunity to do some cleanup:
indexes become unsigned ints, not unsigned longs, for example.
Build and boot on a multicore system, with pcserial enabled.
Capture the output. Observe that the messages
Initializing CPU #0
Initializing CPU #1
Initializing CPU #2
Initializing CPU #3
appear exactly as they do prior to this change.
Change-Id: I5854d8d957c414f75fdd63fb017d2249330f955d
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/1820
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The currently encoded register constraints fails compilation
for SMM code or any code that compiles with -fPIC. The reason
is that the ebx register is used for GOT base register.
I don't believe the comment eluding to register constraints for AMD
processors still applies. Therefore remove mmio_conf.h, and use the
mmio methods in io.h.
Change-Id: I391e5c2088ebc760b3a6ed6c37b65bbecab40a5c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1801
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some of the modules use their own rolled pci_or_configX functions.
Therefore, make them first class so everyone can use them without
copying them.
Change-Id: I9a4d3364c832548dbfe18139c27cce2d60c3316d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/1797
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This will use 3 bytes of CMOS to keep track of the POST
code for the current boot while also leaving a record of
the previous boot.
The active bank is switched early in the bootblock.
Test:
1) clear cmos
2) reboot
3) use "mosys nvram dump" to verify that the first byte
contains 0x80 and the second byte contains 0xF8
4) powerd_suspend and then resume
5) use "mosys nvram dump" to verify that the first byte
contains 0x81 and the second byte contains 0xFD
Change-Id: I1ee6bb2dac053018f3042ab5a0b26c435dbfd151
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1743
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Adds lowlevel handling of DMAR tables for use by mainboards'
ACPI code. Not much automagic (yet).
Change-Id: Ia86e950dfcc5b9994202ec0e2f6d9a2912c74ad8
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1654
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is in preparation for sharing interrupt handlers
between YABEL and x86emu.
Change-Id: Iff92c1d899b8ada20972731944341805a49b6326
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1560
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
pirq_routing_irqs assumed that only four links are available for PIRQ
routing, INTA to INTD. Some chipsets provide more, up to INTH.
When pirq_routing_irqs found a link number greater than 4 in the pirq table,
it would not assign that IRQ. This is a shame, as it limits the flexibility
of routing IRQs.
Make the maximum number of links a Kconfig variable, and modify the code to
respect it. This works beatifully on the VX900, which provides 8 routable
interrupts.
While we're at it, also refactor pirq_routing_irqs, and add some much
needed comments.
Rename pirq_routing_irqs to pirq_route_irqs to demistify the role of this
function.
The copyrights added were determined from git log filename.
Change-Id: I4b565315404c65b871406f616474e2cc9e6e013e
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/1482
Tested-by: build bot (Jenkins)
Adding ranges directly into coreboot memory table raised issues
as those methods bypassed the MTRR setup. Such regions are now
added as resources, so declare the functions again as static.
Change-Id: If78613da40eabc5c99c49dbe2d6047cb22a71b69
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1415
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
These existed to provide a hook to add reserved memory regions
in the coreboot memory table. Reserved memory are now
added as resources.
Change-Id: I9f83df33845cfa6973b018a51cf9444dbf0f8667
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1414
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
We thought about two ways to do this change. The way we decided to try
was to
1. drop all ops from devices in romstage
2. constify all devices in romstage (make them read-only) so we can
compile static.c into romstage
3. the device tree "devices" can be used to read configuration from
the device tree (and nothing else, really)
4. the device tree devices are accessed through struct device * in
romstage only. device_t stays the typedef to int in romstage
5. Use the same static.c file in ramstage and romstage
We declare structs as follows:
ROMSTAGE_CONST struct bus dev_root_links[];
ROMSTAGE_CONST is const in romstage and empty in ramstage; This
forces all of the device tree into the text area.
So a struct looks like this:
static ROMSTAGE_CONST struct device _dev21 = {
#ifndef __PRE_RAM__
.ops = 0,
#endif
.bus = &_dev7_links[0],
.path = {.type=DEVICE_PATH_PCI,{.pci={ .devfn = PCI_DEVFN(0x1c,3)}}},
.enabled = 0,
.on_mainboard = 1,
.subsystem_vendor = 0x1ae0,
.subsystem_device = 0xc000,
.link_list = NULL,
.sibling = &_dev22,
#ifndef __PRE_RAM__
.chip_ops = &southbridge_intel_bd82x6x_ops,
#endif
.chip_info = &southbridge_intel_bd82x6x_info_10,
.next=&_dev22
};
Change-Id: I722454d8d3c40baf7df989f5a6891f6ba7db5727
Signed-off-by: Ronald G. Minnich <rminnich@chromium.org>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1398
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This reverts commit 042c1461fb.
It turned out that sending IPIs via broadcast doesn't work on
Sandybridge. We tried to come up with a solution, but didn't
found any so far. So revert the code for now until we have
a working solution.
Change-Id: I7dd1cba5a4c1e4b0af366b20e8263b1f6f4b9714
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1381
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The existing NVS variable for PPCM will be used to
select a dynamic max P-state.
By itself this does not change existing behavior because
the NVS PPCM variable is initialized to zero.
PPCM can be tested by building and booting a modified BIOS
that sets gnvs->ppcm to a value greater than 1 and checking
from the OS that the P-state is limited to that value.
Change-Id: Ia7b3bbc6b84c1aa42349bb236abee5cc92486561
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/1341
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
coreboot used to pass some information to u-boot in the coreboot table
and other information in a modified flat device tree. Since the FDT code
was never upstreamed and removed from our tree, u-boot was changed to
get the information it needs from the coreboot table alone. However,
in the process of this change only the vboot shared data structure was
passed on by coreboot, so when u-boot tried to update the ChromeOS
specific ACPI entries, it would accidently overwrite the vboot data.
This patch passes on the ChromeOS specific ACPI data structure instead
of the vboot shared data. Another change to u-boot will teach it how
to get to the vboot shared data from there.
Change-Id: Ifbb64eafc0d9967887b4cdeebf97d0c4ce019290
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1282
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This include file needs to be prevented from being included multiple
times.
Change-Id: I42e0cbe38d332b919f22e331eaf7a0251929e1dc
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/1293
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
PCI Type 2 config was a strange and never-used config mechanism.
It is unlikely that in the 13 years of coreboot's existence that
type 2 was ever used; it just made life complicated for everyone.
It lived long enough in coreboot to be replaced by mmioconf.
Prior to making the device tree visible in romstage we want to
get rid of type2.
Delete two files we don't need any more (yay!).
Replace two functions with one: pci_config_default, which returns
a pointer to the default config method. At some future time this
may change to mmio but for now it is old type1 style.
Change-Id: Icc4ccf379a89bfca8be43f305b68ab45d88bf0ab
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/1159
Tested-by: build bot (Jenkins)
Reviewed-by: Sven Schnelle <svens@stackframe.org>
The current code for initializing AP cpus has several shortcomings:
- it assumes APIC IDs are sequential
- it uses only the BSP for determining the AP count, which is bad if
there's more than one physical CPU, and CPUs are of different type
Note that the new code call cpu->ops->init() in parallel, and therefore
some CPU code needs to be changed to address that. One example are old
Intel HT enabled CPUs which can't do microcode update in parallel.
Change-Id: Ic48a1ebab6a7c52aa76765f497268af09fa38c25
Signed-off-by: Sven Schnelle <svens@stackframe.org>
Reviewed-on: http://review.coreboot.org/1139
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
- Add #define to allow the FADT PM Profile to be overridden.
- Change the location of the PMA_CNT_BLOCK_ADDRESS to match
current documentation.
- cst_cnt should be 0 if smi_cmd == 0
- add a couple of default access sizes.
- Add a couple of #define values for unsupported C2 & C3 entries.
- Add PM Profile override value into amd/persimmon platform.
This does not use the #defines in acpi.h so that the files that
include this don't all need to start including acpi.h.
Change-Id: Ib11ef8f9346d42fcf653fae6e2752d62a40a3094
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/1055
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
When compiling coreboot with the latest ChromeOS toolchain, GCC
complains that some printk calls use %zu in connection with size_t
types since it resolves the typedefs to long unsigned int.
The problem is solved by using the GCC built-in __SIZE_TYPE__ if it
exists and define __SIZE_TYPE__ to long unsigned int otherwise.
Change-Id: I449c3d385b5633a05e57204704e981de6e017b86
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1040
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This code fixes the sandybridge C state generation code to work with
the current version of the ACPI code generator.
Change-Id: I56ae1185dc0694c06976236523fdcbe5c1795b01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/950
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It's used by Sandybridge specific C state generation code.
Change-Id: Ia6f1e14e748841a9646fd93d0a18f9e8f2a55e29
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/949
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
... in order to unify the Sandybridge and Lenovo implementations
currently used in the tree.
- use acpi_addr_t in acpigen_write_register()
- use acpi_cstate_t for cstate tables (and fix up
the x60 and t60)
- drop cst_entry from acpigen.h
Change-Id: Icb87418d44d355f607c4a67300107b40f40b3b3f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/943
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
since it is used in CPU specific ACPI generation code
Change-Id: I2559658f43c89dc5b4dc8230dea8847d2802990c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/947
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- Added a union to identify the byte that was reserved in the
Generic Address Structure from ACPI 2.0 to ACPI 2.0b as the
Access Size byte for ACPI 2.0c to ACPI 5.0
- Added various #defines for use in the FADT
- Added a couple of comments for the #endifs
Change-Id: I294ddfd89fcb0ad88bb6e52d911f807d84671e82
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
HEST feature starts from ACPI 4.0.
HEST is one of four kinds of tables of ACPI Platform Error
Interfaces (APEI). In Windows world, APEI is called Windows Hardware
Error Architecture (WHEA).
APEI consists of four separate tables:
1. Error Record Serialization Table (ERST)
2. BOOT Error Record Table (BERT)
3. Hardware Error Source Table (HEST)
4. Error Injection Table (EINJ)
All these 4 tables have the same header as FADT, MADT, etc. They are
pointed by RSDP.
For the HEST, it contains the error source. The types of them are
defined as
type description
1. Machine Check Exception (MCE)
2. Corrected Machine Check (CMC)
3. NMI Error
6. PCI Express Root Port AER
7. PCI Express Device AER
8. PCI Express Bridge AER
9. Generic Hardware Error Source
Error source types 3, 4, and 5 are reserved for legacy reasons and
must not be used.
Currently AMD board only provide part of "Machine Check
Exception (MCE)" & Corrected Machine Check (CMC)". we need to provide
the header of each error source. Other types of Error Sources is in
TODO list.
Only persimmon is tested. Linux can add HEST feature. The dmesg says,
ACPI: HEST 0000000066fe5010 00198 (v03 CORE COREBOOT 00000000 CORE 00000000)
......
HEST: Table parsing has been initialized.
No more message is got.
Windows can boot with this patch. Havent found a way to test it.
Change-Id: I447e7f57b8e8f0433a145a43d0710910afabf00f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/888
Reviewed-by: Peter Stuge <peter@stuge.se>
Tested-by: build bot (Jenkins)
Some places still hardcoded the address instead of using IO_APIC_ADDR.
Change-Id: I3941c1ff62972ce56a5bc466eab7134f901773d3
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/677
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This function can be used outside of the normal CPU setup
Change-Id: I810c63b8aff868a6f69d5b992bea1cfae5a5996b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/868
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
ChromeOS uses two extensions to the coreboot table:
- ChromeOS specific GPIO description for onboard switches
- position of verified boot area in nvram
Change-Id: I8c389feec54c00faf2770aafbfd2223ac9da1362
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/866
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some mainboards (most likely laptops) will need mainboard specific functions
called upon a resume from suspend.
Change-Id: If1518a4b016bba776643adaef0ae64ff49f57e51
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/852
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Since we do not run option roms in normal mode nothing was
initializing the BDA/EBDA and yet Linux depends very much
on it having sane values here. For the most part the kernel
tries to work around this not being initialized, but every
once in awhile (1/300 boots or so) it would end up reading
something that looked sane from BDA but was not and then
it would panic.
In this change the EBDA is unconditionally setup before devices
are initialized. I'm not set on the location in dev_initialize()
but there does not seem to be another place to hook it in so
that it runs just once for ALL platforms regardless of whether
they use option roms or not. (possibly hardwaremain?)
The EBDA setup code has been moved into its own location in
arch/x86/lib/ebda.c so it can be compiled in even if the option
rom code is not.
The low memory size is still set to 1MB which is enough to make
linux happy without having to hook into each mainboard to get a
more appropriate value. The setup_ebda() function takes inputs
so it could be changed for a mainboard if needed.
OLD/BROKEN would read garbage. Examples from different boots:
ebda_addr=0x75e80 lowmem=0x1553400
ebda_addr=0x5e080 lowmem=0x3e51400
ebda_addr=0x7aa80 lowmem=0x2f8a800
NEW/FIXED now reads consistent values:
ebda_addr=0xf6000 lowmem=0x100000
Change-Id: I6cb79f0e3e43cc65f7e5fe98b6cad1a557ccd949
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/769
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This avoids using EBX and instead uses EDI where possible,
and ESI when necessary to get the EBX value out.
This allows me to enable -fpic for SMM TSEG code.
Also add a new CPUID extended function to query with ECX set.
Change-Id: I10dbded3f3ad98a39ba7b53da59af6ca3145e2e5
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: http://review.coreboot.org/764
Tested-by: build bot (Jenkins)
Reviewed-by: Mathias Krause <minipli@googlemail.com>
