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

[Ulf Samuelsson <ulf@atmel.com>]

> On 5/28/07, Ladislav Michl <ladis@linux-mips.org> wrote:
>> Principle described above has few serious drawbacks. Storage is no
>> longer storage, but randomly mapped memory. As a u-boot programer you
>> have to determine such memory map and as a u-boot user you have to
>> remember it.
> 
> Exactly. Giving storage devices which aren't memory mapped a "virtual"
> address is a bad idea. And the database example is crap because it
> depends on hardware paging, which isn't being proposed here (how many
> architectures supported by u-boot can do 64-bit virtual address in
> hardware?)
> 
> That said, I do think Ulf has a point -- being able to compare a block
> of data in nand- or dataflash with something in memory (or other kinds
> of storage) is a pretty neat feature. But it should not be done by
> using "virtual" addresses (due to the problems described above), and
> it should be implemented in a generic way. Pouring #ifdefs all over
> cmd_mem.c is short-sighted and selfish.

My proposal removes all #ifdefs from memory commands.

> I'm not sure if anyone's suggested this before, or whether it was
> well-received or not, but why don't we generalize the cmd_mem syntax a
> little? For example, let every memory address can be prefixed by an
> optional "storage specifier" and a ':' character. The default "storage
> specifier" is "mem", so that if it is omitted everything will work as
> before, but you can also do things like
> 
>  cp.b df0:0x4200 0x85000000
>  cmp.l 0x24000000 nand1.1:0x123456789
> 

Which is 100% compatible with my proposal.

"cp.b df0:0x4200 0x85000000  ${size}"

is decoded by the command parser and the "cp" command is selected.

"cp" sends "df0:0x4200" down the chain of registred memory/storage devices.
The NAND flash driver will not understand "df0" so it ignores the parameter.
The dataflash driver detects that this is a dataflash and decides it is a success
and returns a pointer to a descriptor allowing the "cp" command to read/write dataflash.

Then "cp" sends down the "0x85000000" parameter, and it is decided
that this is located in SDRAM.

"cp" then calls the dataflash specific copy to sdram routine 
(from the descriptor) using 0x85000000 and ${size} as parameters.

The dataflash copy routine will (in the AT91 case) just set
up the initial address and copy chunks of 64 kB using the 
DMA controller (PDC).

No need for any #ifdefs to handle this as far as I see.

> and so on. Whatever comes after ':' is passed to the storage handler
> as a string, so if some storage types need 64-bit offsets, the handler
> can support it without disturbing anything else.
> 
> What do you think about something like that? The actual syntax
> probably needs some work to get right, and we need to take care to
> ensure backwards compatibility of course.
> 
> This does actually come quite close to Ulf's proposal, but instead of
> requiring the user to remember a "virtual address", we instead require
> him to enter a logical device and an offset, ie.. kind of a simple VFS
> without any actual files involved...

I never said that you need to supply an address, you need
to supply a parameter, but the syntax of this can be driver specific.

> 
> Haavard
> 


Best Regards
Ulf Samuelsson