[U-Boot-Users] Atmel DataFlash hooks.

[U-Boot-Users] Atmel DataFlash hooks.

[Peter.Pearse]

As I said to Grant

> 	But I just found the original thread for the inclusion of this code
> (http://blog.gmane.org/gmane.comp.boot-loaders.u-boot)

Search for

 [PATCH] DataFlash for AT91RM9200DK board

Especially:-

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

> Best regards,
> 
> Wolfgang Denk

Peter

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Peter.Pearse <peter.pearse@arm.com> wrote:
> As I said to Grant
>
> >       But I just found the original thread for the inclusion of this code
> > (http://blog.gmane.org/gmane.comp.boot-loaders.u-boot)
>
> Search for
>
>  [PATCH] DataFlash for AT91RM9200DK board
>
> Especially:-
>
> <snip>
> >
> > In this case I think we should offer an interface which looks
> >  to the user like mmeory.
> <snip>

Not all design decision turn out to be good ones.  I'm not
particularly fond of this design decision; but I understand the
argument behind it. I really have a problem with is the
implementation.  It is DataFlash specific and it adds a set of device
specific hooks to each command.  If every other device was added in
the same way, then there would be an absolute rats nest of #ifdef
blocks in the simple memory access routines.

Other storage devices have not gone the route of pretending to be
memory mapped.  I think that u-boot needs to settle on one method for
accessing these devices.  Either add generic hooks to the mem access
commands so *all* storage devices can be accessed that way; or make
those routines *only* for memory mapped devices.

My vote is to treat DataFlash like a block device, and make sure that
it supports byte-wide access.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com> you wrote:
>
> My vote is to treat DataFlash like a block device, and make sure that
> it supports byte-wide access.

Treat DataFlash like a block device? That sounds wrong to me. 

I understand your concerns about the #ifdef mess, but this suggestion
does not sound tempting either.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A man either lives life as it happens to him, meets  it  head-on  and
licks it, or he turns his back on it and starts to wither away.
	-- Dr. Boyce, "The Menagerie" ("The Cage"), stardate unknown

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
>
> In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com> you wrote:
> >
> > My vote is to treat DataFlash like a block device, and make sure that
> > it supports byte-wide access.
>
> Treat DataFlash like a block device? That sounds wrong to me.

Perhaps using the term block device is too loaded.  DataFlash is not
the same as memory mapped storage, but it's not the same as a CF card
or an IDE disk (in that it's not broken up into sectors).  However,
being non-memmapped makes it more similar to those devices than it is
to memmapped flash.

OTOH, the argument could be made that memory mapped flash isn't the
same either because while memmapped flash can be read from directly,
writing requires extra twiddling.  I'd be mad to suggest that
memmapped flash should be removed from the memory manipulation
commands.

Flash devices aren't too bad because all of them use the same
flash_write and addr2info hooks.  Right after them, however, there is
an mmc hook which does essentially the exact same thing.  DataFlash
falls into the same category.  (What kicked off this whole topic is
that I'm working on the md command which only has the DataFlash hook,
not the MMC or Flash hooks (and a flash hook wouldn't even make sense
for 'md').

Does anyone see any reason why these hooks couldn't be merged into a
single addr2info type call?  If the flash_info_t was modified to
include read/write function pointers and a private data pointer (move
a bunch of the parameters into a private data structure).  Boards can
provide a table including the various flash and non-memmapped devices
that are available.  A single hook would be enough to get the entry
for a particular address.

If I took this approach; it could be implemented in a staged approach,
starting with memmapped flash, and then merging in mmc and dataflash
support once the architecture is show to work.  It still leaves the
issue that it pretends mmc and dataflash devices are memory mapped
which I really don't like, but with a standard set of hooks, it may be
possible to just pass the raw string into addr2info instead of an
integer address, and collect all the parsing code in one place (ie.
use a "dev:addr" format as previously suggested)

>
> I understand your concerns about the #ifdef mess, but this suggestion
> does not sound tempting either.

That particular approach happens to be/was my preference, but it is
certainly not the only approach.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701261434l6289a3a4pa2b5464566e3a50a@mail.gmail.com> you wrote:
>
> Does anyone see any reason why these hooks couldn't be merged into a
> single addr2info type call?  If the flash_info_t was modified to

Code size?

We still want to and have to support U-Boot on systems where the image
MUST fit in 128 kB - with a somewhat reasonable feature-set.

Omitting the Dataflash stuff is simple at the moment, so please  make
sure  that  your  new  code  does  not grow for boards that don't use
Dataflash at all.

> If I took this approach; it could be implemented in a staged approach,
> starting with memmapped flash, and then merging in mmc and dataflash
> support once the architecture is show to work.  It still leaves the

Where would you stop? If you go this path, why not add CF and USB and
IDE as well? I'm not convinced that would be a good thing to do.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HANDLE WITH EXTREME CARE:  This Product Contains  Minute Electrically
Charged  Particles  Moving  at  Velocities  in Excess of Five Hundred
Million Miles Per Hour.

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
>
> Omitting the Dataflash stuff is simple at the moment, so please  make
> sure  that  your  new  code  does  not grow for boards that don't use
> Dataflash at all.

ok.  I'll hack something preliminary together and see what it ends up
looking like space wise.

>
> > If I took this approach; it could be implemented in a staged approach,
> > starting with memmapped flash, and then merging in mmc and dataflash
> > support once the architecture is show to work.  It still leaves the
>
> Where would you stop? If you go this path, why not add CF and USB and
> IDE as well? I'm not convinced that would be a good thing to do.

CF/USB/SCSI/IDE already have an abstraction layer; hence the original
idea of merging the other non-memory mapped devices into it.  But your
right; which devices does it make sense to merge into a single
interface?  I don't know, needs more thought.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Arm-linux-gcc malloc get failure while arm-elf-gcc ok

[Rui.Zhou at nokia.com]

 hi there

I wonder if I am the first one to get this problem

In common\lists.c

Handle NewHandle (unsigned int numBytes)
{
	void *memPtr;
	HandleRecord *hanPtr;

	memPtr = calloc (numBytes, 1);
	hanPtr = (HandleRecord *) calloc (sizeof (HandleRecord), 1);

Debug("memPtr:%d hanPtr:%d\n",memPtr ,hanPtr ); //arm-linux-gcc get 0
for both of the Ptr while arm-elf-gcc can malloc successfully

	if (hanPtr && (memPtr || numBytes == 0)) {
		hanPtr->ptr = memPtr;
		hanPtr->size = numBytes;
		return (Handle) hanPtr;
	} else {
		free (memPtr);
		free (hanPtr);
		return NULL;
	}

}

Arm-elf-gcc is 3.4.0
Arm-linux-gcc is 3.3.2 (heard there are most problems in this version??)

Regards
Zhou rui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070127/eaa7d44c/attachment.htm 

[U-Boot-Users] Arm-linux-gcc malloc get failure while arm-elf-gcc ok

[Rui.Zhou at nokia.com]

hi there
 
after modifing some codes(forget  what's the codes:() arm-elf-gcc also
get malloc failure,I have to think about my program has something wrong
 
actually malloc have got failure in the lib_arm/board.c:
 
a malloc will trigger *sbrk twice(why?)
test code in start_armboot()
...
void *testptr;
testptr=malloc(10);
...
 
 
in the void *sbrk (ptrdiff_t increment)
{
 ulong old = mem_malloc_brk;
 ulong new = old + increment;
 
 if ((new < mem_malloc_start) || (new > mem_malloc_end)) {
  return (NULL);
 }
 mem_malloc_brk = new;
 
 return ((void *) old);
}
 
 
I print out the debug information:
 
1st trigger:
 
increment:                a2e2e4e?(so big?)
old:                        c6dfc00
new:                        169c2a4e
mem_malloc_start:    c6dfc00
mem_malloc_end:    c700000
 
 
 
2nd:
 
increment:                1b2
old:                        c6dfc00
new:                        c6dfdb2
mem_malloc_start:    c6dfc00
mem_malloc_end:    c700000
 
seems the 2nd is ok
but testptr still =0
 
*****************
in the cpu/s3c44b0/start.S I create stack like that:
 
stack_setup:
 
ldr r0,=0xc700000   /* upper 128 KiB: relocated uboot   */
sub r0, r0, #CFG_MALLOC_LEN /* malloc area  1024+128*1024 =1227204bytes
*/
sub r0, r0, #CFG_GBL_DATA_SIZE /* bdinfo   128                     */
sub sp, r0, #12  /* leave 3 words for abort-stack    */
 
i think it should be ok
******************
 
regards,
rui
 

________________________________

From: u-boot-users-bounces@lists.sourceforge.net
[mailto:u-boot-users-bounces at lists.sourceforge.net] 
Sent: Saturday, January 27, 2007 12:11 PM
To: u-boot-users at lists.sourceforge.net
Subject: [U-Boot-Users] Arm-linux-gcc malloc get failure while
arm-elf-gcc ok



 hi there 

I wonder if I am the first one to get this problem 

In common\lists.c 

Handle NewHandle (unsigned int numBytes) 
{ 
        void *memPtr; 
        HandleRecord *hanPtr; 

        memPtr = calloc (numBytes, 1); 
        hanPtr = (HandleRecord *) calloc (sizeof (HandleRecord), 1); 

Debug("memPtr:%d hanPtr:%d\n",memPtr ,hanPtr ); //arm-linux-gcc get 0
for both of the Ptr while arm-elf-gcc can malloc successfully

        if (hanPtr && (memPtr || numBytes == 0)) { 
                hanPtr->ptr = memPtr; 
                hanPtr->size = numBytes; 
                return (Handle) hanPtr; 
        } else { 
                free (memPtr); 
                free (hanPtr); 
                return NULL; 
        } 

} 

Arm-elf-gcc is 3.4.0 
Arm-linux-gcc is 3.3.2 (heard there are most problems in this version??)


Regards 
Zhou rui 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20070127/fa7de896/attachment.htm 

[U-Boot-Users] Atmel DataFlash hooks.

[Andreas Schweigstill]

Hello!

Grant Likely schrieb:
> CF/USB/SCSI/IDE already have an abstraction layer; hence the original
> idea of merging the other non-memory mapped devices into it.  But your
> right; which devices does it make sense to merge into a single
> interface?  I don't know, needs more thought.

When we are thinking about a new Dataflash abstraction layer we should
also keep in mind that some new Dataflash components (AT45DBxxxD series)
contain features like the security register and sector locking which
also should be supported by the API. Other memory technologies,
especially SD/MMC, also provide such special features.

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BB54FB.2040904@schweigstill.de> you wrote:
> 
> When we are thinking about a new Dataflash abstraction layer we should
> also keep in mind that some new Dataflash components (AT45DBxxxD series)
> contain features like the security register and sector locking which
> also should be supported by the API. Other memory technologies,
> especially SD/MMC, also provide such special features.

... and to me this sounds is if it would fit better  in  the  set  of
flash  related  commands  (protect  etc.)  than  any  other  existing
interface.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.

[U-Boot-Users] Atmel DataFlash hooks.

[Andreas Schweigstill]

Hello!

Wolfgang Denk schrieb:
> ... and to me this sounds is if it would fit better  in  the  set  of
> flash  related  commands  (protect  etc.)  than  any  other  existing
> interface.

The flash related commands could work on an extension of the block
device layer. IDE/ATA drives also seem to have a means for provision of
drive geometry data to the file system driver or application (e.g. fdisk
under DOS/Windows/Linux). (Yes, I am just joking... :-) )

There is something what I really don't like about U-Boot's current
Dataflash implementation: after copying data to Dataflash using the
"cp.b" command the source data has been corrupted; it has been swapped
with the old contents of the Dataflash. The reason for this behaviour
can be found in the AT91F_SpiWrite() function (at45.c) which programs
the PDC to use the SPI transmit buffer address also as receive address.
Has anybody found out if it is possible to ignore the read data?

With best regards
Andreas Scheigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

Andreas Schweigstill wrote:
> Hello!
>
> Wolfgang Denk schrieb:
>> ... and to me this sounds is if it would fit better  in  the  set  of
>> flash  related  commands  (protect  etc.)  than  any  other  existing
>> interface.
>
> The flash related commands could work on an extension of the block
> device layer. IDE/ATA drives also seem to have a means for provision
> of drive geometry data to the file system driver or application (e.g.
> fdisk under DOS/Windows/Linux). (Yes, I am just joking... :-) )
>
> There is something what I really don't like about U-Boot's current
> Dataflash implementation: after copying data to Dataflash using the
> "cp.b" command the source data has been corrupted; it has been swapped
> with the old contents of the Dataflash. The reason for this behaviour
> can be found in the AT91F_SpiWrite() function (at45.c) which programs
> the PDC to use the SPI transmit buffer address also as receive
> address. Has anybody found out if it is possible to ignore the read
> data?

If you find that annoying, you can always generate a patch
which allocates a 1056 byte buffer and use that
as the receive buffer for all transfers.

>
> With best regards
> Andreas Scheigstill

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BB8611.5070900@schweigstill.de> you wrote:
>
> The flash related commands could work on an extension of the block
> device layer. IDE/ATA drives also seem to have a means for provision of
> drive geometry data to the file system driver or application (e.g. fdisk
> under DOS/Windows/Linux). (Yes, I am just joking... :-) )
;-)

> There is something what I really don't like about U-Boot's current
> Dataflash implementation: after copying data to Dataflash using the
> "cp.b" command the source data has been corrupted; it has been swapped
> with the old contents of the Dataflash. The reason for this behaviour

Arghhh.. That is indeed a bug, then.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real programmers don't comment their code. It was hard to  write,  it
should be hard to understand.

[U-Boot-Users] Atmel DataFlash hooks.

[Andreas Schweigstill]

Hello!

Wolfgang Denk schrieb:
>> There is something what I really don't like about U-Boot's current
>> Dataflash implementation: after copying data to Dataflash using the
>> "cp.b" command the source data has been corrupted; it has been swapped
>> with the old contents of the Dataflash. The reason for this behaviour
> 
> Arghhh.. That is indeed a bug, then.

Oh, since lots of people here are using U-Boot on AT91RM9200 I thought
that such behaviour was a feature. The really big problems occur when
using imxtract command because the multi-file image will be corrupted.
Also verifying the Dataflash contents becomes quite difficult when the
source has been overwritten.

So I suggest that the AT91F_SpiWrite() function has to be modified,
e.g. with a new parameter which determines if the source has to be
overwritten. How many applications have been written which depend on
the strange cp.b behaviour? Should there be an environment variable?
Hmmm.... bad idea.

With best regards
Andreas Schweigstill


-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BD4EA8.90206@schweigstill.de> you wrote:
> 
> Oh, since lots of people here are using U-Boot on AT91RM9200 I thought
> that such behaviour was a feature. The really big problems occur when

None of the AT91 systems I had under my fingers used dataflash.

> using imxtract command because the multi-file image will be corrupted.
> Also verifying the Dataflash contents becomes quite difficult when the
> source has been overwritten.

Indeed. It's simply a bug.

> So I suggest that the AT91F_SpiWrite() function has to be modified,
> e.g. with a new parameter which determines if the source has to be
> overwritten. How many applications have been written which depend on
> the strange cp.b behaviour? Should there be an environment variable?
> Hmmm.... bad idea.

No, this bug should be fixed, and no effort needs  to  be  wasted  on
bug-compatibility.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
He who hesitates is not only lost, but miles from the next exit.

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
>
> In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com> you wrote:
> >
> > My vote is to treat DataFlash like a block device, and make sure that
> > it supports byte-wide access.
>
> Treat DataFlash like a block device? That sounds wrong to me.

I've been thinking about this some more, and I'm not sure I agree.

Just for the moment; forget the term 'block device' and forget about
the current implementation of u-boot.  How significant are the
difference between the following devices? mmc, CF, IDE HD, SCSI HD,
DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage.
Here's my short list:
- different block sizes; DataFlash can be written byte at a time;
while other devices have minimum write sizes.  Some devices need
blocks to be specifically erased before rewriting.
- memmapped flash can be be read directly on the memory bus; but
writing requires a special routine
- Large variation of size, from a few kbytes up to thousands of gigabytes.
- Some devices are typically partitioned for convenience
- speed differences
- large number of

The technology varies wildly, but they are all storage devices which
store of an ordered sequence of bytes.  In every device, the address
of a single item of data can be boiled down to a single integer.

Take a look at the following interface.  For *most* commands; how well
does this is this api encapsulate those differences for common
commands?  Assume that device specific commands still exist for things
that don't fit well into the model.  ie. block erase and protect
commands.

open(device) # Prepare for read/write operation
seek(distance, abs_flag)  # Relative or absolute seek
read(buffer, count)
write(buffer, count)
close() # Operation finished; sync any pending buffers back to disk.
Notes:
   - assume device can only be opened once.  ie. it's a bug to call open() twice
   - this could be used by commands like mm, md, bootm, etc.  I'm not
trying to design a full control interface (protect, erase, etc).
   - common commands would typically call open(), seek(),
read/write(), read/write(), ..., close() before returning to user.
ie. device would *not* be left open after command completes.
   - should be suitable for partition access too
   - read/write commands are expected to transparently handle block
boundaries.  ie. if one byte is written to the middle of a block; the
write hook should read the block, modify the byte, and keep it
buffered until it either a read/write/seek() moves to another sector,
or close() is called.
   - and yes, I'm just using the each device as a file perspective.
It's a well established abstraction, so why not here too?

I think this is a reasonable approach to provide a common interface
without making device specific side cases too complex to deal with.
Adding new device support to all commands becomes pretty trivial this
way.

Thoughts?  Feel free to tell me if I'm flying too high in the
stratosphere on this one.
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hello All,
Grant Likely wrote:

>On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
>  
>
>>In message <528646bc0701261111i6f0dcb0i96f81259b3a4311d@mail.gmail.com> you wrote:
>>    
>>
>>>My vote is to treat DataFlash like a block device, and make sure that
>>>it supports byte-wide access.
>>>      
>>>
>>Treat DataFlash like a block device? That sounds wrong to me.
>>    
>>
>
>I've been thinking about this some more, and I'm not sure I agree.
>  
>
>Just for the moment; forget the term 'block device' and forget about
>the current implementation of u-boot.  How significant are the
>difference between the following devices? mmc, CF, IDE HD, SCSI HD,
>DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage.
>  
>
<snip>

>It's a well established abstraction, so why not here too?
>
>I think this is a reasonable approach to provide a common interface
>without making device specific side cases too complex to deal with.
>Adding new device support to all commands becomes pretty trivial this
>way.
>
>Thoughts?  Feel free to tell me if I'm flying too high in the
>stratosphere on this one.
>g.
>
>  
>
I think Grant has a good point. The discussion about abstractions used 
to read/write devices and memory is
really a discussion about a memory hierarchy. If we treat it this way, 
it is possible to optionally give everybody
what they want while still allowing a "minimal" u-boot configuration for 
people who do not desire a particular
feature of the "storage hierarchy". Suppose we have an abstraction that 
treats CF, IDE HD, DataFlash,
memmapped flash etc. as a device. We also have a set of commands that  
read/write to these devices. There
will be a protect command that does nothing on devices that do not 
understand this command. This way, it
is possible to read/write from any "device" to system ram. A driver to 
treat system ram as a device could also
be compiled into u-boot.
As Grant discussed in an earlier part of this thread, we can also modify 
the current memory commands such that
there is a table of what I will call "mmapped address". If the mmapped 
support is enabled, all memory commands
will pass through a routine that splits them up into sub-commands that 
operate on addresses in single parts of the
mmapped address table for both source and destination. This would 
include breaking the commands into "sector-sized"
operations based on an entry for the sector size in the table. 
Non-sectored devices can use all 1s for the sector size.
The memory commands now would consist of a seek/read from one "device" 
followed by seek and read or write
from another device. If necessary, buffering would be provided by two 
dedicated buffers in the memory command
subsystem.
This "mmapped"  table already basically exists in the current memory 
access system, with almost the right things in it.
Ram/Rom/Flash that has CPU memory  bus addresses appears at the 
"natural" addresses in this table that are
actually occupied by the "media". Unoccupied memory bus addresses are 
assigned to media that does not actually
appear on the bus. This is presently done manually  The memory commands 
would then be executed by calling routines
from the mmapped table to do the reads and writes. These routines should 
use the same I/O routines as are used for
device-mode access.
If the user wants to maintain the ability to operate with memory 
commands on bus-addressed memory of any kind,
it is simple to initialize the mmapped address table appropriately. 
u-boot can also add entries to this table at start-up
if some kind of flash is dynamically detected. This feature also 
provides a natural way to extend this type of support
to any device that can read/write/seek. The user can either build-in 
address ranges/device mappings at u-boot
compile time, they can be dynamically detected, and/or a console command 
(mmap?) could be optionally added to do
dynamically.  If the user does not want this type of support, it can be 
completely omitted from the u-boot build and all
memory type commands will be executed using the CPU ram read/write 
routines and addresses.
I think this approach gives everybody what they want. In cases where 
"normal" ram and device access to a few devices
is all that is desired, u-boot would probably be slightly smaller than 
it is now. If mmapped support is included, it might be very
slightly larger, but probably not by much. The mmapped table would 
contain more information than it does at present,
but only a "few" more items per entry.

Comments welcome. I don't think this is really a big change from the 
current system, it is just a formalization of what
has always been desired.

Best Regards,
Bill Campbell

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BC0099.3070706@comcast.net> you wrote:
>
> understand this command. This way, it
> is possible to read/write from any "device" to system ram. A driver to 
> treat system ram as a device could also
> be compiled into u-boot.

It certainly could. BUt IMHO it does  not  ake  sense  to  require  a
driver  to  access  RAM  (!)  when a "*pointer" is all that's needed.
We're  talking  aboth  the  difference  between  a   single   machine
instruction versus calls to several complex functions here!

Please let's keep the code as small, and as simple, as possible. 

> If the user wants to maintain the ability to operate with memory 
> commands on bus-addressed memory of any kind,
> it is simple to initialize the mmapped address table appropriately. 

Folks, please, do me a favour: before you continue, go and  read  the
U-Boot  code  and  make  a  list  what  needs  to  be done on all the
different boards even before we have a working C environment.

Be aware, that your rewrite  (1)  will  have  to  support  all  these
features,  too,  (2)  must  not  (significantly)  increase the memory
footprint for existing configurations which don't need  any  features
added,  and  (2)  will  have to run in such a restricted environment,
where you probably cannot even allocate a 512 byte buffer for I/O.

I don't want to stop you, but please keep  the  environment  in  mind
where your code has to fit in.

> dynamically.  If the user does not want this type of support, it can be 
> completely omitted from the u-boot build and all
> memory type commands will be executed using the CPU ram read/write 
> routines and addresses.

??? I don;t see how this would be possible if I understand hwta GRand
and you have in mind. At least not without adding yet another  #ifdef
maze.

> I think this approach gives everybody what they want. In cases where 
> "normal" ram and device access to a few devices
> is all that is desired, u-boot would probably be slightly smaller than 
> it is now. If mmapped support is included, it might be very

I can't see how you would get the standard  configuration  (just  RAM
and NOR flash support) smaller with such a change?

