• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1602 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.

SK-AM62: U-Boot SPL Authentication failed.

Neil Lai
Prodigy 180 points

Part Number: SK-AM62

 Hi Expert,

When I do the power on/off test, I am facing an authentication failed issue in u-boot spl. This failed is not always happens. The failed rate is <1%. When board hangs on this authentication failed issue, I try to call do_reset function to reset board. But it doesn't do anything. Could you give me any advise about this issue? Thanks.

U-Boot SPL 2021.01-g93b301dbce (Oct 02 2023 - 15:34:41 +0800)
SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
SPL initial stack usage: 13424 bytes
Trying to boot from MMC1
Authentication passed
Authentication passed
ti_sci system-controller@44043000: ti_sci_get_response: Message receive failed. ret = -110
ti_sci system-controller@44043000: Message not acknowledgedAuthentication failed!
### ERROR ### Please RESET the board ###

Best regards,

Neil

  • +1
    TI__Guru 70392 points

    Hi Neil,

    can you please try/port to the latest SDK v9.0 for U-Boot sources and device firmwares (TIFS, DM)? Looks like something is happening in your system where TIFS becomes unresponsive, as indicated by the time out error.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 180 points

    Hi Andreas,

    I am downloading SDK v9.0 and merge our code later. But I still have question, Why the do_reset function doesn't work in U-Boot SPL?

    Best regrads,

    Neil

  • 0 in reply to Neil Lai
    TI__Guru 70392 points
    Neil Lai said:
    But I still have question, Why the do_reset function doesn't work in U-Boot SPL?

    That is a good question that I don't have the answer to. It would help if you could correlate this failure with some other behavior or something you are doing but that may be easier said than done.

    • Does this happen on all boards? Or particular board(s)?
    • Can you re-create this on a TI EVM?
    • You could try increasing the TIFS communication timeout from 10s (default) to 100s just for testing purposes to see if that makes a difference...

    diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index d7ec3f0bb1..05ea3d428a 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -3030,7 +3030,7 @@ static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
 /* Description for J721e DM to DMSC communication */
 static const struct ti_sci_desc ti_sci_dm_j721e_desc = {
        .default_host_id = 250,
-       .max_rx_timeout_ms = 10000,
+       .max_rx_timeout_ms = 100000,
        .max_msgs = 20,
        .max_msg_size = 60,
 };

    All this being said the involved device firmware (TIFS) is undergoing continuous improvements and I remember there being instances related to timeouts being discussed/fixed, but this doesn't mean this is the same scenario here. However trying with the SDK v9.0 baseline will be an important data point.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 180 points

    Hi Andreas,

    After testing, use SDK v9.0 for U-Boot sources and device firmwares can fix this issue. Thanks for your help.

    Best regards,

    Neil

  • 0 in reply to Neil Lai
    TI__Guru 70392 points

    Hi Neil,

    Glad to hear. Also just to confirm, using SDK v9.0 sources/FW artifacts fixed the issue for you. You did not have to modify `max_rx_timeout_ms` as outlined in my earlier post, correct? (this was a debug step, and should NOT be needed, so I just wanted to make sure).

    Thanks, Andreas

  • 0 in reply to Andreas Dannenberg
    Prodigy 180 points

    Hi Andreas,

    Yes, I don't modify "max_rx_timeout_ms" in ti_sci.c

    Best regards,

    Neil