Skip to contentSkip to conversation

Can't read kernel if bad blocks are present in partition

U-Boot Alexandre Gambier 3 participants 8 messages Apr 26, 2012 – May 2, 2012

lore
Share & tools
lore
#0 lore raw

Hi,

I'm working on a STM chip under linux and U-Boot 1.3.1.

Here's my problem.
To boot linux up I load the kernel stored in a NAND device. If a bad block is present in the nand I can't load the kernel.

To store the kernel I first erase the partition and write the kernel image. During the erase stage, U-Boottells that a bad block has been skipped but everything's fine.

NAND erase: device 0 offset 0x520000, size 0x400000 Skipping bad block at 0x005c0000
Erasing at 0x900000 -- 100% complete.
OK

When I write the kernel image, U-Boottells that everything's fine.

NAND write: device 0 offset 0x520000, size 0x400000

    4194304 bytes written: OK

But when I try to read the kernel, it fails.

NAND read: device 0 offset 0x520000, size 0x1a4bff

    1723391 bytes read: ERROR

I though U-Boot was able to handle bad block when reading back data..

Did I forget to initialize something ?

BEst regards.

Signature · 4 lines
Best regards.

Alexandre Gambier
Fte Maximal France SAS
#1 lore raw
Quoted 24 lines · Alexandre Gambier

Hi,

I'm working on a STM chip under linux and U-Boot 1.3.1.

Here's my problem.
To boot linux up I load the kernel stored in a NAND device. If a bad block is present in the nand I can't load the kernel.

To store the kernel I first erase the partition and write the kernel image. During the erase stage, U-Boottells that a bad block has been skipped but everything's fine.

   NAND erase: device 0 offset 0x520000, size 0x400000
   Skipping bad block at  0x005c0000
   Erasing at 0x900000 -- 100% complete.
   OK

When I write the kernel image, U-Boottells that everything's fine.

NAND write: device 0 offset 0x520000, size 0x400000

    4194304 bytes written: OK

But when I try to read the kernel, it fails.

Quoted 8 lines

NAND read: device 0 offset 0x520000, size 0x1a4bff

    1723391 bytes read: ERROR

I though U-Boot was able to handle bad block when reading back data..

Did I forget to initialize something ?

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

Signature · 2 lines
Peter Barada
peter.barada at logicpd.com
#2 lore raw
Quoted 29 lines · Peter Barada
Quoted 28 lines · Alexandre Gambier

Hi,

I'm working on a STM chip under linux and U-Boot 1.3.1.

Here's my problem.
To boot linux up I load the kernel stored in a NAND device. If a bad block is present in the nand I can't load the kernel.

To store the kernel I first erase the partition and write the kernel image. During the erase stage, U-Boottells that a bad block has been skipped but everything's fine.

   NAND erase: device 0 offset 0x520000, size 0x400000
   Skipping bad block at  0x005c0000
   Erasing at 0x900000 -- 100% complete.
   OK

When I write the kernel image, U-Boottells that everything's fine.

NAND write: device 0 offset 0x520000, size 0x400000

    4194304 bytes written: OK

But when I try to read the kernel, it fails.

NAND read: device 0 offset 0x520000, size 0x1a4bff

    1723391 bytes read: ERROR
Quoted 6 lines
Quoted 4 lines

I though U-Boot was able to handle bad block when reading back data..

Did I forget to initialize something ?

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

That has been the default for a while now. Why use something as ancient as 1.3.1?

-Scott

#3 lore raw

Hi,

Quoted 2 lines
Quoted 2 lines

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

No I use "nand read $load_addr AppKernel" cause I didn't know we can use "nand read.i" - "help nand" doesn't display this information. I tried "nand read.i" and now it works fine but I still can't boot the kernel cause its crc is wrong I will flash the kernel again with "nand write.i" and check if it works.

Quoted 2 lines

That has been the default for a while now. Why use something as ancient as 1.3.1?