> Comments welcome. I don't think this is really a big change from the 
> current system, it is just a formalization of what
> has always been desired.

Umm... "always been desired" - by whom? :-)

You probably remember our old discussion about ENV_IS_EMBEDDED from a
year or so ago - do you? This is another similar  area.  The  current
code  is  not  flexible  and ugly, but all the configuration and code
selection is done at compile time, which  means  we  have  a  minimal
memory footprint.

U-Boot is a boot loader. Keep is small and simple.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
                                  - Terry Pratchett, _Witches Abroad_

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hi All,

Wolfgang Denk wrote:

>In message <45BC0099.3070706@comcast.net> you wrote:
>  
>
>>understand this command. This way, it
>>is possible to read/write from any "device" to system ram. A driver to 
>>treat system ram as a device could also
>>be compiled into u-boot.
>>    
>>
>
>It certainly could. BUt IMHO it does  not  ake  sense  to  require  a
>driver  to  access  RAM  (!)  when a "*pointer" is all that's needed.
>We're  talking  aboth  the  difference  between  a   single   machine
>instruction versus calls to several complex functions here!
>
>Please let's keep the code as small, and as simple, as possible. 
>
>  
>
Agreed. I only pointed out this could be done if for some reason a user 
required complete symmetry in access to all system resources. I don't, 
and probably nobody would, but just in case it was required for some 
reason I can't see right now, it is possible. The code would be small, 
in that a read would just return a pointer to the data already in ram, 
and a write would be just a " memcpy", but it would not be no code at all.

>>If the user wants to maintain the ability to operate with memory 
>>commands on bus-addressed memory of any kind,
>>it is simple to initialize the mmapped address table appropriately. 
>>    
>>
>
>Folks, please, do me a favour: before you continue, go and  read  the
>U-Boot  code  and  make  a  list  what  needs  to  be done on all the
>different boards even before we have a working C environment.
>
>Be aware, that your rewrite  (1)  will  have  to  support  all  these
>features,  too,  (2)  must  not  (significantly)  increase the memory
>footprint for existing configurations which don't need  any  features
>added,  and  (2)  will  have to run in such a restricted environment,
>where you probably cannot even allocate a 512 byte buffer for I/O.
>
>I don't want to stop you, but please keep  the  environment  in  mind
>where your code has to fit in.
>
>  
>
I think you are correct here. Naturally, I have been looking at the code 
in this process, but a complete list, or better yet, a proposed patch, 
would allow this comparison and trade-off to be more simply evaluated. I 
believe that the "restricted environment" caveat above certainly applies 
to reading the environment data before relocation. I am not presently 
aware of other times where this is true, but if  there are any, I need 
to find them! Places where there are any other accesses, or writes that 
take place before relocation could be problems. If you know of any, 
pointers to general areas would be appreciated! At present, the 
CFG_ENV_IS_IN_XXX options are limited to certain devices. I do not 
propose to increase that list unless/until everything else involved is 
working! I notice that the DataFlash routine does allocate a 64 byte 
buffer on the stack to speed up CRC checking the environment, which I 
assume is still OK. There IS a lot of work required to co-ordinate all 
the read/write routines involved in such a proposed change, but these 
routines do already exist.

>>dynamically.  If the user does not want this type of support, it can be 
>>completely omitted from the u-boot build and all
>>memory type commands will be executed using the CPU ram read/write 
>>routines and addresses.
>>    
>>
>
>??? I don;t see how this would be possible if I understand hwta GRand
>and you have in mind. At least not without adding yet another  #ifdef
>maze.
>
>  
>
I certainly do not want to add many more #ifdefs to make this happen. 
Once again, probably only a proposed patch can resolve this question

>>I think this approach gives everybody what they want. In cases where 
>>"normal" ram and device access to a few devices
>>is all that is desired, u-boot would probably be slightly smaller than 
>>it is now. If mmapped support is included, it might be very
>>    
>>
>
>I can't see how you would get the standard  configuration  (just  RAM
>and NOR flash support) smaller with such a change?
>
>  
>
There are presently quite a few #ifdefs involved in cmd_mem.c and 
cmd_load.c to take different memory types into consideration. These 
would mostly go away. That is why I think a ram + flash configuration 
with CFG_NO_FLASH defined  (which would be #ifndef CFG_MMAP_DEVICES in 
my proposed approach) and a FLASH READ/FLASH WRITE  commands  added to 
cmd_flash.c would be slightly smaller than the present minimum 
configuration. Naturally, you loose the ability to dump flash data with 
md, compare to flash data with cmp, copy flash data with cp.b, load data 
directly to flash with loadb, etc. so it is not free, just a bit smaller.

>  
>
>>Comments welcome. I don't think this is really a big change from the 
>>current system, it is just a formalization of what
>>has always been desired.
>>    
>>
>
>Umm... "always been desired" - by whom? :-)
>
>  
>
Well, as I understood it, at least partially by you. :-) The ability to 
use memory oriented commands on memory other than simple ram seems to be 
considered a plus by many u-boot community members. However, this does 
add some complexity and size to the associated memory manipulation 
commands. As the object being addressed differs more and more from 
simple ram, more and more people seem to accept "new" commands to read 
and write these objects, and to forgo the advantages/features of the 
memory commands. This becomes especially true when the size of the 
object to be read/written exceeds the size of the CPU address space. 
What my goal in this proposed design is to allow users to choose at 
compile time what features are desired for the u-boot memory commands  
a) without an ifdef maze and b) without needing to inject new code into 
cmd_mem.c and cmd_load.c for every different memory technology that will 
use memory access type commands. If somebody wants to use the memory 
commands on a serial EEPROM, this can be made to work if desired, or not 
made to work if not considered necessary, without changing cmd_mem.c.  
How possible/good this goal is remains to be seen, I agree. The current 
system  has some implicit and some explicit requirements on memory 
operands. I will try to be either no more restrictive or less 
restrictive in any changes I propose.

>You probably remember our old discussion about ENV_IS_EMBEDDED from a
>year or so ago - do you? This is another similar  area.  The  current
>code  is  not  flexible  and ugly, but all the configuration and code
>selection is done at compile time, which  means  we  have  a  minimal
>memory footprint.
>
>U-Boot is a boot loader. Keep is small and simple.
>  
>
I completely  agree with small and simple, and making feature choices at 
compile time. I think these attributes can be preserved, or perhaps 
enhanced,  in cmd_mem and cmd_load, but naturally you will be the judge 
of the results! I am also very aware of the testing problems that can 
arise from the possible changes.

Best Regards,
Bill Campbell

>Best regards,
>
>Wolfgang Denk
>
>  
>

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BD21D7.20203@comcast.net> you wrote:
> 
> >I can't see how you would get the standard  configuration  (just  RAM
> >and NOR flash support) smaller with such a change?
> >
> There are presently quite a few #ifdefs involved in cmd_mem.c and 
> cmd_load.c to take different memory types into consideration. These 
> would mostly go away. That is why I think a ram + flash configuration 

OK, so the *source* code may become smaller indeed.  But  I'd  expect
the  memory  footprint  on  the target system to grow instead, or you
lose functionality.

> configuration. Naturally, you loose the ability to dump flash data with 
> md, compare to flash data with cmp, copy flash data with cp.b, load data 
> directly to flash with loadb, etc. so it is not free, just a bit smaller.

Arghhh... Indeed, that's not free. I guess for such a price there are
other, more efficient ways to reduce the code size.

> >>current system, it is just a formalization of what
> >>has always been desired.
> >
> >Umm... "always been desired" - by whom? :-)
> >
> Well, as I understood it, at least partially by you. :-) The ability to 
> use memory oriented commands on memory other than simple ram seems to be 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> considered a plus by many u-boot community members. However, this does 

Read what you wrote: "use memory oriented commands on memory". That's
exactly what I really expect to be able to do, indeed.

Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
contents? 

> add some complexity and size to the associated memory manipulation 
> commands. As the object being addressed differs more and more from 

Not really. Normally only writing may need special handling.

I can't say if Dataflash really fits into this szenario; I never used
this feature myself.

> simple ram, more and more people seem to accept "new" commands to read 
> and write these objects, and to forgo the advantages/features of the 
> memory commands. This becomes especially true when the size of the 
> object to be read/written exceeds the size of the CPU address space. 

Do you have an example where this happens in U-Boot context?

> What my goal in this proposed design is to allow users to choose at 
> compile time what features are desired for the u-boot memory commands  
> a) without an ifdef maze and b) without needing to inject new code into 
> cmd_mem.c and cmd_load.c for every different memory technology that will 
> use memory access type commands. If somebody wants to use the memory 
> commands on a serial EEPROM, this can be made to work if desired, or not 

I feel that would be not natural. And EEPROM (like on a I2C bus) does
not have any natural adresses in the CPU's address  space.  Same  for
IDE  or  USB  devices.  These are storage devices on some form of I/O
bus, but certainly NOT memory.

> made to work if not considered necessary, without changing cmd_mem.c.  
> How possible/good this goal is remains to be seen, I agree. The current 

IMHO we should provide a user inteface which is powerful, yet easy to
use - this requires it must be intuitive to the end user. For most  f
them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
EEPROM is not.

> I completely  agree with small and simple, and making feature choices at 
> compile time. I think these attributes can be preserved, or perhaps 

Ther eis another thing that is important to me: U-Boot  on  different
systems,  boards  and architectures shall always behave as similar as
possible. Having the "cmp" command (if configured into  U-Boot)  work
on  flash  memory  on  one system and failing to do so on another one
seems unacceptable to me.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
C makes it easy for you to shoot yourself in the foot. C++ makes that
harder, but when you do, it blows away your whole leg.
                                                 -- Bjarne Stroustrup

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/28/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <45BD21D7.20203@comcast.net> you wrote:
> > What my goal in this proposed design is to allow users to choose at
> > compile time what features are desired for the u-boot memory commands
> > a) without an ifdef maze and b) without needing to inject new code into
> > cmd_mem.c and cmd_load.c for every different memory technology that will
> > use memory access type commands. If somebody wants to use the memory
> > commands on a serial EEPROM, this can be made to work if desired, or not
>
> I feel that would be not natural. And EEPROM (like on a I2C bus) does
> not have any natural adresses in the CPU's address  space.  Same  for
> IDE  or  USB  devices.  These are storage devices on some form of I/O
> bus, but certainly NOT memory.

This is the exact category that MMC and DataFlash devices are in (both
accessed via SPI).  Yet they are both accessible by commands in
cmd_mem.c.

> IMHO we should provide a user inteface which is powerful, yet easy to
> use - this requires it must be intuitive to the end user. For most  f
> them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
> EEPROM is not.

Right; so what do we do with MMC and DataFlash?

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701281850n4b4fa2b1x7022b4daf9bfe89a@mail.gmail.com> you wrote:
>
> This is the exact category that MMC and DataFlash devices are in (both
> accessed via SPI).  Yet they are both accessible by commands in
> cmd_mem.c.

I have never used DataFlash nor MMC. Maybe the interface  was  really
badly  chosen.  From  the description I got from the implementor when
the Dataflash patches went in it sounded OK to me.

> > IMHO we should provide a user inteface which is powerful, yet easy to
> use - this requires it must be intuitive to the end user. For most  f
> > them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
> > EEPROM is not.
> 
> Right; so what do we do with MMC and DataFlash?

So far I hear only discussion from developers.

Are there any users of Dataflah and MCC here? What  is  your  opinion
about the current user interface, abd about the suggested changes?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
All your people must learn before you can reach for the stars.
	-- Kirk, "The Gamesters of Triskelion", stardate 3259.2

[U-Boot-Users] Atmel DataFlash hooks.

[Haavard Skinnemoen]

On 1/29/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701281850n4b4fa2b1x7022b4daf9bfe89a@mail.gmail.com> you wrote:

> > > IMHO we should provide a user inteface which is powerful, yet easy to
> > use - this requires it must be intuitive to the end user. For most  f
> > > them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
> > > EEPROM is not.
> >
> > Right; so what do we do with MMC and DataFlash?
>
> So far I hear only discussion from developers.
>
> Are there any users of Dataflah and MCC here? What  is  your  opinion
> about the current user interface, abd about the suggested changes?

I'm not sure if I understand. U-boot pretends mmc and DataFlash are
memory mapped? That sounds completely insane, especially for MMC. What
happens if you insert an 8GB SD card on a 32-bit host?

I haven't actually used DataFlash on any avr32 boards yet, but I have
written an MMC driver for it and I didn't even know it could be
accessed as a memory-mapped device. In fact, I can't even understand
why anyone would want that -- the main usage of an MMC or SD card is
to put a filesystem (usually FAT, but you can use pretty much
anything) on it and use it for storage.

I guess DataFlash makes slightly more sense to access this way, but I
still think the interface is totally unintuitive.

So, even though I'm technically more of a developer than a user,
consider this a vote in favour of ripping the stuff out. Unless of
course lots of users depend on stuff working this way. I highly doubt
it since it doesn't even work properly (yes, the MMC stuff too; the
mmc2info function on pxa is a total hack which only works for 32MB
cards.)

