• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 883 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: Using custom kernel in local workspace for Yocto TI-SDK

Patricia Holden
Intellectual 265 points
Part Number: SK-AM62

I have chosen as my base image "tisdk-base-image".  I created my own image called "custom-base-image.bb".  I added Wifi networking and changed image name to "custom-base-image".  My SK-AM62 Rev A board comes up, WAN0 shows up and is connected to my home router.  Now the fun begins.  I need to make too many kernel changes for the customer's hardware board to just use a new defconfig or patches.  So I have a local copy of the linux kernel.  How do I set this up for Yocto to use without breaking all the recipes that rely on the kernel?

Thanks!

  • 0
    TI__Guru 69602 points

    Hi Patricia,

    will try to get back to you on this here in a day or two to outline some options.

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 265 points

    Thanks so much!  My latest idea on how to tackle this one is to create a new "linux-ti-staging-custom.bin" and creating a tag to go with it that can be used in COMPATIBLE_MACHINE definition in tisdk-core-bundle.inc.  Do you think this would work?

  • 0 in reply to Patricia Holden
    TI__Guru 69602 points
    Patricia Holden said:
    I need to make too many kernel changes for the customer's hardware board to just use a new defconfig or patches.  So I have a local copy of the linux kernel.  How do I set this up for Yocto to use without breaking all the recipes that rely on the kernel?

    So first, I'd recommend reviewing the applicable Yocto documentation. What you are doing is a very common need, and there's several ways to do this, with different levels of "automation" you can get from Yocto built-in tooling, all of which have their own advantages and disadvantages. Whichever approach is the "best" somewhat depends on the situation, use-case, and individual preferences.

    https://docs.yoctoproject.org/4.0.14/kernel-dev/index.html

    When I do board port/bringup myself like I just recently did working at a customer site, I follow the following general approach:

    • Do any Linux and U-Boot customization "outside" of Yocto, directly working on the respective trees using the associated build methods
    • Once Linux and U-Boot are reasonable stable and in good working condition, generate patches for those (using `git format-patch`), and incorporate them into a custom Yocto layer, to allow for fully-integrated image builds. Make sure to use and configure the same Linux Kernel/U-Boot base commits both outside and from within Yocto so that the resulting binaries will be functionally equivalent without any delta.

    Doing so in my opinion allows for quick iterations doing changes/builds/tests of those core components in an un-abstracted and direct manner, suitable for low-level debug and analysis work including JTAG, etc.. And then, when moving the near-final patches into Yocto, I'll have an immediately usable, working, deployable, and re-creatable way to build everything.

    As for how a custom layer can look like that ties everything together see below `meta-custom` layer I created as part of the aforementioned recent board port and bringup effort.

    The custom layer was added to the `sources/` folder like this...

    a0797059@dasso:~/tisdk/am62pxx-evm/sources (dev)
