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>
PH1-LD20 does not have the dedicated boot swap select latch.
Instead, it is controlled from the boot mode select.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The current table look-up for the DTB file name turned out bothersome
in terms of maintainability; I ended up adding a new entry every time
a new board is supported.
There is a common pattern between the DT compatible string and the
corresponding file name; drop the vendor prefix "socionext," and
prefix it with "uniphier-" and suffix it with ".dtb".
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
No need to stop booting U-Boot even if boot mode is unknown.
Setting the "bootmode" environment is only useful for booting
Linux Kernel. Anyway, U-Boot has already booted by this point.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For PH1-LD20 or later, per-pin input-enable control is supported,
that is, we need to set-up IECTRL registers for a group of pins.
This helper function will be useful for a bunch of register settings.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Because DT properties are 4-byte aligned, the pointer access
*(fdt64_t *) in this code causes unaligned access.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
v7_maint_dcache_all() does not work reliable when build with gcc6,
see: https://bugzilla.redhat.com/show_bug.cgi?id=1318788
While debugging this I learned that v7_maint_dcache_all() is unreliable
when build with gcc5 too when it is marked as noinline.
This commit fixes the reliability issues by replacing the C-code with
the ready to use asm implementation from the kernel.
Given that this code when written as C-code clearly is quite fragile
(also see the existing comments about the C-code being the way it is
to get optimal assembly) and that we have a proven asm alternative,
I believe that this is the best solution.
Note that we actually already had a copy of the kernel's
v7_flush_dcache_all() before this commit in
arch/arm/mach-uniphier/arm32/lowlevel_init.S.
This commit moves that code arch/arm/cpu/armv7/cache_v7_asm.S, renames
it to __v7_flush_dcache_all(), and adds a v7_flush_dcache_all() wrapper
which saves / restores the clobbered registers for use from C-code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-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>
Currently, these functions assume #address-cells and #size-cells are
both one. Fix them to support 64bit DTB.
Also, I am fixing a buffer overrun bug while I am here. The array
size of gd->bd->bd_dram is CONFIG_NR_DRAM_BANKS. The number of
iteration in the loop should be limited by that CONFIG.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This allows to boot from NOR flash (or SRAM) with help of an external
loader (NOR-loader).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
For ARM32 architecture, CONFIG_DEBUG_LL is available for early
low-level debugging (and actually UniPhier 32bit SoCs use it), but
ARM64 architecture does not support it. Instead, CONFIG_DEBUG_UART
is available as an architecture-independent debug facility.
This commit supports it on all the UniPhier SoCs (including the new
ARMv8 SoCs), which is very useful for new SoC bringups.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The System Control block moved to a completely different register
map for ARMv8 SoCs, so it cannot be shared with the ARM 32-bit ones.
Define register macros in a new header file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This helper function would be useful for new SoCs with per-pin
input enable controlling, such as PH1-LD20, PH1-LD11, etc.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These commands are not necessarily needed for usual operations
(they are useful in case of DDR memory trouble), but enabling them
by default would be nice in terms of the compilation test coverage.
They are small enough, so limited impact on the memory footprint.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Due to some hardware guy's awful work, this version is not compatible
with v3.6: the logic of BIT(0) of the reset logic is inverted! (and
v3.6.10 is horribly wrong in multiple ways), but this is what we have
to solve now.
The v3.6 expects 0x0000 set to the register for reset de-assertion,
while v3.6 does 0x0001.
This commit (ab)uses another bug of v3.6.10 to work around the issue.
The UniPhier System Bus is a 16-bit bus, which this support card is
connected to. A 32-bit write to the bus (writel() function call) is
divided into two 16-bit write transactions, with LSB the first. What
is amazing for v3.6.10 is that access to address 4N + 2 goes to 4N
(Jesus Christ!).
For clarification, things are like this:
writel(0x00010000, MICRO_SUPPORT_CARD_RESET);
is done with two bus transactions as follows
[1] write 0x0000 to address MICRO_SUPPORT_CARD
[2] write 0x0001 to address MICRO_SUPPORT_CARD + 2
For v3.6, [1] is written to the register and [2] is correctly ignored
because there is nothing at the address MICRO_SUPPORT_CARD + 2. This
is what we expect.
For v3.6.10, [1] is written to the reset register and then [2] is
over-written to the same register due to the bus access bug.
For the latter, it produces a glitch signal to the BIT[0], so the
device state is lost due to the reset pulse. This solution only
works for the start-up code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The ifdef conditionals in header files prevent us from multi-SoC
support in a single U-Boot image. Detect SoC specific parameters
run-time rather than define them statically with an ifdef in
ddrphy-regs.h.
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>
The current CONFIG names like "CONFIG_ARCH_UNIPHIER_PH1_PRO4" is too
long. It would not hurt to drop "PH1_" because "UNIPHIER_" already
well specifies the SoC family. Also, rename files for consistency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This function should just return for unknown SoCs rather than writing
unexpected values to registers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The UniPhier SoC family has not supported ARMv8 yet, but these would
cause warnings if they were compiled with a 64bit compiler. Before
adding the ARMv8 support really, fix them now.
Because UniPhier SoCs do not support Large Physical Address Extension,
casting "phys_addr_t" into "unsigned long" would carry the address
as is.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Before adding ARMv8 support, this commit refactors the directory
structure. Move ARMv7 specific files to arch/arm/mach-uniphier/arm32
to avoid a mess by mixture of ARMv7 and ARMv8 code. Also move the
"select CPU_V7" to the lower-level menu because we will have to
select ARM64 instead of CPU_V7 for ARMv8 SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Due to the company's awful projecting, PH1-LD10 and PH1-sLD11 have
been renamed to PH1-LD20 and PH1-LD11, respectively.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The chains of "depends on <SoC_name>" in the current Kconfig is
clumsy. The idea here is to allow users to choose a SoC group first
(SoC group consists of some SoCs that can coexist in one binary).
Then, allow to enable/disable each SoC support in the selected SoC
group. This makes the Kconfig menu clearer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These macros are no longer used. These base addresses are
SoC-dependent, so they should not be placed in the header.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, DRAM size is converted twice:
size in byte -> size in Gbit -> enum
Optimize the code by converting the "size in byte" into enum directly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The if-else statements for the frequency-dependent register settings
seem clumsy. Moving them to arrays would make it cleaner.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The DDR PHY settings no longer depend on the DRAM size. Drop the
argument from the init function.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now these three are almost the same. The only difference is the DTPR1
register dependency on the DRAM size, but it can be ignored. (It has
already been ignored in PH1-sLD8 and PH1-Pro4.)
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>
These settings control the clocks around the memory controller.
The debug ability is unneeded once it works properly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
These settings were used only for the PH1-sLD3 and older SoCs. The
PH1-LD4 and newer one just ignore them because their DDR-PHY take
care of such timing parameters instead.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Currently, a dummy value is defined for the UMC_SPCCTLA register
when the DRAM size is zero. This seems weird because the controller
does not need setting in the first place if the size is zero.
Also, redefine enum dram_size to represent the DRAM size per 16-bit
unit. This makes things simpler because the channel 0 and 1 are
connected with 32-bit width DRAM, while the channel 2 is connected
with 16-bit width one.
I am renaming SIZE_* into DRAM_SZ_* (and also FREQ_* to DRAM_FREQ_*
for consistency) while I am here because SIZE_* might be easily
mixed-up with the macros in include/linux/sizes.h.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Now this code can be re-written with a "for" statement instead of
calling the same function multiple times.
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>
Robert P. J. Day