H?vard

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>
> I'm not sure if I understand. U-boot pretends mmc and DataFlash are
> memory mapped? That sounds completely insane, especially for MMC. What
> happens if you insert an 8GB SD card on a 32-bit host?
>
>   
There is nothing to stop U-Boot memory commands from implementing a 64
bit virtual address space.
(The day that you have an 8GB Dataflash, Champagne corks will
fly.Largest one today is 8 MB)

> I haven't actually used DataFlash on any avr32 boards yet, but I have
> written an MMC driver for it and I didn't even know it could be
> accessed as a memory-mapped device. In fact, I can't even understand
> why anyone would want that -- 

The reason to memory map is that then it is easy to do memory commands
like copy, compare etc, which you do want to do on dataflash, even
though it is not fully implemented in the current mainstream.
I have implemented additional functions, because they are really needed.
I wrote them because it is such a pain to copy to RAM before you can
compare,
and I definitely do not like to have to start doing that again.

It is perfectly possible to memory map the dataflash without having a lot
of ifdefs, by letting the memory commands call a driver.
I believe this is the way forward.

It is easier for a user to learn a single command set to handle flash
regardless of type.

MMC/SD/USB Memories have the advantage of beeing able to be read/written
by the host, and this advantage makes it more natural to use a real file
system.


> the main usage of an MMC or SD card is
> to put a filesystem (usually FAT, but you can use pretty much
> anything) on it and use it for storage.
>
> I guess DataFlash makes slightly more sense to access this way, but I
> still think the interface is totally unintuitive.
>
> So, even though I'm technically more of a developer than a user,
> consider this a vote in favour of ripping the stuff out. Unless of
> course lots of users depend on stuff working this way. I highly doubt
> it since it doesn't even work properly (yes, the MMC stuff too; the
> mmc2info function on pxa is a total hack which only works for 32MB
> cards.)
>
> H?vard
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   


-- 
Best Regards,
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com 
links: www.avrfreaks.net; www.at91.com; avr32linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070129/050570ee/attachment.vcf 

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BE7BC7.8030704@atmel.com> you wrote:
> 
> There is nothing to stop U-Boot memory commands from implementing a 64
> bit virtual address space.

There is. Not something, but someone. Me.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot-Users] Atmel DataFlash hooks.

[Haavard Skinnemoen]

On 1/29/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>
> >
> > I'm not sure if I understand. U-boot pretends mmc and DataFlash are
> > memory mapped? That sounds completely insane, especially for MMC. What
> > happens if you insert an 8GB SD card on a 32-bit host?
> >
> >
> There is nothing to stop U-Boot memory commands from implementing a 64
> bit virtual address space.

Except that for most (all?) CPUs supported by u-boot, the virtual
address space _isn't_ 64 bit.

> (The day that you have an 8GB Dataflash, Champagne corks will
> fly.Largest one today is 8 MB)

Yeah, that's why I said it makes slightly more sense to do this with
DataFlash than with MMC. But I'm guessing that whoever implemented the
memory mapped MMC thing didn't expect MMC cards to reach 8 GB  any
time soon either.

> > I haven't actually used DataFlash on any avr32 boards yet, but I have
> > written an MMC driver for it and I didn't even know it could be
> > accessed as a memory-mapped device. In fact, I can't even understand
> > why anyone would want that --
>
> The reason to memory map is that then it is easy to do memory commands
> like copy, compare etc, which you do want to do on dataflash, even
> though it is not fully implemented in the current mainstream.
> I have implemented additional functions, because they are really needed.
> I wrote them because it is such a pain to copy to RAM before you can
> compare,
> and I definitely do not like to have to start doing that again.

I agree that the functionality is needed. I just disagree with the interface.

> It is perfectly possible to memory map the dataflash without having a lot
> of ifdefs, by letting the memory commands call a driver.
> I believe this is the way forward.
>
> It is easier for a user to learn a single command set to handle flash
> regardless of type.

How do you teach the user that the DataFlash is mapped at some obscure
address that has absolutely nothing to do with reality? What address
is it mapped at anyway? I can't find any information about this in the
README...

Extending the memory commands to take a prefix specifying which
address space you're talking about would make a lot more sense,
though. Then it might make sense to use 64-bit offsets too since we're
not really talking about the CPU's address space anymore, although it
could be difficult to support offsets of different size with a single
command.

Maybe it would be better to create a different set of commands for
manipulating any kind of raw storage (including flash) and let the
memory commands deal with memory.

> MMC/SD/USB Memories have the advantage of beeing able to be read/written
> by the host, and this advantage makes it more natural to use a real file
> system.

Exactly. It's just absurd to pretend removable storage devices reside
in physical memory.

Haavard

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <1defaf580701291628s572e1092re30ea906140e2a30@mail.gmail.com> you wrote:
>
> Maybe it would be better to create a different set of commands for
> manipulating any kind of raw storage (including flash) and let the
> memory commands deal with memory.

Exclude flash here, and we already have  such  an  interface:
"<bus> read ..." and "<bus> write", for example "eeprom read" or
"ide read" or "usb read" or ...

> Exactly. It's just absurd to pretend removable storage devices reside
> in physical memory.

Not per se. We could want to support removable  memory  modules  (hot
swap RAM - now that would be fun :-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Carelessly planned projects take three times longer to complete  than
expected.  Carefully  planned  projects  take  four  times  longer to
complete than expected, mostly  because  the  planners  expect  their
planning to reduce the time it takes.

[U-Boot-Users] Atmel DataFlash hooks.

[Haavard Skinnemoen]

On 1/30/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <1defaf580701291628s572e1092re30ea906140e2a30@mail.gmail.com> you wrote:
> >
> > Maybe it would be better to create a different set of commands for
> > manipulating any kind of raw storage (including flash) and let the
> > memory commands deal with memory.
>
> Exclude flash here, and we already have  such  an  interface:
> "<bus> read ..." and "<bus> write", for example "eeprom read" or
> "ide read" or "usb read" or ...

Ah, how come there's no "mmc read" and "mmc write"?

Btw, flash isn't entirely excluded as nand flash seems to use the same
interface.

> > Exactly. It's just absurd to pretend removable storage devices reside
> > in physical memory.
>
> Not per se. We could want to support removable  memory  modules  (hot
> swap RAM - now that would be fun :-)

Yeah, of course. I really meant storage devices that aren't actually
behaving like physical memory.

Haavard

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <1defaf580701291716q431730b4t65bc4b531b351e5@mail.gmail.com> you wrote:
>
> > Exclude flash here, and we already have  such  an  interface:
> > "<bus> read ..." and "<bus> write", for example "eeprom read" or
> > "ide read" or "usb read" or ...
> 
> Ah, how come there's no "mmc read" and "mmc write"?

Dunno. This code was "not invented here" ;-)

> Btw, flash isn't entirely excluded as nand flash seems to use the same
> interface.

Right. Please understand memory as  something  which  is  addressable
through the CPU's address bus.

> Yeah, of course. I really meant storage devices that aren't actually
> behaving like physical memory.

We agree on that.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Cleverness and Style have no place in getting a project completed.
                                                  -- Tom Christiansen

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

Haavard Skinnemoen skrev:
> On 1/29/07, Ulf Samuelsson <ulf@atmel.com> wrote:
>   
>>> I'm not sure if I understand. U-boot pretends mmc and DataFlash are
>>> memory mapped? That sounds completely insane, especially for MMC. What
>>> happens if you insert an 8GB SD card on a 32-bit host?
>>>
>>>
>>>       
>> There is nothing to stop U-Boot memory commands from implementing a 64
>> bit virtual address space.
>>     
>
> Except that for most (all?) CPUs supported by u-boot, the virtual
> address space _isn't_ 64 bit.
>
>   
>> (The day that you have an 8GB Dataflash, Champagne corks will
>> fly.Largest one today is 8 MB)
>>     
>
> Yeah, that's why I said it makes slightly more sense to do this with
> DataFlash than with MMC. But I'm guessing that whoever implemented the
> memory mapped MMC thing didn't expect MMC cards to reach 8 GB  any
> time soon either.
>
>   
>>> I haven't actually used DataFlash on any avr32 boards yet, but I have
>>> written an MMC driver for it and I didn't even know it could be
>>> accessed as a memory-mapped device. In fact, I can't even understand
>>> why anyone would want that --
>>>       
>> The reason to memory map is that then it is easy to do memory commands
>> like copy, compare etc, which you do want to do on dataflash, even
>> though it is not fully implemented in the current mainstream.
>> I have implemented additional functions, because they are really needed.
>> I wrote them because it is such a pain to copy to RAM before you can
>> compare,
>> and I definitely do not like to have to start doing that again.
>>     
>
> I agree that the functionality is needed. I just disagree with the interface.
>
>   
>> It is perfectly possible to memory map the dataflash without having a lot
>> of ifdefs, by letting the memory commands call a driver.
>> I believe this is the way forward.
>>
>> It is easier for a user to learn a single command set to handle flash
>> regardless of type.
>>     
>
> How do you teach the user that the DataFlash is mapped at some obscure
> address that has absolutely nothing to do with reality? What address
> is it mapped at anyway? I can't find any information about this in the
> README...
>   
I have not seen a single customer complain about the fact that
a serial flash is memory mapped.
The customers are informed about the memory map
of the board in the board documentation.
If the  interface is changed, then this board documentation will have to
change.

Alternatively the board documentation will have to document two different
command sets for handling dataflash, depending on which version
of u-boot is on the board.
I am convinced that this is going to cause all sorts of confusion at the
customers.

This simple point is key to why I think that the interface to the dataflash
should remain as it is.

If the internal implementation changes to something more maintainable
I do not have a problem with that, as long as it is tested.
I do have a problem with the approach:
"let's change the interface, and leave the debugging to someone who cares
about whether it works or not".

I know that Atmel's AT91 department does not want to spend any time
on U-Boot right now so who will test the fixes for dataflash?

> Extending the memory commands to take a prefix specifying which
> address space you're talking about would make a lot more sense,
> though. 

If you only see dataflash as an extra storage device then you might
have a point, in my world it is quite often the only device
and I do not see any need to have any prefix.

Computers are good at computation and humans does not like typing.
I am sure that noone wants to have a prefix for accessing their
normal parallell flash memory and I think anyone that do not want
to have such a prefix, should have respect for those that
do not want to have a prefix for accessing their only (serial) flash.


On the memory map:  I think this is up to the implementor.
In AT91 U-Boot AT45/dataflash drivers you have the following mapping :
* chip select 0 maps to 0xC000_0000
* chip select 1 maps to 0xD000_0000

> Then it might make sense to use 64-bit offsets too since we're
> not really talking about the CPU's address space anymore, although it
> could be difficult to support offsets of different size with a single
> command.
>
> Maybe it would be better to create a different set of commands for
> manipulating any kind of raw storage (including flash) and let the
> memory commands deal with memory.
>
>   
>> MMC/SD/USB Memories have the advantage of beeing able to be read/written
>> by the host, and this advantage makes it more natural to use a real file
>> system.
>>     
>
> Exactly. It's just absurd to pretend removable storage devices reside
> in physical memory.
>
> Haavard
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   


-- 
Best Regards,
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com 
links: www.avrfreaks.net; www.at91.com; avr32linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070130/f6048a93/attachment.vcf 

[U-Boot-Users] Atmel DataFlash hooks.

[Tolunay Orkun]

So far I have been staying out of this thread. But I felt maybe my $0.02 
could be useful in this discussion.

I personally feel like existing commands should work on future devices. 
However, assuming not every memory can be mapped to processor memory 
space directly I propose prefixing the addresses with an a"ddress space 
tag" or simply tag (expanding from original similar suggestion).

For example,

cp.b 0xfff00000 tag:0x00002000 2000

The tag would be defined by board designer as appropriate for the 
particular board. For example, it could be "sd1", "sd2", "eeprom", 
"hdd". In this case, "sd1", "sd2" could be referring different instances 
of the same type of device (say sd/mmc memory).

I am envisioning associated with the "tag" the board designer maps a 
technology driver "dataflash", "mmc", "ide", etc. This approach could 
even give us the opportunity to use window mapped flash devices (i.e. 
flash is mapped into memory smaller than total device size) etc. This 
approach would also not modify the user experience significantly. U-Boot 
commands could be developed cleanly and the commands would uniformly use 
a limited number of accessors provided by the technology drivers. This 
could help eliminate the #ifdef maze and remove inconsistencies between 
commands which have been mentioned in the previous posts of this thread. 
I think in addition to ram, we can  support regular nor flash that is 
directly mapped to address space as before (grandfathered).If a command 
could not be supported on a device (like protect on/off) the command 
would issue an error if issued for incompatible device/memory space.

What do you think?

Tolunay

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Hi Mr. Denk,
    You are up late this Sunday night. Probably you will not see this 
until Monday morning!

Wolfgang Denk wrote:

>In message <45BD21D7.20203@comcast.net> you wrote:
>  
>
>>>I can't see how you would get the standard  configuration  (just  RAM
>>>and NOR flash support) smaller with such a change?
>>>
>>>      
>>>
>>There are presently quite a few #ifdefs involved in cmd_mem.c and 
>>cmd_load.c to take different memory types into consideration. These 
>>would mostly go away. That is why I think a ram + flash configuration 
>>    
>>
>
>OK, so the *source* code may become smaller indeed.  But  I'd  expect
>the  memory  footprint  on  the target system to grow instead, or you
>lose functionality.
>  
>
You lose functionality as outlined below. The memory footprint is 
smaller though. Not that that is a big advantage anyway, I just wanted 
to assert it didn't get larger.

>  
>
>>configuration. Naturally, you loose the ability to dump flash data with 
>>md, compare to flash data with cmp, copy flash data with cp.b, load data 
>>directly to flash with loadb, etc. so it is not free, just a bit smaller.
>>    
>>
>
>Arghhh... Indeed, that's not free. I guess for such a price there are
>other, more efficient ways to reduce the code size.
>  
>
Probably. However the fact it gets no larger could be important.

>  
>
>>>>current system, it is just a formalization of what
>>>>has always been desired.
>>>>        
>>>>
>>>Umm... "always been desired" - by whom? :-)
>>>
>>>      
>>>
>>Well, as I understood it, at least partially by you. :-) The ability to 
>>use memory oriented commands on memory other than simple ram seems to be 
>>    
>>
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>  
>
>>considered a plus by many u-boot community members. However, this does 
>>    
>>
>
>Read what you wrote: "use memory oriented commands on memory". That's
>exactly what I really expect to be able to do, indeed.
>
>Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
>contents?
>
You should. However, in the current u-boot, if you try these commands 
with Dataflash addresses, crc takes the crc of some random data, you get 
an error message saying it is not supported for cmp, and it works 
correctly for md (because there is explicit code to support it compiled 
in if Dataflash is present). There is also a device MMC which is 
included in some builds. As near as I can tell, it does not work in any 
of the read operations, there is no code built-in for it as a special case.

> 
>
>  
>
>>add some complexity and size to the associated memory manipulation 
>>commands. As the object being addressed differs more and more from 
>>    
>>
>
>Not really. Normally only writing may need special handling.
>  
>
True enough. Yet the only memory write command that explicitly works on 
flash memory is cp.  mw does not check for a flash address, so what it 
does depends on the protect state of the chip and how the flash works. 
Some flash lets you change a single byte, others require various erase 
operations and so on. The rule here may be know what you are doing 
before you try to modify flash one byte at a time, but it is an 
asymmetry. I won't even hazard a guess at what loopw will do, but I am 
sure its not a good idea on flash. The MMC case is also not provided for 
at all.

>I can't say if Dataflash really fits into this szenario; I never used
>this feature myself.
>  
>
It does not, and probably is an example of why this is an issue to some 
of us. Dataflash requires a routine to read the data as well as to write 
it. Most of the memory read routines work fine on any memory technology 
that has a one-to-one bus address to data technology. Dataflash does not 
fit this model and therefore doesn't work in many read operations. In 
some cases you get an error, because it is explicitly handled in the 
code, in some cases you get a bogus result and no error. As near as I 
can determine, the MMC also requires a routine to read data. When 
copying from MMC to ram, the mmc_read routine is used. In no other cases 
is it used. Since I think the MMC is a read-write interface through a 
fifo buffer, based on looking at mmc.c, I assume it does not work in any 
cases except cp from ram to mmc and from ram to mmc. mmc to flash for 
instance would write trash to flash as near as I can tell. Also you 
can't cmp it or md it correctly.

>  
>
>>simple ram, more and more people seem to accept "new" commands to read 
>>and write these objects, and to forgo the advantages/features of the 
>>memory commands. This becomes especially true when the size of the 
>>object to be read/written exceeds the size of the CPU address space. 
>>    
>>
>
>Do you have an example where this happens in U-Boot context?
>  
>
Yes, some of them you give later, like an IDE disk. It would be 
impossible to memory map large IDE disks all at once, so nobody even 
considers it as an option. You could perhaps consider a serial Flash to 
be memory-mapped if that model was desired. I had thought that that 
might have been desired at one time, but I think that notion is obsolete.

>  
>
>>What my goal in this proposed design is to allow users to choose at 
>>compile time what features are desired for the u-boot memory commands  
>>a) without an ifdef maze and b) without needing to inject new code into 
>>cmd_mem.c and cmd_load.c for every different memory technology that will 
>>use memory access type commands. If somebody wants to use the memory 
>>commands on a serial EEPROM, this can be made to work if desired, or not 
>>    
>>
>
>I feel that would be not natural. And EEPROM (like on a I2C bus) does
>not have any natural adresses in the CPU's address  space.  Same  for
>IDE  or  USB  devices.  These are storage devices on some form of I/O
>bus, but certainly NOT memory.
>  
>
Agreed. But these same arguments apply to Dataflash. Also, there are 
eeproms that are not serial and can reside on the CPU memory bus. The 
read-type memory commands would work fine on them, but there would be no 
way to write to them. I imagine it could be done by hacking into the 
flash interface, since it is after all similar. The chips read like ram 
but write more like flash. However, this is somewhat confusing if the 
parallel eeprom interface would be in the flash module. I guess this can 
be worried about later if necessary.
If it can be decided that the only devices that will be supported by the 
memory commands in cmd_mem.c are those devices that can be read directly 
as ram without a read routine, I think that would help clarify the 
intent of the commands.

