summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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-18rmodule: add rmodules class and new typeAaron Durbin
Add an rmodules class so that there are default rules for compiling files that will be linked by the rmodule linker. Also, add a new type for SIPI vectors. Change-Id: Ided9e15577b34aff34dc23e5e16791c607caf399 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2751 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18wtm2: Disable USB port 7 (SD card) due to hangDuncan Laurie
This is causing a hang in depthcharge. For now just disable this port. Change-Id: I87a6db2d8361588e82eee640c74cea690115bed5 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2764 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18libpayload: Fix the config file dependency in the Makefile templateGabe Black
The template had a dependency on config.h which was correct for coreboot, where this build system originally came from, but not for libpayload which uses the differently named libpayload-config.h, presumably to avoid colliding with a config.h used by the actual payload. Because libpayload-config.h is now effectively a dependency of everything, it doesn't have to be added piecemeal in Makefile.inc. Change-Id: I01f20d363cb1393fa1cdcf0dc916670db90294e9 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2763 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18libpayload: Make keycode constants available outside of curses.h.Gabe Black
And include the new, split out version in drivers/keyboard.c and drivers/usb/usbhid.c. Those files were including curses.h just for those definitions, but the include path was only fixed up to to point to the libpayload versions of those files if one of the variants of curses was compiled in. If neither was, gcc would fall back to the system version of that header which is wrong. Change-Id: I8c2ee0baf5f0702bd8c713c8dd4613a4bb269ce5 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: http://review.coreboot.org/2762 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18rmodule: include heap in bss sectionAaron Durbin
By including the heap in the bss output section the size is accounted for in a elf PT_LOAD segment. Without this change the heap wasn't being put into a PT_LOAD segment. The result is a nop w.r.t. functionality, but readelf and company will have proper MemSiz fields. Change-Id: Ibfe9bb87603dcd4c5ff1c57c6af910bbba96b02b Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2750 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18rmodule: add 16 bytes of paddingAaron Durbin
There is a plan to utlize rmodules for loading ramstage as a relocatable module. However, the rmodule header may change. In order to provide some wiggle room for changing the contents of the rmodule header add some padding. This won't stop the need for coordinating properly between the romstage loader that may be in readonly flash and rmodule header fields. But it will provide for a way to make certain assumptions about alignment of the rmodule's program when the rmodule is compressed in the flash. Change-Id: I9ac5cf495c0bce494e7eaa3bd2f2bd39889b4c52 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2749 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: lapic timer supportAaron Durbin
Haswell's BCLK is fised at 100MHz like Sandy/Ivy. Add Haswell's model to the switch statement. Change-Id: Ib9e2afc04eba940bfcee92a6ee5402759b21cc45 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2747 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18lynxpoint: Move a bit of generic RCBA into early_pchDuncan Laurie
Rather than have to repeat this bit in every mainboard. Also, remove the reset of the RTC power status from here. We had done this in TOT for current platforms but did not carry it back to emeraldlake2 where this branched from. If we clear the status here then we don't get an event logged later which can be important for the devices that do not have a CMOS battery. Change-Id: Ia7131e9d9e7cf86228a285df652a96bcabf05260 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2683 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18lib: add rmodule supportAaron Durbin
A rmodule is short for relocation module. Relocaiton modules are standalone programs. These programs are linked at address 0 as a shared object with a special linker script that maintains the relocation entries for the object. These modules can then be embedded as a raw binary (objcopy -O binary) to be loaded at any location desired. Initially, the only arch support is for x86. All comments below apply to x86 specific properties. The intial user of this support would be for SMM handlers since those handlers sometimes need to be located at a dynamic address (e.g. TSEG region). The relocation entries are currently Elf32_Rel. They are 8 bytes large, and the entries are not necessarily in sorted order. An future optimization would be to have a tool convert the unsorted relocations into just sorted offsets. This would reduce the size of the blob produced after being processed. Essentialy, 8 bytes per relocation meta entry would reduce to 4 bytes. Change-Id: I2236dcb66e9d2b494ce2d1ae40777c62429057ef Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2692 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-18haswell: Clear correct number of MCA banksAaron Durbin
The configure_mca() function was hard coding the number of banks the cpu supported. Query this dynamically so that it no longer clears only 7 banks. Change-Id: I33fce8fadc0facd1016b3295faaf3ae90e490a71 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2745 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18haswell: move definition of CORE_THREAD_COUNT_MSRAaron 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-18haswell: Use SMM ModulesAaron Durbin
This commit adds support for using the SMM modules for haswell-based boards. The SMI handling was also refactored to put the relocation handler and permanent SMM handler loading in the cpu directory. All tseg adjustment support is dropped by relying on the SMM module support to perform the necessary relocations. Change-Id: I8dd23610772fc4408567d9f4adf339596eac7b1f Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2728 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18Add support for "Stout" ChromebookStefan Reinauer
We're happy to announce coreboot support for the "Stout" Chromebook, a.k.a Lenovo X131e Chromebook. Change-Id: I9b995f8d0dd48e41c788b7c3d35b4fac5840e425 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2636 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-18Add Intel Whitetip Mountain 2 mainboardDuncan Laurie
This is mostly a copy of Whitetip Mountain 1 with specific GPIO map for this Customer Reference Board (CRB). This mainboard currently has basic funcionality and is able to boot a Linux Kernel but many of the new Haswell ULT specific devices are not yet enabled. Change-Id: I999452d86f00a2c245fa39b1b76080f6a3b1e352 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2725 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17superiotool: Add support for the IT8728F Super I/OАндрей Павлов
$ superiotool -d superiotool r4.0-3712-gd549279 Found ITE IT8728F (id=0x8728, rev=0x1) at 0x2e Register dump: idx 02 07 20 21 22 23 24 2b 2e 2f val 00 0a 87 28 01 00 00 40 00 00 def NA NA 87 28 01 00 00 MM 00 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 03 f0 06 02 00 00 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 val 01 03 f8 04 00 50 def 00 03 f8 04 00 50 LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 val 00 02 f8 03 00 50 def 00 02 f8 03 00 50 LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 01 03 78 00 00 07 04 08 def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 f9 fa fb val 01 0a 30 0a 20 09 00 80 00 00 20 00 f0 48 00 00 def 00 02 90 02 30 09 00 00 00 00 00 MM MM MM MM MM LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 48 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 2d 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc cd ce cf e0 e1 e2 e3 e4 e9 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb val 00 f3 10 00 00 00 80 00 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 00 00 00 21 10 42 00 00 00 00 1c 00 00 00 00 00 def 00 f3 00 00 00 00 03 00 00 00 00 00 00 00 00 00 20 38 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 MM 00 00 00 00 00 00 00 00 00 00 00 00 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 06 Change-Id: Ifb45d28005d78b2a99d8552b59154d11bdf44f6f Signed-off-by: Андрей Павлов <7134956@gmail.com> Reviewed-on: http://review.coreboot.org/2775 Tested-by: build bot (Jenkins) Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
2013-03-17Intel HD Audio: clean up initialization codeStefan Reinauer
- Some initialization steps were done twice - One step was missing for Panther Point HDA - Added a 1ms delay after reset - Increased timeout to 1ms for all codec operations Change-Id: Ib751f1a16ccd88ea2fbbb2a10737f76277574026 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2518 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17x86 intel: Add Firmware Interface Table supportAaron Durbin
Haswell CPUs require a FIT table in the firmware. This commit adds rudimentary support for a FIT table. The number of entries in the table is based on a configuration option. The code only generates a type 0 entry. A follow-on tool will need to be developed to populate the FIT entries as well as checksumming the table. Verified image has a FIT pointer and table when option is selected. Change-Id: I3a314016a09a1cc26bf1fb5d17aa50853d2ef4f8 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2642 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> 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-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>
2013-03-17bd82x6x: Add config option to force SATA link to different speeds.Shawn Nematbakhsh
Certain SATA devices claim to support SATA 6 Gbps, but in fact have bugs. For these devices, add a config option to force the SATA link speed to something other than default. Change-Id: I2dc1793cd58771298a392345162d39d20eb0afbb Signed-off-by: Shawn Nematbakhsh <shawnn@google.com> Reviewed-on: http://review.coreboot.org/2765 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Pantherpoint: Add XHCI device initDuncan Laurie
This enables power management and clock gating on XHCI. Change-Id: I124ea6c5aca034b7ec4b5286d971c2adfce25c88 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2761 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17bd82x6x: don't use absolute symbolsAaron Durbin
objcopy -B provides symbols of the form _binary_<name>_(start|end|size). However, the _size variant is an absoult symbol. If one wants to relocate the smi loading the _size symbol will be relocated which is wrong since it is suppose to be a fixed size. There is no way to distinguish symbols that shouldn't be relocated vs ones that can. Instead use the _start and _end variants to determine the size. Change-Id: I55192992cf36f62a9d8dd896e5fb3043a3eacbd3 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/2760 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x XHCI(USB3) S3/S4 workaroundMarc Jones
The bd82x6x requires some additional setting on S3/S4 entry. Change-Id: I24489ab94dd7cd5a4a64044f25153f5b01a45b77 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2759 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-17Add bd82x6x PCH functions to SMMMarc Jones
Add the PCH function to SMM for follow-on SMM patches that require these functions. Change-Id: I7f3a512c5e98446e835b59934d63a99e8af15280 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/2758 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-17ASROCK Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I5184df8deb7b5d2e15404d689c16c00493eb01aa Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2736 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same chagne as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Id560ea85a38f73aaba2c35447bbce46bd9c0d0dd Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2741 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iae70c3d0af1cdaca31b206ad6daba4d38ee6b780 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2742 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts This is the same change as made to Persimmon in Change-ID If8d86f: http://review.coreboot.org/#/c/2726/ Change-Id: Iff594d4a3493531561eb25d1cceeb97bcefde424 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2743 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: Ie36b60973c6a5f9076bb55c8f451532711a2f8a8 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2737 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17AMD Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: If6dd1a558d9c319d9a41ce63588550c8e81e595f Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2738 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17ASROCK Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: I2701d915338294bdade2ad334b22a51db980892e Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2739 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17Lippert Fam14 DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. This is the same change made to Persimmon with Change-ID I149428: http://review.coreboot.org/#/c/2684/ Change-Id: Iaf7b8153cec4d730efbceae3e6957d2904b8fae4 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2740 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-17lynxpoint: Add support for disabling ULT devicesDuncan Laurie
These enables are hidden behind IOBP for some reason. Boot to linux with SDIO disabled and see that the SDIO driver does not load and crash the system. Change-Id: Icfbfa117e9e57a51d32db7f6366a9d0d790adcf0 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/2695 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2013-03-16stddef.h: Add standard defines for KiB, MiB, GiB, and TiBRonald G. Minnich
Paul points out that some people like 1024*1024, others like 1048576, but in any case these are all open to typos. Define KiB, MiB, GiB, and TiB as in the standard so people can use them. Change-Id: Ic1b57e70d3e9b9e1c0242299741f71db91e7cd3f Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2769 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-16Show the device tree.Ronald G. Minnich
This is a bit of a hack but it's very handy. It compiles in your static.c and then shows what coreboot would see when it is run. It uses your static.c and functions pulled from src/device/device_util.c. I've already used it to debug problems with the snow device tree. I'm waiting someone to tell me this is already written :-) Change-Id: Ia8c8a5d08d8757bec49eaf70473efa701bc56581 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2767 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16google/snow: rename a file so that it is clear what board it is forRonald G. Minnich
One might wonder what a board named 'build' does. Rename the file to build-snow. The fact that it is in a directory with google in the name should be enough to identify the vendor. Change-Id: I0b473cdce67d56fc6b92032b55180523eb337d66 Signed-off-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-on: http://review.coreboot.org/2766 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2013-03-16gitmodules: Ignore 3rdparty in "diff family"Patrick Georgi
This should help avoid wrong 3rdparty commit ids creeping in. Change-Id: I2134ad1d3ad0237ef3f12baf4d4aafb02009e7bc Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/2768 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
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-15AMD Fam14 DSDT: Add secondary bus range to PCI0Mike Loptien
Adding the 'WordBusNumber' macro to the PCI0 CRES ResourceTemplate in the Persimmon DSDT. This sets up the bus number for the PCI0 device and the secondary bus number in the CRS method. This change came in response to a 'dmesg' error which states: '[FIRMWARE BUG]: ACPI: no secondary bus range in _CRS' By adding the 'WordBusNumber' macro, ACPI can set up a valid range for the PCIe downstream busses, thereby relieving the Linux kernel from "guessing" the valid range based off _BBN or assuming [0-0xFF]. The Linux kernel code that checks this bus range is in `drivers/acpi/pci_root.c`. PCI busses can have up to 256 secondary busses connected to them via a PCI-PCI bridge. However, these busses do not have to be sequentially numbered, so leaving out a section of the range (eg. allowing [0-0x7F]) will unnecessarily restrict the downstream busses. This is the same change as made to Persimmon with change-id I44f22: http://review.coreboot.org/#/c/2592/ Change-Id: I9017a7619b3b17e0e95ad0fe46d0652499289b00 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2735 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Update 3rdparty mark to latest repositoryStefan Reinauer
For google/stout binaries Apparently the actual marker got lost in the rebase / change of the commit message. Change-Id: I4f18b9ddba326988b58f2595c0025a113feb0d68 Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: http://review.coreboot.org/2734 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Super I/O W83627DHG: Enable UART B by redirecting pinsWolfgang Kamp
Pins 78-85 are set to GPIO after power on or reset. To enable UART B the pins must be redirected to it. Look at W83627DHG databook version 1.4 page 185 Chip (global) Control Register CR2C. Change-Id: I12b094a60d9c5cb2447a553be4679a4605e19845 Signed-off-by: Wolfgang Kamp <wmkamp@datakamp.de> Reviewed-on: http://review.coreboot.org/2626 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-03-15Persimmon DSDT: Remove INI method from AZHD deviceMike Loptien
I am removing the _INI method from the AZHD device because it does not seem to do anything and causes errors in the FWTS[1] (Firmware Test Suite) test 'method'. The INI method performs device specific initialization and is run when OSPM loads a description table. It must only access OperationRegions that have been indicated as available by the _REG (Region) method. We do not have a _REG method and during my testing, I added a REG method but it did not seem to make a difference in the PCI register space. The bit fields defined as NSDI (Disable No Snoop), NSDO (Disable No Snoop Override), and NSEN (Enable No Snoop Request) do not ever get written from their default values. And writing to these bit fields does not seem to be necessary because I did not notice any change in audio functionality. In an effort to clean up as many FWTS errors as possible, I propose removing this method altogether. I have seen no change in operation (audio works with and without this method) and there does not seem to be any change in lspci or dmesg. FWTS information can be found here: [1]: https://wiki.ubuntu.com/Kernel/Reference/fwts Change-Id: If8d86f959822d528c44ab011a851659d486289b5 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2726 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-03-15Persimmon DSDT: Add OSC methodMike Loptien
The _OSC method is used to tell the OS what capabilities it can take control over from the firmware. This method is described in chapter 6.2.9 of the ACPI spec v3.0. The method takes 4 inputs (UUID, Rev ID, Input Count, and Capabilities Buffer) and returns a Capabilites Buffer the same size as the input Buffer. This Buffer is generally 3 Dwords long consisting of an Errors Dword, a Supported Capabilities Dword, and a Control Dword. The OS will request control of certain capabilities and the firmware must grant or deny control of those features. We do not want to have control over anything so let the OS control as much as it can. The _OSC method is required for PCIe devices and dmesg checks for its existence and issues an error if it is not found. Change-Id: I1494285def7440972f0549b7cb73eb94dafc72c2 Signed-off-by: Mike Loptien <mike.loptien@se-eng.com> Reviewed-on: http://review.coreboot.org/2684 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-24 01:52:40 +0000