Le 12/02/2011 08:57, Aaron Williams a écrit :
The CFI query is normal for a x16 device: byte address 0xAA is word
address 0x55, which is what is expected from a x16 device in x8 mode as
in x16 mode.
Can you try a 'md.b 0x1f400020 20' once in CFI QRY mode?
Amicalement,
You mean like this?
On Saturday, February 12, 2011 12:49:24 am Albert ARIBAUD wrote:
Le 12/02/2011 08:57, Aaron Williams a écrit :
The CFI query is normal for a x16 device: byte address 0xAA is word
address 0x55, which is what is expected from a x16 device in x8 mode as
in x16 mode.
Can you try a 'md.b
On Saturday, February 12, 2011 02:08:00 am Albert ARIBAUD wrote:
Le 12/02/2011 09:54, Aaron Williams a écrit :
Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
Octeon ebb6300(ram)# mw.b 0x1f40 0xf0
Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98
Octeon ebb6300(ram)# md.b 0x1f400020 20
1f400020:
I think I found the problem. The cfi code does not work properly in x8 mode.
In x8 mode, according to the datasheet, the addresses should be doubled for
all of the commands. Additionally, according to my correspondence with
Spansion, there needs to be at least a 500ns delay after a reset
Le 12/02/2011 01:15, Aaron Williams a écrit :
I think I found the problem. The cfi code does not work properly in x8 mode.
In x8 mode, according to the datasheet, the addresses should be doubled for
all of the commands. Additionally, according to my correspondence with
Spansion, there needs
On Friday, February 11, 2011 10:25:46 pm Albert ARIBAUD wrote:
Le 12/02/2011 01:15, Aaron Williams a écrit :
I think I found the problem. The cfi code does not work properly in x8
mode.
In x8 mode, according to the datasheet, the addresses should be doubled
for all of the commands.
Le 12/02/2011 07:42, Aaron Williams a écrit :
I've placed the results of the scan below.
The problem is that in 8-bit mode the code that scans the CFI does not follow
the specification.
In the specification to read the CFI data you write 0x98 to address 0xAA, not
address 0x55 as you do in
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
Le 12/02/2011 07:42, Aaron Williams a écrit :
I've placed the results of the scan below.
The problem is that in 8-bit mode the code that scans the CFI does not
follow the specification.
In the specification to read the
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
Le 12/02/2011 07:42, Aaron Williams a écrit :
I've placed the results of the scan below.
The problem is that in 8-bit mode the code that scans the CFI does not
follow the specification.
In the specification to read the
Le 12/02/2011 08:14, Aaron Williams a écrit :
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
Le 12/02/2011 07:42, Aaron Williams a écrit :
I've placed the results of the scan below.
The problem is that in 8-bit mode the code that scans the CFI does not
follow the
On Friday, February 11, 2011 11:51:24 pm Albert ARIBAUD wrote:
Le 12/02/2011 08:14, Aaron Williams a écrit :
On Friday, February 11, 2011 11:01:40 pm Albert ARIBAUD wrote:
Le 12/02/2011 07:42, Aaron Williams a écrit :
I've placed the results of the scan below.
The problem is that in
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
On Thu, Feb 10, 2011 at 00:28, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
I would suggest to make sure any caching/prefetching stuff is off,
hardware is doing one flash bus access per CPU read/write.
In
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
On Thu, Feb 10, 2011 at 00:28, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
I would suggest to make sure any caching/prefetching stuff is off,
On Thursday, February 10, 2011 07:27:12 pm Aaron Williams wrote:
On Thursday, February 10, 2011 07:24:54 pm Aaron Williams wrote:
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
On Thu, Feb 10, 2011 at 00:28, Aaron Williams
aaron.willi...@caviumnetworks.com wrote:
I
On Mon, Feb 7, 2011 at 16:58, Scott Wood scottw...@freescale.com wrote:
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
Trying again submitting the patch.
/* Do manufacturer-specific fixups */
switch (info-manufacturer_id) {
+ case
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
On Mon, Feb 7, 2011 at 16:58, Scott Wood scottw...@freescale.com wrote:
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
Trying again submitting the patch.
/* Do manufacturer-specific fixups */
On Tuesday, February 08, 2011 03:11:54 pm Aaron Williams wrote:
On Tuesday, February 08, 2011 07:38:44 am Andrew Dyer wrote:
On Mon, Feb 7, 2011 at 16:58, Scott Wood scottw...@freescale.com wrote:
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
Trying again submitting the
On Mon, Jan 31, 2011 at 06:56:48PM -0800, Aaron Williams wrote:
Trying again submitting the patch.
Adds support for NAND flash chips that are 4GiB and larger.
Signed-off-by: Aaron Williams aaron.willi...@caviumnetworks.com
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index
This patch seems to be working fine in my setup. Any comments?
-Aaron
On Thursday, January 27, 2011 05:43:10 pm Aaron Williams wrote:
I have included my preliminary patch which seems to be working.
It has not been extensively tested yet. All of the changes were basically
making the sizes
On Thu, 27 Jan 2011 17:43:10 -0800
Aaron Williams aaron.willi...@caviumnetworks.com wrote:
I have included my preliminary patch which seems to be working.
It has not been extensively tested yet. All of the changes were basically
making the sizes and offsets u64 instead of u32. When looking
Trying again submitting the patch.
Adds support for NAND flash chips that are 4GiB and larger.
Signed-off-by: Aaron Williams aaron.willi...@caviumnetworks.com
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 5481c88..26d24b0 100644
--- a/common/cmd_mtdparts.c
+++
I have included my preliminary patch which seems to be working.
It has not been extensively tested yet. All of the changes were basically
making the sizes and offsets u64 instead of u32. When looking at the Linux
kernel code it looks like they also use u64. I was mistaken and our NAND
flash chip
22 matches
Mail list logo