>  
>
>>made to work if not considered necessary, without changing cmd_mem.c.  
>>How possible/good this goal is remains to be seen, I agree. The current 
>>    
>>
>
>IMHO we should provide a user inteface which is powerful, yet easy to
>use - this requires it must be intuitive to the end user. For most  f
>them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
>EEPROM is not.
>  
>
I am not sure I concur with the idea users consider NOR flash as 
"memory" . NOR flash has always required the user to be aware of the 
protect on/protect off requirements, as well as erase requirements. In 
fact, the user even needs to know what sectors to protect/unprotect in 
some cases. The only "memory" write commands that actually do work on 
NOR flash are cp and loadX. However, I do agree that u-boot users by now 
expect cp and loadX to work on NOR flash. In fact, I think it is 
expected to work on any bus-addressed flash type. I can see why removing 
that support would not work well for existing boards.
On the other hand, I do not think it less logical to require a write to 
flash to consist of a command different from cp, since in order for it 
to actually work, the user must have done all the right preparation.

>  
>
>>I completely  agree with small and simple, and making feature choices at 
>>compile time. I think these attributes can be preserved, or perhaps 
>>    
>>
>
>Ther eis another thing that is important to me: U-Boot  on  different
>systems,  boards  and architectures shall always behave as similar as
>possible. Having the "cmp" command (if configured into  U-Boot)  work
>on  flash  memory  on  one system and failing to do so on another one
>seems unacceptable to me.
>  
>
Me too, especially since, if we remove the Dataflash case and MMC case, 
support for commands like cmp crc, md etc. is absolutely transparent. It 
takes no code at all. The only issue arises with cp/loadX. If we all 
agree there is no desire to interface anything that requires a routine 
to read data from it to the memory commands, then I have no desire to go 
there either. Presently, we have loadX commands that will work with 
"flash" by calling flash_write. cp also explicity contains code to work 
with flash by calling flash_write. Dataflash and  MMC devices work in cp 
by calling mmc_write, mmc_read, write_dataflash, and read_dataflash. 
These two devices work poorly/not at all in most other memory command 
cases, but if nobody sees this as a problem, then I don't either.
Presently, if there is more than one type of  parallel flash in the 
system, it must be dealt with inside the flash_write routine. Maybe this 
has never been a problem. It is also true that you can't write across 
flash memory type boundaries, you get an error, so this is probably 
fine/expected.

So the summary of all this, from my point of view, is that if we do not 
expect to add a bunch of new devices to the cmd_mem.c and loadX 
interfaces, and if we are ok with the present performance of MMC devices 
and Dataflash devices in the current interface (I don't care since I 
don't use them), I see no reason to change the current code. I would 
suggest removing support for MMC and Dataflash devices from the 
cmd_mem.c file, since these devices seem more like serial FLASH/USB 
device etc., and moving support to a new file, but I am sure current 
users wouldn't like that, so they probably must stay where they are. It 
would be a shame if we intend to add a bunch of cases to the current 
stuff in cmd_mem.c to not generalize the interface to allow adding such 
devices without needing to modify cmd_mem.c in the common code, but if 
we don't expect to make such additions, then I see no need for such a 
change. I had thought that there was interest in interfacing non-bus 
devices to the memory commands, along the lines of the Dataflash 
interface, but with all cases working "properly". I personally have no 
such interest. If nobody else does, I see no reason for changes in how 
cmd_mem.c interfaces to "memory". The only change I have any interest in 
is adding a conditional compile allowing the removal of flash support 
from the cp/loadX commands without removing support for parallel flash 
from the board. I prefer FLASH WRITE x y z to cp x y z when dealing with 
flash, but that's just me. Naturally, all the other commands would still 
work the same, such as cmp, etc. This is probably because most of the 
systems I am now working with use serial flash which requires a 
different command anyway, so I just expect it.

Thanks for bearing with me on this, and I hope the research will be of 
some benefit!

Best Regards,
Bill Campbell

>
>Best regards,
>
>Wolfgang Denk
>
>  
>

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>> Read what you wrote: "use memory oriented commands on memory". That's
>> exactly what I really expect to be able to do, indeed.
>>
>> Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
>> contents?
>>
> You should. However, in the current u-boot, if you try these commands
> with Dataflash addresses, crc takes the crc of some random data, you
> get  an error message saying it is not supported for cmp, and it works
> correctly for md (because there is explicit code to support it
> compiled in if Dataflash is present). There is also a device MMC which is
> included in some builds. As near as I can tell, it does not work in
> any
> of the read operations, there is no code built-in for it as a special
> case.

I have CRC in my version of the dataflash drivers and can do cmp
between SDRAM and flash, so if those patches get merged
that is not an issue.

> True enough. Yet the only memory write command that explicitly works
> on flash memory is cp.  mw does not check for a flash address, so
> what it
> does depends on the protect state of the chip and how the flash works.
> Some flash lets you change a single byte, others require various erase
> operations and so on. The rule here may be know what you are doing
> before you try to modify flash one byte at a time, but it is an
> asymmetry. I won't even hazard a guess at what loopw will do, but I am
> sure its not a good idea on flash. The MMC case is also not provided
> for
> at all.
>
>> I can't say if Dataflash really fits into this szenario; I never used
>> this feature myself.
>>


>>
> It does not, and probably is an example of why this is an issue to
> some
> of us. Dataflash requires a routine to read the data as well as to
> write it. Most of the memory read routines work fine on any memory
> technology that has a one-to-one bus address to data technology.
> Dataflash does not fit this model and therefore doesn't work in many
> read operations.

If you want to update a byte in parallell flash, you have to
read an entire (typically 64 kB) sector, erase that sector
update the byte and write the complete secotr back.

If you want to update a dataflash (AT45) you
read a 1056 byte area into a memory buffer internal
to the device.
This is a parallel operation so the complete
page is read in a fe clock cycles.

You then send a short buffer write command
which updates the specific byte,
followed by a page write with autoerase.

Everything controlled by DMA at 30+ Mbps.

>  In
> some cases you get an error, because it is explicitly handled in the
> code, in some cases you get a bogus result and no error. As near as I
> can determine, the MMC also requires a routine to read data. When
> copying from MMC to ram, the mmc_read routine is used. In no other
> cases  is it used.

I see the main reason to have MMC/SD is to be able
to create a fs on a PC and then move it to the target.
Same for USB memories.

Those little tings should contain a FAT file system...

> Yes, some of them you give later, like an IDE disk. It would be
> impossible to memory map large IDE disks all at once, so nobody even
> considers it as an option. You could perhaps consider a serial Flash
> to
> be memory-mapped if that model was desired. I had thought that that
> might have been desired at one time, but I think that notion is
> obsolete.

No its not.

>> I feel that would be not natural. And EEPROM (like on a I2C bus) does
>> not have any natural adresses in the CPU's address  space.  Same  for
>> IDE  or  USB  devices.  These are storage devices on some form of I/O
>> bus, but certainly NOT memory.

If you want to store environment in EEPROM
(which Wolfgang does not like) then I think you
need to memory map it with the current U-Boot.

One way of using this is to have a microcontroller emulate
the EEPROM.

> Agreed. But these same arguments apply to Dataflash. Also, there are
> eeproms that are not serial and can reside on the CPU memory bus. The
> read-type memory commands would work fine on them, but there would be
> no way to write to them. I imagine it could be done by hacking into
> the  flash interface, since it is after all similar. The chips read like
> ram



> but write more like flash. However, this is somewhat confusing if the
> parallel eeprom interface would be in the flash module. I guess this
> can
> be worried about later if necessary.
> If it can be decided that the only devices that will be supported by
> the memory commands in cmd_mem.c are those devices that can be read
> directly
> as ram without a read routine, I think that would help clarify the
> intent of the commands.

No it can't.
Any modifications to the dataflash needs to allow for
things that work today, and also what needs
to be implemented, like memory compare, crc etc.


>>
> Me too, especially since, if we remove the Dataflash case and MMC
> case, support for commands like cmp crc, md etc. is absolutely
> transparent. It takes no code at all. The only issue arises with
> cp/loadX. If we all
> agree there is no desire to interface anything that requires a routine
> to read data from it to the memory commands

That will never reach an agreement.

> , then I have no desire to
> go there either. Presently, we have loadX commands that will work with
> "flash" by calling flash_write. cp also explicity contains code to
> work with flash by calling flash_write. Dataflash and  MMC devices
> work in cp
> by calling mmc_write, mmc_read, write_dataflash, and read_dataflash.
> These two devices work poorly/not at all in most other memory command
> cases, but if nobody sees this as a problem

It is a problem.
I have fixed some of it in my version of u-boot.

> , then I don't either.
> Presently, if there is more than one type of  parallel flash in the
> system, it must be dealt with inside the flash_write routine. Maybe
> this has never been a problem. It is also true that you can't write
> across
> flash memory type boundaries, you get an error, so this is probably
> fine/expected.
>
> So the summary of all this, from my point of view, is that if we do
> not expect to add a bunch of new devices to the cmd_mem.c and loadX
> interfaces, and if we are ok with the present performance of MMC
> devices and Dataflash devices in the current interface (I don't care
> since I
> don't use them), I see no reason to change the current code. I would
> suggest removing support for MMC and Dataflash devices from the
> cmd_mem.c file, since these devices seem more like serial FLASH/USB
> device etc., and moving support to a new file, but I am sure current
> users wouldn't like that, so they probably must stay where they are.
> It would be a shame if we intend to add a bunch of cases to the
> current
> stuff in cmd_mem.c to not generalize the interface to allow adding
> such devices without needing to modify cmd_mem.c in the common code,
> but if
> we don't expect to make such additions, then I see no need for such a
> change. I had thought that there was interest in interfacing non-bus
> devices to the memory commands, along the lines of the Dataflash
> interface, but with all cases working "properly". I personally have no
> such interest. If nobody else does, I see no reason for changes in how
> cmd_mem.c interfaces to "memory". The only change I have any interest
> in
> is adding a conditional compile allowing the removal of flash support
> from the cp/loadX commands without removing support for parallel flash
> from the board. I prefer FLASH WRITE x y z to cp x y z when dealing
> with flash, but that's just me. Naturally, all the other commands
> would still work the same, such as cmp, etc. This is probably because
> most of the systems I am now working with use serial flash which
> requires a
> different command anyway, so I just expect it.
>
> Thanks for bearing with me on this, and I hope the research will be of
> some benefit!
>
> Best Regards,
> Bill Campbell
>
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your opinions on IT & business topics through brief surveys -
> and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <006c01c74378$2945df50$01c4af0a@atmel.com> you wrote:
>
> If you want to store environment in EEPROM
> (which Wolfgang does not like) then I think you
> need to memory map it with the current U-Boot.

No, not at all. U-Boot will read the EEPROM through  the  appropriate
I2C / SPI / ... driver calls.

[ And my dislike for EEPROm comes from the facts that (1)  I've  seen
  data   loss   /   corruption   on   I2C   EEPROMS  too  often  (see
  doc/I2C_Edge_Conditions), and that it's so slow  which  slows  down
  booting too much. ]


> > If it can be decided that the only devices that will be supported by
> > the memory commands in cmd_mem.c are those devices that can be read
> > directly
> > as ram without a read routine, I think that would help clarify the
> > intent of the commands.
> 
> No it can't.
> Any modifications to the dataflash needs to allow for
> things that work today, and also what needs
> to be implemented, like memory compare, crc etc.

Ummm... I guess you don't have *my* support any longer on this.

> > cp/loadX. If we all
> > agree there is no desire to interface anything that requires a routine
> > to read data from it to the memory commands
> 
> That will never reach an agreement.

Then we will have to come up with a decision even without a  complete
agreement of all involved parties.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
You Don't Have To Be 'Damned' To Work Here, But It Helps!!!
                                             - Terry Pratchett, _Eric_

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BD6755.3000100@comcast.net> you wrote:
>
>     You are up late this Sunday night. Probably you will not see this 
> until Monday morning!

;-)

> >Why should I not be allowed to "md" or "crc" or "cmp" RAM and flash
> >contents?
> >
> You should. However, in the current u-boot, if you try these commands 
> with Dataflash addresses, crc takes the crc of some random data, you get 
> an error message saying it is not supported for cmp, and it works 
> correctly for md (because there is explicit code to support it compiled 
> in if Dataflash is present). There is also a device MMC which is 
> included in some builds. As near as I can tell, it does not work in any 
> of the read operations, there is no code built-in for it as a special case.

OK, so the implementation(s) is/are broken.

I was not aware of this - no system with Dataflash or MMC had to ever
pass our regression testing.

> True enough. Yet the only memory write command that explicitly works on 
> flash memory is cp.  mw does not check for a flash address, so what it 
> does depends on the protect state of the chip and how the flash works. 

Note that this is intentionally. This is what you use to  test  flash
access  commands on the low level. I would consider it broken it this
were different.

> It does not, and probably is an example of why this is an issue to some 
> of us. Dataflash requires a routine to read the data as well as to write 
> it. Most of the memory read routines work fine on any memory technology 
> that has a one-to-one bus address to data technology. Dataflash does not 
> fit this model and therefore doesn't work in many read operations. In 
> some cases you get an error, because it is explicitly handled in the 
> code, in some cases you get a bogus result and no error. As near as I 
> can determine, the MMC also requires a routine to read data. When 
> copying from MMC to ram, the mmc_read routine is used. In no other cases 
> is it used. Since I think the MMC is a read-write interface through a 
> fifo buffer, based on looking at mmc.c, I assume it does not work in any 
> cases except cp from ram to mmc and from ram to mmc. mmc to flash for 
> instance would write trash to flash as near as I can tell. Also you 
> can't cmp it or md it correctly.

I start to understand your concerns. So far I assumed that  Dataflash
and MMC support was just working fine.

> >>memory commands. This becomes especially true when the size of the 
> >>object to be read/written exceeds the size of the CPU address space. 
> >
> >Do you have an example where this happens in U-Boot context?
> >
> Yes, some of them you give later, like an IDE disk. It would be 

That's not what we discussed. You wrote: "size of the  object  to  be
read/written"  -  the size of such objects is probably always smaller
than the storage capacity of the external devices. And I  doubt  that
you  will ever be able to write (as an atomical operation) any object
that is bigger than the CPU's address space.

> >I feel that would be not natural. And EEPROM (like on a I2C bus) does
> >not have any natural adresses in the CPU's address  space.  Same  for
> >IDE  or  USB  devices.  These are storage devices on some form of I/O
> >bus, but certainly NOT memory.
>
> Agreed. But these same arguments apply to Dataflash. Also, there are 
> eeproms that are not serial and can reside on the CPU memory bus. The 

If they do, it is natural to be able to access these  using  standard
commands like "md". That must be a supported option.

> read-type memory commands would work fine on them, but there would be no 
> way to write to them. I imagine it could be done by hacking into the 

I'm not sure I understand. What sort of devices do you have  in  mind
specifically?  We've  had  FRAM  on some boards which was just read /
write without problems.

> If it can be decided that the only devices that will be supported by the 
> memory commands in cmd_mem.c are those devices that can be read directly 
> as ram without a read routine, I think that would help clarify the 
> intent of the commands.

Yes, that's what I have in mind.

Sorry if my argumentation was cofusing, but - as mentioned before - I
never used Dataflash  myself.  My  understanding  was  that  it  does
provide  such  a  direct  read  interface,  but  this  was probably a
misunderstanding then.

> >IMHO we should provide a user inteface which is powerful, yet easy to
> >use - this requires it must be intuitive to the end user. For most  f
> >them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
> >EEPROM is not.
> >  
> I am not sure I concur with the idea users consider NOR flash as 
> "memory" . NOR flash has always required the user to be aware of the 
> protect on/protect off requirements, as well as erase requirements. In 

But it's still memory - "flash memory" is a very commnonly used term,
so for me there is not the slightest doubt about this.

> fact, the user even needs to know what sectors to protect/unprotect in 
> some cases. The only "memory" write commands that actually do work on 
> NOR flash are cp and loadX. However, I do agree that u-boot users by now 

No. Also mw works fine - exactly as it should.

> expect cp and loadX to work on NOR flash. In fact, I think it is 
> expected to work on any bus-addressed flash type. I can see why removing 
> that support would not work well for existing boards.

OK.

> On the other hand, I do not think it less logical to require a write to 
> flash to consist of a command different from cp, since in order for it 
> to actually work, the user must have done all the right preparation.

Call it historical reasons, then ;-)

> takes no code at all. The only issue arises with cp/loadX. If we all 
> agree there is no desire to interface anything that requires a routine 
> to read data from it to the memory commands, then I have no desire to go 
> there either. Presently, we have loadX commands that will work with 

I do agree. Grant?

