- 24 10月, 2016 1 次提交
-
-
由 Mauro Carvalho Chehab 提交于
The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
-
- 28 2月, 2015 1 次提交
-
-
由 Gregory 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: NGregory Fong <gregory.0xf0@gmail.com> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 26 8月, 2013 1 次提交
-
-
由 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: NIan 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: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 9月, 2012 1 次提交
-
-
由 Dave Martin 提交于
Document the possibility of the kernel being entered in HYP mode. Signed-off-by: NDave Martin <dave.martin@linaro.org> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
- 19 7月, 2011 1 次提交
-
-
由 Dave 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: NDave Martin <dave.martin@linaro.org> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 23 5月, 2011 1 次提交
-
-
由 Grant 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: NTony Lindgren <tony@atomide.com> Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org> Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 14 2月, 2011 1 次提交
-
-
由 Grant Likely 提交于
This reverts commit 9830fcd6. The ARM dt support has not been merged yet; this documentation update was premature. Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 01 2月, 2011 1 次提交
-
-
由 Grant Likely 提交于
v3: added details to Documentation/arm/Booting Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
-
- 25 3月, 2006 1 次提交
-
-
由 Andrzej Zaborowski 提交于
This corrects some trivial errors in ARM docs and comments, Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus 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!
-