Re: [Openocd-development] [patch/RFC 2/2] stellaris: write words only
David Brownell wrote: Never attempt to write partial words. The hardware only allows writing entire words ... so don't guess about what users want to do with the other bytes. Require them to say explicitly what data they want written. Hm. Not sure if this patch affects write binary behaviour, but in the past, I had problems writing binary files with an odd number of bytes to flash, because the last byte would trigger a similar check. If this patch re-introduces that behaviour, I ask not to apply it - it would make writing programs with odd-sized data segments a pain. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
On Thursday 17 December 2009, Dean Glazeski wrote:
+...@deffn Command {at91sam9 cle} num addr_line
+Configure the address line used for latching commands. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
+...@deffn Command {at91sam9 ale} num addr_line
+Configure the address line used for latching addresses. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
I suppose num is still necessary ... I don't know how the
new names are exposed. Are you sure that passing the name in
(which you might just know) doesn't work too?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
On Thursday 17 December 2009, Dean Glazeski wrote:
+...@deffn Command {at91sam9 cle} num addr_line
So addr_line is for example 8 to indicate that A8 is
used to drive the CLE signal? Or should that be 0x0100
instead?
And ... are there defaults, or are ALE and CLE must specify
things? If the latter ... are they shared between all the
various NANDs of $TARGET, or is there some other reason these
two aren't parameters to nand device ...? It'd be good to
avoid extra commands, as well as the potential failure modes
from someone not providing those parameters.
+ target_write_u8(target, info-cmd, command);
+
+ return ERROR_OK;
Why not return target_write_u8(...) etc?
As a rule, you should be returning status codes from
routines you've called, not ERROR_OK.
+static int at91sam9_write_data(struct nand_device *nand, uint16_t data) {
That's not a struct decl, or a switch/for/if/while/do/... control
flow construct. So the brace should be at the beginning of the
next line. :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] All ones when connecting to LM3S811 Evaluation Board (Chip Revision C2)
On Thu, Dec 17, 2009 at 7:52 PM, Charles Vaughn cvau...@gmail.com wrote: I've recently purchased an LM3S811 evaluation board. I've tried to connect to it with OpenOCD, but I've met very little success even initiating a connection. When I use the version of OpenOCD available from Ubuntu repositories (r2403), I get the following error: m...@mint /usr/share/openocd/scripts $ sudo openocd -f interface/luminary.cfg -f target/lm3s811.cfg Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:11) svn:r2403 BUGS? Read /usr/share/doc/openocd/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Error: JTAG communication failure: check connection, JTAG interface, target power etc. Error: trying to validate configured JTAG chain anyway... Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x3F. tap=lm3s811.cpu pos=0 expected 0x1 got 3 Warn : Could not validate JTAG chain, continuing anyway... Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Block read error address 0xe000ed00, count 0x1 Warn : Invalid ACK in SWJDP transaction When I use version 0.3.1 or check out the latest with GIT, I get this error message: Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones I've tried the following scripts: board/ek-lm3s811.cfg interface/luminary.cfg target/lm3s811.cfg interface/luminary.cfg target/stellaris.cfg The only difference is when using the board/ek-lm3s811.cfg the board does visibly reset. I've changed the jtag_khz to 100 and 1, nrst delay to 1, all with no change in result. My best guess is that there is some difference in the C2 revision of the chips that's causing this, though reviewing the datasheet, I see no difference other than device ID. This is a christmas present for a friend, so I'd appreciate any help... I've just pulled the latest changes from OpenOCD git repo and tried to connect to my LM3S811 board with openocd.cfg containing: source [ find interface/luminary.cfg ] source [ find target/stellaris.cfg ] This is output from flash info 0: TI/LMI Stellaris information: Chip is class 0 (Sandstorm) LM3S811 rev C2 did1: 0x0032002d, arch: 0x32002d, eproc: ARMv7M, ramsize: 8k, flashsize: 64k master clock: 6000kHz, rcc is 0x0, rcc2 is 0x0 pagesize: 1024, pages: 64, lockbits: 32, pages per lockbit: 2 Regards, Yegor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] All ones when connecting to LM3S811 Evaluation Board (Chip Revision C2)
What revision is your board? The title is a bit out of sync with the issue, as in June it appears TI multiplexed SWO and JTAG. My board rev is LMWLV-C. On Fri, Dec 18, 2009 at 3:13 AM, Yegor Yefremov yegorsli...@googlemail.comwrote: On Thu, Dec 17, 2009 at 7:52 PM, Charles Vaughn cvau...@gmail.com wrote: I've recently purchased an LM3S811 evaluation board. I've tried to connect to it with OpenOCD, but I've met very little success even initiating a connection. When I use the version of OpenOCD available from Ubuntu repositories (r2403), I get the following error: m...@mint /usr/share/openocd/scripts $ sudo openocd -f interface/luminary.cfg -f target/lm3s811.cfg Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:11) svn:r2403 BUGS? Read /usr/share/doc/openocd/BUGS $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ 500 kHz jtag_nsrst_delay: 100 jtag_ntrst_delay: 100 Error: JTAG communication failure: check connection, JTAG interface, target power etc. Error: trying to validate configured JTAG chain anyway... Error: Could not validate JTAG scan chain, IR mismatch, scan returned 0x3F. tap=lm3s811.cpu pos=0 expected 0x1 got 3 Warn : Could not validate JTAG chain, continuing anyway... Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Invalid ACK in SWJDP transaction Warn : Block read error address 0xe000ed00, count 0x1 Warn : Invalid ACK in SWJDP transaction When I use version 0.3.1 or check out the latest with GIT, I get this error message: Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones I've tried the following scripts: board/ek-lm3s811.cfg interface/luminary.cfg target/lm3s811.cfg interface/luminary.cfg target/stellaris.cfg The only difference is when using the board/ek-lm3s811.cfg the board does visibly reset. I've changed the jtag_khz to 100 and 1, nrst delay to 1, all with no change in result. My best guess is that there is some difference in the C2 revision of the chips that's causing this, though reviewing the datasheet, I see no difference other than device ID. This is a christmas present for a friend, so I'd appreciate any help... I've just pulled the latest changes from OpenOCD git repo and tried to connect to my LM3S811 board with openocd.cfg containing: source [ find interface/luminary.cfg ] source [ find target/stellaris.cfg ] This is output from flash info 0: TI/LMI Stellaris information: Chip is class 0 (Sandstorm) LM3S811 rev C2 did1: 0x0032002d, arch: 0x32002d, eproc: ARMv7M, ramsize: 8k, flashsize: 64k master clock: 6000kHz, rcc is 0x0, rcc2 is 0x0 pagesize: 1024, pages: 64, lockbits: 32, pages per lockbit: 2 Regards, Yegor ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] NAND read data page refactor.
That may be a bug, but that's how the original NAND code did the read and write functions. It does make sense for them to either both do the swap or not do the swap. // Dean Glazeski On Fri, Dec 18, 2009 at 1:43 AM, David Brownell davi...@pacbell.net wrote: On Thursday 17 December 2009, Dean Glazeski wrote: Feel free to make the same tweak to the NAND write page data function as well (patch 2/2 in the series). That's swapping 16-bit data before it writes ... but the read function isn't swapping in either case. Bug? If so I'll ask you to send a bugfix patch after I merge updated versions of these, probably later tonight. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
Right now, I'm specifically calling get_nand_device_by_num or some such.
Can you suggest a better method or direct me to an example NAND flash? I'm
not really aware of any other method.
// Dean Glazeski
On Fri, Dec 18, 2009 at 4:13 AM, David Brownell davi...@pacbell.net wrote:
On Thursday 17 December 2009, Dean Glazeski wrote:
+...@deffn Command {at91sam9 cle} num addr_line
+Configure the address line used for latching commands. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
+...@deffn Command {at91sam9 ale} num addr_line
+Configure the address line used for latching addresses. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
I suppose num is still necessary ... I don't know how the
new names are exposed. Are you sure that passing the name in
(which you might just know) doesn't work too?
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
Yep, addr_line is a number like 8 that I automatically shift so that I
don't have to specify the line using binary notation. It's just easier to
handle it in C in my opinion.
ALE and CLE do have defaults (21 and 22 respectively). Ready/~Busy and chip
enable do not have defaults, however, but it seems a like I'd be making the
NAND device command even longer. At some point it seems good to not add
more to that command. I'll leave that to the maintainers to decide, though.
I'll have to go through the code, but yes, things like target_write_u8(..)
should be the return value. I've attached a new version of the patch to
address formatting and return value stuff.
// Dean Glazeski
On Fri, Dec 18, 2009 at 4:29 AM, David Brownell davi...@pacbell.net wrote:
On Thursday 17 December 2009, Dean Glazeski wrote:
+...@deffn Command {at91sam9 cle} num addr_line
So addr_line is for example 8 to indicate that A8 is
used to drive the CLE signal? Or should that be 0x0100
instead?
And ... are there defaults, or are ALE and CLE must specify
things? If the latter ... are they shared between all the
various NANDs of $TARGET, or is there some other reason these
two aren't parameters to nand device ...? It'd be good to
avoid extra commands, as well as the potential failure modes
from someone not providing those parameters.
+ target_write_u8(target, info-cmd, command);
+
+ return ERROR_OK;
Why not return target_write_u8(...) etc?
As a rule, you should be returning status codes from
routines you've called, not ERROR_OK.
+static int at91sam9_write_data(struct nand_device *nand, uint16_t data)
{
That's not a struct decl, or a switch/for/if/while/do/... control
flow construct. So the brace should be at the beginning of the
next line. :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
From 840367b53169aa51dd7fbfc6d2029db92e3c0fca Mon Sep 17 00:00:00 2001
From: Dean Glazeski dngl...@gmail.com
Date: Wed, 9 Dec 2009 12:40:54 -0600
Subject: [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
This creates the TCL interface for configuring an AT91SAM9 NAND flash controller
and implements the necessary functions to correctly work with a NAND flash
device connected to the chip. This includes updates to the driver list and the
Makefile.am to support building the driver and also houses the documentation
update in openocd.texi.
---
doc/openocd.texi | 35 ++
src/flash/nand/Makefile.am |3 +-
src/flash/nand/at91sam9.c | 750
src/flash/nand/driver.c|2 +
4 files changed, 789 insertions(+), 1 deletions(-)
create mode 100644 src/flash/nand/at91sam9.c
diff --git a/doc/openocd.texi b/doc/openocd.texi
index cda5be3..8546742 100644
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -4812,6 +4812,41 @@ As noted above, the @command{nand device} command allows
driver-specific options and behaviors.
Some controllers also activate controller-specific commands.
+...@deffn {NAND Driver} at91sam9
+This driver handles the NAND controllers found on AT91SAM9 family chips from
+Atmel. It takes two extra parameters: address of the NAND chip;
+address of the ECC controller.
+...@example
+nand device $NANDFLASH at91sam9 $CHIPNAME 0x4000 0xfe800
+...@end example
+AT91SAM9 chips support single-bit ECC hardware. The @code{write_page} and
+...@code{read_page} methods are used to utilize the ECC hardware unless they are
+disabled by using the @command{nand raw_access} command. There are four
+additional commands that are needed to fully configure the AT91SAM9 NAND
+controller.
+...@deffn Command {at91sam9 cle} num addr_line
+Configure the address line used for latching commands. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
+...@deffn Command {at91sam9 ale} num addr_line
+Configure the address line used for latching addresses. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
+
+For the next two commands, it is assumed that the pins have already been
+properly configured for input or output.
+...@deffn Command {at91sam9 rdy_busy} num pio_base_addr pin
+Configure the RDY/~BUSY input from the NAND device. The @var{num}
+paramter is the value shown by @command{nand list}. @var{pio_base_addr}
+is the base address of the PIO controller and @var{pin} is the pin number.
+...@end deffn
+...@deffn Command {at91sam9 ce} num pio_base_addr pin
+Configure the chip enable input to the NAND device. The @var{num}
+parameter is the value shown by @command{nand list}. @var{pio_base_addr}
+is the base address of the PIO controller and @var{pin} is the pin number.
+...@end deffn
+...@end deffn
+
@deffn {NAND Driver} davinci
This driver handles the NAND controllers found on DaVinci family
chips from Texas Instruments.
Re: [Openocd-development] Have the NAND erase function use the nand page command
The increase happens because the NAND erase function was using 1000 for a timeout so I just increased the general timeout to that amount. I don't think it should be a big deal because the timeout shouldn't happen normally. By the way, what is top-posting and how do I stop? // Dean Glazeski On Fri, Dec 18, 2009 at 2:32 AM, Marek Vasut marek.va...@gmail.com wrote: Dne Pá 18. prosince 2009 06:11:23 Dean Glazeski napsal(a): Sorry, I took another look and saw what you were talking about and how to correct for it. Here's another version that addresses that issue. // Dean Glazeski On Thu, Dec 17, 2009 at 10:56 PM, Dean Glazeski dngl...@gmail.com wrote: Oh, I didn't see that. This patch can be ignored then. It just looks so similar :). // Dean Glazeski On Thu, Dec 17, 2009 at 10:29 PM, David Brownell davi...@pacbell.net wrote: On Tuesday 15 December 2009, Dean Glazeski wrote: I noticed the NAND erase function was doing page command stuff, so I pulled the redundant code out. Patch is attached This doesn't look right. Consider the 16 Gbit large page chip I happen to have on some boards here: - read/write of 2KB page uses 5 byte addressing - erase of 128KB block uses 3 byte addressping You're making both use the 5 byte addressing ... basically, if this is going to be shared, the erase commands shouldn't be writing column addresses, just row addresses. - Dave Why are you incrementing the timeout from 100 to 1000 in the nand_page_command ? btw. please stop top-posting. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Have the NAND erase function use the nand page command
Dne Pá 18. prosince 2009 16:02:35 Dean Glazeski napsal(a): The increase happens because the NAND erase function was using 1000 for a timeout so I just increased the general timeout to that amount. I don't think it should be a big deal because the timeout shouldn't happen normally. By the way, what is top-posting and how do I stop? // Dean Glazeski Top-posting -- writing reply at the top of the mail that you're replying to. It's not a good practice and in many mailing lists, they'll not like it. So just stick the reply under it -- it's easier to read/follow -- I guess you get the point. Anyway, about the timeout, you're probably right it shouldn't matter. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch] flash fill[bwh] should use bulk i/o
It's currently allocating a big buffer but writing it out in
units of sizeof(host's pointer) ... sub-optimal.
--- a/src/flash/nor/tcl.c
+++ b/src/flash/nor/tcl.c
@@ -534,14 +534,16 @@ COMMAND_HANDLER(handle_flash_fill_command)
for (wrote = 0; wrote (count*wordsize); wrote += cur_size)
{
- cur_size = MIN((count*wordsize - wrote), sizeof(chunk));
struct flash_bank *bank;
+
bank = get_flash_bank_by_addr(target, address);
if (bank == NULL)
{
retval = ERROR_FAIL;
goto done;
}
+
+ cur_size = MIN((count * wordsize - wrote), chunksize);
err = flash_driver_write(bank, chunk, address - bank-base +
wrote, cur_size);
if (err != ERROR_OK)
{
@@ -576,7 +578,7 @@ COMMAND_HANDLER(handle_flash_fill_command)
duration_elapsed(bench), duration_kbps(bench,
wrote));
}
- done:
+done:
free(readback);
free(chunk);
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [patch/RFC 2/2] stellaris: write words only
On Friday 18 December 2009, Michael Schwingen wrote: David Brownell wrote: Though ... I suppose that just verifying flash writes would catch a number of these problems too. After all, the main constraint is that zero bits can't turn back to ones... Sounds good. Another alternative would be to read the current flash contents, patch in the byte to be written, and then write it back. That way, a single byte at the end of a segment can be written, and nothing is accidentally overwritten. Writing ones to it, as the current code does, should have the same no change effect ... hence my thought about verification. Consider what happens if you write to some flash that's not been erased beforehand. In most cases, you lose ... Semi-related ... how about the generic NOR patch insisting that erases only apply to whole sectors? It's not quite the converse of this patch. This one was perhaps more on the side of paranoia. That one was concern that the code was certainly doing something destructive, by clobbering data it was told to leave alone. Allowing erase only on complete sectors is fine with me, because the damage potential is large, and I see no direct use case where you would specify a partial sector and expect that the whole sector should be erased. My thought exactly. I'll commit that change as-is then... One thing to take care of would be write_image with the erase option: the image will probably not competely fill the last sector, but the erase should not fail in that case. ... and expect some followup bugfixes. That one, for example, certainly deserves at least a WARNING whenever it kicks in... - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH v2] Common target file for lm3s CPU family
On Tuesday 15 December 2009, Yegor Yefremov wrote: I've tested your changes with OpenOCD: 0.4.0-dev-00931-g6f929db (2009-12-15-13:50) It is working as earlier. For my board lm3s6432 I had to increase work-area amount to 0x4000 to avoid warnings. Issuing warnings was inappropriate; that behaviour should be gone now (in ...-963-g3f18900). But still I have a problem that sometimes the first erase/write attempt fails with the following messages: flash write_image erase image.bin 0x1000 bin auto erase enabled Algorithm flash write 2048 words to 0x1000, 16757 remaining error executing stellaris flash write algorithm Current code will report the status code there. If you still see the problem, please report that code. This would seem to indicate an issue at the level of Cortex-M3 algorithm operation. Not necessarily one caused by the Stellaris flash support ... though it's strange that this happens only the *FIRST* time. flash writing failed with CRIS: 0x0 I'll have to see about removing that diagnostic when it's useless, as it is here. CRIS == 0 is the output after success, too. ;) - Dave error writing to flash at address 0x at offset 0x1000 (-902) Command handler execution failed in procedure 'flash' called at file command.c, line 637 called at file command.c, line 352 but the second one always succeeds: ... ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Have the NAND erase function use the nand page command
A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Friday 18 December 2009, Dean Glazeski wrote: By the way, what is top-posting and how do I stop? When you trim down the message you're replying to, just make a point of sticking your reply *AFTER* the thing to which you're replying. Instead of before. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] Initial import of AT91SAM9 NAND flash driver.
On Friday 18 December 2009, Dean Glazeski wrote:
Right now, I'm specifically calling get_nand_device_by_num or some such.
Can you suggest a better method or direct me to an example NAND flash? I'm
not really aware of any other method.
+...@deffn Command {at91sam9 ale} num addr_line
+Configure the address line used for latching addresses. The @var{num}
+parameter is the value shown by @command{nand list}.
+...@end deffn
I suppose num is still necessary ... I don't know how the
new names are exposed. Are you sure that passing the name in
(which you might just know) doesn't work too?
Maybe Zach can answer; he's the one who changed the syntax
to require adding a name.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Have the NAND erase function use the nand page command
On Fri, Dec 18, 2009 at 2:48 PM, David Brownell davi...@pacbell.net wrote: A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? On Friday 18 December 2009, Dean Glazeski wrote: By the way, what is top-posting and how do I stop? When you trim down the message you're replying to, just make a point of sticking your reply *AFTER* the thing to which you're replying. Instead of before. Alright, GMail was putting my signature above the quoted email because of a lab thing I had enabled. It is now disabled so I should start to put my responses in a better place. I took a look at the archives and it is pretty hard to follow the conversation :). // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Have the NAND erase function use the nand page command
Hello Dean, Friday, December 18, 2009, 10:00:16 PM, you wrote: DG Alright, GMail was putting my signature above the quoted email DG because of a lab thing I had enabled. It is now disabled so I DG should start to put my responses in a better place. I took a look DG at the archives and it is pretty hard to follow the conversation :). Now you just need to remember to send text, not HTML. -- WBR, Igormailto:skochin...@mail.ru ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