[I really have to stop myself from writing "You can take this for
Granted" :-) ]

> "flash" by calling flash_write. cp also explicity contains code to work 
> with flash by calling flash_write. Dataflash and  MMC devices work in cp 
> by calling mmc_write, mmc_read, write_dataflash, and read_dataflash. 
> These two devices work poorly/not at all in most other memory command 
> cases, but if nobody sees this as a problem, then I don't either.

As I  just  learned  today,  there  are  serious  problems  with  the
implementation of the Dataflash support. So at least the most blatant
bugs should get fixed, even in the old implementation.

> Presently, if there is more than one type of  parallel flash in the 
> system, it must be dealt with inside the flash_write routine. Maybe this 
> has never been a problem. It is also true that you can't write across 
> flash memory type boundaries, you get an error, so this is probably 
> fine/expected.

No - if flash regions are mapped contiguously, a "cp" should be  able
to cross device boundaries transparently.

> don't use them), I see no reason to change the current code. I would 
> suggest removing support for MMC and Dataflash devices from the 
> cmd_mem.c file, since these devices seem more like serial FLASH/USB 
> device etc., and moving support to a new file, but I am sure current 
> users wouldn't like that, so they probably must stay where they are. It 

That's an important issue: what are *users* thinking about all that?

> change. I had thought that there was interest in interfacing non-bus 
> devices to the memory commands, along the lines of the Dataflash 

Not on my side...


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The algorithm to do that is extremely nasty. You might want  to  mug
someone with it."                   - M. Devine, Computer Science 340

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Wolfgang Denk wrote:

>In message <45BD6755.3000100@comcast.net> you wrote:
>  
>
><snip>
>  
>
>>True enough. Yet the only memory write command that explicitly works on 
>>flash memory is cp.  mw does not check for a flash address, so what it 
>>does depends on the protect state of the chip and how the flash works. 
>>    
>>
>
>Note that this is intentionally. This is what you use to  test  flash
>access  commands on the low level. I would consider it broken it this
>were different.
>  
>
I understand your point. Similar conditions apply to memory-mapped 
control and status registers. However, there is still an asymmetry 
between mw and cp. mw feeds the data directly to the chip, no matter 
what kind of chip/address is used (which is useful). cp "cooks" the data 
sent to flash chips so that it will actually write into the chips. 
(Granted it is cooked very rare, but still it is cooked)  This is also 
desired behavior, but not the same behavior.

<snip>

>  
>
>>>>memory commands. This becomes especially true when the size of the 
>>>>object to be read/written exceeds the size of the CPU address space. 
>>>>        
>>>>
>>>Do you have an example where this happens in U-Boot context?
>>>
>>>      
>>>
>>Yes, some of them you give later, like an IDE disk. It would be 
>>    
>>
>
>That's not what we discussed. You wrote: "size of the  object  to  be
>read/written"  -  the size of such objects is probably always smaller
>than the storage capacity of the external devices. And I  doubt  that
>you  will ever be able to write (as an atomical operation) any object
>that is bigger than the CPU's address space.
>  
>
We agree here, I just was not very precise. The trick  is that if you 
allow mapping an IDE disk as memory, you could copy from one part of the 
disk to another part of the disk an an object that is LARGER than the 
CPU memory space. (There would be nothing requiring the first or second 
operand of the cp command must be on the CPU memory bus) We also both 
agree we don't want to do this as part of the cmd_mem.c interface!

>  
>
>>>I feel that would be not natural. And EEPROM (like on a I2C bus) does
>>>not have any natural adresses in the CPU's address  space.  Same  for
>>>IDE  or  USB  devices.  These are storage devices on some form of I/O
>>>bus, but certainly NOT memory.
>>>      
>>>
>>Agreed. But these same arguments apply to Dataflash. Also, there are 
>>eeproms that are not serial and can reside on the CPU memory bus. The 
>>    
>>
>
>If they do, it is natural to be able to access these  using  standard
>commands like "md". That must be a supported option.
>  
>
All read commands would work fine. Write operations could be another 
story. If we define (as I think you do) mw to be a "raw" write to the 
address space, it would also work, subject to any timing requirements of 
the device, which is the users problem anyway. cp is another story.

>  
>
>>read-type memory commands would work fine on them, but there would be no 
>>way to write to them. I imagine it could be done by hacking into the 
>>    
>>
>
>I'm not sure I understand. What sort of devices do you have  in  mind
>specifically?  We've  had  FRAM  on some boards which was just read /
>write without problems.
>  
>
You undoubtedly had FRAM like the FM20L08 that has "NoDelay" writes. 
However, even these chips do have a software protect/unprotect sequence 
that  requires some "flash-like" commands to use. Some EEPROM chips  
(for instance the M28LV16) have a (3 ms) page/byte maximum write cycle, 
which requires a write routine to poll the chip for done on a write when 
a page boundary is crossed or at the end of any write operation.

>  
>
>>If it can be decided that the only devices that will be supported by the 
>>memory commands in cmd_mem.c are those devices that can be read directly 
>>as ram without a read routine, I think that would help clarify the 
>>intent of the commands.
>>    
>>
>
>Yes, that's what I have in mind.
>  
>
Good. I think this position greatly clarifies things, at least from my 
point of view.


<snip>

>>>IMHO we should provide a user inteface which is powerful, yet easy to
>>>use - this requires it must be intuitive to the end user. For most  f
>>>them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
>>>EEPROM is not.
>>> 
>>>      
>>>
>>I am not sure I concur with the idea users consider NOR flash as 
>>"memory" . NOR flash has always required the user to be aware of the 
>>protect on/protect off requirements, as well as erase requirements. In 
>>    
>>
>
>But it's still memory - "flash memory" is a very commnonly used term,
>so for me there is not the slightest doubt about this.
>  
>
I understand you point of view. However, the very common use of "flash 
memory" is also often directed at flash memory that has an spi or other 
type of interface, which is not the type of flash memory you have in 
mind! It is also worthy of mention that PPCBUG does have a PFLASH 
command, so it is not a universal idea that NOR flash is simply memory. 
It is however a perfectly good point of view, and the one that u-boot 
follows!

>  
>
>>fact, the user even needs to know what sectors to protect/unprotect in 
>>some cases. The only "memory" write commands that actually do work on 
>>NOR flash are cp and loadX. However, I do agree that u-boot users by now 
>>    
>>
>
>No. Also mw works fine - exactly as it should.
>  
>
Ack.

<snip>

>  
>
>>On the other hand, I do not think it less logical to require a write to 
>>flash to consist of a command different from cp, since in order for it 
>>to actually work, the user must have done all the right preparation.
>>    
>>
>
>Call it historical reasons, then ;-)
>  
>
I like this better :-)

>>Presently, if there is more than one type of  parallel flash in the 
>>system, it must be dealt with inside the flash_write routine. Maybe this 
>>has never been a problem. It is also true that you can't write across 
>>flash memory type boundaries, you get an error, so this is probably 
>>fine/expected.
>>    
>>
>
>No - if flash regions are mapped contiguously, a "cp" should be  able
>to cross device boundaries transparently.
>  
>
Actually, what I said above is wrong. The flash_write code DOES allow 
crossing  flash type boundaries. What is not allowed in the flash_write 
routine is starting in flash and ending in non-flash. This throws an 
error. Starting in flash,  intervening ram, ending in flash would not 
work properly. Holes in the memory map between flash regions also would 
not work properly. This  may be defined as an error, but  you don't get 
an error  message in these cases as near as I can tell. Rather, the code 
seems to do something untoward in the next flash bank. It would be 
trivial to detect and throw an error for these cases, but the current 
code does not.  Also, there are several places in the current code where 
it is assumed that if the initial destination address is in ram, the 
entire operation is in ram. This can be false if ram and flash are 
contiguously mapped. IMNSHO this condition should either work or be an 
error that is detected.

There is also a semantic question regarding the meaning of the size part 
of the cp.X command when the destination operand is flash. If the 
destination operand is in flash, the size of the operand for both the 
source and destination addresses is not enforced. The size of access is 
enforced if the destination is ram. This may be a bit of a nit, but I 
bring it up for completeness. cp.l commands that look like they for sure 
should generate an alignment exception will not do so if the destination 
is flash.

<snip>

>>change. I had thought that there was interest in interfacing non-bus 
>>devices to the memory commands, along the lines of the Dataflash 
>>    
>>
>
>Not on my side...
>
>  
>
Ack. Not mine either!

Best Regards,
Bill Campbell

>Best regards,
>
>Wolfgang Denk
>
>  
>

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BE5CD4.3090306@comcast.net> you wrote:
> 
> I understand your point. Similar conditions apply to memory-mapped 
> control and status registers. However, there is still an asymmetry 
> between mw and cp. mw feeds the data directly to the chip, no matter 
> what kind of chip/address is used (which is useful). cp "cooks" the data 
> sent to flash chips so that it will actually write into the chips. 
> (Granted it is cooked very rare, but still it is cooked)  This is also 
> desired behavior, but not the same behavior.

Correct. But "cp" is not a "m*" command, then :-)

> We agree here, I just was not very precise. The trick  is that if you 
> allow mapping an IDE disk as memory, you could copy from one part of the 

I don't want to do this. Not in a boot loader.

> operand of the cp command must be on the CPU memory bus) We also both 
> agree we don't want to do this as part of the cmd_mem.c interface!

I don't want to do this at all. I want to be able to read  and  write
from resp. to disk, that's all.

> >No - if flash regions are mapped contiguously, a "cp" should be  able
> >to cross device boundaries transparently.
>
> Actually, what I said above is wrong. The flash_write code DOES allow 
> crossing  flash type boundaries. What is not allowed in the flash_write 
> routine is starting in flash and ending in non-flash. This throws an 
> error. Starting in flash,  intervening ram, ending in flash would not 
> work properly. Holes in the memory map between flash regions also would 

You are right. But anybody who is crazy enough to come up with such a
memory map should fix his design before complaining that U-Boot  does
not support all possible pathologic cases.

> not work properly. This  may be defined as an error, but  you don't get 
> an error  message in these cases as near as I can tell. Rather, the code 

There are many other misconfigurations  that  result  in  non-working
systems  without useful error message (in most cases because the code
crashes long before it can send any messages at all).

> seems to do something untoward in the next flash bank. It would be 
> trivial to detect and throw an error for these cases, but the current 
> code does not.  Also, there are several places in the current code where 

As mentioned before: I tend to consider this as a design error  which
is not worth the code for runtime error checking.

> it is assumed that if the initial destination address is in ram, the 
> entire operation is in ram. This can be false if ram and flash are 
> contiguously mapped. IMNSHO this condition should either work or be an 
> error that is detected.

If you look close enough, you can find many problematic situations  -
eception vectors, malloc arena, stack, U-Boot code, data and BSS etc.
are  not  protected  in  RAM  - you can easily overwrite any of these
without any protection.

You can do a lot more mess when meddeling with PCI memory.

U-Boot does not attampt to prevent all possible kind of user errors.
It was designed to be small, powerful, and easy to port.

Here is one of my favorite quotes which fully applies to U-Boot, too:

"UNIX was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things."       - Doug Gwyn

> There is also a semantic question regarding the meaning of the size part 
> of the cp.X command when the destination operand is flash. If the 
> destination operand is in flash, the size of the operand for both the 
> source and destination addresses is not enforced. The size of access is 
> enforced if the destination is ram. This may be a bit of a nit, but I 

Sorry, I cannot parse this. Please explain.

> bring it up for completeness. cp.l commands that look like they for sure 
> should generate an alignment exception will not do so if the destination 
> is flash.

Why should they? 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A committee is a life form with six or more legs and no brain.
                              -- Lazarus Long, "Time Enough For Love"

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Wolfgang Denk wrote:
<snip>

>>>No - if flash regions are mapped contiguously, a "cp" should be  able
>>>to cross device boundaries transparently.
>>>      
>>>
>>Actually, what I said above is wrong. The flash_write code DOES allow 
>>crossing  flash type boundaries. What is not allowed in the flash_write 
>>routine is starting in flash and ending in non-flash. This throws an 
>>error. Starting in flash,  intervening ram, ending in flash would not 
>>work properly. Holes in the memory map between flash regions also would 
>>    
>>
>
>  
>
Actually, I am still wrong. The flash code allows crossing flash chip 
boundaries of the same type. It does not support crossing flash type 
boundaries of different types unless the write_buff routine chosen for 
the target board does some additional de-multiplexing. Thus, if you use 
common/cfi_flash.c, all your flash needs to be cfi flash. Many of the 
flash routines in the board/ directory do support more than one type of 
flash. I just wanted to state this correctly.

>You are right. But anybody who is crazy enough to come up with such a
>memory map should fix his design before complaining that U-Boot  does
>not support all possible pathologic cases.
>  
>
OK, that makes sense.

>  
>
>>not work properly. This  may be defined as an error, but  you don't get 
>>an error  message in these cases as near as I can tell. Rather, the code 
>>    
>>
>
>There are many other misconfigurations  that  result  in  non-working
>systems  without useful error message (in most cases because the code
>crashes long before it can send any messages at all).
>  
>
OK, but there are also cases where you DO get an error. I assume it 
depends mostly on the cost of detecting the error and how 
important/probable the error condition may be.

>  
>
>>seems to do something untoward in the next flash bank. It would be 
>>trivial to detect and throw an error for these cases, but the current 
>>code does not.  Also, there are several places in the current code where 
>>    
>>
>
>As mentioned before: I tend to consider this as a design error  which
>is not worth the code for runtime error checking.
>  
>
OK. I'm not sure I totally agree, as I think the parameters could easily 
be checked in addr2info in a manner that should not increase the 
footprint much if at all. I will submit a patch and see what you think.  
On the other hand you are quite right that nothing prevents the user 
from copying from non-existent memory to non-existent memory, so other 
address errors are no different.

>  
>
>>it is assumed that if the initial destination address is in ram, the 
>>entire operation is in ram. This can be false if ram and flash are 
>>contiguously mapped. IMNSHO this condition should either work or be an 
>>error that is detected.
>>    
>>
>
>If you look close enough, you can find many problematic situations  -
>eception vectors, malloc arena, stack, U-Boot code, data and BSS etc.
>are  not  protected  in  RAM  - you can easily overwrite any of these
>without any protection.
>
>You can do a lot more mess when meddeling with PCI memory.
>
>U-Boot does not attampt to prevent all possible kind of user errors.
>It was designed to be small, powerful, and easy to port.
>
>Here is one of my favorite quotes which fully applies to U-Boot, too:
>
>"UNIX was not designed to stop you from doing stupid things,  because
>that would also stop you from doing clever things."       - Doug Gwyn
>  
>
Agreed and understood.

>  
>
>>There is also a semantic question regarding the meaning of the size part 
>>of the cp.X command when the destination operand is flash. If the 
>>destination operand is in flash, the size of the operand for both the 
>>source and destination addresses is not enforced. The size of access is 
>>enforced if the destination is ram. This may be a bit of a nit, but I 
>>    
>>
>
>Sorry, I cannot parse this. Please explain.
>
>  
>
>>bring it up for completeness. cp.l commands that look like they for sure 
>>should generate an alignment exception will not do so if the destination 
>>is flash.
>>    
>>
>
>Why should they?
>
Well, my thought on this is that UNIX (and u-boot) also follows the 
Principle of Least Surprise, namely that like cases tend to work alike. 
If  I type cp.l 0x3 0x10 0x1 on a system that enforces longword (4 byte 
words) to be aligned, it will throw an exception and not work. I would 
therefore also expect cp.l 0x3 <some flash address> 0x1 to also throw an 
exception and not work for the same reason, yet it does not do so. It is 
executed as cp.b 0x3 <some flash address> 0x1, which is not what I asked 
for. Like I said, this is a nit and probably not important. I expect few 
people use cp.l to copy into flash anyway. It was just a difference 
between flash and ram that I noticed.

Best Regards,
Bill Campbell

> 
>
>Best regards,
>
>Wolfgang Denk
>
>  
>

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BE7D37.5090601@comcast.net> you wrote:
>
> >>bring it up for completeness. cp.l commands that look like they for sure 
> >>should generate an alignment exception will not do so if the destination 
> >>is flash.
> >
> >Why should they?
> >
> Well, my thought on this is that UNIX (and u-boot) also follows the 
> Principle of Least Surprise, namely that like cases tend to work alike. 
> If  I type cp.l 0x3 0x10 0x1 on a system that enforces longword (4 byte 
> words) to be aligned, it will throw an exception and not work. I would 

Note that it will trap on the unaligned read access at address 0x3.

> therefore also expect cp.l 0x3 <some flash address> 0x1 to also throw an 
> exception and not work for the same reason, yet it does not do so. It is 

It should trap as well on the unaligned read access at address 0x3 -
it should not matter at all what the target address is.

> executed as cp.b 0x3 <some flash address> 0x1, which is not what I asked 

It's more in the equivalent of "cp.b 3 <flash address> 4"

> for. Like I said, this is a nit and probably not important. I expect few 
> people use cp.l to copy into flash anyway. It was just a difference 
> between flash and ram that I noticed.

Indeed, there is a difference.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A memorandum is written not to inform the reader, but to protect  the
writer.                                               -- Dean Acheson

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

> If it can be decided that the only devices that will be supported by the 
> memory commands in cmd_mem.c are those devices that can be read directly 
> as ram without a read routine, I think that would help clarify the 
> intent of the commands.
>   

Why limit to "read".
Why not say that any memory which can be read or *written* without a driver
will be supported by the cmd_mem.c ?



-- 
Best Regards,
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com 
links: www.avrfreaks.net; www.at91.com; avr32linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070130/94500636/attachment.vcf 

[U-Boot-Users] Atmel DataFlash hooks.

[J. William Campbell]

Ulf Samuelsson wrote:

>>If it can be decided that the only devices that will be supported by the 
>>memory commands in cmd_mem.c are those devices that can be read directly 
>>as ram without a read routine, I think that would help clarify the 
>>intent of the commands.
>>  
>>    
>>
>
>Why limit to "read".
>Why not say that any memory which can be read or *written* without a driver
>will be supported by the cmd_mem.c ?
>
>
>  
>
There are at least two very good reasons why adding the "written" 
constraint is not practical: First, as he has stated several times in 
this thread, Mr. Denk believes that users regard NOR flash as just like 
ram and therefore expect ram commands to work on it. This point of view 
certainly has merit, and while we may not all totally agree with it, it 
is, and must be, Mr. Denk's u-boot. He is the final determining person 
on what will be accepted.
The second, and perhaps even better reason to not remove NOR flash from 
the memory commands is that it will break just about 100% of all 
existing u-boot configurations. Ok, maybe it's 95%, but its real large. 
This doesn't even take into account how many README files out there 
describe copying things into flash with the cp command. This type of 
support is not going away for these reasons.
My main goal in this thread is to create/keep the "read" constraint 
intact so that we don't have constant additions of #ifdefs  to the 
cmd_mem.c to support any arbitrary non-memory bus devices that people 
decide they want to use like memory, or that if we were going to do that 
we would create a way to do it that didn't result in an #ifdef maze.  
Mr. Denk has solved this concern on my part. We aren't going to add 
devices that require read routines.

