summaryrefslogtreecommitdiff
path: root/src/mainboard/intel/wtm1
AgeCommit message (Collapse)Author
2013-05-11Remove the wtm1 mainboardDuncan Laurie
This was an early bring-up reference board for ULT but it is no longer being worked on and was never complete enough to be useful and I no longer have a board so it is already stale and untested. All ULT bring-up work has moved to the wtm2 mainboard instead. Change-Id: If64d61bf7a3fc8c9e16096ffc28fa4128aa99477 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48897 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3231 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2013-04-01lynxpoint: Move ACPI NVS into separate CBMEM tableDuncan Laurie
The ACPI NVS region was setup in place and there was a CBMEM table that pointed to it. In order to be able to use NVS earlier the CBMEM region is allocated for NVS itself during the LPC device init and the ACPI tables point to it in CBMEM. The current cbmem region is renamed to ACPI_GNVS_PTR to indicate that it is really a pointer to the GNVS and does not actually contain the GNVS. Change-Id: I31ace432411c7f825d86ca75c63dd79cd658e891 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2970 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-30wtm1/wtm2/baskingridge: Enable TPM ACPI deviceDuncan Laurie
This enables the TPM device in ACPI tables so the OS is able to probe for the TPM without needing it be force loaded. Change-Id: I21e660ac1c12e3e1341cf266cf8f0bf03763df5a Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2968 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-30x86: Drop BOARD_HAS_FADTKyösti Mälkki
There is a wildcard rule to include mainboard/fadt.c. Change-Id: I7f59d6b241c683b62c2c41c5795e45184882635e Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/2940 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-22Unify coreboot table generationStefan Reinauer
coreboot tables are, unlike general system tables, a platform independent concept. Hence, use the same code for coreboot table generation on all platforms. lib/coreboot_tables.c is based on the x86 version of the file, because some important fixes were missed on the ARMv7 version lately. Change-Id: Icc38baf609f10536a320d21ac64408bef44bb77d Signed-off-by: Stefan Reinauer <reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/2863 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Aaron Durbin <adurbin@google.com> Tested-by: build bot (Jenkins)
2013-03-22haswell boards: support added chromeos functionAaron Durbin
The get_write_protect_state() function was added to the chromeos API that needs to be supported by the boards. Implement this support. Built and booted. Noted firmware select worked on an image with RW firmware support. Also checked that recovery mode worked as well by choosing the RO path. Change-Id: Ifd213be25304163fc61d153feac4f5a875a40902 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2855 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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-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-18haswell: unify romstage logicAaron Durbin
This commit pulls in all the common logic for romstage into the Haswell cpu directory. The bits specific to the mainboard still reside under their respective directories. The calling sequence bounces from the cpu directory to mainboard then back to the cpu directory. The reasoning is that Haswell systems use cache-as-ram for backing memory in romstage. The stack is used to allocate structures. However, now changes can be made to the romstage for Haswell and apply to all boards. Change-Id: I2bf08013c46a99235ffe4bde88a935c3378eb341 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2754 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-17Add Intel Whitetip Mountain 1 mainboardDuncan Laurie
Lots of things are still placeholder and need work. Due to the useful GPIOs being run to either the EC or the SIO1007 I have hard coded developer mode on and recovery mode off. Change-Id: I4c308bd90db03ac5bffdfde566e5adbbaabac632 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2724 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>