[U-Boot-Users] Atmel DataFlash hooks.

Wolfgang Denk
2007-01-28T22:50:45Z

In message <45BD21D7.20203@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