[U-Boot-Users] Atmel DataFlash hooks.
J. William Campbell
jwilliamcampbell at comcast.net
Sun Jan 28 23:21:11 CET 2007
Wolfgang Denk wrote:
>In message <45BC0099.3070706 at comcast.net> you wrote:
>>understand this command. This way, it
>>is possible to read/write from any "device" to system ram. A driver to
>>treat system ram as a device could also
>>be compiled into u-boot.
>It certainly could. BUt IMHO it does not ake sense to require a
>driver to access RAM (!) when a "*pointer" is all that's needed.
>We're talking aboth the difference between a single machine
>instruction versus calls to several complex functions here!
>Please let's keep the code as small, and as simple, as possible.
Agreed. I only pointed out this could be done if for some reason a user
required complete symmetry in access to all system resources. I don't,
and probably nobody would, but just in case it was required for some
reason I can't see right now, it is possible. The code would be small,
in that a read would just return a pointer to the data already in ram,
and a write would be just a " memcpy", but it would not be no code at all.
>>If the user wants to maintain the ability to operate with memory
>>commands on bus-addressed memory of any kind,
>>it is simple to initialize the mmapped address table appropriately.
>Folks, please, do me a favour: before you continue, go and read the
>U-Boot code and make a list what needs to be done on all the
>different boards even before we have a working C environment.
>Be aware, that your rewrite (1) will have to support all these
>features, too, (2) must not (significantly) increase the memory
>footprint for existing configurations which don't need any features
>added, and (2) will have to run in such a restricted environment,
>where you probably cannot even allocate a 512 byte buffer for I/O.
>I don't want to stop you, but please keep the environment in mind
>where your code has to fit in.
I think you are correct here. Naturally, I have been looking at the code
in this process, but a complete list, or better yet, a proposed patch,
would allow this comparison and trade-off to be more simply evaluated. I
believe that the "restricted environment" caveat above certainly applies
to reading the environment data before relocation. I am not presently
aware of other times where this is true, but if there are any, I need
to find them! Places where there are any other accesses, or writes that
take place before relocation could be problems. If you know of any,
pointers to general areas would be appreciated! At present, the
CFG_ENV_IS_IN_XXX options are limited to certain devices. I do not
propose to increase that list unless/until everything else involved is
working! I notice that the DataFlash routine does allocate a 64 byte
buffer on the stack to speed up CRC checking the environment, which I
assume is still OK. There IS a lot of work required to co-ordinate all
the read/write routines involved in such a proposed change, but these
routines do already exist.
>>dynamically. If the user does not want this type of support, it can be
>>completely omitted from the u-boot build and all
>>memory type commands will be executed using the CPU ram read/write
>>routines and addresses.
>??? I don;t see how this would be possible if I understand hwta GRand
>and you have in mind. At least not without adding yet another #ifdef
I certainly do not want to add many more #ifdefs to make this happen.
Once again, probably only a proposed patch can resolve this question
>>I think this approach gives everybody what they want. In cases where
>>"normal" ram and device access to a few devices
>>is all that is desired, u-boot would probably be slightly smaller than
>>it is now. If mmapped support is included, it might be very
>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
with CFG_NO_FLASH defined (which would be #ifndef CFG_MMAP_DEVICES in
my proposed approach) and a FLASH READ/FLASH WRITE commands added to
cmd_flash.c would be slightly smaller than the present minimum
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.
>>Comments welcome. I don't think this is really a big change from the
>>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
add some complexity and size to the associated memory manipulation
commands. As the object being addressed differs more and more from
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.
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
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
system has some implicit and some explicit requirements on memory
operands. I will try to be either no more restrictive or less
restrictive in any changes I propose.
>You probably remember our old discussion about ENV_IS_EMBEDDED from a
>year or so ago - do you? This is another similar area. The current
>code is not flexible and ugly, but all the configuration and code
>selection is done at compile time, which means we have a minimal
>U-Boot is a boot loader. Keep is small and simple.
I completely agree with small and simple, and making feature choices at
compile time. I think these attributes can be preserved, or perhaps
enhanced, in cmd_mem and cmd_load, but naturally you will be the judge
of the results! I am also very aware of the testing problems that can
arise from the possible changes.
More information about the U-Boot