Hi All,
Wolfgang Denk wrote:
In message 45BC0099.3070706@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 maze.
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 memory footprint.
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.
Best Regards, Bill Campbell
Best regards,
Wolfgang Denk