• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 4100 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.

Linux/AM3352: defconfig problems when using meta-arago/meta-ti and a custom layer

c0wb0y
Prodigy 130 points

Part Number: AM3352

Tool/software: Linux

Hello,

I'm having a rather difficult time trying to get the linux-ti-staging-4.9 kernel configured using my own defconfig for a custom am3352 board.

I've set up my meta-arago centralized build environment using the steps found on Arago's Setting Up Build Environment page, with the exception that I'm using the Linaro 6.2.1-2016 toolchain instead of the Linaro 5.3-2016 toolchain and I used the arago-morty-next-config for the layer configuration.

I've also added a custom layer for my board (which I created with the yocto project's yocto-bsp tool, that is located in a different directory), named meta-custom, and have added my defconfig (which is actually a full .config that I made for the 4.9.10 kernel) and board-specific patch to meta-custom/recipes-kernel/linux/linux-ti-staging-4.9. My linux-ti-staging_4.9.bbappend file at meta-custom/recipes-kernel/linux looks like this:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-4.9:"

SRC_URI += "file://defconfig"
SRC_URI += "file://0001-Added-support-for-my-board.patch"

For my custom.conf machine configuration in meta-custom/conf/machine/, I require the ti33x.inc from meta-ti/conf/machine/include. I believe that this is where most of my problems are stemming from because this include declares SOC_FAMILY = "ti33x", which appears to force the defconfig at meta-ti/recipes-kernel/linux/linux-ti-staging-4.9/ti33x/. From there, it looks like the defconfig (and ultimately the .config) gets built from the defconfig fragments at tisdk/build/arago-tmp-external-linaro-toolchain/work/custom-linux-gnueabi/linux-ti-staging/4.9.10+gitblahblahblah/build/source/ti_config_fragments/ using the defconfig_builder.sh script.

In my layer.conf for my layer, I changed BBFILE_PRIORITY_custom to equal "11" and have also added my layer to the end of the BBLAYERS variable in the bblayers.conf file in tisdk/build/conf/

I'm able to successfully complete the bitbake core-image-minimal build for my board, but the .config file in the work directory for the kernel isn't anything like my defconfig, which I believe is due to the defconfig_builder.sh script overwriting my defconfig, and therefore doesn't produce the correct kernel for my board. Can anyone help me rectify this situation?

Thank you,

