On 07/06/2012 03:05 PM, Catalin Marinas wrote: > The patch adds the kernel booting and the initial setup code. > Documentation/aarch64/booting.txt describes the booting protocol on the > AArch64 Linux kernel. This is subject to change following the work on > boot standardisation, ACPI.
> diff --git a/Documentation/aarch64/booting.txt > b/Documentation/aarch64/booting.txt > +3. Decompress the kernel image > +------------------------------ > + > +Requirement: OPTIONAL > + > +The AArch64 kernel does not provide a decompressor and therefore > +requires gzip decompression to be performed by the boot loader if the > +default Image.gz target is used. For bootloaders that do not implement > +this requirement, the larger Image target is available instead. I'm curious why a decompressor isn't provided. The reason I ask is that this change will cause differences in the way e.g. a U-Boot script boots the kernel; the filename would be different, you'd need to use a uImage in order for U-Boot to decompress the kernel instead of a raw zImage, etc. This makes things on AArch64 work just a little bit different from existing systems, and differences between systems make for more things for everyone to understand and remember; more mistakes will be made. U-Boot has recently grown a "bootz" command to simplify booting a zImage directly for example, and now it seems that won't be useful moving forward. Also, on Tegra at least and perhaps OMAP too, there are a few parts of earlyprintk serial port setup (i.e. port selection) which happen as part of the decompressor rather than the main kernel image, so we'd have to re-jig that too. > +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 */ > + > +The image must be placed at the specified offset (currently 0x80000) > +from the start of the system RAM (aligned to 2MB) and called there. Is "0x80000" meant to have an extra "0"; 0x80000 isn't aligned to 2MB unless I'm really missing too much sleep today. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/