When we import code from Linux, with regular re-sync planned, we want
to use printk() and pr_*(). U-Boot does not support them in a clean
way. So, people end up with local macros, or compat headers here and
there, then we occasionally see build errors of definition conflicts.
We have include/linux/compat.h, but putting all sorts of unrelated
things into a single header is just a temporal workaround. Hence this
patch, to find the best home for all printk variants. If you want to
use printk() and friends, please include <linux/printk.h>. This header
is self-contained, and pulls in only a few headers.
When I was testing this clean-up, I noticed the image size exceeded
its platform limit on some boards. This is because all pr_*() that
were previously defined as no-op in include/linux/mtd/mtd.h (unless
CONFIG_MTD_DEBUG is set), are now enabled.
To make such boards happy, this commit also implements CONFIG_LOGLEVEL.
The concept is similar to the kernel parameter "loglevel". (Actually,
the Kconfig help message was taken from kernel-paremeter.txt of Linux)
Messages with a loglevel smaller than console loglevel will be printed.
The difference is the loglevel is build-time determined. To save the
image size, lower priority pr_*() are compiled out. I set the default
of CONFIG_LOGLEVEL to 6, i.e. pr_notice and higher priority messages
are compiled in.
I adjusted CONFIG_LOGLEVEL to avoid build error for some boards.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
[trini: Add in SPL_LOGLEVEL that is the same as LOGLEVEL]
Signed-off-by: Tom Rini <trini@konsulko.com>
It has been a while since ARM Trusted Firmware supported UniPhier SoC
family. U-Boot SPL was intended as a temporary loader that runs in
secure world. It is a maintenance headache to support two different
boot mechanisms. Secure firmware is realm of ARM Trusted Firmware
and now U-Boot only serves as a non-secure boot loader for UniPhier
ARMv8 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fix warnings reported by sparse:
- ... was not declared. Should it be static?"
- cast to restricted __be32
While fixing those, the type conflict of cci500_init() was found.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The SCP (System Control Processor) or what we call STM (Stand-by
MPU) is integrated in LD4, Pro4, sLD8, LD6b, LD11, and LD20.
For these SoCs, show the information if STM is enabled.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For LD11 and LD20 SoCs, the RST_n pin is asserted by default. If
the EXT_CSD[162], bit[1:0] (RST_n_ENABLE) is fused, the eMMC device
would stay in the reset state until its RST_n pin is deasserted by
software.
Currently, this is cared by an ad-hoc way because the eMMC hardware
reset provider is not supported in U-Boot for now. This code should
be re-written once the "mmc-pwrseq-emmc" binding is supported.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This parameter is redundant because we can know the number of
channels by checking if dram_ch[2].size is zero.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The current implementation has ugly switch statements here and there,
and duplicates similar code. Rework it using table lookups for SoC
data and reduce code duplication.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The base address of each DRAM channel can be calculated from other
parameters, so does not need hard-coding. What we need is the size
of each DRAM channel and DRAM_SPARSE flag to decide the start address
of DRAM channel 1.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
U-Boot needs to set up available memory area(s) in dram_init() and
dram_init_banksize(). It is platform-dependent how to detect the
memory banks. Currently, UniPhier adopts the memory banks _alleged_
by DT. This is based on the assumption that users bind a correct DT
in their build process.
Come to think of it, the DRAM controller has already been set up
before U-Boot is entered (because U-Boot runs on DRAM). So, the
DRAM controller setup register seems a more reliable source of any
information about DRAM stuff. The DRAM banks are initialized by
preliminary firmware (SPL, ARM Trusted Firmware BL2, or whatever),
so this means the source of the reliability is shifted from Device
Tree to such early-stage firmware. However, if the DRAM controller
is wrongly configured, the system will crash. If your system is
running, the DRAM setup register is very likely to provide the
correct DRAM mapping.
Decode the SG_MEMCONF register to get the available DRAM banks.
The dram_init() and dram_init_banksize() need similar decoding.
It would be nice if dram_init_banksize() could reuse the outcome
of dram_init(), but global variables are unavailable at this stage
because the .bss section is available only after the relocation.
As a result, SG_MEMCONF must be checked twice, but a new helper
uniphier_memconf_decode() will help to avoid code duplication.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Merge init-*.c into a single file using a table of callbacks because
the initialization flow is almost common among SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code here is cluttered due to the switch statement. Introduce a
table of callbacks to clean up the initialization code across SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, memconf-sld3.c and memconf-pxs2.c duplicate the code.
There are 3 patterns in terms of MEMCONF init:
- DRAM 2 channels: LD4, sLD8, Pro4, Pro5, LD11
- DRAM 3 channels: sLD3
- DRAM 3 channels (Ch2 is disable by MEMCONF[21]): Pxs2, LD20
All of them can be moved into a single file by a little more
refactoring.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The clock enable bits for UMC are more SoC-specific than for
the other hardware blocks. Separate the UMC clocks and the other
clocks for better code reuse across SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
At first, we thought the LD20 PLL setting would be board dependent,
but this argument turned out unneeded after all.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
- Initialize PLLs (SPL initializes only DPLL to save the precious
SPL memory footprint)
- Adjust CPLL/MPLL to the final tape-out frequency
- Set the Cortex-A53 clock to the maximum frequency since it is
running at 500MHz (SPLL/4) on startup
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Initialize the DPLL (PLL for DRAM) in SPL, and others in U-Boot
proper. Split the common code into pll-base-ld20.c for easier
re-use.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The PLL for the DRAM interface must be initialized in SPL, but the
others can be delayed until U-Boot proper. Move them from SPL to
U-Boot proper to save the precious SPL memory footprint.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This is the last code in the mach-uniphier/pinctrl/ directory.
Push the remaining code out to delete the directory entirely.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Use the pin-mux data in the pinctrl drivers by directly calling
pinctrl_generic_set_state().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The NAND subsystem has not supported the Driver Model yet, but the
NAND pin-mux data are already in the pinctrl drivers. Use them by
calling pinctrl_generic_set_state() directly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Unfortunately, this SoC needs per-board adjustment between clock
and address/command lines. This flag will be passed to the DRAM
init function and used for compensating the difference of DRAM
timing parameters.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, the UniPhier platform calls several init functions in the
following order:
[1] spl_board_init()
[2] board_early_init_f()
[3] board_init()
[4] board_early_init_r()
[5] board_late_init()
The serial console is not ready at the point of [2], so we want to
avoid using [2] from the view point of debuggability. Fortunately,
all of the initialization in [2] can be delayed until [3]. I see no
good reason to split into [3] and [4]. So, merge [2] through [4].
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I need to add more board attributes, so the "flags" member will be
handier than separate boolean ones.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The code in uniphier_sld3_sbc_init() is pin-muxing, so it would
be a better fit in uniphier_sld3_early_pin_init().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The System Bus is not available by default on the ROM boot mode of
PH1-LD20. To use devices connected to the System Bus, such as the
Micro Support Card, it is necessary to set up pin-muxing and some
System Bus Controller register.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Eliminate the "ph1"_ prefixes from function names because "uniphier_"
describes the SoC familiy better.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
There is a bunch of duplication in the System Bus Controller init
code. Roughly, there are two types in the SBC mode: Adress/Data
Multiplex Mode and Save Pins Mode. Consolidate per-SoC functions
into the two, plus per-SoC optional init code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Add a field to distinguish DDR3+ from (standard) DDR3. It also
allows to delete CONFIG_DDR_STANDARD (this is not a software
configuration, but a board attribute).
Default DDR3 spec for each SoC:
PH1-LD4, PH1-sLD8: DDR3+
Others: DDR3
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This commit reworks "struct uniphier_board_data" with an array of
DRAM channel data in it. It will allow further cleanups by means of
"for" statements that iterate over the DDR channels.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As mentioned in the log of commit 019df879a9 (ARM: uniphier: add
ProXstream2 and PH1-LD6b support), the DRAM init code was missing
for a long time. Finally, here it is. SPL works now.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These headers are only included locally in arch/arm/mach-uniphier/.
There is no reason to export them by putting in the mach/ directory.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2016-01-13 01:54:53 +09:00
Renamed from arch/arm/mach-uniphier/include/mach/init.h (Browse further)
