[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell <jwilliamcampbell@comcast.net>]

Ulf Samuelsson wrote:

>>If it can be decided that the only devices that will be supported by the 
>>memory commands in cmd_mem.c are those devices that can be read directly 
>>as ram without a read routine, I think that would help clarify the 
>>intent of the commands.
>>  
>>    
>>
>
>Why limit to "read".
>Why not say that any memory which can be read or *written* without a driver
>will be supported by the cmd_mem.c ?
>
>
>  
>
There are at least two very good reasons why adding the "written" 
constraint is not practical: First, as he has stated several times in 
this thread, Mr. Denk believes that users regard NOR flash as just like 
ram and therefore expect ram commands to work on it. This point of view 
certainly has merit, and while we may not all totally agree with it, it 
is, and must be, Mr. Denk's u-boot. He is the final determining person 
on what will be accepted.
The second, and perhaps even better reason to not remove NOR flash from 
the memory commands is that it will break just about 100% of all 
existing u-boot configurations. Ok, maybe it's 95%, but its real large. 
This doesn't even take into account how many README files out there 
describe copying things into flash with the cp command. This type of 
support is not going away for these reasons.
My main goal in this thread is to create/keep the "read" constraint 
intact so that we don't have constant additions of #ifdefs  to the 
cmd_mem.c to support any arbitrary non-memory bus devices that people 
decide they want to use like memory, or that if we were going to do that 
we would create a way to do it that didn't result in an #ifdef maze.  
Mr. Denk has solved this concern on my part. We aren't going to add 
devices that require read routines.

Best Regards,
Bill Campbell