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)
This gets rid of the somewhat unstructured placement of AMD's
sysinfo structure in CAR.
We used to carve out some CAR space using a Kconfig variable,
and then put sysinfo there manually (by "virtue" of pointer magic).
Now it's a variable with the CAR_GLOBAL qualifier, and build
system magic.
For this, the following steps were done (but must happen together
since the intermediates won't build):
- Add new CAR_GLOBAL sysinfo_car
- point all sysinfo pointers to sysinfo_car instead of GLOBAL_VAR
- remove DCACHE_RAM_GLOBAL_VAR_SIZE
- from CAR setup (no need to reserve the space)
- commented out code (that was commented out for years)
- only copy sizeof(sysinfo) into RAM after ram init, where
before it copied the whole GLOBAL_VAR area.
- from Kconfig
Change-Id: I3cbcccd883ca6751326c8e32afde2eb0c91229ed
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Marc Jones <marcj303@gmail.com>
The use of ramstage.a required the build system to handle some
object files in a special way, which were put in the drivers
class.
These object files didn't provide any symbols that were used
directly (but only via linker magic), and so the linker never
considered them for inclusion.
With ramstage.a gone, we can drop this special class, too.
Change-Id: I6f1369e08d7d12266b506a5597c3a139c5c41a55
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1872
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Each G34 socket has two node. Previous lapic algorithm is written for
the CPU which has one node per socket. I test the code on h8qgi with
4 family 15 CPUs(8 cores per CPU). The topology is:
socket 0 --> Node 0, Node 1
socket 2 --> Node 2, Node 3
socket 1 --> Node 4, Node 5
socket 3 --> Node 6, Node 7
Each node has 4 cores.
I change the code according to this topology.
Change-Id: I45f242e0dfc61bd9b18afc952d7a0ad6a0fc3855
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1659
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
PCIE devices are detected and initialized by the AMD PCIe init functions,
which is in cimx rd890. The parameters are read from devicetree.cb before PCIe init.
Now, all bridges and devices are trained on the device 0.0 enable.
After PCIe init, the PCIe ports with devices are on and the PCIe ports
without devices are off. so resources may be allocated correctly
during the rest of the PCI scan.
But if the devicetree was being used to enable/disable devices after initialization,
the problems would arise. Take a look at the serial log:
do_pci_scan_bridge for PCI: 00:02.0
PCI: pci_scan_bus for bus 01
PCI: pci_scan_bus returning with max=001
do_pci_scan_bridge returns max 1
do_pci_scan_bridge for PCI: 00:03.0
PCI: pci_scan_bus for bus 02
PCI: pci_scan_bus returning with max=002
do_pci_scan_bridge returns max 2
do_pci_scan_bridge for PCI: 00:04.0
PCI: pci_scan_bus for bus 03
PCI: pci_scan_bus returning with max=003
do_pci_scan_bridge returns max 3
PCI bridge 02.0, 03.0 and 04.0 are not inserted devices, but these bridges
are still scanned. This is not correct.
Change-Id: I87dac5f062c6926081970ed0c5f26a7e3f447395
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1640
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
There are four mainboards using agesa family15 code:
Supermicro h8scm and h8qgi, Tyan s8226 and AMD dinar.
All of these boards' PCI domain starts from 0x18.0. Take h8scm as
an example, PCI devices from 0.0 to 0x14.5 is under 0x18.0.
Now, the PCI domain's scan bus function stats from 0.0. This would
result to the PCI devices be scanned twice. Because when the function
run to device 18.0, it would scan from 0.0 again.
This issue would result to 2 problems:
1) PCI device may be assigned two different PCI address.
If this happenned on VGA device, coreboot maybe not load
vga bios correctly.
2) coreboot initializes rd890's IO APIC twice.
So this patch scans from 0x18.0 and could resolve the problems above.
Change-Id: I90fbdf695413fd24c7a5e3e9b426dc7ca6e128b1
Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com>
Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com>
Reviewed-on: http://review.coreboot.org/1639
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Also deletes files not included in build:
src/southbridge/amd/cimx/sb700/chip_name.c
src/southbridge/amd/cimx/sb800/chip_name.c
src/southbridge/amd/cimx/sb900/chip_name.c
Change-Id: I2068e3859157b758ccea0ca91fa47d09a8639361
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1473
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
In commit 6b5eb1cc2d setup of
UMA memory region was moved to happen at a later state and
this broke UMA with RS780 southbridge.
Share the TOP_MEM and UMA settings before any of the PCI or CPU
scanning takes place.
Change-Id: I9cae1fc2948cbccede58d099faf1dfe49e9df303
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1488
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Factor CPU allocation out of AMD northbridge codes. As CPU topology
information is required for generation of certain ACPI tables, make
this code globally available.
For AMDK8 and AMDFAM10 northbridge, there is a possible case of
BSP CPU with lapicid!=0. We do not want to leave the lapic 0 from
devicetree unused, so always use that node for BSP CPU.
Change-Id: I8b1e73ed5b20b314f71dfd69a7b781ac05aea120
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1418
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use of alloc_find_dev() prevents creation of a device duplicates
for device_path and is SMP safe.
Reduce scope of variables to make the code more readable and in
preparation for refactoring the allocation out of northbridge.c.
Change-Id: I153dc1a5cab4f2eae4ab3a57af02841cb1a261c0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1186
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The name is derived directly from the device path.
Change-Id: If2053d14f0e38a5ee0159b47a66d45ff3dff649a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Take a copy of BSP CPU's TOP_MEM and TOP_MEM2 MSRs to be distributed
to AP CPUs and factor out the debugging info from setup_uma_memory().
Change-Id: I1acb4eaa3fe118aee223df1ebff997289f5d3a56
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1387
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The function is a noop for all but amd/serengeti_cheetah.
Change-Id: I09e2e710aa964c2f31e35fcea4f14856cc1e1dca
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1184
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Apply the change
http://review.coreboot.org/1265
to all the AMD northbridge.
Change-Id: Idf3994c1e9ec76cd19db9f740d825cf24059884f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1404
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Apply the change
http://review.coreboot.org/1264
to all the AMD northbridge.
Change-Id: Ied74d6f579d2c0350288e2619d7810f8d44fa574
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1403
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The field device in PCI_ADDRESS only takes 5 bits. So if the device number is
more than 32, it will truncated to 5 bits. Before this patch, other pci devices
will be incorrectly probed as processor node.
Change-Id: I64dcd4f4fda7b7080a9905dce580feb829584b94
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1264
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
UMA region can be determined at any time after the amount
of RAM is known and before the uma_resource() call.
Change-Id: I2a0bf2d3cad55ee70e889c88846f962b7faa0c7e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1379
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Without GFXUMA, variables were not referenced anywhere.
Fail builds on Family10 if GFXUMA is selected, because the northbridge
code does not set UMA base or size.
Change-Id: I15b91cf6241e9a890398eed03824b753828a0a51
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1247
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The code in rs690 or rs780 is always used with K8 or AMDFAM10
northbridge. Without GFXUMA, both of these set the same static value
indirectly using the variable uma_memory_base.
Make the register setting with immediate value, to remove the obscure
use of variable uma_memory_base.
Change-Id: I5354684457a76e73013b4e34a4538a6d122eee8d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1246
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
I dont known if missed something, but why an extra 0x100 was added to limit?
My board would get the wrong memory table entry 7f000000-7fffffff as RAM, which
is higher than TOM.
coreboot memory table:
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000c0000-000000005e13efff: RAM
3. 000000005e13f000-000000005effffff: CONFIGURATION TABLES
4. 000000005f000000-000000007effffff: RESERVED
5. 000000007f000000-000000007fffffff: RAM
6. 00000000a0000000-00000000afffffff: RESERVED
Ronald G. Minnich:
I think someone who wrote the code was trying to round up the
next 0x100 boundary and did it incorrectly.
Here is code that would do it correctly:
limitk = ((resource_t)((d.mask + 0x00000ff) & 0x1fffff00)) << 9 ;
Zheng:
Plus 0xFF is correct, but the d.mask take bit 0 as enable it.
This bit should be clear when we try to calculate the limitk.
Change-Id: I3848ed5f23001e5bd61a19833650fe13df26eef3
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1265
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Our driver infrastructure became more flexible recently.
Make use of it.
These are the low hanging fruits (files with 5 device
variants or more), but there are still lots of files
with less potential for deduplication.
Change-Id: If6b7be5046581f81485a511b150f99b029b95c3b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1358
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
LX has two values that are usually automatically derived but can
be overridden, that were so far defined in each board's romstage.
These values, along with the toggle to enable override are now
part of LX's Kconfig. For boards that gave values but requested
autogeneration, the values are removed.
Further improvements: Figure out the various fields in PLLMSRlo
and make them sensible Kconfig options (instead of the hex value
it is now)
Change-Id: I8a17c89e4a3cb1b52aaceef645955ab7817b482d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2048 * ONE_MB will cause warning,
src/northbridge/amd/agesa/family15tn/northbridge.c:667:50: warning: integer overflow in expression [-Woverflow]
I guess it will change the data type to signed integer.
I think the bit shifting is better.
Change-Id: I823f7ead1f7d622bf653cb3bf2ae2343f5e76805
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1263
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Set the default location of hudson firmware to 3rdparty.
Move UMA code from mainboard to northbridge.
Change-Id: I11afea0c7fd04aa84a629dc762704c42baf002df
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1241
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It defaults to true, and isn't disabled anywhere in the tree.
I also couldn't think of a case where it's actually useful.
Change-Id: I126a47625d5294f3cfff225629f2a948a83c9b7e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1250
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
One could not pass a device of type APIC to PCI resource functions.
The correct CPU model specific cpu->ops is set at later time in
cpu_initialize().
Change-Id: Ifa274185e4db3080433c1f07e3a48f2b55c0514f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Northbridge code incorrectly adjusted the last cacheable memory
resource to accomodate room for UMA framebuffer. If system had
4GB or more memory that last resource is not below 4GB and not
the one where UMA is located.
There are three consequences:
The last entry in coreboot memory table is reduced by uma_memory_size.
Due the incorrect code in northbridge code state.tomk,
end of last resource below 4GB, had not been adjusted.
Incrementing that by uma_memory_size diverts a region
possibly claimed for MMIO to RAM, as TOP_MEM is written.
Since the UMA framebuffer did not have IORESOURCE_CACHEABLE,
it was ignored from the MTRR setup and not set uncacheable.
The setting of TOP_MEM and TOP_MEM2, as well as all the MTRRs,
should be copied from BSP to all APs instead of deriving the data
separately for each Logical CPU.
Change-Id: I8e69fc8854b776fe9e4fe6ddfb101eba14888939
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1217
Tested-by: build bot (Jenkins)
Reviewed-by: Denis Carikli <GNUtoo@no-log.org>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
These boards had identical UMA code:
amd/dbm690t
amd/pistachio
technexion/tim5690
technexion/tim8690
The ones below had whitespace or debug level change
compared to the one above:
kontron/kt690
siemens/sitemp_g1p1
These boards use AMDFAM10 guidelines in code:
asrock/939a785gmh
amd/mahogany
Change-Id: Id7c3f48035727f5847f2d7c3a6e87a3d15582003
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1210
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Following boards had identical code:
advansus/a785e-i
amd/bimini_fam10
amd/mahogany_fam10
asus/m5a88-v
avalue/eax-785e
gigabyte/ma78gm
iei/kino-780am2-fam10
jetway/pa78vm5
Following boards had identical code:
amd/tilapia_fam10
asus/m4a78-em
asus/m4a785-m
gigabyte/ma785gm
gigabyte/ma785gmt
In between the two, only whitespace difference.
Change-Id: Iaa48cc7b0038ebcc81be49219b4fc87670aa9941
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1209
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Following boards had identical code:
amd/inagua
amd/persimmon
The following had only whitespace or debug level changes
compared to ones above.
amd/union_station
amd/south_station
asrock/e350m1
Change-Id: I11ee46e06e1dd510cba551166189ebcaa144464b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1208
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Use of the uma_memory_base and _size variables is very scattered.
Implementation of setup_uma_memory() will appear in each northbridge.
It should be possible to do this setup entirely in northbridge
code and get rid of the globals in a follow-up.
Change-Id: I07ccd98c55a6bcaa8294ad9704b88d7afb341456
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1204
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Like ram_resource(), but reserved and not cacheable.
Switch all AMD northbridges to use this one.
Change-Id: I88515c6a0f59f80fd8607c390d0d4a2a35d805f2
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/1203
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The wrapper for Trinity. Support S3. Parme is a example board.
Change-Id: Ib4f653b7562694177683e1e1ffdb27ea176aeaab
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/1156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Remove all the repeated sections of code in cbtypes.h and place it
in a common location. Add include dir in vendor code's Makefile.
Change-Id: Ida92c2a7a88e9520b84b0dcbbf37cd5c9f63f798
Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Reviewed-on: http://review.coreboot.org/912
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
Replace #elif (CONFIG_FOO==1) with #elif CONFIG_FOO
find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]1),\1\2,g" {} +
(manual tweak since it hit a false positive)
Replace #elif (CONFIG_FOO==0) with #elif !CONFIG_FOO
find src -type f -exec sed -i "s,\(#.*\)(\(CONFIG_[A-Z0-9_]*\)[[:space:]]*==[[:space:]]0),\1\!\2,g" {} +
Change-Id: I8f4ebf609740dfc53e79d5f1e60f9446364bb07d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/1006
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Martin Roth <martin@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
AMD supplies their video bios for the Family 14h processor line
with Vendor ID: 1002, Device ID: 9802. This rom should work for
Device IDs 9802-9809. This patch maps all those device IDs to
0x9802 so coreboot will be able to load the vbios. If a vbios
rom using the ACTUAL Device ID is loaded, this function will not
be called.
This file should contain of all Family 14h Graphics PCI IDs so
that they don't need to be overridden on a per mainboard basis.
Change-Id: If3d4a744b3c400dea9444a61f05382af2b2d0237
Signed-off-by: Martin L Roth <martin@se-eng.com>
Reviewed-on: http://review.coreboot.org/955
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Marc Jones <marcj303@gmail.com>
1. Move the Stack to high memory.
2. Restore the MTRR before Coreboot jump to the wakeup vector.
Change-Id: I9872e02fcd7eed98e7f630aa29ece810ac32d55a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/623
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The Fam15 northbridge.c had hardcoded the CBMEM size. It should use
the one in cbmem.h instead.
Change-Id: I8a00e05884bdb1d1a4a012433b0adfbb9eb22983
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/796
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The Fam12 northbridge.c had hardcoded the CBMEM size. It should use
the one in cbmem.h instead.
Change-Id: I1eca18e21fa59ae32e802d8452e42e8b7a3575cf
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/795
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
The Fam10 northbridge.c had hardcoded the CBMEM size. It should use
the one in cbmem.h instead.
Change-Id: Id6c4128d8f5f6a417f83daa3a39b2bfc8e810f8a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/794
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marcj303@gmail.com>
