summaryrefslogtreecommitdiff
path: root/src/soc/example/min86/Makefile.inc
AgeCommit message (Collapse)Author
2022-10-31soc: Add SPDX license headers to MakefilesMartin Roth
Signed-off-by: Martin Roth <gaumless@gmail.com> Change-Id: Ic875708697f07b6dae09d27dbd67eb8b960749f0 Reviewed-on: https://review.coreboot.org/c/coreboot/+/68984 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Sean Rhodes <sean@starlabs.systems>
2021-10-25cpu,soc/x86: always include cpu/x86/mtrr on x86 CPUs/SoCsFelix Held
All x86-based CPUs and SoCs in the coreboot tree end up including the Makefile in cpu/x86/mtrr, so include this directly in the Makefile in cpu/x86 to add it for all x86 CPUs/SoCs. In the unlikely case that a new x86 CPU/SoC will be added, a CPU_X86_MTRR Kconfig option that is selected be default could be added and the new CPU/SoC without MTRR support can override this option that then will be used in the Makefile to guard adding the Makefile from the cpu/x86/mtrr sub-directory. In cpu/intel all models except model 2065X and 206AX are selcted by a socket and rely on the socket's Makefile.inc to add x86/mtrr to the subdirs, so those models don't add x86/mtrr themselves. The Intel Broadwell SoC selects CPU_INTEL_HASWELL and which added x86/mtrr to the subdirs. The Intel Xeon SP SoC directory contains two sub-folders for different versions or generations which both add x86/mtrr to the subdirs in their Makefiles. Change-Id: I743eaac99a85a5c712241ba48a320243c5a51f76 Signed-off-by: Angel Pons <th3fanbus@gmail.com> Signed-off-by: Felix Held <felix-coreboot@felixheld.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/44230 Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
2020-10-30x86: Add a minimal example SoC along with a boardNico Huber
The min86 example SoC code along with the example mainboard should serve as a minimal example how a buildable x86 SoC code base can look like. This can serve, for instance, as a basis to add new SoCs to coreboot. Starting with a buildable commit should help with the review of the actual code, and also avoid any regressions when common coreboot code changes. As the example code itself is build-tested, it should advance with coreboot and can't rot like documentation might. It also serves as a check what APIs need to be implemented with the default Kconfig settings. Change-Id: Id76ab15fe77ae3e405c43f9c8677694f178be112 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: https://review.coreboot.org/c/coreboot/+/45710 Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org> Reviewed-by: Angel Pons <th3fanbus@gmail.com> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>