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 wrote:
> On Thursday 17 December 2009, Dean Glazeski 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
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
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
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
