Loading from NAND using 'nboot' Periodically Fails Where 'nand read' Succeeds

Before I jump in with the BDI and start debugging, has anyone else using 'nboot' and FIT images noticed that 'nboot' periodically fails where 'nand read.i' of the SAME region of NAND succeeds?

    => echo $bootaddr
    800000
    => echo $boot0
    nboot ${bootaddr} 0 0 && setenv bootargs root=/dev/mtdblock9 && run
    addjffs2 addtty && bootm ${bootaddr}
    => run boot0

    Loading from NAND 64MiB 3,3V 8-bit, offset 0x0
    ** Bad FIT image format

    => nand read.i ${bootaddr} 0 400000

    NAND read: device 0 offset 0x0, size 0x400000

    Reading data from 0x3ffe00 -- 100% complete.
     4194304 bytes read: OK
    => setenv bootargs root=/dev/mtdblock9
    => run addjffs2 addtty
    => bootm ${bootaddr}
    ## Booting kernel from FIT Image at 00800000 ...
       Using 'config at 1' configuration
       Trying 'kernel at 1' kernel subimage
    ...
    Using Haleakala machine description
    Linux version 2.6.25-rc3-00951-g6514352-dirty (gerickson at ubuntu-fusion)

(gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #2 Wed May 28 22:49:36 PDT 2008
Zone PFN ranges:
DMA 0 -> 65536
Normal 65536 -> 65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
...

This is using AMCC's Haleakala board with Samsung K9F1208U0B NAND, though I suspect that doesn't make any difference since nand read.i works fine.

Regards,

Grant

Hi Grant,

Not sure here, since I never used nboot before. But "nand read.i" skips bad blocks and perhaps "nboot" not? I suggest that you check if this is the case and if you have bad blocks in this NAND area.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================

It is indeed the case -- you need to use "nboot.i".

-Scott

Scott and Stefan,

Thanks for the suggestion. That solved it. As an academic exercise, is there any practical reason a system would want to use nboot, as I erroneously chose to do, without .i|.jffs2|.e?

Regards,

Grant

Principal
Nuovation System Designs, LLC

998 Alpine Terrace Suite 3
Sunnyvale, CA 94086-2469
US

T +1-408-749-0495
F +1-205-449-0495
M +1-408-489-5710

gerickson at nuovations.com
http://www.nuovations.com/

I don't think so, though I don't know the history involved. Does anyone actually use the non-block-skipping versions of any of the nand commands (intentionally, that is)? If the answer is no, then we could make it the default.

-Scott

I would vote for making bad black handling the default. I've been working on fixing up a design of ours that mistakenly used non block skipping version and I've been trying to find all the places were bad block's were not being skipped and fixes them. Our system only uses NAND flash and people are very concerned about it.

Stuart

Stuart Wood

Lab X Technologies, LLC
176 Anderson Ave.
Suite 302
Rochester, NY 14607
Phone: (585) 271-7790 x207
Fax: (585) 473.4707

I'm fine with making bad-block-skipping the default. I never used the "other" version and I don't know what it's really useful for.

Best regards,
Stefan

=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office at denx.de
=====================================================================

Hi Scott,

we are using the NAND stuff for a couple of boards. All use the .i or .jffs2 extension. So I also vote for making skipping the default. But the extensions should be preserved :-)

Matthias

Hi Scott,

I also vote for commands to be bad-block aware per default as I also already got bitten by that.

Cheers
Detlev

Q:  What does FAQ stand for?
A:  We are Frequently Asked this Question, and we have no idea.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

It would appear I was slightly too quick to regard this as fixed. What I found this morning is the following with the AMCC "Haleakala" board:

1) A 48+ hour reboot test bouncing between the boot0 and boot1 partitions passed, where boot0 and boot1 are defined as:

    => printenv bootaddr bootcmd boot0 boot1
    bootaddr=800000
    bootcmd=run boot0 || run boot1 || reset
    boot0=nboot.i ${bootaddr} 0 0 && setenv bootargs root=/dev/mtdblock9 &&
run addjffs2 addtty && bootm ${bootaddr}
    boot1=nboot.i ${bootaddr} 0 1C00000 && setenv bootargs

root=/dev/mtdblock11 && run addjffs2 addtty && bootm ${bootaddr}

2) I stopped that test and added power-cycling to the mix and it, again, immediately failed with:

