summaryrefslogtreecommitdiff
path: root/Documentation/arm/Booting
AgeCommit message (Collapse)Author
2015-02-27Documentation: arm: Update for DT-only platformsGregory Fong
The documentation specified that a machine type is mandatory and made that assumption in a few places. However, for DT-only platforms, the current advice is that no machine type should be registered, so update accordingly. Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2013-08-25ARM: 7824/1: update advice on kernel, initramfs and FDT load address.Ian Campbell
- Recommend that the kernel be placed under 128MiB, this is required if CONFIG_AUTO_ZRELADDR=y and good (or at least not bad) advice even if CONFIG_AUTO_ZRELADDR=n. - Recommend that a zImage kernel be placed above 32MiB, this avoids the need to relocate prior to decompression, which can speed up boot. - Add basic info on the requirements when loading a raw (non-zImage) kernel which are stricter than the zImage requirements. - Recommend that the DTB be placed after the 128MiB boundary, avoiding any potential conflict with the kernel decompressor, and within the lowmem region. In practice it could follow the kernel loaded after 32MiB, assuming the kernel decompesses to less than 32MiB, but the 128MiB recommendation is simple and unambiguous. - Add similar recommendation regarding initramfs. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Dave Martin <dave.martin@linaro.org> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Roy Franz <roy.franz@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-09-19ARM: virt: Update documentation for hyp mode entry supportDave Martin
Document the possibility of the kernel being entered in HYP mode. Signed-off-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2011-07-19ARM: 6999/1: head, zImage: Always Enter the kernel in ARM stateDave Martin
Currently, the documented kernel entry requirements are not explicit about whether the kernel should be entered in ARM or Thumb, leading to an ambiguitity about how to enter Thumb-2 kernels. As a result, the kernel is reliant on the zImage decompressor to enter the kernel proper in the correct instruction set state. This patch changes the boot entry protocol for head.S and Image to be the same as for zImage: in all cases, the kernel is now entered in ARM. Documentation/arm/Booting is updated to reflect this new policy. A different rule will be needed for Cortex-M class CPUs as and when support for those lands in mainline, since these CPUs don't support the ARM instruction set at all: a note is added to the effect that the kernel must be entered in Thumb on such systems. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-05-23dt: add documentation of ARM dt boot interfaceGrant Likely
v6: typo fixes v5: clarified that dtb should be aligned on a 64 bit boundary in RAM. v3: added details to Documentation/arm/Booting Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-02-14Revert "dt: add documentation of ARM dt boot interface"Grant Likely
This reverts commit 9830fcd6f6a4781d8b46d2b35c13b39f30915c63. The ARM dt support has not been merged yet; this documentation update was premature. Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-01-31dt: add documentation of ARM dt boot interfaceGrant Likely
v3: added details to Documentation/arm/Booting Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2006-03-24Fix simple typosAndrzej Zaborowski
This corrects some trivial errors in ARM docs and comments, Signed-off-by: Adrian Bunk <bunk@stusta.de>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!