Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 10 Apr 2015 06:19 AM by  Oleg Kuryan
copy from one device to another unsuccessful
 2 Replies
Sort:
You are not authorized to post a reply.
Author Messages
Oleg Kuryan
New Member
New Member
Posts:3


--
26 Mar 2015 03:25 PM

    Dear support team,

    I spent hours in trying to copy NAND FW from one device to another but with no success. The target device always stuck up.

    I did it by LoLo comands:

    dd of:/tftp/192.168.1.100\:NAND.raw if:/dev/nand0 count:130720 obs:528 ibs:528 skip:0 skip_bad:1;

    erase B0 B4096 /dev/nand0;

    dd if:/tftp/192.168.1.100\:NAND.raw of:/dev/nand0 count:130720 obs:528 ibs:528 seek:0 skip_bad:1;

     

    On the console of target device I have output:

    ### JFFS2 loading 'linux.uboot' to 0x87000000
    Scanning JFFS2 FS:   read_nand_cached: error reading nand off 0x104000 size 8192 bytes
    . done.

    But on the source device I have no such error.

    Could you please help me solve it?

    What I do wrong with copy?

    Thank you in advance. 

    BR

    Oleg Kuryan

     

    bradb
    Basic Member
    Basic Member
    Posts:203


    --
    27 Mar 2015 04:10 PM
    Oleg,

    In Logic Loader "dd" is modeled after Unix’s dd command. "dd" is designed to be file system agnostic. I am not aware of any software program that can copy all file systems for all devices.

    "dd" will only read blocks/chunks/buffers of data from hardware and write blocks/chunks/buffers to hardware. That is the extent of it. We have expanded that slightly to verify the data written, and even count any bit differences when verifying. We have always tried to keep "dd" close to it’s file system agnostic roots.

    "dd" will work for any file system that supports an identical image moved from one device to the next. This works most of the time. It falls short for NAND flash on two accounts:
    - NAND flash bad blocks are specific to each NAND device. Therefor exact image duplication from one NAND device to the next will likely not work. To handle this, the NAND driver in LoLo will skip bad blocks making "dd" think all blocks are always good. This scheme just happens to work with YAFFS as well.
    - NAND flash can have bad bits. In this case too, exact image duplication from one NAND device to the next will likely not work. To handle this, ECC in the data image is used to correct bad bits. In LoLo’s "dd" command during a read there may be bad bits in the data read (and subsequently duplicated to a different NAND flash). We rely on ECC in the data image to correct those bad bits on both the source device, and the duplicated destination device.

    Some file systems may not work with "dd". I only know of a few file systems, but I do know there is one or more NAND flash file systems that use a bad block table located on NAND flash, rather than skipping bad blocks. In this case "dd" will not work, because "dd" doesn't know how to deconstruct the bad block table on the source device, and generate a new bad block table on the destination device. This is just one example, I am sure there are others.

    "dd" has been around for ages. It was not originally designed for NAND flash. As far as I know there is no one single copy mechanism that can copy all file systems to/from all devices. Either the copy program has to be file system (and hardware) aware, or the file system must be designed to accommodate direct duplication.

    Regards,
    Brad
    Oleg Kuryan
    New Member
    New Member
    Posts:3


    --
    10 Apr 2015 06:19 AM
    Thank you very much for the good explanation.

    The problem has been solved by replace NAND flash with bad blocks on 0x104000 to new one:

    Configuration of /dev/nand0:
    Total Blocks: 4096
    Bytes Per Block: 16896
    Has Chunks: yes
    Total Chunks: 131072
    Chunks Per Block: 32
    Bytes Per Chunk: 528
    Bytes Per Spare: 16

    and then copy software by:
    dd if:/tftp/192.168.1.100:NAND131040.raw of:/dev/nand0 count:131040 ibs:528 obs:528 seek:0 skip_bad:1;

    You are not authorized to post a reply.