[U-Boot] flash erasing: len alignment

[U-Boot] flash erasing: len alignment

[Mike Frysinger]

the different flash subsystems dont exactly all operate the same, specifically 
when it comes to erasing.  some require you to specify lengths that are 
aligned exactly to the erase sector size whereas others are much more 
intelligent: they automatically round up for you.  is there any real arguments 
for a particular method ?

personally, i prefer the latter behavior as it makes scripting a hell of a lot 
easier.  for example, if i want to load a binary file into a flash, the 
loading process (i.e. tftp) will automatically set $(filesize) which i can 
then use as the erase/write length.  otherwise i need to either manually do 
the rounding up based on sector size, or i have to assume ahead of time that 
the file will never exceed a certain max size and use that hardcoded value 
(which leads to wasted time erasing sectors that never actually get used and 
unable to use the same code across multiple platforms).

here's an example change to the SPI flash driver:
--- a/u-boot-2008.10/drivers/mtd/spi/stmicro.c
+++ b/u-boot-2008.10/drivers/mtd/spi/stmicro.c
@@ -262,12 +262,12 @@ int stmicro_erase(struct spi_flash
 
 	sector_size = stm->params->page_size * stm->params->pages_per_sector;
 
-	if (offset % sector_size || len % sector_size) {
+	if (offset % sector_size) {
 		debug("SF: Erase offset/length not multiple of sector size\n");
 		return -1;
 	}
 
-	len /= sector_size;
+	len = len / sector_size + !!(len % sector_size);
 	cmd[0] = CMD_M25PXX_SE;
 	cmd[2] = 0x00;
 	cmd[3] = 0x00;
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081211/ba1a2e9c/attachment.pgp 

[U-Boot] flash erasing: len alignment

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200812110431.35694.vapier@gentoo.org> you wrote:
> 
> the different flash subsystems dont exactly all operate the same, specifically 
> when it comes to erasing.  some require you to specify lengths that are 
> aligned exactly to the erase sector size whereas others are much more 
> intelligent: they automatically round up for you.  is there any real arguments 
> for a particular method ?

Flash commands *should* support two formats:

1) sector (and bank) numbers, for example:

	erase 1:3-6

2) start and end address, for example:

	erase 40000000 4003FFFF

3) start address and length, for example:

	erase 40000000 +40000

The idea is that addresses (start and end address) have to  be  exact
and  match  sector  boundaries  as  needed by the flash device, while
length is handled intelligently, i. e. to erase one  sector  you  can
write

	erase 40000000 +1

Sector and bank numbers have to be exact, too, of course.

> personally, i prefer the latter behavior as it makes scripting a hell of a lot 
> easier.  for example, if i want to load a binary file into a flash, the 
> loading process (i.e. tftp) will automatically set $(filesize) which i can 
> then use as the erase/write length.  otherwise i need to either manually do 
> the rounding up based on sector size, or i have to assume ahead of time that 
> the file will never exceed a certain max size and use that hardcoded value 
> (which leads to wasted time erasing sectors that never actually get used and 
> unable to use the same code across multiple platforms).

That's why the "+length" method was added.

> here's an example change to the SPI flash driver:
> --- a/u-boot-2008.10/drivers/mtd/spi/stmicro.c
> +++ b/u-boot-2008.10/drivers/mtd/spi/stmicro.c
> @@ -262,12 +262,12 @@ int stmicro_erase(struct spi_flash
>  
>  	sector_size = stm->params->page_size * stm->params->pages_per_sector;
>  
> -	if (offset % sector_size || len % sector_size) {
> +	if (offset % sector_size) {
>  		debug("SF: Erase offset/length not multiple of sector size\n");
>  		return -1;
>  	}
>  
> -	len /= sector_size;
> +	len = len / sector_size + !!(len % sector_size);

Except for the notation, which I find not so easy to read, that's OK
with me. Is a documentation update needed?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"May your future be limited only by your dreams."
- Christa McAuliffe

[U-Boot] flash erasing: len alignment

[Mike Frysinger]

On Thursday 11 December 2008 05:22:49 Wolfgang Denk wrote:
> 	erase 40000000 +1

when was this notation added ?  i'm not familiar with it ... but until 
recently, i was living with u-boot-1.1.6 ...

and any tips on which flash systems are known to support this syntax ?  i can 
look at fixing the ones that i use that dont use this syntax ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081211/9e0d9ade/attachment.pgp 

[U-Boot] flash erasing: len alignment

[Wolfgang Denk]

Dear Mike,

In message <200812110537.04572.vapier@gentoo.org> you wrote:
> 
> On Thursday 11 December 2008 05:22:49 Wolfgang Denk wrote:
> > 	erase 40000000 +1
> 
> when was this notation added ?  i'm not familiar with it ... but until 
> recently, i was living with u-boot-1.1.6 ...

Then you have that code:

...
Changes for U-Boot 1.1.3:
======================================================================
 
* Add new argument format for flash commands to allow for usage like
  "erase $(addr) +$(filesize)", i. e. a size argument can be used and
  U-Boot will automaticially find the end of the corresponding sector.
...

> and any tips on which flash systems are known to support this syntax ?  i can 
> look at fixing the ones that i use that dont use this syntax ...

I know it's working on NOR flash.

I am pretty sure that it doesn't work that way on NAND yet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If you're not part of the solution, you're part of the problem.