Non standard CFI detection tweaks

U-Boot Rogan Dawes 5 participants 22 messages Jul 13, 2010 – Aug 12, 2010

lore

Share & tools

lore

Rogan Dawes

author

2010-07-13 20:00 UTC #0 lore raw

Hi Stefan,

I'm trying to add support for my D-Link DNS323 (Orion5x-based) to U-Boot, building on the efforts of Albert Aribaud.

One place where I am struggling is with the detection of the flash chip.

The flash part is a 8 MB Spansion S29GL064M90TFIR4, and the data sheet can be found at:

http://www.spansion.com/Support/Datasheets/s29gl-m_00_b8_e.pdf

It says:

Quoted 3 lines

This device enters the CFI Query mode when the system writes the CFI Query command, 98h, to address 55h, any time the device is ready to read array data.

Testing this from the command line, however, shows that this is in fact NOT true. In fact, the write needs to occur at aah, not 55h.

This may be influenced by the following paragraph from the manual:

Quoted 4 lines

Depending on the model number, the devices have an 8-bit wide data bus only, 16-bit wide data bus only, or a 16-bit wide data bus that can also function as an 8-bit wide data bus by using the BYTE# input.

And:

Quoted 1 line

R4 = x8/x16

Looking at the debug logs from cfi_flash.c, I see the following output:

fwc addr ff8000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr ff800020 is= ffff 5151

These lines are the closest to doing what appears to be needed for this part, in that the address being written to is correct, the address being read from is correct, the expected result is correct. The only thing that is not correct is the command to enter QRY mode.

For this particular chip, the command is:

mw.w 0xff8000aa 9800 (rather than 9898)

(FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode)

Having done that, the QRY results are present at 0xff800020:

md.b ff800020 20
ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@....
ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 ......''66......

Do you have any suggestions on the best way to modify cfi_flash.c to detect this chip?

Regards,

Rogan Dawes

Stefan Roese

2010-07-19 09:34 UTC #1 lore raw

Hi Rogan,

Quoted 10 lines · On Tuesday 13 July 2010 22:00:37 Rogan Dawes wrote:

I'm trying to add support for my D-Link DNS323 (Orion5x-based) to U-Boot, building on the efforts of Albert Aribaud.
One place where I am struggling is with the detection of the flash chip.
The flash part is a 8 MB Spansion S29GL064M90TFIR4, and the data sheet can be found at:
http://www.spansion.com/Support/Datasheets/s29gl-m_00_b8_e.pdf

Quoted 7 lines

It says:
Quoted 3 lines
This device enters the CFI Query mode when the system writes the CFI Query command, 98h, to address 55h, any time the device is ready to read array data.
Testing this from the command line, however, shows that this is in fact NOT true. In fact, the write needs to occur at aah, not 55h.

This is most likely because of the 8bit width (byte address) vs. 16bit width (word address) modes.

How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)?

Quoted 19 lines

This may be influenced by the following paragraph from the manual:
Quoted 4 lines
Depending on the model number, the devices have an 8-bit wide data bus only, 16-bit wide data bus only, or a 16-bit wide data bus that can also function as an 8-bit wide data bus by using the BYTE# input.
And:
Quoted 1 line
R4 = x8/x16
Looking at the debug logs from cfi_flash.c, I see the following output:
fwc addr ff8000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr ff800020 is= ffff 5151
These lines are the closest to doing what appears to be needed for this part, in that the address being written to is correct, the address being read from is correct, the expected result is correct. The only thing that is not correct is the command to enter QRY mode.

Quoted 5 lines

For this particular chip, the command is:
mw.w 0xff8000aa 9800 (rather than 9898)
(FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode)

Hmmm. Again my question: Are you using byte- or word-mode?

Quoted 8 lines

Having done that, the QRY results are present at 0xff800020:
md.b ff800020 20
ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00 QQRRYY....@@....
ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04 ......''66......
Do you have any suggestions on the best way to modify cfi_flash.c to detect this chip?

Not right now, sorry.

Cheers,
Stefan

--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

Rogan Dawes

author

2010-07-19 10:18 UTC #2 lore raw

