aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAlexander Schulz <alex@shark-linux.de>2005-07-17 15:12:08 -0400
committerRussell King <rmk+kernel@arm.linux.org.uk>2005-07-17 15:12:08 -0400
commit246b49768bc96d942ab0e2a17aab6fc3d2e011da (patch)
tree57eb0344054e488e4800a14963eb8c5fa63a0afe
parentb66da4a4859b0be3f12575863bf1d873116d1947 (diff)
[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>
-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 848f60e5429b..089c560e07f1 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
63 63
64 mov pc, r2 64 mov pc, r2
65 65
66__copy_target: .long 0x08508000 66__copy_target: .long 0x08507FFC
67__copy_end: .long 0x08608000 67__copy_end: .long 0x08607FFC
68 68
69 .word _start 69 .word _start
70 .word __bss_start 70 .word __bss_start
@@ -73,9 +73,10 @@ __copy_end: .long 0x08608000
73__temp_stack: .space 128 73__temp_stack: .space 128
74 74
75__mmu_off: 75__mmu_off:
76 adr r0, __ofw_data 76 adr r0, __ofw_data @ read the 1. entry of the memory map
77 ldr r0, [r0, #4] 77 ldr r0, [r0, #4]
78 orr r0, r0, #0x00600000 78 orr r0, r0, #0x00600000
79 sub r0, r0, #4
79 80
80 ldr r1, __copy_end 81 ldr r1, __copy_end
81 ldr r3, __copy_target 82 ldr r3, __copy_target
@@ -89,20 +90,43 @@ __mmu_off:
89 * from 0x08500000 to 0x08508000 if we have only 8MB 90 * from 0x08500000 to 0x08508000 if we have only 8MB
90 */ 91 */
91 92
93/* As we get more 2.6-kernels it gets more and more
94 * uncomfortable to be bound to kernel images of 1MB only.
95 * So we add a loop here, to be able to copy some more.
96 * Alexander Schulz 2005-07-17
97 */
98
99 mov r4, #3 @ How many megabytes to copy
100
101
102__MoveCode: sub r4, r4, #1
92 103
93__Copy: ldr r2, [r0], #-4 104__Copy: ldr r2, [r0], #-4
94 str r2, [r1], #-4 105 str r2, [r1], #-4
95 teq r1, r3 106 teq r1, r3
96 bne __Copy 107 bne __Copy
108
109 /* The firmware maps us in blocks of 1 MB, the next block is
110 _below_ the last one. So our decrementing source pointer
111 ist right here, but the destination pointer must be increased
112 by 2 MB */
113 add r1, r1, #0x00200000
114 add r3, r3, #0x00100000
115
116 teq r4, #0
117 bne __MoveCode
118
119
97 /* and jump to it */ 120 /* and jump to it */
98 adr r2, __go_on 121 adr r2, __go_on @ where we want to jump
99 adr r0, __ofw_data 122 adr r0, __ofw_data @ read the 1. entry of the memory map
100 ldr r0, [r0, #4] 123 ldr r0, [r0, #4]
101 sub r2, r2, r0 124 sub r2, r2, r0 @ we are mapped add 0e50 now, sub that (-0e00)
102 sub r2, r2, #0x00500000 125 sub r2, r2, #0x00500000 @ -0050
103 ldr r0, __copy_target 126 ldr r0, __copy_target @ and add 0850 8000 instead
127 add r0, r0, #4
104 add r2, r2, r0 128 add r2, r2, r0
105 mov pc, r2 129 mov pc, r2 @ and jump there
106 130
107__go_on: 131__go_on:
108 adr sp, __temp_stack 132 adr sp, __temp_stack