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
next prev parent 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