[U-Boot] Non standard CFI detection tweaks
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:
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:
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:
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
Hi Rogan,
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
It says:
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)?
This may be influenced by the following paragraph from the manual:
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:
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)
Hmmm. Again my question: Are you using byte- or word-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?
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@denx.de
On 2010/07/19 11:34 AM, Stefan Roese wrote:
Hi Rogan,
Hi Stefan,
Thanks for responding.
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
It says:
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)?
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]
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
Hi Rogan,
On Monday 19 July 2010 12:18:45 Rogan Dawes wrote:
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?
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
-- 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@denx.de
On 2010/07/19 12:49 PM, Stefan Roese wrote:
Hi Rogan,
On Monday 19 July 2010 12:18:45 Rogan Dawes wrote:
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.
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
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 ................
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.
What's the output of those commands?
Cheers, Stefan
Thanks for your help!
On Monday 19 July 2010 13:05:09 Rogan Dawes wrote:
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
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.
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 ...............
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.
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
-- 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@denx.de
On 2010/07/19 1:50 PM, Stefan Roese wrote:
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
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:
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......
Does that help?
Rogan
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 ................
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. :-(
This is the procedure for entering QRY mode, though, from my original email:
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......
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
-- 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@denx.de
On 2010/07/19 3:33 PM, Stefan Roese wrote:
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:
http://lxr.free-electrons.com/source/arch/arm/mach-orion5x/dns323-setup.c#L9...
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
Hi Rogan,
On Monday 19 July 2010 16:37:08 Rogan Dawes wrote:
On 2010/07/19 3:33 PM, Stefan Roese wrote:
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:
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.
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
-- 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@denx.de
On 2010/07/20 9:58 AM, Stefan Roese wrote:
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?
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
On 2010/07/20 10:38 AM, I wrote:
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
Rogan Dawes schrieb:
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
Rogan Dawes schrieb:
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
On 2010/07/20 12:22 PM, Reinhard Meyer (-VC) wrote:
Rogan Dawes schrieb:
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...
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
Rogan Dawes schrieb:
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
On 2010/07/20 12:53 PM, Reinhard Meyer (-VC) wrote:
Rogan Dawes schrieb:
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
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
Le 20/07/2010 13:01, Rogan Dawes a écrit :
On 2010/07/20 12:53 PM, Reinhard Meyer (-VC) wrote:
Rogan Dawes schrieb:
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
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
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,
On 2010/07/20 9:58 AM, Stefan Roese wrote:
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.
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
Hi Rogan,
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.
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".
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
-- 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@denx.de
Stefan Roese wrote:
Hi Rogan,
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.
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
On 2010/08/12 3:14 PM, Reinhard Meyer wrote:
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.
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
participants (5)
-
Albert ARIBAUD -
Reinhard Meyer -
Reinhard Meyer (-VC) -
Rogan Dawes -
Stefan Roese