[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[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

	New board and cpu must use the new framework

	Only justify exception will be ack

	The actual only exception will the at91rm9200ek and bug fix

Best Regards,
J.

[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[Ulf Samuelsson]

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

I would like to have capabilities to

1) print contents of the dataflash
2) compare contents of the dataflash with SDRAM.
3) Automatically add a CRC when the dataflash is written
	based on an environment variable "crc-check"
4) Verify that the CRC is correct.
?5) high granularity read/writes
	The dataflash can easily support byte write.
6) Support partitions for 
	bootstrap
	environemnt
	u-boot
	kernel
	filesystem
   in the boot dataflash.
   additional dataflash should have other partitions.
7) 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.
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.

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.

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

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.



> 	New board and cpu must use the new framework
> 
> 	Only justify exception will be ack
> 
> 	The actual only exception will the at91rm9200ek and bug fix
> 
> Best Regards,
> J.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[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

[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[Mike Frysinger]

On Thursday 08 January 2009 03:21:24 Haavard Skinnemoen wrote:
> Ulf Samuelsson wrote:
> > 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.

rather than reinvent the wheel, just support redboot partitioning scheme.  but 
yeah, i dont think it makes much sense to add partitioning support to each 
flash layer and turn around and unify it all.  take the common layer approach 
first.

> > 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.

agreed here ... especially on systems that cant ...

> 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.

agreed here
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090108/dd7fbbe4/attachment.pgp 

[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[Jean-Christophe PLAGNIOL-VILLARD]

I agree with Haavard

> > 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.
Not necessarely you cn need to update or install the image from u-boot
> 
> > 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.
> 
I like too

Best Regards,
J.

[U-Boot] [ANNOUNCE] DATAFLASH DRIVER

[Jean-Christophe PLAGNIOL-VILLARD]

On 06:04 Thu 08 Jan     , Mike Frysinger wrote:
> On Thursday 08 January 2009 03:21:24 Haavard Skinnemoen wrote:
> > Ulf Samuelsson wrote:
> > > 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.
> 
> rather than reinvent the wheel, just support redboot partitioning scheme.  but 
> yeah, i dont think it makes much sense to add partitioning support to each 
> flash layer and turn around and unify it all.  take the common layer approach 
> first.
during my work on the nslu2 I'm preparing a part to support redboot
partitioning scheme

Best Regards,
J.