Quoted 1 line · Stefan Roese

Hi Rogan,

Hi Stefan,

Thanks for responding.

Quoted 16 lines · On Tuesday 13 July 2010 22:00:37 Rogan Dawes wrote:

Quoted 15 lines
I'm trying to add support for my D-Link DNS323 (Orion5x-based) to U-Boot, building on the efforts of Albert Aribaud.
One place where I am struggling is with the detection of the flash chip.
The flash part is a 8 MB Spansion S29GL064M90TFIR4, and the data sheet can be found at:
http://www.spansion.com/Support/Datasheets/s29gl-m_00_b8_e.pdf
It says:
Quoted 3 lines
This device enters the CFI Query mode when the system writes the CFI Query command, 98h, to address 55h, any time the device is ready to read array data.

Quoted 8 lines

Quoted 2 lines
Testing this from the command line, however, shows that this is in fact NOT true. In fact, the write needs to occur at aah, not 55h.
This is most likely because of the 8bit width (byte address) vs. 16bit width (word address) modes.
How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)?

I have no idea. Do you have any suggestions how I can find out?

If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot "partition", and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all?

[snip]

Quoted 7 lines

Quoted 2 lines
Do you have any suggestions on the best way to modify cfi_flash.c to detect this chip?
Not right now, sorry.
Cheers,
Stefan

Any hints on how to get more information to assist in debugging this? The CPU is an Orion5x (ARM) part, if that makes any difference.

Rogan

Stefan Roese

2010-07-19 10:49 UTC #3 lore raw

Hi Rogan,

Quoted 4 lines · On Monday 19 July 2010 12:18:45 Rogan Dawes wrote:

Quoted 2 lines
How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)?
I have no idea. Do you have any suggestions how I can find out?

I don't suppose you have the schematics for this board?

Quoted 4 lines

If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot "partition", and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all?

No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)?

Byte addresses:

=> mw.b base + aaa aa
=> mw.b base + 555 55
=> mw.b base + aaa 90
=> md.b base

Word addresses:

=> mw.w base + 555 00aa
=> mw.w base + 2aa 0055
=> mw.w base + 555 0090
=> md.w base

What's the output of those commands?

Cheers,
Stefan

Rogan Dawes

author

2010-07-19 11:05 UTC #4 lore raw

Quoted 9 lines · Stefan Roese

Hi Rogan,
Quoted 4 lines · On Monday 19 July 2010 12:18:45 Rogan Dawes wrote:
Quoted 2 lines
How is your FLASH chip connected to your CPU? In 16bit wide mode (which is more common)?
I have no idea. Do you have any suggestions how I can find out?
I don't suppose you have the schematics for this board?

No, I'm afraid not.

Quoted 9 lines

Quoted 4 lines
If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot "partition", and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all?
No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)?

Quoted 6 lines

Byte addresses:

=>  mw.b base + aaa aa
=>  mw.b base + 555 55
=>  mw.b base + aaa 90
=>  md.b base

DNS323B1> mw.b 0xff800aaa aa
DNS323B1> mw.b 0xff800555 55
DNS323B1> mw.b 0xff800aaa 90
DNS323B1> md.b 0xff800000
ff800000: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
................
ff800010: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
................
ff800020: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
................
ff800030: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
................
DNS323B1> mw.b ff800000 f0
DNS323B1> mw.b ff800000 ff
DNS323B1> md.b 0xff800000
ff800000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
ff800010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
ff800020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................
ff800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
................

Quoted 6 lines

Word addresses:

=>  mw.w base + 555 00aa
=>  mw.w base + 2aa 0055
=>  mw.w base + 555 0090
=>  md.w base

This is quite odd, though.

DNS323B1> mw.w 0xff800555 00aa

... never returns. It seems to hang up the board for some reason.

Quoted 4 lines

What's the output of those commands?
Cheers,
Stefan

Thanks for your help!

Stefan Roese

2010-07-19 11:50 UTC #5 lore raw

Quoted 16 lines · On Monday 19 July 2010 13:05:09 Rogan Dawes wrote:

Quoted 9 lines
Quoted 4 lines
If I do a normal md over the rest of the flash, I do see expected strings from the U-Boot "partition", and the kernel and ramdisk partitions. i.e. not duplicated or anything like that. Not sure if that answers your question at all?
No, it doesn't. But the unlocking addresses should give us the result (8bit vs. 16bit wide connection). What does work for you? The byte addresses or the word addresses (read manufacturer ID)?
Quoted 6 lines
Byte addresses:
=>  mw.b base + aaa aa
=>  mw.b base + 555 55
=>  mw.b base + aaa 90
=>  md.b base

Quoted 12 lines

DNS323B1> mw.b 0xff800aaa aa
DNS323B1> mw.b 0xff800555 55
DNS323B1> mw.b 0xff800aaa 90
DNS323B1> md.b 0xff800000
ff800000: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
...............
ff800010: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
...............
ff800020: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
...............
ff800030: 7f 7f cb cb 00 00 08 08 7f 7f cb cb 00 00 08 08
...............

This doesn't seem to be the manufacturer/device ID. Not sure what it really is.

Quoted 19 lines

DNS323B1> mw.b ff800000 f0
DNS323B1> mw.b ff800000 ff
DNS323B1> md.b 0xff800000
ff800000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...............
ff800010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...............
ff800020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...............
ff800030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...............
Quoted 6 lines
Word addresses:
=>  mw.w base + 555 00aa
=>  mw.w base + 2aa 0055
=>  mw.w base + 555 0090
=>  md.w base

Quoted 5 lines

This is quite odd, though.
DNS323B1> mw.w 0xff800555 00aa
.. never returns. It seems to hang up the board for some reason.

Ahh, unaligned 16bit access on ARM.

Please give these commands another try:

=>  mw.w ff800aaa 00aa
=>  mw.w ff800554 0055
=>  mw.w ff800aaa 0090
=>  md.w ff800000

Cheers,
Stefan

Rogan Dawes

author

2010-07-19 12:18 UTC #6 lore raw

Quoted 10 lines · Stefan Roese

Quoted 5 lines
This is quite odd, though.
DNS323B1> mw.w 0xff800555 00aa
.. never returns. It seems to hang up the board for some reason.
Ahh, unaligned 16bit access on ARM.
Please give these commands another try:

Quoted 8 lines

=>   mw.w ff800aaa 00aa
=>   mw.w ff800554 0055
=>   mw.w ff800aaa 0090
=>   md.w ff800000

Cheers,
Stefan

DNS323B1> mw.w ff800aaa 00aa
DNS323B1> mw.w ff800554 0055
DNS323B1> mw.w ff800aaa 0090
DNS323B1> md.w ff800000
ff800000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800070: 0000 0000 0000 0000 0000 0000 0000 0000 ................

I also tried various permutations of mw.w ff8000aa 00aa, etc, as well as mw.w 0xff800554 5500 (rather than 0055), since we are writing to a different address, and none of them gave anything other than 0000 results.

This is the procedure for entering QRY mode, though, from my original email:

Quoted 10 lines

For this particular chip, the command is:
mw.w 0xff8000aa 9800 (rather than 9898)
(FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode)
Having done that, the QRY results are present at 0xff800020:
md.b ff800020 20
ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00

QQRRYY....@@....

Quoted 1 line

ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04

......''66......

Does that help?

Rogan

Stefan Roese

2010-07-19 13:33 UTC #7 lore raw

Quoted 13 lines · On Monday 19 July 2010 14:18:37 Rogan Dawes wrote:

DNS323B1> mw.w ff800aaa 00aa
DNS323B1> mw.w ff800554 0055
DNS323B1> mw.w ff800aaa 0090
DNS323B1> md.w ff800000
ff800000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
ff800070: 0000 0000 0000 0000 0000 0000 0000 0000 ................

Quoted 3 lines

I also tried various permutations of mw.w ff8000aa 00aa, etc, as well as mw.w 0xff800554 5500 (rather than 0055), since we are writing to a different address, and none of them gave anything other than 0000 results.

