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

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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

Jump to solution
1,239 Views
kravik
Contributor IV

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.

Labels (2)
0 Kudos
Reply
1 Solution
847 Views
kravik
Contributor IV

The issue is resolved with the kobs-ng patch : https://community.freescale.com/servlet/JiveServlet/download/2004-304760-318027-258403/0002-set-dbbt...

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.

FCB format.png

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?

View solution in original post

0 Kudos
Reply
4 Replies
847 Views
kravik
Contributor IV

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

0 Kudos
Reply
848 Views
kravik
Contributor IV

The issue is resolved with the kobs-ng patch : https://community.freescale.com/servlet/JiveServlet/download/2004-304760-318027-258403/0002-set-dbbt...

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.

FCB format.png

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?

0 Kudos
Reply
847 Views
alejandrolozan1
NXP Employee
NXP Employee

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

0 Kudos
Reply
847 Views
kravik
Contributor IV

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? 

0 Kudos
Reply