On 17:26 Fri 07 Sep , Catalin Marinas wrote: > The patch adds the kernel booting and the initial setup code. > Documentation/arm64/booting.txt describes the booting protocol on the > AArch64 Linux kernel. This is subject to change following the work on > boot standardisation, ACPI. > > Signed-off-by: Will Deacon <will.deacon@xxxxxxx> > Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx> > Acked-by: Nicolas Pitre <nico@xxxxxxxxxx> > Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> > --- > Documentation/arm64/booting.txt | 152 ++++++++++++ > arch/arm64/include/asm/setup.h | 26 ++ > arch/arm64/kernel/head.S | 510 +++++++++++++++++++++++++++++++++++++++ > arch/arm64/kernel/setup.c | 351 +++++++++++++++++++++++++++ > 4 files changed, 1039 insertions(+), 0 deletions(-) > create mode 100644 Documentation/arm64/booting.txt > create mode 100644 arch/arm64/include/asm/setup.h > create mode 100644 arch/arm64/kernel/head.S > create mode 100644 arch/arm64/kernel/setup.c > > diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt > new file mode 100644 > index 0000000..9c4d388 > --- /dev/null > +++ b/Documentation/arm64/booting.txt > @@ -0,0 +1,152 @@ > + Booting AArch64 Linux > + ===================== > + > +Author: Will Deacon <will.deacon@xxxxxxx> > +Date : 07 September 2012 > + > +This document is based on the ARM booting document by Russell King and > +is relevant to all public releases of the AArch64 Linux kernel. > + > +The AArch64 exception model is made up of a number of exception levels > +(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure > +counterpart. EL2 is the hypervisor level and exists only in non-secure > +mode. EL3 is the highest priority level and exists only in secure mode. > + > +For the purposes of this document, we will use the term `boot loader' > +simply to define all software that executes on the CPU(s) before control > +is passed to the Linux kernel. This may include secure monitor and > +hypervisor code, or it may just be a handful of instructions for > +preparing a minimal boot environment. > + > +Essentially, the boot loader should provide (as a minimum) the > +following: > + > +1. Setup and initialise the RAM > +2. Setup the device tree > +3. Decompress the kernel image > +4. Call the kernel image > + > + > +1. Setup and initialise RAM > +--------------------------- > + > +Requirement: MANDATORY > + > +The boot loader is expected to find and initialise all RAM that the > +kernel will use for volatile data storage in the system. It performs > +this in a machine dependent manner. (It may use internal algorithms > +to automatically locate and size all RAM, or it may use knowledge of > +the RAM in the machine, or any other method the boot loader designer > +sees fit.) > + > + > +2. Setup the device tree > +------------------------- > + > +Requirement: MANDATORY > + > +The device tree blob (dtb) must be no bigger than 2 megabytes in size > +and placed at a 2-megabyte boundary within the first 512 megabytes from > +the start of the kernel image. This is to allow the kernel to map the > +blob using a single section mapping in the initial page tables. why do you want to restrict the DT to be less tahn 2MiB? > + > + > +3. Decompress the kernel image > +------------------------------ > + > +Requirement: OPTIONAL > + > +The AArch64 kernel does not currently provide a decompressor and > +therefore requires decompression (gzip etc.) to be performed by the boot > +loader if a compressed Image target (e.g. Image.gz) is used. For > +bootloaders that do not implement this requirement, the uncompressed > +Image target is available instead. > + > + > +4. Call the kernel image > +------------------------ > + > +Requirement: MANDATORY > + > +The decompressed kernel image contains a 32-byte header as follows: > + > + u32 magic = 0x14000008; /* branch to stext, little-endian */ > + u32 res0 = 0; /* reserved */ > + u64 text_offset; /* Image load offset */ > + u64 res1 = 0; /* reserved */ > + u64 res2 = 0; /* reserved */ we need to have a magic to known it's a arm64 kernel > + > +The image must be placed at the specified offset (currently 0x80000) > +from the start of the system RAM and called there. The start of the > +system RAM must be aligned to 2MB. can we drop this > + > +Before jumping into the kernel, the following conditions must be met: > + > +- Quiesce all DMA capable devices so that memory does not get > + corrupted by bogus network packets or disk data. This will save > + you many hours of debug. > + > +- Primary CPU general-purpose register settings > + x0 = physical address of device tree blob (dtb) in system RAM. > + x1 = 0 (reserved for future use) > + x2 = 0 (reserved for future use) > + x3 = 0 (reserved for future use) > + > +- CPU mode > + All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, > + IRQ and FIQ). > + The CPU must be in either EL2 (RECOMMENDED in order to have access to > + the virtualisation extensions) or non-secure EL1. > + > +- Caches, MMUs > + The MMU must be off. > + Instruction cache may be on or off. > + Data cache must be off and invalidated. > + External caches (if present) must be configured and disabled. > + > +- Architected timers > + CNTFRQ must be programmed with the timer frequency. > + If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) > + set where available. can you explain why? > + > +- Coherency > + All CPUs to be booted by the kernel must be part of the same coherency > + domain on entry to the kernel. This may require IMPLEMENTATION DEFINED > + initialisation to enable the receiving of maintenance operations on > + each CPU. > + > +- System registers > + All writable architected system registers at the exception level where > + the kernel image will be entered must be initialised by software at a > + higher exception level to prevent execution in an UNKNOWN state. > + > +The boot loader is expected to enter the kernel on each CPU in the > +following manner: > + > +- The primary CPU must jump directly to the first instruction of the > + kernel image. The device tree blob passed by this CPU must contain > + for each CPU node: > + > + 1. An 'enable-method' property. Currently, the only supported value > + for this field is the string "spin-table". > + > + 2. A 'cpu-release-addr' property identifying a 64-bit, > + zero-initialised memory location. > + > + It is expected that the bootloader will generate these device tree > + properties and insert them into the blob prior to kernel entry. > + > +- Any secondary CPUs must spin outside of the kernel in a reserved area > + of memory (communicated to the kernel by a /memreserve/ region in the > + device tree) polling their cpu-release-addr location, which must be > + contained in the reserved region. A wfe instruction may be inserted > + to reduce the overhead of the busy-loop and a sev will be issued by > + the primary CPU. When a read of the location pointed to by the > + cpu-release-addr returns a non-zero value, the CPU must jump directly > + to this value. do you plan AMP boot? Best Regards, J. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
