• State TI Thinks Resolved
  • Locked Locked
  • Replies 18 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1377 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.

AM6526: Issues with booting from UART on AM6526 SR2.1.

Novica Jovanovic
Intellectual 470 points
Part Number: AM6526
Other Parts Discussed in Thread: AM6548, UNIFLASH

Hello All,

I have a question regarding the issue we have when we try to boot the application directly from UART on AM6526 SR2.1.

My configuration is:
PDK - pdk_am65xx_1_0_7 (processor_sdk_rtos_am65xx_6_03_00_106)

We developed our custom board based on Sitara AM6548 SR2.0. (some of the boards were assembled with AM6526 SR2.1.) on which we use QSPI flash as a primary and UART (MCU_UART) as a backup boot device.

We added our custom board in PDK, and we were able to boot and run our application either from NOR flash (preprogrammed with Uniflash tool) or directly from UART (software-dl.ti.com/.../index_Foundational_Components.html

Everything works fine when we try to use our custom board based on AM6548 SR2.0. We can boot and run the application directly from UART or we can write our images (sbl, sysfw and app) to NOR flash and we can boot from it.

But when we try to boot our application on boards that have AM6526 SR2.1. then we have the following problems:
1) When we try to boot the application via UART (we are using Teraterm to send UART SBL to ROM bootloader), then on each board we are facing the same issue that the transfer of SBL to ROM bootloader was stopped on the 53.6% (picture on the left). But we do not have this problem with boards that have AM6548 SR2.0. (the picture on the right)

    

2) Then we tried to use the Uniflash tool to store sbl, sysfw and app images to NOR flash. But again we have a problem with writing images or erasing NOR flash on boards that have AM6526 SR2.1. Below are given output messages from the Uniflash tool from which we can see that problem occur after SYSFW was transferred to the target board:


We didn't have this kind of problem with boards that have AM6548 SR2.0.. There we can write all three images and we can boot the application from NOR flash without any problem.


So I have the following questions:

Q1) Can we use the same SBL for booting from UART on AM6526 SR2.1. and on AM6548 SR2.0.? Why the ROM bootloader on the AM6526 SR2.1. can not read the whole SBL and
what we can do/change to boot our application directly from UART on AM6526 SR2.1. like we did on board with AM6548 SR2.0.?

Q2) Do we need to change something in flash-writer binary so we can flash our images (SBL, SYSFW, and APP) to NOR flash or do we just need a different version of sysfw?

Q3) From firmware and SDK point of view, does AM6526 SR2.1 is compatible with AM6548 SR2.0 (except in numbers of A53 cores)? Do we need to add some additional changes in the bord library for our board to support  AM6526 SR2.1?


