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
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
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
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
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
Ø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
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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 =
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
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
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
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
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
36 matches
Mail list logo
