[U-Boot-Users] [rfc] new spiflash subsystem
Ulf Samuelsson
ulf at atmel.com
Wed Jan 30 01:39:56 CET 2008
please quote properly in your replies
==> Mailers can't quote properly when mails are sent as a text attachement.
Also quoting does not work when people are sending non-compliant mails
allowing long lines.
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
==> Should have been a line break there, the sentence belongs to the
statement below.
> > 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.
==> If a customer measures the boot speed, then slow non-DMA code is wrong
and fast code using DMA is right.
It may be that this should be in an Atmel specific driver location.
> > 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 ?
==> If you store the U-boot and environment in the NAND flash
then allowing users to destroy the functionality of the board
with a simple command is stupid.
NAND flash need partitioning and protection as well.
> > 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.
==> It is your opinion that it is inappropriate, others may disagree.
I believe that this should be a user choice.
I have seen this problem numerous times and users invariably
look in the wrong place to solve the problem, wasting their time
and eventually my time as well.
> > 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.
==> I *am* providing feedback, and the feedback is that the proposed code
will limit functionality compared to the current implementation,
and introduce dangerous features which I prefer not having in any boards
that I have to support.
It is moving u-boot in a direction which I belive is a dead end due to
the emergence of huge flash memories.
I do not mind that code like this is added to u-boot as long as
you do not build this in by default and that the current implemention
is available until the deficiencies in the proposed implementation is fixed.
-mike
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden
Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Technical support when I am not available:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
AVR32 Applications Group mailto:avr32 at atmel.com
http://www.avrfreaks.net/; http://avr32linux.org/
http://www.at91.com/ ; ftp://at91dist:distrib@81.80.104.162/
----- Original Message -----
From: "Mike Frysinger" <vapier at gentoo.org>
To: "Ulf Samuelsson" <ulf.samuelsson at atmel.com>
Cc: <u-boot-users at lists.sourceforge.net>
Sent: Tuesday, January 29, 2008 3:07 PM
Subject: Re: [U-Boot-Users] [rfc] new spiflash subsystem
More information about the U-Boot
mailing list