Best Regards,
Bill Campbell

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <45BE95C6.8090809@comcast.net> you wrote:
> 
> There are at least two very good reasons why adding the "written" 
> constraint is not practical: First, as he has stated several times in 
> this thread, Mr. Denk believes that users regard NOR flash as just like 
> ram and therefore expect ram commands to work on it. This point of view 

I *never* said that. I said we consider it as  *memory*,  and  expect
*memory* commands to work on it. Note the difference.

I also expect memory commands to work on PCI windows, for example.

> certainly has merit, and while we may not all totally agree with it, it 
> is, and must be, Mr. Denk's u-boot. He is the final determining person 
> on what will be accepted.

No, it's not my U-Boot, it's *our* baby.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Business is like a wheelbarrow. Nothing ever happens until you  start
pushing.

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

J. William Campbell skrev:
> Ulf Samuelsson wrote:
>
>   
>>> If it can be decided that the only devices that will be supported by the 
>>> memory commands in cmd_mem.c are those devices that can be read directly 
>>> as ram without a read routine, I think that would help clarify the 
>>> intent of the commands.
>>>  
>>>    
>>>
>>>       
>> Why limit to "read".
>> Why not say that any memory which can be read or *written* without a driver
>> will be supported by the cmd_mem.c ?
>>
>>
>>  
>>
>>     
> There are at least two very good reasons why adding the "written" 
> constraint is not practical: First, as he has stated several times in 
> this thread, Mr. Denk believes that users regard NOR flash as just like 
> ram and therefore expect ram commands to work on it. This point of view 
> certainly has merit, and while we may not all totally agree with it, it 
> is, and must be, Mr. Denk's u-boot. He is the final determining person 
> on what will be accepted.
>   
Dataflash users regard dataflash as just like RAM
even though all commands are not implemented.
> The second, and perhaps even better reason to not remove NOR flash from 
> the memory commands is that it will break just about 100% of all 
> existing u-boot configurations. Ok, maybe it's 95%, but its real large. 
> This doesn't even take into account how many README files out there 
> describe copying things into flash with the cp command. This type of 
> support is not going away for these reasons.
>   
So you are happy with only breaking 100% of all dataflash based
configurations?
> My main goal in this thread is to create/keep the "read" constraint 
> intact so that we don't have constant additions of #ifdefs  to the 
> cmd_mem.c to support any arbitrary non-memory bus devices that people 
> decide they want to use like memory, or that if we were going to do that 
> we would create a way to do it that didn't result in an #ifdef maze.  
> Mr. Denk has solved this concern on my part. We aren't going to add 
> devices that require read routines.
>
> Best Regards,
> Bill Campbell
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>   


-- 
Best Regards,
Ulf Samuelsson                ulf at atmel.com
Atmel Nordic AB
Mail:  Box 2033, 174 02 Sundbyberg, Sweden
Visit:  Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22     Fax +46 (8) 441 54 29
GSM    +46 (706) 22 44 57

Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com 
links: www.avrfreaks.net; www.at91.com; avr32linux.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070130/5d145a48/attachment.vcf 

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/29/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <45BD6755.3000100@comcast.net> you wrote:
> > On the other hand, I do not think it less logical to require a write to
> > flash to consist of a command different from cp, since in order for it
> > to actually work, the user must have done all the right preparation.
>
> Call it historical reasons, then ;-)
>
> > takes no code at all. The only issue arises with cp/loadX. If we all
> > agree there is no desire to interface anything that requires a routine
> > to read data from it to the memory commands, then I have no desire to go
> > there either. Presently, we have loadX commands that will work with
>
> I do agree. Grant?

Yes, I agree.

>
> [I really have to stop myself from writing "You can take this for
> Granted" :-) ]

:-P

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

Grant Likely wrote:
> On 1/29/07, Wolfgang Denk <wd@denx.de> wrote:
>> In message <45BD6755.3000100@comcast.net> you wrote:
>>> On the other hand, I do not think it less logical to require a
>>> write to flash to consist of a command different from cp, since in
>>> order for it to actually work, the user must have done all the
>>> right preparation.
>>
>> Call it historical reasons, then ;-)
>>
>>> takes no code at all. The only issue arises with cp/loadX. If we all
>>> agree there is no desire to interface anything that requires a
>>> routine to read data from it to the memory commands, then I have no
>>> desire to go there either. Presently, we have loadX commands that
>>> will work with

But we dont all agree,
I only see a bunch of non-data flash users that agree
that dataflash users do not need to do memory commands.

Memory commands are used to handle flash and DRAM.
The user today see no difference between dataflash and flash,
and use both kinds in the same way.

It is completely illogical then to claim that the memory
commands are useful for parallel flash and not for serial flash.

Please explain to me why the users should care about
that you do not like the internal implementation?

The idea that dataflash / mmc / sd could be used with a prefix,
also shows a total unwillingness.

A perfectly good implementation would let the memory commands
(after translation of environment variables)
send the parameters to a validation routine for each supported memory.

The validation routine  would return an accept or reject.
If accepted, then for you would call a probe routine
for any memorty read, which would return a pointer to a valid block
of memory containint minimum n valid bytes.

The SDRAM/Flash would just return the passed parameters
while a serial flash memory /memor card/NAND flash etc
would first read a block into a buffer and then return
a pointer to the buffer.

With such a structure, it is up to the driver to select how to
handle memory addresses.

An MMC driver could validate "mmc:10000FFFF" (note > 4 GB address)
and a dataflash driver could check for addresses between
C0000000..DFFFFFFF like it does today.

At the intialization of u-boot, each flash driver registers
its access routines in a table.
Then no ifdefs would be needed and any memory can
be used as memory.


>> I do agree. Grant?
>
> Yes, I agree.
>
>>
>> [I really have to stop myself from writing "You can take this for
>> Granted" :-) ]
>
> :-P

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <007201c7455f$aebb2b20$01c4af0a@atmel.com> you wrote:
>
> But we dont all agree,
> I only see a bunch of non-data flash users that agree
> that dataflash users do not need to do memory commands.

How many dataflash *users* have voiced their opinion here?

> Memory commands are used to handle flash and DRAM.

... and other memory ranges that are mapped into the address sapce of
the processor.

> Please explain to me why the users should care about
> that you do not like the internal implementation?

Where are those users?

> A perfectly good implementation would let the memory commands
> (after translation of environment variables)
> send the parameters to a validation routine for each supported memory.

I disagree here. You are talking about storage devices,  not  memory.
Can  we  agree  that  "memory" shall be considered something which is
directly addressable in the processors address space? So ROM, RAM and
NOR flash are memory, but NAND flash, data flash, an EEPROM with  I2C
interface,  USB,  IDE,  etc.  are  *not* memory? Once we have such an
agreement, then you will understand what the  memory  commands  shall
support (memory), and what not (storage devices).

I am sorry that I did not catch this when dataflash support was added
initially, or when MMC support was added. My fault.

> The validation routine  would return an accept or reject.
> If accepted, then for you would call a probe routine
> for any memorty read, which would return a pointer to a valid block
> of memory containint minimum n valid bytes.

And how do you explain to a user, that the "cp" or "md"  command  can
read  valid  data  from  some magic address, while accessing the same
addresses in a JTAG debugger does not work at all?

Sorry, this *is* conceptually broken. I agree that this needs  to  be
cleaned up.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies.                             - Charles Anthony Richard Hoare

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

ons 2007-01-31 klockan 22:55 +0100 skrev Wolfgang Denk:
> In message <007201c7455f$aebb2b20$01c4af0a@atmel.com> you wrote:
> >
> > But we dont all agree,
> > I only see a bunch of non-data flash users that agree
> > that dataflash users do not need to do memory commands.
> 
> How many dataflash *users* have voiced their opinion here?

I know that I am the only one, but on the other hand
there are also no dataflash users which has said
that they are of another opinion.

> 
> > Memory commands are used to handle flash and DRAM.
> 
> ... and other memory ranges that are mapped into the address sapce of
> the processor.
> 
> > Please explain to me why the users should care about
> > that you do not like the internal implementation?
> 
> Where are those users?

Our customers.

> 
> > A perfectly good implementation would let the memory commands
> > (after translation of environment variables)
> > send the parameters to a validation routine for each supported memory.
> 
> I disagree here. You are talking about storage devices,  not  memory.
> Can  we  agree  that  "memory" shall be considered something which is
> directly addressable in the processors address space? 


Can you explain why you need to have the memory commands at all?
Then please continue to explain why, when you are doing exactly
the same manouvers, but use a serial flash, you do not need the
commands.

Why do you think it is not neccessary to compare the
written dataflash with the SDRAM?

Why do you think dataflash users will appreciate to have to copy
to SDRAM every time they do something?



> 
> So ROM, RAM and
> NOR flash are memory, but NAND flash, data flash, an EEPROM with  I2C
> interface,  USB,  IDE,  etc.  are  *not* memory? Once we have such an
> agreement, then you will understand what the  memory  commands  shall
> support (memory), and what not (storage devices).
> 
> I am sorry that I did not catch this when dataflash support was added
> initially, or when MMC support was added. My fault.
> 
> > The validation routine  would return an accept or reject.
> > If accepted, then for you would call a probe routine
> > for any memorty read, which would return a pointer to a valid block
> > of memory containint minimum n valid bytes.
> 
> And how do you explain to a user, that the "cp" or "md"  command  can
> read  valid  data  from  some magic address, while accessing the same
> addresses in a JTAG debugger does not work at all?
> 

The concept to map an address is not at all hard to explain.
Even so, I have never had the question in over 100 projects.


> Sorry, this *is* conceptually broken. I agree that this needs  to  be
> cleaned up.

There is a very big difference in "cleaning" something up
and removing most of the functionality,because
You dont use it, and find it irritating to see it in the code.


My proposal will remove the need for ifdefs, and
will allow the writer of the driver to implement either
the proposed prefix, or the mapped address.




> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/31/07, Ulf Samuelsson <ulf@atmel.com> wrote:
> ons 2007-01-31 klockan 22:55 +0100 skrev Wolfgang Denk:
> There is a very big difference in "cleaning" something up
> and removing most of the functionality,because
> You dont use it, and find it irritating to see it in the code.

I have no intention of removing the functionality.  However, I do not
believe that it belongs in the memory access commands.  There should
be an appropriate command set for doing read/write/compare against
devices which does not pretend that it is mapped onto memory

Nor have I any intention of pushing patches to remove the DataFlash
hooks right now.  I will make wait until an appropriate replacement
has been accepted and tested before posting patches to remove the
cmd_mem hooks.

As for the prefix option; I do agree that it can be implemented that
way, but I think that a separate command set for device access is a
better UI (for many of the reasons discussed in this thread).  Since
Wolfgang is also of this opinion, I'm going to go ahead and start
drafting a command set.

What remains to be discussed is the process of depreciating the
cmd_mem hooks to minimize the end user impact.  ie. Format of
replacement commands, How long will the transition period be, how will
the changes be documented, what order do patches get applied, etc.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <1170285215.21572.20.camel@elrond.sweden.atmel.com> you wrote:
>
> > I disagree here. You are talking about storage devices,  not  memory.
> > Can  we  agree  that  "memory" shall be considered something which is
> > directly addressable in the processors address space? 
> 
> Can you explain why you need to have the memory commands at all?

To access memory.

> Then please continue to explain why, when you are doing exactly
> the same manouvers, but use a serial flash, you do not need the
> commands.

Because these devices are not directly addressable in the processors
address space, i. e. they are not memory.

Everything is fine as long as the "md" command in U-Boot and the "md"
command at my BDI2000's telnet prompt show the same results  for  the
same  address ranges. When this is NOT the case, something is broken.
Here, it is the U-Boot implementation.

> Why do you think it is not neccessary to compare the
> written dataflash with the SDRAM?

Nobody is going to take away the function from you. Just  the  inter-
face will have to cahcne, as the current implementation is broken.

> Why do you think dataflash users will appreciate to have to copy
> to SDRAM every time they do something?

But they are already doing this all the time, right?

> > And how do you explain to a user, that the "cp" or "md"  command  can
> > read  valid  data  from  some magic address, while accessing the same
> > addresses in a JTAG debugger does not work at all?
> 
> The concept to map an address is not at all hard to explain.
> Even so, I have never had the question in over 100 projects.

For me this is a very important issue: when  U-Boto  and  a  hardware
debugger  start  behaving  differently,  I  consider  this  a serious
problem. U-Boot is a boot loader, and as such mostly a hardware debug
tool.

> There is a very big difference in "cleaning" something up
> and removing most of the functionality,because
> You dont use it, and find it irritating to see it in the code.

You can keep the function, but not  in  the  context  of  the  memory
commands.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mistakes are often the stepping stones to utter failure.

[U-Boot-Users] Atmel DataFlash hooks.

[Tolunay Orkun]

Wolfgang Denk wrote:
>> Then please continue to explain why, when you are doing exactly
>> the same manouvers, but use a serial flash, you do not need the
>> commands.
>>     
>
> Because these devices are not directly addressable in the processors
> address space, i. e. they are not memory.
>
> Everything is fine as long as the "md" command in U-Boot and the "md"
> command at my BDI2000's telnet prompt show the same results  for  the
> same  address ranges. When this is NOT the case, something is broken.
> Here, it is the U-Boot implementation.
>   

I guess I am OK with either implementation.

I think just because BDI is not capable of handling any address space 
besides the processor address space should not mean we should so 
restrictive of command line of U-Boot. I think address space tags that I 
proposed yesterday could remove the confusion of what address the 
command is referring to and it is easy to explain that a BDI could only 
access untagged address space directly and everything else are 
indirectly accessible memory. This would also enable us to use paged 
memory mapped to a small window in processor address space seamlessly.

Anyway, I think either approach is valid and usable. There are pros and 
cons with either scheme.

I think it might be easier to educate the user with one set of commands 
as opposed to user having to decide which one of several <dev> 
read/write commands should be applicable.

>> The concept to map an address is not at all hard to explain.
>> Even so, I have never had the question in over 100 projects.
>>     
>
> For me this is a very important issue: when  U-Boto  and  a  hardware
> debugger  start  behaving  differently,  I  consider  this  a serious
> problem. U-Boot is a boot loader, and as such mostly a hardware debug
> tool.
>   

I see your point. However, with a hardware debugger you are not 
currently able to mmc data directly and so you could not be able to 
access mmc:0x00112233 either because "mmc:0x00112233" is not an address 
that would be valid for BDI. So, I see no difference. It is really 
mostly a matter of style rather than function.

Having the capability of u-boot memory commands to access different 
address spaces is a convenience feature. When such feature is not 
available the read/write commands will bring a chunk to ram and it will 
be processed using memory commands again so first one would allow the 
two operations combined but not a huge gain or loss either way.

Having said all that, I will concluded that either way is OK for me as 
long as we maintain consistent architecture.

Tolunay

[U-Boot-Users] Atmel DataFlash hooks.

[Stefan Roese]

On Sunday 28 January 2007 23:50, Wolfgang Denk wrote:
> > made to work if not considered necessary, without changing cmd_mem.c.
> > How possible/good this goal is remains to be seen, I agree. The current
>
> IMHO we should provide a user inteface which is powerful, yet easy to
> use - this requires it must be intuitive to the end user. For most  f
> them,  (NOR) flash *is* memory, while and IDE or USB disk and even an
> EEPROM is not.

From my technical point of view, NOR flash is memory but NAND flash *and* 
DataFlash are not.

But I also see the problem in changing the DataFlash user interface and 
unfortunately I have no solution for it right now.

Best regards,
Stefan

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/27/07, J. William Campbell <jwilliamcampbell@comcast.net> wrote:
> Grant Likely wrote:
> >On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
> >Thoughts?  Feel free to tell me if I'm flying too high in the
> >stratosphere on this one.
> >g.
> >
> >
> >
> I think Grant has a good point. The discussion about abstractions used
> to read/write devices and memory is
> really a discussion about a memory hierarchy. If we treat it this way,
> it is possible to optionally give everybody
> what they want while still allowing a "minimal" u-boot configuration for
> people who do not desire a particular
> feature of the "storage hierarchy". Suppose we have an abstraction that
> treats CF, IDE HD, DataFlash,
> memmapped flash etc. as a device. We also have a set of commands that
> read/write to these devices.  There
> will be a protect command that does nothing on devices that do not
> understand this command.

Yes, a device driver exports a table of ops and it is free to omit any
operations it does not support.

BTW, for this iteration, I'm only looking at device read/write.  I
plan to leave the protect/erase/etc commands alone (use existing
commands)

> This way, it
> is possible to read/write from any "device" to system ram.

yes

> A driver to
> treat system ram as a device could also
> be compiled into u-boot.

Hmmm, I think that goes too far.  Memory mapped ram is always
available and doesn't need any special operations to access it.  I
don't see any value in wrapping it with a device driver.

> As Grant discussed in an earlier part of this thread, we can also modify
> the current memory commands such that
> there is a table of what I will call "mmapped address". If the mmapped
> support is enabled, all memory commands
> will pass through a routine that splits them up into sub-commands that
> operate on addresses in single parts of the
> mmapped address table for both source and destination.

Yes.  I'm not fond of this behavior, but it can be easily implemented.
 I don't like the idea of pretending non memmapped devices have real
bus addresses.  I would prefer a namespace which defines the device
you want to talk to.  For example:

Instead of: "cp 200000 cf004000 200"  (copy from 0x200 bytes from mem
address 200000 to address 0x4000 on MMC card)
I'd prefer: "cp 200000 mmc0:4000"

But, I don't want to debate this issue just yet.  For the time being,
I'll stick with using virtual memmapping (status quo for MMC and
DataFlash).

> This would
> include breaking the commands into "sector-sized"
> operations based on an entry for the sector size in the table.
> Non-sectored devices can use all 1s for the sector size.
> The memory commands now would consist of a seek/read from one "device"
> followed by seek and read or write
> from another device. If necessary, buffering would be provided by two
> dedicated buffers in the memory command
> subsystem.

Yes, mostly, as long as regular memcpy is used wherever possible.  For
copy operations, I see four possible cases:
1. memory to memory
2. memory to device
3. device to memory
4. device to device

