From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Date: Thu, 11 Dec 2008 04:31:34 -0500 Subject: [U-Boot] flash erasing: len alignment Message-ID: <200812110431.35694.vapier@gentoo.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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