Because my embedded linux distribution is STLinux which includes support for STM chips with this version of u-boot.

Alex.

#4 lore raw
Quoted 10 lines · Alexandre Gambier

Hi,

Quoted 2 lines
Quoted 2 lines

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

No I use "nand read $load_addr AppKernel" cause I didn't know we can use "nand read.i" - "help nand" doesn't display this information. I tried "nand read.i" and now it works fine but I still can't boot the kernel cause its crc is wrong I will flash the kernel again with "nand write.i" and check if it works.

Assuming you load the kernel to ram with tftp (and that "AppKernel" is an mtdparts partition in NAND), then you could do:

nand erase.part AppKernel
tftp $load_addr uImage
crc32 $load_addr $filesize
nand write.i $load_addr AppKernel $filesize
nand read.i $load_addr AppKernel $filesize
crc32 $load_addr $filesize

To verify the CRCs match between what you load off tftp and what you read back from NAND.

Signature · 2 lines
Peter Barada
peter.barada at logicpd.com
#5 lore raw
Quoted 21 lines · Peter Barada
Quoted 10 lines · Alexandre Gambier

Hi,

Quoted 2 lines
Quoted 2 lines

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

No I use "nand read $load_addr AppKernel" cause I didn't know we can use "nand read.i" - "help nand" doesn't display this information. I tried "nand read.i" and now it works fine but I still can't boot the kernel cause its crc is wrong I will flash the kernel again with "nand write.i" and check if it works.

Assuming you load the kernel to ram with tftp (and that "AppKernel" is an mtdparts partition in NAND), then you could do:

nand erase.part AppKernel
tftp $load_addr uImage
crc32 $load_addr $filesize
nand write.i $load_addr AppKernel $filesize
nand read.i $load_addr AppKernel $filesize
crc32 $load_addr $filesize

Quoted 2 lines

To verify the CRCs match between what you load off tftp and what you read back from NAND.

There is no U-Boot version that both has "nand erase.part" and requires a .i suffix on nand read/write.

-Scott

#6 lore raw
Quoted 10 lines
Quoted 10 lines

Assuming you load the kernel to ram with tftp (and that "AppKernel" is an mtdparts partition in NAND), then you could do:

nand erase.part AppKernel
tftp $load_addr uImage
crc32 $load_addr $filesize
nand write.i $load_addr AppKernel $filesize
nand read.i $load_addr AppKernel $filesize
crc32 $load_addr $filesize

Quoted 2 lines
Quoted 2 lines

To verify the CRCs match between what you load off tftp and what you read back from NAND.

Everything works fine now.
I now use "nand write.i" and "nand read.i" instead of "nand write" and "nand.read".

Quoted 4 lines
Quoted 4 lines

Does STLinux have a support contact?

This list is for mainline U-Boot. Have you checked whether these chips are supported in current mainline U-Boot?

It was just a misunderstanding of u-boot commands.

Thank you guys for your help.

#7 lore raw
In reply to Alexandre Gambier
Quoted 11 lines · Alexandre Gambier

Hi,

Quoted 2 lines
Quoted 2 lines

Did you use "nand write.i" to write the kernel and "nand read.i" to read the kernel? the ".i" tells u-boot to skip bad blocks...

No I use "nand read $load_addr AppKernel" cause I didn't know we can use "nand read.i" - "help nand" doesn't display this information. I tried "nand read.i" and now it works fine but I still can't boot the kernel cause its crc is wrong I will flash the kernel again with "nand write.i" and check if it works.

Quoted 4 lines
Quoted 2 lines

That has been the default for a while now. Why use something as ancient as 1.3.1?

Because my embedded linux distribution is STLinux which includes support for STM chips with this version of u-boot.

Does STLinux have a support contact?

This list is for mainline U-Boot. Have you checked whether these chips are supported in current mainline U-Boot?

-Scott