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

[Ladislav Michl]

On Wed, May 23, 2007 at 06:19:21PM +0200, Ulf Samuelsson wrote:
> > In message <007301c79d3a$37b63320$f22ab10a at atmel.com> you wrote:
> >>
> >> I tried to resubmit, but since Grant and Wolfgang has come to the
> >> conclusion that sometimes memory is not memory I see no possibility
> >> to overcome difference.
> >
> > Memory is always memory. Serially attached devices are NOT memory.
>
> That is _your_ definition of memory, others like "Webster Dictionary"
> say:
> 
> "Memory: a device (as a chip) or a component of a device in which
> information especially for a computer can be inserted and stored and
> from which it may be extracted when wanted; especially : RAM"
> 
> You add an extra requirement that memory must be randomly addressable
> over a parallel bus.  This view is uncompatible with Websters
> dictionary which does not pose such restrictions.  Furthermore,
> everyone designing flash memories, believe that serial flash memories
> are memories.

That belive has nothing to do with software interface design. While you
pretend serial flash memory is somehow mapped into procesor address
space, others have different ideas. "Webster Dictionary" uses largest
common denominator so its definition applies to hard discs as well.
Do we pretend hard disc content is mapped over IDE or SCSI bus into
CPU address space?

> You have made your decision here, and I have to accept that, but you
> are then trying to get *me* to make the changes you want, and I really
> have no incentive to do that and will leave that to others.

Then I'm voluntering to do that work. There is one issue left. The
interface. I remember few almost endless debates about this topic, but
no conclusion.

Lets dive into archives.

In this thread most of possible solutions were developed. Without
conclusion.
Subject: Atmel DataFlash hooks.
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/25983

And this is another very interesting thread:
Subject: [PATCH] DataFlash for AT91RM9200DK board
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/9175
It contains quite interesting part which is worth to repeat there
(by Wolfgang Denk, 2003-06-04)

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> In our case, we use it to store and boot an image of linux(the dataflash
> contains the linux zImage and the ramdisk).
> This dataflash can be used also for a filesystem.

In this case I think we should offer an interface which looks\
to the user like mmeory.

Instead of providing separate commands to read and  write  from  such
"memory" I think we should integrate this into the existing code.

For  example,  writing  to  "normal"  flash  memory  is  an  implicit
operation  to the "cp" (copy) command when it detects that the target
address is in flash memory.

The same should be done for dataflash.

OK, with "normal" flash memory we don't  have  to  special-case  read
accesses  like  used  by  "md" or "bootm" commands - where in case of
dataflash such handling will be necessary.

But especially if you boot Linux from dataflash it seems more logical
to me to use "bootm" directly instead of  using  "dataflash  read"  +
"bootm" in separate steps.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

That makes clear reasons behind Ulf's statement and also shows that not
all decisions are good ones.

If anyone feels need to fix u-boot's dataflash support, then please
either lets continue in more than 16 weeks old debate in 'Atmel
DataFlash hooks' thread or spawn new one.

Best regards,
	ladis