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

[Mike Frysinger]

please quote properly in your replies

On Tuesday 29 January 2008, Ulf Samuelsson wrote:
> > 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.
>
> ==> And this is not a good approach, you want the S/W to use the
>         first 256 kB to store initial boot, U-boot and environment.
>         The AT91SAM9 chips will use the first 8 kB sector
>         for the AT91bootstrap, and that should have protection separate
> from U-Boot code. AVR32 boot ROM will boot from a higher address and use
> the 8 kB sector at address zero as environment.
>         Both will need to have a S/W partitioning scheme added with
>         separate protection for each partition.
>         This partioning scheme exists today.

sorry, i didnt mean to imply i thought this limitation was something to be 
written in stone.  i understand perfectly why you would want this 
flexibility, so i can take a look.  rather than making general statements, 
can you please provide a concrete list of all relevant examples you know of.

> > 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.
>
> ==> Which means that you want to impose an arbitary limit which
>         currently does not exist in U-Boot.
>         You also increase startup time, which is a critical parameter for
> many customers.

uhh, what ?  you're telling me that customers do a SPI write in u-boot 
everytime they boot up ?  that just sounds stupid and your customers need to 
rethink their system.  "critical boot time" and "spi flash writing" dont 
belong in the same sentence :P

> > 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.
>
> ==> This is not how the dataflash support is implemented in U-Boot today.
>         Current implementation is using DMA.

then i'm afraid your implementation is wrong.  DMA is board/cpu-specific and 
there's no way that can be represented in a general framework.  in fact, when 
i was researching how to support SPI dataflash originally, i saw the 
dataflash code in u-boot and found it to be worthless in terms of re-use.  as 
Haavard points out though, by using a more general SPI transfer layer, you 
can still (wrongly imo) do DMA transfers.

> > 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.
>
> ==>
>         No, but U-Boot should make them aware of consequences,
>         so they do not do this by mistake.
>         You normally can't remove the bootloader from a parallel flash
>         without unprotecting it first.

providing sector protection is a different topic from removing functionality.  
nand flash provides the ability to erase the whole flash, so are you going to 
lobby them to drop that too ?

> > 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.
>
> ==> Just pointing out that the user interface is missing features.

what features ?  checksums is not the domain of the flash layer unless the 
flash media itself requires it (like NAND and ECC/bad-blocks).  parallel/SPI 
flash provide no such thing, so adding a completely software checksum layer 
is inappropriate.  if you want checksums, add them yourself in your board 
code.

> > 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.
>
> ==> Yes, it is a basic design decision, and with huge flash memories,
>         it is becoming flawed. Thats why I think we should rethink how
>         we do things, before we rewrite the code.
>
>         Programming the internal flash memory in an efficient
>         way is really the core of a bootloader, not an extended feature.
>         Programming time is a critical parameter for large volume
> production so if you can avoid booting Linux, this is probably a good
> thing.

not relevant to the thread.  please drop any further comments on the topic.  
if you want to re-architect u-boot, start a new thread.

> ==> My conclusion remains, that I do not see why anyone using
>         dataflash in the current U-boot would want to switch to the
> proposed implementation, which will reduce performance and functionality,
> and increase risk of errors.

do you not understand how the software development process works ?  i post a 
new framework, asking for feedback.  that doesnt mean it is perfect the first 
time through and that everyone should start using it RIGHT NOW.  please 
exercise some patience.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080129/bd8300f9/attachment.pgp