Re: [Openocd-development] Problem when tryng to flash LPC2368
About html, I am sorry! I think that it is fixed now.
I can post the complete solution, no problem. If I forgot to post
something, please tell it to me!
I am using the 0.2.0 version because I already was using it before to
write some LPC2109 boards.
Now I will try the 0.3.1 version... :-)
I am still having some problems to write the flash with gdb. If I use
the telnet connection to write directly in OpenOCD it is working.
I agree that the write to MEMMAP register should be placed inside the
config file but I got an error when trying it, I will try again later.
All that I need to do to write the memory in LPC2368 is:
1) Programmer configuration file
1.1) J-Link: jlink.cfg
#
# Segger J-Link
#
# http://www.segger.com/jlink.html
#
interface jlink
1.2) J-TEC (it is our own programmer based in FT2232, I will send a
patch to add it to OpenOCD later): jtec.cfg
#
# Tecnequip J-TEC
#
# http://www.tecnequip.com.br
#
interface ft2232
ft2232_layout jtec_jtag
ft2232_device_desc Dual RS232 A
2) CPU configuration file: lpc2368.cfg
# NXP LPC2103 ARM7TDMI-S with 32kB Flash and 8kB SRAM, clocked with
12MHz crystal
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
set _CHIPNAME lpc2368
}
if { [info exists ENDIAN] } {
set _ENDIAN $ENDIAN
} else {
set _ENDIAN little
}
if { [info exists CPUTAPID ] } {
set _CPUTAPID $CPUTAPID
} else {
set _CPUTAPID 0x4f1f0f0f
}
# LPC2000 - SRST causes TRST
reset_config trst_and_srst srst_pulls_trst
# reset delays
jtag_nsrst_delay 100
jtag_ntrst_delay 100
jtag_reset 1 1
jtag_reset 0 0
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf
-expected-id $_CPUTAPID
set _TARGETNAME [format %s.cpu $_CHIPNAME]
target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position
$_TARGETNAME -variant arm7tdmi-s_r4
# 8kB of internal SRAM
$_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x4000
-work-area-size 0x8000 -work-area-backup 0
# 32kB of internal Flash, core clocked with 12MHz crystal
# flash bank lpc2000 base size 0 0 target# variant clock
[calc_checksum]
flash bank lpc2000 0x0 0x8 0 0 0 lpc2000_v2 12000 calc_checksum
3) Execute OpenOCD:
sudo openocd -f jtec.cfg -f lpc2368.cfg
4) Connect by telnet and send commands:
$ telnet 127.0.0.1
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Open On-Chip Debugger
halt
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x40d7 pc: 0x00066a3c
flash write_image erase
/Projetos/linux/Linux/ARM/Programas/GDB/elfs/minilpc.elf
auto erase enabled
Padding image section 0 with 0 bytes
wrote 69996 byte from file
/Projetos/linux/Linux/ARM/Programas/GDB/elfs/minilpc.elf in 23.154978s
(2.952085 kb/s)
verify_image
/Projetos/linux/Linux/ARM/Programas/GDB/elfs/minilpc.elf
verified 69996 bytes in 2.292830s
When I fix the GDB configuration I will send it to the list.
Best regards,
Marcelo Utikawa da Fonseca
Øyvind Harboe escreveu:
On Wed, Dec 16, 2009 at 5:52 PM, Marcelo Utikawa da Fonseca
marcelo.fons...@tecnequip.com.br wrote:
Great, now it is working! :-)
I put the following line in my gdb config file:
monitor mwb 0xe01fc040 0x01
Thank you!
That's great, but actually that mwb should probably go into the
reset init sequence inside the config file I think.
Now please post to the complete solution to the list.
You probably want to see that config file go into the the next
release of OpenOCD, right?
Also what version of OpenOCD are you running? It says 0.2.0 and
that's an old version.
Can I ask where you got it and why you
decided to try with an older version?
-
Tecnequip Tecnologia em Equipamentos
Endere�o/Address: R. Ganges, 557
Cidade/City: S�o Paulo
Estado/State: SP
Pa�s/Country: Brasil
CEP/Postal Code: 03445-030
Fone/Phone: 55-11-20937199
FAX: 55-11-29412289
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem when tryng to flash LPC2368
Try with 0.3.1 and report back. If this is works with 0.2 and fails with git master head then the list will be interested. If this is works with git master head, then the list probably isn't hugely interested unless you provide clear details and possibly some patch/code to boot. -- Ø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] Problem when tryng to flash LPC2368
I have OpenOCD 0.3.1 working here now. GDB is still failing to write, I think that this is a gdb configuration problem. About our J-TEC programmer it is an open hardware. Who is interested in the schematic please mail me because it is not in our website yet. I will prepare a patch to include support for it in the OpenOCD. Is this possible? Best regards, Marcelo Utikawa da Fonseca Øyvind Harboe escreveu: Try with 0.3.1 and report back. If this is works with 0.2 and fails with git master head then the list will be interested. If this is works with git master head, then the list probably isn't hugely interested unless you provide clear details and possibly some patch/code to boot. - Tecnequip Tecnologia em Equipamentos Endere�o/Address: R. Ganges, 557 Cidade/City: S�o Paulo Estado/State: SP Pa�s/Country: Brasil CEP/Postal Code: 03445-030 Fone/Phone: 55-11-20937199 FAX: 55-11-29412289 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] multiple flash banks
I get the following on any device that has multiple flash banks, eg. flash bank pic32mx.flash pic32mx 0xbd00 0 0 0 pic32mx.cpu flash bank pic32mx.flash pic32mx 0xbfc0 0 0 0 pic32mx.cpu The second flash bank causes the error msg: Error: 256 16 command.c:370 register_command(): command 'pic32mx' is already registered in 'global' context Error: 257 16 command.c:370 register_command(): command 'chip_erase' is already registered in 'pic32mx' context Error: 258 16 command.c:370 register_command(): command 'pgm_word' is already registered in 'pic32mx' context For normal cmds i can see the msg making sense, but in the case of flash maybe not. Perhaps this also needs changing to a warning, as this msg is not a serious one. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] multiple flash banks
This is a small regression where Zach postponed (good!) registering the flash commands until they were actually used. The solution that comes to mind would be to check if the commands are already registered. That should amount to a few simple lines of code. I'm more concerned that there might be other cases of the same problem? What happens if we register two targets of the same type? -- Ø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] multiple flash banks
Øyvind Harboe wrote: This is a small regression where Zach postponed (good!) registering the flash commands until they were actually used. The solution that comes to mind would be to check if the commands are already registered. That should amount to a few simple lines of code. The code already checks for that, and the second instance is not registered. For other cmds outputting a LOG_ERROR is ok in this case - but not for multiple flash banks. Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problem when tryng to flash LPC2368
On Thursday 17 December 2009, Marcelo Utikawa da Fonseca wrote: About our J-TEC programmer it is an open hardware. Who is interested in the schematic please mail me because it is not in our website yet. I will prepare a patch to include support for it in the OpenOCD. Is this possible? We're happy to merge clean patches supporting new hardware. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Hi David, As I understand it, ANSI C says it returns NULL when it can't allocate memory. Anything else would be phenominally rude. You don't follow the thread, right? You don't read the people who said it is a bad idea to check the result ;-)? Alex and some others came up with the point, that on linux malloc doesn't come back anymore and send instead a sigterm. He posted this link: http://article.gmane.org/gmane.comp.audio.jackit/19998 I have just checked that out and this is NOT TRUE on my linux machine with Fedora Core 11. For the record, I've never heard of *ANY* runtime environment where a malloc()/calloc()/... failure aborts the program. Well.. yesterday people said that right here on the list. Best Regards, Carsten ___ 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 Thursday 17 December 2009, Charles Vaughn wrote: Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones I vaguely recall that some of the early Stellaris boards (like that one!) actually wired up TRST ... other chips don't seem to expose that signal, so it's not wired out of the JTAG adapters' CPLDs either. The all ones could indicate that the TAP is still being held in reset ... perhaps via TRST. I suggest you check your reset_config lines against board schematics, and maybe the code for that specific adapter. There are a bunch of Stellaris eval boards, with minor differences in JTAG wiring. I'm not sure which config is right for that board. I use interface/luminary.cfg on a different board and it's fine, so I'd expect once you sort out this config issue you'll have no problems. - Dave p.s. I also add reset_config srst_nogate to my board's default reset_config srst_only, but I don't recall that anything would care about that. ___ 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)
Oh fun. I'll take a look. That hadn't occurred to me, but that would make the most sense. On Thu, Dec 17, 2009 at 12:42 PM, David Brownell davi...@pacbell.netwrote: On Thursday 17 December 2009, Charles Vaughn wrote: Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones I vaguely recall that some of the early Stellaris boards (like that one!) actually wired up TRST ... other chips don't seem to expose that signal, so it's not wired out of the JTAG adapters' CPLDs either. The all ones could indicate that the TAP is still being held in reset ... perhaps via TRST. I suggest you check your reset_config lines against board schematics, and maybe the code for that specific adapter. There are a bunch of Stellaris eval boards, with minor differences in JTAG wiring. I'm not sure which config is right for that board. I use interface/luminary.cfg on a different board and it's fine, so I'd expect once you sort out this config issue you'll have no problems. - Dave p.s. I also add reset_config srst_nogate to my board's default reset_config srst_only, but I don't recall that anything would care about that. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Carsten Breuer wrote: Perhaps we should use something like: void *allocate_or_exit(size); I would also make some defines in types.h: #define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC #define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC With this, developers can't use malloc accidentally. This is just wrong. No one wants to malloc() to _always_ terminate the process. As I said, you have to differentiate the cases. If you alloc some big chunk of memory (like reading a .bin file for flashing, etc.), malloc() _may_ return NULL, and that case _must_ be checked. But in the vast majority of cases, malloc() is used to allocate small, fixed size structures. If a tiny malloc(64) fails, you would have to provide an error handling path that is guaranteed to not need additional memory. How would you make that guarantee? Do you know for sure, that your fprintf(stderr, HELP!); won't call malloc() itself? You can't. That's why it's better to leave those tiny mallocs unchecked. The only reason that those small mallocs would fail is a memory leak. Checking for NULL doesn't help there either - in the best case you will get a OOM after a random malloc, but won't get a hint on the _cause_ of the leak. There are much better tools for this job (just google around, there's everything from simple wrappers to valgrind -- no need to reinvent the wheel!). ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Codecheck
Hi Thomas, hi all, This is just wrong. No one wants to malloc() to _always_ terminate the process. As I said, you have to differentiate the cases. Do you read this? http://article.gmane.org/gmane.comp.audio.jackit/19998 We have discussed this already a lot and the plan must be first to get an inprovement of the current code base. Even in small steps. If you want to do it, please go for it. My solution would be to check every malloc. If someone else is standing up... that's fine for me. How would you make that guarantee? Do you know for sure, that your fprintf(stderr, HELP!); won't call malloc() itself? A printf is pretty fine and you can look at the code. You can alloc reserve memory that you can free if malloc fails. Nonetheless this all is academical. Improvement in small steps is all a way better Then talking 5 years for the perfect solution. What's you vote? Leave it as it is? Best Regards, Carsten ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] malloc: Vote what to do
Carsten Breuer wrote:
Hi all,
Hi!
after finding out, that malloc come back with NULL
even on linux (where people says here, it don't),
It does, but it's a tricky topic. Please post your test program!
I've tried this one on Ubuntu 9.10 in VirtualBox:
#include stdio.h
#include malloc.h
#include string.h
void main()
{
int sz = 16*1024*1024;
while (sz 0) {
printf(%d: , sz);
void *p = malloc(sz);
if (p != NULL) {
// Touch the memory !!!
// (observe the effect of commenting it out!)
//
memset(p, 0x55, sz);
printf(ok!\n);
}
else {
printf(failed.\n);
sz = 1;
}
}
printf(still alive!\n);
}
$ gcc eatmem.c -o eatmem
$ ./eatmem
16777216: ok!
16777216: ok!
[ .. ~30 times, takes 2 minutes with heavy thrashing]
16777216: ok!
16777216: ok!
16777216: ok!
16777216: ok!
16777216: ok!
Killed
Please note that without the memset, no thrashing or killing will occur.
The program will terminate with still alive!.
That's because linux has virtual memory, and can overcommit. Real memory
pages are only allocated on first _use_.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] malloc: Vote what to do
As a maintainer I would summarize the status quo as(and there are no plans to change this): - accept all clean patches to fix propagation of error handling. malloc() is just one example of broken error propagation - leave malloc()'s as-is meanwhile, we have tools to identify the cases where we're missing malloc() checks. Do not introduce a new function to mark the sites. -- Ø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] malloc: Vote what to do
On Thursday 17 December 2009, Øyvind Harboe wrote: As a maintainer I would summarize the status quo as(and there are no plans to change this): - accept all clean patches to fix propagation of error handling. malloc() is just one example of broken error propagation - leave malloc()'s as-is meanwhile, we have tools to identify the cases where we're missing malloc() checks. Do not introduce a new function to mark the sites. Right. By the way ... that http://article.gmane.org/gmane.comp.audio.jackit/19998 URL highlighted: Does that mean it never makes sense to write OOM-safe userspace code? No. For very low-level system daemons, such as udev or the init system itself clean OOM handling is important. And in some embedded appliances that is true too. That last sentence is relevant here -- we have at least one embedded appliance configuration. For that matter, so is the next-to-last one -- JTAG is lower level than those two examples. :) - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] malloc: Vote what to do
On Thu, 2009-12-17 at 21:44 +0100, Carsten Breuer wrote: Hi all, after finding out, that malloc come back with NULL even on linux (where people says here, it don't), im starting to loose interest in the hole thing. So what should we do? I think now, that all this arguments not to check malloc result is academical and some arguments are not even true. I believe the actual argument against NULL checks was in the context of NULL pointers passed into API functions. All returns from malloc should be checked for NULL. I will come to the house of anyone who says otherwise with a 2x4 clue club and knock them over the head with it. If that fails, I will go for their kneecaps. --Z ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/rfc] NOR FLASH: only erase/unlock whole sectors
Much to my surprise, I observed a flash erase_address ...
command erasing data which I didn't say should be erased.
The issue turns out to be generic NOR flash code which was
silently, and rather dangerously, morphing partial-sector
references into unrequested whole-sector ones.
This patch removes that low-level morphing. If desired, it
can and should be done in higher level code.
---
I suspect there's one GDB server path which should do that
morphing, but it looks like a later one already handles it.
Other than that, does anyone object to fixing this?
NEWS |2 ++
src/flash/nor/core.c | 44
2 files changed, 38 insertions(+), 8 deletions(-)
--- a/NEWS
+++ b/NEWS
@@ -39,6 +39,8 @@ Flash Layer:
- bank_name: reference the bank with its defined name
- driver_name[.N]: reference the driver's Nth bank
New 'nand verify' command to check bank against an image file.
+ The flash erase_address command now rejects partial sectors;
+ previously it would silently erase data you did not request.
Board, Target, and Interface Configuration Scripts:
ARM9
--- a/src/flash/nor/core.c
+++ b/src/flash/nor/core.c
@@ -279,11 +279,13 @@ int default_flash_blank_check(struct fla
return ERROR_OK;
}
+
/* erase given flash region, selects proper bank according to target and
address */
static int flash_iterate_address_range(struct target *target, uint32_t addr,
uint32_t length,
int (*callback)(struct flash_bank *bank, int first, int last))
{
struct flash_bank *c;
+ uint32_t last_addr = addr + length; /* first address AFTER end */
int first = -1;
int last = -1;
int i;
@@ -306,26 +308,52 @@ static int flash_iterate_address_range(s
return callback(c, 0, c-num_sectors - 1);
}
- /* check whether it fits */
+ /* check whether it all fits in this bank */
if (addr + length - 1 c-base + c-size - 1)
return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
+ /** @todo: handle erasures that cross into adjacent banks */
+
addr -= c-base;
for (i = 0; i c-num_sectors; i++)
{
- /* check whether sector overlaps with the given range and is
not yet erased */
- if (addr c-sectors[i].offset + c-sectors[i].size addr +
length c-sectors[i].offset c-sectors[i].is_erased != 1) {
- /* if first is not set yet then this is the first
sector */
- if (first == -1)
+ struct flash_sector *f = c-sectors + i;
+
+ /* start only on a sector boundary */
+ if (first 0) {
+ /* is this the first sector? */
+ if (addr == f-offset)
first = i;
- last = i; /* and it is the last one so far in any case
*/
+ else if (addr f-offset)
+ break;
+ }
+
+ /* is this (also?) the last sector? */
+ if (last_addr == f-offset + f-size) {
+ last = i;
+ break;
}
+
+ /* MUST finish on a sector boundary */
+ if (last_addr = f-offset)
+ break;
}
- if (first == -1 || last == -1)
- return ERROR_OK;
+ /* invalid start or end address? */
+ if (first == -1 || last == -1) {
+ LOG_ERROR(address range 0x%8.8x .. 0x%8.8x
+ is not sector-aligned,
+ (unsigned) c-base + addr,
+ (unsigned) last_addr - 1);
+ return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
+ }
+ /* The NOR driver may trim this range down, based on
+* whether or not a given sector is already erased.
+*
+* REVISIT should *we* trim it... ?
+*/
return callback(c, first, last);
}
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch/RFC 2/2] stellaris: write words only
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.
---
Similar in concept to the NOR patch I sent for comment.
I sure hope we don't have a lot of upper-level code that
is so sloppy about flash handling that it requires writing
random garbage ...
src/flash/nor/stellaris.c | 33 ++---
1 file changed, 2 insertions(+), 31 deletions(-)
--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -927,8 +927,6 @@ static int stellaris_write(struct flash_
uint32_t address = offset;
uint32_t flash_cris, flash_fmc;
uint32_t words_remaining = (count / 4);
- uint32_t bytes_remaining = (count 0x0003);
- uint32_t bytes_written = 0;
int retval;
if (bank-target-state != TARGET_HALTED)
@@ -943,9 +941,9 @@ static int stellaris_write(struct flash_
if (stellaris_info-did1 == 0)
return ERROR_FLASH_BANK_NOT_PROBED;
- if (offset 0x3)
+ if ((offset 0x3) || (count 0x3))
{
- LOG_WARNING(offset size must be word aligned);
+ LOG_WARNING(Only word-aligned data may be written to flash.);
return ERROR_FLASH_DST_BREAKS_ALIGNMENT;
}
@@ -1014,33 +1012,6 @@ static int stellaris_write(struct flash_
words_remaining--;
}
- if (bytes_remaining)
- {
- uint8_t last_word[4] = {0xff, 0xff, 0xff, 0xff};
- int i = 0;
-
- while (bytes_remaining 0)
- {
- last_word[i++] = *(buffer + bytes_written);
- bytes_remaining--;
- bytes_written++;
- }
-
- if (!(address 0xff))
- LOG_DEBUG(0x% PRIx32 , address);
-
- /* Program one word */
- target_write_u32(target, FLASH_FMA, address);
- target_write_buffer(target, FLASH_FMD, 4, last_word);
- target_write_u32(target, FLASH_FMC, FMC_WRKEY | FMC_WRITE);
- /* LOG_DEBUG(0x%x 0x%x 0x%x,address,buf_get_u32(buffer, 0,
32),FMC_WRKEY | FMC_WRITE); */
- /* Wait until write complete */
- do
- {
- target_read_u32(target, FLASH_FMC, flash_fmc);
- } while (flash_fmc FMC_WRITE);
- }
-
/* Check access violations */
target_read_u32(target, FLASH_CRIS, flash_cris);
if (flash_cris (AMASK))
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [patch 1/2] stellaris: update bulk flash writes
Try to right-size the SRAM buffers, by not:
- using them for very small writes
- giving up when a large buffer isn't available
- allocating buffers much larger than their data
Also don't:
- bother loading the code unless we can allocate the buffer too
- be so verbose with messaging (including, too-high severity)
The minimum buffer size is something of a guess. It's eight
times smaller than before, almost the same size as the code
being downloaded. It probably deserves some tuning.
Also, note an erratum affecting flash protection on some chips.
---
src/flash/nor/stellaris.c | 66 ++--
1 file changed, 46 insertions(+), 20 deletions(-)
--- a/src/flash/nor/stellaris.c
+++ b/src/flash/nor/stellaris.c
@@ -748,6 +748,9 @@ static int stellaris_protect(struct flas
/* Write commit command */
/* REVISIT safety check, since this cannot be undone
* except by the Recover a locked device procedure.
+* REVISIT some chips (e.g. '3748-A0, DustDevil) have an erratum
+* making FMPPE writes inadvisable ... it makes future mass erase
+* operations fail.
*/
LOG_WARNING(Flash protection cannot be removed once commited, commit
is NOT executed !);
/* target_write_u32(target, FLASH_FMC, FMC_WRKEY | FMC_COMT); */
@@ -823,37 +826,49 @@ static int stellaris_write_block(struct
struct armv7m_algorithm armv7m_info;
int retval = ERROR_OK;
+ /* power of two, and multiple of word size */
+ static const unsigned buf_min = 32;
+
+ /* for small buffers it's faster not to download an algorithm */
+ if (wcount buf_min)
+ return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
+
LOG_DEBUG((bank=%p buffer=%p offset=%08 PRIx32 wcount=%08 PRIx32
,
bank, buffer, offset, wcount);
/* flash write code */
if (target_alloc_working_area(target, sizeof(stellaris_write_code),
write_algorithm) != ERROR_OK)
{
- LOG_WARNING(no working area available, can't do block memory
writes);
+ LOG_DEBUG(no working area available, can't do block memory
writes);
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
};
- target_write_buffer(target, write_algorithm-address,
- sizeof(stellaris_write_code),
- (uint8_t *) stellaris_write_code);
+ /* plus a buffer big enough for this data */
+ if (wcount buffer_size) {
+ buffer_size = wcount;
+ buffer_size += buf_min - 1;
+ buffer_size = ~(buf_min - 1);
+ }
/* memory buffer */
while (target_alloc_working_area(target, buffer_size, source) !=
ERROR_OK)
{
- LOG_DEBUG(called target_alloc_working_area(target=%p
buffer_size=%08 PRIx32 source=%p),
- target, buffer_size, source);
buffer_size /= 2;
- if (buffer_size = 256)
+ if (buffer_size = buf_min)
{
- /* if we already allocated the writing code, but failed
to get a buffer, free the algorithm */
- if (write_algorithm)
- target_free_working_area(target,
write_algorithm);
+ target_free_working_area(target, write_algorithm);
- LOG_WARNING(no large enough working area available,
can't do block memory writes);
+ LOG_DEBUG(no buffer; can't do block memory writes);
return ERROR_TARGET_RESOURCE_NOT_AVAILABLE;
}
+ LOG_DEBUG(retry target_alloc_working_area(%s, size=%d),
+ target_name(target), (unsigned) buffer_size);
};
+ retval = target_write_buffer(target, write_algorithm-address,
+ sizeof(stellaris_write_code),
+ (uint8_t *) stellaris_write_code);
+
armv7m_info.common_magic = ARMV7M_COMMON_MAGIC;
armv7m_info.core_mode = ARMV7M_MODE_ANY;
@@ -870,11 +885,18 @@ static int stellaris_write_block(struct
buf_set_u32(reg_params[0].value, 0, 32, source-address);
buf_set_u32(reg_params[1].value, 0, 32, address);
buf_set_u32(reg_params[2].value, 0, 32, 4*thisrun_count);
- LOG_INFO(Algorithm flash write % PRIi32 words to 0x%
PRIx32 , % PRIi32 remaining, thisrun_count, address, (wcount -
thisrun_count));
- LOG_DEBUG(Algorithm flash write % PRIi32 words to 0x%
PRIx32 , % PRIi32 remaining, thisrun_count, address, (wcount -
thisrun_count));
- if ((retval = target_run_algorithm(target, 0, NULL, 3,
reg_params, write_algorithm-address, write_algorithm-address +
sizeof(stellaris_write_code)-10, 1, armv7m_info)) != ERROR_OK)
+ LOG_DEBUG(Algorithm flash write % PRIi32
+
Re: [Openocd-development] Codecheck
On Thursday 17 December 2009, Carsten Breuer wrote: As I understand it, ANSI C says it returns NULL when it can't allocate memory. Anything else would be phenominally rude. You don't follow the thread, right? You don't read the people who said it is a bad idea to check the result ;-)? I may have overlooked such blatantly bad advice. My point was that since NULL is a standard return value from malloc(), it needs to be checked. It's not a case of how a routine should behave given an out-of-spec input value ... it's a case of a very clearly defined function output. Alex and some others came up with the point, that on linux malloc doesn't come back anymore and send instead a sigterm. He posted this link: http://article.gmane.org/gmane.comp.audio.jackit/19998 I referenced that in my message. You weren't representing that discussion accurately ... it's about overcommitting virtual memory, which can in a sense retroactively make a pointer from malloc() point to memory that's not present. I have just checked that out and this is NOT TRUE on my linux machine with Fedora Core 11. That failure mode is: alloc some memory, get back pointer to address space, and then at some later point you try writing to that memory. But since the system was using lazy allocation, at that later point there may not be any swapspace to page that memory into ... so what you get is a kind of deferred error, if the system is under very high load. For the record, I've never heard of *ANY* runtime environment where a malloc()/calloc()/... failure aborts the program. Well.. yesterday people said that right here on the list. Sometimes people don't know what they're talking about. The OOM killer situation is not a malloc() failure. It's about virtual memory overcommit. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] malloc: Thanks for the answers
Hi all, thanks for the answers and to clear this point. Since the majority votes for check the result, i can start hacking now :-). Best Regards, Carsten ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 2/2] NAND write data page refactoring.
Refactored the write page raw function into two new functions for writing data
to a NAND device and then another function to finish up a write to a NAND
device. This includes some new updates to introduce more error checking to
existing code.
---
src/flash/nand/core.c | 116 ++---
src/flash/nand/core.h |3 +
2 files changed, 64 insertions(+), 55 deletions(-)
diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c
index de601b4..7535247 100644
--- a/src/flash/nand/core.c
+++ b/src/flash/nand/core.c
@@ -643,7 +643,8 @@ static int nand_write_plain(struct nand_device *nand,
uint32_t address, uint8_t
}
#endif
-int nand_write_page(struct nand_device *nand, uint32_t page, uint8_t *data,
uint32_t data_size, uint8_t *oob, uint32_t oob_size)
+int nand_write_page(struct nand_device *nand, uint32_t page, uint8_t *data,
+uint32_t data_size, uint8_t *oob, uint32_t oob_size)
{
uint32_t block;
@@ -781,66 +782,43 @@ int nand_read_page_raw(struct nand_device *nand, uint32_t
page,
return ERROR_OK;
}
-int nand_write_page_raw(struct nand_device *nand, uint32_t page, uint8_t
*data, uint32_t data_size, uint8_t *oob, uint32_t oob_size)
+int nand_write_data_page(struct nand_device *nand, uint8_t *data, uint32_t
size)
{
+ int retval = ERROR_NAND_OPERATION_FAILED;
uint32_t i;
- int retval;
- uint8_t status;
- retval = nand_page_command(nand, page, NAND_CMD_SEQIN, !data);
- if (ERROR_OK != retval)
- return retval;
+ if (nand-controller-write_block_data != NULL) {
+ retval = (nand-controller-write_block_data)(nand, data, size);
+ }
- if (data)
- {
- if (nand-controller-write_block_data != NULL)
- (nand-controller-write_block_data)(nand, data,
data_size);
- else
- {
- for (i = 0; i data_size;)
- {
- if (nand-device-options NAND_BUSWIDTH_16)
- {
- uint16_t data_buf = le_to_h_u16(data);
- nand-controller-write_data(nand,
data_buf);
- data += 2;
- i += 2;
- }
- else
- {
- nand-controller-write_data(nand,
*data);
- data += 1;
- i += 1;
- }
+ if (ERROR_NAND_NO_BUFFER == retval) {
+ bool is16bit = nand-device-options NAND_BUSWIDTH_16;
+ uint32_t incr = (is16bit) ? 2 : 1;
+ uint16_t write_data;
+ for (i = 0; i size; i += incr) {
+ if (is16bit) {
+ write_data = le_to_h_u16(data);
+ } else {
+ write_data = *data;
}
- }
- }
- if (oob)
- {
- if (nand-controller-write_block_data != NULL)
- (nand-controller-write_block_data)(nand, oob,
oob_size);
- else
- {
- for (i = 0; i oob_size;)
- {
- if (nand-device-options NAND_BUSWIDTH_16)
- {
- uint16_t oob_buf = le_to_h_u16(data);
- nand-controller-write_data(nand,
oob_buf);
- oob += 2;
- i += 2;
- }
- else
- {
- nand-controller-write_data(nand,
*oob);
- oob += 1;
- i += 1;
- }
+ retval = nand-controller-write_data(nand, write_data);
+ if (ERROR_OK != retval) {
+ break;
}
+
+ data += incr;
}
}
+ return retval;
+}
+
+int nand_write_finish(struct nand_device *nand)
+{
+ int retval;
+ uint8_t status;
+
nand-controller-command(nand, NAND_CMD_PAGEPROG);
retval = nand-controller-nand_ready ?
@@ -849,14 +827,13 @@ int nand_write_page_raw(struct nand_device *nand,
uint32_t page, uint8_t *data,
if (!retval)
return ERROR_NAND_OPERATION_TIMEOUT;
- if ((retval = nand_read_status(nand, status)) != ERROR_OK)
- {
+ retval = nand_read_status(nand, status);
+ if (ERROR_OK != retval) {
[Openocd-development] [PATCH 0/2] NAND read/write page refactoring
This series refactors some common code in the NAND core and makes them available to NAND drivers. - The first one refactors reading page data - The second refactors the commond write page data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH 0/2] AT91SAM9 NAND Driver
This patch series represents a NAND flash controller implementation for AT91SAM9 devices and perhaps Atmel NAND in general. The first patch is the driver and the necessary file updates to build it. The second patch is the driver applied to the Olimex SAM9-L9260 board. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [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 | 746
src/flash/nand/driver.c|2 +
4 files changed, 785 insertions(+), 1 deletions(-)
create mode 100644 src/flash/nand/at91sam9.c
diff --git a/doc/openocd.texi b/doc/openocd.texi
index 9d56523..c1ae0a5 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.
diff --git a/src/flash/nand/Makefile.am b/src/flash/nand/Makefile.am
index f3033b8..bb9998e 100644
--- a/src/flash/nand/Makefile.am
+++ b/src/flash/nand/Makefile.am
@@ -24,7 +24,8 @@ NAND_DRIVERS = \
s3c2410.c \
s3c2412.c \
s3c2440.c \
- s3c2443.c
+ s3c2443.c \
+ at91sam9.c
noinst_HEADERS = \
arm_io.h \
diff --git a/src/flash/nand/at91sam9.c b/src/flash/nand/at91sam9.c
new file mode 100644
index 000..966daee
--- /dev/null
+++ b/src/flash/nand/at91sam9.c
@@ -0,0 +1,746 @@
+/*
+ * Copyright (C) 2009 by Dean Glazeski
+ * dngl...@gmail.com
+ *
+ * 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.
+ */
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include target/arm.h
+#include helper/log.h
+#include imp.h
+#include arm_io.h
+
+#define AT91C_PIOx_SODR (0x30) /** Offset to PIO SODR. */
+#define AT91C_PIOx_CODR (0x34) /** Offset to PIO CODR. */
+#define AT91C_PIOx_PDSR (0x3C) /** Offset to PIO PDSR. */
+#define AT91C_ECCx_CR (0x00) /** Offset to ECC CR. */
+#define AT91C_ECCx_SR (0x08) /** Offset to ECC SR. */
+#define AT91C_ECCx_PR (0x0C) /** Offset to ECC PR. */
+#define AT91C_ECCx_NPR (0x10) /** Offset to ECC NPR. */
+
+/**
+ * Representation of a pin on an AT91SAM9 chip.
+ */
+struct at91sam9_pin {
+ /** Target this pin is on. */
+ struct target *target;
+
+ /** Address of the PIO controller. */
+ uint32_t pioc;
+
+ /** Pin number. */
+ uint32_t num;
+};
+
+/**
+ * Private
[Openocd-development] [PATCH 2/2] Olimex SAM9-L9260 board configuration update.
This updates the board configuration for the SAM9-L9260 board with the
configuration for the on-board NAND and dataflash. Included are commands
for configuring the AT91SAM9 NAND flash driver.
---
tcl/board/olimex_sam9_l9260.cfg | 94 ++-
1 files changed, 73 insertions(+), 21 deletions(-)
diff --git a/tcl/board/olimex_sam9_l9260.cfg b/tcl/board/olimex_sam9_l9260.cfg
index 5c4714e..ef7e4bc 100644
--- a/tcl/board/olimex_sam9_l9260.cfg
+++ b/tcl/board/olimex_sam9_l9260.cfg
@@ -30,41 +30,43 @@ $_TARGETNAME configure -event reset-start {
}
$_TARGETNAME configure -event reset-init {
- mww 0xfd44 0x8000 # WDT_MR : disable watchdog
+ mww 0xfd44 0x8000 ;# WDT_MR : disable watchdog
##
# Clock configuration for 99.328 MHz main clock.
##
- mww 0xfc20 0x4001 # CKGR_MOR : enable main oscillator, 512 slow
clock startup
- sleep 20 # wait 20 ms (need 15.6 ms for startup)
- mww 0xfc30 0x0001 # PMC_MCKR : switch to main oscillator
(18.432 MHz)
- sleep 10 # wait 10 ms
- mww 0xfc28 0x2060bf09 # CKGR_PLLAR : 18.432 MHz / 9 * 97 = 198.656
MHz, 63 slow clock startup
- sleep 20 # wait 20 ms (need 1.9 ms for startup)
- mww 0xfc30 0x0101 # PMC_MCKR : no scale on proc clock, master
is proc / 2
- sleep 10 # wait 10 ms
- mww 0xfc30 0x0102 # PMC_MCKR : switch to PLLA (99.328 MHz)
+puts Setting up clock
+ mww 0xfc20 0x4001 ;# CKGR_MOR : enable main oscillator, 512
slow clock startup
+ sleep 20 ;# wait 20 ms (need 15.6 ms for startup)
+ mww 0xfc30 0x0001 ;# PMC_MCKR : switch to main oscillator
(18.432 MHz)
+ sleep 10 ;# wait 10 ms
+ mww 0xfc28 0x2060bf09 ;# CKGR_PLLAR : 18.432 MHz / 9 * 97 = 198.656
MHz, 63 slow clock startup
+ sleep 20 ;# wait 20 ms (need 1.9 ms for startup)
+ mww 0xfc30 0x0101 ;# PMC_MCKR : no scale on proc clock, master
is proc / 2
+ sleep 10 ;# wait 10 ms
+ mww 0xfc30 0x0102 ;# PMC_MCKR : switch to PLLA (99.328 MHz)
# Increase JTAG speed to 6 MHz if RCLK is not supported.
jtag_rclk 6000
- arm7_9 dcc_downloads enable # Enable faster DCC downloads.
+ arm7_9 dcc_downloads enable ;# Enable faster DCC downloads.
##
# SDRAM configuration for 2 x Samsung K4S561632J-UC75, 4M x 16Bit x 4
Banks.
##
- mww 0xf870 0x # PIOC_ASR : select peripheral function for
D15..D31
- mww 0xf804 0x # PIOC_PDR : disable PIO function for D15..D31
+puts Configuring SDRAM
+ mww 0xf870 0x ;# PIOC_ASR : select peripheral function for
D15..D31
+ mww 0xf804 0x ;# PIOC_PDR : disable PIO function for
D15..D31
- mww 0xef1c 0x00010002 # EBI_CSA : assign EBI CS1 to SDRAM,
VDDIOMSEL set for +3V3 memory
+ mww 0xef1c 0x00010002 ;# EBI_CSA : assign EBI CS1 to SDRAM,
VDDIOMSEL set for +3V3 memory
- mww 0xea08 0x85237259 # SDRAMC_CR : configure SDRAM for Samsung
chips
+ mww 0xea08 0x85237259 ;# SDRAMC_CR : configure SDRAM for Samsung
chips
- mww 0xea00 0x1# SDRAMC_MR : issue NOP command
+ mww 0xea00 0x1;# SDRAMC_MR : issue NOP command
mww 0x2000 0
- mww 0xea00 0x2# SDRAMC_MR : issue an 'All Banks Precharge'
command
+ mww 0xea00 0x2;# SDRAMC_MR : issue an 'All Banks Precharge'
command
mww 0x2000 0
- mww 0xea00 0x4# SDRAMC_MR : issue 8 x 'Auto-Refresh' command
+ mww 0xea00 0x4;# SDRAMC_MR : issue 8 x 'Auto-Refresh'
command
mww 0x2000 0
mww 0xea00 0x4
mww 0x2000 0
@@ -80,10 +82,60 @@ $_TARGETNAME configure -event reset-init {
mww 0x2000 0
mww 0xea00 0x4
mww 0x2000 0
- mww 0xea00 0x3# SDRAMC_MR : issue a 'Load Mode Register'
command
+ mww 0xea00 0x3;# SDRAMC_MR : issue a 'Load Mode Register'
command
mww 0x2000 0
- mww 0xea00 0x0# SDRAMC_MR : normal mode
+ mww 0xea00 0x0;# SDRAMC_MR : normal mode
mww 0x2000 0
- mww 0xea04 0x2b6 # SDRAMC_TR : set refresh timer count to 7 us
+ mww 0xea04 0x2b6 ;# SDRAMC_TR : set refresh timer count to 7 us
+
+##
+# NAND Flash Configuration for 1 x Samsung K9F4G08U0M, 512M x 8Bit.
+##
+puts Configuring NAND flash
+mww 0xfc10 0x0010 ;# PMC_PCER : enable PIOC clock
+mww 0xf800 0x6000 ;# PIOC_PER : enable PIO function for
13(RDY/~BSY) and 14(~CS)
+mww 0xf810 0x4000 ;# PIOC_OER : enable output on 14
+
Re: [Openocd-development] [PATCH 0/2] AT91SAM9 NAND Driver
I forgot to mention, this builds on top of my NAND refactor work (read/write page data function) that I posted in a previous patch series. // Dean Glazeski On Thu, Dec 17, 2009 at 9:10 PM, Dean Glazeski dngl...@gmail.com wrote: This patch series represents a NAND flash controller implementation for AT91SAM9 devices and perhaps Atmel NAND in general. The first patch is the driver and the necessary file updates to build it. The second patch is the driver applied to the Olimex SAM9-L9260 board. ___ 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 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 ___ 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
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.netwrote:
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
From 2bb284a568f936f47e2a638e80c1554f94f5e860 Mon Sep 17 00:00:00 2001
From: Dean Glazeski dngl...@gmail.com
Date: Tue, 15 Dec 2009 23:57:18 -0600
Subject: [PATCH 1/4] Use NAND page command in erase.
Updated the NAND erase function to use the NAND page command function. This
also updates the command function to support the erase command and uses the NAND
poll function when the NAND ready function doesn't exist for the controller.
---
src/flash/nand/core.c | 50 +++-
1 files changed, 12 insertions(+), 38 deletions(-)
diff --git a/src/flash/nand/core.c b/src/flash/nand/core.c
index d52cf5d..044f4e2 100644
--- a/src/flash/nand/core.c
+++ b/src/flash/nand/core.c
@@ -537,48 +537,16 @@ int nand_erase(struct nand_device *nand, int first_block, int last_block)
for (i = first_block; i = last_block; i++)
{
/* Send erase setup command */
- nand-controller-command(nand, NAND_CMD_ERASE1);
-
page = i * (nand-erase_size / nand-page_size);
+ retval = nand_page_command(nand, page, NAND_CMD_ERASE1, false);
- /* Send page address */
- if (nand-page_size = 512)
- {
- /* row */
- nand-controller-address(nand, page 0xff);
- nand-controller-address(nand, (page 8) 0xff);
-
- /* 3rd cycle only on devices with more than 32 MiB */
- if (nand-address_cycles = 4)
-nand-controller-address(nand, (page 16) 0xff);
-
- /* 4th cycle only on devices with more than 8 GiB */
- if (nand-address_cycles = 5)
-nand-controller-address(nand, (page 24) 0xff);
- }
- else
- {
- /* row */
- nand-controller-address(nand, page 0xff);
- nand-controller-address(nand, (page 8) 0xff);
-
- /* 3rd cycle only on devices with more than 128 MiB */
- if (nand-address_cycles = 5)
-nand-controller-address(nand, (page 16) 0xff);
- }
-
- /* Send erase confirm command */
- nand-controller-command(nand, NAND_CMD_ERASE2);
-
- retval = nand-controller-nand_ready ?
-nand-controller-nand_ready(nand, 1000) :
-nand_poll_ready(nand, 1000);
- if (!retval) {
+ if (ERROR_OK != retval) {
LOG_ERROR(timeout waiting for NAND flash block erase to complete);
return ERROR_NAND_OPERATION_TIMEOUT;
}
- if ((retval = nand_read_status(nand, status)) != ERROR_OK)
+ retval = nand_read_status(nand, status);
+ if (retval != ERROR_OK)
{
LOG_ERROR(couldn't read status);
return ERROR_NAND_OPERATION_FAILED;
@@ -758,11 +726,17 @@ int nand_page_command(struct nand_device *nand, uint32_t page,
nand-controller-command(nand, NAND_CMD_READSTART);
}
+ if (NAND_CMD_ERASE1 == cmd) {
+ /* verify erase commands. */
+ nand-controller-command(nand, NAND_CMD_ERASE2);
+ }
+
if (nand-controller-nand_ready) {
- if (!nand-controller-nand_ready(nand, 100))
+ if (!nand-controller-nand_ready(nand, 1000))
return ERROR_NAND_OPERATION_TIMEOUT;
} else {
- alive_sleep(1);
+ if (!nand_poll_ready(nand, 1000))
+ return ERROR_NAND_OPERATION_TIMEOUT;
}
return ERROR_OK;
--
1.6.5.2
___
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.
On Thursday 17 December 2009, Dean Glazeski wrote:
+ if (ERROR_NAND_NO_BUFFER == retval) {
That's something OpenOCD doesn't do often enough: have
fault handling logic that's specific to the fault!
Instead of, say, throwing up its hands in the face of
any/all faults, and not even trying to recover.
Or, as in a previous iteration of this patch, just
assuming all faults are the same, and can thus be
handled identically. :)
- Dave
___
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.
On Thursday 17 December 2009, Dean Glazeski wrote:
+int nand_read_data_page(struct nand_device *nand, uint8_t *data, uint32_t
size)
+{
+ uint32_t i;
+ int retval = ERROR_NAND_OPERATION_FAILED;
+
+ if (nand-controller-read_block_data != NULL) {
+ retval = (nand-controller-read_block_data)(nand, data,
size);
+ }
+
+ if (ERROR_NAND_NO_BUFFER == retval) {
+ int incr = (nand-device-options NAND_BUSWIDTH_16) ? 2 : 1;
+ for (i = 0; i size; i += incr) {
+ nand-controller-read_data(nand, data);
+ data += incr;
+ }
+ }
+
+ return ERROR_OK;
However, returning ERROR_OK if retval != NAND_NO_BUFFER is wrong
on multiple counts.
Any problem if I just combine it with the appended fixup patch?
- Dave
--- oocd.orig/src/flash/nand/core.c 2009-12-17 21:48:27.0 -0800
+++ oocd/src/flash/nand/core.c 2009-12-17 21:47:05.0 -0800
@@ -770,22 +770,23 @@ int nand_page_command(struct nand_device
int nand_read_data_page(struct nand_device *nand, uint8_t *data, uint32_t size)
{
- uint32_t i;
- int retval = ERROR_NAND_OPERATION_FAILED;
+ int retval = ERROR_NAND_NO_BUFFER;
- if (nand-controller-read_block_data != NULL) {
+ if (nand-controller-read_block_data != NULL)
retval = (nand-controller-read_block_data)(nand, data, size);
- }
if (ERROR_NAND_NO_BUFFER == retval) {
+ uint32_t i;
int incr = (nand-device-options NAND_BUSWIDTH_16) ? 2 : 1;
- for (i = 0; i size; i += incr) {
- nand-controller-read_data(nand, data);
+
+ retval = ERROR_OK;
+ for (i = 0; retval == ERROR_OK i size; i += incr) {
+ retval = nand-controller-read_data(nand, data);
data += incr;
}
}
- return ERROR_OK;
+ return retval;
}
int nand_read_page_raw(struct nand_device *nand, uint32_t page,
___
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)
So I have the C revision of the board, which was released in June of this year. I confirmed TRST being pulled up, with no external control. The revision notes mention SWO support being added, which uses TDO and TMS. I've tried pulling the SWO_EN pin low, but that doesn't do anything, and it seems to operate fine for the windows flash utility. I'm also not able to see any activity other than the RST pin on a scope when running it. Any thoughts? On Thu, Dec 17, 2009 at 1:01 PM, Charles Vaughn cvau...@gmail.com wrote: Oh fun. I'll take a look. That hadn't occurred to me, but that would make the most sense. On Thu, Dec 17, 2009 at 12:42 PM, David Brownell davi...@pacbell.netwrote: On Thursday 17 December 2009, Charles Vaughn wrote: Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones I vaguely recall that some of the early Stellaris boards (like that one!) actually wired up TRST ... other chips don't seem to expose that signal, so it's not wired out of the JTAG adapters' CPLDs either. The all ones could indicate that the TAP is still being held in reset ... perhaps via TRST. I suggest you check your reset_config lines against board schematics, and maybe the code for that specific adapter. There are a bunch of Stellaris eval boards, with minor differences in JTAG wiring. I'm not sure which config is right for that board. I use interface/luminary.cfg on a different board and it's fine, so I'd expect once you sort out this config issue you'll have no problems. - Dave p.s. I also add reset_config srst_nogate to my board's default reset_config srst_only, but I don't recall that anything would care about that. ___ 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.
I'm fine with that. It probably is better to keep an eye on the actual read
data function as well. Feel free to make the same tweak to the NAND write
page data function as well (patch 2/2 in the series).
// Dean Glazeski
On Thu, Dec 17, 2009 at 11:51 PM, David Brownell davi...@pacbell.netwrote:
On Thursday 17 December 2009, Dean Glazeski wrote:
+int nand_read_data_page(struct nand_device *nand, uint8_t *data,
uint32_t size)
+{
+ uint32_t i;
+ int retval = ERROR_NAND_OPERATION_FAILED;
+
+ if (nand-controller-read_block_data != NULL) {
+ retval = (nand-controller-read_block_data)(nand, data,
size);
+ }
+
+ if (ERROR_NAND_NO_BUFFER == retval) {
+ int incr = (nand-device-options NAND_BUSWIDTH_16) ? 2
: 1;
+ for (i = 0; i size; i += incr) {
+ nand-controller-read_data(nand, data);
+ data += incr;
+ }
+ }
+
+ return ERROR_OK;
However, returning ERROR_OK if retval != NAND_NO_BUFFER is wrong
on multiple counts.
Any problem if I just combine it with the appended fixup patch?
- Dave
--- oocd.orig/src/flash/nand/core.c 2009-12-17 21:48:27.0 -0800
+++ oocd/src/flash/nand/core.c 2009-12-17 21:47:05.0 -0800
@@ -770,22 +770,23 @@ int nand_page_command(struct nand_device
int nand_read_data_page(struct nand_device *nand, uint8_t *data, uint32_t
size)
{
- uint32_t i;
- int retval = ERROR_NAND_OPERATION_FAILED;
+ int retval = ERROR_NAND_NO_BUFFER;
- if (nand-controller-read_block_data != NULL) {
+ if (nand-controller-read_block_data != NULL)
retval = (nand-controller-read_block_data)(nand, data,
size);
- }
if (ERROR_NAND_NO_BUFFER == retval) {
+ uint32_t i;
int incr = (nand-device-options NAND_BUSWIDTH_16) ? 2 :
1;
- for (i = 0; i size; i += incr) {
- nand-controller-read_data(nand, data);
+
+ retval = ERROR_OK;
+ for (i = 0; retval == ERROR_OK i size; i += incr) {
+ retval = nand-controller-read_data(nand, data);
data += incr;
}
}
- return ERROR_OK;
+ return retval;
}
int nand_read_page_raw(struct nand_device *nand, uint32_t page,
___
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 Thursday 17 December 2009, Charles Vaughn wrote: revision notes mention SWO support being added, which uses TDO and TMS. Your problem signal is TDO (that's giving all ones output), so this looks like the right track... Looks to me like the way they added SWO support involved adding an additional control signal, which the previous revision didn't use. And thus, the previous OpenOCD driver didn't use... so one theory is that said signal is driven wrong, disabling JTAG. In the best of worlds, they used the same signal as various other boards, so you could just switch to the other interface config (which doesn't advertise itself as being for the '811 board). ISTR those go through CPLDs ... this one seems not to do that, I mis-remembered. Less optimally you'd have to tweak src/jtag/driver/ft2232.c to understand this as yet another variant. - Dave ___ 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)
So I've done a little more scope probing, and I can see a TCK out of the FT2232, but not on the TCK pin, so that backs that up. I'll take a closer look at the schematics and try to find out what drives that. On Thu, Dec 17, 2009 at 10:35 PM, David Brownell davi...@pacbell.netwrote: On Thursday 17 December 2009, Charles Vaughn wrote: revision notes mention SWO support being added, which uses TDO and TMS. Your problem signal is TDO (that's giving all ones output), so this looks like the right track... Looks to me like the way they added SWO support involved adding an additional control signal, which the previous revision didn't use. And thus, the previous OpenOCD driver didn't use... so one theory is that said signal is driven wrong, disabling JTAG. In the best of worlds, they used the same signal as various other boards, so you could just switch to the other interface config (which doesn't advertise itself as being for the '811 board). ISTR those go through CPLDs ... this one seems not to do that, I mis-remembered. Less optimally you'd have to tweak src/jtag/driver/ft2232.c to understand this as yet another variant. - Dave ___ 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.
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
