| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The complexity of the boot sequence of UniPhier SoC family is
a PITA due to the following hardware limitations:
[1] No dedicated on-chip SRAM
SoCs in general have small SRAM, on which a tiny firmware or a boot
loader can run before SDRAM is initialized. As UniPhier SoCs do not
have any dedicated SRAM accessible from CPUs, the locked outer cache
is used instead. Due to the ARM specification, to have access to
the outer cache, the MMU must be enabled. This is done for all CPU
cores by the program hard-wired in the boot ROM. The boot ROM code
loads a small amount of program (this is usually SPL of U-Boot) from
a non-volatile device onto the locked outer cache, and the primary
CPU jumps to it. The secondary CPUs stay in the boot ROM until they
are kicked by the primary CPU.
[2] CPUs can not directly jump to SDRAM address space
As mentioned above, the MMU is enable for all the CPUs with the page
table hard-wired in the boot ROM. Unfortunately, the page table only
has minimal sets of valid sections; all the sections of SDRAM address
space are zero-filled. That means all the CPUs, including secondary
ones, can not jump directly to SDRAM address space. So, the primary
CPU must bring up secondary CPUs to accessible address mapped onto
the outer cache, then again kick them to SDRAM address space.
Before this commit, this complex task was done with help of a boot
loader (U-Boot); U-Boot SPL brings up the secondary CPUs to the entry
of U-Boot SPL and they stay there until they are kicked by Linux.
This is not nice because a boot loader must put the secondary CPUs
into a certain state expected by the kernel. It makes difficult to
port another boot loader because the boot loader and the kernel must
work in sync to wake up the secondary CPUs.
This commit reworks the SMP operations so that they do not rely on
particular boot loader implementation; the SMP operations (platsmp.c)
put trampoline code (headsmp.S) on a locked way of the outer cache.
The secondary CPUs jump from the boot ROM to secondary_entry via the
trampoline code. The boot loader no longer needs to take care of SMP.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
| |
|
|
|
|
|
|
| |
This is unnecessary since commit 02b4e2756e01 ("ARM: v7 setup
function should invalidate L1 cache").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This makes uniphier behave like all the other platforms that
support TWD, and only select this driver when SMP is enabled.
Without this, we get a compile error on UP builds:
arch/arm/kernel/smp_twd.c: In function 'twd_local_timer_of_register':
arch/arm/kernel/smp_twd.c:391:20: error: 'setup_max_cpus' undeclared (first use in this function)
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
|
Initial commit for a new SoC family, UniPhier, developed by
Socionext Inc. (formerly, System LSI Business Division of
Panasonic Corporation).
This commit includes a minimal set of components for booting the
kernel, including SMP support.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
