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
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 wrote:
> On Thursday 17 December 2009,
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 addi
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 wrote:
> On Thursday 17
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
seem
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) {
> + re
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 t
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 wrote:
> Oh, I didn't see that. This patch can be ignored then. It just looks so
> sim
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 wrote:
> On Tuesday 15 December 2009, Dean Glazeski wrote:
> > I noticed the NAND erase function was doing page command stuff, so I
> pulled
>
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 pa
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 wrote:
> This patch series represents a NAND flash controller implementation for
> AT91SAM9
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
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 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 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-developme
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 +
Added a new function to encapsulate reading a page of data from a NAND device
using either the read_block_data function of a NAND controller or to use direct
reading of data from the NAND device. This also adds some performance
enhancements and uses the read_data function if the read_block_data fu
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.berl
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
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
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 ha
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 remo
Hi,
Not from a maintainer but from one following this thread with interest after
I too noticed malloc calls as unchecked function call parameters, something
that made me gasp a little being mainly an embedded programmer.
I would vote for...
> [] Check the result of malloc:
Actually, I would
On Thu, 2009-12-17 at 15:24 +, Spencer Oliver wrote:
> Ø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 re
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 n
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 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
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
#include
#include
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 g
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
> acc
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 wrote:
> On Thursday 17 December 2009, Charles Vaughn wrote:
> > Error: 409 14198 core.c:905 jtag_examine_chain_check(): JTAG scan chain
> > interrogation f
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.
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
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, th
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?
W
Ø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 c
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
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 'pi
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
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 Harbo
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 a
41 matches
Mail list logo
