aboutsummaryrefslogtreecommitdiff
path: root/src/mainboard/intel/dcp847ske/early_southbridge.c
AgeCommit message (Collapse)Author
2018-07-02src/mb: Fix non-local header treated as localElyes HAOUAS
Also remove some unnedded includes. Change-Id: I036208a111d009620d8354fa9c97688eb4e872ad Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr> Reviewed-on: https://review.coreboot.org/27129 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-06-21Revert "sb/intel/{bd82x6,ibexpeak}: Move RCBA macros to a common location"Arthur Heymans
In the end it does not look like RCBA register offsets are fully compatible over southbridges. This reverts commit d2d2aef6a3222af909183fb96dc7bc908fac3cd4. Is squashed with revert of "sb/intel/common: Fix conflicting OIC register definition" 8aaa00401b68e5c5b6c07b0984e3e7c3027e3c2f. Change-Id: Icbf4db8590e60573c8c11385835e0231cf8d63e6 Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/27038 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2018-02-27sb/intel/{bd82x6,ibexpeak}: Move RCBA macros to a common locationArthur Heymans
Many generations of Intel hardware have identical code concerning the RCBA. Change-Id: I33ec6801b115c0d64de1d2a0dc5d439186f3580a Signed-off-by: Arthur Heymans <arthur@aheymans.xyz> Reviewed-on: https://review.coreboot.org/23287 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Patrick Rudolph <siro@das-labor.org>
2018-01-23sb/intel/bd82x6x: Reduce function-disable messNico Huber
Most affected boards set the function disabled (FD) register to an arbitrary state dumped from systems running the vendor BIOS. This makes it impossible to enable the devices in devicetree and a pretty big mess of course because nobody cared to keep the register in sync with the devicetree. To get completely rid of most of the writes to FD, move setting of PCH_DISABLE_ALWAYS into the southbridge code where it belongs. Change-Id: Ia2a507cbcdf218d09738e2e16f0d3ad1dcf57b8b Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/23255 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Hal Martin <hal.martin+coreboot@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Bill XIE <persmule@gmail.com> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
2017-12-22intel/dcp847ske: Add Intel NUC DCP847SKETobias Diedrich
https://ark.intel.com/products/71620/Intel-NUC-Board-DCP847SKE Created using autoport and manual edits. mainboard_fill_pei_data copied and adjusted from samsung/lumpy. Tested: - RAM slots with 2x4GB Kingston KVR1333D3S9/4G (DDR3-1333 1.5V). - RAM slots with 2x4GB Kingston KVR16LS11/4G (DDR3L-1600 1.35V). - SeaBIOS stable payload. - Linux 4.13.14 payload. - Booting into Linux 4.13.14 with Debian/unstable installed on the internal mSATA slot. - Non-native raminit (works). - Native raminit - KVR1333D3S9 doesn't work. - KVR16LS11 only works at 1.5V. - Native VGA init, HDMI port detection with libgfxinit. - Basic ACPI functions (power button event; power-off; reboot). - Suspend to RAM and resume works. - PCIe WLAN in half-minicard slot. - USB device in half-minicard slot. - PCIe device in full-minicard slot. - mSATA device in full-minicard slot. - Fan spins up/down in response to CPU load. Known issues: - Native raminit fails timC calibration with the RAM I have. - Technical Product Specification mentions overcurrent protection for back panel and front panel USB connectors, but I haven't been able to trigger it with either native fw or coreboot (tried up to 2.5A load). Untested: - USB debug port. Change-Id: I6e210310f55c051eaf61e0698fed855eda5d7d90 Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de> Reviewed-on: https://review.coreboot.org/22683 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>