Now the user can select the CPU type for each target. Thus
CONFIG_SYS_CPU could be set globally.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Now the types of CONFIG_SYS_{ARCH, CPU, SOC, VENDOR, BOARD, CONFIG_NAME}
are specified in arch/Kconfig.
We can delete the ones in arch and board Kconfig files.
This commit can be easily reproduced by the following command:
find . -name Kconfig -a ! -path ./arch/Kconfig | xargs sed -i -e '
/config[[:space:]]SYS_\(ARCH\|CPU\|SOC\|\VENDOR\|BOARD\|CONFIG_NAME\)/ {
N
s/\n[[:space:]]*string//
}
'
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
We have switched to Kconfig and the boards.cfg file is going to
be removed. We have to retrieve the board status and maintainers
information from it.
The MAINTAINERS format as in Linux Kernel would be nice
because we can crib the scripts/get_maintainer.pl script.
After some discussion, we chose to put a MAINTAINERS file under each
board directory, not the top-level one because we want to collect
relevant information for a board into a single place.
TODO:
Modify get_maintainer.pl to scan multiple MAINTAINERS files.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
This commit adds:
- arch/${ARCH}/Kconfig
provide a menu to select target boards
- board/${VENDOR}/${BOARD}/Kconfig or board/${BOARD}/Kconfig
set CONFIG macros to the appropriate values for each board
- configs/${TARGET_BOARD}_defconfig
default setting of each board
(This commit was automatically generated by a conversion script
based on boards.cfg)
In Linux Kernel, defconfig files are located under
arch/${ARCH}/configs/ directory.
It works in Linux Kernel since ARCH is always given from the
command line for cross compile.
But in U-Boot, ARCH is not given from the command line.
Which means we cannot know ARCH until the board configuration is done.
That is why all the "*_defconfig" files should be gathered into a
single directory ./configs/.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Whilst U-boot does not require this itself, Linux currently relies upon
it having been muxed and enabled by the bootloader. Thus in order to
preserve compatibility with current kernels before a fix is merged in
Linux we will enable the SERIRQ interrupt and mux it to its pin.
Without doing this current kernels will never receive serial port
interrupts and the end result is typically that userland appears to
hang.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
This patch adds a script which may be used with MIPS Navigator Console
and a MIPS Nagivator Probe in order to flash U-boot to a MIPS Malta
development board.
Please see the newly added doc/README.malta for usage instructions.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Without setting up the PIRQ[A:D] interrupt routes, PCI interrupts will
be left disabled. Linux does not set up this routing but relies upon it
having been set up by the bootloader, reading back the IRQ lines which
the PIRQ[A:D] signals have been routed to.
This patch routes PIRQA & PIRQB to IRQ 10, and PIRQC & PIRQD to IRQ 11.
This matches the setup used by YAMON.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
This is actually required in order for a Linux kernel to boot
successfully on a physical Malta board. Without enabling the RTC, a
Malta Linux kernel will get stuck in its estimate_frequencies function
on boot.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Malta boards may be used with cores which support L2 caches, however
U-boot does not yet support L2 cache for MIPS. Thus for the moment we'll
disable L2 caches by setting the L2B bit in Config2. This is specific to
MTI/Imagination MIPS cores which is why this is done for the Malta board
rather than generically.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Displaying a message on the LCD screen is a simple yet effective way to
show the user that the board has booted successfully.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
This patch adds support for running on Malta boards using coreFPGA6
core cards, including support for the msc01 system controller used
with them. The system controller is detected at runtime allowing one
U-boot binary to run on a Malta with either.
Due to the PCI I/O base differing between Maltas using gt64120 & msc01
system controllers, the UART setup is modified slightly. A second UART
is added so that there is one pointing at the correct address for each
system controller. The Malta board then defines its own
default_serial_console function to select the correct one at runtime.
The incorrect UART will simply not function.
Tested on:
- A coreFPGA6 Malta running interAptiv and proAptiv bitstreams, both
with and without an L2 cache.
- QEMU.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
On a real Malta the Super I/O needs to be configured before we are able
to access the UARTs. This patch performs that configuration, setting up
the UARTs in the same way that YAMON would.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
This is in preparation for adapting this board to function correctly on
a physical MIPS Malta board. The board is moved into an "imgtec" vendor
directory at the same time in order to ready us for any other boards
supported by Imagination in the future.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