Too bad. :-(

Quoted 12 lines

This is the procedure for entering QRY mode, though, from my original email:
Quoted 10 lines
For this particular chip, the command is:
mw.w 0xff8000aa 9800 (rather than 9898)
(FWIW mw.b 0xff8000aa 98 also works fine to enter QRY mode)
Having done that, the QRY results are present at 0xff800020:
md.b ff800020 20
ff800020: 51 51 52 52 59 59 02 02 00 00 40 40 00 00 00 00

Quoted 7 lines

QQRRYY....@@....
Quoted 1 line
ff800030: 00 00 00 00 00 00 27 27 36 36 00 00 00 00 04 04
.....''66......
Does that help?

Not really. I find it odd, that writing 0x9800 works and 0x0098 doesn't. Perhaps the chip is connected in byte-mode after all? Not sure.

Do you know if and how the Linux MTD driver handles the NOR FLASH?

Cheers,
Stefan

Rogan Dawes

author

2010-07-19 14:37 UTC #8 lore raw

Quoted 8 lines · Stefan Roese

Not really. I find it odd, that writing 0x9800 works and 0x0098 doesn't. Perhaps the chip is connected in byte-mode after all? Not sure.
Do you know if and how the Linux MTD driver handles the NOR FLASH?
Cheers,
Stefan

Here is the setup code from the Linux kernel:

Quoted 1 line

http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#L93>

Which is used by:

<http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#L435>

I don't know enough about the kernel to understand where it goes to from there.

Rogan

Stefan Roese

2010-07-20 07:58 UTC #9 lore raw

Hi Rogan,

Quoted 13 lines · On Monday 19 July 2010 16:37:08 Rogan Dawes wrote:

Quoted 7 lines · Stefan Roese
Not really. I find it odd, that writing 0x9800 works and 0x0098 doesn't. Perhaps the chip is connected in byte-mode after all? Not sure.
Do you know if and how the Linux MTD driver handles the NOR FLASH?
Cheers,
Stefan
Here is the setup code from the Linux kernel:
Quoted 2 lines
http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c
#L93>

Quoted 7 lines

Which is used by:
<http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#
L435>
I don't know enough about the kernel to understand where it goes to from there.

OK, so the width is definitely 8 bit and not 16 bit:

static struct physmap_flash_data dns323_nor_flash_data = {
	.width		= 1,

...

But the base address is listed here as 0xf4000000:

#define DNS323_NOR_BOOT_BASE 0xf4000000

Are you sure you got this right? Nevertheless, now we know for sure, that the NOR chip is connected as an 8bit device and the chip is operated in byte mode. So all tests from the U-Boot prompt should be done with ".b" extension.

BTW: This code you referenced is also available in mainline kernel.org.

Cheers,
Stefan

Rogan Dawes

author

2010-07-20 08:38 UTC #10 lore raw

Quoted 11 lines · Stefan Roese

Hi Rogan,
OK, so the width is definitely 8 bit and not 16 bit:
static struct physmap_flash_data dns323_nor_flash_data = {
	.width		= 1,
...
But the base address is listed here as 0xf4000000:
#define DNS323_NOR_BOOT_BASE 0xf4000000

Hmmm, maybe I must try changing that, then. That might be the answer to all the confusion.

Although it is definitely an 8MB flash, and I thought it was supposed to be at the end of memory?

Quoted 5 lines

Are you sure you got this right? Nevertheless, now we know for sure, that the NOR chip is connected as an 8bit device and the chip is operated in byte mode. So all tests from the U-Boot prompt should be done with ".b" extension.
BTW: This code you referenced is also available in mainline kernel.org.

Yes, I eventually got my "git clone" finished.

Thanks again for your help!

Rogan

Rogan Dawes

author

2010-07-20 10:00 UTC #11 lore raw

Quoted 9 lines · On 2010/07/20 10:38 AM, I wrote:

Quoted 3 lines
But the base address is listed here as 0xf4000000:
#define DNS323_NOR_BOOT_BASE 0xf4000000
Hmmm, maybe I must try changing that, then. That might be the answer to all the confusion.
Although it is definitely an 8MB flash, and I thought it was supposed to be at the end of memory?

Well, obviously, the address lines are connected up such that all accesses in that section wrap into the flash, whatever the offset is.

Unfortunately, but understandably, it makes no difference whatsoever to the behaviour of the flash chip. I can still put it into QRY mode, where I get the doubled QQRRYY response, but the flash is not detected any better than it was previously.

I suppose my next best option is to try to ask the Linux kernel folk if they have any ideas.

Rogan

Reinhard Meyer (-VC)

2010-07-20 10:06 UTC #12 lore raw

Quoted 4 lines · Rogan Dawes

Unfortunately, but understandably, it makes no difference whatsoever to the behaviour of the flash chip. I can still put it into QRY mode, where I get the doubled QQRRYY response, but the flash is not detected any better than it was previously.

Might it be that the design connects the flash A(-1) not to A(0) of the CPU? Or might it be that the flash is actually connected 16-bit wide, but you programmed the bus interface to be 8-bit wide?
Both variants would lead to such a doubled answer.

Reinhard

Reinhard Meyer (-VC)

2010-07-20 10:22 UTC #13 lore raw

In reply to Rogan Dawes

Quoted 4 lines · Rogan Dawes

Unfortunately, but understandably, it makes no difference whatsoever to the behaviour of the flash chip. I can still put it into QRY mode, where I get the doubled QQRRYY response, but the flash is not detected any better than it was previously.

OOPS:

On our system (top5200) the behaviour is exactly as yours:

=> mm.b ff0000aa
ff0000aa: 00 ? 98
ff0000ab: 00 ? .
=> md.l ff000000
ff000000: 00000000 00000000 00000000 00000000 ................
ff000010: 00000000 00000000 00000000 00000000 ................
ff000020: 51515252 59590202 00004040 00000000 QQRRYY....@@....
ff000030: 00000000 00002727 36360000 00000707 ......''66......
ff000040: 07070a0a 00000303 05050404 00001a1a ................
ff000050: 02020000 05050000 0101ffff 01010000 ................
ff000060: 02020000 00000000 00000000 00000000 ................
ff000070: 00000000 00000000 00000000 00000000 ................
ff000080: 50505252 49493131 33331010 02020101 PPRRII1133......
ff000090: 00000808 00000000 0202b5b5 c5c50404 ................
ff0000a0: 01010000 00000000 00000000 00000000 ................
ff0000b0: 00000000 00000000 00000000 00000000 ................
ff0000c0: 00000000 00000000 00000000 00000000 ................
ff0000d0: 00000000 00000000 00000000 00000000 ................
ff0000e0: 00000000 00000000 00000000 00000000 ................
ff0000f0: 00000000 00000000 00000000 00000000 ................
=>

But because of other constraints and since the port was done in 2003 we never tried to use the CFI driver ;)
(our flash has 64MB but only the first 16 MB are memory mapped.)

Hardware: Spansion 29GL512 in 8-Bit mode, that means Flash D15/A(-1) connected to CPU A0
Flash A0 connected to CPU A1
Flash A1 connected to CPU A2
etc...

You might want to look at board/emk/common/flash.c for insights :)

Reinhard

Rogan Dawes

author

2010-07-20 10:29 UTC #14 lore raw

Quoted 28 lines · Reinhard Meyer (-VC)

Quoted 4 lines · Rogan Dawes
Unfortunately, but understandably, it makes no difference whatsoever to the behaviour of the flash chip. I can still put it into QRY mode, where I get the doubled QQRRYY response, but the flash is not detected any better than it was previously.
OOPS:
On our system (top5200) the behaviour is exactly as yours:
=> mm.b ff0000aa
ff0000aa: 00 ? 98
ff0000ab: 00 ? .
=> md.l ff000000
ff000000: 00000000 00000000 00000000 00000000 ................
ff000010: 00000000 00000000 00000000 00000000 ................
ff000020: 51515252 59590202 00004040 00000000 QQRRYY....@@....
=>
But because of other constraints and since the port was done in 2003 we never tried to use the CFI driver ;)
(our flash has 64MB but only the first 16 MB are memory mapped.)
Hardware: Spansion 29GL512 in 8-Bit mode, that means Flash D15/A(-1) connected to CPU A0
Flash A0 connected to CPU A1
Flash A1 connected to CPU A2
etc...

