mån 2007-08-20 klockan 01:40 +0200 skrev trimarchi@gandalf.sssup.it:
Quoting Håvard Skinnemoen hskinnemoen@gmail.com:
On 8/19/07, Wolfgang Denk wd@denx.de wrote:
In message 20070818231206.GA4040@gandalf.sssup.it you wrote:
--- drivers/dataflash.c.orig 2007-08-18 17:36:08.000000000 +0200 +++ drivers/dataflash.c 2007-08-18 17:37:05.000000000 +0200 @@ -27,16 +27,16 @@ AT91S_DATAFLASH_INFO dataflash_info[CFG_ static AT91S_DataFlash DataFlashInst;
#ifdef CONFIG_AT91SAM9260EK -int cs[][CFG_MAX_DATAFLASH_BANKS] = { +int cs[][2] = { {CFG_DATAFLASH_LOGIC_ADDR_CS0, 0}, /* Logical adress, CS */ {CFG_DATAFLASH_LOGIC_ADDR_CS1, 1} }; #elif defined(CONFIG_AT91SAM9263EK) -int cs[][CFG_MAX_DATAFLASH_BANKS] = { +int cs[][2] = { {CFG_DATAFLASH_LOGIC_ADDR_CS0, 0} /* Logical adress, CS */ }; #else -int cs[][CFG_MAX_DATAFLASH_BANKS] = { +int cs[][2] = { {CFG_DATAFLASH_LOGIC_ADDR_CS0, 0}, /* Logical adress, CS */ {CFG_DATAFLASH_LOGIC_ADDR_CS3, 3} };
Why not call it dataflash_cs[] and move it into the board code? It already pollutes the namespace, is already board-dependent (hence the #ifdefs) and is apparently buggy?
Then the board code is responsible for defining a CFG_MAX_DATAFLASH_BANKS symbol which corresponds with the actual number of entries in the array. Of course, it can still be buggy, but at least it's contained within the board code.
Haavard
I send the patch just to say that the implementation does't work in the u-boot git code when CFG_MAX_DATAFLASH_BANKS is egual to 1. I find this fixing for me and send to the mailing list for a better solution. There are a lot of problem in the implementation of the dataflash layer. Take the cmd_mem.c file and It simple to observ that is not possible to use a dataflash cp operation to memory without define a dummy flash with parameters like CONFIG_MAX_BANKS set to 0. Regards Michael
Yes, but you fix it in the wrong way.
You remove the error message by introducing an inconsistency between the configuration and the actual code.
BR Ulf Samuelsson