All board defconfig files currently set the architecture in addition to
the board and the SoC, by setting e.g. CONFIG_ARM=y. This spams up
defconfig files.
CONFIG_<arch> symbols currently being set in configuration files also
means that they are configurable (can be changed in menuconfig and in
configuration files), even though changing the architecture won't work,
since other things get set from -DBOARD=<board>. Many boards also allow
changing the architecture symbols independently from the SoC symbols,
which doesn't make sense.
Get rid of all assignments to CONFIG_<arch> symbols and clean up the
relationships between symbols and the configuration interface, like
this:
1. Remove the choice with the CONFIG_<arch> symbols in arch/Kconfig and
turn the CONFIG_<arch> symbols into invisible
(promptless/nonconfigurable) symbols instead.
Getting rid of the choice allows the symbols to be 'select'ed (choice
symbols don't support 'select').
2. Select the right CONFIG_<arch> symbol from the SOC_SERIES_* symbols.
This makes sense since you know the architecture if you know the SoC.
Put the select on the SOC_* symbol instead for boards that don't have
a SOC_SERIES_*.
3. Remove all assignments to CONFIG_<arch> symbols. The assignments
would generate errors now, since the symbols are promptless.
The change was done by grepping for assignments to CONFIG_<arch>
symbols, finding the SOC_SERIES_* (or SOC_*) symbol being set in the
same defconfig file, and putting a 'select' on it instead.
See
https://github.com/ulfalizer/zephyr/commits/hide-arch-syms-unsquashed
for a split-up version of this commit, which will make it easier to see
how stuff was done. This needs to go in as one commit though.
This change is safer than it might seem re. outstanding PRs, because any
assignment to CONFIG_<arch> symbols generates an error now, making
outdated stuff easy to catch.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Assignments to promptless symbols have no effect. Flagged by
https://github.com/zephyrproject-rtos/zephyr/pull/20742.
From looking at
http://www.mouser.com
/catalog/specsheets/CircuitCO_595-MINNOWMAX-DUAL%20Data%20Sheet.pdf
, this board uses an Intel Atom E3815 or an Intel Atom E3825 CPU.
Both of those CPUs are listed as vulnerable to all three variants of
Meltdown and Spectre in
https://www.techarp.com/guides/complete-meltdown-spectre-cpu-list/6/.
All the X86_NO_SPECTRE_V* symbols default to n (and it seems nothing
turns them on at the moment), so just remove the assignment, which will
be a no-op.
Also remove the comment re. Spectre V4, as it seems this board is
vulnerable to more than that, though I could've missed something.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Assignments have no effect on promptless symbols. Flagged by
https://github.com/zephyrproject-rtos/zephyr/pull/20742.
This symbol is enabled through being selected by SOC_ATOM in
soc/x86/atom/Kconfig.soc.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
This driver was still using CONFIG_* values to determine its address,
IRQ, etc. Add a binding for an "intel,hpet" device and migrate this
driver to devicetree.
Fixes: #18657
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
According to INTEL-SA-00115[1], Intel(r) Atom(tm) Processor E Series
are affected. All Minnowboards sports one of these processors.
[1]: https://goo.gl/CKyLQy
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Introduce an architecture sorting of boards. This is to allow for
easier maintenance going forward as the number of boards grows. It
will be easier for any scripts to know the board/arch mapping without
having to maintain an explicit list of what boards are associated with
which arch. We can also do things like have architecture maintainers
cover reviews and branches for arch/${ARCH} and boards/${ARCH} going
forward.
Change-Id: I02e0a30292b31fad58fb5dfab2682ad1c5a7d5a7
Signed-off-by: Kumar Gala <kumar.gala@linaro.org>
Ulf Magnusson