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
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.