• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 413 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Bootloader/ECC issues DM8168

John Walker
Expert 8560 points

Team,

Received this inquiry from one of my customers.  My first thought is that the ECC can't correct for this much but if so I would've expected it to go to SD, not hang.  ??

I’m looking into an issue we noticed today where one of our engineers accidently erased some info from the flash and then our board wouldn’t boot. 

 

That is table 4-5 which has to do with boot order of the data sheet is set to 10011 which specifies that we would go NAND then NANI2C then SD and then UART for the boot sequence.  What we saw is that when some bytes of the nand were erased in the booloader the board didn’t seem to go all the way to the SD boot.

 

In looking at the sprugx8b document section 25.7.3.1 NAND Read Sector Procedure, it looks like there are two cases in which the memory can fail in the NAND part of the sequnce.  One being block is invalid, does that mean that it’s erased?   Or that the ECC could not correct the mistake it found on the read.

 

I’m wondering if the fact that we got rid of a couple of bytes then would it have been possible for the ECC to correct them? If so how come it didn’t work? If not then how come it failed?  Is there a way to check this? 

Also this was written in the bootloader prompt so then I would assume the ecc would be fine since it gets corrected after the write.  So my other question is if the ecc is correct but there is no valid image in there a way to make it fail?

 Any ideas on what the problem might be?

Thanks,

John

  • 0
    TI__Guru**** 170625 points

    Hi John,

     

    John Walker said:
    My first thought is that the ECC can't correct for this much but if so I would've expected it to go to SD, not hang.  ?

    Do you have something valid on the SD? If you switch the boot order (BTM[4:0] = 10111) for SD first, will you be able to boot successful?

    John Walker said:
    That is table 4-5 which has to do with boot order of the data sheet

    This is actually Table 5-6. Boot Mode Order from the SPRS614E

    John Walker said:
    What we saw is that when some bytes of the nand were erased in the booloader the board didn’t seem to go all the way to the SD boot.

    May be the ROM code is able to find valid booting image in the NAND, but hangs afterwards into the NAND boot process. Do you have any console message output when trying to boot from NAND? You might need attach JTAG emulator to see where exactly it hangs, in ROM code or in u-boot.

    John Walker said:
    I’m wondering if the fact that we got rid of a couple of bytes then would it have been possible for the ECC to correct them?

    What is the ECC algorithm you are using? Note that on new PSP versions, it should be BCH8 for u-boot. See the below wiki page:


    Regards,
    Pavel

  • 0 in reply to Pavel Botev
    TI__Expert 8560 points

    Pavel,

    Feedback from customer:

    1)     Do you have something valid on the SD? If you switch the boot order (BTM[4:0] = 10111) for SD first, will you be able to boot successful?

    Yes there is something valid in the sd card.  If we change the setting it works.

    What we saw is that when some bytes of the nand were erased in the booloader the board didn’t seem to go all the way to the SD boot.

    2)     May be the ROM code is able to find valid booting image in the NAND, but hangs afterwards into the NAND boot process. Do you have any console message output when trying to boot from NAND? You might need attach JTAG emulator to see where exactly it hangs, in ROM code or in u-boot.

    No we don’t see an output.  I don’t think we have a way to attach a jtag emulator on our design

    I’m wondering if the fact that we got rid of a couple of bytes then would it have been possible for the ECC to correct them?

    3)     What is the ECC algorithm you are using? Note that on new PSP versions, it should be BCH8.

    I believe we’re using the latst ECC algorithm which is the one you mentioned.

  • 0 in reply to John Walker
    TI__Guru**** 170625 points

    Hi John,

    John Walker said:
    I’m wondering if the fact that we got rid of a couple of bytes then would it have been possible for the ECC to correct them?

    I think you can correct only 8bits (with BCH8) per 512 bytes block.

    See also if the below pointers will be in help:

    Regards,
    Pavel