• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 31 subscribers
  • Views 657 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.

MCU-PLUS-SDK-AM263X: Signature/Building of custom bootloader doesn't work. The prebuilt one from TI works.

Grizzly Bear
Prodigy 10 points
Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: TMDSCNCD263, UNIFLASH

1) Tools Used:

ccsstudio: 12.5.0

SDK: mcu_plus_sdk_am263x_09_00_00_35

OS: Development PC OS Ubuntu 22.04

2) Hardware: Sitara Eval Kit, AM263x Control Card, TMDSCNCD263

3) Importing the BL example from

/opt/ti/mcu_plus_sdk_am263x_09_00_00_35/examples/drivers/boot/sbl_qspi/am263x-cc/

into code composer studio:

File->Import->CCS Project

4) The post build step fails:

makefile:166: recipe for target 'post-build' failed
makefile_ccs_bootimage_gen:87: *** extraneous 'endif'.  Stop.

5) Trying to fix this: uncommenting in makefile_ccs_bootimage_gen the all target and replacing it with:

all:
    @echo Test
    $(OBJCOPY) --strip-sections -O binary $(OUTFILE) $(BOOTIMAGE_BIN_NAME)
    $(BOOTIMAGE_CERT_GEN_CMD) --image-bin $(BOOTIMAGE_BIN_NAME) --core R5 --swrv 1 --loadaddr $(SBL_RUN_ADDRESS) --sign-key $(BOOTIMAGE_CERT_KEY) --out-image $(BOOTIMAGE_NAME) --debug DBG_SOC_DEFAULT
    @echo  Boot image: am263x:r5fss0-0:nortos:ti-arm-clang $(BOOTIMAGE_NAME) Done !!!

5) The generated ttimage is flashed to the target but it won't work. We are in Boot mode QSPI - 1S Fallback UART boot mode

6) The precompiled ttimage from

/opt/ti/mcu_plus_sdk_am263x_09_00_00_35/examples/drivers/boot/sbl_qspi/am263x-cc/r5fss0-0_nortos/ti-arm-clang/sbl_qspi.debug.tiimage