$ ll
total 124
drwxrwxr-x 13 a0797059 a0797059  4096 Dec  7 01:03 ./
drwxrwxr-x  4 a0797059 a0797059  4096 Dec  5 20:17 ../
drwxrwxr-x  9 a0797059 a0797059  4096 Dec  5 20:17 bitbake/
drwxrwxr-x  7 a0797059 a0797059  4096 Dec  5 20:17 meta-arago/
drwxrwxr-x 13 a0797059 a0797059  4096 Dec  5 20:18 meta-arm/
drwxrwxr-x  5 a0797059 a0797059  4096 Dec  6 02:04 meta-custom/
drwxrwxr-x 12 a0797059 a0797059  4096 Dec  5 20:19 meta-edgeai/
drwxrwxr-x 15 a0797059 a0797059  4096 Dec  5 20:18 meta-openembedded/
drwxrwxr-x 12 a0797059 a0797059  4096 Dec  5 20:17 meta-qt5/
drwxrwxr-x  5 a0797059 a0797059  4096 Dec  5 20:18 meta-ti/
drwxrwxr-x 15 a0797059 a0797059  4096 Dec  5 20:17 meta-tisdk/
drwxrwxr-x 19 a0797059 a0797059  4096 Dec  5 20:18 meta-virtualization/
drwxrwxr-x  8 a0797059 a0797059  4096 Dec  5 20:19 oe-core/

    ...and has the following layout (customer-specific info is x'd out):

    a0797059@dasso:~/tisdk/am62pxx-evm/sources (dev)
$ tree meta-custom
meta-custom
├── conf
│   └── layer.conf
├── COPYING.MIT
├── README
├── recipes-bsp
│   └── u-boot
│       ├── files
│       │   ├── 0001-ram-k3-ddrss-do-not-touch-ctrl-regs-during-training.patch
│       │   ├── 0002-configs-am62px_evm_a53_defconfig-Disable-autoboot.patch
│       │   ├── 0003-configs-am62px_evm_a53_defconfig-Enable-a-temporary-.patch
│       │   ├── 0004-xxxxxx.patch
│       │   ├── 0005-xxxxxx.patch
│       │   ├── 0006-xxxxxx.patch
│       │   ├── 0007-xxxxxx.patch
│       │   ├── 0008-xxxxxx.patch
│       │   ├── 0009-xxxxxx.patch
│       │   ├── 0010-xxxxxx.patch
│       │   ├── 0011-xxxxxx.patch
│       │   ├── 0012-xxxxxx.patch
│       │   ├── 0013-xxxxxx.patch
│       │   ├── 0014-xxxxxx.patch
│       │   ├── 0015-xxxxxx.patch
│       │   └── 0016-xxxxxx.patch
│       └── u-boot-ti-staging_2023.04.bbappend
└── recipes-kernel
    └── linux
        ├── linux-ti-staging-6.1
        │   └── k3
        │       ├── 0001-xxxxxx.patch
        │       ├── 0002-xxxxxx.patch
        │       ├── 0003-xxxxxx.patch
        │       ├── 0004-xxxxxx.patch
        │       ├── 0005-xxxxxx.patch
        │       ├── 0006-xxxxxx.patch
        │       ├── 0007-xxxxxx.patch
        │       ├── 0008-xxxxxx.patch
        │       ├── 0009-xxxxxx.patch
        │       ├── 0010-xxxxxx.patch
        │       ├── 0011-xxxxxx.patch
        │       ├── 0012-xxxxxx.patch
        │       ├── 0013-xxxxxx.patch
        │       ├── 0014-xxxxxx.patch
        │       ├── 0015-xxxxxx.patch
        │       ├── 0016-xxxxxx.patch
        │       └── defconfig
        └── linux-ti-staging_6.1.bbappend

    The key files amending the U-Boot and Linux kernel recipes look like this:

    a0797059@dasso:~/tisdk/am62pxx-evm/sources (dev)
$ cat meta-custom/recipes-bsp/u-boot/u-boot-ti-staging_2023.04.bbappend
SRCREV = "71b8c840ca61a4e11b2cdf63b0e6580ecb427912"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += " \
    file://0001-ram-k3-ddrss-do-not-touch-ctrl-regs-during-training.patch \
    file://0002-configs-am62px_evm_a53_defconfig-Disable-autoboot.patch \
    file://0003-configs-am62px_evm_a53_defconfig-Enable-a-temporary-.patch \
    file://0004-xxxxxx.patch \
    file://0005-xxxxxx.patch \
    file://0006-xxxxxx.patch \
    file://0007-xxxxxx.patch \
    file://0008-xxxxxx.patch \
    file://0009-xxxxxx.patch \
    file://0010-xxxxxx.patch \
    file://0011-xxxxxx.patch \
    file://0012-xxxxxx.patch \
    file://0013-xxxxxx.patch \
    file://0014-xxxxxx.patch \
    file://0015-xxxxxx.patch \
    file://0016-xxxxxx.patch \
"

a0797059@dasso:~/tisdk/am62pxx-evm/sources (dev)
$ cat meta-custom/recipes-kernel/linux/linux-ti-staging_6.1.bbappend
# Look in the generic major.minor directory for files
FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}-6.1:"

SRC_URI += " \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://xxxxxx.patch \
    file://defconfig \
"

    Note how the Kernel recipe adds a custom `defconfig` file which was generated based on the original aarch64 defconfig w/ added changes, and then saved/generated via the Kernel `make savedefconfig` mechanism.

    Lastly, one needs to make sure to add the new layer to `conf/bblayers.conf` for example like this (last line):

    a0797059@dasso:~/tisdk/am62pxx-evm/build (dev)
$ cat conf/bblayers.conf
# This template file was created by taking the oe-core/meta/conf/bblayers.conf
# file and removing the BBLAYERS section at the end.

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "7"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

# Layers configured by oe-core-setup script
BBLAYERS += " \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-tisdk \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arago/meta-arago-distro \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arago/meta-arago-extras \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arago/meta-arago-demos \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arago/meta-arago-test \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-qt5 \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-virtualization \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-networking \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-python \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-oe \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-gnome \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-filesystems \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-openembedded/meta-multimedia \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-ti/meta-ti-extras \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-ti/meta-ti-bsp \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arm/meta-arm \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-arm/meta-arm-toolchain \
        /home/a0797059/tisdk/am62pxx-evm/sources/oe-core/meta \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-edgeai \
        /home/a0797059/tisdk/am62pxx-evm/sources/meta-custom \
"

    Regards, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 265 points

    Can't I just create a new COMPATIBLE_MACHINE tag and add a new linux-ti-staging_custom.bb to use my own source which I already have in place in my own customer repository?  Seems like a lot less work. 

  • 0 in reply to Patricia Holden
    TI__Guru 69602 points

    I've not done it like this myself but you can certainly try it. May work well for experimentation, but usually you don't want to fork/modify any of the existing layers, so there'll be still some of the steps you need. Please review the kernel development guide pointed to earlier. If you think you found some elegant / easy solution feel free to share it here

    Thanks, Andreas

  • 0 in reply to Andreas Dannenberg
    Intellectual 265 points

    I am not too worried about doing something out of the ordinary, as this won't be going back to the TI base code space.  I'm just concerned with getting the desired outcome:  bitbake recipe that allows me to use my local kernel/uboot directories for development.  The hardware I'm doing the kernel and uboot for digresses quite a bit from the TI development boards.  I will definitely post the resulting solution once I've got it.

  • 0 in reply to Patricia Holden
    TI__Guru 69602 points

    Hi Patricia,

    sounds good, I'm curious what you come up with for your given needs.

    Regards, Andreas