1. is trivial; it's just memcpy.
2 & 3 are mostly trivial; a call to the device read/write hook can
operate directly on memory
3. this is not trivial (but not hard either).  It  requires the copy
routine to buffer all data to be transfered, and also to reconcile
between differing block sizes.  I'm tempted to say this is either not
supported; or is an optional feature.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701271419l8069e56nb06bb328cf85b8b7@mail.gmail.com> you wrote:
>
> Just for the moment; forget the term 'block device' and forget about
> the current implementation of u-boot.  How significant are the

OK.

> difference between the following devices? mmc, CF, IDE HD, SCSI HD,
> DataFlash, memmapped flash, NAND flash, i2c eeprom, USB storage.
> Here's my short list:
> - different block sizes; DataFlash can be written byte at a time;
> while other devices have minimum write sizes.  Some devices need
> blocks to be specifically erased before rewriting.

- some devices can also only be read in blocks of a certain size

- some device can have sectors / blocks write protected,  both  logi-
  cally  (in  U-Boot),  or in hardware; some of these devices come up
  write protected out of reset i. e. you have to unprotect  these  to
  make them writable.

- some devices may require (re-) write operations evey now  and  then
  to avoid data loss.

- some devices must never be wrtitten to when the board resets / loses
  power.

- some devices may be "banked"; right now, for example,  we  have  no
  way to access flash devices on systems that need bank switching.

> - memmapped flash can be be read directly on the memory bus; but
> writing requires a special routine
> - Large variation of size, from a few kbytes up to thousands of gigabytes.
> - Some devices are typically partitioned for convenience
> - speed differences
> - large number of

of ???

> The technology varies wildly, but they are all storage devices which
> store of an ordered sequence of bytes.  In every device, the address
> of a single item of data can be boiled down to a single integer.

...assuming your "integer" type has enough bits to address any byte.

> Take a look at the following interface.  For *most* commands; how well
> does this is this api encapsulate those differences for common
> commands?  Assume that device specific commands still exist for things
> that don't fit well into the model.  ie. block erase and protect
> commands.

I don't doubt that you can come up with aninterface that fits more or
less nicely on oll possible tyes of storage media. After all, a  file
is a file is a file, as we all have learnt - haven't we?

IN addition to your own fun inh  designing  nice  interfaces,  please
also  keep  in  minde  the mental welfare of the normal end user, who
thinks of "flash memory" as some simple thing where you can just read
data from.

> open(device) # Prepare for read/write operation
> seek(distance, abs_flag)  # Relative or absolute seek
> read(buffer, count)
> write(buffer, count)
> close() # Operation finished; sync any pending buffers back to disk.

Please keep in mind that this is a boot loader, not an  OS.  One  im-
portant  point  is, and always has been, to keep the memory footprint
small. I often sacrificed beautiful code  for  an  uglier,  but  much
smaller implementation. And I guess I will (have to) do this again.

> Notes:
>    - assume device can only be opened once.  ie. it's a bug to call open() twice

Why?

>    - this could be used by commands like mm, md, bootm, etc.  I'm not
> trying to design a full control interface (protect, erase, etc).

Why not? I'm not willing to see such functions dropped.

>    - common commands would typically call open(), seek(),
> read/write(), read/write(), ..., close() before returning to user.
> ie. device would *not* be left open after command completes.

Sounds like a lot of code to implement (code size) and run (execution
times).

>    - should be suitable for partition access too
>    - read/write commands are expected to transparently handle block
> boundaries.  ie. if one byte is written to the middle of a block; the
> write hook should read the block, modify the byte, and keep it
> buffered until it either a read/write/seek() moves to another sector,
> or close() is called.
>    - and yes, I'm just using the each device as a file perspective.

> It's a well established abstraction, so why not here too?

Well, just to name one of the potential issues: U-Boot is designed to
make porting to new hardware as eassy as possible. So we want to have
serial console output as soon as possible. That means that very, very
early in the boot process you will have to read  the  environment  to
read  environment  variables like "baudrate" and some others. In this
stage, we usually don't have a regular stack, we have no BSS, and  we
have  no  writable  data  segment.  In  other  words, we don't have a
regular C environment, only a very primitve subset.  But  *all*  your
new  code  would  have  to  be able to run in this environment. Or we
would need duplicate implementations which is even worse than what we
have today. If you want, you can even go one step further  and  think
about NAND booting, where you have even more severe size restrictions
(for which we don't have a good solution yet).

I don't want to say it's impossible what you usggest, but I  have  to
admit  that  I  cannot see a way to implement this without redefining
the basics of the project.

> Thoughts?  Feel free to tell me if I'm flying too high in the
> stratosphere on this one.

I can't read your altimeter from here, but it seems you did take  off
(i. e. lose ground ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made machine language; all the rest is the work of man.

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/28/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701271419l8069e56nb06bb328cf85b8b7@mail.gmail.com> you wrote:

> > - large number of
>
> of ???

heh; brain fart... please ignore.  :)

>
> > The technology varies wildly, but they are all storage devices which
> > store of an ordered sequence of bytes.  In every device, the address
> > of a single item of data can be boiled down to a single integer.
>
> ...assuming your "integer" type has enough bits to address any byte.

yes.

>
> > Take a look at the following interface.  For *most* commands; how well
> > does this is this api encapsulate those differences for common
> > commands?  Assume that device specific commands still exist for things
> > that don't fit well into the model.  ie. block erase and protect
> > commands.
>
> > open(device) # Prepare for read/write operation
> > seek(distance, abs_flag)  # Relative or absolute seek
> > read(buffer, count)
> > write(buffer, count)
> > close() # Operation finished; sync any pending buffers back to disk.
>
> Please keep in mind that this is a boot loader, not an  OS.  One  im-
> portant  point  is, and always has been, to keep the memory footprint
> small. I often sacrificed beautiful code  for  an  uglier,  but  much
> smaller implementation. And I guess I will (have to) do this again.

May bootloaders use this type of interface.  OpenFirmware is a good
example.  RedBoot is another.  CFE does too.  I think it is a good and
well established abstraction regardless of whether it is an OS or a
bootloader.

> > Notes:
> >    - assume device can only be opened once.  ie. it's a bug to call open() twice
>
> Why?

Mostly to keep the use cases simple; but maybe I'm optimizing too
early.  I was thinking in terms of not needing to dynamically allocate
temporary buffers.

>
> >    - this could be used by commands like mm, md, bootm, etc.  I'm not
> > trying to design a full control interface (protect, erase, etc).
>
> Why not? I'm not willing to see such functions dropped.

Neither am I.

I'm not trying to design a one size fits all interface for all extra
device features.  The specific problem I want to tackle is to provide
a single hook point for attaching read/write commands to non-memmapped
devices.  I'm comfortable with keeping the existing device specific
commands for protect/erase/etc, (at least for now).

I'm going to do a trial implementation of that stuff discussed so far
so I can post patches for review.  At that point I'll be looking for
feedback to decide if this is a direction worth pursuing further.  If
so, then I'll take a look at the protect/erase/etc features

>
> >    - common commands would typically call open(), seek(),
> > read/write(), read/write(), ..., close() before returning to user.
> > ie. device would *not* be left open after command completes.
>
> Sounds like a lot of code to implement (code size) and run (execution
> times).

I don't think it will be; but I'll should just stop arguing here and
implement it.  It's the only way to actually know.

> > It's a well established abstraction, so why not here too?
>
> Well, just to name one of the potential issues: U-Boot is designed to
> make porting to new hardware as eassy as possible. So we want to have
> serial console output as soon as possible. That means that very, very
> early in the boot process you will have to read  the  environment  to
> read  environment  variables like "baudrate" and some others. In this
> stage, we usually don't have a regular stack, we have no BSS, and  we
> have  no  writable  data  segment.  In  other  words, we don't have a
> regular C environment, only a very primitve subset.  But  *all*  your
> new  code  would  have  to  be able to run in this environment. Or we
> would need duplicate implementations which is even worse than what we
> have today.

I'm not looking at rewriting all the device back end drivers.  I'm
only looking at the attachment to common commands.  I have no
intention to rip and replace the existing code for early access.

> I can't read your altimeter from here, but it seems you did take  off
> (i. e. lose ground ;-)

:-P

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>>> Notes:
>>>    - assume device can only be opened once.  ie. it's a bug to call
>>> open() twice
>>

I dont see why you should need to call any "open" routine
since the dataflash is active before u-boot has even started
and does not need any initialization sequence.

You load U-boot from the dataflash to the SDRAM
so any initialization needed by the dataflash is already
done before the first U-boot instruction is executed..

Thus you search for the dataflash at boot
if support is enabled and then initialize
the datastructures, and your done with it.

> I'm going to do a trial implementation of that stuff discussed so far
> so I can post patches for review.  At that point I'll be looking for
> feedback to decide if this is a direction worth pursuing further.  If
> so, then I'll take a look at the protect/erase/etc features

I don't think anything trivial should be merged.
It should be kept as a

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <009101c7437a$0d0ee6e0$01c4af0a@atmel.com> you wrote:
>
> I dont see why you should need to call any "open" routine
> since the dataflash is active before u-boot has even started
> and does not need any initialization sequence.
> 
> You load U-boot from the dataflash to the SDRAM
> so any initialization needed by the dataflash is already
> done before the first U-boot instruction is executed..

This may, or may not, be the case. We've been discussing this before.
For me, booting from dataflash is not a default  mode  operation  for
U-Boot.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
When some people discover the truth, they just can't  understand  why
everybody isn't eager to hear it.

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/29/07, Ulf Samuelsson <ulfs@atmel.com> wrote:
> >>> Notes:
> >>>    - assume device can only be opened once.  ie. it's a bug to call
> >>> open() twice
> >>
>
> I dont see why you should need to call any "open" routine
> since the dataflash is active before u-boot has even started
> and does not need any initialization sequence.

I'm thinking in terms of the open() routine providing a pointer to the
device data structure; either by allocating a new one or just
returning a preinitialized structure.  The point being that the device
driver can decide how to manage/map devices structures and the
relevant command won't care.  Open would most likely accept a string
argument which identifies the desired device.

I'm also thinking that if a device can accept multiple read or write
operations after a single setup command, then the setup command can be
issued in the open() routine.

> > I'm going to do a trial implementation of that stuff discussed so far
> > so I can post patches for review.  At that point I'll be looking for
> > feedback to decide if this is a direction worth pursuing further.  If
> > so, then I'll take a look at the protect/erase/etc features
>
> I don't think anything trivial should be merged.
> It should be kept as a

I'm not going to push for anything to be merged until I'm sure of the
approach, and until others agree.

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Andreas Schweigstill]

Hello!

Ulf Samuelsson schrieb:
> I dont see why you should need to call any "open" routine
> since the dataflash is active before u-boot has even started
> and does not need any initialization sequence.

There could be further initialization of Dataflash devices
at later time:
- Dataflash card may be plugged into the board when U-Boot is
   already running, e.g. for firmware updates.
- A Dataflash can be placed on an extension board which will
   be powered up later during system start-up. This could also
   require a Dataflash to be initialized later. Probably such
   open() function could check if the extension board is present
   and powered.

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701281833i5d595d83ua436f75c8b29e76@mail.gmail.com> you wrote:
> 
> I'm not looking at rewriting all the device back end drivers.  I'm
> only looking at the attachment to common commands.  I have no
> intention to rip and replace the existing code for early access.

Does that mean you suggest to have to different sets of accesor
functions, one for early boot and another one for later?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!            - Terry Pratchett, _Soul Music_

[U-Boot-Users] Atmel DataFlash hooks.

[Stefan Roese]

Hi Wolfgang,

On Friday 26 January 2007 22:25, Wolfgang Denk wrote:
> > My vote is to treat DataFlash like a block device, and make sure that
> > it supports byte-wide access.
>
> Treat DataFlash like a block device? That sounds wrong to me.

When we treat NAND like a "block device", then we should treat DataFlash like 
it too.

> I understand your concerns about the #ifdef mess, but this suggestion
> does not sound tempting either.

Yes, it will break existing board, that have some predefined environment 
variables to read/write/... the DataFlash. And the users of DataFlash would 
have to adapt to the new syntax.

Best regards,
Stefan

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

There is a mountain of stuff that should probably be reworked in
u-boot (notably the maze of #ifdefs), but all I've got is a small
spade.  So, I'll just pick things off as I come across them...

Issue: CONFIG_HAS_DATAFLASH hooks are invasive
Background: Atmel DataFlash is a serial FLASH device with an SPI
interface.  There is code in u-boot that pretends that it is
bus-addressable.

For all but a handful of boards, the commands in cmd_bootm.c,
cmd_flash.c and cmd_mem.c (md, mm, cp, bootm, etc) interface with bus
addressable memories.  However, when CONFIG_HAS_DATAFLASH is defined,
extra code is enabled to make it appear that SPI DataFlash is bus
addressable to those commands.

IMHO, pretending that a serial flash device occupies a range of bus
addresses is a bad precedence and a "Really Bad Idea".  It means that
every command that manipulates memory needs to have special hooks to
be aware of DataFlash.  The way the current hooks are implemented are
ugly and dangerous.  (search for CONFIG_HAS_DATAFLASH to see the
hooks).  Dangerous because code indentation is messed up which makes
the code flow hard to follow, and also it invites a great mess if
other non-bus-addressable memories are added in the same way.

The current hooks should be removed and the DataFlash support should
be reworked so it no longer pretends to be bus addressable memories.
This leaves the question, "then how should it be accessed?".  There
are other non-bus-addressable memories out there which have the same
problem.  For example, i2c eeproms, USB storage, CF, SCSI & IDE
drivers.  Currently USB storage, IDE, SCSI and MMC share the block
device infrastructure used by the filesystem drivers.  However it is
read-only at the moment (but I've got some patches to fix that).

Possible solutions:
1. Move DataFlash support over to the block device infrastructure and
add commands for direct manipulation of block devices.  This assumes
that it makes sense to look at a DataFlash device as just like any
other block device.
2. Create a new set of commands specifically for manipulating dataflash
3. Create an abstraction layer for accessing both bus addressable and
non bus addressable memories.  Add a naming convention for commands to
specify non-bus-addressable devices.  ie. "cp.b 00004000 DF:0000 100"
would copy 0x100 bytes from bus address 0x4000 to dataflash 0x0000.
(but I really don't think this is the route to go; far to complex.  I
don't think it is unreasonable to require a separate command to copy
to/from off-bus memories before comparing, booting, etc.)

and for completeness:
3. SImply remove the current hooks and leave DataFlash support out of mainline.
4. Grant is on drugs, do nothing.

Comments?  If I don't here anything, then I'll go ahead an generate a
patch to pull out the DataFlash hooks.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Peter.Pearse]

 I bottom post

> -----Original Message-----
> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf 
> Of Grant Likely
> Sent: 26 January 2007 08:45
> To: uboot
> Cc: Peter Pearse; Peter Menzebach
> Subject: Atmel DataFlash hooks.
> 
> Issue: CONFIG_HAS_DATAFLASH hooks are invasive
> Background: Atmel DataFlash is a serial FLASH device with an 
> SPI interface.  There is code in u-boot that pretends that it 
> is bus-addressable.
> Possible solutions:
> 1. Move DataFlash support over to the block device 
> infrastructure and add commands for direct manipulation of 
> block devices.  This assumes that it makes sense to look at a 
> DataFlash device as just like any other block device.
Grant

My first reaction is.

If it walks like a block device & quacks like a block device
- it's a block device.

However I've forwarded to Hamid (author of dataflash.c)
&& Rick (AT91RM9200DK maintainer) for their opinions.

In the absence of any evidence otherwise, I just assume Atmel wanted to show

how neatly DataFlash can be treated as bus addressable.....

Regards

Peter

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701260044t56b5cfd6h98ac591f7edc02b9@mail.gmail.com> you wrote:
>
> Comments?  If I don't here anything, then I'll go ahead an generate a
> patch to pull out the DataFlash hooks.

Please don't rip out working code (even if ugly) as long as you don't
have a working (= tested) replacement.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I knew then (in 1970) that a 4-kbyte minicomputer would cost as much
as a house. So I reasoned  that  after  college,  I'd  have  to  live
cheaply in an apartment and put all my money into owning a computer."
      - Apple co-founder Steve Wozniak, EE Times, June 6, 1988, pg 45

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701260044t56b5cfd6h98ac591f7edc02b9@mail.gmail.com> you wrote:
> >
> > Comments?  If I don't here anything, then I'll go ahead an generate a
> > patch to pull out the DataFlash hooks.
>
> Please don't rip out working code (even if ugly) as long as you don't
> have a working (= tested) replacement.

hehehe; even if I write such a patch, I would need to also convince
you to pick it up.  :)

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <528646bc0701261124p671ee3a7qc42f1b747b3b1c1a@mail.gmail.com> you wrote:
>
> > Please don't rip out working code (even if ugly) as long as you don't
> > have a working (= tested) replacement.
> 
> hehehe; even if I write such a patch, I would need to also convince
> you to pick it up.  :)

Indeed. And having no replacement that is obviously better  than  the
replaced code is a pretty sure method to have a patch rejected. Ugly,
but working code is IMHO still better than no code at all.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
My challenge to the goto-less programmer  is  to  recode  tcp_input()
without any gotos ... without any loss of efficiency (there has to be
a catch).                                             - W. R. Stevens

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc0701261124p671ee3a7qc42f1b747b3b1c1a@mail.gmail.com> you wrote:
> >
> > hehehe; even if I write such a patch, I would need to also convince
> > you to pick it up.  :)
>
> Indeed. And having no replacement that is obviously better  than  the
> replaced code is a pretty sure method to have a patch rejected. Ugly,
> but working code is IMHO still better than no code at all.

agreed

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs@dof.se> wrote:

First, a clarification.  I'm coming at this from the point of view of
establishing some architectural clarity.  Currently, the primary way
to access non-memory-mapped memories is via the block device
infrastructure (include/part.h, disk/part.c).  DataFlash is currently
a major exception and I see no reason to treat it as such.

My goal is to attack the current #ifdef hell in u-boot.  DataFlash
just happens to be the first thing I want to clean up.  I'm pretty
sure I'm going to trod on all kinds of toes as I go through stuff.

