2008-12-10 10:15:25     Trouble with busybox 'dd' command.

Document created by Aaronwu Employee on Aug 14, 2013
Version 1Show Document
  • View in full screen mode

2008-12-10 10:15:25     Trouble with busybox 'dd' command.


Message: 66609   


We are currently using 'dd' to update versions of firmware on our board.


When we call dd:


dd if=/update.bin of=/dev/mtdblock3




We get an I/O error and page write failure early on, the system locks up.  When we reset, the linux image is partially overwritten, so naturally, it won't start. 


Is there a good alternative to 'dd' for updating the image in flash?  Netflash might be an option, but it seems it has a few bugs as well.






-Matt Gilg




2008-12-11 02:20:42     Re: Trouble with busybox 'dd' command.

Michele d'Amico (ITALY)

Message: 66619   


I'm using flashw and it works well....


Are you sure that the problem is dd? I could not understand why it doesn't work. If it fails maybe flashw fails too.


What kind of bord do you use? Is the flash shared with other resources?










2008-12-11 06:20:57     Re: Trouble with busybox 'dd' command.

Patrick Hotz (GERMANY)

Message: 66629   


Hi Mat,


i don´t know which board do you use but on my CM-BF537E board i know the problem.

The CM-BF537E uses the PF4 to access the upper 2Mb of flash....


I think the "dd" programm isn´t able to access the upper 2Mb so the image can´t be written in it.


I hope that there is a answer but i don´t know it now.








2009-02-24 10:49:10     Re: Trouble with busybox 'dd' command.


Message: 69821   


We are using our own modified BF537 stamp board with spi flash.  We use the M25P128, and it uses the same drivers as the other M25 chips.


Writing to flash is unstable, seems to brick the thing over 50% of the time.


Anyone have a clue what might be happening?


dd if=update.bin of=/dev/mtdblock3








2009-02-24 11:18:14     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 69829   


post the exact output of /proc/mtd and your kernel boot output




2009-02-24 15:48:19     Re: Trouble with busybox 'dd' command.


Message: 69840   


Shortly after issuing the 'dd' command, i get the following error:


dd if=/update.bin of=/dev/mtdblock3


end_request: I/O error, dev mtdblock3, sector 1024

Buffer I/O error on device mtdblock3, logical block 128

lost page write due to I/O error on mtdblock3


Now, if I open two telnet connections, and run 'top' in one of them prior to executing 'dd', 'top' continues to run.  After running dd and seeing the message above, I can no longer open a new telnet connection.  All previously opened shells seem to continue to run, until I try and execute 'top', 'ps', 'ls', etc.  The shell hangs at that point, but top continues to run.  No processes seem to be consuming an abnormal amount of CPU time.


After it crashed as shown above, top continued to run. dmesg (in the other terminal) showed that the above messages were logged. free seems to work:


root:~> free

              total         used         free       shared      buffers

  Mem:        30724        11472        19252            0         1472


Running other commands caused that terminal to lock up. The one running top seems to still be alive, though, as it occasionally updates the values:


Mem: 11212K used, 19512K free, 0K shrd, 1472K buff, 2124K cached

Load average: 3.98 3.33 2.91


1104 root     R        848  1097  0.3  2.7 busybox

1094 root     S        936  1093  0.0  3.0 sh

1097 root     S        936  1096  0.0  3.0 sh

1111 root     D        936  1110  0.0  3.0 sh

1143 root     D        936  1111  0.0  3.0 sh

  150 root     S        936     1  0.0  3.0 sh

1137 root     S        928  1094  0.0  3.0 ddwrapper

1139 root     D        840  1137  0.0  2.7 busybox

  151 root     S        836     1  0.0  2.7 syslogd

  152 root     S        836     1  0.0  2.7 klogd

    1 root     S        568     0  0.0  1.8 init

  144 root     S        516     1  0.0  1.6 dhcpcd

1093 root     S        508   146  0.0  1.6 telnetd

1110 root     S        508   146  0.0  1.6 telnetd

1096 root     S        508   146  0.0  1.6 telnetd

  146 root     S        484     1  0.0  1.5 inetd

    3 root     SWN        0     2  0.0  0.0 ksoftirqd/0

   77 root     DW<        0     2  0.0  0.0 mtdblockd

   83 root     SW<        0     2  0.0  0.0 bfin-spi.0

   38 root     SW         0     2  0.0  0.0 pdflush

    2 root     SW<        0     0  0.0  0.0 kthreadd


I can still get root~> prompts via serial. I can't get a net telnet connection to open; it won't even prompt for the login. "kill -9 1137" killed ddwrapper. Still can't make new telnet connection.


"ls" from the serial port hung it. CTRL-C from the telnet running top got me a root prompt. I tried to run "dmesg" but accidentally typed "demsb", which hung it.




Any Ideas?






2009-02-24 15:59:30     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 69841   


then that's not an issue with dd.  the lower mtd layers are crapping out (most likely due to the SPI crapping out).




2009-02-24 18:40:09     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 69843   


I am Matt Gilg's co-worker, with an update on the SPI "crapping out".  We just put a scope on the SPI clock line going to the M25P128 flash chip.  We see the clock run at 25MHz in bursts 8 pulses long when U-Boot loads the uClinux image from flash or when it saves to the flash (which works every time).  We just tried to program the flash from uClinux with the dd command, got the same errors mentioned previously, and saw on the scope that it sent only two bursts of 8 pulses.  The pulse rate was 25MHz and the groups were 4.3uS apart (a relatively long time).  Then about 5uS later, the SPI clock line, which is normally high when inactive, appeared to go high-Z (maybe got switched to an input?) and slowly decayed to ground.


What does it try to do in the first two bytes transferred?  Is it checking to see if a flash sector is blank (ready to be programmed)?  What would it do if it failed to read the expected value from the flash?  Does anyone know offhand what source file I should be looking at for answers?


It is interesting to me that when it has trouble programming the flash that some things continue to work ("top" will continue to run, for example, and you can run "free" from the root~> prompt), but other things cause a terminal to hang, such as running "ls", a new copy of "top" or trying to run a command that doesn't exist (such as "dmesb").  Is that an indication that the SPI routines hang while holding the "big lock"?








2009-02-24 18:57:21     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 69844   


based on your description, i have no idea.  if you decode the trace though, it should be fairly trivial to figure out.  the SPI flash protocol is fairly simple and the bits are sampled according to the clock.


you guys didnt post either of the things i asked for, so i wont attempt to explain the hanging.


presumably you're using the 2008R1.5 release ... we've fixed SPI issues since the release




2009-02-24 19:08:03     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 69845   


I am working on connecting the logic analyzer now, so I can dig through the traces.


We are using 2008R1.5 RC3.


root:~> cat /proc/mtd

dev:    size   erasesize  name

mtd0: 01f00000 00001000 "ROMfs"

mtd1: 00040000 00040000 "bootloader"

mtd2: 00040000 00040000 "bootloader-environment"

mtd3: 00d80000 00040000 "kernel"

mtd4: 00200000 00040000 "file system"




U-Boot 1.1.6-svn63 (ADI-2008R2-pre) (Mar 19 2008 - 07:43:49)

CPU:   ADSP bf537-0.2 (Detected Rev: 0.3)

Board: ADI BF537 stamp board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 500 MHz, Core: 500 MHz, System: 100 MHz

RAM:   64 MB

In:    serial

Out:   serial

Err:   serial

Net:   Blackfin EMAC

MAC:   00:50:C2:90:50:57

I2C:   ready

Hit any key to stop autoboot:  0

EEPROM @0x0 read: addr 02000000  off 80000  count 14155776 .........................................................done

## Booting image at 02000000 ...

   Image Name:   uClinux Kernel and ext2

   Created:      2009-02-24  18:31:44 UTC

   Image Type:   Blackfin Linux Kernel Image (gzip compressed)

   Data Size:    7300232 Bytes =  7 MB

   Load Address: 00001000

   Entry Point:  001a4000

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

Starting Kernel at = 1a4000

Linux version (stevestrobel@dev1-ubuntu) (gcc version 4.1.2 (ADI svn)) #5 Mon Feb 23 16:44

:01 MST 2009

Hardware Trace Active and Enabled

Reset caused by Software reset

Blackfin support (C) 2004-2007 Analog Devices, Inc.

Compiled for ADSP-BF537 Rev 0.3

Blackfin Linux support by http://blackfin.uclinux.org/

Processor Speed: 500 MHz core clock and 100 MHz System Clock

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

  text      = 0x00001000-0x0013a450

  rodata    = 0x0013b000-0x0018f6f0

  data      = 0x00190000-0x001a4000

    stack   = 0x00190000-0x00192000

  init      = 0x001a4000-0x001b7000

  bss       = 0x001b7000-0x001c7ef0

  available = 0x001c7ef0-0x02000000

  rootfs    = 0x02000000-0x03f00000

  DMA Zone  = 0x03f00000-0x04000000

NOMPU: setting up cplb tables for global access

Instruction Cache Enabled

Data Cache Enabled (write-back)

Built 1 zonelists.  Total pages: 8128

Kernel command line: root=/dev/mtdblock0 rw console=ttyBF0,115200

Configuring Blackfin Priority Driven Interrupts

PID hash table entries: 128 (order: 7, 512 bytes)

Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)

Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)

Memory available: 30648k/65536k RAM, (76k init code, 1253k kernel code, 490k data, 1024k dma, 304k reserved)

Blackfin Scratchpad data SRAM: 4 KB

Blackfin Data A SRAM: 16 KB (15 KB free)

Blackfin Data B SRAM: 16 KB (16 KB free)

Blackfin Instruction SRAM: 48 KB (39 KB free)

Security Framework v1.0.0 initialized

Capability LSM initialized

Mount-cache hash table entries: 512

NET: Registered protocol family 16

Blackfin GPIO Controller

Blackfin DMA Controller

tcb_406_board_init(): registering device resources

tcb_406_board_init(): registering Blackfin SPI resources

tcb_406_board_init(): finished registering Blackfin SPI resources

Generic PHY: Registered new driver

SCSI subsystem initialized

NET: Registered protocol family 2

IP route cache hash table entries: 1024 (order: 0, 4096 bytes)

TCP established hash table entries: 1024 (order: 1, 8192 bytes)

TCP bind hash table entries: 1024 (order: 0, 4096 bytes)

TCP: Hash tables configured (established 1024 bind 1024)

TCP reno registered

JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.

io scheduler noop registered

io scheduler anticipatory registered (default)

io scheduler cfq registered

ISA-BlackFin-CAN CAN Driver 3.4.6_AD_BLACKFIN (c) Feb 23 2009

BlackFin port by H.J. Oertel (oe@port.de)

bfin-wdt: initialized: timeout=20 sec (nowayout=0)

RLC-DSP4 cors driver

MSAT-IP init_switch driver

RLC-DSP4 ptts driver

Serial: Blackfin serial driver

bfin-uart.1: ttyBF0 at MMIO 0xffc00400 (irq = 18) is a BFIN-UART

bfin-uart.1: ttyBF1 at MMIO 0xffc02000 (irq = 20) is a BFIN-UART

RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize

bfin_mac_mdio: probed

bfin_mac: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01, irq=-1, mdc_clk=2500000Hz(mdc_div=19)@sclk=100MHz)

bfin_mac: Version 1.1, Blackfin BF53[67] BF527 on-chip Ethernet MAC driver

uclinux[mtd]: RAM probe address=0x2000000 size=0x1f00000

Creating 1 MTD partitions on "RAM":

0x00000000-0x01f00000 : "ROMfs"

m25p80 spi0.1: m25p128 (16384 Kbytes)

Creating 4 MTD partitions on "m25p80":

0x00000000-0x00040000 : "bootloader"

0x00040000-0x00080000 : "bootloader-environment"

0x00080000-0x00e00000 : "kernel"

0x00e00000-0x01000000 : "file system"

bfin-spi bfin-spi.0: Blackfin BF5xx on-chip SPI Contoller Driver, Version 1.0, regs_base@ffc00500, dma channel@7

bfin-spi-gpio-mstr: registering platform driver

bfin-spi-gpio-mstr: bfin_spi_gpio_probe()

bits_per_word not specified in spi_bitbang_setup.  Defaulting to 32.

bits_per_word not specified in spi_bitbang_setup.  Defaulting to 32.

Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).

dma_alloc_init: dma_page @ 0x002d9000 - 256 pages at 0x03f00000


ALSA device list:

  #0: ADI ad1836 at PF4 SPORT0 rx/tx dma 3/4 err irq 45

TCP cubic registered

NET: Registered protocol family 1

NET: Registered protocol family 17

VFS: Mounted root (ext2 filesystem).

Freeing unused kernel memory: 76k freed


        a8888b.           / Welcome to the uClinux distribution \

       d888888b.         /       _     _                         \

       8P"YP"Y88        /       | |   |_|            __  __ (TM)  |

       8|o||o|88  _____/        | |    _ ____  _   _ \ \/ /       |

       8'    .88       \        | |   | |  _ \| | | | \  /        |

       8`._.' Y8.       \       | |__ | | | | | |_| | /  \        |

      d/      `8b.       \      \____||_|_| |_|\____|/_/\_\       |

     dP   .    Y8b.       \   For embedded processors including   |

    d8:'  "  `::88b        \    the Analog Devices Blackfin      /

   d8"         'Y88b        \___________________________________/

  :8P    '      :888

   8a.   :     _a88P         For further information, check out:

._/"Yaa_:   .| 88P|            - http://blackfin.uclinux.org/

\    YP"    `| 8P  `.          - http://docs.blackfin.uclinux.org/

/     \.___.d|    .'           - http://www.uclinux.org/

`--..__)8888P`._.'  jgs/a:f    - http://www.analog.com/blackfin

Have a lot of fun...

This is /mnt/permanent/scripts/init-passwd

Checking for password file

Password file already exists

Password file exists - using it



BusyBox v1.4.1 (2009-02-23 17:13:38 MST) Built-in shell (msh)

Enter 'help' for a list of built-in commands.





2009-02-24 20:34:17     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 69846   


are you actually using/mounting /dev/mtdblock4 ?  if the SPI master is crapping out, then attempts to use it would cause hangs otherwise.


i dont suppose you'd be able to test the svn branch ?  really the only thing going in there is bug fixes ...




2009-02-25 10:56:29     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 69898   


We have no trouble storing files on mtdblock4.  /etc/rc mounts it as follows:


mkdir -p /mnt/permanent

mount -t jffs2 /dev/mtdblock4 /mnt/permanent


The problem we are working on is updating the uClinux image (which also contains all of our firmware) in mtdblock3.  Background:  We didn't want the end-user to be able to mess up stuff in the filesystem, so the kernel and entire filesystem (uImage.ext2, about 7MB) is decompressed into a RAMFS on startup.  /etc/rc then mounts mtdblock4 as a small jffs2 filesystem where we store any customized settings.  If the user goofs things up, rm -rf /mnt/permanent puts everything back to normal.  The big drawback of this method is that it takes about 30 seconds to boot.


We have in the past supported updating the firmware via two different methods.  If a serial port connection is available, we reset the unit, abort startup in U-Boot, x/ymodem the file into memory, then store it to mtdblock3 with the command


eeprom write $(loadaddr) 0x80000 $(filesize)


That works every time.  If we have access to both the serial port and a network connection, rather than x/ymodem we use tftp to transfer the file, then the same command to store it.  Some of our end-users want to be able to update the firmware remotely when only a network connection is available.  I don't know how to do that just using U-Boot (no way to abort bootup and issue the commands), so we have done that (when it worked) by booting into Linux, ftping the uImage.ext2 file (renamed to update.bin) into the ramfs, then using the


dd if=/update.bin of=/dev/mtdblock3


command to copy it to flash.  That has worked some of the time.  Obviously if something goes wrong, it leaves the board without a bootable version of Linux.  It can be recovered using a serial connection, but that isn't always convenient.  We tried different versions (the Busybox and standalone versions) and thought we had it working consistently when we were using 2007R1-RC3.  Since updating to 2008R1.5-RC3, we have again found it to be inconsistent.  It might be helpful for me to go back and verify that it really was consistent before and try to determine what changed, although the real issue is whether or not the current version works correctly.


While we have seen several types of problems while running dd (the whole system hanging, the COP watchdog timing out (we now disable it completely before starting), etc.), the problem we can easily reproduce now is the one that causes it to print the following almost immediately after issuing the dd command:


end_request: I/O error, dev mtdblock3, sector 1024

Buffer I/O error on device mtdblock3, logical block 128

lost page write due to I/O error on mtdblock3


In summary, the fact that U-Boot can write to mtdblock3 consistently and that uClinux can use a jffs2 filesystem on mtdblock4 on the same flash chip without problems makes me think that the hardware must be OK and that the problem is in either dd itself or something else that is going on at the same time that is messing up dd (we do stop all of our applications before running dd).  Any suggestions for how to continue troubleshooting this are greatly appreciated.






2009-02-25 13:24:01     Re: Trouble with busybox 'dd' command.

Frank Van Hooft (CANADA)

Message: 69902   


I'm using an M25P32 on a BF537. What do you have for pullups & pulldowns on the SPI lines? I pulled up our schematics and this is what we have:


CS, MOSI, MISO: Pullups


CLK: Pulldown






2009-02-25 13:36:39     Re: Trouble with busybox 'dd' command.

Phil Wilshire (UNITED STATES)

Message: 69903   




Just a wild idea.


Try limiting the blocksize with dd


dd if=/update.bin of=/dev/mtdblock3 bs=1024


I must admit I have not tried this with the more recent systems but..


  I usually use cp to copy the char device.


cp /update.bin /dev/mtd3


   Where /dev/mtd3 is the char device version of mtdblock3 with write access.


Thinking about it you probably should try the char device with dd as well.




  Phil Wilshire






2009-02-25 14:43:08     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 69906   


We have 10K pullups to 3.3V on all four of those lines.  I don't remember if there was a particular reason for that design, except for the MISO line, which must have a pullup for the flash type detection to work at boot time.  Would you suggest trying a pulldown on the clock line?  What value did you use?




2009-02-25 14:51:00     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 69907   


Thanks for the suggestions.  I will try specifying the block size and report back.  Would setting the block size smaller than the size of a flash sector cause multiple erase/program cycles?


It looks like there are several permutations I can try:  dd or cp, /dev/mtd3 or /dev/mtdblock3, various block sizes, etc.  I am afraid I don't understand why one choice might be better than another (except that maybe it works better in testing).  Is there a general guideline for which should be used for accessing a SPI flash, or maybe something I should read to find out?




2009-02-25 17:07:22     Re: Trouble with busybox 'dd' command.

Frank Van Hooft (CANADA)

Message: 69916   


We have a 10k pulldown on the clock line.


Like Phil, we also use "cp" to write to the flash. Specifically, we do:


eraseall  /dev/mtd0


cp  firmware  /dev/mtd0




2009-02-26 07:18:09     Re: Trouble with busybox 'dd' command.

Phil Wilshire (UNITED STATES)

Message: 70000   




I always use the char device "dev/mtdx" when erasing (thanks Frank) and then copying an image.


This would be a good place to start testing and come back if that does not work.


Phil Wilshire






2009-03-04 15:25:56     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 70380   


Many thanks to all of you that wrote to help Matt and me get flash updates working reliably. I will summarize what I learned both to close the loop on all of the suggestions and because I think it provides evidence that a device driver used to access m25p128 SPI flash through /dev/mtdblock3 has a bug (maybe timing that is more aggressive than some chips can consistently handle).


History:  Trying to update the uClinux image in flash with the command "dd if=update.bin of=/dev/mtdblock3" worked inconsistently, sometimes causing error messages similar to this (sometimes the addresses varied):




end_request: I/O error, dev mtdblock3, sector 1024

Buffer I/O error on device mtdblock3, logical block 128

lost page write due to I/O error on mtdblock3


#1:  After receiving such an error message, some commands could still be executed (free, kill...) while executing others would cause the console to hang (top, ps, ls, or a mis-typed name that didn't exist).  If top was already running in a different console when the error occurred, it would continue to run.  dd would not run again, which prevented retrying the same command.


#2:  I had trouble for a while getting the logic analyzer to trigger on the flash programming sequence because the SPI flash's chip select was also being being asserted whenever we accessed a different SPI device.  According to http://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_item_id=4097 this has been fixed, but we are still using V1.5RC3 and don't have that fix yet.  I disabled the other driver to avoid that issue.


