i.MX ProcessorsのトピックRe: Kernel data corruption while flashing u-boot with kobs-ng

Kernel data corruption while flashing u-boot with kobs-ng

kravik — Wed, 30 Mar 2016 06:52:45 GMT

I am using IMX53 based custom board with micron flash. I have flashed NAND as follows after booting with sdcard, but in Kernel partition (/dev/mtd1) specific memory locations (2002 byte, 4050=2002+2048 byte, 6098=4050+2048 byte) at end of every 2048 byte was corrupted(the values is always FF).

Step 1. Flashed kernel image using nandwrite.

#flash_erase /dev/mtd1 0 0

#nandwrite -b 1 -n /dev/mtd1 -p /home/uImage

Step 2. Flashed u-boot using kobs-ng.

#flash_erase /dev/mtd0 0 0

#kobs-ng init -v --chip_0_device_path=/dev/mtd0 /home/u-boot.bin

After Step1 the memory locations(2002 byte, 4050=2002+2048 byte, 6098=4050+2048 byte etc...) are having correct values, but after flashing u-boot with kobs-ng those memory locations(2002 byte, 4050 (2002+2048)byte, 6098(4050+2048) etc...) of kernel partition values are changes to FF.

Following is the first memory location corruption example:

Actual value after Step 1:

---------------------------------

# nanddump -c -n -l 1 /dev/mtd2 | grep "000007d0:"

Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x00000001...

0x000007d0: 10 af 40 ee 9a af 07 ee 15 af 07 ee 9a af 07 ee |..@.............|

Corrupted value after Step 2:

--------------------------------------

# nanddump -c -n -l 1 /dev/mtd2 | grep "000007d0:"

Block size 131072, page size 2048, OOB size 64

Dumping data starting at 0x00000000 and ending at 0x00000001...

0x000007d0: ff af 40 ee 9a af 07 ee 15 af 07 ee 9a af 07 ee |..@.............|

The corrupted value(10 changes to ff) highlighted with bold.

My doubht here is why kernel partition value is corrupted while flasing u-boot using kobs-ng. When I flash u-boot also with nandwrite then values are not corrupted.

When I flash u-boot first( using kobs-ng) and kernel second then also same issue.

Can you guide me to debug the issue while using kobs-ng for flashing u-boot.

Re: Kernel data corruption while flashing u-boot with kobs-ng

kravik — Fri, 01 Apr 2016 08:33:53 GMT

The issue is resolved with the kobs-ng patch : https://community.freescale.com/servlet/JiveServlet/download/2004-304760-318027-258403/0002-set-dbbt-fingerprint2-to-same-as-mx53-rom-and-enable.patch.zip

I was checking the differences in FCB with and without patch.

With patch:

---------------

FCB:

0000000 0000 0000 4346 2042 0001 0000 0000 0000

0000010 0000 0000 0000 0000 0000 0000 0000 0000

0000060 0000 0000 0000 0000 0200 0000 1100 0000

0000070 0064 0000 0064 0000 0100 0000 07d0 0000

0000080 0000 0000 0000 0000 0000 0000 0000 0000

00000a0 0000 0000 0000 0000 0000 0000 0001 0000

00000b0 0831 0000 0000 0000 0000 0000 0000 0000

00000c0 0000 0000 0000 0000 0000 0000 0000 0000

0000800 ffff ffff ffff ffff ffff ffff ffff ffff

Without patch:

-------------------

FCB:

0000000 0000 0000 4346 2042 0001 0000 0000 0000

0000010 0000 0000 0000 0000 0000 0000 0000 0000

0000060 0000 0000 0000 0000 0200 0000 1100 0000

0000070 0064 0000 0064 0000 0100 0000 0000 0000

0000080 0000 0000 0000 0000 0000 0000 0000 0000

0000800 ffff ffff ffff ffff ffff ffff ffff ffff

I have following doubhts in FCB format, can you help me to understand.

1. Here Primary and secondary images refers to u-boot and kernel respectively?

2. What is mean by Bad block marker offset?

3. What will happen if Bad block marker swapping is enabled?

4. What is mean by Bad block marker offset to spare byte?

Re: Kernel data corruption while flashing u-boot with kobs-ng

kravik — Mon, 04 Apr 2016 06:27:08 GMT

Can anyone help to understand the doubts updated in above post related to badblocks in FCB format.

Re: Kernel data corruption while flashing u-boot with kobs-ng

alejandrolozan1 — Thu, 07 Apr 2016 20:03:17 GMT

Hi,

Thanks for sharing your solution. This is very helpful.

Regarding your questions I think I might help with a few of them:

1.- Both images correspond to the boot image, that is ussually u-boot.

2.- The offset in the BCH page where the ROM code swaps the first byte metadata.

3.- The BootRom code will swap BadBlockMarkerByt with metadata[0]

Best Regards,

Alejandro

Re: Kernel data corruption while flashing u-boot with kobs-ng

kravik — Fri, 08 Apr 2016 17:00:42 GMT

Hi,

Thanks for the reply.

If both images refers to U-boot then u-boot will store at two locations in NAND?

I started learning NAND basics with this issue, can you please tell me what is mean by BCH page? What metadata contains?