From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Wed, 30 Jan 2008 01:16:14 +0100 Subject: [U-Boot-Users] [rfc] new spiflash subsystem References: <200801281500.34869.vapier@gentoo.org> <017901c8620a$d600f0c0$030514ac@atmel.com> <200801281941.13941.vapier@gentoo.org><20080129082814.GD8079@game.jcrosoft.org> <479F033E.20307@psyent.com> Message-ID: <00bd01c862d8$9d602140$070514ac@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >>>> 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. >>> > > I have valid reasons, better _requirements_, for erasing an > entire spi flash and have done so many times. I never realized > that I was stupid ... and for all these years! ;-) > >>>> 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) OK, let me rephrase the statement: It is stupid to allow the user to *accidently* erase the environment sector and the U-boot area The proposed user interface will do this, if you do not give any address parameters to the erase command. Best Regards Ulf Samuelsson