Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
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? Nope. There is no code in OpenOCD to figure this out. Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. -- Ø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] Problems with workareasize and STM32F100 (8kB of RAM)
Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. Patches welcome! :-) Good target/board scripts can do wonder for the OpenOCD experience... Some scripts are also a lot of work to put together. -- Ø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] Problems with workareasize and STM32F100 (8kB of RAM)
Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. Patches welcome! :-) Fair enough. Always the tradeoff between using and producing tools. As much as I dislike things ftdi it'd be nice to touch up that driver a little. Going to libftdi-1.0 would be a somewhat major change I think, but small simple fixes might be to get rid of the segfault when JTAG adapter is not plugged, and if the adapter is unplugged while OpenOCD is running then it goes into some loop printing error messages. Anyway, I'd like to do more testing with the Versaloon. Good target/board scripts can do wonder for the OpenOCD experience... Yes, I would even say that they are key. Have to refresh those Tcl skills. Some scripts are also a lot of work to put together. No doubt. Especially if they are to be really generic. //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 27/10/2010 18:50, Øyvind Harboe wrote: On Wed, Oct 27, 2010 at 6:21 PM, Peter Stugepe...@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 Stugepe...@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. updated patchset attached - is this better? Cheers Spen From 1fafb669c99744b986d85b5c4a4e276767898654 Mon Sep 17 00:00:00 2001 From: Spencer Oliver ntfr...@users.sourceforge.net Date: Thu, 28 Oct 2010 09:19:37 +0100 Subject: [PATCH 1/2] 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/README | 33 contrib/loaders/checksum/armv4_5_crc.s | 58 ++ contrib/loaders/checksum/armv7m_crc.s | 66 contrib/loaders/checksum/mips32.s | 72 + contrib/loaders/flash/pic32mx.s| 131 contrib/loaders/flash/stellaris.s | 66 contrib/loaders/flash/stm32x.s | 52 + contrib/loaders/flash/str7x.s | 57 ++ contrib/loaders/flash/str9x.s | 54 + 9 files changed, 589 insertions(+), 0 deletions(-) create mode 100644 contrib/loaders/README create mode 100644 contrib/loaders/checksum/armv4_5_crc.s create mode 100644 contrib/loaders/checksum/armv7m_crc.s create mode 100644 contrib/loaders/checksum/mips32.s create mode 100644 contrib/loaders/flash/pic32mx.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/README b/contrib/loaders/README new file mode 100644 index 000..2b123cf --- /dev/null +++ b/contrib/loaders/README @@ -0,0 +1,33 @@ +Included in these directories are the src to the various ram loaders used +within openocd. + +** target checksum loaders ** + +checksum/armv4_5_crc.s : + - ARMv4 and ARMv5 checksum loader : see target/arm_crc_code.c:arm_crc_code + +checksum/armv7m_crc.s : + - ARMv7m checksum loader : see target/armv7m.c:cortex_m3_crc_code + +checksum/mips32.s : + - MIPS32 checksum loader : see target/mips32.c:mips_crc_code + +** target flash loaders ** + +flash/pic32mx.s : + - Microchip PIC32 flash loader : see flash/nor/pic32mx.c:pic32mx_flash_write_code + +flash/stellaris.s : + - TI Stellaris flash loader : see flash/nor/stellaris.c:stellaris_write_code + +flash/stm32x.s : + - ST STM32 flash loader : see flash/nor/stm32x.c:stm32x_flash_write_code + +flash/str7x.s : + - ST STR7 flash loader : see flash/nor/str7x.c:str7x_flash_write_code + +flash/str9x.s : + - ST STR9 flash loader : see flash/nor/str9x.c:str9x_flash_write_code + +Spencer Oliver +s...@spen-soft.co.uk 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 -
Re: [Openocd-development] [PATCH] contrib: add ram loader src code
On Thu, Oct 28, 2010 at 11:12 AM, Spencer Oliver s...@spen-soft.co.uk wrote: On 27/10/2010 18:50, Øyvind Harboe wrote: On Wed, Oct 27, 2010 at 6:21 PM, Peter Stugepe...@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 Stugepe...@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. updated patchset attached - is this better? Much better. Anyone who wants to work on these magic sequences will then know where the source is and then take it from there. -- Ø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] Problems with workareasize and STM32F100 (8kB of RAM)
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl wrote: 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. We should probably change it to the least common denominator within the family, which is 8kB (maybe even 6?). Definitely, if you don't see any significant reduction in flashing speed after reducing the workareasize (8kB vs 2kB). That's likely dependent on the adapter in use, of course. 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? Yes. Early silicon had a SRAM size register in factory programmed ROM but it was later removed for some reason. I don't think OpenOCD used it even when it existed. We could probably determine the size indirectly, maybe from a chip id database, but I think it's just as good to simply provide a minimum safe workareasize and let the user override it if he wishes. //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On 2010-10-28 19:53, Andreas Fritiofson wrote: We should probably change it to the least common denominator within the family, which is 8kB (maybe even 6?). Definitely, if you don't see any significant reduction in flashing speed after reducing the workareasize (8kB vs 2kB). That's likely dependent on the adapter in use, of course. The smallest RAM capacity in the STM32 family is 4kB. There are like 10 devices with so little RAM available. http://www.st.com/stonline/stappl/st/com/selector/index.html#querycriteria=RNP139=1169.0 I'll try to check the flashing speed with various workareasizes later. Yes. Early silicon had a SRAM size register in factory programmed ROM but it was later removed for some reason. I don't think OpenOCD used it even when it existed. We could probably determine the size indirectly, maybe from a chip id database, but I think it's just as good to simply provide a minimum safe workareasize and let the user override it if he wishes. It's a good idea in my opinion, but I'm not sure whether it's possible - the MCU Device ID register only shows the family (low-, medium-, high-density, connectivity, value, etc.), so that's not enough - maybe checking flash size would allow OpenOCD to determine the RAM size... I'll investigate this more later. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On 2010-10-28 20:15, Freddie Chopin wrote: I'll try to check the flashing speed with various workareasizes later. _WORKAREASIZE 0x4000 (16kB) Start address 0x8000130, load size 129296 Transfer rate: 8 KB/sec, 12929 bytes/write. _WORKAREASIZE 0x1000 (4kB) Start address 0x8000130, load size 129296 Transfer rate: 4 KB/sec, 12929 bytes/write. So there is a decrease... It's a good idea in my opinion, but I'm not sure whether it's possible - the MCU Device ID register only shows the family (low-, medium-, high-density, connectivity, value, etc.), so that's not enough - maybe checking flash size would allow OpenOCD to determine the RAM size... I'll investigate this more later. There are some cases where the amount of available RAM cannot be determined - there are some devices of the same family that have the same flash size but different amount of RAM. E.g.: STM32F105VB (CL), 128kB flash, 32kB RAM STM32F107RB (CL), 128kB flash, 48kB RAM However, that is enough to determine max amount of RAM with small error - there are such pairs with (more or less) adjacent amounts of ram (4/6, 6/10, 32/48, 48/64, etc.). I'd even like to do that, but the mechanics of OpenOCD is still a big mystery for me - in stm32x_write_block() (stm32x.c) the buffer size to be allocated is fixed at 16kB, and this file does nothing with workareasize defined in cfg files (I think...). What is the reason to use fixed buffer size of 16kB? Shouldn't that be changed as there are chips with more RAM and those could benefit from higher workareasize (I cannot check, I only have chips with 20kB of RAM). Of course another solution would be to create a general cfg file and small dedicated cfg files for every STM32 device available (currently 89) - these would use (include) the general cfg. The structure of the target folder could be changed to target - st - stm32 stm32f103rb.cfg stm32f105v8.cfg ... - str7 str710.cfg str711.cfg ... - str9 ... - nxp - lpc17xx ... - lpc2xxx ... and so on. I think that would improve the OpenOCD experience for the users... It's still not very user-friendly ); I could try to do some patches, but I'd first like to hear your opinions. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 3/3] Add EfikaMX smarttop board support
This patch finally adds support for i.MX51 based Genesi USA EfikaMX smarttop board. Signed-off-by: Marek Vasut marek.va...@gmail.com --- tcl/board/efikamx.cfg |9 + 1 files changed, 9 insertions(+), 0 deletions(-) create mode 100644 tcl/board/efikamx.cfg diff --git a/tcl/board/efikamx.cfg b/tcl/board/efikamx.cfg new file mode 100644 index 000..f8ae25d --- /dev/null +++ b/tcl/board/efikamx.cfg @@ -0,0 +1,9 @@ +# Genesi USA EfikaMX +# http://www.genesi-usa.com/products/efika + +# Fall back to 6MHz if RTCK is not supported +jtag_rclk 6000 + +source [find target/imx51.cfg] + +reset_config trst_only -- 1.7.1 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
In this patch, I introduce the use of -variant parameter, so I can adjust the
debug_base accordingly.
So far, only the OMAP3530 and AM/DM37x CPUs, which utilize the Cortex A8 core
are supported by OpenOCD and both of these use the same Cortex A8 Debug Access
Port address (0x54011000).
There are other CPU manufacturers, who use different address for the Cortex A8
Debug Access Port though. As I was unable to figure out a way to detect the
address of DAP, this should at least work around the problem until there is a
proper solution.
Signed-off-by: Marek Vasut marek.va...@gmail.com
---
src/target/cortex_a8.c | 11 ++-
tcl/target/amdm37x.cfg |3 ++-
tcl/target/omap3530.cfg |3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/src/target/cortex_a8.c b/src/target/cortex_a8.c
index 8b4ced5..64b78bd 100644
--- a/src/target/cortex_a8.c
+++ b/src/target/cortex_a8.c
@@ -1719,7 +1719,16 @@ static int cortex_a8_examine_first(struct target *target)
LOG_DEBUG(TODO - autoconfigure);
/* Here we shall insert a proper ROM Table scan */
- armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ if (strcmp(target-variant, amdm37x) == 0)
+ armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ else if (strcmp(target-variant, omap3530) == 0)
+ armv7a-debug_base = OMAP3530_DEBUG_BASE;
+ else {
+ LOG_DEBUG(Unknown CPU variant);
+ return ERROR_FAIL;
+ }
+
+ LOG_DEBUG(Using Cortex A8, %s variant, target-variant);
/* We do one extra read to ensure DAP is configured,
* we call ahbap_debugport_init(swjdp) instead
diff --git a/tcl/target/amdm37x.cfg b/tcl/target/amdm37x.cfg
index ab18681..3776435 100644
--- a/tcl/target/amdm37x.cfg
+++ b/tcl/target/amdm37x.cfg
@@ -142,7 +142,8 @@ jtag configure $_CHIPNAME.jrc -event setup jtag tapenable
$_CHIPNAME.dap
# Create the CPU target to be used with GDB: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+ -variant amdm37x
# The DM37x has 64K of SRAM starting at address 0x4020_. Allow the first
# 16K to be used as a scratchpad for OpenOCD.
diff --git a/tcl/target/omap3530.cfg b/tcl/target/omap3530.cfg
index ba130a9..e7b598f 100644
--- a/tcl/target/omap3530.cfg
+++ b/tcl/target/omap3530.cfg
@@ -36,7 +36,8 @@ jtag newtap $_CHIPNAME jrc -irlen 6 -ircapture 0x1 -irmask
0x3f \
# GDB target: Cortex-A8, using DAP
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap
+target create $_TARGETNAME cortex_a8 -chain-position $_CHIPNAME.dap \
+ -variant omap3530
# SRAM: 64K at 0x4020.; use the first 16K
$_TARGETNAME configure -work-area-phys 0x4020 -work-area-size 0x4000
--
1.7.1
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
Freddie Chopin wrote: another solution would be to create a general cfg file and small dedicated cfg files for every STM32 device available (currently 89) - these would use (include) the general cfg. I was considering this too. I strongly prefer a single file for the entire family if possible, but it should not cost very much, if any, performance. The structure of the target folder could be changed to target - st - stm32 stm32f103rb.cfg stm32f105v8.cfg ... - str7 str710.cfg str711.cfg ... - str9 ... - nxp - lpc17xx ... - lpc2xxx ... and so on. Too many levels IMO. Just put stm32, str7, str9 directly under target. I don't know the ST parts, but I like NXP a lot and I've started looking at the TI LM3S (I think we should rename the files from stellaris) which also look nice. Have a look at stellaris.cfg, which seems to be generic for that family. I think that would improve the OpenOCD experience for the users... Yes and no. I think that it's really nice to only need to specify the family of chips that you're working with. It's still not very user-friendly ); Also yes and no. A typical openocd.cfg should just pull in some existing files from tcl/ but there are a lot of bad examples which confuse things, by copypasting everything into openocd.cfg instead of sourcing the distributed cfg files. If there isn't one already then I think an example on the web would go a long way. Do we have a wiki? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Shouldn't this be automatically detected? -- Ø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
