[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