[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BD21D7.20203 at comcast.net> you wrote:
> 
> >I can't see how you would get the standard  configuration  (just  RAM
> >and NOR flash support) smaller with such a change?
> >
> There are presently quite a few #ifdefs involved in cmd_mem.c and 
> cmd_load.c to take different memory types into consideration. These 
> would mostly go away. That is why I think a ram + flash configuration 

OK, so the *source* code may become smaller indeed.  But  I'd  expect
the  memory  footprint  on  the target system to grow instead, or you
lose functionality.

> configuration. Naturally, you loose the ability to dump flash data with 
> md, compare to flash data with cmp, copy flash data with cp.b, load data 
> directly to flash with loadb, etc. so it is not free, just a bit smaller.

Arghhh... Indeed, that's not free. I guess for such a price there are
other, more efficient ways to reduce the code size.

> >>current system, it is just a formalization of what
> >>has always been desired.
> >
> >Umm... "always been desired" - by whom? :-)
> >
> Well, as I understood it, at least partially by you. :-) The ability to 
> use memory oriented commands on memory other than simple ram seems to be 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> considered a plus by many u-boot community members. However, this does 

Read what you wrote: "use memory oriented commands on memory". That's
exactly what I really expect to be able to do, indeed.

Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
contents? 

> add some complexity and size to the associated memory manipulation 
> commands. As the object being addressed differs more and more from 

Not really. Normally only writing may need special handling.

I can't say if Dataflash really fits into this szenario; I never used
this feature myself.

> simple ram, more and more people seem to accept "new" commands to read 
> and write these objects, and to forgo the advantages/features of the 
> memory commands. This becomes especially true when the size of the 
> object to be read/written exceeds the size of the CPU address space. 

Do you have an example where this happens in U-Boot context?

> What my goal in this proposed design is to allow users to choose at 
> compile time what features are desired for the u-boot memory commands  
> a) without an ifdef maze and b) without needing to inject new code into 
> cmd_mem.c and cmd_load.c for every different memory technology that will 
> use memory access type commands. If somebody wants to use the memory 
> commands on a serial EEPROM, this can be made to work if desired, or not 

I feel that would be not natural. And EEPROM (like on a I2C bus) does
not have any natural adresses in the CPU's address  space.  Same  for
IDE  or  USB  devices.  These are storage devices on some form of I/O
bus, but certainly NOT memory.

> made to work if not considered necessary, without changing cmd_mem.c.  
> How possible/good this goal is remains to be seen, I agree. The current 

IMHO we should provide a user inteface which is powerful, yet easy to
use - this requires it must be intuitive to the end user. For most  f
them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
EEPROM is not.

> I completely  agree with small and simple, and making feature choices at 
> compile time. I think these attributes can be preserved, or perhaps 

Ther eis another thing that is important to me: U-Boot  on  different
systems,  boards  and architectures shall always behave as similar as
possible. Having the "cmp" command (if configured into  U-Boot)  work
on  flash  memory  on  one system and failing to do so on another one
seems unacceptable to me.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
                                                 -- Bjarne Stroustrup