The NI 169445 board uses a little endian MIPS32r2 CPU, and therefore
including board support in kernels that are unable to run on such a CPU
is pointless.

Specify requirements in the board config fragment that cause the NI
169445 board support to only be included in generic kernels that target
little endian MIPS32r2 CPUs.

For example, NI 169445 support will be included when configuring using
32r2el_defconfig but not when using 64r6_defconfig.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Acked-by: NNathan Sullivan <nathan.sullivan@ni.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16945/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The MIPS SEAD-3 development board has only ever been used with 32 bit
CPUs, so including support for it in 64 bit kernels is wasteful since
those kernels will never run on a SEAD-3.

Specify a requirement in the SEAD-3 board config fragment that ensures
the board support is only included in 32 bit kernels, by checking that
CONFIG_32BIT=y.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16944/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Support the National Instruments 169445 board.
Signed-off-by: NNathan Sullivan <nathan.sullivan@ni.com>
Acked-by: NRob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16782/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add support for the MIPS Boston development board to generic kernels,
which essentially amounts to:

  - Adding the device tree source for the MIPS Boston board.

  - Adding a Kconfig fragment which enables the appropriate drivers for
    the MIPS Boston board.

With these changes in place generic kernels will support the board by
default, and kernels with only the drivers needed for Boston enabled can
be configured by setting BOARDS=boston during configuration. For
example:

  $ make ARCH=mips 64r6el_defconfig BOARDS=boston
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Reviewed-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16485/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Convert the MIPS SEAD-3 board support to be a generic board, supported
by generic kernels.

Because the SEAD-3 boot protocol was defined long ago and we don't want
to force a switch to the UHI protocol, SEAD-3 is added as a legacy board
which is detected by reading the REVISION register. This may technically
not be a valid memory read & future work will include attempting to
handle that gracefully. In practice since SEAD-3 is the only legacy
board supported by the generic kernel so far the read will only happen
on SEAD-3 boards, and even once Malta is converted the same REVISION
register exists there too. Other boards such as Boston, Ci20 & Ci40 will
use the UHI boot protocol & thus not run any of the legacy board detect
functions.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14354/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Introduce a "generic" platform, which aims to be board-agnostic by
making use of device trees passed by the boot protocol defined in the
MIPS UHI (Universal Hosting Interface) specification. Provision is made
for supporting boards which use a legacy boot protocol that can't be
changed, but adding support for such boards or any others is left to
followon patches.

Right now the built kernels expect to be loaded to 0x80100000, ie. in
kseg0. This is fine for the vast majority of MIPS platforms, but
nevertheless it would be good to remove this limitation in the future by
mapping the kernel via the TLB such that it can be loaded anywhere & map
itself appropriately.

Configuration is handled by dynamically generating configs using
scripts/kconfig/merge_config.sh, somewhat similar to the way powerpc
makes use of it. This allows for variations upon the configuration, eg.
differing architecture revisions or subsets of driver support for
differing boards, to be handled without having a large number of
defconfig files.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14353/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>