- 18 11月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Now kbuild core scripts create empty built-in.o where necessary. Remove "obj- := dummy.o" tricks. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 29 8月, 2016 1 次提交
-
-
由 Masahiro Yamada 提交于
The UniPhier architecture (32bit) switched over to PSCI. Remove the SoC-specific SMP operations. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 05 7月, 2016 1 次提交
-
-
由 Masahiro Yamada 提交于
Since the initial support of mach-uniphier, this has always been just empty. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 27 10月, 2015 1 次提交
-
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 12 5月, 2015 1 次提交
-
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 12 3月, 2015 2 次提交
-
-
由 Kumar Gala 提交于
Architectural changes in the ARM Linux kernel tree mandate the eventual removal of the mach-* directories. Move the scm driver to drivers/firmware and the scm header to include/linux to support that removal. Signed-off-by: NKumar Gala <galak@codeaurora.org>
-
由 Kumar Gala 提交于
Put all scm related code into a single file as a first step in cleaning up the scm interface to just expose functional behavior insteam of making direct scm calls. Signed-off-by: NKumar Gala <galak@codeaurora.org>
-
- 07 2月, 2014 1 次提交
-
-
由 Kumar Gala 提交于
Introduce a new mach-qcom that will support SoCs that intend to be multiplatform compatible while keeping mach-msm to legacy SoC/board support that will not transition over to multiplatform. As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over to mach-qcom. Signed-off-by: NKumar Gala <galak@codeaurora.org>
-