Quoted 3 lines

You might want to look at board/emk/common/flash.c for insights :)
Reinhard

I'll do that.

You're not tempted to try to fix the CFI driver for your board anyway, I suppose? :-)

Thanks for the pointer.

Rogan

Reinhard Meyer (-VC)

2010-07-20 10:53 UTC #15 lore raw

Quoted 2 lines · Rogan Dawes

You're not tempted to try to fix the CFI driver for your board anyway, I suppose? :-)

Tempted: YES !

Time available: (currently) NONE

Being on the wish/todo list: since years :)

(and I might have to add some board specifig #ifdefs because of the 16 MB mapping)

BTW.. are you sure the CFI driver cannot handle such a simple flash? It might need just the proper #defines.
After all, the Spansion 8/16-bit wide flashs are not uncommon, neither should it be uncommon to connect them in 8-bit mode.

Reinhard

Rogan Dawes

author

2010-07-20 11:01 UTC #16 lore raw

Quoted 13 lines · Reinhard Meyer (-VC)

Quoted 2 lines · Rogan Dawes
You're not tempted to try to fix the CFI driver for your board anyway, I suppose? :-)
Tempted: YES !
Time available: (currently) NONE
Being on the wish/todo list: since years :)
(and I might have to add some board specifig #ifdefs because of the 16 MB mapping)

Quoted 6 lines

BTW.. are you sure the CFI driver cannot handle such a simple flash? It might need just the proper #defines.
After all, the Spansion 8/16-bit wide flashs are not uncommon, neither should it be uncommon to connect them in 8-bit mode.
Reinhard

Hi Reinhard,

Of course I understand that everyone's time is limited, and my priorities are not everyone else's.

If you can point me to the correct defines, I'd be happy to try them. Unfortunately, I have no real clue what I am doing :-)

Regards,

Rogan

Albert ARIBAUD

2010-07-23 10:17 UTC #17 lore raw

Le 20/07/2010 13:01, Rogan Dawes a ?crit :

Quoted 26 lines · Reinhard Meyer (-VC)

Quoted 13 lines
Quoted 2 lines · Rogan Dawes
You're not tempted to try to fix the CFI driver for your board anyway, I suppose? :-)
Tempted: YES !
Time available: (currently) NONE
Being on the wish/todo list: since years :)
(and I might have to add some board specifig #ifdefs because of the 16 MB mapping)
Quoted 6 lines
BTW.. are you sure the CFI driver cannot handle such a simple flash? It might need just the proper #defines.
After all, the Spansion 8/16-bit wide flashs are not uncommon, neither should it be uncommon to connect them in 8-bit mode.
Reinhard
Hi Reinhard,
Of course I understand that everyone's time is limited, and my priorities are not everyone else's.

Quoted 6 lines

If you can point me to the correct defines, I'd be happy to try them. Unfortunately, I have no real clue what I am doing :-)
Regards,
Rogan

Hi Rogan,

The best, I think, is to go through the ifdefs in the CFI flash detection code and reverse-engineer those defines. You could even maybe update the doc/ directory with the result of this analysis.

Amicalement,

Signature · 1 line

Albert.

Rogan Dawes

author

2010-08-12 12:07 UTC #18 lore raw

In reply to Stefan Roese

Quoted 7 lines · Stefan Roese

OK, so the width is definitely 8 bit and not 16 bit:
static struct physmap_flash_data dns323_nor_flash_data = {
	.width		= 1,
...

Quoted 7 lines

But the base address is listed here as 0xf4000000:
#define DNS323_NOR_BOOT_BASE 0xf4000000
Are you sure you got this right? Nevertheless, now we know for sure, that the NOR chip is connected as an 8bit device and the chip is operated in byte mode. So all tests from the U-Boot prompt should be done with ".b" extension.

Hi Stefan,

I found the following configuration snippet for OpenOCD for the DNS323 at http://wiki.dns323.info/hardware:jtag:

#          driver   addr       size     chip_width  bus_width  options
flash bank cfi      0xff800000 0x800000 1           2          0

It seems that the key here is that the bus_width is set to 2, even though the chip_width is only 1.

Also, the flash address is still 0xff800000, even though the kernel has it as 0xf4000000. I guess this is because only a certain number of address lines are actually connected through to the flash chip, and so the chip can appear in multiple places?

Does that make any more sense? Is it possible that the CFI code in U-Boot doesn't consider the case when bus_width == 2?

Regards,

Rogan

Stefan Roese

2010-08-12 12:40 UTC #19 lore raw

Hi Rogan,

Quoted 8 lines · On Thursday 12 August 2010 14:07:03 Rogan Dawes wrote:

I found the following configuration snippet for OpenOCD for the DNS323 at http://wiki.dns323.info/hardware:jtag:
#          driver   addr       size     chip_width  bus_width  options
flash bank cfi      0xff800000 0x800000 1           2          0
It seems that the key here is that the bus_width is set to 2, even though the chip_width is only 1.

Seems not to be so uncommon: 8bit device on a 16bit external bus.

Quoted 4 lines

Also, the flash address is still 0xff800000, even though the kernel has it as 0xf4000000. I guess this is because only a certain number of address lines are actually connected through to the flash chip, and so the chip can appear in multiple places?

Yes, this could be the case. The flash is most likely "mirrored".

Quoted 2 lines

Does that make any more sense? Is it possible that the CFI code in U-Boot doesn't consider the case when bus_width == 2?

As mentioned above, this seems to be a common use-case (even though I don't have such a board at hand right now). Bus-width = 2 (vs. bus-width = 1) shouldn't really matter here. A CPU byte access to the flash address space should translate in one access cycle (8-bit) to the flash device.

Sorry, no real idea whats going wrong without being able to test/debug on this platform.

Cheers,
Stefan

Reinhard Meyer

2010-08-12 13:14 UTC #20 lore raw

Quoted 6 lines · Stefan Roese

Hi Rogan,
Quoted 3 lines · On Thursday 12 August 2010 14:07:03 Rogan Dawes wrote:
I found the following configuration snippet for OpenOCD for the DNS323 at http://wiki.dns323.info/hardware:jtag:

Quoted 7 lines

Quoted 5 lines
#          driver   addr       size     chip_width  bus_width  options
flash bank cfi      0xff800000 0x800000 1           2          0
It seems that the key here is that the bus_width is set to 2, even though the chip_width is only 1.
Seems not to be so uncommon: 8bit device on a 16bit external bus.

It is mostly likely a 8/16 bit wide device in 8 bit mode on an 8 bit external bus. Then all CFI data appears twice.

Reason: the chip presents CFI data correctly (from the flash point of view) in 16 bit mode (flash A0 connected to CPU A1). If connected in 8 bit mode (flash A0 connected to CPU A1, flash A-1 connected to CPU A0) it still presents the data at the same adresses but the CFI driver gets misled because its told to try for 8 bit wide flash.

Since that was an issue long ago, I made the board/emk/common/flash.c (CFI) driver. Anyone is welcome to add that special handling for 16 bit flash connected in 8 bit mode to the general CFI driver :)

Best Regards,
Reinhard

Rogan Dawes

author

2010-08-12 13:26 UTC #21 lore raw

Quoted 2 lines · Reinhard Meyer

It is mostly likely a 8/16 bit wide device in 8 bit mode on an 8 bit external bus. Then all CFI data appears twice.

Yes, this is exactly what I was seeing.

Quoted 9 lines

Reason: the chip presents CFI data correctly (from the flash point of view) in 16 bit mode (flash A0 connected to CPU A1). If connected in 8 bit mode (flash A0 connected to CPU A1, flash A-1 connected to CPU A0) it still presents the data at the same adresses but the CFI driver gets misled because its told to try for 8 bit wide flash.
Since that was an issue long ago, I made the board/emk/common/flash.c (CFI) driver. Anyone is welcome to add that special handling for 16 bit flash connected in 8 bit mode to the general CFI driver :)

Thanks a lot! I'll take a look, and see if I can understand it. :-)

Rogan