Re: [U-Boot] [PATCH 1/1] NAND Re: mtdparts fails with NAND >= 4GB - Second try
On Thursday, February 10, 2011 07:08:01 am Andrew Dyer wrote:
On Thu, Feb 10, 2011 at 00:28, Aaron Williams
Aaron.Williams@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 cmdset_amd_read_jedec_ids() after this line:
manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
add something like
printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f400000); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f400002); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001c); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001e);
and see what you get.
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: address: 1f400000, value: 0xf0f0 fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: address: 1f401554, value: 0xaaaa fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: address: 1f400aaa, value: 0x5555 fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: address: 1f401554, value: 0x9090 flash_read8: address: 1f400001, value: 0x0 test manf id word = 1000 test device id word = 013f test device id word = da6c test device id word = 2926
looks like garbage :-( What's in the flash at those addresses? Maybe something is happening to mess up the unlock sequence and you're reading the memory data instead of the device codes.
It's odd that earlier in the sequence when the CFI query data is read the byte data is mirrored across both bytes of the response, here the two bytes are different.
I received an email back from Spansion about this problem. They suggested that instead of the following:
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following: write 0xAA to 0x1F400AAA write 0x55 to 0x1F400555 write 0x90 to 0x1F400AAA
read 0x1F400001 returns 0x01 read 0x1F400003 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in flash_write_cmd I use info->chipwidth instead of info->portwidth for the write commands, and second, in __flash_detect_cfi I don't modify the address in compatibility mode. This works. If either of those steps are left out then reading the manufacturer ID fails.
-Aaron
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.Williams@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 cmdset_amd_read_jedec_ids() after this line:
manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
add something like
printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f400000); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f400002); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001c); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001e);
and see what you get.
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: address: 1f400000, value: 0xf0f0 fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: address: 1f401554, value: 0xaaaa fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: address: 1f400aaa, value: 0x5555 fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: address: 1f401554, value: 0x9090 flash_read8: address: 1f400001, value: 0x0 test manf id word = 1000 test device id word = 013f test device id word = da6c test device id word = 2926
looks like garbage :-( What's in the flash at those addresses? Maybe something is happening to mess up the unlock sequence and you're reading the memory data instead of the device codes.
It's odd that earlier in the sequence when the CFI query data is read the byte data is mirrored across both bytes of the response, here the two bytes are different.
I received an email back from Spansion about this problem. They suggested that instead of the following:
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following: write 0xAA to 0x1F400AAA write 0x55 to 0x1F400555 write 0x90 to 0x1F400AAA
read 0x1F400001 returns 0x01 read 0x1F400003 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in flash_write_cmd I use info->chipwidth instead of info->portwidth for the write commands, and second, in __flash_detect_cfi I don't modify the address in compatibility mode. This works. If either of those steps are left out then reading the manufacturer ID fails.
-Aaron
It looks like I spoke too soon. It fixes the manufacturer problem but everything else is now broken.
-Aaron
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.Williams@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 cmdset_amd_read_jedec_ids() after this line:
manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
add something like
printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f400000); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f400002); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001c); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001e);
and see what you get.
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: address: 1f400000, value: 0xf0f0 fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: address: 1f401554, value: 0xaaaa fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: address: 1f400aaa, value: 0x5555 fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: address: 1f401554, value: 0x9090 flash_read8: address: 1f400001, value: 0x0 test manf id word = 1000 test device id word = 013f test device id word = da6c test device id word = 2926
looks like garbage :-( What's in the flash at those addresses? Maybe something is happening to mess up the unlock sequence and you're reading the memory data instead of the device codes.
It's odd that earlier in the sequence when the CFI query data is read the byte data is mirrored across both bytes of the response, here the two bytes are different.
I received an email back from Spansion about this problem. They suggested that instead of the following:
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following: write 0xAA to 0x1F400AAA write 0x55 to 0x1F400555 write 0x90 to 0x1F400AAA
read 0x1F400001 returns 0x01 read 0x1F400003 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in flash_write_cmd I use info->chipwidth instead of info->portwidth for the write commands, and second, in __flash_detect_cfi I don't modify the address in compatibility mode. This works. If either of those steps are left out then reading the manufacturer ID fails.
-Aaron
It looks like I spoke too soon. It fixes the manufacturer problem but everything else is now broken.
-Aaron
It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some reason.
static void cmdset_amd_read_jedec_ids(flash_info_t *info) { ushort bankId = 0; uchar manuId;
debug("In %s\n", __func__); flash_write_cmd(info, 0, 0, AMD_CMD_RESET); flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START); flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK); flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID); /*flash_unlock_seq(info, 0); */ /*flash_write_cmd(info, 0, info->addr_unlock1, FLASH_CMD_READ_ID);*/
With this, everything works with my mod to flash_write_cmd to use chipwidth instead of portwidth.
-Aaron
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 command.
The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when it is actually 8-bits. Currently things just happen to work because the bus is being incorrectly detected as 16-bits,
The 16-bit bus detection, however, breaks in x8 mode when it issues the commands for the manufacturer ID.
In this case, the following takes place:
In cmdset_amd_read_jedec_ids fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 funlock writing 0xaa to address 0xaaa fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 flash_read8: Read 0x0 from address 1f400001 flash_read8: Read 0x3f from address 1f400003
This does not work.
If the proper sequence is written, then it works fine.
The proper sequence, according to the datasheet, is to do the following:
write 0xf0 to address 0x0000 write 0xaa to address 0xaaa write 0x55 to address 0x555 write 0x90 to address 0xaaa read address 0 (returns 1 as expected) read address 2 (returns 0x7e as expected) ...
So the cfi code is broken in the x8 case.
-Aaron Williams
On Thursday, February 10, 2011 08:05:37 pm Aaron Williams wrote:
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.Williams@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 cmdset_amd_read_jedec_ids() after this line:
manuId = flash_read_uchar (info, FLASH_OFFSET_MANUFACTURER_ID);
add something like
printf("test manf id word = %04x\n", *(volatile uint16_t *)0x1f400000); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f400002); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001c); printf("test device id word = %04x\n", *(volatile uint16_t *)0x1f40001e);
and see what you get.
fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: address: 1f400000, value: 0xf0f0 fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: address: 1f401554, value: 0xaaaa fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: address: 1f400aaa, value: 0x5555 fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: address: 1f401554, value: 0x9090 flash_read8: address: 1f400001, value: 0x0 test manf id word = 1000 test device id word = 013f test device id word = da6c test device id word = 2926
looks like garbage :-( What's in the flash at those addresses? Maybe something is happening to mess up the unlock sequence and you're reading the memory data instead of the device codes.
It's odd that earlier in the sequence when the CFI query data is read the byte data is mirrored across both bytes of the response, here the two bytes are different.
I received an email back from Spansion about this problem. They suggested that instead of the following:
fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554
to instead do the following: write 0xAA to 0x1F400AAA write 0x55 to 0x1F400555 write 0x90 to 0x1F400AAA
read 0x1F400001 returns 0x01 read 0x1F400003 returns 0x7e
This looks correct.
I found two things I need to do to work around the problem. First, in flash_write_cmd I use info->chipwidth instead of info->portwidth for the write commands, and second, in __flash_detect_cfi I don't modify the address in compatibility mode. This works. If either of those steps are left out then reading the manufacturer ID fails.
-Aaron
It looks like I spoke too soon. It fixes the manufacturer problem but everything else is now broken.
-Aaron
It works now, but I had to hard-code cmdset_amd_read_jedec_ids for some reason.
static void cmdset_amd_read_jedec_ids(flash_info_t *info) { ushort bankId = 0; uchar manuId;
debug("In %s\n", __func__); flash_write_cmd(info, 0, 0, AMD_CMD_RESET); flash_write_cmd(info, 0, 0x555, AMD_CMD_UNLOCK_START); flash_write_cmd(info, 0, 0x2AA, AMD_CMD_UNLOCK_ACK); flash_write_cmd(info, 0, 0x555, FLASH_CMD_READ_ID); /*flash_unlock_seq(info, 0); */ /*flash_write_cmd(info, 0, info->addr_unlock1, FLASH_CMD_READ_ID);*/
With this, everything works with my mod to flash_write_cmd to use chipwidth instead of portwidth.
-Aaron _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 to be at least a 500ns delay after a reset command.
The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when it is actually 8-bits. Currently things just happen to work because the bus is being incorrectly detected as 16-bits,
The 16-bit bus detection, however, breaks in x8 mode when it issues the commands for the manufacturer ID.
In this case, the following takes place:
In cmdset_amd_read_jedec_ids fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 funlock writing 0xaa to address 0xaaa fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 flash_read8: Read 0x0 from address 1f400001 flash_read8: Read 0x3f from address 1f400003
This does not work.
If the proper sequence is written, then it works fine.
The proper sequence, according to the datasheet, is to do the following:
write 0xf0 to address 0x0000 write 0xaa to address 0xaaa write 0x55 to address 0x555 write 0x90 to address 0xaaa read address 0 (returns 1 as expected) read address 2 (returns 0x7e as expected) ...
So the cfi code is broken in the x8 case.
Hmm... It would be surprising that the x8 CFI code be broken -- not impossible, mind you -- because it was intensively used with a variety of chips, and thus extensively checked for brokenness.
What *might* be at stake is the result of the width detection, because many reputedly CFI compliant Flash devices are actually not compliant, especially among the dual-width, x8/x16, ones. On my ED Mini V2, there is a Macronix x8/x16 part which presents its CFI QRY response as a pure x16 even though it is a x8/x16, thus tricking the width detection mechanism into taking the wrong decision; I had to resort to using the LEGACY feature of manually defining the widths.
Did you check the Flash part against the CFI specs, including the QRY location and layout?
Can you boot into a RAM-baed u-boot and use its memory write and read commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device?
Amicalement,
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. Additionally, according to my correspondence with Spansion, there needs to be at least a 500ns delay after a reset command.
The cfi code is incorrectly detecting the port width as FLASH_CFI_16BIT when it is actually 8-bits. Currently things just happen to work because the bus is being incorrectly detected as 16-bits,
The 16-bit bus detection, however, breaks in x8 mode when it issues the commands for the manufacturer ID.
In this case, the following takes place:
In cmdset_amd_read_jedec_ids fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 funlock writing 0xaa to address 0xaaa fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 flash_read8: Read 0x0 from address 1f400001 flash_read8: Read 0x3f from address 1f400003
This does not work.
If the proper sequence is written, then it works fine.
The proper sequence, according to the datasheet, is to do the following:
write 0xf0 to address 0x0000 write 0xaa to address 0xaaa write 0x55 to address 0x555 write 0x90 to address 0xaaa read address 0 (returns 1 as expected) read address 2 (returns 0x7e as expected) ...
So the cfi code is broken in the x8 case.
Hmm... It would be surprising that the x8 CFI code be broken -- not impossible, mind you -- because it was intensively used with a variety of chips, and thus extensively checked for brokenness.
What *might* be at stake is the result of the width detection, because many reputedly CFI compliant Flash devices are actually not compliant, especially among the dual-width, x8/x16, ones. On my ED Mini V2, there is a Macronix x8/x16 part which presents its CFI QRY response as a pure x16 even though it is a x8/x16, thus tricking the width detection mechanism into taking the wrong decision; I had to resort to using the LEGACY feature of manually defining the widths.
Did you check the Flash part against the CFI specs, including the QRY location and layout?
Can you boot into a RAM-baed u-boot and use its memory write and read commands (m[wd].[lwb]) to test the main CFI sequences of your Flash device?
Amicalement,
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 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
-Aaron
Here's the results of the scan:
flash detect cfi fwc addr 1f400000 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f400000 fwc addr 1f400055 cmd 98 98 8bit x 8 bit flash_write8: Wrote 0x98 to address 1f400055 is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010 is= 0 51 flash_read8: Read 0x0 from address 1f400010 fwc addr 1f400000 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f400000 fwc addr 1f400555 cmd 98 98 8bit x 8 bit flash_write8: Wrote 0x98 to address 1f400555 is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010 is= 0 51 flash_read8: Read 0x0 from address 1f400010 fwc addr 1f400000 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f400000 fwc addr 1f400000 cmd 98 98 8bit x 8 bit flash_write8: Wrote 0x98 to address 1f400000 is= cmd 51(Q) addr 1f400010 flash_read8: Read 0x0 from address 1f400010 is= 0 51 flash_read8: Read 0x0 from address 1f400010 fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit flash_write16: Wrote 0x9898 to address 1f4000aa is= cmd 51(Q) addr 1f400020 flash_read16: Read 0x5151 from address 1f400020 is= 5151 5151 flash_read16: Read 0x5151 from address 1f400020 is= cmd 52(R) addr 1f400022 flash_read16: Read 0x5252 from address 1f400022 is= 5252 5252 flash_read16: Read 0x5252 from address 1f400022 is= cmd 59(Y) addr 1f400024 flash_read16: Read 0x5959 from address 1f400024 is= 5959 5959 flash_read16: Read 0x5959 from address 1f400024 flash_read8: Read 0x51 from address 1f400021 flash_read8: Read 0x52 from address 1f400023 flash_read8: Read 0x59 from address 1f400025 flash_read8: Read 0x2 from address 1f400027 flash_read8: Read 0x0 from address 1f400029 flash_read8: Read 0x40 from address 1f40002b flash_read8: Read 0x0 from address 1f40002d flash_read8: Read 0x0 from address 1f40002f flash_read8: Read 0x0 from address 1f400031 flash_read8: Read 0x0 from address 1f400033 flash_read8: Read 0x0 from address 1f400035 flash_read8: Read 0x27 from address 1f400037 flash_read8: Read 0x36 from address 1f400039 flash_read8: Read 0x0 from address 1f40003b flash_read8: Read 0x0 from address 1f40003d flash_read8: Read 0x7 from address 1f40003f flash_read8: Read 0x7 from address 1f400041 flash_read8: Read 0xa from address 1f400043 flash_read8: Read 0x0 from address 1f400045 flash_read8: Read 0x3 from address 1f400047 flash_read8: Read 0x5 from address 1f400049 flash_read8: Read 0x4 from address 1f40004b flash_read8: Read 0x0 from address 1f40004d flash_read8: Read 0x17 from address 1f40004f flash_read8: Read 0x2 from address 1f400051 flash_read8: Read 0x0 from address 1f400053 flash_read8: Read 0x5 from address 1f400055 flash_read8: Read 0x0 from address 1f400057 flash_read8: Read 0x2 from address 1f400059 flash_read8: Read 0x7 from address 1f40005b flash_read8: Read 0x0 from address 1f40005d flash_read8: Read 0x20 from address 1f40005f flash_read8: Read 0x0 from address 1f400061 flash_read8: Read 0x7e from address 1f400063 flash_read8: Read 0x0 from address 1f400065 flash_read8: Read 0x0 from address 1f400067 flash_read8: Read 0x1 from address 1f400069 flash_read8: Read 0x0 from address 1f40006b flash_read8: Read 0x0 from address 1f40006d flash_read8: Read 0x0 from address 1f40006f flash_read8: Read 0x0 from address 1f400071 flash_read8: Read 0x0 from address 1f400073 flash_read8: Read 0x0 from address 1f400075 flash_read8: Read 0x0 from address 1f400077 flash_read8: Read 0x0 from address 1f400079 device interface is 2 found port 2 chip 1 port 16 bits chip 8 bits __flash_detect_cfi: unlock addresses 0xaaa, 0x555, interface 2 flash_read8: Read 0x31 from address 1f400087 flash_read8: Read 0x33 from address 1f400089 00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07 QRY..@.....'6... 10 : 07 0a 00 03 05 04 00 17 02 00 05 00 02 07 00 20 ............... 20 : 00 7e 00 00 01 00 00 00 00 00 00 00 00 06 d6 98 .~.............. In cmdset_amd_read_jedec_ids fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 funlock writing 0xaa to address 0xaaa fwc addr 1f401554 cmd aa aaaa 16bit x 8 bit flash_write16: Wrote 0xaaaa to address 1f401554 funlock writing 0xaa to address 0x555 fwc addr 1f400aaa cmd 55 5555 16bit x 8 bit flash_write16: Wrote 0x5555 to address 1f400aaa fwc addr 1f401554 cmd 90 9090 16bit x 8 bit flash_write16: Wrote 0x9090 to address 1f401554 flash_read8: Read 0x0 from address 1f400001 flash_read8: Read 0x3f from address 1f400003 fwc addr 1f400000 cmd f0 f0f0 16bit x 8 bit flash_write16: Wrote 0xf0f0 to address 1f400000 fwc addr 1f4000aa cmd 98 9898 16bit x 8 bit flash_write16: Wrote 0x9898 to address 1f4000aa flash_read8: Read 0x3 from address 1f40009f manufacturer is 2 manufacturer id is 0x0 device id is 0x3f device id2 is 0x0 cfi version is 0x3133 size_ratio 1 port 16 bits chip 8 bits found 2 erase regions erase region 0: 0x0100007e erase_region_count = 127 erase_region_size = 65536 erase region 1: 0x00200007 erase_region_count = 8 erase_region_size = 8192 fwc addr 1f400000 cmd f0 f0 8bit x 8 bit flash_write8: Wrote 0xf0 to address 1f400000 fwc addr 1fbfe000 cmd 70 70 8bit x 8 bit flash_write8: Wrote 0x70 to address 1fbfe000 flash_read8: Read 0x6f from address 1fbfe000 flash_read8: Read 0x6f from address 1fbfe000 flash_is_busy: 0 Flash: 8 MiB
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 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”.
I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode.
Are we in sync here?
Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours.
-Aaron
Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved.
Amicalement,
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 CFI data you write 0x98 to address 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”.
I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode.
Are we in sync here?
Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours.
-Aaron
Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved.
Amicalement,
I'm looking at the Spansion S29GL-N datasheet from 2008. Look at table 10.3 on page 53.
http://www.spansion.com/Support/Datasheets/S29GL-N_01_12_e.pdf
-Aaron
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 CFI data you write 0x98 to address 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”.
I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode.
Are we in sync here?
This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode according to the data sheet.
Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours.
-Aaron
Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved.
Amicalement,
When I use the addresses and data shown in the datasheet, everything responds as it should using mw.b and md.b.
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 .
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
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 specification.
In the specification to read the CFI data you write 0x98 to address 0xAA, not address 0x55 as you do in 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”.
I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode.
Are we in sync here?
This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode according to the data sheet.
Yes, but the 0xAA address is a byte address and the 0x55 address is a word address, translating to byte address 0xAA as well.
On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte location for a pure x8 device is 0x55, and 0xAA for a x16 device, both in x16 or x8 mode (the difference is that byte mode will expect a byte write of 0x98 where x16 mode will expect a word write of 0x0098).
This is in sync with my Macronix MX29LV400CB/CT spec.
Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours.
-Aaron
Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved.
Amicalement,
When I use the addresses and data shown in the datasheet, everything responds as it should using mw.b and md.b.
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 .
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
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,
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 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 16-bit mode. flash_offset_cfi is set to 0x55 which in this case is wrong and won't work. When it tries 16-bit mode then it writes to address 0xAA which causes it to work.
Let us see the specs, then. The specs I have (admittedly not necessarily the latest: I use JESD 68.01, september 1999) state the following:
"Nonvolatile memory devices are assumed to power up in a read-only state. Independent of that assumption, the Query structure contents must be able to be read at the specific address locations following a single system write cycle where: 1) a 98h Query command code is written to 55h address location within the device’s address space (in maximum device buswidth), and 2) the device is in any valid read state, such as “Read Array” or “Read ID Data”.
I read "55h address location within the device’s address space (in maximum device buswidth" as implying that 0x55 is the only address to use but is in device bus terms, and that may mean different CPU addresses for different devices types: for x8 devices, one should access the byte address 0x55 because the device bus is in bytes, whereas for x8/x16 and x16 devices, one should access byte address 0xAA because it translates to x16 device bus address 0x55 -- regardless of actual x8 or x16 mode.
Are we in sync here?
This is wrong. The address is actually 0xAA in x8 mode and 0x55 in x16 mode according to the data sheet.
Yes, but the 0xAA address is a byte address and the 0x55 address is a word address, translating to byte address 0xAA as well.
On the JESD 68.01 spec, page number 3 (that's PDF page 9), the byte location for a pure x8 device is 0x55, and 0xAA for a x16 device, both in x16 or x8 mode (the difference is that byte mode will expect a byte write of 0x98 where x16 mode will expect a word write of 0x0098).
This is in sync with my Macronix MX29LV400CB/CT spec.
Now it's been a long time since I last looked at my ED Mini V2 Flash, but I should be able to dig it up and do a test within one or two hours.
-Aaron
Here's the results of the scan:
Yes, that's what U-boot *CFI code* does, but I'd like to see what very basic writes and reads give without any detection logic involved.
Amicalement,
When I use the addresses and data shown in the datasheet, everything responds as it should using mw.b and md.b.
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 .
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
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?
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 0 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 . Octeon ebb6300(ram)# md.b 0x1f400005 1 1f400005: 00 . Octeon ebb6300(ram)# md.b 0x1f400006 1 1f400006: 1a . Octeon ebb6300(ram)# md.b 0x1f400008 1 1f400008: 00 . Octeon ebb6300(ram)# md.b 0x1f40000a 1 1f40000a: 00 . Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
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?
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 0 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 . Octeon ebb6300(ram)# md.b 0x1f400005 1 1f400005: 00 . Octeon ebb6300(ram)# md.b 0x1f400006 1 1f400006: 1a . Octeon ebb6300(ram)# md.b 0x1f400008 1 1f400008: 00 . Octeon ebb6300(ram)# md.b 0x1f40000a 1 1f40000a: 00 . Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20' once in CFI QRY mode, that is:
mw.b 0x1f400000 0xf0 mw.b 0x1f4000AA 0x98 md.b 0x1f400020 20
Amicalement,
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 0x1f400020 20' once in CFI QRY mode?
Amicalement,
You mean like this?
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0xaa Octeon ebb6300(ram)# mw.b 0x1f400555 0x55 Octeon ebb6300(ram)# mw.b 0x1f400aaa 0x90 Octeon ebb6300(ram)# md.b 0x1f400000 0 Octeon ebb6300(ram)# md.b 0x1f400000 1 1f400000: 01 . Octeon ebb6300(ram)# md.b 0x1f400002 1 1f400002: 7e ~ Octeon ebb6300(ram)# md.b 0x1f400004 1 1f400004: 00 . Octeon ebb6300(ram)# md.b 0x1f400005 1 1f400005: 00 . Octeon ebb6300(ram)# md.b 0x1f400006 1 1f400006: 1a . Octeon ebb6300(ram)# md.b 0x1f400008 1 1f400008: 00 . Octeon ebb6300(ram)# md.b 0x1f40000a 1 1f40000a: 00 . Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 1f400020: 51 Q Octeon ebb6300(ram)# md.b 0x1f400022 1f400022: 52 R Octeon ebb6300(ram)# md.b 0x1f400024 1f400024: 59 Y Octeon ebb6300(ram)# md.b 0x1f400026 1f400026: 02 . Octeon ebb6300(ram)# md.b 0x1f400028 1f400028: 00 .
-Aaron
No, I meant the instruction exactly as I quoted it: 'md.b 0x1f400020 20' once in CFI QRY mode, that is:
mw.b 0x1f400000 0xf0 mw.b 0x1f4000AA 0x98 md.b 0x1f400020 20
Amicalement,
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 20 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@.... 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07 ......''66......
-Aaron
Le 12/02/2011 09:54, Aaron Williams a écrit :
Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 20 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@.... 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07 ......''66......
This, according to the CFI spec, gives us the proof that the Spansion chip is a x16 device in x8 mode.
Can you now please, based on the knowledge that the device is x16 in x8 mode, go through the CFI detection sequence agin and determine which line exactly fails to work as expected?
-Aaron
Amicalement,
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 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f400000 0xf0 Octeon ebb6300(ram)# mw.b 0x1f4000AA 0x98 Octeon ebb6300(ram)# md.b 0x1f400020 20 1f400020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@.... 1f400030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 07 07 ......''66......
This, according to the CFI spec, gives us the proof that the Spansion chip is a x16 device in x8 mode.
Can you now please, based on the knowledge that the device is x16 in x8 mode, go through the CFI detection sequence agin and determine which line exactly fails to work as expected?
-Aaron
Amicalement,
I'll take a look at this next week. The problem with the current code is that it detects the chip width of 8 but a port width of 16 which results in 16-bit writes. This fails for obtaining the manufacturer ID.
-Aaron
participants (2)
-
Aaron Williams -
Albert ARIBAUD