Jon

  • 0
    TI__Guru 55345 points
    Hello Jon,

    I think the build system doesn't take you defconfig file. There are many recipes-kernel directories within the layers. Please, check which one the OE build system takes and apply your changes to this one.

    Best regards,
    Kemal
  • 0 in reply to Kemal R. Shakir
    Prodigy 130 points

    The issue was that I was doing an append of the linux-ti-staging kernel recipe. So what ended up happening then? Well, executing the command

    bitbake -e linux-ti-staging | grep "SRC_URI="

    after building the kernel revealed the answer to be

    SRC_URI=" git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git;protocol=git;branch=ti-lsk-linux-4.9.y             file://defconfig file://defconfig file://0001-Added-support-for-my-board.patch".

    The first defconfig is from the linux-ti-staging_4.9 recipe from the meta-ti layer and the second defconfig in from my layer.  The TI defconfig gets picked up by the script in meta-ti/recipes-kernel/linux/setup-defconfig.inc, which is required by TI's linux-ti-staging_4.9 recipe (line 9 in the recipe).  This is all shown to be true when the defconfig at tisdk/build/arago-tmp-external-linaro-toolchain/work/custom-linux-gnueabi/linux-ti-staging/4.9.10+gitAUTOINC+1c74e8801c-r22a.arago5/ contains the one line "use-tisdk-config=ti_sdk_am3x_release".  So though my defconfig gets included into SRC_URI, it does not get used because it was not the first defconfig to be seen by the script I mentioned earlier.

    How did I overcome this issue?  I copied the contents of TI's linux-ti-staging_4.9 recipe into my own linux-ti-staging_4.9.bb, stripped out all of the non-ti33x related lines (which was quite a few of them) and appended my patch to SRC_URI.  This forced the use of my recipe over TI's recipe and caused the kernel to be built with my defconfig.

    If you are facing the same or similar issue, here are some questions you can ask yourself:

    1) Do you have meta-ti included in your conf/bblayers.conf?

    2) Do you have your layer included in conf/bblayers.conf?

    3) Are you having bitbake build for your device (MACHINE=mydevice)?

    4) Are you appending to the linux-ti-staging recipe or are you using your own in place of the TI recipe?  From my experience, you need to be using your own recipe.

    5) After building the kernel, what does SRC_URI contain (bitbake -e linux-ti-staging | grep "SRC_URI=")?

    6) Have you checked your recipe for typos?

    Several Notes:

    1) When I was still trying to append to the TI kernel recipe, I tried

    SRC_URI_remove = "file://defconfig"

    SRC_URI += "file://defconfig"

    The _remove removes ALL of the instances of whatever is being specified between the "" from SRC_URI; this included both my defconfig and TI's defconfig.

    2) Including use-tisdk-config= "" in my append file did nothing (not that I really noticed at least).

    3) Adding the following anonymous python function to the end of my append file did remove the TI defconfig, but not before the script in setup-defconfig.inc had used it.

    python () {

    src_uri = d.getVar('SRC_URI', True)

    src_uri = src_uri.replace(" file://defconfig", "", 1)

    d.setVar('SRC_URI', src_uri)

    }

    If anyone else has a better solution, or any other "does or don'ts", I'd appreciate your responses :)

  • 0 in reply to c0wb0y
    Intellectual 715 points

    c0wb0y said:
    If anyone else has a better solution, or any other "does or don'ts", I'd appreciate your responses :)

    I had a similar problem, except I am not using Arago, but building it in Yocto after adding meta-ti layer. For a while I couldn't get my kernel configuration fragments into the .config (doing work in my own .bbappend recipe linux-ti-staging_%.bbappend). Then after investigating code in "meta-ti/recipes-kernel/linux/setup-defconfig.inc", I noticed that it expects my kernel config fragments additionally be listed in this variable: "KERNEL_CONFIG_FRAGMENTS". Then I added them there in my recipe:

    KERNEL_CONFIG_FRAGMENTS += "${WORKDIR}/rpmsg_client_samples.cfg \
    ${WORKDIR}/unset_uio_and_prueth.cfg \
    "

    And everything started working beautifully. No need to copy TI recipe and put it into my layer, I can just use a .bbappend file.

  • 0 in reply to c0wb0y
    TI__Guru 70392 points
    c0wb0y said:

    Several Notes:

    1) When I was still trying to append to the TI kernel recipe, I tried

    SRC_URI_remove = "file://defconfig"

    SRC_URI += "file://defconfig"

    The _remove removes ALL of the instances of whatever is being specified between the "" from SRC_URI; this included both my defconfig and TI's defconfig.

    I was encountering the same issue when I tried replacing the defconfig file for the linux-ti-staging Kernel in its entirety with a custom one in a custom layer however I was able to "creatively wrestle this into submission" and got it to work by doing the below. Sharing my bbappend file here in case it's helpful for some other reader:

    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-5.10:"

# Remove the defconfig that gets pulled from the machine-specific folder located
# within recipes-kernel/linux/linux-ti-staging-5.10
SRC_URI:remove = "file://defconfig"

# Add defconfig located within the machine-specfic folder within our custom
# layer here. Note that we decorate the URI with a "dummy option" to make it
# unique so that we can remove the original config without harming the new
# one (the parser won't latch onto it and remove it).
SRC_URI:append = " file://defconfig;subdir=."

    See here for more complete steps including how to create a custom layer/bbapend file and configure the Kernel for AM335x: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1260215/processor-sdk-am335x-how-to-change-the-kernel-config-in-yocto/4786598#4786598

    Regards, Andreas