• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 719 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.

PROCESSOR-SDK-AM57X: PDK version 1.0.19 in Yocto

Sebastian Pastor
Prodigy 190 points
Part Number: PROCESSOR-SDK-AM57X

We have migrated our development from SDK 6.02 to SDK 8.02. However, when building our application from a Yocto build instead of building in my local machine I got compilation errors.

The problem is because of the name of functions McSPIMasterModeConfig and McSPIMasterModeEnable, that in pdk_am57xx_1_0_19 have been renamed to McSPIControllerModeConfig
and McSPIControllerModeEnable. Specifically, they are dfined at ~/ti/pdk_am57xx_1_0_19/packages/ti/csl/src/ip/mcspi/V0/mcspi.h while in SDK6 it was in ~/ti/pdk_am57xx_1_0_16/packages/ti/csl/src/ip/mcspi/V0/mcspi.h

The new naming is stated in the RTOS Migration Guide, so it is clear to me that we should go with the new names. When building locally, I set PDK_INSTALL_DIR ?= ${TI_RTOS_PATH}/pdk_am57xx_1_0_19 and it works, but when launching the build from Yocto the path is set by meta-ti, and the result file is build/tmp/sysroots-components/smc_8series/common-csl-ip-rtos/usr/share/ti/ti-pdk-tree/packages/ti/csl/src/ip/mcspi/V0/mcspi.h, which has the old names instead of the new ones.

This means that my code can only compile locally or remotely, but not both!

I have not been able to determine how to make meta-ti recipes to point to the proper PDK version. Our meta-ti points to tag 08.02.00.006, which is the same that the SDK 08.02 yocto build uses:

It seems that the mcspi.h is grabbed from common-csl-ip.inc, but in none of the branches the src/ip/mcspi/V0/mcspi.h file has the new names.

So, the question can be asked in several ways:

  • Why PDK differs when built from meta-ti or when downloaded from TI's SDK page?
  • How can we make meta-ti match PDK sources to be the same?
  • Where does shipped SDK grab the sources? I couldn't find the mcspi.h with the new names anywhere in the repos (likely I searched wrong)
  • 0
    TI__Mastermind 18165 points

    Hi Sebastian,

    Sebastian Pastor said:
    Why PDK differs when built from meta-ti or when downloaded from TI's SDK page?

    It looks like ti-pdk-fetch is defaulting to TI_PDK_VERSION ?= "2020.5.6". PROCESSOR-SDK-RTOS-AM57X 08.01.00.09 released in 2022, so that can't be right.

    Sebastian Pastor said:
    How can we make meta-ti match PDK sources to be the same?

    Change the default TI_PDK_VERSION to a newer version. I need to see what version that would be.

    Sebastian Pastor said:
    Where does shipped SDK grab the sources? I couldn't find the mcspi.h with the new names anywhere in the repos (likely I searched wrong)

    It looks like it's running a script, so it's grabbing the sources from somewhere, and the files are only created when it's actually building.

    I need to look into this in more detail, and will get back to you in 1 or 2 business days.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    TI__Mastermind 18165 points

    Hi Sebastian,

    Can you also share the bitbake command you executed and the error log that Yocto output?

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 190 points

    Hello Jared,

    The build is a "heavily customized" image for our target. And the output error is our application's Makefile complaining that the mentioned functions do not exist. If I change our application codebase to use the old names, the image builds with no errors.

    Since I've changed the sources, now it's not failing. I'll try to get the failing log later today.

  • 0 in reply to Sebastian Pastor
    TI__Mastermind 18165 points

    Hi Sebastian,

    I found out where the file is grabbed from. It's coming from the keystone-rtos/common-csl-ip repository (mcspi.h). The file: ./meta-ti/recipes-bsp/common-csl-ip/common-csl-ip.inc contains the commit (027d26031709ad6a0e9f84625d11a3419e486467) and link (git://git.ti.com/keystone-rtos/common-csl-ip.git) for it.

    I need to see where the newer version of the SDK is pulling from, so that it won't pull in the old names.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 190 points

    Hi Jared,

    That's what I pointed out in my first post of this thread. I couldn't find anywhere online the mcspi.h version that has the "Controller/Peripheral" naming instead of the "Master/Slave", so it looks like the SDK tar.gz distributes by TI is being built with different sources than the one Yocto grabs from meta-ti repo.

    Now, would that be the only part of the SDK that's different or should we check one by one each part of the repo? If that's the case, it doesn't seem to be easy at all since the naming and version is really hard, for example, the SDK 8.01.00.09 has the PDK 1.0.19 (guessed by the pdk_am57xx_1_0_19 directory) but I couldn't find the version that meta-ti would be building, and if it's "2020.5.6", then why is it so different than 1.0.19? How that would match?

    Best regards,

  • 0 in reply to Sebastian Pastor
    TI__Mastermind 18165 points

    Hi Sebastian,

    Sorry, I noticed you pointing that out the minute after I sent the response. Interestingly/annoyingly, it looks like the AM57 is the only device where we changed the function names. All of the J7 devices use the old Master/Slave names in their newest pdk tarballs.

    Going off of that information, I assume that each of the new names within the migration guide will stay as the old names within meta-ti and the yocto builds.

    I've filed an internal ticket and will ask our developers how they migrated the AM57 yocto builds compared to the other devices.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 190 points

    Hello Jared,

    Any update on this issue? Best regards,

  • 0 in reply to Sebastian Pastor
    TI__Mastermind 18165 points

    Hi Sebastian,

    I have not yet received an update from our developers.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 190 points

    Hello again Jared,

    It's been a while, when should we expect an update on this issue?

  • 0 in reply to Sebastian Pastor
    TI__Mastermind 18165 points

    Hi Sebastian,

    The pdk and the RTOS SDK are not supported for building through Yocto. The supported method of building and running is through the RTOS SDK.

    If you use the existing Yocto recipes for your custom image, I would use the older function names as the Yocto recipes are unlikely to change.

    Best,
    Jared

  • 0 in reply to Jared McArthur
    Prodigy 190 points

    That doesn't make a lot of sense: the RTOS SDK and the PDK are supported to build from yocto: that's why the images can be built, because they download, build and use the tools to do it, as you and I pointed out in this very same thread.

    Clearly there is a fork between what is delivered through the download page and what's delivered through the repos and recipes, but that doesn't solve the issue: how should we be able to build locally and through yocto? (Yocto builds are supported by TI, recipes are provided, and it works, except for this PDK issue)

    Local builds are great for development, but today's trend is to build final images through Yocto with everything in it. If the RTOS SDK is the way to go, is there an recipe or something that uses that to build applications and install them in the image, so we can use as an example?

  • 0 in reply to Sebastian Pastor
    TI__Mastermind 18165 points

    Hi Sebastian,

    Unsupported is more "untested". Additionally, there isn't really a endorsed way of building complete images from RTOS firmwares. For local development, I would replace the csl directory with the common-csl-ip repository (https://git.ti.com/cgit/keystone-rtos/common-csl-ip).

    Best,
    Jared