[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[Haavard Skinnemoen]

Ulf Samuelsson wrote:
> ons 2009-01-07 klockan 21:56 +0100 skrev Jean-Christophe
> PLAGNIOL-VILLARD:
> > Hi,
> > 
> > 	The AT91 arch use a at45 driver design to be show as a parallel flash
> > 	but it's a spi flash.
> > 
> > 	Haavard add a new spi flash framework which support the dataflash
> > 	so the current driver is mark as *depracated* and plan to be remove
> 
> There is very limited support for the flash in the new spi driver.
> so most things you would like to do with a flash is not supported

Yes, it is a bit minimal right now. But it should be fairly easy to
extend once we know what the requirements are.

Now, the current driver does work fairly well for my purposes, so I
won't promise anything about when I can get around to extend the
driver. But it shouldn't be too difficult to do for someone who has an
itch to scratch.

> I would like to have capabilities to
> 
> 1) print contents of the dataflash

We should add a "sf dump" command similar to the existing "nand dump"
command.

> 2) compare contents of the dataflash with SDRAM.

This is one of the controversial points, I believe.

> 3) Automatically add a CRC when the dataflash is written
> 	based on an environment variable "crc-check"

What kind of CRC and where should it be placed?

> 4) Verify that the CRC is correct.

Same issue.

> 5) high granularity read/writes
> 	The dataflash can easily support byte write.

Supported by the current driver, I believe. Erase still operates on full
pages, however, and I don't think there's anything to do about that.

> 6) Support partitions for 
> 	bootstrap
> 	environemnt
> 	u-boot
> 	kernel
> 	filesystem
>    in the boot dataflash.
>    additional dataflash should have other partitions.

We should add a partitioning layer on top of the current interface.

And even better solution would be to introduce a common flash interface
for NOR, NAND, SPI, etc. flash and add a partitioning layer on top of
that.

> 7) protection of partitions.

As well as protection of raw sectors, perhaps? A partitioning layer
could use such functionality to implement protection of partitions.

> I have my own patches for the memory commands
> to enable most of this but adding that to the
> cmd_mem driver was not accepted.

Yes, as you probably know, I for one think memory mapping of serial
devices is a bad idea.

> At that time it was promised that the new driver
> will not limit the functionality, and would
> only remove the use of direct addressing to the dataflash.

There's nothing in the driver or its architecture which limits any
functionality. If you need additional features, feel free to implement
them, or convince someone else to do it.

> The whole storage concept is really not working
> when storage becomes larger than the SDRAM.
> 
> How do you download an 128 MB image over the network
> to a machine with 64 MB SDRAM. - Major pain...
> You need to be able to TFTP to flash directly
> if you want to have an easy user interface.

Or start an operating system which can do all of this much faster and
with support for more protocols.

> That is likely to require another way of handling storage.
> and parameter parsing so you can do
> tftp mmc0:kernel linux-2.6.28
> or
> tftp df3:fs rootfs.arm.ext2

Now, I kind of like that syntax, but I seem to recall it got shot down
at some point too.

> The tftp can then write incoming packets to a caching driver
> and will delay fetching new packets when waiting for flash
> writes  to complete. Whn your storage is handled
> by a DMA controller, you should be able to implement
> this nicely.

Adding DMA support to the SPI driver shouldn't be a big deal, but I
don't see what it has to do with the user interface.

Also, caching sounds like something which comes dangerously close to
crossing the line between "boot loader" and "operating system". I don't
think it fits well into the current u-boot architecture.

Haavard