[U-Boot-Users] Atmel DataFlash hooks.
J. William Campbell
jwilliamcampbell at comcast.net
Tue Jan 30 01:48:06 CET 2007
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.
More information about the U-Boot