On Fri, Apr 01, 2016 at 09:14:15PM -0600, Stephen Warren wrote:
On all Pis so far, the VC FW provides a short stub to set up the ARM CPU before entering the kernel (a/k/a U-Boot for us). This feature is not currently supported by the VC FW when booting in 64-bit mode. However, this feature will likely appear in the near future, and this U-Boot port assumes that such a feature is in place. Without that feature, or a temporary workaround described below, U-Boot will not boot.
Once the VC FW does provide the ARM stub, u-boot.bin built for rpi_3 can be used drectly as kernel7.img, in the same way as any other RPi port. The following config.txt is required:
# Fix mini UART input frequency, and setup/enable up the UART. # Without this option, U-Boot will not boot, even if you don't care # about the serial console. This option will always be required for # all RPi3 use-cases, unless the PL011 UART is used, which is not # yet supported by rpi_3* builds of U-Boot. enable_uart=1 # Boot in AArch64 (64-bit) mode. # It is possible that a future VC FW will remove the need for this # option, instead auto-setting 32-/64-bit mode based on the "kernel" # filename present on the SD card. arm_control=0x200Prior to the VC FW providing the ARM boot stub, you can use the following steps to build an equivalent stub into the U-Boot binary:
git clone https://github.com/swarren/rpi-3-aarch64-demo.git \ ../rpi-3-aarch64-demo (cd ../rpi-3-aarch64-demo && ./build.sh) Build U-Boot for rpi_3 in the usual way cat ../rpi-3-aarch64-demo/armstub64.bin u-boot.bin > u-boot.bin.stubbed Use u-boot.bin.stubbed as kernel7.img on the Pi SD card.
In this case, the following additional entries are required in config.txt:
# Tell the FW to load the kernel image at address 0, the reset vector. kernel_old=1Signed-off-by: Stephen Warren swarren@wwwdotorg.org
As our infrastructure stands today: Reviewed-by: Tom Rini trini@konsulko.com
But would it be possible to clean things up and consolidate files? If CONFIG_SYS_CACHLINE_SIZE and CONFIG_SKIP_LOWLEVEL_INIT were in Kconfig it looks like everything could live in board/raspberrypi/rpi/ which it nearly does today. If it's hard, I'd be OK punting that to v2015.07. Or am I missing something?