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
- print contents of the dataflash
We should add a "sf dump" command similar to the existing "nand dump" command.
- compare contents of the dataflash with SDRAM.
This is one of the controversial points, I believe.
- 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?
- 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.
- 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.
- 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