diff options
author | Alexander Schulz <alex@shark-linux.de> | 2005-07-17 15:12:08 -0400 |
---|---|---|
committer | Russell King <rmk+kernel@arm.linux.org.uk> | 2005-07-17 15:12:08 -0400 |
commit | 246b49768bc96d942ab0e2a17aab6fc3d2e011da (patch) | |
tree | 57eb0344054e488e4800a14963eb8c5fa63a0afe | |
parent | b66da4a4859b0be3f12575863bf1d873116d1947 (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.S | 42 |
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 |