Loading from NAND 64MiB 3,3V 8-bit, offset 0x0 ** Bad FIT image format

Loading from NAND 64MiB 3,3V 8-bit, offset 0x1c00000 ** Bad FIT image format

So, resets are not enough to trigger this issue, it takes a power cycle.

I have found that this state is recoverable by issuing a 'nand read.i' and then re-running 'boot0':

    => nand read.i ${bootaddr} 0 400000 && run boot0

From that point forward, both boot0 and boot1 work flawlessly.

I have also found that NFS booting to get Linux up and running, restarting and then running boot0 or boot1 also works from that point forward until the next power cycle.

So, there seems to be some specific state the PowerPC NDFC (NAND controller) or Samsung K9F1208U0B NAND gets in where either 'nand read.i' or the Linux MTD driver kick one or both in such a way as to get out of whatever state prevents nboot.i from working.

Strangely though, both nand read.i and nboot.i both exercise the same nand_read_opts path in nand_util.c.

Any thoughts?

Regards,

Grant

Marian:

I'm following up with you on this since 'git blame cmd_nand.c' seems to indicate you added the CONFIG_FIT support to this file.

Based on stepping through with the debugger, my initial guess about hardware issues may have been incorrect. Is there an implicit assumption in the following snippet from nand_load_image() in cmd_nand.c:

    ...

    cnt = nand->oobblock;
    if (jffs2) {
        nand_read_options_t opts;
        memset(&opts, 0, sizeof(opts));
        opts.buffer = (u_char*) addr;
        opts.length = cnt;
        opts.offset = offset;
        opts.quiet      = 1;
        r = nand_read_opts(nand, &opts);
    } else {
        r = nand_read(nand, offset, &cnt, (u_char *) addr);
    }

    if (r) {
        puts("** Read error\n");
        show_boot_progress (-56);
        return 1;
    }

    ...

    switch (genimg_get_format ((void *)addr)) {

    ...

#if defined(CONFIG_FIT)
    case IMAGE_FORMAT_FIT:
        fit_hdr = (const void *)addr;
        if (!fit_check_format (fit_hdr)) {
            show_boot_progress (-150);
            puts ("** Bad FIT image format\n");
            return 1;
        }
        show_boot_progress (151);
        puts ("Fit image detected...\n");

        cnt = fit_get_size (fit_hdr);
        break;

#endif

    ...

that casting 'addr' to 'fit_hdr' represents more than 512 bytes of valid data to be accessed by fit_check_format()? If so, should not 'cnt = nand->oobblock' be explicitly set to match that assumption?

I am guessing that my observation that NFS booting and nand read.i addressed the issue strictly had to do with the fact that the 8 MiB address to which those operate were not getting used or otherwise updated between resets after the boot of the kernel allowing subsequent runs of 'nboot' to "leverage" the stale data.

Regards,

Grant

The boot.itb image I have in NAND is 0x13CB98 bytes in size. Running a series of 'nand read.i ${bootaddr} 0 <...>':

    => nand read.i ${bootaddr} 0 1000 && iminfo ${bootaddr}
    ## Checking Image at 00800000 ...
       FIT image found
    Bad FIT image format!
    
    => nand read.i ${bootaddr} 0 2000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 4000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 8000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 10000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 20000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 40000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 80000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 100000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 200000 && iminfo ${bootaddr}
    ...
    ## Checking Image at 00800000 ...
       FIT image found
       FIT description: Linux Kernel with Device Tree
        Image 0 (kernel at 1)
         Description:  Kernel
         Type:         Kernel Image
         Compression:  gzip compressed
         Data Start:   0x008000c8
    ...

So, it would appear that the answer, at least for this trivial boot.itb of a kernel and DTB, for how large must the initial value of 'cnt' be is "as large as the image being nboot'ed is". That said, it looks like nboot and FIT images may not work together at present with today's code.

Any thoughts?

Regards,

Grant

Hi Grant,

...

Doing a FIT format check on a first sector data is obviously wrong. This was a good spot for such check with the initial implementation of the routine, but it should have been corrected after that changed, stupid me. As you'll note fit_print_contents() call is deferred, and that is for the same reason, it needs the whole image data to operate on. Same, for format check, it cannot be done earlier than that.

I'll post a patch later today that fixes it, please give it a try on your system.

Cheers,
m.