AM1808 NAND boot - Peripheral Open Failed

Daniel thank you for responding.

I'm using the davinci nand driver included in openocd to program the NAND.  I've tried the 3 different modes [hwecc1, hwecc4, and hwecc4_infix] all with the same failing result.

In my tests I erased NAND blocks 0 and 1, wrote my AIS ubl binary to blocks 0 and block 1 (bootloader mentions starting at block 1, but wrote both anyway) starting a page 0.

nand erase 0 0 0x40000

nand write 0 ubl-ais.bin 0

nand verify 0 ubl-ais.bin 0

nand write 0 ubl-ais.bin 0x20000

nand verify 0 ubl-ais.bin 0x20000

I did this for all 3 modes as well as just erasing NAND completely.  I get the same result.  'Peripheral Open Failed'.

Can you think of anyway I could verify that the failure is indeed due to ECC?

Are there any breakpoints I could set in RBL and subsequent registers I could inspect to narrow this problem down?

Are there any other reasons why this error might be seen?

BTW, I was expecting to see data at 0x80000000 change regardless of ECC failure or not, is that a correct assumption?

Thanks again for your help.

Tom Saeger said:

BTW, I was expecting to see data at 0x80000000 change regardless of ECC failure or not, is that a correct assumption?

Since the AIS image has not begun being parsed, no data is being copied to the load address your program was linked to run at.

Tom Saeger said:

Can you think of anyway I could verify that the failure is indeed due to ECC?

One quick thing you can do is check the memory at 0xFFFF1000.  This is the location of the NAND page buffer.  If you see what appears to be AIS image data in the 512 bytes starting at that memory location, but you don't see the correct data beyond those 512 bytes, then that tells us that the NAND was correctly identified by the ROM boot loader, and that data was begun to be read, but that the ECC check at the end of the first 512 bytes failed.  If you don't see any correct AIS image data in that memory region, then either the NAND identification failed or the blocks into which you wrote the image are marked as bad, and the ROM skipped over them.

Tom Saeger said:

I'm using the davinci nand driver included in openocd to program the NAND.  I've tried the 3 different modes [hwecc1, hwecc4, and hwecc4_infix] all with the same failing result.

I have no knowledge of this driver or what it does as far as ECC operations go. It's entirely conceivable that this driver doesn't work, or that it operates on the wrong chip select of the device (previous devices booted NAND from the first chip select of the EMIF, this one boots from the second). Based on the names of the modes, either hwecc4 or hwecc4_infix sounds like they would be the ones you want to try.

Regards, Daniel

Daniel,

I dumped 0xFFFF1000 as you suggested and it contains all 0xFFFFFFFF, exactly 512 bytes worth.

I scoped CE#, ALE, and CLE of the NAND and verified things are indeed wiggling.

I have also verified the contents of NAND at offset 0x20000 (block 1, page 0) are correct.  ECC could still be wrong, but it's hard to tell if RBL is getting that far.

Does the RBL code ever explicitly set the page buffer to 0xFFFFFFFF?

Otherwise from what you've suggested, either it's skipping the block or hasn't identified the NAND correctly.

Thanks again for your insights on this - it has been extremely helpful.

Daniel,

I switched our board into UART2 boot and used the sfh utilities to flash ubl down.  It is now booting from NAND.  I believe you were absolutely correct in figuring it was ECC.  I will mark that answer as accepted.

Thanks again for you help.

Tom,

Thanks for the feedback.  I'm a little perplexed as to why you were seeing 0xFFFFFFFF in the NAND page buffer, but I can only conclude that somehow the driver you were using with the JTAG setup you have was not actually writing where you think it was writing, or somehow it was writing to where you thought it was, but that the ROM was thinking that block was bad and was skipping over it.  There is a global boot loader data structure from 0xFFFF0700 - 0xFFFF0800 and one of the elements of that structure is what block and page the RBL was trying to read last, so we could dig into it further, but if you are satisfied with what you have now, we can also just let it lie.

Regards, Daniel

I did get a chance to dig into this further once I got u-boot up and running.

The JTAG driver is calculating CRC correctly, however the layout of the OOB bytes is different.  Now at least I know what to fix.

Working:

OOB:

        ff ff ff ff ff ff 13 d2

        03 6f d7 8e 0c fd 64 94

        ff ff ff ff ff ff 6d 8e

        99 dc 47 c6 53 16 79 ba

        ff ff ff ff ff ff c6 cf

        b3 52 98 9f a8 8a 7a 1a

        ff ff ff ff ff ff b2 b3

        b9 55 81 9b 04 bd 52 2b

Not Working:

OOB:

        ff ff ff ff ff ff ff ff

        ff ff ff ff ff ff ff ff

        ff ff ff ff ff ff ff ff

        13 d2 03 6f d7 8e 0c fd

        64 94 6d 8e 99 dc 47 c6

        53 16 79 ba c6 cf b3 52

        98 9f a8 8a 7a 1a b2 b3

        b9 55 81 9b 04 bd 52 2b