Hi,
I have a board which has four cpus, each cpu has four cores, and the
four cpus are concated by fpga. And I don't know how to write the config
file. Could you help me?
Thank you.
2013/7/16 <openocd-devel-requ...@lists.sourceforge.net>
> Send OpenOCD-devel mailing list submissions to
> openocd-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
> or, via email, send a message with subject or body 'help' to
> openocd-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> openocd-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenOCD-devel digest..."
>
>
> Today's Topics:
>
> 1. Problems with DM368 (Joel Holdsworth)
> 2. Re: Problems with DM368 (Joel Holdsworth)
> 3. Re: 16-bit CFI flash detection with big endian MIPS
> (Oleksij Rempel)
> 4. Re: Problems with DM368 (Paul Fertser)
> 5. [PATCH]: dfa30e8 target: fix halt and wait_halt timeout units
> (ger...@openocd.zylin.com)
> 6. [PATCH]: e7875ad etm: prevent segfault when reading bogus
> information (ger...@openocd.zylin.com)
> 7. [PATCH]: 578ca3f fm3: add Fujitsu MB9Ax family support
> (ger...@openocd.zylin.com)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 15 Jul 2013 12:09:30 +0100
> From: Joel Holdsworth <j...@airwebreathe.org.uk>
> Subject: [OpenOCD-devel] Problems with DM368
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <51e3d86a.1020...@airwebreathe.org.uk>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi All,
>
> I'm tackling a couple of issues that maybe this list can help me with.
>
> My setup is a bespoke board with a TI DM368 (very similar to the
> Davinci DM365) with a Flyswatter 2 adapter.
>
> I have two problems:
>
> 1. I'm having trouble connecting. The only way I can get it to
> enumerate the TAPs is if I press the board reset button with the
> ribbon cable disconnected, then connect the ribbon, then run openocd.
> If I don't follow this procedure, it times out with "Error: couldn't
> read enough bytes from FT2232 device (0 < 81)" messages.
>
> Any ideas why this would be?
>
> 2. My JTAG port doesn't have a SRST pin on it, so I want to use
> davinci_wdog_reset. Unfortunately this fails because of a problem with
> the mww command. If I call the offending command in isolation (mww
> phys 0x01c21c28 0x00004000) with the debug level set to three, I get
> the following messages printed:
>
> Debug: 407 43677 command.c:145 script_debug(): command - ocd_command
> ocd_command type ocd_mww phys 0x01c21c28 0x00004000
> Debug: 408 43677 command.c:145 script_debug(): command - mww ocd_mww
> phys 0x01c21c28 0x00004000
> Debug: 410 43677 command.c:631 run_command(): Command failed with
> error code -304
> User : 411 43678 command.c:669 command_run_line(): in procedure 'mww'
>
> I added some printfs to the jim_target_mw function, which showed that
> the function is never called. It's as if the binding is failing somehow.
>
> Any ideas?
>
> Best Regards
> Joel Holdsworth
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 15 Jul 2013 12:12:00 +0100
> From: Joel Holdsworth <j...@airwebreathe.org.uk>
> Subject: Re: [OpenOCD-devel] Problems with DM368
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <51e3d900.4050...@airwebreathe.org.uk>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Oh, I forgot to mention...
>
> I'm running off Git head.
>
> Best Regards
> Joel Holdsworth
>
>
> On 15/07/13 12:09, Joel Holdsworth wrote:
> > Hi All,
> >
> > I'm tackling a couple of issues that maybe this list can help me
> > with.
> >
> > My setup is a bespoke board with a TI DM368 (very similar to the
> > Davinci DM365) with a Flyswatter 2 adapter.
> >
> > I have two problems:
> >
> > 1. I'm having trouble connecting. The only way I can get it to
> > enumerate the TAPs is if I press the board reset button with the
> > ribbon cable disconnected, then connect the ribbon, then run
> > openocd. If I don't follow this procedure, it times out with
> > "Error: couldn't read enough bytes from FT2232 device (0 < 81)"
> > messages.
> >
> > Any ideas why this would be?
> >
> > 2. My JTAG port doesn't have a SRST pin on it, so I want to use
> > davinci_wdog_reset. Unfortunately this fails because of a problem
> > with the mww command. If I call the offending command in isolation
> > (mww phys 0x01c21c28 0x00004000) with the debug level set to three,
> > I get the following messages printed:
> >
> > Debug: 407 43677 command.c:145 script_debug(): command -
> > ocd_command ocd_command type ocd_mww phys 0x01c21c28 0x00004000
> > Debug: 408 43677 command.c:145 script_debug(): command - mww
> > ocd_mww phys 0x01c21c28 0x00004000 Debug: 410 43677 command.c:631
> > run_command(): Command failed with error code -304 User : 411 43678
> > command.c:669 command_run_line(): in procedure 'mww'
> >
> > I added some printfs to the jim_target_mw function, which showed
> > that the function is never called. It's as if the binding is
> > failing somehow.
> >
> > Any ideas?
> >
> > Best Regards Joel Holdsworth
> >
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 15 Jul 2013 13:22:42 +0200
> From: Oleksij Rempel <li...@rempel-privat.de>
> Subject: Re: [OpenOCD-devel] 16-bit CFI flash detection with big
> endian MIPS
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <51e3db82.2000...@rempel-privat.de>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Am 14.07.2013 00:45, schrieb Pete Batard:
> > On 2013.07.12 10:21, Andreas Fritiofson wrote:
> >> Are you talking about the same patches that are published in gerrit,
> >> ending with http://openocd.zylin.com/1464 ?
> >
> > Dunno. I was pointed to a mips github repo, that may or may not include
> > these patches, and this is what I have been using for my tests.
>
> Hi,
>
> patches on github and gerrit are same.
>
> >> Then please post your
> >> feedback there. Most maintainers are relatively unfamiliar with the MIPS
> >> code base so it's hard for us to tell if patches are in a mergeable
> >> state, i.e. without breaking other MIPS configurations. Therefore,
> >> without third party review and opinions, the patches risk going stale.
> >
> > I'll see what I can do, but I'm already behind reviewing patches that I
> > need to review for libusbx, and I also have way too much non libusbx
> > stuff to churn through. This means that any OpenOCD work will be very
> > low priority => don't expect anything fast.
> >
> > Regards,
> >
> > /Pete
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > OpenOCD-devel mailing list
> > OpenOCD-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openocd-devel
> >
>
>
> --
> Regards,
> Oleksij
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 15 Jul 2013 20:42:12 +0400
> From: Paul Fertser <fercer...@gmail.com>
> Subject: Re: [OpenOCD-devel] Problems with DM368
> To: Joel Holdsworth <j...@airwebreathe.org.uk>
> Cc: openocd-devel@lists.sourceforge.net
> Message-ID: <20130715164212.ga18...@home.lan>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> On Mon, Jul 15, 2013 at 12:09:30PM +0100, Joel Holdsworth wrote:
> > 1. I'm having trouble connecting. The only way I can get it to
> > enumerate the TAPs is if I press the board reset button with the
> > ribbon cable disconnected, then connect the ribbon, then run openocd.
> > If I don't follow this procedure, it times out with "Error: couldn't
> > read enough bytes from FT2232 device (0 < 81)" messages.
>
> That ft2232 driver has some known issues and it's unlikely anybody's
> interested in debugging it. Please try interface/ftdi/flyswatter2.cfg
> instead which is using a new rewritten driver ftdi.
>
> Also pay attention to your "reset_config". You should set it to match
> your particular board and adapter. If you have doubts SRST on your
> adapter works properly, you can use "jtag_reset" command interactively
> via telnet to verify the functionality with a voltmeter (you should
> probably do that even though your board's connector lacks srst as
> it'll be useful for other targets you might eventually meet). Check
> other JTAG signals as well, your story about disconnecting the cable
> looks fishy.
>
> > 2. My JTAG port doesn't have a SRST pin on it, so I want to use
> > davinci_wdog_reset. Unfortunately this fails because of a problem with
> > the mww command. If I call the offending command in isolation (mww
> > phys 0x01c21c28 0x00004000) with the debug level set to three, I get
> > the following messages printed:
> >
> > Debug: 407 43677 command.c:145 script_debug(): command - ocd_command
> > ocd_command type ocd_mww phys 0x01c21c28 0x00004000
> > Debug: 408 43677 command.c:145 script_debug(): command - mww ocd_mww
> > phys 0x01c21c28 0x00004000
> > Debug: 410 43677 command.c:631 run_command(): Command failed with
> > error code -304
> > User : 411 43678 command.c:669 command_run_line(): in procedure 'mww'
>
> git grep suggests me -304 means ERROR_TARGET_NOT_HALTED, so you
> probably just need to add 'halt' before your 'mww' command.
>
> HTH
> --
> Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
> mailto:fercer...@gmail.com
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 16 Jul 2013 06:11:30 +0000 (UTC)
> From: ger...@openocd.zylin.com
> Subject: [OpenOCD-devel] [PATCH]: dfa30e8 target: fix halt and
> wait_halt timeout units
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <20130716061130.75e7e24...@openocd.zylin.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is an automated email from Gerrit.
>
> Paul Fertser (fercer...@gmail.com) just uploaded a new patch set to
> Gerrit, which you can find at http://openocd.zylin.com/1504
>
> -- gerrit
>
> commit dfa30e8f3071a2d36bc1025c3c26e7f13cc8f0cb
> Author: Paul Fertser <fercer...@gmail.com>
> Date: Tue Jul 16 10:00:42 2013 +0400
>
> target: fix halt and wait_halt timeout units
>
> Documentation says they should be given values in milliseconds,
> DEFAULT_HALT_TIMEOUT matches that too.
>
> Change-Id: Ic1a30fa90f75b412c43fe50ba187d01c3d0a5fba
> Signed-off-by: Paul Fertser <fercer...@gmail.com>
>
> diff --git a/src/target/target.c b/src/target/target.c
> index 60a8a77..1f517ac 100644
> --- a/src/target/target.c
> +++ b/src/target/target.c
> @@ -2417,8 +2417,6 @@ COMMAND_HANDLER(handle_wait_halt_command)
> int retval = parse_uint(CMD_ARGV[0], &ms);
> if (ERROR_OK != retval)
> return ERROR_COMMAND_SYNTAX_ERROR;
> - /* convert seconds (given) to milliseconds (needed) */
> - ms *= 1000;
> }
>
> struct target *target = get_current_target(CMD_CTX);
> @@ -5538,7 +5536,7 @@ static const struct command_registration
> target_exec_command_handlers[] = {
> .handler = handle_wait_halt_command,
> .mode = COMMAND_EXEC,
> .help = "wait up to the specified number of milliseconds "
> - "(default 5) for a previously requested halt",
> + "(default 5000) for a previously requested halt",
> .usage = "[milliseconds]",
> },
> {
> @@ -5546,7 +5544,7 @@ static const struct command_registration
> target_exec_command_handlers[] = {
> .handler = handle_halt_command,
> .mode = COMMAND_EXEC,
> .help = "request target to halt, then wait up to the
> specified"
> - "number of milliseconds (default 5) for it to
> complete",
> + "number of milliseconds (default 5000) for it to
> complete",
> .usage = "[milliseconds]",
> },
> {
>
> --
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 16 Jul 2013 07:39:15 +0000 (UTC)
> From: ger...@openocd.zylin.com
> Subject: [OpenOCD-devel] [PATCH]: e7875ad etm: prevent segfault when
> reading bogus information
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <20130716073915.55f7224...@openocd.zylin.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is an automated email from Gerrit.
>
> Paul Fertser (fercer...@gmail.com) just uploaded a new patch set to
> Gerrit, which you can find at http://openocd.zylin.com/1505
>
> -- gerrit
>
> commit e7875ada28e3b9fa794d1424903144f13a100f59
> Author: Paul Fertser <fercer...@gmail.com>
> Date: Tue Jul 16 11:29:15 2013 +0400
>
> etm: prevent segfault when reading bogus information
>
> When I do not have the JTAG adapter connected to the target, I often
> end up always reading 1s from the chain. If the OpenOCD is configured
> to connect to an ETM-equipped target (i.MX25 ARM9 in my case), this
> results in writing garbage values in the etm reg_cache as the ETM bit
> fields for the comparators, counters and outputs are wider than the
> amount of entries in the corresponding arrays. This later results in a
> segfault in the first etm_reg_lookup() call.
>
> Change-Id: Ied81fdbf3a53a3dd749e2e5e97adf86c012df575
> Signed-off-by: Paul Fertser <fercer...@gmail.com>
>
> diff --git a/src/target/etm.c b/src/target/etm.c
> index e99c24f..be5dd02 100644
> --- a/src/target/etm.c
> +++ b/src/target/etm.c
> @@ -144,6 +144,7 @@ static const struct etm_reg_info etm_addr_comp[] = {
> ADDR_COMPARATOR(14),
> ADDR_COMPARATOR(15),
> ADDR_COMPARATOR(16),
> + { 0, 0, 0, 0, NULL }
> #undef ADDR_COMPARATOR
> };
>
> @@ -162,6 +163,7 @@ static const struct etm_reg_info etm_data_comp[] = {
> DATA_COMPARATOR(6),
> DATA_COMPARATOR(7),
> DATA_COMPARATOR(8),
> + { 0, 0, 0, 0, NULL }
> #undef DATA_COMPARATOR
> };
>
> @@ -179,6 +181,7 @@ static const struct etm_reg_info etm_counters[] = {
> ETM_COUNTER(2),
> ETM_COUNTER(3),
> ETM_COUNTER(4),
> + { 0, 0, 0, 0, NULL }
> #undef ETM_COUNTER
> };
>
> @@ -206,6 +209,7 @@ static const struct etm_reg_info etm_outputs[] = {
> ETM_OUTPUT(2),
> ETM_OUTPUT(3),
> ETM_OUTPUT(4),
> + { 0, 0, 0, 0, NULL }
> #undef ETM_OUTPUT
> };
>
> @@ -265,6 +269,11 @@ static void etm_reg_add(unsigned bcd_vers, struct
> arm_jtag *jtag_info,
> * version of the ETM, to the specified cache.
> */
> for (; nreg--; r++) {
> + /* No more registers to add */
> + if (!r->size) {
> + LOG_ERROR("etm_reg_add is requested to add
> non-existing registers, ETM config might be bogus");
> + return;
> + }
>
> /* this ETM may be too old to have some registers */
> if (r->bcd_vers > bcd_vers)
>
> --
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 16 Jul 2013 13:55:52 +0000 (UTC)
> From: ger...@openocd.zylin.com
> Subject: [OpenOCD-devel] [PATCH]: 578ca3f fm3: add Fujitsu MB9Ax
> family support
> To: openocd-devel@lists.sourceforge.net
> Message-ID: <20130716135552.0eba224...@openocd.zylin.com>
> Content-Type: text/plain; charset="utf-8"
>
> This is an automated email from Gerrit.
>
> Spencer Oliver (s...@spen-soft.co.uk) just uploaded a new patch set to
> Gerrit, which you can find at http://openocd.zylin.com/1506
>
> -- gerrit
>
> commit 578ca3f4ac25147d7afbf4bead887beca2298c08
> Author: Nemui Trinomius <nemuisan_kawausogas...@live.jp>
> Date: Tue Jul 16 14:44:20 2013 +0100
>
> fm3: add Fujitsu MB9Ax family support
>
> Not tested, adapted from
> http://tech.groups.yahoo.com/group/versaloon/message/391
>
> Change-Id: I52048f6e8e66b38087fa249eb66ceab6801d07d5
> Signed-off-by: Spencer Oliver <s...@spen-soft.co.uk>
>
> diff --git a/src/flash/nor/fm3.c b/src/flash/nor/fm3.c
> index 32e8179..a9a11a3 100644
> --- a/src/flash/nor/fm3.c
> +++ b/src/flash/nor/fm3.c
> @@ -229,7 +229,7 @@ static int fm3_erase(struct flash_bank *bank, int
> first, int last)
> return ERROR_TARGET_NOT_HALTED;
> }
>
> - LOG_INFO("Fujitsu MB9Bxxx: Sector Erase ... (%d to %d)", first,
> last);
> + LOG_INFO("Fujitsu MB9[A/B]FXXX: Sector Erase ... (%d to %d)",
> first, last);
>
> /* FASZR = 0x01, Enables CPU Programming Mode (16-bit Flash
> acccess) */
> retval = target_write_u32(target, 0x40000000, 0x0001);
> @@ -296,7 +296,7 @@ static int fm3_write_block(struct flash_bank *bank,
> uint8_t *buffer,
> {
> struct fm3_flash_bank *fm3_info = bank->driver_priv;
> struct target *target = bank->target;
> - uint32_t buffer_size = 2048; /* 8192 for MB9Bxx6! */
> + uint32_t buffer_size = 2048; /* Default minimum value */
> struct working_area *write_algorithm;
> struct working_area *source;
> uint32_t address = bank->base + offset;
> @@ -307,6 +307,10 @@ static int fm3_write_block(struct flash_bank *bank,
> uint8_t *buffer,
> uint32_t u32FlashSeqAddress1;
> uint32_t u32FlashSeqAddress2;
>
> + /* Increase buffer_size if needed */
> + if (buffer_size < (target->working_area_size / 2))
> + buffer_size = (target->working_area_size / 2);
> +
> u32FlashType = (uint32_t) fm3_info->flashtype;
>
> if (u32FlashType == fm3_flash_type1) {
> @@ -446,13 +450,13 @@ static int fm3_write_block(struct flash_bank *bank,
> uint8_t *buffer,
> 0x00, 0xBE, /* BKPT
> #0 */
>
> /* The following address pointers assume, that the code is running
> from */
> - /* address 0x1FFF8008. These address pointers will be patched, if
> a */
> - /* different start address in RAM is used (e.g. for Flash type 2)!
> */
> - 0x00, 0x80, 0xFF, 0x1F, /* u32DummyRead address in RAM
> (0x1FFF8000) */
> - 0x04, 0x80, 0xFF, 0x1F /* u32FlashResult address in RAM
> (0x1FFF8004) */
> + /* SRAM basic-address(BASE_ADDR)+8.These address pointers will be
> patched */
> + /* if a different start address in RAM is used (e.g. for Flash
> type 2)! */
> + 0x00, 0x80, 0xFF, 0x1F, /* u32DummyRead address in RAM
> (BASE_ADDR) */
> + 0x04, 0x80, 0xFF, 0x1F /* u32FlashResult address in RAM
> (BASE_ADDR+4)*/
> };
>
> - LOG_INFO("Fujitsu MB9B500: FLASH Write ...");
> + LOG_INFO("Fujitsu MB9[A/B]FXXX: FLASH Write ...");
>
> /* disable HW watchdog */
> retval = target_write_u32(target, 0x40011C00, 0x1ACCE551);
> @@ -487,8 +491,6 @@ static int fm3_write_block(struct flash_bank *bank,
> uint8_t *buffer,
> if (retval != ERROR_OK)
> return retval;
>
> -
> -
> /* memory buffer */
> while (target_alloc_working_area(target, buffer_size, &source) !=
> ERROR_OK) {
> buffer_size /= 2;
> @@ -522,7 +524,7 @@ static int fm3_write_block(struct flash_bank *bank,
> uint8_t *buffer,
> break;
>
> /* Patching 'local variable address' for different RAM
> addresses */
> - if (write_algorithm->address != 0x1FFF8008) {
> + if (write_algorithm->address != (target->working_area_phys
> + 8)) {
> /* Algorithm: u32DummyRead: */
> retval = target_write_u32(target,
> (write_algorithm->address)
> + sizeof(fm3_flash_write_code) - 8,
> (write_algorithm->address) - 8);
>
> --
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> OpenOCD-devel mailing list
> OpenOCD-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openocd-devel
>
>
> End of OpenOCD-devel Digest, Vol 21, Issue 17
> *********************************************
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