Does work.

  • 0
    TI__Guru*** 135355 points

    Hello Grizzly,

    No need to make that replacement, just open the makefile_ccs_bootimage_gen and remove the endif on line 87. That resolves the build issue. I will open a bug ticket on this so it can be fixed in future releases.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 10 points

    Hi Ralph,

    thanks for your reply. The ccs build does now work and sbl_qspi_am263x-cc_r5fss0-0_nortos_ti-arm-clang.tiimage is generated.

    However, the generated Image does not work.

    The following config file was generated for the uart_uniflash.py utility:

    --flash-writer=/opt/ti/mcu_plus_sdk_am263x_09_00_00_35/tools/boot/sbl_prebuilt/am263x-cc/sbl_uart_uniflash.release.tiimage

    --file=../ccs_ws/sbl_qspi_am263x-cc_r5fss0-0_nortos_ti-arm-clang/Release/sbl_qspi_am263x-cc_r5fss0-0_nortos_ti-arm-clang.tiimage --operation=flash --flash-offset=0x0

    After flashing I would expect some output on the UART (as with the precompiled tiimage). The fall back is activated -> no valid SBL was loaded by RBL.

    Best regards

    Marco

  • 0 in reply to Grizzly Bear
    TI__Guru*** 135355 points

    Hello Marco,

    Can you check if you have a correctly generated sbl_qspi_am263x-cc_r5fss0-0_nortos_ti-arm-clang.tiimage output in your CCS project?

    Trying to run through these steps ahead I noticed that if after doing an initial build, I modify the makefile_ccs_bootimage_gen as described, it does not always build the .tiimage file when rebuilding. 

    If you don't see that file, try cleaning the project or even just deleting the Release folder to force it to re-build everything from scratch. It looks like CCS thinks that the build is largely identical so it's not executing the step that generates the .tiimage.

    One of my co-workers tested a .tiimage file via UART and saw it working so I'm leaning to this being your issue. I will plan to go through the full test myself still to verify, but wanted to give you this information first.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    TI__Guru*** 135355 points

    Hi Marco,

    I've tested the sbl_qspi example as well now and it is working as expected. If you are not getting it to work and have verified the .tiimage file is generated properly, I will need details about your boot loading process:

    • Switch settings used on the CC
    • What COM port is being used to try and load the firmware
    • cfg file details such as which appimage is being loaded and at what offsets

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    TI__Guru*** 135355 points

    Hello Marco,

    I received your screencast offline and was able to watch the entirety of it. Appreciate the clear and detailed walkthrough of your steps. Based on that, I think I understand what is occurring here.

    When you finish loading the QSPI bootloader, you are just resetting the board without any other steps. However for the AM263 to boot via the QSPI bootloader, you need to set the correct SOP pins on the device via the DIP switches on the AM263CC. You'll see that we document both QSPI and UART Boot mode switch configurations on this page: https://dev.ti.com/tirex/content/mcu_plus_sdk_am263x_09_00_00_35/docs/api_guide_am263x/EVM_SETUP_PAGE.html#autotoc_md29

    Please try and use the DIP switch settings displayed for QSPI boot after loading the sbl_qspi example and see if you are able to get the expected output. Those are the steps both my coworker and I followed when validating that the CCS project version of sbl_qspi is working as expected.

    As a final note, what is very misleading here and frankly surprising to me was that you got a QSPI print out when using the stock boot loader. I'm not entirely sure why that occurred, but that is not what I was expecting when you just rebooted the board without making any changes to the switches.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 10 points

    Hello Ralph,

    I have the board in Boot Mode QSPI (1S) - Single Read UART Fallback as mentioned in the AM263x Control Card Hardware User's Guide

    So whenever an invalid SBL is at flash address 0 the UART fall back is started, that is how I understand it. That would explain the behavior of the screen cast I believe. 

    I switched now to qspi Mode 1S, nothing is shown on the UART.

    Verified in CCS:

    Cortex_R5_0: GEL Output: SOP MODE = 0x00000002
    Cortex_R5_0: GEL Output:
    QSPI - 1S Functional boot mode

    Your colleague Frank mentioned that it might be due to ES Silicon. This is what I find on the board:

    The Eval Kit PCB#: PROC110E2

    OPN# TMDSCNCD263 

    On the Sitara chip:

    XAM2634B

    OMFHAZCZ

    21CG3LW G1

    (hardly readable, so no warranty that it is correct)

    Could you please send me your ttimage file? This way we can verify weather the HW settings are correct or not. If this fails we need to check if the flash content is the same.

    Thanks

    Marco

    P.S.: I am out of office next week and cannot do tests

  • 0 in reply to Grizzly Bear
    TI__Guru*** 135355 points

    Hello Marco,

    Grizzly Bear said:
    So whenever an invalid SBL is at flash address 0 the UART fall back is started, that is how I understand it. That would explain the behavior of the screen cast I believe. 

    So our process to load images is to put the board explicitly in UART mode first, load the SBL and application images, and then switch over to QSPI boot and power cycle to execute the application code. I've never tried just keeping it in Boot Mode QSPI (1S) - Single Read UART Fallback for the whole process. I'd have to see how to revert the board into a state with a bad SBL to even test that which I need to ask about how to do.

    That you got 'C' outputs would give an initial sign that the UART mode was occurring properly but I'd prefer if we use the same flow here. You can also try both flows with the out file I'm posting here.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/sbl_5F00_qspi_5F00_am263x_2D00_cc_5F00_r5fss0_2D00_0_5F00_nortos_5F00_ti_2D00_arm_2D00_clang.tiimage

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 10 points

    Hi Ralph.

    my colleague Alen has found out that with openssl version 1.1.1 the signing of the SBL works in a way that RBL is loading it. I have openssl 3.05 installed (default Ubuntu Version). I'll verify this next week. Maybe you can clarify the supported ssl versions. 1.1.1 is quite old...

    Best regards

    Marco

  • 0 in reply to Grizzly Bear
    TI__Guru*** 135355 points

    Hi Marco,

    Sorry for the delay here, I was able to test the QSPI Boot w/ UART fallback as you have been and it's been working as expected on my end. Then I dug into the openssl piece that looks to be the proverbial smoking gun here:

    The following is straight out of our User's Guide for SDK installation: https://dev.ti.com/tirex/content/mcu_plus_sdk_am263x_09_00_00_35/docs/api_guide_am263x/SDK_DOWNLOAD_PAGE.html#INSTALL_OPENSSL

    • In Linux,
      • The v1.1.1 is important, OpenSSL 3.0 won't work with the current signing scripts of SDK. So if you have Ubuntu 18.04, do below in Linux Ubuntu shell to install openssl 
            $ sudo apt install openssl
      • If you have an Ubuntu version higher than that, make sure that you install the 1.1.1 version. You can get the 1.1.1 packages from http://security.ubuntu.com/ubuntu/pool/main/o/openssl/. The packages required are openssl, libssl and libssl-dev

    When you are back, please give this a try and that should hopefully resolve your issue.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 10 points

    Hi Ralph,

    sorry for my late reply I was on a business trip for the last week,

    yes that is what my colleague found out. Do you think TI will move to a more recent version? I  mean openssl 1.1.1 was release back in 2018 and we have a brand new TI product here.

    Thanks

    Marco

  • 0 in reply to Grizzly Bear
    TI__Guru*** 135355 points

    Hi Marco,

    I would imagine at some point we would yes but I don't have any details as to when.

    Typically the reason newer TI products end up with some older dependencies on third party software libraries is because updating to newer versions would require ensuring backwards compatibility for older TI products. So it can take added time to validate that across older products.

    Best Regards,

    Ralph Jacobi