[U-Boot-Users] Atmel DataFlash hooks.
wd at denx.de
Sun Jan 28 23:50:45 CET 2007
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
> 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
> 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.
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
More information about the U-Boot