aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/boot
diff options
context:
space:
mode:
authorAlexander Schulz <alex@shark-linux.de>2005-07-17 20:12:08 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2005-07-17 20:12:08 +0100
commit246b49768bc96d942ab0e2a17aab6fc3d2e011da (patch)
tree57eb0344054e488e4800a14963eb8c5fa63a0afe /arch/arm/boot
parentb66da4a4859b0be3f12575863bf1d873116d1947 (diff)
downloadkernel_samsung_espresso10-246b49768bc96d942ab0e2a17aab6fc3d2e011da.zip
kernel_samsung_espresso10-246b49768bc96d942ab0e2a17aab6fc3d2e011da.tar.gz
kernel_samsung_espresso10-246b49768bc96d942ab0e2a17aab6fc3d2e011da.tar.bz2
[PATCH] ARM: 2816/1: Shark: boot kernel images bigger than 1 MB
Patch from Alexander Schulz Up to now, shark kernels were limited to one megabyte compressed size. As the kernels get bigger, this becomes more and more uncomfortable. So I added a loop to copy 3 MB instead of one and added some comments. Signed-off-by: Alexander Schulz <alex@shark-linux.de> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/boot')
-rw-r--r--arch/arm/boot/compressed/head-shark.S42
1 files changed, 33 insertions, 9 deletions
diff --git a/arch/arm/boot/compressed/head-shark.S b/arch/arm/boot/compressed/head-shark.S
index 848f60e..089c560 100644
--- a/arch/arm/boot/compressed/head-shark.S
+++ b/arch/arm/boot/compressed/head-shark.S
@@ -63,8 +63,8 @@ __beginning: mov r4, r0 @ save the entry to the firmware
mov pc, r2
-__copy_target: .long 0x08508000
-__copy_end: .long 0x08608000
+__copy_target: .long 0x08507FFC
+__copy_end: .long 0x08607FFC
.word _start
.word __bss_start
@@ -73,9 +73,10 @@ __copy_end: .long 0x08608000
__temp_stack: .space 128
__mmu_off:
- adr r0, __ofw_data
+ adr r0, __ofw_data @ read the 1. entry of the memory map
ldr r0, [r0, #4]
orr r0, r0, #0x00600000
+ sub r0, r0, #4
ldr r1, __copy_end
ldr r3, __copy_target
@@ -89,20 +90,43 @@ __mmu_off:
* from 0x08500000 to 0x08508000 if we have only 8MB
*/
+/* As we get more 2.6-kernels it gets more and more
+ * uncomfortable to be bound to kernel images of 1MB only.
+ * So we add a loop here, to be able to copy some more.
+ * Alexander Schulz 2005-07-17
+ */
+
+ mov r4, #3 @ How many megabytes to copy
+
+
+__MoveCode: sub r4, r4, #1
__Copy: ldr r2, [r0], #-4
str r2, [r1], #-4
teq r1, r3
bne __Copy
+
+ /* The firmware maps us in blocks of 1 MB, the next block is
+ _below_ the last one. So our decrementing source pointer
+ ist right here, but the destination pointer must be increased
+ by 2 MB */
+ add r1, r1, #0x00200000
+ add r3, r3, #0x00100000
+
+ teq r4, #0
+ bne __MoveCode
+
+
/* and jump to it */
- adr r2, __go_on
- adr r0, __ofw_data
+ adr r2, __go_on @ where we want to jump
+ adr r0, __ofw_data @ read the 1. entry of the memory map
ldr r0, [r0, #4]
- sub r2, r2, r0
- sub r2, r2, #0x00500000
- ldr r0, __copy_target
+ sub r2, r2, r0 @ we are mapped add 0e50 now, sub that (-0e00)
+ sub r2, r2, #0x00500000 @ -0050
+ ldr r0, __copy_target @ and add 0850 8000 instead
+ add r0, r0, #4
add r2, r2, r0
- mov pc, r2
+ mov pc, r2 @ and jump there
__go_on:
adr sp, __temp_stack