[U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT

[Ulf Samuelsson]

> On Sat, May 26, 2007 at 12:53:31PM +0200, Ulf Samuelsson wrote:
>> => OK, then tell me how
>>    to compare a 6 MB
>>    file in flash with a 6MB
>>    file in SDRAM when
>>    your SDRAM is 8 MB.
> 
> Chunk by chunk?

Yes, but not by doing that manually.
It was suggested that you do not need any command
to do that compare since you can copy from dataflash to SDRAM.
If you use 64 kB buffers, then you have to type in 96 U.boot commands
to do that single compare.

> But indeed, there is a little problem. It would be usefull to show
> address which contains diferences from the beginning of dataflash
> (or dataflash partition)...
> 
>>    We are *not* running on
>>    PC's.
> 
> 
> Anyone who copies whole file into RAM and then does compare has either a
> lot of RAM or doesn't deserve to be called power user.
> 

The amount of flash and ram is typically determined by the need of 
the application, and not by the qualifications of the person running U-boot.

> Lines 303-308 of common/cmd_mem.c reads (cmp command):
> #ifdef CONFIG_HAS_DATAFLASH
>        if (addr_dataflash(addr1) | addr_dataflash(addr2)){
>                puts ("Comparison with DataFlash space not supported.\n\r");
>                return 0;
>        }
> #endif
> 
> On my boards it leads to:
> # cmp.l 10000000 C0000000 10
> Comparison with DataFlash space not supported.
> 
> Therefore it seems I have to copy to RAM anyway and it doesn't seem to
> be fixed by any patch at ftp 81.80.104.162.

That is funny because I have done that patch.

> 
>>    I would have more respects
>>    for exhibited views if writes
>>    to parallel flash is removed
>>    from cp.b...
>>    Parallel flash is clearly not
>>    "memory" for write 
>>     purposes, only for read
>>     purposes.
>>     Its existence in cp.b will 
>>     force endless #ifdefs
>>     or support for parallel flash
>>     will have to remain and
>>    bloat code.
> 
> Erm... This interface is finished, contains finite number of features
> and certainly finite numbers of #ifdefs. This number could be reduced
> even more by removing hacks for MMC.

It is not finished, since people would like to "clean" up the memory commands
but you are avoiding the point, in favour of advocacy.

Parallel flash CANNOT be written in the same way as SDRAM.
Why should then parallel flash be considered as memory.

I really do not advocate that this is changed, but I would like to see
some consistency in arguments.

> 
>>     You could then argue that 
>>     support for parallel flash 
>>     should be removed from
>>     all commands to remove
>>     inconsistencies...
>> 
>>    I do not think this will
>>    happen because it is
>>    *useful* and because
>>    this affects boards which
>>    people that makes 
>>    decisions works with
>>    this. They do not work
>>    with dataflash and do
>>    not care about people
>>    that wants this.
> 
> I have two AT91RM9200 based boards here. One boots from dataflash,
> stores enviroment here and loads kernel from NAND. Sure I care about
> dataflash support...
> 
>>    I think that consistency
>>    in argumentation is a
>>    reasonable demand.
>>    
>>    * BYTE WRITE
>> 
>>    Why should you waste
>>    time on copying dataflash
>>    to SDRAM when you can 
>>    do operations inside the
>>    internal SRAM.
>> 
>>    It is not desirable to transfer
>>    20,000 bits between CPU
>>    and dataflash when 100-200
>>    are sufficient.
> 
> Could you please point exactly where I suggested such behaviour?
> 

Wolfgang suggested byte writes should be implemented as 
1) Copy to SDRAM
2) Modify SDRAM
3) Write to Dataflash

which will result in above inefficiency.


> Best regards,
> ladis
>

Personally, I would like to see an architecture where every memory
registers itself in a common database.

When a memory command is executed, the command should be split 
the memory areas involved into pages, and execute the command
on each page.

Each driver would, if neccessary copy its data into a SDRAM buffer before use.

cp.b
     
     for each registred memory do
         if(src = parse(parameter 1)) != FAIL) 
                break;
         end if
     done
     if(src == FAIL) then
            src = SDRAM
    end if 

     for each registred memory do
         if(dst = parse(parameter 2)) != FAIL) 
                break;
         end if;
    done
     if(dst == FAIL) then
            dst = SDRAM
    end if

    /*
         Now you have src pointing to a descriptor for the first parameter
         and dst pointing to a descriptor for the second parameter.
        - Without any ifdefs, and easily extendible.
    */
    pageesize = determine_pagesize(src,dst);

    for(i = 0; i < size; i += pagesize) {
            Ensure that src is accessible using a memory pointer to SDRAM
                 * maybe by reading from storage to SDRAM
                 * if in SDRAM/par flash memory, just return pointer
            Copy page to destination, using access routine defined in storage driver.
    }


Best Regards
Ulf Samuelsson