[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hi All,

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
>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
>
>  
>