public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ulf Samuelsson <ulf@atmel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT
Date: Mon, 28 May 2007 16:08:50 +0200	[thread overview]
Message-ID: <01a501c7a131$e7bea950$0302a8c0@atmel.com> (raw)
In-Reply-To: 20070528113756.GA7121@michl.2n.cz

> 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

  reply	other threads:[~2007-05-28 14:08 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-26 10:53 [U-Boot-Users] Question about CFG_ENV_ADDR during RAMBOOT Ulf Samuelsson
2007-05-26 13:15 ` Wolfgang Denk
2007-05-28 11:37 ` Ladislav Michl
2007-05-28 14:08   ` Ulf Samuelsson [this message]
2007-05-28 15:39     ` Ladislav Michl
2007-05-28 16:16       ` Håvard Skinnemoen
2007-05-28 16:56         ` Ulf Samuelsson
2007-05-28 19:39           ` Ladislav Michl
2007-05-29  0:10             ` Wolfgang Denk
2007-05-29 22:13               ` Ulf Samuelsson
2007-05-29 22:46                 ` Wolfgang Denk
2007-05-29 23:15                   ` Ulf Samuelsson
2007-05-29 23:39                     ` Wolfgang Denk
2007-05-30  0:46                       ` Ulf Samuelsson
2007-05-30  6:57                         ` Wolfgang Denk
2007-05-30 10:52                           ` Ladislav Michl
2007-05-30 13:43                             ` Wolfgang Denk
2007-05-30 18:11                               ` Ulf Samuelsson
  -- strict thread matches above, loose matches on Subject: below --
2007-05-30 11:34 Ulf Samuelsson
2007-05-30 12:16 ` Ladislav Michl
2007-05-30 13:47 ` Wolfgang Denk
2007-05-30 18:23   ` Ulf Samuelsson
2007-05-30 23:19     ` Wolfgang Denk
2007-05-16 19:58 Timur Tabi
2007-05-22 20:36 ` Timur Tabi
2007-05-22 20:53   ` Jerry Van Baren
2007-05-22 21:04     ` Wolfgang Denk
2007-05-22 21:07       ` Timur Tabi
2007-05-23  0:15         ` Wolfgang Denk
2007-05-23 15:58           ` Timur Tabi
2007-05-22 21:26       ` Jerry Van Baren
2007-05-22 21:20     ` Andy Fleming
2007-05-22 21:22       ` Timur Tabi
2007-05-23  0:17         ` Wolfgang Denk
2007-05-23 14:56           ` Timur Tabi
2007-05-22 21:00   ` Wolfgang Denk
2007-05-22 21:30     ` Andy Fleming
2007-05-23 10:04     ` Ladislav Michl
2007-05-23 10:48       ` Ulf Samuelsson
2007-05-23 11:39         ` Ladislav Michl
2007-05-23 12:52           ` Ulf Samuelsson
2007-05-23 13:57             ` Wolfgang Denk
2007-05-23 16:19               ` Ulf Samuelsson
2007-05-24 12:10                 ` Ladislav Michl
2007-05-24 13:03                   ` Wolfgang Denk
2007-05-24 13:34                     ` Ladislav Michl
2007-05-24 19:08                   ` Ulf Samuelsson
2007-05-24 21:11                     ` Wolfgang Denk
2007-05-24 21:43                       ` Ulf Samuelsson
2007-05-24 23:46                         ` Wolfgang Denk
2007-05-25  5:37                         ` Stefan Roese
2007-05-25  8:50                           ` Ladislav Michl
2007-05-23 12:59           ` Ulf Samuelsson
2007-05-23 13:25             ` Ladislav Michl
2007-05-23 16:05               ` Ulf Samuelsson
2007-05-24 12:29                 ` Ladislav Michl
2007-05-24 18:34                   ` Ulf Samuelsson
2007-05-24 18:35                   ` Ulf Samuelsson
2007-05-23 12:59         ` Wolfgang Denk
2007-05-23 15:44           ` Ulf Samuelsson
2007-05-23 18:08             ` Wolfgang Denk
2007-05-24  9:14             ` Ladislav Michl
2007-05-25  9:06               ` Ladislav Michl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='01a501c7a131$e7bea950$0302a8c0@atmel.com' \
    --to=ulf@atmel.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox