2008-12-10 10:15:25 Trouble with busybox 'dd' command.
Matt Gilg (UNITED STATES)
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.
Thanks!
-Matt Gilg
QuoteReplyEditDelete
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?
Regards
--Michele
QuoteReplyEditDelete
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.
Patrick
TranslateQuoteReplyEditDelete
2009-02-24 10:49:10 Re: Trouble with busybox 'dd' command.
Matt Gilg (UNITED STATES)
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
-Matt
QuoteReplyEditDelete
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
QuoteReplyEditDelete
2009-02-24 15:48:19 Re: Trouble with busybox 'dd' command.
Matt Gilg (UNITED STATES)
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
PID USER STATUS VSZ PPID %CPU %MEM COMMAND
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?
-Matt
QuoteReplyEditDelete
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).
QuoteReplyEditDelete
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"?
Steve
QuoteReplyEditDelete
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
QuoteReplyEditDelete
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 2.6.22.19-ADI-2008R1.5-svn469 (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
snd_ad1836_configure
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.
root:~>
QuoteReplyEditDelete
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 ...
QuoteReplyEditDelete
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.
Steve
QuoteReplyEditDelete
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
QuoteReplyEditDelete
2009-02-25 13:36:39 Re: Trouble with busybox 'dd' command.
Phil Wilshire (UNITED STATES)
Message: 69903
Steve,
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.
regards
Phil Wilshire
QuoteReplyEditDelete
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?
QuoteReplyEditDelete
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?
QuoteReplyEditDelete
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
QuoteReplyEditDelete
2009-02-26 07:18:09 Re: Trouble with busybox 'dd' command.
Phil Wilshire (UNITED STATES)
Message: 70000
Steve,
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
QuoteReplyEditDelete
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?
Steve
QuoteReplyEditDelete
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).
QuoteReplyEditDelete
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?
QuoteReplyEditDelete
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
QuoteReplyEditDelete
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.