#3:  By observing the logic analyzer traces we determined that the flash programming sequence could appear to be working fine for more than 10mS (transferring hundreds of bytes), fail in a shorter time (like 1.9mS), transfer only two bytes (8 SPI clock pulses) or in one case after recording only one low-going pulse on the SPI CLK line (no activity on the other lines - it could possibly have been triggered by static).  I never could find anything in the traces that indicated a problem;  it would just stop suddenly and print the error message.  I would be glad to supply saved traces from the logic analyzer and descriptions of what happened in each case if someone is interested in taking a closer look.


#4:  About 5uS after the flash programming fails (judging by the SPI activity stopping), the SPI clock line (which is normally high when inactive) apears to go high-Z, decaying slowly to ground as if it was switched to an input.


#5:  The problem seems to affect only certain flash chips, and the printing on the chips themselves is not enough to determine whether they will work or not.  We tried four different PCBs using M25P128 chips from three different lots.  Of the two chips that were marked the same, one consistently worked while the other consistently failed (when using /dev/mtdblock3).  On the other two PCBs, one consistently worked and the other consistently failed until we swapped the flash chips;  then the problem followed the "bad" chip.


#6:  Even the "bad" flash chips work fine when programmed using U-Boot's eeprom command and when used by uClinux for a JFFS2 file system.  In other words, I don't think the chips are really bad;  they just can't handle something about the way they are used when writing to /dev/mtdblock3.


#7:  We accidentally had both a 10K pullup and a 47K pulldown on the SPI clock line.  We removed the pullup, then changed the pulldown to 10K.  Neither change had any noticible effect.


#8:  I didn't try limiting the blocksize with dd.


#9:  Using /dev/mtd3 rather than /dev/mtdblock3 works reliably on all of the hardware we tested, including with the "bad" flash chips.  This is a usable solution for us, and may indicate that there is a problem with /dev/mtdblock3 that should be fixed.  I would like to test with the SVN trunk to confirm that the problem still exists there, but can't right now.


#10:  When using /dev/mtd3, you must erase the flash sectors first (eraseall /dev/mtd3) as it doesn't seem to happen automatically as it does with /dev/mtdblock3 (I can guess why, but didn't know it before).  Using the erase command before writing to /dev/mtdblock3 does not help with the problem.


#11:  cp and dd seem to equivalent in every way that I tested.  They both failed on the same hardware when using /dev/mtdblock3 and worked in all other cases.  The execution time was similar.  We are continuing to use dd because it is convenient for us to watch for the message it prints when it finishes (14585+1 records in, 14585+1 records out).


Thanks again to all who offered suggestions.  I hope to follow up on this issue someday to make sure that /dev/mtdblock3 works too.  Should I open a tracker issue for it?






2009-03-04 15:47:45     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 70382   


the mtd/mtdblock description you give is correct.  the point of mtdblock is to present the mtd as a block device and take care of the erase/write for you.  mtd does no such thing (again, by design).


based on your observations, i'd posit that either the devices are slightly deffective when it comes to back-to-back operations like write;erase;write;erase;write;erase or the chip driver for spi flashes does not include any timing delays (or correctly polls the status register).  i'd lean towards the former personally ...


writing to mtdblock# would induce that cycle (erase a block, write a block, erase a block, ...).  but working with a mtd# would not as you would start with doing all erase commands (not sure if they have auto-incrementing addresses), then you would do all write commands (which do have auto-incrementing addresses so you often dont even need to re-issue the program command).




2009-03-05 12:51:39     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 70456   


I hadn't considered alternating erase/write cycles being a difference in how the flash chip gets accessed in each case, but I agree that the timing during the switch back and for seems likely to be the culprit.  Whether the driver or the chip doesn't follow the spec remains to be determined, but since we can't change the chips, we might want to modify the driver either way.


We have three different hardware designs (different PCB layouts) all with the same issue, so I don't think it is a layout problem unique to the design we tested with.  Should I open a tracker item for it?




2009-03-05 12:58:32     Re: Trouble with busybox 'dd' command.

Mike Frysinger (UNITED STATES)

Message: 70459   


i'm not sure it'd help if we cant reproduce


i dont suppose you have a throw away dev system that has the bug you could send us




2009-03-05 15:41:57     Re: Trouble with busybox 'dd' command.

Steve Strobel (UNITED STATES)

Message: 70473   


I could probably get approval to loan one for a month or two.  Email me direct with the address if you are interested.