-U-boot for arm64
+U-Boot for arm64
Summary
=======
-No hardware platform of arm64 is available now. The u-boot is
-simulated on Foundation Model and Fast Model for ARMv8.
+The initial arm64 U-Boot port was developed before hardware was available,
+so the first supported platforms were the Foundation and Fast Model for ARMv8.
+These days U-Boot runs on a variety of 64-bit capable ARM hardware, from
+embedded development boards to servers.
Notes
=====
-1. Currenly, u-boot run at the highest exception level processor
- supported and jump to EL2 or optionally EL1 before enter OS.
+1. U-Boot can run at any exception level it is entered in, it is
+ recommened to enter it in EL3 if U-Boot takes some responsibilities of a
+ classical firmware (like initial hardware setup, CPU errata workarounds
+ or SMP bringup). U-Boot can be entered in EL2 when its main purpose is
+ that of a boot loader. It can drop to lower exception levels before
+ entering the OS.
-2. U-boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
+2. U-Boot for arm64 is compiled with AArch64-gcc. AArch64-gcc
use rela relocation format, a tool(tools/relocate-rela) by Scott Wood
is used to encode the initial addend of rela to u-boot.bin. After running,
- the u-boot will be relocated to destination again.
+ the U-Boot will be relocated to destination again.
-3. Fdt should be placed at a 2-megabyte boundary and within the first 512
- megabytes from the start of the kernel image. So, fdt_high should be
- defined specially.
+3. Earlier Linux kernel versions required the FDT to be placed at a
+ 2 MB boundary and within the same 512 MB section as the kernel image,
+ resulting in fdt_high to be defined specially.
+ Since kernel version 4.2 Linux is more relaxed about the DT location, so it
+ can be placed anywhere in memory.
Please reference linux/Documentation/arm64/booting.txt for detail.
4. Spin-table is used to wake up secondary processors. One location
6. CONFIG_ARM64 instead of CONFIG_ARMV8 is used to distinguish aarch64 and
aarch32 specific codes.
-7. CONFIG_SYS_FULL_VA is used to enable 2-level page tables. For cores
- supporting 64k pages it allows usage of full 48+ virtual/physical addresses
- Enabling this option requires the following ones to be defined:
- - CONFIG_SYS_MEM_MAP - an array of 'struct mm_region' describing the
- system memory map (start, length, attributes)
- - CONFIG_SYS_MEM_MAP_SIZE - number of entries in CONFIG_SYS_MEM_MAP
- - CONFIG_SYS_PTL1_ENTRIES - number of 1st level page table entries
- - CONFIG_SYS_PTL2_ENTRIES - number of 1nd level page table entries
- for the largest CONFIG_SYS_MEM_MAP entry
- - CONFIG_COREID_MASK - the mask value used to get the core from the
- MPIDR_EL1 register
- - CONFIG_SYS_PTL2_BITS - number of bits addressed by the 2nd level
- page tables
- - CONFIG_SYS_BLOCK_SHIFT - number of bits addressed by a single block
- entry from L2 page tables
- - CONFIG_SYS_PGTABLE_SIZE - total size of the page table
- - CONFIG_SYS_TCR_EL{1,2,3}_IPS_BITS - the IPS field of the TCR_EL{1,2,3}
-
-
-
-
-Contributor
-===========
+Contributors
+============
Tom Rini <trini@ti.com>
Scott Wood <scottwood@freescale.com>
York Sun <yorksun@freescale.com>