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.

SK-AM64B: SK-AM64B cannot boot

Part Number: SK-AM64B

Hi,

Customer has SK-AM64B. 

They inserted SD card with boot image. However it did not boot.

The following message was shown.

Would you let me know the root cause and countermeasure?

U-Boot SPL 2023.04-gb0d717b732 (Dec 06 2023 - 15:11:45 +0000)
EEPROM not available at 0x50, trying to read at 0x51
Reading on-board EEPROM at 0x51 failed -19
Resetting on cold boot to workaround ErrataID:i2331
Please resend tiboot3.bin in case of UART/DFU boot
resetting ...

Best Regards,

Kasai

  • Hello Kasai-san,

    This is a known bug with SDK 9.1 unfortunately... the out-of-the-box uboot code is broken. I'm not totally sure how we are fixing it for SDK 9.1, but it will definitely be resolved in SDK 9.2, and we are closing the test gap that caused this to slip by us.

    Looks like the uboot fixes are here:
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=40682843ba90a42b1d8ec702865eeac35eed1de1
    https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04&id=57820c133a06b875c0da01776909ced81eed2ad5

    An easy way to test if the customer doesn't want to try modifying uboot quite yet is they could just boot the board with the default SD card filesystem image from SDK 9.0. I would expect the board to boot as expected.

    Regards,

    Nick

  • To add to what Nick explained...

    I'm not totally sure how we are fixing it for SDK 9.1, but it will definitely be resolved in SDK 9.2

    We are working on an early release of SDK v9.2 for AM64 that should be available shortly.

    In the meantime one can also cherry-pick the 2 earlier-mentioned Git commit on top of the U-Boot shipping with SDK v9.1 and then re-build U-Boot, this should also resolve the issue. But obviously this makes for a less-than-ideal out-of-the-box experience, hence we'll provide early access to SDK v9.2 very soon.

    we are closing the test gap that caused this to slip by us.

    It was found that in our automated test farm/setup we were not always using the very latest/correct U-Boot associated with a planned release. In this case here, a late change came into U-Boot that broke the actual final image which however didn't get picked up in time for the associated overall system test. Basically we were running/testing an almost-current / almost-correct U-Boot together with the correct everything else, making the overall test vulnerable for exactly such U-Boot late changes that happened. So while the test(s) passed they did not test the final/combined image as expected.

    Regards, Andreas

  • Hi Andreas,

    Very sorry for my response and thank you for your reply.

    We believe we can keep customer's trust with this explanation.

    Best Regards,

    Kasai