aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/boot/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* update other arm platforms from 3.2.72 and also merge some general arm code ↵Wolfgang Wiedmeyer2015-10-231-0/+17
| | | | (boot)
* samsung update 1codeworkx2012-06-021-0/+4
|
* ARM: add 'uinstall' target for installing uboot kernelsRussell King2011-02-231-0/+4
| | | | | | | | | | | We have 'install' and 'zinstall' for installing Image and zImage kernels, so add 'uinstall' to complete the set. This allows developers to have a ~/bin/installkernel script which (eg) copies the kernel to the tftp server automatically once the kernel has built, resulting in a better workflow. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for ↵Dave Martin2010-11-301-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_THUMB2_KERNEL The code which makes up the zImage header intends to leave a 32-byte gap followed by a branch to the real entry point, a magic number, and a word containing the absolute entry point address. This gets messed up with with CONFIG_THUMB2_KERNEL, because the size of the initial padding NOPs changes. Instead, the header can be made fully compatible by restoring it to ARM. In the Thumb-2 case, we can replace the initial NOPs with a sequence which switches to Thumb and jumps to the real entry point. As a consequence, the zImage entry point is now always ARM, so no special magic is needed any more for the uImage rules in the Thumb-2 case. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: Partially revert "Auto calculate ZRELADDR and provide option for ↵Russell King2010-09-091-3/+5
| | | | | | | | | | | | | exceptions" Partially revert e69edc7, which introduced automatic zreladdr support. The change in the way the manual definition is defined seems to be error and conflict prone. Go back to the original way we were handling this for the time being, while keeping the automatic zreladdr facility. Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* ARM: Auto calculate ZRELADDR and provide option for exceptionsEric Miao2010-07-121-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As long as the zImage is placed within the 128MB range from the start of memory, ZRELADDR (Address where the decompressed kernel will be placed, usually == PHYS_OFFSET + TEXT_OFFSET) can be determined at run-time by masking PC with 0xf80000000. Running through all the Makefile.boot, all those zreladdr-y addresses == 0x[0-f][08]00_0000 + TEXT_OFFSET can be determined at run-time. Option CONFIG_AUTO_ZRELADDR and CONFIG_ZRELADDR are introduced, CONFIG_ZRELADDR _must_ be explicitly specified if: - ((zreladdr-y - TEXT_OFFSET) & ~0xf8000000) != 0, which means masking PC with 0xf8000000 will result in an incorrect address. Currently this is only a problem on u300. - or the assumption of the zImage being loaded by the bootloader within the first 128MB of RAM is incorrect - or when ZBOOT_ROM is used, where the above assumption is usually wrong. [ukleinek: changed mask from 0xf0000000 to 0xf8000000 for mx1 and shark + some review fixes from the mailing list] Original-Idea-and-Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Eric Miao <eric.miao@canonical.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
* Thumb-2: Make the uImage entry an odd numberCatalin Marinas2009-07-241-1/+8
| | | | | | | This allows U-Boot to branch to the kernel in Thumb-2 mode via "mov pc, lr". Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
* [ARM] 4854/1: fix the load address of uImage for CONFIG_ZBOOT_ROM=yUwe Kleine-König2008-04-191-1/+7
| | | | | | | | | | | U-Boot puts an image at the load address specified in the uImage header before jumping to the entry point. In the CONFIG_ZBOOT_ROM case ZBOOT_ROM_TEXT is the right load address. Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* [ARM] Make 'i' and 'zi' targets workRussell King2007-07-201-0/+8
| | | | | | | | | The 'i' and 'zi' targets short-circuit the dependencies for 'install' and 'zinstall' targets; these are useful for installing the kernel on platforms which have make but no compiler installed. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* kbuild: change kbuild to not rely on incorrect GNU make behaviorPaul Smith2006-03-061-1/+4
| | | | | | | | | | | | | | | | | | | | The kbuild system takes advantage of an incorrect behavior in GNU make. Once this behavior is fixed, all files in the kernel rebuild every time, even if nothing has changed. This patch ensures kbuild works with both the incorrect and correct behaviors of GNU make. For more details on the incorrect behavior, see: http://lists.gnu.org/archive/html/bug-make/2006-03/msg00003.html Changes in this patch: - Keep all targets that are to be marked .PHONY in a variable, PHONY. - Add .PHONY: $(PHONY) to mark them properly. - Remove any $(PHONY) files from the $? list when determining whether targets are up-to-date or not. Signed-off-by: Paul Smith <psmith@gnu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
* [ARM] Make kernel link address depend on PAGE_OFFSETRussell King2006-01-031-1/+1
| | | | | | | | | | | | We are coding the kernel link address into the makefiles, which is invisibly dependent on PAGE_OFFSET. If PAGE_OFFSET is changed, the makefiles also need to be changed. Make adjustments such that the makefiles encode just the offset from PAGE_OFFSET for the kernel link address, and use PAGE_OFFSET in the linker scripts directly. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* Linux-2.6.12-rc2Linus Torvalds2005-04-161-0/+91
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!