> Are you prepared to make the fixes so that all Atmel development kits
> are supported by your patches.
> This means taking the atmnel patches from the Atmel ftp site and
> test them thoroughly on the appropriate boards.

No.  If the board port is not in mainline, then it is the
responsibility of the port maintainer to keep it synced.

For the stuff that *is* in mainline, I will of course make sure that
the patches compile, but I cannot test them.  I do not have the
hardware to do so, nor will I spend the time to test boards that I
have absolutely no involvement with.

Once again, this is about establishing some level of architectural
clarity; in this case about how to access non memory mapped memories.
That *requires* discussion and involvement of the board port
maintainers.

>
> AT91SAM9260EK
> AT91SAM9261EK
> AT91SAM9263EK
> AT91RM9200DK
> AT91RM9200EK
> ATR0663EK
> AT91SAM9XE
> and probably several AVR32 boards currently in design.
>
> I assume there are multiple customer boards that rely on this as well.

Even if the owner of the non-mainline boards is not able/willing to
migrate to internal u-boot changes, older u-boot releases will of
course continue to work as is.  However, I refuse to be handcuffed to
old design and code if in hindsight it was poorly done.  I reference
"linux-2.6/Documentation/stable_api_nonsense.txt" here as support.

>
> Will you patches support byte writes?

I don't see any reason why not.  Need to settle on a design first.

> > 3. Create an abstraction layer for accessing both bus addressable and
> > non bus addressable memories.  Add a naming convention for commands to
> > specify non-bus-addressable devices.  ie. "cp.b 00004000 DF:0000 100"
> > would copy 0x100 bytes from bus address 0x4000 to dataflash 0x0000.
> > (but I really don't think this is the route to go; far to complex.  I
> > don't think it is unreasonable to require a separate command to copy
> > to/from off-bus memories before comparing, booting, etc.)
> >
>
> I think it is unreasonable to require that users of dataflash
> has a more complex way of handling that memory.
> Computers are good at handling these things, humans are not.

Changes to the load sequence can easily be handled in environmental
boot scripts.  Regardless of how it is changed, the command format
should not stay as-is (as I think it is a bad precedence to pretend it
has a bus address).  Hence it does require changes to how boards are
booted (like your example solution below).

>
> Woudl you accept a patch that required bus addressable devices
> to have a prefix?
> "cp.b BAD:00004000 0000 100"

As I said; I don't particularly like this from an architectural
standpoint.  However, if it was done in a way that was *generic* (ie.
any memory device could register to use it) then I would be cool with
it.  If it's just another mess of device specific #ifdefs in the
memory access routines then I violently disagree.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs@dof.se> wrote:
> Grant Likely wrote:
> > On 1/26/07, Ulf Samuelsson <ulfs@dof.se> wrote:
> >
> >> Are you prepared to make the fixes so that all Atmel development kits
> >> are supported by your patches.
> >> This means taking the atmnel patches from the Atmel ftp site and
> >> test them thoroughly on the appropriate boards.
> >
> > No.  If the board port is not in mainline, then it is the
> > responsibility of the port maintainer to keep it synced.
> >
>
> Now with the new approach to introducing patches,
> I think the SAM9 patches should be sent in soon
> and you will have a significant number of boards
> that will break if you screw up.

Just because I write the patches doesn't mean they get accepted.  They
need to be acked by someone who has tested them first.  I'm offering
to take on the workload of writing the patches, but I cannot take on
the testing.  A number of the changes that I'm making right now (not
just DataFlash) affect every single board, but I cannot test them all.
 Best I can do is make sure it works on the handful of boards I do
have, post the patches for others to test, and only request inclusion
in mainline when nobody reports problems with them.

>
> > For the stuff that *is* in mainline, I will of course make sure that
> > the patches compile, but I cannot test them.  I do not have the
> > hardware to do so, nor will I spend the time to test boards that I
> > have absolutely no involvement with.
> >
>
> That sound like a great idea, introduce significant modifications
> without testing...

The mods I'm interested in are the architectural changes which I can
and will test.  The DataFlash changes are collateral damage.  The
alternative for me is to break dataflash support without even
attempting to providing a solution.

>
> I think you should spend time on modifying things you *can* test.

Then how does *anybody* attempt to fix common code?  Nobody can test
all platforms.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>> Now with the new approach to introducing patches,
>> I think the SAM9 patches should be sent in soon
>> and you will have a significant number of boards
>> that will break if you screw up.
>
> Just because I write the patches doesn't mean they get accepted.  They
> need to be acked by someone who has tested them first.  I'm offering
> to take on the workload of writing the patches, but I cannot take on
> the testing.  A number of the changes that I'm making right now (not
> just DataFlash) affect every single board, but I cannot test them all.
> Best I can do is make sure it works on the handful of boards I do
> have, post the patches for others to test, and only request inclusion
> in mainline when nobody reports problems with them.
>

I beleive a more proper approach is that
If you cannot test the patches yourself, then you need to wait
until someone confirms that the patch is actually working.

If noone tests the patch, that is an indication that noone is interested.

>>> For the stuff that *is* in mainline, I will of course make sure that
>>> the patches compile, but I cannot test them.  I do not have the
>>> hardware to do so, nor will I spend the time to test boards that I
>>> have absolutely no involvement with.
>>>
>>
>> That sound like a great idea, introduce significant modifications
>> without testing...
>
> The mods I'm interested in are the architectural changes which I can
> and will test.  The DataFlash changes are collateral damage.  The
> alternative for me is to break dataflash support without even
> attempting to providing a solution.
>
>>
>> I think you should spend time on modifying things you *can* test.
>
> Then how does *anybody* attempt to fix common code?  Nobody can test
> all platforms.

No, but you started off by saying you specifically are focusing on 
dataflash,
and then you need to test on the primary target for the dataflash
which is the AT91 series.

> Cheers,
> g.

Best Regards,
Ulf Samuelsson

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs@atmel.com> wrote:
>
> >> Now with the new approach to introducing patches,
> >> I think the SAM9 patches should be sent in soon
> >> and you will have a significant number of boards
> >> that will break if you screw up.
> >
> > Just because I write the patches doesn't mean they get accepted.  They
> > need to be acked by someone who has tested them first.  I'm offering
> > to take on the workload of writing the patches, but I cannot take on
> > the testing.  A number of the changes that I'm making right now (not
> > just DataFlash) affect every single board, but I cannot test them all.
> > Best I can do is make sure it works on the handful of boards I do
> > have, post the patches for others to test, and only request inclusion
> > in mainline when nobody reports problems with them.
> >
>
> I beleive a more proper approach is that
> If you cannot test the patches yourself, then you need to wait
> until someone confirms that the patch is actually working.
>
> If noone tests the patch, that is an indication that noone is interested.

Fair enough.  I'm still going to push for change though.  :)

> >>> For the stuff that *is* in mainline, I will of course make sure that
> >>> the patches compile, but I cannot test them.  I do not have the
> >>> hardware to do so, nor will I spend the time to test boards that I
> >>> have absolutely no involvement with.
> >>>
> >>
> >> That sound like a great idea, introduce significant modifications
> >> without testing...
> >
> > The mods I'm interested in are the architectural changes which I can
> > and will test.  The DataFlash changes are collateral damage.  The
> > alternative for me is to break dataflash support without even
> > attempting to providing a solution.
> >
> >>
> >> I think you should spend time on modifying things you *can* test.
> >
> > Then how does *anybody* attempt to fix common code?  Nobody can test
> > all platforms.
>
> No, but you started off by saying you specifically are focusing on
> dataflash,
> and then you need to test on the primary target for the dataflash
> which is the AT91 series.

Then I apologies and ask for forgiveness.  I want to see some of the
crazy side cases removed from the generic routines (and replaced with
generic hooks where appropriate).  I should have couched it more in
those terms when I first brought it up.

Plus, looking deeper there are similar issues with MMC and flash
writing which can probably be cleaned up at the same time (as
discussed in a previous email)

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

>>> Then how does *anybody* attempt to fix common code?  Nobody can test
>>> all platforms.
>>
>> No, but you started off by saying you specifically are focusing on
>> dataflash,
>> and then you need to test on the primary target for the dataflash
>> which is the AT91 series.
>
> Then I apologies and ask for forgiveness.  I want to see some of the
> crazy side cases removed from the generic routines (and replaced with
> generic hooks where appropriate).

Why?
Have you done any cost benefit analysis to the rest of the community?
What will the world gain by such a change?

> I should have couched it more in
> those terms when I first brought it up.
>

From my point of view, dataflash is the main case, and
everything else is a side case.
I do not see any benefit in changing the MMI for dataflash.
I rather see changes which will make dataflash more similar
in use to std parallell flash.
In my u-boot I can compare dataflash to SDRAM etc.


> Plus, looking deeper there are similar issues with MMC and flash
> writing which can probably be cleaned up at the same time (as
> discussed in a previous email)


>
> Cheers,
> g.

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Grant Likely]

On 1/26/07, Ulf Samuelsson <ulfs@atmel.com> wrote:
> >> No, but you started off by saying you specifically are focusing on
> >> dataflash,
> >> and then you need to test on the primary target for the dataflash
> >> which is the AT91 series.
> >
> > Then I apologies and ask for forgiveness.  I want to see some of the
> > crazy side cases removed from the generic routines (and replaced with
> > generic hooks where appropriate).
>
> Why?
> Have you done any cost benefit analysis to the rest of the community?
> What will the world gain by such a change?

Simpler code, easier to maintain code, easier to add new storage
devices, easier to have boards with multiple different storage
technologies, smaller u-boot binaries.

Let me flip the question around: Do you like the current
implementation where each storage technology (MMC, memmapped flash,
and DataFlash; see my reply to Wolfgang) has it's own set of hooks in
each memory access command?

How about this:
1. start with *not* changing the mmi and u-boot continues to pretend
that DataFlash and MMC devices are memmapped.  I may not like it, but
I understand your position on this.
2. add a common interface for non-RAM and non-memorymapped devices
that provides a single interface for commands like cp, md, bootm, etc
to find out if an address is 'special' and what routines it should
call to access them.
3. First migrate memmapped flash devices to the new interface to prove
it is workable.
4. Second migrate over either MMC or DataFlash devices; based on who
is able to provide test support (this does *not* touch the low level
code.  It introduces a shim between the commands and the device
routines)
5. Migrate the remaining hooks.  At this point, all the command
functions should only have a single hook for access non-memmapped,
non-RAM devices.  All commands should now work on all devices.  ie. md
command can access MMC devices, something it cannot do now.

Of course there is design work that needs to be done, but in this
stages approach, the first patch will show how the common interface is
designed.

>
> > I should have couched it more in
> > those terms when I first brought it up.
> >
>
> >From my point of view, dataflash is the main case, and
> everything else is a side case.

I only see it as a side case due to the way it is implemented.  Now
that I've looked deeper into the other commands, the same argument
goes for MMC devices.  If the implementation changes to use a common
interface for these similar devices then it's not a side case any
longer in my mind.

> I do not see any benefit in changing the MMI for dataflash.
> I rather see changes which will make dataflash more similar
> in use to std parallell flash.
> In my u-boot I can compare dataflash to SDRAM etc.
>

Fair enough

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely at secretlab.ca
(403) 399-0195

[U-Boot-Users] Atmel DataFlash hooks.

[Ulf Samuelsson]

Grant Likely wrote:
> On 1/26/07, Ulf Samuelsson <ulfs@atmel.com> wrote:
>>>> No, but you started off by saying you specifically are focusing on
>>>> dataflash,
>>>> and then you need to test on the primary target for the dataflash
>>>> which is the AT91 series.
>>>
>>> Then I apologies and ask for forgiveness.  I want to see some of the
>>> crazy side cases removed from the generic routines (and replaced
>>> with generic hooks where appropriate).
>>
>> Why?
>> Have you done any cost benefit analysis to the rest of the community?
>> What will the world gain by such a change?
>
> Simpler code, easier to maintain code, easier to add new storage
> devices, easier to have boards with multiple different storage
> technologies, smaller u-boot binaries.
>
> Let me flip the question around: Do you like the current
> implementation where each storage technology (MMC, memmapped flash,
> and DataFlash; see my reply to Wolfgang) has it's own set of hooks in
> each memory access command?
>
> How about this:
> 1. start with *not* changing the mmi and u-boot continues to pretend
> that DataFlash and MMC devices are memmapped.  I may not like it, but
> I understand your position on this.
> 2. add a common interface for non-RAM and non-memorymapped devices
> that provides a single interface for commands like cp, md, bootm, etc
> to find out if an address is 'special' and what routines it should
> call to access them.
> 3. First migrate memmapped flash devices to the new interface to prove
> it is workable.
> 4. Second migrate over either MMC or DataFlash devices; based on who
> is able to provide test support (this does *not* touch the low level
> code.  It introduces a shim between the commands and the device
> routines)
> 5. Migrate the remaining hooks.  At this point, all the command
> functions should only have a single hook for access non-memmapped,
> non-RAM devices.  All commands should now work on all devices.  ie. md
> command can access MMC devices, something it cannot do now.
>
> Of course there is design work that needs to be done, but in this
> stages approach, the first patch will show how the common interface is
> designed.
>

Now you are getting there...
This is a workable approach.


>>
>>> I should have couched it more in
>>> those terms when I first brought it up.
>>>
>>
>>> From my point of view, dataflash is the main case, and
>> everything else is a side case.
>
> I only see it as a side case due to the way it is implemented.  Now
> that I've looked deeper into the other commands, the same argument
> goes for MMC devices.  If the implementation changes to use a common
> interface for these similar devices then it's not a side case any
> longer in my mind.
>
>> I do not see any benefit in changing the MMI for dataflash.
>> I rather see changes which will make dataflash more similar
>> in use to std parallell flash.
>> In my u-boot I can compare dataflash to SDRAM etc.
>>
>
> Fair enough
>
> Cheers,
> g.

Best Regards,
Ulf Samuelsson
ulf at atmel.com
GSM:  +46 (706) 22 44 57
Tel:     +46  (8) 441 54 22
Fax:     +46 (8) 441 54 29
Mail: Box 2033  174 02 Sundbyberg
Visit: Kavalleriv?gen 24
          174 58 Sundbyberg'
Sweden

[U-Boot-Users] Atmel DataFlash hooks.

[Stefan Roese]

Hi Ulf,

On Saturday 27 January 2007 00:01, Ulf Samuelsson wrote:
> > Then I apologies and ask for forgiveness.  I want to see some of the
> > crazy side cases removed from the generic routines (and replaced with
> > generic hooks where appropriate).
>
> Why?
> Have you done any cost benefit analysis to the rest of the community?
> What will the world gain by such a change?

More readable and less error-prone code.

> > I should have couched it more in
> > those terms when I first brought it up.
> >
> >
> >From my point of view, dataflash is the main case, and
>
> everything else is a side case.
> I do not see any benefit in changing the MMI for dataflash.
> I rather see changes which will make dataflash more similar
> in use to std parallell flash.
> In my u-boot I can compare dataflash to SDRAM etc.

You can do this with NAND flash too. You just have to copy it to SDRAM before 
comparing.

Best regards,
Stefan

[U-Boot-Users] Atmel DataFlash hooks.

[Peter.Pearse]

 

> -----Original Message-----
> From: glikely at gmail.com [mailto:glikely at gmail.com] On Behalf 
> Of Grant Likely
> Sent: 26 January 2007 20:27
> To: Ulf Samuelsson
> Cc: uboot; Peter Menzebach; Peter Pearse
> Subject: Re: [U-Boot-Users] Atmel DataFlash hooks.
> 
> >
> > > For the stuff that *is* in mainline, I will of course 
> make sure that 
> > > the patches compile, but I cannot test them.  I do not have the 
> > > hardware to do so, nor will I spend the time to test 
> boards that I 
> > > have absolutely no involvement with.
> > >
> >

I propose that part of each gatekeepers checking for a (non-trivial) patch
is to
request & collate testing of the patch to ensure it works
on TBD % of the affected boards.

The patch would not be offered to the main tree until such testing 
has been done

Peter

[U-Boot-Users] Atmel DataFlash hooks.

[Stefan Roese]

On Monday 29 January 2007 14:44, Peter.Pearse wrote:
> I propose that part of each gatekeepers checking for a (non-trivial) patch
> is to
> request & collate testing of the patch to ensure it works
> on TBD % of the affected boards.

Yes. This should definitely be the gatekeepers/custodians responsibility, to 
check if these patches have been tested successfully (and _not_ Wolfgangs).

> The patch would not be offered to the main tree until such testing
> has been done

ACK.

Best regards,
Stefan

[U-Boot-Users] Atmel DataFlash hooks.

[Wolfgang Denk]

In message <200701291547.44180.sr@denx.de> you wrote:
> 
> Yes. This should definitely be the gatekeepers/custodians responsibility, to 
> check if these patches have been tested successfully (and _not_ Wolfgangs).

This is one of the idea behind the custodians: it is expected that
they have access to at least some of the related hardware.

For example, I don't even have access to a system with Dataflash on
it, so how should I test it?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"There is such a fine line between genius and stupidity."
- David St. Hubbins, "Spinal Tap"

[U-Boot-Users] Atmel DataFlash hooks.

[Stefan Roese]

Hi Grant,

On Friday 26 January 2007 20:02, Grant Likely wrote:
> My goal is to attack the current #ifdef hell in u-boot.  DataFlash
> just happens to be the first thing I want to clean up.

I welcome such attempts very much. This #ifdef hell is annoying me more and 
more (even if I am responsible for it too :-().

But we have to be careful here. We can't just rip out existing interface 
without supplying replacements.

> I'm pretty 
> sure I'm going to trod on all kinds of toes as I go through stuff.

Yes, you will... ;-)

I'm right now catching up on the discussion from last week and I have to 
admit, that the DataFlash handling always annoyed me too, even (or possibly 
because) I never used it personally before. I would compare this DataFlash 
most with a NAND Flash, so why not as you already suggested use something 
like:

dflash info
dflash device
dflash read
dflash write
...

Now I continue with the remaining 200 mails in this thread... ;-)

Best regards,
Stefan