summaryrefslogtreecommitdiff
path: root/src/northbridge
AgeCommit message (Collapse)Author
2013-07-10Rename hardwaremain() to main()Stefan Reinauer
... and drop the wrapper on ARMv7 Change-Id: If3ffe953cee9e61d4dcbb38f4e5e2ca74b628ccc Signed-off-by: Stefan Reinauer <reinauer@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3639 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10FUI: reorganize include filesRonald G. Minnich
We've got enough of a handle on this to realize some things: drm_dp_helper.h is by design device and architecture independent i915.h is common to most intel graphics chipsets going back several years i915_reg.h is as well Move these files to src/include/device, and adjust the .c files accordingly. Change-Id: I07512b3695fea0b22949074b467986420783d62a Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3637 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Drop some duplicates of PCI-e config functionsKyösti Mälkki
These are not specific to Intel. Further work needs to be done to combine these with MMCONF_SUPPORT in arch/io.h. Change-Id: Id429db2df8d47433117c21133d80fc985b3e11e4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3502 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-10Fix MMCONF_SUPPORT_DEFAULT for ramstageKyösti Mälkki
Define at one place whether to use IO 0xcf8/0xcfc or MMIO via MMCONF_BASE_ADDRESS for PCI configuration access funtions in ramstage. The implementation of pci_default_config() always returned with pci_cf8_conf1. This means any PCI configuration access that did not target bus 0 used PCI IO config operations, if PCI MMIO config was not explicitly requested. Change-Id: I3b04f570fe88d022cd60dde8bb98e76bd00fe612 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3606 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-07-09fox_wtm2: First step support for coreboot-based graphics startupRonald G. Minnich
This code is the initial version of FUI for haswell and wtm2. The code is simplified from before in many ways. I've gotten rid of the opcode table, because it obscured meaning and I don't think it is needed any more. Register sets, mainly used for reset, are just lines of code -- not many of them. There are a bunch of not-yet-documented registers here; the VBIOS seemed to think they were necessary and testing shows they seem to be right. As a bit of added paranoia, we always include the VBIOS code as our emergency recovery path. You have to run it now anyways, so this is no regression from our current situation; and, if all goes well, in a week (or so), you'll never have to run it again, but like the Force and nose hair, it will be with you always. The code can return in three ways. The first, best way is success: panel is up and the VBIOS need not run. The second mode is that we tried to light up the panel but could not, for some reason, but will return with the panel partly up. In this case, it's ok not to power cycle the panel. The third, worst case, which will NEVER happen, ha ha, is that we have to turn the panel off and wait the required 600ms for it to cycle. Life sucks sometimes. This failure mode is in the 'hang on we're going to fix it' category now that we have ramstage in RW. The Big Goal here is to create something other coreboot ports can use as well. The guys doing the x60 report that the link FUI works, without too many mods, on that chipset, so it seems Intel is keeping things from changing too much over time. Also, again, please note: this and the next 3 versions will ALWAYS fail. The goal is to verify the correctness of the recovery path. The bizarre tab-space formatting in drm_dp_helper.h is from the original, as in i915_reg.h Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3635 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-09FOX_WTM2: First pass at FUI.Ronald G. Minnich
This lights up the display. We don't get graphics but we are missing the gttsetup at this point, so that is no shock. The real shock is that anything works at all. Change-Id: I03fc470334e96878aeb8465044b3cc9c90378735 Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3634 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-07-04intel/i5000: Use MMCONF_SUPPORT_DEFAULTKyösti Mälkki
Change all PCI configuration accesses to MMIO on two boards with i5000 chipset. To enable MMIO style access, add explicit PCI IO config write in the bootblock. Change-Id: I26f1c2da5ae98aeeda78bdcae0fb1e8c711a3586 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3601 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-04Move select MMCONF_SUPPORT under northbridge (fix)Kyösti Mälkki
I missed the board with gm45 when I moved MMCONF_SUPPORT lines. Also, the intel/i3100 does not have MMCONF_SUPPORT implemented even though it was previously selected for intel/eagleheights board. Change-Id: I9c7f6b0a150b4d54288a1e015277b9d98467fca4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3598 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-04intel/i945: Use MMCONF_SUPPORT_DEFAULTKyösti Mälkki
Change all PCI configuration accesses to MMIO on all boards with i945 chipset. To enable MMIO style access, add explicit PCI IO config write in the bootblock. Change-Id: Ia1ab73f1a2dcda87db4eb9b2ffddc6f7b4382b01 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3584 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-07-04intel/sandybridge intel/ivybridge: Use MMCONF_SUPPORT_DEFAULTKyösti Mälkki
Change all PCI configuration accesses to MMIO on all boards with SandyBridge and IvyBridge. To enable MMIO style access, add explicit PCI IO config write in the bootblock. Change-Id: I8f957a80bf57df000897c5a080dd5ff131b1ec0d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3576 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-07-03Move select MMCONF_SUPPORT under northbridgeKyösti Mälkki
Move/remove MMCONF_SUPPORT reference under mainboard Kconfig, as that feature originates from northbridge and cannot be disabled for a single mainboard. Change-Id: I6d6861079876ddddaff90b10f18edb6936e93bd0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3589 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-02Intel GM45, 945, Sandy Bridge: Unify `delay.c` and `udelay.c`Paul Menzel
Use the same indentation, comment placement and spelling of words. Run `indent -linux …`. Change-Id: Id5765c45b28058cdd50ee4c0a1fd9f645ad7f3f8 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3220 Reviewed-by: Nico Huber <nico.huber@secunet.com> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-07-02Make setting MAX_PIRQ_LINKs depend on NORTHBRIDGE_VIA_VX900Dave Frodin
The MAX_PIRQ_LINKS is defined in src/Kconfig with a default value of 4. The src/northbridge/via/vx900/Kconfig also defines MAX_PIRQ_LINKS with a default of 8 and it ends up giving us a value of 8 for non-VIA platforms. Change-Id: Iee1938d38a93ab7c35c8cb6fe9656a92cf3fa21e Signed-off-by: Dave Frodin <dave.frodin@se-eng.com> Reviewed-on: http://review.coreboot.org/3586 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-06-28amd/cimx/rd890/amd.h: Eliminate redefinition of NULLBruce Griffith
This change replaces a redefinition of NULL with the standard definition from <stddef.h> to eliminate a compiler redefinition warning. Change-Id: I441fa569f545c0efb00284b5ee58aa27cb6617ba Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3540 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-28amd/agesa/family15/northbridge.c: Delete unused variableBruce Griffith
This change eliminates an unused variable that causes a build warning. Change-Id: I02487c7dd80d458f562d7afe1827eefcc0fb678b Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/3526 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-06-28Add support to enable/disable builtin GbE (again)Stefan Reinauer
This requires a new system agent binary (v6 / v11 on haswell). Note that the existing system agent binaries are long time obsolete and won't work with current coreboot, so this update is overdue. Change-Id: I48d8649576ca84d2b85ab082ce06f3462e189059 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3568 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-27Revert "Add support to enable/disable builtin GbE"Kyösti Mälkki
This reverts commit d358a506c4230950e34d783bd0187cd200d60691 http://review.coreboot.org/#/c/3514/ comments: The pei_data version changed to 6, so new binaries are needed. However, demand for new binary blob is not referenced with this commit nor is git submodules hash updated. Also the new binary blob almost doubles its size and no longer fits in the allocation sandybridge defines. Change-Id: I84eb70517d5b9278c611fdfa587a71f6ca0f657f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3553 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-25Vortex86EX northbridge.c : Remove Vortex86DX PCI N/B related code.Andrew Wu
6021 is Vortex86DX northbridge PCI device ID, not for Vortex86EX. Change-Id: I9bea799c9033adbcfacc8ad47052280a32f9ee59 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3529 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-25intel/sch: Use MMCONF_BASE_ADDRESSKyösti Mälkki
For iwave/iWRainbowG6 using intel/sch, MMCONF_BASE_ADDRESS was unused and different from hardware setting. Change that to match hardware programming. Change-Id: I3324b7ea0e6f092206d4b6b791476d538e826657 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3507 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-24AMD: Drop empty root_complexKyösti Mälkki
There are no files to build left under AMD nortbridge/x/root_complex directories. For some cases, even the Kconfig file was no longer sourced. Remove all such references and empty files. For devicetree.cb treat component paths with "/root_complex" in them valid even when the directory does not exists. This is because AMD boards us this dummy chip component as the root node in their devicetree.cb. The generated devicetree file static.c remains unchanged. Change-Id: I9278ebb50a83cebbf149b06afb5669899a8e4d0b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3434 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-24AMD Fam15tn: Add support for AGESA runtime allocation in CBMEMRudolf Marek
The IOMMU AGESA needs a reserved scratch space and it wants to allocate the stuff for runtime. So provide a simple allocator for 4 KB CBMEM page. Change-Id: I53bdfcd2cd69f84fbfbc6edea53a051f516c05cc Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/3315 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-24AMD Fam15tn: Add IOMMU BAR allocation to northbridgeRudolf Marek
For IOMMU we need to allocate a 512 KB BAR in a non-standard location. Use the standard allocator for that and limit the BAR to 32-bits to be compatible with older systems. Change-Id: I44414ce6b264b7f1c086a9b1c7ea275a0830205e Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3314 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-22intel/sandybridge: Locate CBMEM TOC early in ramstageKyösti Mälkki
This patch allows the use of migrated CAR_GLOBAL variables from the very beginning of ramstage. Without the patch, CAR_GLOBALS were not available until northbridge set_resources(). Change-Id: Ifd4ab2ed52e07dcbe8c77e2e460dc483323e93c0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3513 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2013-06-22Add support for DMP Vortex86EX PCI northbridge.Andrew Wu
Change-Id: I60675a357f9db430ebb59b17be6d8c92a9cadf43 Signed-off-by: Andrew Wu <arw@dmp.com.tw> Reviewed-on: http://review.coreboot.org/3511 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-21Add support to enable/disable builtin GbEStefan Reinauer
In case we are going to use this in future designs. BUG=none TEST=none BRANCH=none Change-Id: I750addf10e4fe6f8240f8c8262253f8af7027e29 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/55844 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3515 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-20sandybridge: Store MRC cache in CBFSPatrick Georgi
Location is hard-coded right now, which isn't optimal. It must be chip erase block aligned, which might fail on some flash chips (it's 64k aligned which should work for most cases). Change-Id: I6fe0607948c5fab04b9ed565a93e00b96bf44986 Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3497 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-06-13AMD: Kconfig cleanupKyösti Mälkki
Change-Id: I21182eae1d389790c330f27e6a830d91c3ee4eb6 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3433 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-06-10VX900: Use MIN/MAX from stdlib.h instead of redefining themAlexandru Gagniuc
Change-Id: I2dd693b300085493baa65bb652df8d6cce80b63b Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3431 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-06-10VIA VX900: Add minimal ramstage needed to boot linuxAlexandru Gagniuc
This is the minimal code needed to get past ramstage, load SeaBIOS, jump to GRUB2, and boot linux (or load memtest). See individual source files for the status of each individual component. Change-Id: Ib7d5d7593c945f18af2c2fc5e0ae689ba66131a2 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3419 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-10VX900: Add DDR3 initializationAlexandru Gagniuc
The VX900 can be connected to either DDR2 or DDR3. On my board, it is DDR3, hence why there is no and will be no DDR2 code from my side. This is the raminit for DDR3 dimms for the VX900. I like the term "raminit" better than "memory training". This is a device, not a dog. What works and what doesn't is documented in the code. It does not make sense to hide that information in a commit message. Change-Id: Ib2ebc10e6d4d22d0a937fe9e895c17ce79153c88 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3417 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-10VX900: Add support for early romstageAlexandru Gagniuc
Add support for VX900 early initialization up until, but not including raminit. Add the basic infrastructure, add a romstrap table, and functionality to configure the CPU bus and SMBus. This code is necessary and sufficient to prepare us for raminit. Change-Id: Icc9c41e4927b589f17416836f87a6a5843b24aa7 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/3372 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-07i945: Add Display defines for int15h handler.Denis 'GNUtoo' Carikli
Change-Id: I7bc99761c7047e64b4e29c307ad779cec49c17c8 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3306 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-06-05Intel 945: Select LAPIC_MONOTONIC_TIMER for X86EMU_DEBUG_TIMINGSDenis 'GNUtoo' Carikli
X86EMU_DEBUG_TIMING is needed for producing i915tool compatible output. So add its dependencies to the i945’s Kconfig in order to be able to use X86EMU_DEBUG_TIMINGS, which depends on HAVE_MONOTONIC_TIMER which LAPIC_MONOTONIC_TIMER provides/selects. Note that UDELAY_LAPIC is already selected by the Intel CPU. Change-Id: Ie834ebc92e527eb186a92b39341ebd0a08889fb0 Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/3356 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04Move the MARK_GRAPHICS_MEM_WRCOMB to x86 architectureRonald G. Minnich
The MARK_GRAPHICS_MEM_WRCOMB was spreading like a cancer since it was defined in sandybridge. It is really more of an x86 thing however, and we now have three systems that can use it. I considered making this more general, since it technically can apply to PTE-based systems like ARM, and maybe we should. But the 'WRCOMB' moniker is usually closely tied to the x86. Change-Id: I3eb6eb2113843643348a5e18e78c53d113899ff8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3349 Tested-by: build bot (Jenkins)
2013-06-04AMD Northbridge LX: get rid of #include "northbridge/amd/lx/raminit.c"Christian Gmeiner
Change-Id: I249c63646267ebe8dd8e06980aa6367a16fe7297 Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3370 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: convert spd_read_byte() to non-static versionChristian Gmeiner
Change-Id: Ie329606852dfd7109acb694e9a9ff851b023cc63 Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3369 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: rename get_systop() to get_top_of_ram()Christian Gmeiner
Change-Id: I6126d575b8289f76b38858304836e3037200bcdb Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3367 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: include northbridge.h in raminit.cChristian Gmeiner
Change-Id: Ic2f50ae184678637c611757d3391826c1d2719a1 Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3365 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: make GeodeLinkSpeed() function prototype non-staticChristian Gmeiner
Change-Id: Id914be1ae4dac96c51f2640f056af4ce58a248eb Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3364 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: add some missing includesChristian Gmeiner
This commit fixes problems if we build raminit.c for romstage. Change-Id: Ic1380f3635ac28b939fa2a8ce614814012455c44 Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3363 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Northbridge LX: make sdram_* function prototypes non-staticChristian Gmeiner
In order to get rid of the bad #include "northbridge/amd/lx/raminit.c" line we need to do some prepartion steps. This commit is one of them. Change-Id: I33173660bbda8894e7672e41e1b994d254d7ae8a Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> Reviewed-on: http://review.coreboot.org/3362 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-04AMD Fam 15tn: Use all memory on systems with more than 4 GBSiyuan Wang
Take a Parmer board with 4G memory as an example. Use 'cat /proc/meminfo' to check memory, it reads 'MemTotal 3327540kB'. Parmer uses 512M as video memory when it has 4G. 3327540+512*1024 = 3851828(kB), so some memory is lost. When Parmer has 4G memory, TOM2 low is 0x1F000000, TOM2 high is 0x00000001. But in e820 table or coreboot table, the last item is 6: 0000000100000000 - 0000000118000000 = 1 RAM This is not correct, it should be 6: 0000000100000000 - 000000011f000000 = 1 RAM This patch changes the memory layout when TOM2 is set. Change-Id: I4e2d163ae8fe1e65ddc384b520a5112ca067b1d1 Signed-off-by: Siyuan Wang <SiYuan.Wang@amd.com> Signed-off-by: Siyuan Wang <wangsiyuanbuaa@gmail.com> Reviewed-on: http://review.coreboot.org/3366 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-03haswell: fix overflow handling TOUUDAaron Durbin
It's possible that the TOUUD can be set to less than 4GiB. When that is the case the size_k variable is an extremely large value. Instead ensure TOUUD is greater than 4GiB before adding said resources. Change-Id: I456633d6210824e60665281538300fd15656b86d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3352 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-06-03northbridge/amd/amdmct: Use `static const` instead of `const static`Paul Menzel
From ISO C99 standard: »The placement of a storage-class specifier other than at the beginning of the declaration specifiers in a declaration is an obsolescent feature.« Found at <http://www.approxion.com/?p=41>. The following command was used to make the change. $ git grep -l 'const static' src/ | xargs sed -i 's/const static/static const/' As asked by Bruce Griffith, the changes in `src/vendorcode` were reverted as that is what AMD prefers. The same change was done already for AMD Persimmon in the following commit. commit 824e192809e021b3cdee947a44b3a18d276bdb35 Author: Jens Rottmann <JRottmann@LiPPERTembedded.de> Date: Wed Feb 20 21:24:20 2013 +0100 Persimmon: platform_cfg.h: Declare codec arrays as `static const` Reviewed-on: http://review.coreboot.org/2474 Change-Id: I233c83fdc95ea4f83f7296c818547beb52366a3d Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3197 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2013-05-25Intel GM45, 945, SNB: Move `multiply_to_tsc()` to `tsc.h`Ronald G. Minnich
multiply_to_tsc was being copied everywhere, which is bad practice. Put it in the tsc.h include file where it belongs. Delete the copies of it. Per secunet, no copyright notice is needed. This might be a good time to get a copyright notice into tsc.h anyway. Change-Id: Ied0013ad4b1a9e5e2b330614bb867fd806f9a407 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/3242 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-05-23Intel Sandy Bridge: udelay.c: Change comparison from <= to <Paul Menzel
Currently code in `udelay.c` differs between the Intel northbridges GM45, 945 on the one hand and Sandy Bridge on the other hand. The reason for this is that a wrong comparison > was used. The following commit commit 784ffb3db694dd2c964d9a4e1c6657a835b2d141 Author: Sven Schnelle <svens@stackframe.org> Date: Tue Jan 10 12:16:38 2012 +0100 i945: fix tsc udelay() Reviewed-on: http://review.coreboot.org/530 fixed the sign from > to <, whereas Stefan Reinauer changed it from > to <= before adding the Sandy Bridge port in the following commit. commit 00636b0daefc3c499990744226a0e1a316d71731 Author: Stefan Reinauer <stefan.reinauer@coreboot.org> Date: Wed Apr 4 00:08:51 2012 +0200 Add support for Intel Sandybridge CPU (northbridge part) Reviewed-on: http://review.coreboot.org/854 As there are no technical reasons for this difference, unify this between the chipsets. See the discussion of the other patch set in Gerrit [1]. [1] http://review.coreboot.org/#/c/3220/1/src/northbridge/intel/i5000/udelay.c Change-Id: I64f2aa1db114ad2e9f34181c5f3034f6a8414a11 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3259 Tested-by: build bot (Jenkins) Reviewed-by: Nico Huber <nico.huber@secunet.com>
2013-05-22intel/gm45: Add more debug output to read/write trainingNico Huber
Add debug output for the timing values of the edges found during read and write training. Now, output for one DIMM of DDR3-1066 in a roda/rk9 looks like: [...] Lower bound for byte lane 0 on channel 0: 0.0 Upper bound for byte lane 0 on channel 0: 8.4 Final timings for byte lane 0 on channel 0: 4.2 Lower bound for byte lane 1 on channel 0: 0.0 Upper bound for byte lane 1 on channel 0: 10.2 Final timings for byte lane 1 on channel 0: 5.1 Lower bound for byte lane 2 on channel 0: 0.0 Upper bound for byte lane 2 on channel 0: 7.5 Final timings for byte lane 2 on channel 0: 3.6 Lower bound for byte lane 3 on channel 0: 0.0 Upper bound for byte lane 3 on channel 0: 11.4 Final timings for byte lane 3 on channel 0: 5.6 Lower bound for byte lane 4 on channel 0: 0.0 Upper bound for byte lane 4 on channel 0: 9.4 Final timings for byte lane 4 on channel 0: 4.6 Lower bound for byte lane 5 on channel 0: 0.0 Upper bound for byte lane 5 on channel 0: 11.2 Final timings for byte lane 5 on channel 0: 5.5 Lower bound for byte lane 6 on channel 0: 0.0 Upper bound for byte lane 6 on channel 0: 8.4 Final timings for byte lane 6 on channel 0: 4.2 Lower bound for byte lane 7 on channel 0: 0.0 Upper bound for byte lane 7 on channel 0: 10.4 Final timings for byte lane 7 on channel 0: 5.2 Lower bound for group 0 on channel 0: 1.7.5 Upper bound for group 0 on channel 0: 2.2.2 Final timings for group 0 on channel 0: 1.10.7 Lower bound for group 1 on channel 0: 1.6.1 Upper bound for group 1 on channel 0: 2.0.2 Final timings for group 1 on channel 0: 1.9.1 Lower bound for group 2 on channel 0: 2.0.7 Upper bound for group 2 on channel 0: 2.8.1 Final timings for group 2 on channel 0: 2.4.4 Lower bound for group 3 on channel 0: 2.4.7 Upper bound for group 3 on channel 0: 3.0.0 Final timings for group 3 on channel 0: 2.8.3 [...] Final timings are always the average of the two bounds. The last dots separate eights (not decimals) and the middles are elenvenths or twelfths depending on the clock speed (twelfths in this case). Change-Id: Idb7c84b514716c7265b94890c39b7225de7800dc Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3257 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22intel/gm45: Handle overflows during DDR3 write trainingNico Huber
We halted the machine on any overflow during the write training. However, overflows during the search for a good to bad edge are non-fatal, and should be ignored. Change-Id: I45ccbabc214e208974039246d806b0d2ca2fdc03 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3256 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22intel/gm45: Refactor DDR3 write trainingNico Huber
Split some code in individual functions. It's the refactoring part of a bigger change, following... Change-Id: Id19be4588ad8984935040d9bcba4d7c5f2e1114f Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3255 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22intel/gm45: Handle overflows during DDR3 read trainingNico Huber
We halted the machine on any overflow during the read training. However, overflows during the search for a good to bad edge are non-fatal, and should be ignored. Change-Id: I77085840ade25bce955480689c84603334113d1f Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3254 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22intel/gm45: Refactor DDR3 read trainingNico Huber
Split some code in individual functions. It's the refactoring part of a bigger change, following... Change-Id: Ied551a011eaf22f6f8f6db0044de3634134f0b37 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3253 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-22intel/gm45: Fix interpretation of VT-d disable bitNico Huber
When configuring the GTT size for the integrated graphics, the state of VT-d was read wrong. Bit 48 of CAPID0 (D0F0) is set when VT-d is _disabled_. In the log of a VT-d enabled roda/rk9 we have now: [...] VT-d enabled [...] IGD decoded, subtracting 32M UMA and 4M GTT [...] Without this patch, only 2M GTT were reported. Change-Id: I87582c18f4769c2a05be86936d865c0d1fb35966 Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3252 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-05-21intel/i5000: Remove unused copy of udelay.cNico Huber
It's a copy from i945 and looks like not beeing included in a build at all. If you should ever want to use that file for the Intel 5000, please copy it from another chipset like the Intel 945 as it is going to be improved. Change-Id: I5c113bb0b2fed7b93feb3dcb1b5d962e1442963a Reported-by: Ronald G. Minnich <rminnich@gmail.com> Signed-off-by: Nico Huber <nico.huber@secunet.com> Reviewed-on: http://review.coreboot.org/3219 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Sven Schnelle <svens@stackframe.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-10Get rid of a number of __GNUC__ checksStefan Reinauer
In the process of streamlining coreboot code and getting rid of unneeded ifdefs, drop a number of unneeded checks for the GNU C compiler. This also cleans up x86emu/types.h significantly by dropping all the duplicate types in there. Change-Id: I0bf289e149ed02e5170751c101adc335b849a410 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3226 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-10northbridge/intel/i5000/udelay.c: Remove unused header `console.h`Paul Menzel
Nothing from the header `console.h` is needed in `udelay.c`, so do not include it. This header was included since commit »Add Intel i5000 Memory Controller Hub« (17670866) [1]. [1] http://review.coreboot.org/491 Change-Id: Ie136a1b862b55c9471f9293ed616ce27a1d01a50 Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3218 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-10Drop prototype guarding for romccStefan Reinauer
Commit "romcc: Don't fail on function prototypes" (11a7db3b) [1] made romcc not choke on function prototypes anymore. This allows us to get rid of a lot of ifdefs guarding __ROMCC__ . [1] http://review.coreboot.org/2424 Change-Id: Ib1be3b294e5b49f5101f2e02ee1473809109c8ac Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3216 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-08Drop CONFIG_AP_CODE_IN_CARStefan Reinauer
This option has not been enabled on any board and was considered obsolete last time it was touched. If we need the functionality, let's fix this in a generic way instead of a K8 specific way. This was mostly a speedup hack back in the day. Change-Id: Ib1ca248c56a7f6e9d0c986c35d131d5f444de0d8 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3211 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-08hardwaremain: drop boot_complete parameterStefan Reinauer
it has been unused since 9 years or so, hence drop it. Change-Id: I0706feb7b3f2ada8ecb92176a94f6a8df53eaaa1 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/3212 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-05-07haswell: use tsc for udelay()Aaron Durbin
Instead of using the local apic timer for udelay() use the tsc. That way SMM, romstage, and ramstage all use the same delay functionality. Change-Id: I024de5af01eb5de09318e13d0428ee98c132f594 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3169 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-05-01boot: remove cbmem_post_handling()Aaron Durbin
The cbmem_post_handling() function was implemented by 2 chipsets in order to save memory configuration in flash. Convert both of these chipsets to use the boot state machine callbacks to perform the saving of the memory configuration. Change-Id: I697e5c946281b85a71d8533437802d7913135af3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3137 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-18Intel i945: ACPI: Add _OSC methodDenis 'GNUtoo' Carikli
Add the ACPI Operating System Capabilities Method and let the operation system control everything. Commit »AMD Fam14 DSDT: Add OSC method« (00a0e76b) [1] is used as a template. The Lenovo X60 [2] running the Parabola GNU/Linux distribution [3] is used for testing. Before that change: $ dmesg | egrep -e OSC -e ASPM [ 0.108036] pci_root PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM [ 0.108040] pci_root PNP0A08:00: Unable to request _OSC control (_OSC support mask: 0x08) [ 0.118089] ACPI _OSC control for PCIe not granted, disabling ASPM [ 16.874569] e1000e 0000:01:00.0: Disabling ASPM L0s L1 With that change: $ dmesg | egrep -e OSC -e ASPM [ 0.107962] pci_root PNP0A08:00: Requesting ACPI _OSC control (0x1d) [ 0.108003] pci_root PNP0A08:00: ACPI _OSC control (0x1d) granted [ 0.111052] pci 0000:01:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' [ 17.537970] e1000e 0000:01:00.0: Disabling ASPM L0s L1 [1] http://review.coreboot.org/2738 [2] http://www.coreboot.org/Lenovo_x60x [3] https://parabolagnulinux.org/ Change-Id: I1caffa44eea447d553c01caaf431f2db241ea5ea Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/2938 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-16Lenovo ThinkPad X60: Add Native VGA init.Denis 'GNUtoo' Carikli
The code has been taken from the google link mainboard and modified to fit the ThinkPad X60. Change-Id: Ie16e45163acdc651ea46699ecc33055bfd34099c Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> Reviewed-on: http://review.coreboot.org/2998 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-12Revert "siemens/sitemp_g1p1: Make ACPI report the right mmconf region"Nico Huber
This reverts commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5: commit 1fde22c54cacb15493bbde8835ec9e20f1d39bf5 Author: Patrick Georgi <patrick.georgi@secunet.com> Date: Tue Apr 9 15:41:23 2013 +0200 siemens/sitemp_g1p1: Make ACPI report the right mmconf region ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> It sneaked in without it's dependencies and, therefore, broke the build for all amdk8 targets. Paul Menzel already commented on the issue in [1]. It also doesn't look like the dependencies would be pulled soon [2]. [1] http://review.coreboot.org/#/c/3047/ [2] http://review.coreboot.org/#/c/2662/ Change-Id: Ica89563aae4af3f0f35cacfe37fb608782329523 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/3063 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2013-04-11Persimmon/Fam14/SB800 DSDT: Split into common areasMike Loptien
Split the Persimmon DSDT into common code areas. For example, split the Southbridge specific code into the Southbridge directory and CPU specific code into the CPU directory. Also adding the superio.asl file to the Persimmon DSDT tree. This file is empty for the moment but will be necessary in the future. I have also emptied the thermal.asl file in the mainboard directory because it does not seem to perform as intended (fan control does not change when it is brought back into the code base) and it has been inside a '#if 0' statement for a long time. Removing it until it is decided that it is actually necessary. This change was verified in three different ways: 1. Visual comparison of the compiled DSDT pulled from the Persimmon after booting into Linux using the ACPI tools acpidump, acpixtract, and iasl. The comparison was done between the DSDT before and after doing the split work. This test is somewhat difficult considering the expanse of the changes. Blocks of code have been moved, and others changed. 2. Linux logs were dumped before and after the DSDT split. Logs dumped and compared include dmesg and lspci -tv. Neither log changed significantly between the two compare points. 3. The test suite FWTS was run on the Coreboot build both before and after doing the DSDT split with the command 'sudo fwts -b -P -u'. The flag -b specifies all batch jobs, -P specifies all power tests, and -u specifies utilities. Interactive jobs were not run as most of them consist of laptop checks. Again, there were no significant changes between the two endpoints. These tests lead me to believe that there was no change in the functionality of the ACPI tables apart from what is known and expected. This patch is the first of a series of patches to split the DSDT. The ASRock patch was merged before this one and breaks the ASROCK E350M1 build (patch 8d80a3fb: http://review.coreboot.org/#/c/3050/). Please be aware of this dependency when pulling these patches. Other patches that depend on this patch are 'AMD Fam14: Split out the AMD Fam14 DSDT' (http://review.coreboot.org/#/c/3051/) and 'Fam14 DSDT: Also return for unrecognized UUID in _OSC' (http://review.coreboot.org/#/c/3052/) Change-Id: I53ff59909cceb30a08e8eab3d59b30b97c802726 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/3048 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>
2013-04-10siemens/sitemp_g1p1: Make ACPI report the right mmconf regionPatrick Georgi
ACPI reported the entire space between top-of-memory and some (relatively) arbitrary limit as useful for MMIO. Unfortunately the HyperTransport configuration disagreed. Make them match up. Other boards are not affected since they don't report any region for that purpose at all (it seems). Change-Id: I432a679481fd1c271f14ecd6fe74f0b7a15a698e Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/3047 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-04-04AMD GX1: Remove useless copied header file `northbridge.h`Paul Menzel
This was there since the beginning commit d24d6993b6d7bcf7977d74d081e718e1b076d1b0 Author: arch import user (historical) <svn@openbios.org> Date: Wed Jul 6 17:06:46 2005 +0000 Revision: linuxbios@linuxbios.org--devel/freebios--devel--2.0--patch-26 Creator: Hamish Guthrie <hamish@prodigi.ch> Added AMD GX1 northbridge and cs5530 Southbridge but blindly copied from Intel 440 BX and is not used anywhere. Thanks to Idwer Vollering for spotting this. Change-Id: I38b3d3feb25966c3aa382994d323e59c3f3c9e6c Reported-by: Idwer Vollering Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: http://review.coreboot.org/3020 Reviewed-by: Marc Jones <marc.jones@se-eng.com> Tested-by: build bot (Jenkins)
2013-04-03sandybridge: enable ROM cachingAaron Durbin
If ROM caching is selected the sandybridge chipset code will will enable ROM caching after all other CPU threads are brought up. Change-Id: I3a57ba8753678146527ebf9547f5fbbd4f441f43 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3017 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29sandybridge: add option to mark graphics memory write-combining.Aaron Durbin
The graphics memory can be accessed in a faster manner by setting it to write-combing mode. Add an option to enable write-combining for the graphics memory. Change-Id: I7d37fd78906262aabef92c2b4f4cab0e3f7e4f6d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2894 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29haswell: add option to mark graphics memory write-combining.Aaron Durbin
The graphics memory can be accessed in a faster manner by setting it to write-combing mode. Add an option to enable write-combining for the graphics memory. Change-Id: I797fcd9f0dfb074f9e45476773acbfe614eb4b0a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2893 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-29x86: add new mtrr implementationAaron Durbin
The old MTRR code had issues using too many variable MTRRs depending on the physical address space layout dictated by the device resources. This new implementation calculates the default MTRR type by comparing the number of variable MTRRs used for each type. This avoids the need for IORESOURE_UMA_FB because in many of those situations setting the default type to WB frees up the variable MTTRs to set that space to UC. Additionally, it removes the need for IORESOURCE_IGNORE_MTRR becuase the new mtrr uses the memrange library which does merging of resources. Lastly, the sandybridge gma has its speedup optimization removed for the graphics memory by writing a pre-determined MTRR index. That will be fixed in an upcoming patch once write-combining support is added to the resources. Slight differences from previous MTRR code: - The number of reserved OS MTRRs is not a hard limit. It's now advisory as PAT can be used by the OS to setup the regions to the caching policy desired. - The memory types are calculated once by the first CPU to run the code. After that all other CPUs use that value. - CONFIG_CACHE_ROM support was dropped. It will be added back in its own change. A pathological case that was previously fixed by changing vendor code to adjust the IO hole location looked like the following: MTRR: Physical address space: 0x0000000000000000 - 0x00000000000a0000 size 0x000a0000 type 6 0x00000000000a0000 - 0x00000000000c0000 size 0x00020000 type 0 0x00000000000c0000 - 0x00000000ad800000 size 0xad740000 type 6 0x00000000ad800000 - 0x00000000d0000000 size 0x22800000 type 0 0x00000000d0000000 - 0x00000000e0000000 size 0x10000000 type 1 0x00000000e0000000 - 0x0000000100000000 size 0x20000000 type 0 0x0000000100000000 - 0x000000014f600000 size 0x4f600000 type 6 As noted by the output below it's impossible to accomodate those ranges even with 10 variable MTRRS. However, because the code can select WB as the default MTRR type it can be done in 6 MTRRs: MTRR: default type WB/UC MTRR counts: 6/14. MTRR: WB selected as default type. MTRR: 0 base 0x00000000ad800000 mask 0x0000007fff800000 type 0 MTRR: 1 base 0x00000000ae000000 mask 0x0000007ffe000000 type 0 MTRR: 2 base 0x00000000b0000000 mask 0x0000007ff0000000 type 0 MTRR: 3 base 0x00000000c0000000 mask 0x0000007ff0000000 type 0 MTRR: 4 base 0x00000000d0000000 mask 0x0000007ff0000000 type 1 MTRR: 5 base 0x00000000e0000000 mask 0x0000007fe0000000 type 0 Change-Id: Idfcc78d9afef9d44c769a676716aae3ff2bd79de Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2889 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-23resources: introduce reserved_ram_resource()Aaron Durbin
mmio_resource() was previously being used for reserving RAM from the OS by using IORESOURCE_IGNORE_MTRR atrribute. Instead, be more explicit for those uses with reserved_ram_resource(). bad_ram_resource() now calls reserved_ram_resource(). Those resources are marked as cacheable but reserved. The sandybridge and haswell code were relying on the implementation fo the MTRR algorithm's interaction for reserved regions. Instead be explicit about what ranges are MMIO reserved and what are RAM reserved. Change-Id: I1e47026970fb37c0305e4d49a12c98b0cdd1abe5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2886 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22haswell: use dynamic cbmemAaron Durbin
Convert the existing haswell code to support reloctable ramstage to use dynamic cbmem. This patch always selects DYNAMIC_CBMEM as this option is a hard requirement for relocatable ramstage. Aside from converting a few new API calls, a cbmem_top() implementation is added which is defined to be at the begining of the TSEG region. Also, use the dynamic cbmem library for allocating a stack in ram for romstage after CAR is torn down. Utilizing dynamic cbmem does mean that the cmem field in the gnvs chromeos acpi table is now 0. Also, the memconsole driver in the kernel won't be able to find the memconsole because the cbmem structure changed. Change-Id: I7cf98d15b97ad82abacfb36ec37b004ce4605c38 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2850 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-22coreboot: dynamic cbmem requirementAaron Durbin
Dynamic cbmem is now a requirement for relocatable ramstage. This patch replaces the reserve_* fields in the romstage_handoff structure by using the dynamic cbmem library. The haswell code is not moved over in this commit, but it should be safe because there is a hard requirement for DYNAMIC_CBMEM when using a reloctable ramstage. Change-Id: I59ab4552c3ae8c2c3982df458cd81a4a9b712cc2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2849 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22x86: Unify arch/io.h and arch/romcc_io.hStefan Reinauer
Here's the great news: From now on you don't have to worry about hitting the right io.h include anymore. Just forget about romcc_io.h and use io.h instead. This cleanup has a number of advantages, like you don't have to guard device/ includes for SMM and pre RAM anymore. This allows to get rid of a number of ifdefs and will generally make the code more readable and understandable. Potentially in the future some of the code in the io.h __PRE_RAM__ path should move to device.h or other device/ includes instead, but that's another incremental change. Change-Id: I356f06110e2e355e9a5b4b08c132591f36fec7d9 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2872 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell/lynxpoint: Use new PCH/PM helper functionsDuncan Laurie
This makes use of the new functions from pmutil.c that take care of the differences between -H and -LP chipsets. It also adds support for the LynxPoint-LP GPE0 register block and the SMI/SCI routing differences. The FADT is updated to report the new 256 byte GPE0 block on wtm2/wtm2 boards which is too big for the 64bit X_GPE0 address block so that part is zeroed to prevent IASL and the kernel from complaining about a mismatch. This was tested on WTM2. Unfortunately I am still unable to get an SCI delivered from the EC but I suspect that is due to a magic command needed to put the EC in ACPI mode. Instead I verified that all of the power management and GPIO registers were set to expected values. I also tested transitions into S3 and S5 from both the kernel and by pressing the power button at the developer mode screen and they all function as expected. Change-Id: Ice9e798ea5144db228349ce90540745c0780b20a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2816 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: Drop the device ID check in graphics init pathDuncan Laurie
Change-Id: I10c4264d317b5fac02a44f50ed10b457e1865e17 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2809 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: add multipurpose SMM memory regionAaron Durbin
The SMM region is available for multipurpose use before the SMM handler is relocated. Provide a configurable sized region in the TSEG for use before the SMM handler is relocated. This feature is implemented by making the reserved size a Kconfig option. Also make the IED region a Kconfig option as well. Lastly add some sanity checking on the Kconfig options. Change-Id: Idd7fccf925a8787146906ac766b7878845c75935 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2804 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: use s3_resume field in romstage_handoffAaron Durbin
Now that there is a way to disseminate the presence of s3 wake more formally use that instead of hard coded pointers in memory and stashing magic values in device registers. The northbridge code picks up the field's presence in the romstage_handoff structure and sets up the acpi_slp_type variable accordingly. Change-Id: Ida786728ce2950bd64610a99b7ad4f1ca6917a99 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2799 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-21haswell: cbmem_get_table_location() implementationAaron Durbin
Provide the implemenation of cbmem_get_table_location() so that cbmem can be initialized early in ramstage when CONFIG_EARLY_CBMEM_INIT is enabled. The cbmem tables are located just below the TSEG region. Change-Id: Ia160ac6aff583fc52bf403d047529aaa07088085 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2798 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-20haswell: drop memory reservation for sandybridge GPU bugDuncan Laurie
This is not needed in haswell. Change-Id: I23817c2e01be33855f9d5a5e389e8ccb7954c0e2 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2847 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-19AMD Fam15: Add SPD read functions to wrapper codeKimarie Hoot
Change: This is the initial step for moving the AMD F15 & HUDSON1,2,3 SPD-read callout out of the mainboard directories and into the wrapper. The next step is to update the platforms to use this routine in BiosCallouts.c and to delete the code from the mainboard directories. The DIMM addresses should be moved into devicetree.cb. If there are significant differences or reasons that the mainboard needs to override this code, it's perfectly reasonable to keep using the version in the mainboard, but this allows us to remove duplicated code and simplify the mainboard directories. Notes: This started by duplicating what was in Dinar, and was changed to use the devicetree.cb structures. Significant cleanup and magic number reduction was done as well. It is intended that this file will not be included in ramstage as the DIMM init is all done in romstage. This is similar to what was done for Parmer/Thatcher in commit 7fb692bd - http://review.coreboot.org/#/c/2190/ Fam15tn: Move SPD read from mainboards into wrapper Yes, it would make sense to split this into two separate files and move the SMBus initialization and access into the southbridge wrapper. Maybe that can come next. Change-Id: I4e00ada288e1486cf30684403505e475f9093ec2 Signed-off-by: Kimarie Hoot <kimarie.hoot@se-eng.com> Reviewed-on: http://review.coreboot.org/2777 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-18haswell: move call site of save_mrc_data()Aaron Durbin
The save_mrc_data() was previously called conditionally in the raminit code. The save_mrc_data() function was called in the non-S3 wake paths. However, the common romstage_common() code was checking cbmem initialization things on s3 wake. Between the two callers cbmem_initialize() was being called twice in the non-s3 wake paths. Moreover, saving of the mrc data was not allowed when CONFIG_EARLY_CBMEM_INIT wasn't enabled. Therefore, move the save_mrc_data() to romstage_common. It already has the knowledge of the wake path. Also remove the CONFIG_EARLY_CBMEM_INIT requirement from save_mrc_data() as well as the call to cbmem_initialize(). Change-Id: I7f0e4d752c92d9d5eedb8fa56133ec190caf77da Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2756 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: remove unused sys_info structureAaron Durbin
This structure is not used nor the variable being instantiated on the stack. Remove them. Change-Id: If3abe2dd77104eff49665dd33570b07179bf34f5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2753 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: adjust CAR usageAaron Durbin
It was found that the Haswell reference code was smashing through the stack into the reference code's heap implementation. The reason for this is because our current CAR allocation is too small. Moreover there are quite a few things to coordinate between 2 code bases to get correct. This commit separates the CAR into 2 parts: 1. MRC CAR usage. 2. Coreboot CAR usage. Pointers from one region can be passed between the 2 modules, but one should not be able to affect the others as checking has been put into place in both modules. The CAR size has effectively been doubled from 0x20000 (128 KiB) to 0x40000 (256KiB). Not all of that increase was needed, but enforcing a power of 2 size only utilizes 1 MTRR. Old CAR layout with a single contiguous stack with the region starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | MRC global variables | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ | ROM stage stack | | | | | +---------------------------------------+ | MRC Heap 30000 bytes | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 There was some hard coded offsets in the reference code wrapper to start the heap past the console buffer. Even with this commit the console can smash into the following region depending on what size CONFIG_CONSOLE_CAR_BUFFER_SIZE is. As noted above This change splits the CAR region into 2 parts starting at CONFIG_DCACHE_RAM_BASE: +---------------------------------------+ | MRC Region | | CONFIG_DCACHE_RAM_MRC_VAR_SIZE bytes | +---------------------------------------+ Offset CONFIG_DCACHE_RAM_SIZE | ROM stage stack | | | | | +---------------------------------------+ | ROM stage console | | CONFIG_CONSOLE_CAR_BUFFER_SIZE bytes | +---------------------------------------+ | ROM stage CAR_GLOBAL variables | +---------------------------------------+ Offset 0 Another variable was add, CONFIG_DCACHE_RAM_ROMSTAGE_STACK_SIZE, which represents the expected stack usage for the romstage. A marker is checked at the base of the stack to determine if either the stack was smashed or the console encroached on the stack. Change-Id: Id76f2fe4a5cf1c776c8f0019f406593f68e443a7 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2752 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: fix ACPI MCFG tableAaron Durbin
The acpi_fill_mcfg() was still using ivy/sandy PCI device ids which Hawell obviously doesn't have. This resulted in an empty MCFG table. Instead of relying on PCI device ids use dev/fn 0/0 since that is where the host bridge always resides. Additionally remove the defines for the IB and SB pci device ids. Replace them with mobile and ult Haswel device ids and use those in the pci driver tables for the northbridge code. Booted to Linux and noted that MCFG was properly parsed. Change-Id: Ieaab2dfef0e9daf3edbd8a27efe0825d2beb9443 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2748 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: enable caching before SMM initializationAaron Durbin
The SMM handler resides in the TSEG region which is far above CONFIG_RAM_TOP (which is the highest cacheable address) before MTRRs are setup. This means that calling initialize_cpus() before performing MTRR setup on the BSP means the SMM handler is copied using uncacheable accesses. Improve the SMM handler setup path by enabling performing MTRR setup on for the BSP before the call to initialize_cpus(). In order to do this the haswell_init() function was split into 2 paths: BSP & AP paths. There is a cpu_common_init() that both call to perform similar functionality. The BSP path in haswell_init() then starts the APs using intel_cores_init(). The AP path in haswell_init() loads microcode and sets up MTRRs. This split will be leveraged for future support of bringing up APs in parallel as well as adhering to the Haswell MP initialization requirements. Change-Id: Id8e17af149e68d708f3d4765e38b1c61f7ebb470 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2746 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell platforms: restructure romstage mainAaron Durbin
There was a mix of setup code sprinkled across the various components: southbridge code in the northbridge, etc. This commit reorganizes the code so that northbridge code doesn't initialize southbridge components. Additionally, the calling dram initialization no longer calls out to ME code. The main() function in the mainboard calls the necessary ME functions before and after dram initialization. The biggest change is the addition of an early_pch_init() function which initializes the BARs, GPIOs, and RCBA configuration. It is also responsible for reporting back to the caller if the board is being woken up from S3. The one sequence difference is that the RCBA config is performed before claling the reference code. Lastly the rcba configuration was changed to be table driven so that different board/configurations can use the same code. It should be possible to have board/configuration specific gpio and rcba configuration while reusing the romstage code. Change-Id: I830e41b426261dd686a2701ce054fc39f296dffa Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2681 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17haswell: include TSEG region in cacheable memoryAaron Durbin
The SMRR takes precedence over the MTRR entries. Therefore, if the TSEG region is setup as cacheable through the MTTRs, accesses to the TSEG region before SMM relocation are cached. This allows for the setup of SMM relocation to be faster by caching accesses to the future TSEG (SMRAM) memory. MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BGSM: 0xad800000 MC MAP: BDSM: 0xada00000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 TSEG->BGSM: PCI: 00:00.0 resource base ad000000 size 800000 align 0 gran 0 limit 0 flags f0004200 index 4 BGSM->TOLUD: PCI: 00:00.0 resource base ad800000 size 2200000 align 0 gran 0 limit 0 flags f0000200 index 5 Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB Setting variable MTRR 1, base: 2048MB, range: 512MB, type WB Setting variable MTRR 2, base: 2560MB, range: 256MB, type WB Adding hole at 2776MB-2816MB Setting variable MTRR 3, base: 2776MB, range: 8MB, type UC Setting variable MTRR 4, base: 2784MB, range: 32MB, type UC Zero-sized MTRR range @0KB Allocate an msr - basek = 00400000, sizek = 0023d800, Setting variable MTRR 5, base: 4096MB, range: 2048MB, type WB Setting variable MTRR 6, base: 6144MB, range: 256MB, type WB Adding hole at 6390MB-6400MB Setting variable MTRR 7, base: 6390MB, range: 2MB, type UC MTRR translation from MB to addresses: MTRR 0: 0x00000000 -> 0x80000000 WB MTRR 1: 0x80000000 -> 0xa0000000 WB MTRR 2: 0xa0000000 -> 0xb0000000 WB MTRR 3: 0xad800000 -> 0xae000000 UC MTRR 4: 0xae000000 -> 0xb0000000 UC I'm not a fan of the marking physical address space with MTRRs as being UC which is PCI space, but it is technically correct. Lastly, drop a comment describing AP startup flow through coreboot. Change-Id: Ic63c0377b9c20102fcd3f190052fb32bc5f89182 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2690 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17i945: Replace some two magic values by defined namesPatrick Georgi
Devoutly to be wish'd. To die,—to sleep;— To sleep! perchance to dream:—ay, there's the rub; For in that sleep of death what dreams may come, (Since who could argue with William Shakespeare?) Change-Id: I4e4c617dcd3ede81a0abbe16f9916562d24fa8ce Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com> Reviewed-on: http://review.coreboot.org/2733 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-16haswell: don't add a 0-sized memory range resourceAaron Durbin
It's possible that TOUUD can be 4GiB in a small physical memory configuration. Therefore, don't add a 0-size memory range resouce in that case. Change-Id: I016616a9d9d615417038e9c847c354db7d872819 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2691 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15Google Link: Add remaining code to support native graphicsRonald G. Minnich
The Link native graphics commit 49428d84 [1] Add support for Google's Chromebook Pixel was missing some of the higher level bits, and hence could not be used. This is not new code -- it has been working since last August -- so the effort now is to get it into the tree and structure it in a way compatible with upstream coreboot. 1. Add options to src/device/Kconfig to enable native graphics. 2. Export the MTRR function for setting variable MTRRs. 3. Clean up some of the comments and white space. While I realize that the product name is Pixel, the mainboard in the coreboot tree is called Link, and that name is what we will use in our commits. [1] http://review.coreboot.org/2482 Change-Id: Ie4db21f245cf5062fe3a8ee913d05dd79030e3e8 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2531 Tested-by: build bot (Jenkins)
2013-03-15haswell: Fix BDSM and BGSM indicies in memory mapAaron Durbin
This wasn't previously spotted because the printk's were correct. However if one needed to get the value of the BDSM or BGSM register the value would reflect the other register's value. Change-Id: Ieec7360a74a65292773b61e14da39fc7d8bfad46 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2689 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: reserve default SMRAM spaceAaron Durbin
Currently the OS is free to use the memory located at the default SMRAM space because it is not marked reserved in the e820. This can lead to memory corruption on S3 resume because SMM setup doesn't save this range before using it to relocate SMRAM. Resulting tables: coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000002ffff: RAM 2. 0000000000030000-000000000003ffff: RESERVED 3. 0000000000040000-000000000009ffff: RAM 4. 00000000000a0000-00000000000fffff: RESERVED 5. 0000000000100000-0000000000efffff: RAM 6. 0000000000f00000-0000000000ffffff: RESERVED 7. 0000000001000000-00000000acebffff: RAM 8. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 9. 00000000ad000000-00000000af9fffff: RESERVED 10. 00000000f0000000-00000000f3ffffff: RESERVED 11. 00000000fed10000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 13 items: 0: 0000000000000000 - 0000000000030000 = 1 RAM 1: 0000000000030000 - 0000000000040000 = 2 RESERVED 2: 0000000000040000 - 000000000009f400 = 1 RAM 3: 000000000009f400 - 00000000000a0000 = 2 RESERVED 4: 00000000000f0000 - 0000000000100000 = 2 RESERVED 5: 0000000000100000 - 0000000000f00000 = 1 RAM 6: 0000000000f00000 - 0000000001000000 = 2 RESERVED 7: 0000000001000000 - 00000000acec0000 = 1 RAM 8: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 9: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 10: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 11: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 12: 0000000100000000 - 000000018f600000 = 1 RAM Booted and checked e820 as well as coreboot table information. Change-Id: Ie4985c748b591bf8c0d6a2b59549b698c9ad6cfe Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2688 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-15haswell: resource allocationAaron Durbin
The previous code w.r.t. resource allocation was getting lucky based on the way fixed mmio resources on the system were being chosen. Namely, PCIEXBAR was the lowest mmio space and the other fixed non-standar BARs were above it. The resource allocator would then start allocating standard BARs below that. On top of that other resources were being added when dev_ops->set_resources() was being called on the PCI domain. At that point the PCI range limit were already picked for where to start allocating from. To ensure we no longer get lucky during resource allocation add the fixed resources in the host bridge and add the memory controller cacheable memory areas. With those resources added the range limit for standard PCI BARs is chosen properly. Depending on haswell board configurations we may need to adjust and pass in the size of physical address space needed for PCI resources to the reference code. For the time being the CRBs appear to be OK. Lastly, remove the SNB workaround for reserving 2MiB at 1GiB and 512MiB. Output from 6GiB memory configuration: MC MAP: TOM: 0x140000000 MC MAP: TOUUD: 0x18f600000 MC MAP: MESEG_BASE: 0x13f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x13f000000 MC MAP: REMAP_LIMIT: 0x18f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000018f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000018f600000 = 1 RAM Output from 4GiB memory configuration: MC MAP: TOM: 0x100000000 MC MAP: TOUUD: 0x14f600000 MC MAP: MESEG_BASE: 0xff000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x14f5fffff MC MAP: TOLUD: 0xafa00000 MC MAP: BDSM: 0xada00000 MC MAP: BGSM: 0xad800000 MC MAP: TESGMB: 0xad000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-00000000acebffff: RAM 6. 00000000acec0000-00000000acffffff: CONFIGURATION TABLES 7. 00000000ad000000-00000000af9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-000000014f5fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 00000000acec0000 = 1 RAM 6: 00000000acec0000 - 00000000afa00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 000000014f600000 = 1 RAM Output from 2GiB memory configuration: MC MAP: TOM: 0x40000000 MC MAP: TOUUD: 0x100600000 MC MAP: MESEG_BASE: 0x3f000000 MC MAP: MESEG_LIMIT: 0x7fff0fffff MC MAP: REMAP_BASE: 0x100000000 MC MAP: REMAP_LIMIT: 0x1005fffff MC MAP: TOLUD: 0x3ea00000 MC MAP: BDSM: 0x3ca00000 MC MAP: BGSM: 0x3c800000 MC MAP: TESGMB: 0x3c000000 MC MAP: GGC: 0x209 coreboot memory table: 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000a0000-00000000000fffff: RESERVED 3. 0000000000100000-0000000000efffff: RAM 4. 0000000000f00000-0000000000ffffff: RESERVED 5. 0000000001000000-000000003bebffff: RAM 6. 000000003bec0000-000000003bffffff: CONFIGURATION TABLES 7. 000000003c000000-000000003e9fffff: RESERVED 8. 00000000f0000000-00000000f3ffffff: RESERVED 9. 00000000fed10000-00000000fed17fff: RESERVED 10. 00000000fed18000-00000000fed18fff: RESERVED 11. 00000000fed19000-00000000fed19fff: RESERVED 12. 00000000fed84000-00000000fed84fff: RESERVED 13. 0000000100000000-00000001005fffff: RAM e820 map has 11 items: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 3: 0000000000100000 - 0000000000f00000 = 1 RAM 4: 0000000000f00000 - 0000000001000000 = 2 RESERVED 5: 0000000001000000 - 000000003bec0000 = 1 RAM 6: 000000003bec0000 - 000000003ea00000 = 2 RESERVED 7: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 8: 00000000fed10000 - 00000000fed1a000 = 2 RESERVED 9: 00000000fed84000 - 00000000fed85000 = 2 RESERVED 10: 0000000100000000 - 0000000100600000 = 1 RAM Verified through debug messages that range limits as well as resources were being properly honored. Change-Id: I2faa7d8a2a34a6a411a2885afb3b5c3fa1ad9c23 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2687 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2013-03-14haswell: more ULT/LP support and minor tweaksDuncan Laurie
- Add ME device ID for Lynxpoint LP - Add GPU device IDs for ULT - SATA init tweaks from checking against DXE reference code - Remove the ICH7 from the SPI driver so it works on all lynxpoint without having to add more LPC device ID checks - Add function disable for audio dsp and xhci, remove PCI bridge - Add interrupt route registers for new devices (needs romstage setup) Change-Id: Idb48f50d0bacb6bf90531c3834542b9abb54fb8a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2680 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: Add VGA PCI ID mappingsAaron Durbin
Needed to map VGA OPROM IDs to actual device IDs Change-Id: I6743905c3db52519bf18f4bcc1a972aec43d3e9d Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2674 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14haswell: Add ULT device IDsDuncan Laurie
Device IDs for northbridge and GPU. Also mask off the lock bit in the memory map registers. Change-Id: I9a4955d4541b938285712e82dd0b1696fa272b63 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2646 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2013-03-14graysreef: update platform informationAaron Durbin
Some of the Lynx Point ids were off. Correct those and make the pei data BAR fields consistent with the others. Change-Id: I4102439588362cdb94643bd1ce69c9fa4278329e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2622 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: remove explicit pcie config accessesAaron Durbin
Now that MMCONF_SUPPORT_DEFAULT is enabled by default remove the pcie explicit accesses. The default config accesses use MMIO. Change-Id: I8406cec16c1ee1bc205b657a0c90beb2252df061 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2618 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-14haswell: add PCI id supportAaron Durbin
In order for coreboot to assign resources properly the pci drivers need to have th proper device ids. Add the host controller and the LPC device ids for Lynx Point. Resource assignment works correctly now w/o odd behavior because of conflicts. Change-Id: Id33b3676616fb0c428d84e5fe5c6b8a7cc5fbb62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2638 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martin.roth@se-eng.com>