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.