Best regards,
Novica

  • 0
    TI__Mastermind 42135 points

    Hi Novica,


    I have few queries here:
    1) Is there any other component change in the boards other than the silicon?
    2) Are you facing similar issue with all the boards with SR2.1?
    3) Can you please share which QSPI part you are using?

    Regrads,
    Parth

  • 0 in reply to Parth Nagpal
    Intellectual 470 points

    Hi Parth,

    1) Is there any other component change in the boards other than the silicon?

    Ans#1) No, the schematic and PCB are the same. The silicon is the only component that is different between boards

    2) Are you facing similar issue with all the boards with SR2.1?

    Ans#2) Yes, we have the same issues on all boards with AM6526 SR2.1.

    3) Can you please share which QSPI part you are using?

    Ans#3) All information related to our modification to support QSPI nor flash you can find in our previous post:
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/865286/ccs-am6548-qspi-nor-flash-support

    If we assume that we have some problem with our modification that we made to support QSPI nor flash on our side, for which the chances are minimal because our modification related to QSPI works without any problem on boards with AM6548 SR2.0, we still have the problem of why the ROM bootloader on AM6526 SR2.1. is not able to load UART SBL.

    I didn't find too many details about RBL, but from our understanding and according to TRM,  RBL should first load the complete SBL image, and then it should pass execution to SBL. But in our case with AM6526 SR2.1 the RBL stuck when it read 53.6% of SBL.

    Regards,
    Novica

  • 0 in reply to Novica Jovanovic
    TI__Guru** 113810 points

    Novica,

    Two questions:

    1. Have you tried with the Uniflash version 6.4.0?
    2. Can you please confirm the version of the SYSFW used with SR2.0 and now with SR2.1? If you can share the exact binary name and the md5sum that would be useful.

    Regards

    Karthik

  • 0 in reply to Karthik Ramanan
    Intellectual 470 points

    Hi Karthik,

    1. Have you tried with the Uniflash version 6.4.0?

    We installed Uniflash version 6.4.0 and we made a test. I can confirm that we still have the same problems as I described above.

    2. Can you please confirm the version of the SYSFW used with SR2.0 and now with SR2.1? If you can share the exact binary name and the md5sum that would be useful.

     The version of SYSFW that we use for SR2.0 and now with SR2.1 is "SYSFW  ver: 19.12.2-v2019.12b ". We are using SYSFW which is located on the following path in SDK6.3 <\ti\pdk_am65xx_mls\packages\ti\drv\sciclient\soc\V0\sysfw_sr2.bin>. 

    The full name of the SDK version which we are using is: processor_sdk_rtos_am65xx_6_03_00_106

    sysfw_sr2.zip

    Regards,

    Novica

  • 0 in reply to Novica Jovanovic
    Prodigy 41 points

    Dear all,

    to complete the picture and give answers to the question sent by mail:

    1. RTOS SDK version is exactly 6.3.0.106:

    https://www.ti.com/tool/download/PROCESSOR-SDK-RTOS-AM65X/06.03.00.106

    This is the version with full SR2 support. If you were using earlier versions of 6.3, you should upgrade to this version.

    • Answered in first Post
    1. Are you using the sysfw for SR2.0. ti-sci-firmware-am65x_sr2-gp.bin. This firmware shall be compatible with SR2.1.
    • Specified the Version we use sysfw_sr2.bin
    • Missing information: We can not use the file named above because the second bootloader cannot handle this file.
    1. Can you confirm that with the same ti-sci-firmware-am65x_sr2-gp.bin, SR2.0 silicon boots and SR2.1 not booting?
    • Implicit answered: We only use sysfw_sr2.bin for SR2.0 and SR2.1
  • 0 in reply to Joern Graewe
    TI__Mastermind 42135 points

    Hi Novica,


    Have you made any changes in SBL? If yes, can you please share linker command file used for the SBL.

    Regards,
    Parth

  • 0 in reply to Parth Nagpal
    Intellectual 470 points

    Hi Parth,

    In SDK6.03 we made changes in SBL, we add support for nor flash that we have on our board. I can confirm, with our changes in SBL, that booting from UART and from NOR flash is working on our boards that have AM6548 SR2.0. In sbl_linker.zip you have SBL linker file and .map files from SBLs (uart SBL and qspi_nor SBL).
    sbl_linker.zip

    Then we made some additional tests. We tried to use UART SBLs for the IDK board from the newest SDKs, SDK 7.03 and SDK8.0., and I can confirm that again ROM bootloader, on boards with Sitara AM6526 SR2.1., is not able to read complete SBL image. The transfer was stopped on the 45% for both uart SBLs.
    UART_SBLs.zip
    sbl_uart_idk_7_03_.bin (\ti\pdk_am65xx_07_03_00_54\packages\ti\boot\sbl\binary\am65xx_idk\uart\bin\sbl_uart_img_mcu1_0_release.tiimage)
    sbl_uart_idk_8_00_.bin (\ti\pdk_am65xx_08_00_00_36\packages\ti\boot\sbl\binary\am65xx_idk\uart\bin\sbl_uart_img_mcu1_0_release.tiimage)

    AM6526 SR2.1. Loading of uart sbl for IDK board from SDK 7.03.

    AM6526 SR2.1. Loading of uart sbl for IDK board from SDK 8.00.

    We made the same tests on boards that have AM6548 SR2.0. We tried to load UART SBLs from SDK7.03 and SDK8.0. and SBLs are loaded by ROM bootloader without any problem.


    AM6548 SR2.0. Loading of uart sbl for IDK board from SDK 7.03.

    AM6548 SR2.0. Loading of uart sbl for IDK board from SDK 8.00.



    The full name of the AM6526 chip that we have on our boards is (XAM6526BACDXA): 

     


    Q1) Can you make the same tests on your side as we did (with SDK6.03, SDK7.03, and SDK8.0), and can you tell us did you menage to boot the application directly from UART on the XAM6526BACDXA chip?
    Q2) Could you please clarify and explain the different behavior we see between the AM6580AACD and the XAM6526BACDXA?


    As I mentioned in my previous replay, the only difference between our boards is that some of the boards have AM6548SR2.0. and some of them have AM6526SR2.1. But XAM6526BACDXA is the component we selected to use for the series, so this issue is getting really critical for us.


    Regards,

    Novica

  • 0 in reply to Novica Jovanovic
    TI__Mastermind 23125 points

    Novica, 

    I tried an AM6526 device on my socketed EVM, using X-modem protocol, and was able to see the transfer is complete. Details are:

    1. Install a AM6526BACDXA device to the socketed EVM, set EVM to boot via UART

    2. on MCU UART window, I can see the ...CCCC... char

    3. on Tera Term menus, go File->Transfer->Xmodem, selected sbl_uart_idk_8_0.bin, and saw the file was transferred complete, then UART window prompt for sysfw.bin. complete UART log (with garbage) are shown below. Note that I transferred SBL twice. 

    Let me know if you want to try uniflash command lines. you will need to send me the full sequence and the uniflash version you used. 

    I will also send you some additional debug notes in the next post. 

    regards

    Jian

    01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CSBL Revision: 01.00.10.01 (Aug 2 2021 - 18:01:55)
    Waiting for sysfw.bin ...
    CCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCC01000000011a00006d617877656c6c0000000000475020200002010000CCCCCCCCCCCCCCCCCCCCCCCCCCCCC

  • 0 in reply to jian35385
    TI__Mastermind 23125 points

    Novica, 

    On your hardware, one suspect is that some of your boot code tried to write efused subsystems on AM6526 device. Since you original software was development on the superset device, there might be some unintentional writes to some subsystem or config space registers, which is powered off on 
    AM6526 device. Examples such as:

    - Writing to control/config registers on the second A53 cluster

    - writing to GPU registers

    - Trying to setup CCM events for R5 lockstep

    note all these are powered off in the AM6526 device. 

    let us know if you can recall or scan you boot code to ensure there are no such operations. 

    regard

    jian 

  • 0 in reply to jian35385
    Intellectual 470 points

    Hi Jian,

    First, I want to thank you for your response and detailed explanation!

    But it seems that you (on your EVM board) and we have different versions of AM6526 SoC. This is a conclusion based on the number that is printed before the ROM bootloader starts with the printing of character C.


    In our case with AM6526 SR2.1 (XAM6526BACDXA) the RBL print the following number:

    02000000011a00006d617877656c6c000000000048535345000201000002010002a60000010001002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b41f6002b07cd9b0b7c47d9ca8d1aae57b8e8784a12f636b2b760d7d98a18f189760dfd0f23e2b0cb10ec7edc7c6edac3d9bdfefe0eddc3fff7fe9ad875195527d7564f66cb964e04144c86a1fd16c42f7888bfef0a9e81864f89c300b2d

    But in your case the RBL prints:
    01000000011a00006d617877656c6c0000000000475020200002010000

    We have noticed the number that is printed by RBL on our boards with AM6548 SR2.0. (AM6580AACD) is the same as the number on your EVM board with AM6526  (AM6526BACDXA):
    01000000011a00006d617877656c6c0000000000475020200002010000


    Q1) Can you explain to us what this number represents and what kind of information is given in the number that is printed on UART by RBL?

    Q2) You wrote that on your EVM board you use AM6526BACDXA, can you make a test with XAM6526BACDXA? Because this version of the silicon we have on our side.

    Regard,
    Novica

  • 0 in reply to Novica Jovanovic
    TI__Guru** 113810 points

    Novica,

    Please see this FAQ on identifying SR2.1 vs. 2.0: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1032107/faq-am6548-ctrlmmr_wkup_jtagid-register-value-for-sr2-1, kindly check this and confirm if you see the difference as mentioned here.

    I have asked my colleague who has access to another AM65 SR2.1 hardware to post a parallel set of observation. We will have an update here shortly.

    Regards

    Karthik

  • 0 in reply to Karthik Ramanan
    TI__Mastermind 42135 points

    Hi Novica,

    I am able to transfer complete SBL that you shared by following the procedure Jian shared in one of the previous post.

    Also, I can confirm that the silicon revision is 2.1 by looking at Silicon Revision Register as mention in the thread  https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1032107/faq-am6548-ctrlmmr_wkup_jtagid-register-value-for-sr2-1,

    Regards,

    Parth

  • 0 in reply to Parth Nagpal
    TI__Mastermind 23125 points

    Novica/Parth, 

    Below is the UART log of an an HS device, it seems to match Novica's log. We will send you the decoding of these logs later. 

    But even with the HS device, I was able to xmodem Novica's SBLs to the 100% completion. below logs are for first loaded 8.0 SBL then reloaded 7.3 SBL. 

    On the part number marking, the two part numbers are supposed to be equivalent functionally, will confirm back once we trace back the shipment details.   

    regards

    Jian

    ÿ02000000011a00006d617877656c6c000000000048534653000201000002010002a60000000000002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4ad0bc40b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078c875d81ca3f8322ff40eb22ff3aea68ba74c241d8b94c20827785076CCCCCSBL Revision: 01.00.10.01 (Aug 2 2021 - 18:01:55)
    Waiting for sysfw.bin ...
    CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC02000000011a00006d617877656c6c000000000048534653000201000002010002a60000000000002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4ad0bc40b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078c875d81ca3f8322ff40eb22ff3aea68ba74c241d8b94c20827785076CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCSBL Revision: 01.00.10.00 (May 31 2021 - 19:56:01)
    Waiting for sysfw.bin ...
    CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC02000000011a00006d617877656c6c000000000048534653000201000002010002a60000000000002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b4ad0bc40b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000078c875d81ca3f8322ff40eb22ff3aea68ba74c241d8b94c20827785076CCC

  • 0 in reply to jian35385
    Intellectual 705 points

    Hi TI guys,

    I tried now with 2 boards having XAM6526 SR2.1 chips of the same Lot (label and behavior of both boards are exactly identical):

    UART boot signature is

    02000000011a00006d617877656c6c000000000048535345000201000002010002a60000010001002e08e296cf63f9842019afd8b0582240a2874890ef58bff3a1dacb2235519af10ccf494c627c2b66b6341a1c219824cc3d5aa207c7085fb0bc4b36a6df6a58b41f6002b07cd9b0b7c47d9ca8d1aae57b8e8784a12f636b2b760d7d98a18f189760dfd0f23e2b0cb10ec7edc7c6edac3d9bdfefe0eddc3fff7fe9ad875195527d26e4bedf97814d72323830b9a62641dcbf93052c929def7c0674333f33CCCCC

    Silicon label has no security identifier "S1" or "SB":

    When I try to boot via UART the following SBL:
    C:\ti\pdk_am65xx_07_03_00_54\packages\ti\boot\sbl\binary\am65xx_idk\uart\bin\sbl_uart_img_mcu1_0_release.tiimage   (size: 71092 bytes)

    Transfer got always stuck at packet #250 at the same amount of transferred data 32000 bytes:

    Then I tried to connect via JTAG to the M3 core (using the CCS setup of our AM6548) and got the following error message:

    DMSC_Cortex_M3_0: Error connecting to the target: (Error -1274 @ 0x0) Error encountered during connect sequence.  The specific reason is unknown but may be the result of trying to access a Core or logic that is inaccessible due to a lack of Power, Clocks, or Authentication (i.e. Security is preventing).  If blocked by security, and if supported, access may be allowed after following the Authentication process. (Emulation package 8.3.0.00003)

    I guess that it is really a HS device (even if not marked on the label) and therefore M3 connection may be blocked.

    But I don't have any idea what causes the stop of xmodem boot. 

    Regards,
    Ruediger

  • 0 in reply to Ruediger Wurth
    TI__Mastermind 23125 points

    Ruediger, 

    could you also confirm if you can connect to the R5?

    Jian

  • 0 in reply to jian35385
    Intellectual 705 points

    Jian,

    Yes I confirm that I also cannot connect to R5. But I get a different error message:

    Regards,
      Ruediger

  • 0 in reply to jian35385
    Intellectual 470 points

    Hi Jian,


    I created a Target configuration file in which I excluded all GEL files that are used for initialization of A53 (M4_R5orA53_Startup.gel), R5 (M4_R5orA53_Startup.gel) and M3 (AM65xEVM.gel) cores

    Then I tried to connect to M3 and R5 cores and got the same error messages as Ruediger:


    When I try to boot via UART by using uart SBL (SDK6.03, SDK7.03 and SDK8.00.) I still have the same problem, the transfer got always stuck at packet #250 at the same amount of transferred data 32000 bytes.

    But if I tried to load the flash writer app via TeraTerm and xmodem, that RBL can load the whole flash writer app from SDK 6.03:
    \packages\ti\board\utils\uniflash\target\bin\am65xx_idk\uart_am65xx_idk_flash_programmer.tiimage

    Then I tried to connect to R5 core, and I can confirm that I can read  Silicon Revision Register:


    But still, i can not connect to the M3 core:


    Then I tried to use flash writer binaries from SDK 7.03 and SDK 8.00.:
    C:\ti\pdk_am65xx_07_03_00_54\packages\ti\board\utils\uniflash\target\bin\am65xx_idk\uart_am65xx_idk_flash_programmer_release.tiimage
    C:\ti\pdk_am65xx_08_00_00_36\packages\ti\board\utils\uniflash\target\bin\am65xx_idk\uart_am65xx_idk_flash_programmer_release.tiimage

    But when I try to load them via TeraTerm to the target board the transfer got always stuck at packet #250 at the same amount of transferred data 32000 bytes (same problem like with SBL).



    Regards,
    Novica

  • 0 in reply to Novica Jovanovic
    Intellectual 705 points

    TI guys,

    now it turned out that we got some SoCs with special marking. In fact they are HS types with TI dummy keys, security enforced.
    I think this explains the behaviour.

    Sorry for the inconvenience, I think we can close this topic here.
    Regards,
      Ruediger