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

[Ladislav Michl]

On Mon, May 28, 2007 at 04:08:50PM +0200, Ulf Samuelsson wrote:
> > 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.

Not if you could run command in a loop.

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

Sure. Point was that sane power user will compare chunk by chunk (6 MB
file and 8 MB RAM case).

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

Could you point me to it, please?

[snip]
> > 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.

NOR interface is finished.

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

Mapped into address space, CAN be written in the same way as SDRAM.
Note that I'm not doing any advocacy here, I want acceptable solution
without drawbacks.

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

See below and try to imagine what would need to be done to support 64bit
virtual address space.

[snip]
> 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.

That's only suggestion.

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

And memory is even IDE disc as you suggested in your database example?

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

So here you basicaly proposing something like u-boot virtual memory.
What if I have storage greater than addresable area? NAND chips are
pretty close to that for example (and even today it is quite easy to
build such board using few more NAND chips) and consider design with
64MB of RAM, 2GB NAND and 1G SD card and 1G USB stick. Will you move
to 64bit address space? In bootloader? Bootloader has always been
something simple, usefull only to boot application which does the job.
Perhaps it would help if you could express what you expect from a
bootloader...

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

That's it... Above example needs 64bit virtual address space.

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. If you are using partitions you probably want to pass such
partitions mapping to linux. Curently it very easy and comfortale, you
can copy kernel and rootfs image to partion refered by name, without
even knowing where it is. And btw, where would you map OOB area of NAND
chip?

Best regards,
	ladis