From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Date: Thu, 7 Feb 2013 16:22:28 -0600 Subject: [U-Boot] U-boot nand bug, read.part should fail In-Reply-To: (from hchapman-uboot@3gfp.com on Thu Feb 7 16:13:55 2013) References: <1360274360.27002.10@snotra> Message-ID: <1360275748.27002.11@snotra> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 02/07/2013 04:13:55 PM, Harvey Chapman wrote: > [ I started this conversation off-list before I joined the list. ] > > The idea is to add .part as a valid command suffix to nand read/write > so it would match nand erase.part. The code to implement it makes > "nand read.part" act identically to "nand read". > > On Feb 7, 2013, at 4:59 PM, Scott Wood > wrote: > > >> >> In fact, I think erase should be modified to deprecate > erase.part and make erase work like read does now. > >> > > >> > Erase used to work like read does. I deliberately changed it so > that typos (e.g. "nand erase $partition $fliesize") don't end up > erasing your entire partition or chip. > >> Ah, then maybe we should add .part to nand read for consistency? > I'm ok either way. > > > > That would get messy because it would be orthogonal to other > suffixes. Reading too much is not as harmful as > > Nothing would change other than do_nand() would treat "nand read" and > "nand read.part" identically. The only reason to add .part/.chip is if the unsuffixed versions no longer operate on entire partitions/chips. > > erasing too much. Writing too much can be bad, though. Perhaps we > should just eliminate the ability to do reads/writes without explicit > size (it already has problems with the size needing adjustment due to > bad blocks). > > I liked that I didn't have to specify the size. It's fine until you get a bad block in the partition, and you end up accessing the first block of the next partition (or getting "Attempt to read/write outside the flash area" if it's the last partition). Of course, fixing partition/chip accesses to account for this when determining size would be even better. :-) -Scott