[Openocd-development] [PATCH] contrib: add ram loader src code
Hi, Having a bit of a tidy up and found the src to the various ram loaders i have written over the years - no objections i will commit. Cheers Spen From 5c25c2cbec8d4a7966ccb18b8dadbde5da59b4b9 Mon Sep 17 00:00:00 2001 From: Spencer Oliver ntfr...@users.sourceforge.net Date: Wed, 27 Oct 2010 11:03:16 +0100 Subject: [PATCH] contrib: add ram loader src code Add src code for ram loaders to contrib directory. Signed-off-by: Spencer Oliver ntfr...@users.sourceforge.net --- contrib/loaders/checksum/armv4_5_crc.s | 58 contrib/loaders/checksum/armv7m_crc.s | 66 contrib/loaders/flash/stellaris.s | 66 contrib/loaders/flash/stm32x.s | 52 + contrib/loaders/flash/str7x.s | 57 +++ contrib/loaders/flash/str9x.s | 54 ++ 6 files changed, 353 insertions(+), 0 deletions(-) create mode 100644 contrib/loaders/checksum/armv4_5_crc.s create mode 100644 contrib/loaders/checksum/armv7m_crc.s create mode 100644 contrib/loaders/flash/stellaris.s create mode 100644 contrib/loaders/flash/stm32x.s create mode 100644 contrib/loaders/flash/str7x.s create mode 100644 contrib/loaders/flash/str9x.s diff --git a/contrib/loaders/checksum/armv4_5_crc.s b/contrib/loaders/checksum/armv4_5_crc.s new file mode 100644 index 000..950a8d0 --- /dev/null +++ b/contrib/loaders/checksum/armv4_5_crc.s @@ -0,0 +1,58 @@ +/*** + * Copyright (C) 2010 by Spencer Oliver * + * s...@spen-soft.co.uk * + * * + * This program is free software; you can redistribute it and/or modify * + * it under the terms of the GNU General Public License as published by * + * the Free Software Foundation; either version 2 of the License, or * + * (at your option) any later version. * + * * + * This program is distributed in the hope that it will be useful, * + * but WITHOUT ANY WARRANTY; without even the implied warranty of* + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * + * GNU General Public License for more details. * + * * + * You should have received a copy of the GNU General Public License * + * along with this program; if not, write to the * + * Free Software Foundation, Inc., * + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * + ***/ + +/* + r0 - address in - crc out + r1 - char count +*/ + + .text + .arm + +_start: +main: + mov r2, r0 + mov r0, #0x /* crc */ + mov r3, r1 + mov r4, #0 + b ncomp +nbyte: + ldrbr1, [r2, r4] + ldr r7, CRC32XOR + eor r0, r0, r1, asl #24 + mov r5, #0 +loop: + cmp r0, #0 + mov r6, r0, asl #1 + add r5, r5, #1 + mov r0, r6 + eorlt r0, r6, r7 + cmp r5, #8 + bne loop + add r4, r4, #1 +ncomp: + cmp r4, r3 + bne nbyte +end: + bkpt#0 + +CRC32XOR: .word 0x04c11db7 + + .end diff --git a/contrib/loaders/checksum/armv7m_crc.s b/contrib/loaders/checksum/armv7m_crc.s new file mode 100644 index 000..e50db0a --- /dev/null +++ b/contrib/loaders/checksum/armv7m_crc.s @@ -0,0 +1,66 @@ +/*** + * Copyright (C) 2010 by Spencer Oliver * + * s...@spen-soft.co.uk * + * * + * This program is free software; you can redistribute it and/or modify * + * it under the terms of the GNU General Public License as published by * + * the Free Software Foundation; either version 2 of the License, or * + * (at your option) any later version. * + * * + * This program is distributed in the hope that it will be useful, * + * but WITHOUT ANY WARRANTY; without even the implied warranty of* + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
Re: [Openocd-development] [PATCH] contrib: add ram loader src code
On Wed, Oct 27, 2010 at 6:21 PM, Peter Stuge pe...@stuge.se wrote: Spencer Oliver wrote: Having a bit of a tidy up and found the src to the various ram loaders i have written over the years - no objections i will commit. Acked-by: Peter Stuge pe...@stuge.se Could they also be magically hooked up to OpenOCD? I think a good start would be to add comments in the code where these stubs are used(now as binary sequences) that the next time these sequences need to change, then they should be built using a script. I don't think we want to require target cross compilers to be available to build OpenOCD. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] contrib: add ram loader src code
Øyvind Harboe wrote: Having a bit of a tidy up and found the src to the various ram loaders i have written over the years - no objections i will commit. Could they also be magically hooked up to OpenOCD? I think a good start would be to add comments in the code where these stubs are used(now as binary sequences) Oh! So they are already magically hooked up! Great. that the next time these sequences need to change, then they should be built using a script. I don't think we want to require target cross compilers to be available to build OpenOCD. I actually don't think it is an unreasonable expectation. I know I have not had OpenOCD without the cross toolchain. However, compiling them could be done in make dist, rather than make. (Ie. when preparing a tarball, rather than when compiling OpenOCD.) //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] contrib: add ram loader src code
On Wed, Oct 27, 2010 at 10:10 PM, Peter Stuge pe...@stuge.se wrote:
Øyvind Harboe wrote:
Having a bit of a tidy up and found the src to the various ram loaders
i have written over the years - no objections i will commit.
Could they also be magically hooked up to OpenOCD?
I think a good start would be to add comments in the
code where these stubs are used(now as binary sequences)
Oh! So they are already magically hooked up! Great.
Actually, I think they are the source code for the unsigned code[]
={0x12345678,...} codelets you find here and there.
that the next time these sequences need to change, then
they should be built using a script.
I don't think we want to require target cross compilers to be
available to build OpenOCD.
I actually don't think it is an unreasonable expectation. I know I
have not had OpenOCD without the cross toolchain.
However, compiling them could be done in make dist, rather than make.
(Ie. when preparing a tarball, rather than when compiling OpenOCD.)
I'm loathe to make building OpenOCD from the master branch
any more difficult than it is already: learning git, installing
the right tools, etc.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
Hi! Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM). After some time I've come to conclusion that the problem was caused by incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With std cfg files flashing the device resulted in: Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : Block write error address 0x20002000, wcount 0xc The flashing actually works, but is extremely slow (rate 200B/s). Changing the workareasize to 2kB helps - everything works normally then. However, I've always thought that OpenOCD somehow finds the amount of RAM that is available on the chip and will not allocate more than is possible? Am I wrong? Here is the relevant part of -d 3 log for workareasize that is way over the available RAM: Debug: 570 5594 target.c:1125 target_alloc_working_area_try(): MMU disabled, using physical address for working memory 0x2000 Debug: 571 5594 target.c:1185 target_alloc_working_area_try(): allocated new working area at address 0x2000 Debug: 572 5594 target.c:1315 target_write_buffer(): writing buffer of 48 byte at 0x2000 Debug: 573 5594 target.c:1185 target_alloc_working_area_try(): allocated new working area at address 0x2030 Debug: 574 5594 target.c:1315 target_write_buffer(): writing buffer of 8192 byte at 0x2030 Debug: 575 5735 adi_v5_jtag.c:266 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 576 5735 adi_v5_jtag.c:296 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 577 5750 adi_v5_jtag.c:312 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 578 5750 adi_v5_jtag.c:327 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Debug: 579 5750 adi_v5_jtag.c:266 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 580 5750 adi_v5_jtag.c:296 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 581 5766 adi_v5_jtag.c:312 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 582 5766 adi_v5_jtag.c:327 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : 583 5766 arm_adi_v5.c:337 mem_ap_write_buf_u32(): Block write error address 0x20002000, wcount 0xc Any ideas? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] contrib: add ram loader src code
On 10/27/2010 10:29 PM, Øyvind Harboe wrote: I actually don't think it is an unreasonable expectation. I know I have not had OpenOCD without the cross toolchain. However, compiling them could be done in make dist, rather than make. (Ie. when preparing a tarball, rather than when compiling OpenOCD.) I'm loathe to make building OpenOCD from the master branch any more difficult than it is already: learning git, installing the right tools, etc. Yes. However, having scripts that compile these assembler parts and create the corresponding C source files with the arrays would be nice. The generated files can be checked in (just like they are now), so only someone who wants to modify that code needs the cross compiler installed. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
