[U-Boot] [RFC PATCH 13/13] arm: nexell: switch to 32-bit

[Andre Przywara]

The vendor provided SPL blob (called "secondboot") runs completely in
AArch32, so expects U-Boot to be AArch32 as well.
Also the lack of a working arch timer limits Linux to 32-bits, as the
mainline arm64 kernel heavily relies on the arch timer.

This commit switches the NanoPiM3 board over to generate an ARM(32) binary,
to allow easy testing for now. Also this adds a README file to describe
the generation of a bootable SD card image.

Signed-off-by: Andre Przywara <andre.przywara at arm.com>
---
 arch/arm/Kconfig            |  2 +-
 arch/arm/mach-nexell/README | 49 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-nexell/README

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5c52344ca6..3b72528019 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -654,7 +654,7 @@ config ARCH_MX5
 
 config ARCH_NEXELL
 	bool "Nexell S5P support"
-	select ARM64
+	select CPU_V7
 	select ENABLE_ARM_SOC_BOOT0_HOOK
 	select OF_CONTROL
 	select DM
diff --git a/arch/arm/mach-nexell/README b/arch/arm/mach-nexell/README
new file mode 100644
index 0000000000..52bdb19b6b
--- /dev/null
+++ b/arch/arm/mach-nexell/README
@@ -0,0 +1,49 @@
+Booting
+-------
+
+U-Boot can be build as either a 32-bit binary (capable of loading 32-bit
+ARM OS kernels) or as a 64-bit binary, to launch 64-bit AArch64 kernels.
+The only difference in U-Boot is the selection of either CONFIG_ARM64
+or CONFIG_CPU_V7 in the ARCH_NEXELL Kconfig stanza in arch/arm/Kconfig.
+
+At the moment the U-Boot port does not support an SPL, so we need to rely
+on external loaders to initialize the DRAM and load U-Boot proper.
+
+Quick start
+-----------
+
+Download a GPLed version of the boot loader and compile it:
+$ git clone https://github.com/rafaello7/bl1-nanopi-m3.git
+$ cd bl1-nanopi-m3
+(edit config.mak to set OPMODE to "aarch32")
+$ make
+Make sure you have a 32-bit ARM (cross-)compiler installed, change the
+triplet name in config.mak if necessary.
+
+Then copy the resulting binary to an SD card, starting at the second sector:
+$ sudo dd if=out/bl1-nanopi.bin of=/dev/sdX bs=512 seek=1
+
+Now configure and build U-Boot, then copy the binary to sector 64:
+$ make nanopi_m3_defconfig
+$ make
+$ sudo dd if=u-boot.bin of=/dev/sdX bs=512 seek=64
+
+This will build a 32-bit AArch64 version of both the bootloader and U-Boot.
+
+To load 64-bit kernels, change config.mak in the bl1-nanopi-m3 repository
+to set the variable OPMODE back to "aarch64", then re-compile with an Aarch64
+cross compiler. To build a 64-bit version of U-Boot, revert the patch that
+switches the Nexell port to 32-bit. That selects CONFIG_ARM64 instead
+of CONFIG_CPU_V7. Then rebuild as "dd" to the SD card as described above.
+
+"secondboot"
+------------
+There is an official, but proprietary loader ("secondboot"), provided by
+Nexell. It can be found in "official" images, starting from sector 2
+(behind the MBR) and ranging until at most 32KB, though most versions seem
+to be shorter. This loader only supports 32-bit payloads. Also the boot
+protocol differs slightly, as the NSIH header (the first 512 byte of the
+U-Boot image) is cut off and the actual payload is loaded to the load address.
+This breaks U-Boot's assumption about its start address and will fail to boot.
+Interested people might add 512 to the the launch and load address in boot0.h
+to be able to use that boot loader.
-- 
2.14.1