src/sys/arm/include/cpuconf.h, branch releng/13.3FreeBSD source treehttps://cgit-dev.freebsd.org/src/atom?h=releng%2F13.32017-01-16T16:44:13ZRemove arm's cpuconf.h, and references to it, after moving a few lines from2017-01-16T16:44:13ZIan Leporeian@FreeBSD.org2017-01-16T16:44:13Zurn:sha1:3b9a898298abbf50c832a76a8485d0dcbffa6e9e
it into pmap-v4.h where they are used. Other than those few lines of
support for different MMU types, nothing in cpuconf.h has been used in our
code for quite a while.
The file existed to set up a variety of symbols to describe the
architecture. Over the past few years we have converted all of our source
to use the new architecture symbols standardized by ARM Inc, and predefined
by both clang and gcc.
PR: 216104
Split CPU_CORTEXA into CPU_CORTEXA8, for the Cortex-A8, and CPU_CORTEXA_MP,2016-10-04T12:25:44ZAndrew Turnerandrew@FreeBSD.org2016-10-04T12:25:44Zurn:sha1:1834282de6b9f6fd30291bfe1cc9c3ecf5547c40
for later Cortex-A CPUs that support the Multiprocessor Extensions. This
will be needed to support both in a single GENERIC kernel while still
being able to only build for a single SoC.
Reviewed by: mmel
Relnotes: yes
Sponsored by: ABT Systems Ltd
Differential Revision: https://reviews.freebsd.org/D8138
ARM: Remove support for xscale i80219 and i80321 CPUs. We haven't single2016-02-03T09:15:44ZMichal Melounmmel@FreeBSD.org2016-02-03T09:15:44Zurn:sha1:afdcfee48364e2f5bf4ae7796009220de20d36c4
supported config/board with these CPUs.
Remove support for CPU_XSCALE_80200. None of our configs support it, and2015-03-30T09:29:45ZAndrew Turnerandrew@FreeBSD.org2015-03-30T09:29:45Zurn:sha1:a3db11e053606ac7fe5d6873d44d59d1d0d3a6d7
there wasn;t an option to enable it.
While here remove a check for CPU_ARM10 being defined as it has also been
removed.
Remove support for CPU_FA626TE. It's unused by any of our kernel configs.2015-03-30T08:38:18ZAndrew Turnerandrew@FreeBSD.org2015-03-30T08:38:18Zurn:sha1:303c8079abb93f2d6a8eb3aa475cf5feaa2c2022Remove arm1136 support. We don't have any configs that use it, and I don't2015-03-29T21:12:59ZAndrew Turnerandrew@FreeBSD.org2015-03-29T21:12:59Zurn:sha1:930798f3a15a792ac7ec1e2f5d8e92b191723d55
expect us to add support for any more arm11 SoCs.
Revert a glitched mismerge that got caught up in the prior commit.2014-12-24T03:09:55ZIan Leporeian@FreeBSD.org2014-12-24T03:09:55Zurn:sha1:0236b3314fc11e041f52cccc0a4ed29724dc0542
The PJ4B family is still armv7, not armv6.
Define the old-school arm arch constants we still use internally based on2014-12-24T03:02:12ZIan Leporeian@FreeBSD.org2014-12-24T03:02:12Zurn:sha1:6783238b2deea7acaf2f83745b864263f701536c
the somewhat newer constants predefined by the compiler. This will allow
userland apps to use various machine/foo.h headers without CPUTYPE defined.
The arm PJ4B cpu is armv7 architecture, not v6.2014-11-24T01:13:58ZIan Leporeian@FreeBSD.org2014-11-24T01:13:58Zurn:sha1:378781576156692bdea094f5b7c9b28d8b3042da
If this feels like deja vu... the last time this was fixed in this file
only ARM_MMU_V6 was fixed, this time it's ARM_ARCH_V6 (and this time I
searched for other occurrances of pj4b in here).
The Marvell PJ4B cpu family is armv7, not armv6.2014-08-31T15:23:49ZIan Leporeian@FreeBSD.org2014-08-31T15:23:49Zurn:sha1:46dd56e7818fa44275a415d2143a9a3aa8de8f5b