Partition the first flash page #2
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
SAMD microcontrollers can protect the bootloader flash using at91samd bootloader [size] command In processors with big flash like SAMD21G18A the minimum flash partition is 256kB / 16 = 16kB, which is way bigger than minimum bootloader size. When a "load" is executed during gdb debugging session, if the .text section starts before 0x4000 (16kB), the entire first flash page gets erased. This fails if the page is protected via the bootloader command. This patch partitions the first flash page into logical smaller chunks, so the "load" command only erases the relevant pages. If the flash page is smaller/equal than the minimum bootloader size, do nothing.
sandeepmistry
pushed a commit
to sandeepmistry/OpenOCD
that referenced
this pull request
Nov 4, 2016
In the case that the STKALIGN bit is set on Cortex M processors, on
entry to an exception - the processor can store an additional 4 bytes
of padding before regular stacking to achieve 8-byte alignment on
exception entry. In the case that this padding is present, the
processor will set bit (1 << 9) in the stacked xPSR register. Use the
new calculate_process_stack callback to take into account the xPSR
register and use it on the standard Cortex_M3 stacking.
Note: Change #2301 had some misinformation regarding the padding. On
Cortex-M the padding is stored BEFORE stacking so xPSR is always
available at a fixed offset.
Tested on a Cortex-M0+ (Atmel SAMR21) board which has STKALIGN fixed
to a '1' such that this alignment always occurs on non-aligned stacks.
Behavior of xPSR verified via the (bad-sorry) assembly program below by
setting a breakpoint on the SVC_Handler symbol. The first time
SVC_Handler is triggered the stack was 0x20000ff8, the second time
SVC_Handler is triggered the stack was 0x20000ffc. Note that in both
cases the interrupt handler gets 0x20000fd8 for a stack pointer.
GDB exerpt:
Breakpoint 1, 0x000040b6 in Reset_Handler ()
(gdb) hbreak SVC_Handler
Hardware assisted breakpoint 2 at 0x40f8
(gdb) cont
Continuing.
Breakpoint 2, 0x000040f8 in SVC_Handler ()
(gdb) print $msp
$3 = (void *) 0x20000fd8
(gdb) x/9w $msp
0x20000fd8: 0x1 0x2 0x3 0x4
0x20000fe8: 0x88160082 0xa53 0x40ce 0x21000000
0x20000ff8: 0x0
(gdb) cont
Continuing.
Breakpoint 2, 0x000040f8 in SVC_Handler ()
(gdb) print $msp
$4 = (void *) 0x20000fd8
(gdb) x/9w $msp
0x20000fd8: 0x1 0x2 0x3 0x4
0x20000fe8: 0x88160082 0xa53 0x40e8 0x21000200
0x20000ff8: 0x0
Assembly program:
.cpu cortex-m0plus
.fpu softvfp
.thumb
.syntax unified
.section .vectors
@ pvStack:
.word 0x20001000
@ pfnReset_Handler:
.word Reset_Handler + 1
@ pfnNMI_Handler:
.word 0
@ pfnHardFault_Handler:
.word 0
@ pfnReservedM12:
.word 0
@ pfnReservedM11:
.word 0
@ pfnReservedM10:
.word 0
@ pfnReservedM9:
.word 0
@ pfnReservedM8:
.word 0
@ pfnReservedM7:
.word 0
@ pfnReservedM6:
.word 0
@ pfnSVC_Handler:
.word SVC_Handler + 1
.section .text
.global Reset_Handler
Reset_Handler:
cpsie i
ldr r0, .stack_start
ldr r2, .stack_last
eors r1, r1
.loop_clear:
str r1, [r0]
adds r0, r0, arduino#4
cmp r0, r2
bne .loop_clear
subs r2, r2, arduino#4
mov sp, r2
movs r0, arduino#1
movs r1, arduino#2
movs r2, arduino#3
movs r3, arduino#4
svc #0
ldr r0, .stack_start
ldr r2, .stack_last
eors r1, r1
.loop_clear2:
str r1, [r0]
adds r0, r0, arduino#4
cmp r0, r2
bne .loop_clear2
mov sp, r2
movs r0, arduino#1
movs r1, arduino#2
movs r2, arduino#3
movs r3, arduino#4
svc #0
.loop:
b .loop
.align 4
.stack_start:
.word 0x20000f00
.stack_last:
.word 0x20000ffc
@ first call - 0x2000fff8 -- should already be aligned
@ second call - 0x2000fffc -- should hit the alignment code
.global SVC_Handler
SVC_Handler:
bx lr
Change-Id: Id0940e6bbd6a59adee1378c0e86fe86830f0c8fc
Signed-off-by: Andrew Ruder <[email protected]>
Cc: Paul Fertser <[email protected]>
Cc: Andreas Fritiofson <[email protected]>
Cc: Evan Hunter <[email protected]>
Cc: Jon Burgess <[email protected]>
Reviewed-on: http://openocd.zylin.com/3003
Tested-by: jenkins
Reviewed-by: Freddie Chopin <[email protected]>
el-han
pushed a commit
to el-han/OpenOCD
that referenced
this pull request
Sep 14, 2017
Add new AARCH64 target and ARMv8 support files.
This is an instantiation from the cortex_a files but modified to support
64bit ARMv8. Not all features are complete, notably breakpts and single
stepping are not yet implemented.
Currently it lets you halt of the processors, resume, dump cpu
registers,
read/write memory and getting a stack trace with gdb.
> halt
invalid mode value encountered 5
target state: halted
unrecognized psr mode: 0x5
target halted in ARM state due to debug-request, current mode:
UNRECOGNIZED
cpsr: 0x600001c5 pc: 0x00093528
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> targets
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* cpu0 aarch64 little cpu.dap halted
> reg
===== arm v8 registers
(0) r0 (/64): 0x00000000FFFFFFED (dirty)
(1) r1 (/64): 0x00000000F76E4000
(2) r2 (/64): 0x0000000000000000
(3) r3 (/64): 0x0000000000010000
(4) r4 (/64): 0xFFFFFFC06E2939E1
(5) r5 (/64): 0x0000000000000018
(6) r6 (/64): 0x003A699CFB3C8480
(7) r7 (/64): 0x0000000053555555
(8) r8 (/64): 0x00FFFFFFFFFFFFFF
(9) r9 (/64): 0x000000001FFEF992
(10) r10 (/64): 0x0000000000000001
(11) r11 (/64): 0x0000000000000000
(12) r12 (/64): 0x00000000000000F0
(13) r13 (/64): 0x00000000EFDFEAC8
(14) r14 (/64): 0x00000000F6DDA659
(15) r15 (/64): 0x0000000000000000
(16) r16 (/64): 0xFFFFFFC0000F9094
(17) r17 (/64): 0x0000000000000000
(18) r18 (/64): 0x0000000000000000
(19) r19 (/64): 0xFFFFFFC00087C000
(20) r20 (/64): 0x0000000000000002
(21) r21 (/64): 0xFFFFFFC000867C28
(22) r22 (/64): 0xFFFFFFC000916A52
(23) r23 (/64): 0xFFFFFFC00116D8B0
(24) r24 (/64): 0xFFFFFFC000774A0C
(25) r25 (/64): 0x000000008007B000
(26) r26 (/64): 0x000000008007D000
(27) r27 (/64): 0xFFFFFFC000080450
(28) r28 (/64): 0x0000004080000000
(29) r29 (/64): 0xFFFFFFC00087FF20
(30) r30 (/64): 0xFFFFFFC000085114
(31) sp (/64): 0xFFFFFFC00087FF20
(32) pc (/64): 0xFFFFFFC000093528
(33) xPSR (/64): 0x00000000600001C5
And from gdb
(gdb) bt
#0 cpu_do_idle () at /mnt/host/source/src/third_party/kernel/3.14/arch/arm64/mm/proc.S:87
arduino#1 0xffffffc000085114 in arch_cpu_idle () at /mnt/host/source/src/third_party/kernel/3.14/arch/arm64/kernel/process.c:107
arduino#2 0x0000000000000000 in ?? ()
Change-Id: Iccb1d15c7d8ace7b9e811dac3c9757ced4d0f618
Signed-off-by: David Ung <[email protected]>
Signed-off-by: Matthias Welwarsky <[email protected]>
facchinm
pushed a commit
to facchinm/OpenOCD
that referenced
this pull request
Jun 8, 2018
…oo far
Without this, we have some types promoted to `int` when they need to be
`unsigned int`.
Here's some ubsan output hitting this:
Unfortunately, what happens is that things get promoted to `int`, but
need to be `unsigned int`. Here's the ubsan output:
src/helper/types.h:126:65: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
#0 0x55978a612060 in le_to_h_u32 src/helper/types.h:126
arduino#1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
arduino#2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
arduino#3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
arduino#4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
arduino#5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
arduino#6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
arduino#7 0x55978a528357 in target_poll src/target/target.c:535
arduino#8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
arduino#9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
arduino#10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
arduino#11 0x55978aaed894 in JimInvokeCommand /home/cody/d/openocd-code/jimtcl/jim.c:10364
Change-Id: I24f6abfd26b6980100657397d69c84f2b80a005a
Signed-off-by: Cody P Schafer <[email protected]>
Reviewed-on: http://openocd.zylin.com/4455
Reviewed-by: Tomas Vanek <[email protected]>
Tested-by: jenkins
Reviewed-by: Christopher Head <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SAMD microcontrollers can protect the bootloader flash using
at91samd bootloader [size] command
In processors with big flash like SAMD21G18A the minimum flash partition is
256kB / 16 = 16kB, which is way bigger than minimum bootloader size.
When a "load" is executed during gdb debugging session, if the .text section
starts before 0x4000 (16kB), the entire first flash page gets erased.
This fails if the page is protected via the bootloader command.
This patch partitions the first flash page into logical smaller chunks, so
the "load" command only erases the relevant pages.
If the flash page is smaller/equal than the minimum bootloader size, do nothing.