This repository has been archived by the owner on Sep 28, 2019. It is now read-only.
OpenOCD silent installations on windows 7 #2
Assignees
Labels
Comments
|
I currently have no experience with Windows silent installations, so I'll need some time to investigate. |
|
According to the NSIS manual, it should work:
The NSIS script used to build the setup is publicly available from: gnuarmeclipse/openocd. Unfortunately I have limited Windows testing capabilities, so if you spot any problems that would prevent /D to work properly, please suggest a patch and I can try to fix it. |
ilg-ul
pushed a commit
that referenced
this issue
Jan 11, 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, #4
cmp r0, r2
bne .loop_clear
subs r2, r2, #4
mov sp, r2
movs r0, #1
movs r1, #2
movs r2, #3
movs r3, #4
svc #0
ldr r0, .stack_start
ldr r2, .stack_last
eors r1, r1
.loop_clear2:
str r1, [r0]
adds r0, r0, #4
cmp r0, r2
bne .loop_clear2
mov sp, r2
movs r0, #1
movs r1, #2
movs r2, #3
movs r3, #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]>
|
any progress? can we close this ticket? |
|
fixed in v0.10.0-201610281609-dev |
ilg-ul
pushed a commit
that referenced
this issue
Jun 4, 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
#1 0xffffffc000085114 in arch_cpu_idle () at /mnt/host/source/src/third_party/kernel/3.14/arch/arm64/kernel/process.c:107
#2 0x0000000000000000 in ?? ()
Change-Id: Iccb1d15c7d8ace7b9e811dac3c9757ced4d0f618
Signed-off-by: David Ung <[email protected]>
Signed-off-by: Matthias Welwarsky <[email protected]>
ilg-ul
pushed a commit
that referenced
this issue
May 12, 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
#1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
#2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
#3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
#4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
#5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
#6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
#7 0x55978a528357 in target_poll src/target/target.c:535
#8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
#9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
#10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
#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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I am trying to install https://github.com/gnuarmeclipse/openocd/releases/download/gae-0.9.0-20150519/gnuarmeclipse-openocd-win64-0.9.0-201505190955-setup.exe from command line. I am successfully able to install silently with /S option but failed to install to different folder than default. The silent installations always installing openocd at "C:\Program Files\GNU ARM Eclipse\OpenOCD". Kindly let me know how install to different folder than default one.
Following are the commands i used to install openocd at "L:\openocd":
C:>"C:\Users\rkandur\Downloads\gnuarmeclipse-openocd-win64-0.9.0-201505190955-setup.exe" /S /D=l:\openocd
The text was updated successfully, but these errors were encountered: