[U-Boot-Users] [rfc] new spiflash subsystem

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 19:41 Mon 28 Jan     , Mike Frysinger wrote:
> On Monday 28 January 2008, Ulf Samuelsson wrote:
> > Unfortunately, this code seems useless, at least for the combination AT91 +
> > SPI flash. Some issues:
> >
> > I believe that the AT45 is not using the same command set as other
> > SPI flash memories. I think the commands need to be separated.
> 
> i already accounted for different command sets based on part family.
> 
> > AT45 is much more advanced than other SPI flash.
> 
> yes, but it still has a basic subset which can be used.
> 
> > Did you really test your code on the AT45 series?
> 
> it was the part i developed the code on originally (the 64mbit one).
> 
> > You assume, incorrectly, that all sector sizes are the same size.
> 
> that depends on what level you look at it.  sector 0 can be accessed in 
> pieces, but it can also be treated as one big sector the same as all the 
> others.  this is how i treated it.
> 
> > How do you do "byte writes" which is an important feature of the  AT45?
> 
> simple: i dont.  spi flash writing isnt something to be done constantly nor is 
> it fast, so i dont sweat getting maximum performance.
> 
> > Your code does not support DMA transfers, while the current dataflash code
> > runs DMA up to 50 Mbps.
> 
> so ?  the point of u-boot is to do everything in PIO mode.
> 
> > Erasing the entire SPI flash is generally stupid, since you store the
> > environment there. You typically also store the initial bootloader and
> > U-Boot.
> 
> so the user is stupid if they erase the entire flash ?  you could say the same 
> thing about any flash type.
> 
> > Very rarely you want to erase the complete flash ,and a protection
> > mechanism is needed to avoid accidental overwrites.
> > The current solution allows dataflash pages to be protected.

I disagree on some product you use a spi flash to store other code and
not nessarely store u-boot in it? (you can have 2 falsh)

> 
> yes, protection of pages (hardware and software) is missing.
> 
> > Typically you want to store data with a checksum,since relying
> > on the boot of the linux kernel to produce the error, will in my experience
> > make people confused and they will spend a lot of time barking up the wrong
> > tree.
> 
> ok ?  not sure how this is relevant to the topic at hand.
> 
> > There is a general problem with U-Boot which seems to assume
> > that there is more RAM than flash in the system.
> > How do you easily copy 256 MB from an SD-Card to an onboard 256 MB NAND
> > flash when the SDRAM is 64 MB?
> >
> > Today, you have to use 10 lines (U-Boot occupies 1 MB) and that is really
> > bad.
> >
> > The vanilla way of supporting storage devices is really wasteful in
> > resources, and you cannot compare two memory areas if the memory area is
> > larger than half the SDRAM size.
> 
> ok ?  u-boot is designed as a monitor to get the system bootstrapped and 
> execute something else.  it isnt an operating system, it doesnt get maximal 
> performance, and it isnt supposed to support all sorts of extended features.  
> what you describe as deficiency doesnt apply to the topic at hand and really 
> sounds like a basic design decision for u-boot.  if you want optimal 
> performance, use Linux.

I also disagree you may need the optimal performance, in some project I
need it.

Best Regards,
J.
> -mike



> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users