[Openocd-development] arm1136 download problems & performance
On Fri, Sep 11, 2009 at 6:54 AM, michal smulski wrote: > > Attached: > 1. debug output for load_image without and with memburst write on > arm1136. See the slow load time on first and error on the other one. Try "help arm11" and tinker with memrw_no_increment and memwrite_error_fatal options. If manage to get load_image to succeed run a "verify_image" check if the error is a red herring or not. You may need to fill the memory with garbage to avoid verify_image succeeding when in fact the last memory position wasn't touched. idea on improving arm11 burst memory performance: add option to make download open loop, i.e. do not check for completion of instructions... -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] feroceon: tighten error checking in bulk_write
Committed. Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] Dragonite support
Why doesn't target.c doesn't add dragonite_target to the target_types array? -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Please create threads more often...
I'd like to see new subjects broken out into new threads please. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] small feroceon.c cleanup
feroceon.c: put feroceon target definition at the end so to avoid a
bunch of useless forward declarations.
feroceon.c: put feroceon target definition at the end so to avoid a bunch of
forward declarations.
---
src/target/feroceon.c | 165 +++-
1 files changed, 79 insertions(+), 86 deletions(-)
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 6a673b7..8eea33e 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -56,14 +56,6 @@
#include "arm966e.h"
#include "target_type.h"
-
-int feroceon_examine(struct target_s *target);
-int feroceon_target_create(struct target_s *target, Jim_Interp *interp);
-int dragonite_target_create(struct target_s *target, Jim_Interp *interp);
-int feroceon_bulk_write_memory(target_t *target, uint32_t address, uint32_t
count, uint8_t *buffer);
-int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
-int feroceon_quit(void);
-
int feroceon_assert_reset(target_t *target)
{
armv4_5_common_t *armv4_5 = target->arch_info;
@@ -77,84 +69,6 @@ int feroceon_assert_reset(target_t *target)
return arm7_9_assert_reset(target);
}
-target_type_t feroceon_target =
-{
- .name = "feroceon",
-
- .poll = arm7_9_poll,
- .arch_state = arm926ejs_arch_state,
-
- .target_request_data = arm7_9_target_request_data,
-
- .halt = arm7_9_halt,
- .resume = arm7_9_resume,
- .step = arm7_9_step,
-
- .assert_reset = feroceon_assert_reset,
- .deassert_reset = arm7_9_deassert_reset,
- .soft_reset_halt = arm926ejs_soft_reset_halt,
-
- .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
-
- .read_memory = arm7_9_read_memory,
- .write_memory = arm926ejs_write_memory,
- .bulk_write_memory = feroceon_bulk_write_memory,
- .checksum_memory = arm7_9_checksum_memory,
- .blank_check_memory = arm7_9_blank_check_memory,
-
- .run_algorithm = armv4_5_run_algorithm,
-
- .add_breakpoint = arm7_9_add_breakpoint,
- .remove_breakpoint = arm7_9_remove_breakpoint,
- .add_watchpoint = arm7_9_add_watchpoint,
- .remove_watchpoint = arm7_9_remove_watchpoint,
-
- .register_commands = arm926ejs_register_commands,
- .target_create = feroceon_target_create,
- .init_target = feroceon_init_target,
- .examine = feroceon_examine,
- .quit = feroceon_quit
-};
-
-target_type_t dragonite_target =
-{
- .name = "dragonite",
-
- .poll = arm7_9_poll,
- .arch_state = armv4_5_arch_state,
-
- .target_request_data = arm7_9_target_request_data,
-
- .halt = arm7_9_halt,
- .resume = arm7_9_resume,
- .step = arm7_9_step,
-
- .assert_reset = feroceon_assert_reset,
- .deassert_reset = arm7_9_deassert_reset,
- .soft_reset_halt = arm7_9_soft_reset_halt,
-
- .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
-
- .read_memory = arm7_9_read_memory,
- .write_memory = arm7_9_write_memory,
- .bulk_write_memory = feroceon_bulk_write_memory,
- .checksum_memory = arm7_9_checksum_memory,
- .blank_check_memory = arm7_9_blank_check_memory,
-
- .run_algorithm = armv4_5_run_algorithm,
-
- .add_breakpoint = arm7_9_add_breakpoint,
- .remove_breakpoint = arm7_9_remove_breakpoint,
- .add_watchpoint = arm7_9_add_watchpoint,
- .remove_watchpoint = arm7_9_remove_watchpoint,
-
- .register_commands = arm966e_register_commands,
- .target_create = dragonite_target_create,
- .init_target = feroceon_init_target,
- .examine = feroceon_examine,
- .quit = feroceon_quit
-};
-
int feroceon_dummy_clock_out(arm_jtag_t *jtag_info, uint32_t instr)
{
scan_field_t fields[3];
@@ -765,3 +679,82 @@ int feroceon_examine(struct target_s *target)
return ERROR_OK;
}
+
+target_type_t feroceon_target =
+{
+ .name = "feroceon",
+
+ .poll = arm7_9_poll,
+ .arch_state = arm926ejs_arch_state,
+
+ .target_request_data = arm7_9_target_request_data,
+
+ .halt = arm7_9_halt,
+ .resume = arm7_9_resume,
+ .step = arm7_9_step,
+
+ .assert_reset = feroceon_assert_reset,
+ .deassert_reset = arm7_9_deassert_reset,
+ .soft_reset_halt = arm926ejs_soft_reset_halt,
+
+ .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
+
+ .read_memory = arm7_9_read_memory,
+ .write_memory = arm926ejs_write_memory,
+ .bulk_write_memory = feroceon_bulk_write_memory,
+ .checksum_memory = arm7_9_checksum_memory,
+ .blank_check_memory = arm7_9_blank_check_memory,
+
+ .run_algorithm = armv4_5_run_algorithm,
+
+ .add_breakpoint = arm7_9_add_breakpoint,
+ .remove_breakpoint = arm7_9_remove_breakpoint,
+ .add_watchpoint = arm7_9_add_watchpoint,
+ .remove_watchpoint = arm7_9_remove_watchpoint,
+
+ .register_commands = arm926ejs_register_commands,
+ .target_create = feroceon_target_
[Openocd-development] [PATCH] feroceon: tighten error checking in bulk_write
Make sure the target is actually halted at the end of the transfer and
confirm from the target's r0 content that the right amount of data was
actually received.
feroceon: tighten error checking in bulk_write
---
src/target/feroceon.c | 19 +++
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 5bbf72c..6a673b7 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -634,9 +634,20 @@ int feroceon_bulk_write_memory(target_t *target, uint32_t
address, uint32_t coun
buffer += 4;
}
- target_halt(target);
- while (target->state != TARGET_HALTED)
- target_poll(target);
+ retval = target_halt(target);
+ if (retval == ERROR_OK)
+ retval = target_wait_state(target, TARGET_HALTED, 500);
+ if (retval == ERROR_OK) {
+uint32_t endaddress =
+ buf_get_u32(armv4_5->core_cache->reg_list[0].value, 0,
32);
+ if (endaddress != address + count*4) {
+ LOG_ERROR("DCC write failed,"
+ " expected end address 0x%08" PRIx32
+ " got 0x%0" PRIx32 "",
+ address + count*4, endaddress);
+ retval = ERROR_FAIL;
+ }
+ }
/* restore target state */
for (i = 0; i <= 5; i++)
@@ -650,7 +661,7 @@ int feroceon_bulk_write_memory(target_t *target, uint32_t
address, uint32_t coun
armv4_5->core_cache->reg_list[15].dirty = 1;
armv4_5->core_state = core_state;
- return ERROR_OK;
+ return retval;
}
int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target)
--
1.6.5.rc0.164.g5f6b0
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] Dragonite support
Dragonite is similar to the Feroceon core but has no MMU.
This can be found in chips such as the Marvell 8686 wireless chip.
Dragonite support. It is similar to the Feroceon core but has no MMU.
---
src/target/arm966e.c |3 --
src/target/arm966e.h |2 +
src/target/feroceon.c | 89 +++-
src/target/target.c |1 +
4 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/src/target/arm966e.c b/src/target/arm966e.c
index d8e8281..badcd4f 100644
--- a/src/target/arm966e.c
+++ b/src/target/arm966e.c
@@ -32,9 +32,6 @@
#define _DEBUG_INSTRUCTION_EXECUTION_
#endif
-/* cli handling */
-int arm966e_register_commands(struct command_context_s *cmd_ctx);
-
/* forward declarations */
int arm966e_target_create(struct target_s *target, Jim_Interp *interp);
int arm966e_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
diff --git a/src/target/arm966e.h b/src/target/arm966e.h
index 64641ea..c7a5b1b 100644
--- a/src/target/arm966e.h
+++ b/src/target/arm966e.h
@@ -34,6 +34,8 @@ typedef struct arm966e_common_s
uint32_t cp15_control_reg;
} arm966e_common_t;
+extern int arm966e_init_arch_info(target_t *target, arm966e_common_t *arm966e,
jtag_tap_t *tap);
+extern int arm966e_register_commands(struct command_context_s *cmd_ctx);
extern int arm966e_read_cp15(target_t *target, int reg_addr, uint32_t *value);
extern int arm966e_write_cp15(target_t *target, int reg_addr, uint32_t value);
diff --git a/src/target/feroceon.c b/src/target/feroceon.c
index 536b678..5bbf72c 100644
--- a/src/target/feroceon.c
+++ b/src/target/feroceon.c
@@ -1,5 +1,5 @@
/***
- * Copyright (C) 2008 by Marvell Semiconductors, Inc.*
+ * Copyright (C) 2008-2009 by Marvell Semiconductors, Inc.
*
* Written by Nicolas Pitre*
* *
* Copyright (C) 2008 by Hongtao Zheng *
@@ -22,10 +22,10 @@
***/
/*
- * Marvell Feroceon support, including Orion and Kirkwood SOCs.
+ * Marvell Feroceon/Dragonite support.
*
- * The Feroceon core mimics the ARM926 ICE interface with the following
- * differences:
+ * The Feroceon core, as found in the Orion and Kirkwood SoCs amongst others,
+ * mimics the ARM926 ICE interface with the following differences:
*
* - the MOE (method of entry) reporting is not implemented
*
@@ -43,6 +43,9 @@
*
* - the DCC channel is half duplex (only one FIFO for both directions) with
* seemingly no proper flow control.
+ *
+ * The Dragonite core is the non-mmu version based on the ARM966 model, and
+ * it shares the above issues as well.
*/
#ifdef HAVE_CONFIG_H
@@ -50,11 +53,13 @@
#endif
#include "arm926ejs.h"
+#include "arm966e.h"
#include "target_type.h"
int feroceon_examine(struct target_s *target);
int feroceon_target_create(struct target_s *target, Jim_Interp *interp);
+int dragonite_target_create(struct target_s *target, Jim_Interp *interp);
int feroceon_bulk_write_memory(target_t *target, uint32_t address, uint32_t
count, uint8_t *buffer);
int feroceon_init_target(struct command_context_s *cmd_ctx, struct target_s
*target);
int feroceon_quit(void);
@@ -111,6 +116,44 @@ target_type_t feroceon_target =
.quit = feroceon_quit
};
+target_type_t dragonite_target =
+{
+ .name = "dragonite",
+
+ .poll = arm7_9_poll,
+ .arch_state = armv4_5_arch_state,
+
+ .target_request_data = arm7_9_target_request_data,
+
+ .halt = arm7_9_halt,
+ .resume = arm7_9_resume,
+ .step = arm7_9_step,
+
+ .assert_reset = feroceon_assert_reset,
+ .deassert_reset = arm7_9_deassert_reset,
+ .soft_reset_halt = arm7_9_soft_reset_halt,
+
+ .get_gdb_reg_list = armv4_5_get_gdb_reg_list,
+
+ .read_memory = arm7_9_read_memory,
+ .write_memory = arm7_9_write_memory,
+ .bulk_write_memory = feroceon_bulk_write_memory,
+ .checksum_memory = arm7_9_checksum_memory,
+ .blank_check_memory = arm7_9_blank_check_memory,
+
+ .run_algorithm = armv4_5_run_algorithm,
+
+ .add_breakpoint = arm7_9_add_breakpoint,
+ .remove_breakpoint = arm7_9_remove_breakpoint,
+ .add_watchpoint = arm7_9_add_watchpoint,
+ .remove_watchpoint = arm7_9_remove_watchpoint,
+
+ .register_commands = arm966e_register_commands,
+ .target_create = dragonite_target_create,
+ .init_target = feroceon_init_target,
+ .examine = feroceon_examine,
+ .quit = feroceon_quit
+};
int feroceon_dummy_clock_out(arm_jtag_t *jtag_info, uint32_t instr)
{
@@ -621,16 +664,10 @@ int feroceon_quit(void)
return ERROR_OK;
}
-int feroceon_target_create(struct target_s *target, Jim_Interp *interp)
+void
[Openocd-development] libftdi regression since rev 2573
The SheevaPlug interface is now unusable since rev 2573: Error: unable to open ftdi device: device not found Runtime error, file "command.c", line 469: Backing out changes from that revision does indeed fix the issue. So what was the point of that patch? Nicolas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] imx31 nand flash controller support
Hello, all.
little cleaning
--
Regards,
Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia
http://www.rez.ru
Jabber ID: imp...@jabber.ru
diff -Naur /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.c trunk/src/flash/mx3_nand.c
--- /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.c 2009-09-11 08:36:19.126864628 +0600
+++ trunk/src/flash/mx3_nand.c 2009-09-11 09:43:08.0 +0600
@@ -43,8 +43,6 @@
"minimal granularity is one half-word, %d is incorrect";
static const char sram_buffer_bounds_err_msg[] =
"trying to access out of SRAM buffer bound (addr=0x%x)";
-static const char invalid_command_sequense_err_msg[] =
- "invalid command sequence in %s";
static const char get_status_register_err_msg[] = "can't get NAND status";
static uint32_t in_sram_address;
unsigned char sign_of_sequental_byte_read;
@@ -237,7 +235,7 @@
* testing IOMUX settings; must be in "functional-mode output and
* functional-mode input" mode
*/
- uint8_t test_iomux;
+ int test_iomux;
test_iomux = ERROR_OK;
test_iomux |=
test_iomux_settings (target, 0x43fac0c0, 0x7f7f7f00, "d0,d1,d2");
@@ -438,10 +436,6 @@
mx3_nf_info->fin = MX3_NF_FIN_DATAOUT;
mx3_nf_info->optype = MX3_NF_DATAOUT_PAGE;
break;
- case NAND_CMD_SEQIN:
- LOG_ERROR ("aaa");
- return ERROR_FAIL;
- break;
default:
mx3_nf_info->optype = MX3_NF_DATAOUT_PAGE;
}
diff -Naur /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.h trunk/src/flash/mx3_nand.h
--- /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.h 2009-09-11 08:36:19.130199416 +0600
+++ trunk/src/flash/mx3_nand.h 2009-09-11 09:37:49.0 +0600
@@ -1,3 +1,30 @@
+
+/***
+ * Copyright (C) 2009 by Alexei Babich *
+ * Rezonans plc., Chelyabinsk, Russia*
+ * imp...@mail.ru*
+ * *
+ * 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. *
+ ***/
+
+/*
+ * Freescale iMX3* OpenOCD NAND Flash controller support.
+ *
+ * Many thanks to Ben Dooks for writing s3c24xx driver.
+ */
#include
#define MX3_NF_BASE_ADDR 0xb800
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] imx31 nand flash controller support
> I've committed this so that testing can commence. The chances > of regressions seem very slight. Thank you :) > The formatting/coding style is a bit quaint I use the automatic formatting to match the requirements of style. I also do not like the result. I use a style similar to the style of Kernighan-Ritchie, it is more dense and convenient for me. Therefore, it would be nice if the options for "indent" utility, would be clarified community for more exact match. -- Regards, Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia http://www.rez.ru Jabber ID: imp...@jabber.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
Øyvind Harboe wrote:
> Regarding the run_algorithm. This makes me think about
> the refactoring I did for the arm simulation code
>
> W.r.t. run_algorithm, I was thinking about how much work
> it would be to write a *small* machine code translator
> that would translate generic code in to machine specific
> code... Sounds impossibly hard, but is it really? I haven't
> looked at what's out there.
>
We also talked a while back about the idea of a standardized download to
the target.
The general idea i was taking about at the time is described below.
-Duane.
A small say 2K, 100% position independent common block of arm code.
perhaps - an "armv4" based 32bit code (not thumb)
why? Because that would cover all arm7 and arm9 chips.
Perhaps - another for cortexM3
perhaps - another for armv7 - (cortexA8)
Maybe other chips are "fixed address" - but generally ARM code can be made
to be PIC in a very simple way.
When this idea would be bad: Little quick downloads
When this idea would be good: BULK transfers, flash programing, etc.
The idea is this:
Let us assume there is a 4K block (working space) of ram some where.
The code could be 2K, set aside 1K for stack (yes 1K)
And 1K for a download buffer - could be bigger..
Maybe we work with 4K and 4K...
The entry point would be fixed - always at Buffer+0
Set the program counter there, nothing else needs set.
Then, set a SW breakpoint at - a fixed location.
Example: Buffer + 0x10
This would leave a few bytes @ the start for startup code
And might be easier for different chips (ie: non-arm chips).
The target code *RUNS*, sets up the stack and then enters
some type of "for-ever" loop, that looks like this:
*AND* is 100% written in *C* code - not assembler.
some_c_function( void )
{
uint32_t buffer[16];
// this example puts the 4K transfer buffer on the stack
uint32_t download_buffer[ 1024 ];
int result;
// assume result=success
result = 0;
for( ;; ){
// buffer[0] = holds result
buffer[0] = result;
// tell app where transfer buffer is located.
buffer[1] = &download_buffer[0];
buffer[2] = sizeof(download_buffer);
// this hits openocd breakpoint
openocd_syscall( &buffer[0] );
// openocd stuffs parameters in the buffer.
// parameter 0 - is the command.
// parameter 1/2/3 ... /15 are command specific
switch( buffer[0] ){
case CFI_FLASH_ERASE:
// params 1,2,3 are address and length
result= perform_cfi_erase( &buffer[0] );
case HIGH_SPEED_DOWNLOAD:
// on ARM this might use CP15 DCC
result =perform_high_speed_download(
&buffer[0] );
case .. other commands
// break
} // switch
} // forever()
}
==
Why do I suggest C? And the above method...
Because it would work on *ALL* targets!
One only needs to *compile* a small C program.
And little helpers would be very fast.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
Regarding the run_algorithm. This makes me think about the refactoring I did for the arm simulation code W.r.t. run_algorithm, I was thinking about how much work it would be to write a *small* machine code translator that would translate generic code in to machine specific code... Sounds impossibly hard, but is it really? I haven't looked at what's out there. -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
On Thursday 10 September 2009, Øyvind Harboe wrote: > > I can see there is run_algorithm implemented in arm11.c. Can you give me > > some pointers on what needs to be added/changed? I can take a stab at > > this. > > I think David looked at this... > > Can you share David? One issue I have with the ARM run_algorithm() stuff is that each core has a separate *interface* ... the last param is core-specific, not generic for all ARM cores. So for example the src/flash/arm_nandwrite.c code can't be used on ARMv6 or ARMv7 cores. And there are various CFI utils that can't be used either (for NOR flash). Which means if you have some ARM algorithm, you need different invocation code for ARMv4/ARMv5, ARMv6 (like arm1136), ARMv7, etc. OR ... there's pretty dubious stuff going on there, where the ARMv4/ARMv5 stuff is used as "generic ARM" even though there's a bunch of stuff that should be core-specific. Sorting all that out could be messy; but the place to start is that "arch_info" parameter. Now, the arm11 stuff (is it arm1136-specific? or does it work for other arm11 cores?) doesn't use that param. But half the code in its run_algorithm() method is commented out, Thumb isn't supported, there's a big HACKHACKHACK comment up front, and so forth. One gets the feeling it's been used much yet! So one thing to do is just to address those obvious problems in the code. Specific to the ARM1136 cores, I'm not sure the bulk_write() method is as fast as it should be. For ARMv4/ARMv5 there is some DCC write code which seems to make a big difference; it uses the run_algorithm() logic. Doesn't NOR flash writing use those bulk_write() paths? Section 14.8.14 of the ARM1136 spec shows what is claimed to be a code sequence that's optimized for fast writes. I think something using the DCC would be faster. (Note: DCC on 1136 differs from v4/v5.) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
On Thu, Sep 10, 2009 at 10:03 PM, michal smulski wrote: > > I can see there is run_algorithm implemented in arm11.c. Can you give me > some pointers on what needs to be added/changed? I can take a stab at > this. I think David looked at this... Can you share David? > Note that I see a really slow times for coping uboot to DDR memory > (load_image). Is this expected as well? > > If I turn on burst writes, things go much faster but I get an error > message and the end. Separate post instructions & details to reproduce? > > Thanks, > Michal > > On Thu, 2009-09-10 at 10:07 +0200, Øyvind Harboe wrote: >> Committed. >> >> Thanks! >> >> > 1. How do I speed up flash writes. Right now, I get about 2kB/s write to >> > NOR (see flashUBOOT proc). >> >> the arm11 needs the run_algorithm support. Known problem, "sombody" >> needs to pitch in, it's not super hard. >> >> > 2. Is there a way to run openocd and flash write command from the same >> > script. That is, I don't want to telnet to port and run flash write >> > command. I would like to automate it. >> >> Write a script: >> >> init # initializes openocd >> flash # do whatever you need to do >> >> >> >> > > -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm1136 scripts
I can see there is run_algorithm implemented in arm11.c. Can you give me some pointers on what needs to be added/changed? I can take a stab at this. Note that I see a really slow times for coping uboot to DDR memory (load_image). Is this expected as well? If I turn on burst writes, things go much faster but I get an error message and the end. Thanks, Michal On Thu, 2009-09-10 at 10:07 +0200, Øyvind Harboe wrote: > Committed. > > Thanks! > > > 1. How do I speed up flash writes. Right now, I get about 2kB/s write to > > NOR (see flashUBOOT proc). > > the arm11 needs the run_algorithm support. Known problem, "sombody" > needs to pitch in, it's not super hard. > > > 2. Is there a way to run openocd and flash write command from the same > > script. That is, I don't want to telnet to port and run flash write > > command. I would like to automate it. > > Write a script: > > init # initializes openocd > flash # do whatever you need to do > > > > ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD current SVN regression on s3c6410
> -Original Message- > From: openocd-development-boun...@lists.berlios.de [mailto:openocd- > development-boun...@lists.berlios.de] On Behalf Of Harald Welte > Sent: dinsdag 8 september 2009 11:20 > To: Øyvind Harboe > Cc: openocd-development@lists.berlios.de > Subject: Re: [Openocd-development] OpenOCD current SVN regression on s3c6410 > > On Tue, Sep 08, 2009 at 08:48:58AM +0200, Øyvind Harboe wrote: > > Does anyone have an s3c6410 PCB out there they > > could donate to us? > > unfortunately Openmoko is no longer working on the 6410 based phone, > otherwise > we could have tried to get one. The SMDK6410 are quite expensive (typical > old-fashioned reference boards with expensive connectors and dozens of > peripherals), so I think it's unlikely somebody will cough one up. > > What I would personally contribute is a SmartQ5 device (less than USD 200), > but > I don't know if people have figured out which test pads or other unpopulated > connectors to use for JTAG. > > If somebody can suggest a relatively inexpensive 6410 based mass-market > product > tha thas known JTAG locations, I'd donate one to OpenOCD. Harald, I came across these boards. Prices seem reasonable. http://www.developmentboard.net/index.php/productdetail/Development+board/ARM11/SAMSUNG/S3C6410/MINI6410/info/1 Nico Coesel ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD current SVN regression on s3c6410
On Tue, Sep 08, 2009 at 08:48:58AM +0200, Øyvind Harboe wrote: > Does anyone have an s3c6410 PCB out there they > could donate to us? unfortunately Openmoko is no longer working on the 6410 based phone, otherwise we could have tried to get one. The SMDK6410 are quite expensive (typical old-fashioned reference boards with expensive connectors and dozens of peripherals), so I think it's unlikely somebody will cough one up. What I would personally contribute is a SmartQ5 device (less than USD 200), but I don't know if people have figured out which test pads or other unpopulated connectors to use for JTAG. If somebody can suggest a relatively inexpensive 6410 based mass-market product tha thas known JTAG locations, I'd donate one to OpenOCD. -- - Harald Weltehttp://laforge.gnumonks.org/ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] imx31 nand flash controller support
I've committed this so that testing can commence. The chances of regressions seem very slight. The formatting/coding style is a bit quaint, but I'm going to let it slide. I think it is important to get the tested code committed as is, and then correct the formatting afterwards so we can track any regressions in svn via bisection easily. Your efforts are very much appreciated! Thanks! -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] imx31 nand flash controller support
Hello all.
This is my first attempt to contribute to open projects.
Do not judge strictly, please.
The current state of the driver: support imx31. I expect to add support imx35.
For formatting I used the commands like:
indent -st --line-length80 -nbad -bap -bbb -sob -cdb -sc -i4 -ip4 -lp -bli4 -c4
-cli4 -nbfda -fca -npsl ~/mx3_nand.c | sed "s/^\ \{4\,\}/\t/g;s/[ \t]*$//"
>mx3_nand.c
Thank you.
--
Regards,
Alexei Babich, circuit design engineer, Rezonans plc., Chelyabinsk, Russia
http://www.rez.ru
Jabber ID: imp...@jabber.ru
diff -Naur /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/Makefile.am /tmp/openocd/src/flash/Makefile.am
--- /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/Makefile.am 2009-08-31 11:22:56.996055759 +0600
+++ /tmp/openocd/src/flash/Makefile.am 2009-09-08 10:29:12.0 +0600
@@ -35,7 +35,8 @@
ocl.c \
mflash.c \
pic32mx.c \
- avrf.c
+ avrf.c \
+ mx3_nand.c
noinst_HEADERS = \
flash.h \
@@ -58,6 +59,7 @@
mflash.h \
ocl.h \
pic32mx.h \
- avrf.h
+ avrf.h \
+ mx3_nand.h
MAINTAINERCLEANFILES = $(srcdir)/Makefile.in
diff -Naur /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.c /tmp/openocd/src/flash/mx3_nand.c
--- /mnt/data/clfs2/__hidden/source/openocd/trunk/src/flash/mx3_nand.c 1970-01-01 05:00:00.0 +0500
+++ /tmp/openocd/src/flash/mx3_nand.c 2009-09-10 17:44:55.0 +0600
@@ -0,0 +1,908 @@
+
+/***
+ * Copyright (C) 2009 by Alexei Babich *
+ * Rezonans plc., Chelyabinsk, Russia*
+ * imp...@mail.ru*
+ * *
+ * 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. *
+ ***/
+
+/*
+ * Freescale iMX3* OpenOCD NAND Flash controller support.
+ *
+ * Many thanks to Ben Dooks for writing s3c24xx driver.
+ */
+
+/*
+driver tested with STMicro NAND512W3A @imx31
+tested "nand probe #", "nand erase # 0 #", "nand dump # file 0 #", "nand write # file 0"
+get_next_halfword_from_sram_buffer() not tested
+*/
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include "mx3_nand.h"
+
+static const char target_not_halted_err_msg[] =
+ "target must be halted to use mx3 NAND flash controller";
+static const char data_block_size_err_msg[] =
+ "minimal granularity is one half-word, %d is incorrect";
+static const char sram_buffer_bounds_err_msg[] =
+ "trying to access out of SRAM buffer bound (addr=0x%x)";
+static const char invalid_command_sequense_err_msg[] =
+ "invalid command sequence in %s";
+static const char get_status_register_err_msg[] = "can't get NAND status";
+static uint32_t in_sram_address;
+unsigned char sign_of_sequental_byte_read;
+
+static int test_iomux_settings (target_t * target, uint32_t value,
+uint32_t mask, const char *text);
+static int initialize_nf_controller (struct nand_device_s *device);
+static int get_next_byte_from_sram_buffer (target_t * target, uint8_t * value);
+static int get_next_halfword_from_sram_buffer (target_t * target,
+ uint16_t * value);
+static int poll_for_complete_op (target_t * target, const char *text);
+static int validate_target_state (struct nand_device_s *device);
+static int do_data_output (struct nand_device_s *device);
+
+static int imx31_nand_device_command (struct command_context_s *cmd_ctx,
+ char *cmd, char **args, int argc,
+ struct nand_device_s *device);
+static int imx31_init (struct nand_device_s *device);
+static int imx31_read_data (struct nand_device_s *device, void *data);
+static int imx31_write_data (struct nand_device_s *device, uint16_t data);
+static int imx31_nand_ready (struct nand_device_s *device, int timeout);
+static int imx31_register_commands (struct command_context_s *c
Re: [Openocd-development] arn1136 scripts
Committed. Thanks! > 1. How do I speed up flash writes. Right now, I get about 2kB/s write to > NOR (see flashUBOOT proc). the arm11 needs the run_algorithm support. Known problem, "sombody" needs to pitch in, it's not super hard. > 2. Is there a way to run openocd and flash write command from the same > script. That is, I don't want to telnet to port and run flash write > command. I would like to automate it. Write a script: init # initializes openocd flash # do whatever you need to do -- Øyvind Harboe Embedded software and hardware consulting services http://www.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
