| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2013-07-11 | cpu: Fix spelling | Martin Roth | |
| Change-Id: I69c46648de0689e9bed84c7726906024ad65e769 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/3729 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> | |||
| 2013-06-03 | haswell: allow for disabled hyperthreading | Aaron Durbin | |
| There were assumptions being made in the haswell MP and SMM code which assumed the APIC id space was 1:1 w.r.t. cpu number. When hyperthreading is disabled the APIC ids of the logical processors are all even. That means the APIC id space is sparse. Handle this situation. Change-Id: Ibe79ab156c0a171208a77db8a252aa5b73205d6c Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3353 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-05-10 | Drop prototype guarding for romcc | Stefan 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-07 | haswell: use asmlinkage for assembly-called funcs | Aaron Durbin | |
| When the haswell MP/SMM code was developed it was using a coreboot repository that did not contain the asmlinkage macro. Now that the asmlinkage macro exists use it. BUG=None BRANCH=None TEST=Built and booted. Change-Id: I662f1b16d1777263b96a427334fff8f98a407755 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/3203 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> | |||
| 2013-03-21 | haswell: implement ramstage caching in SMM region | Aaron Durbin | |
| Cache the relocated ramstage into the SMM region. There is a reserved region within the final SMM region (TSEG). Use that space to cache the relocated ramstage program. That way, on S3 resume there is a copy that can be loaded quickly instead of accessing the flash. Caching the ramstage in the SMM space is also helpful in that it prevents the OS from tampering with the ramstage program. Change-Id: Ifa695ad1c350d5b504b14cc29d3e83c79b317a62 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2806 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-21 | haswell: add multipurpose SMM memory region | Aaron 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-21 | haswell: support for parallel SMM relocation | Aaron Durbin | |
| The haswell processors support the ability to save their SMM state into MSR space instead of the memory. This feaure allows for parallel SMM relocation handlers as well as setting the same SMBASE for each CPU since the save state memory area is not used. The catch is that in order determine if this feature is available the CPU needs to be in SMM context. In order to implement parallel SMM relocation the BSP enters the relocation handler twice. The first time is to determine if that feature is available. If it is, then that feature is enabled the BSP exits the relocation handler without relocating SMBASE. It then releases the APs to run the SMM relocation handler. After the APs have completed the relocation the BSP will re-enter the SMM relocation handler to relocate its own SMBASE to the final location. If the parallel SMM feature is not available the BSP relocates its SMBASE as it did before. This change also introduces the BSP waiting for the APs to relocate their SMBASE before proceeding with the remainder of the boot process. Ensured both the parallel path and the serial path still continue to work on cold, warm, and S3 resume paths. Change-Id: Iea24fd8f9561f1b194393cdb77c79adb48039ea2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2801 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-19 | haswell: Parallel AP bringup | Aaron Durbin | |
| This patch parallelizes the AP startup for Haswell-based devices. It does not touch the generic secondary startup code. Instead it provides its own MP support matching up with the Haswell BWG. It seemed to be too much trouble to support the old startup way and this new way. Because of that parallel loading is the only thing supported. A couple of things to note: 1. Micrcode needs to be loaded twice. Once before MTRR and caching is enabled. And a second time after SMM relocation. 2. The sipi_vector is entirely self-contained. Once it is loaded and written back to RAM the APs do not access memory outside of the sipi_vector load location until a sync up in ramstage. 3. SMM relocation is kicked off by an IPI to self w/ SMI set as the destination mode. The following are timings from cbmem with dev mode disabled and recovery mode enabled to boot directly into the kernel. This was done on the baskingridge CRB with a 4-core 8-thread CPU and 2 DIMMs 1GiB each. The kernel has console enabled on the serial port. Entry 70 is the device initialization, and that is where the APs are brought up. With these two examples it looks to shave off ~200 ms of boot time. Before: 1:55,382 2:57,606 (2,223) 3:3,108,983 (3,051,377) 4:3,110,084 (1,101) 8:3,113,109 (3,024) 9:3,156,694 (43,585) 10:3,156,815 (120) 30:3,157,110 (295) 40:3,158,180 (1,069) 50:3,160,157 (1,977) 60:3,160,366 (208) 70:4,221,044 (1,060,677) 75:4,221,062 (18) 80:4,227,185 (6,122) 90:4,227,669 (484) 99:4,265,596 (37,927) 1000:4,267,822 (2,225) 1001:4,268,507 (685) 1002:4,268,780 (272) 1003:4,398,676 (129,896) 1004:4,398,979 (303) 1100:7,477,601 (3,078,621) 1101:7,480,210 (2,608) After: 1:49,518 2:51,778 (2,259) 3:3,081,186 (3,029,407) 4:3,082,252 (1,066) 8:3,085,137 (2,884) 9:3,130,339 (45,202) 10:3,130,518 (178) 30:3,130,544 (26) 40:3,131,125 (580) 50:3,133,023 (1,897) 60:3,133,278 (255) 70:4,009,259 (875,980) 75:4,009,273 (13) 80:4,015,947 (6,674) 90:4,016,430 (482) 99:4,056,265 (39,835) 1000:4,058,492 (2,226) 1001:4,059,176 (684) 1002:4,059,450 (273) 1003:4,189,333 (129,883) 1004:4,189,770 (436) 1100:7,262,358 (3,072,588) 1101:7,263,926 (1,567) Booted the baskingridge board as noted above. Also analyzed serial messages with pcserial enabled. Change-Id: Ifedc7f787953647c228b11afdb725686e38c4098 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2779 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-18 | haswell: add romstage_after_car() function | Aaron Durbin | |
| There are changes coming to perform more complex tasks after cache-as-ram has been torn down but before ramstage is loaded. Therefore, add the romstage_after_car() function to call after cache-as-ram is torn down. Its responsibility is for loading the ramstage and any other complex tasks. For example, the saving of OS-controlled memory in the resume path has now been moved into C instead of assembly. Change-Id: Ie0c229cf83a9271c8995b31c534c8e5a696b164e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2757 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-18 | haswell: romstage: pass stack pointer and MTRRs | Aaron Durbin | |
| Instead of hard coding the policy for the stack and MTRR values after the cache-as-ram is torn down, allow for the C code to pass those policies back to the cache-as-ram assembly file. That way, ramstage relocation can use a different stack as well as different MTRR policies. Change-Id: Ied024d933f96a12ed0703c51c506586f4b50bd14 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2755 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-18 | haswell: unify romstage logic | Aaron 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-18 | haswell: adjust CAR usage | Aaron 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-18 | haswell: enable caching before SMM initialization | Aaron 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-18 | haswell: move definition of CORE_THREAD_COUNT_MSR | Aaron Durbin | |
| This just moves the definiton of CORE_THREAD_COUNT_MSR so that future code can utilize it. Change-Id: I15a381090f21ff758288f55dc964b6694feb6064 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2744 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
| 2013-03-14 | haswell: Add initial support for Haswell platforms | Aaron Durbin | |
| The Haswell parts use a PCH code named Lynx Point (Series 8). Therefore, the southbridge support is included as well. The basis for this code is the Sandybridge code. Management Engine, IRQ routing, and ACPI still requires more attention, but this is a good starting point. This code partially gets up through the romstage just before training memory on a Haswell reference board. Change-Id: If572d6c21ca051b486b82a924ca0ffe05c4d0ad4 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2616 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> | |||
 |
index : coreboot.git | |
| my copy of coreboot | User & |
| summaryrefslogtreecommitdiff |