summaryrefslogtreecommitdiff
path: root/arch/arm/mach-uniphier/boot-mode
Commit message (Collapse)AuthorAgeLines
* common: Pass the boot device into spl_boot_mode()Marek Vasut2016-06-26-1/+1
| | | | | | | | | | | | | | | | | | The SPL code already knows which boot device it calls the spl_boot_mode() on, so pass that information into the function. This allows the code of spl_boot_mode() avoid invoking spl_boot_device() again, but it also lets board_boot_order() correctly alter the behavior of the boot process. The later one is important, since in certain cases, it is desired that spl_boot_device() return value be overriden using board_boot_order(). Signed-off-by: Marek Vasut <marex@denx.de> Cc: Andreas Bießmann <andreas.devel@googlemail.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Andreas Bießmann <andreas@biessmann.org> [add newly introduced zynq variant] Signed-aff-by: Andreas Bießmann <andreas@biessmann.org>
* ARM: uniphier: fix boot mode for PH1-LD11Masahiro Yamada2016-06-09-1/+18
| | | | | | | This function is shared between PH1-LD11 and PH1-LD20. The difference is the boot-mode latch for the USB boot mode. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: support eMMC boot for PH1-LD11 and PH1-LD20Masahiro Yamada2016-06-09-3/+154
| | | | | | | | The Boot ROM on PH1-LD11/LD20 exports built-in APIs to load images from an eMMC device. They are useful to reduce the memory footprint of SPL, rather than compiling the whole MMC framework. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add PH1-LD11 SoC supportMasahiro Yamada2016-05-26-2/+5
| | | | | | This is a low-cost ARMv8 SoC from Socionext Inc. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: clean up boot mode tablesMasahiro Yamada2016-05-26-13/+13
| | | | | | Tidy up alignment of open parentheses. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* Fix various typos, scattered over the code.Robert P. J. Day2016-05-05-1/+1
| | | | | | | | | | | | | Spelling corrections for (among other things): * environment * override * variable * ftd (should be "fdt", for flattened device tree) * embedded * FTDI * emulation * controller
* ARM: uniphier: fix boot mode table of PH1-LD20Masahiro Yamada2016-05-01-1/+1
| | | | | | | 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>
* ARM: uniphier: add PH1-LD20 SoC supportMasahiro Yamada2016-04-24-0/+89
| | | | | | This is the first ARMv8 SoC from Socionext Inc. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: rename function names ph1_* to uniphier_*Masahiro Yamada2016-04-01-24/+24
| | | | | | | Eliminate the "ph1"_ prefixes from function names because "uniphier_" describes the SoC familiy better. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add NOR boot supportMasahiro Yamada2016-03-24-2/+2
| | | | | | | 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>
* ARM: uniphier: drop PH1- prefix from CONFIG options and file namesMasahiro Yamada2016-03-24-35/+31
| | | | | | | | 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>
* ARM: uniphier: default to environment in eMMCMasahiro Yamada2016-02-29-0/+5
| | | | | | | Of the several boot devices supported, it looks like the eMMC is the most commonly used. Enable CONFIG_ENV_IS_IN_MMC by default. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add a command to find the first MMC (non-SD) deviceMasahiro Yamada2016-02-29-0/+34
| | | | | | | | | | | UniPhier SoC family supports both (e)MMC boot and SD card boot; however, both of them are handled in the same uclass. When booting from the eMMC, we want to know the device number of the (e)MMC, not SD. This command is useful to find the first MMC (non-SD) device. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add eMMC boot supportMasahiro Yamada2016-02-29-0/+25
| | | | | | | | Export device nodes needed for eMMC boot (eMMC node, pinctrl, and clock) to the SPL DTB. CONFIG_SUPPORT_EMMC_BOOT is also necessary to use "mmc partconf" command. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: support USB boot mode for ProXstream2 / PH1-LD6b SoCMasahiro Yamada2016-02-14-1/+15
| | | | | | | | | | | | | | | | | | The USB boot code is too fat and complicated to be included in SPL (at least for now). So, it was implemented as a separate project (what we call USB-loader). The expected boot sequence is as follows: Boot ROM -> USB-loader -> SPL -> U-Boot proper The USB-loader loads the SPL and U-Boot proper from a USB memory onto the locked L2 cache. Then, SPL needs to copy the U-Boot proper to DRAM, so this mode looks like a NOR boot from the view of SPL. However, we want to distinguish between (genuine) NOR boot and USB boot in some places. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add missing static qualifierMasahiro Yamada2016-02-14-1/+1
| | | | | | This function is for local use in the file. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: move headers out of include/mach directoryMasahiro Yamada2016-01-13-14/+45
| | | | | | | 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>
* ARM: uniphier: move cmd_pinmon.c to boot-mode subdirectoryMasahiro Yamada2016-01-13-0/+56
| | | | | | | This command shows the boot mode pins, so it would be more at home in the boot-mode subdirectory. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: kill bogus header includesMasahiro Yamada2016-01-13-6/+0
| | | | | | These includes are not necessary. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* Various Makefiles: Add SPDX-License-Identifier tagsTom Rini2015-11-10-0/+4
| | | | | | | | | | | After consulting with some of the SPDX team, the conclusion is that Makefiles are worth adding SPDX-License-Identifier tags too, and most of ours have one. This adds tags to ones that lack them and converts a few that had full (or in one case, very partial) license blobs into the equivalent tag. Cc: Kate Stewart <kstewart@linuxfoundation.org> Signed-off-by: Tom Rini <trini@konsulko.com>
* ARM: uniphier: add ProXstream2 and PH1-LD6b supportMasahiro Yamada2015-09-25-0/+83
| | | | | | | The DDR SDRAM initialization code has not been mainlined yet, but U-Boot proper should work. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: add PH1-Pro5 supportMasahiro Yamada2015-09-25-0/+80
| | | | | | | The DDR SDRAM initialization code has not been mainlined yet, but U-Boot proper should work. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
* ARM: uniphier: allow to enable multiple SoCsMasahiro Yamada2015-09-25-0/+221
Before this commit, the Kconfig menu in mach-uniphier only allowed us to choose one SoC to be compiled. Each SoC has its own defconfig file for the build-test coverage. Consequently, some defconfig files are duplicated with only the difference in CONFIG_DEFAULT_DEVICE_TREE and CONFIG_{SOC_NAME}=y. Now, most of board-specific parameters have been moved to device trees, so it makes sense to include init code of multiple SoCs into a single image as long as the SoCs have similar architecture. In fact, some SoCs of UniPhier family are very similar: - PH1-LD4 and PH1-sLD8 - PH1-LD6b and ProXstream2 (will be added in the upcoming commit) This commit will be helpful to merge some defconfig files for better maintainability. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>