Linux/PROCESSOR-SDK-AM335X: Identifying where to add changes for custom board via bitbake

Thanks Kemal 

- this looks like a really comprehensive response!

All the best,

- Richard

I am trying to inch my way forward by mocking up a board descriptor using minimal changes from the SDK (rather than jump straight in to using my custom board defintiions)

So I've created a layer meta-test-layer and have copied in to this some files from the meta-ti layer (changing the layer.conf to fit and renameing am33)

└── conf
  ├── layer.conf
  └── machine
   ├── include
   │   └── ti33x.inc
   └── test-machine-ext.conf

I can build using:

MACHINE=test-machine-ext bitbake arago-core-tisdk-image

once that completes I find that there appears to have been a defconfig file created which can be found at:

/home/richard/tisdk/build/arago-tmp-external-linaro-toolchain/work-shared/test-machine-ext/kernel-source/arch/arm/configs/tisdk_test-machine-ext_defconfig

- can you tell me what causes this file to be generated?

Do the new files need to be added via patches? or is there a mechanism for copying them in to the correct location within the source?

If they need to be done as patches: what is the preferred/correct mechanism for creating a patch to add a new file?

e.g. diff /dev/null my_new_defconfig > add_defconfig.patch 

does not appear to be with respect to the necessary root folder

Thanks for the help.

Best regards,

Richard

Hello Richard,

Richard McAleer said:

- can you tell me what causes this file to be generated?

Richard McAleer said:

Do the new files need to be added via patches? or is there a mechanism for copying them in to the correct location within the source?

Richard McAleer said:

If they need to be done as patches: what is the preferred/correct mechanism for creating a patch to add a new file?

e.g. diff /dev/null my_new_defconfig > add_defconfig.patch

Hi Kemal

Thanks for pointing me to that .inc file

I agree it makes most sense to me to copy a complete file (as patches seem more of a diff concept)

You say:

The best practice is to use the do_install task for copying the bigger and complete files, and use the patch method to make few changes over already existent files

I thought from my reading that the do_install was performed after the do_compile. 

Given that I will need the board & config files prior to compilation is it necessary to extend the do_unpack or do_configure to ensure the files end up where they should be prior to compilation?

Thanks greatly for the help.

Best regards,

Richard

Richard McAleer said:

Given that I will need the board & config files prior to compilation is it necessary to extend the do_unpack or do_configure to ensure the files end up where they should be prior to compilation?

Thanks that is a great help

it really looks like I am starting to make some progress
- adding the custom function to install my defconfig puts it in the correct place
- and the postfunc hooks look like they will be a really useful

after appending my config via
           KERNEL_CONFIG_FRAGMENTS_append_am335x-evm = " ${WORKDIR}/all_new_defconfig"
when i check the logs for the do_configure I can see that my "all_new_defconfig" is merged with "ti_sdk_am3x_release_defconfig"

and that there is a litany of comments similar to: Value of CONFIG_ARM_HAS_SG_CHAIN is redundant by fragment <PATH>/all_new_defconfig

This looks like it mostly works however I would prefer to not include any config fragments that are outwith my control

Having just read through: meta-ti/recipes-kernel/linux/setup-defconfig.inc
- it looks as though I should be able to use a complete config file rather than fragments
- this would work best for us at the moment as we have been locally making adjustments via menuconfig and persisting the resultant .config (I can however see the benefits of config fragments and will look to porting to that methd when we have spare time)

I am trying to work out from the setup recipe what is the best way to use the config file as the complete config for the build

the file meta-arago/meta-arago-distro/recipes-kernel/linux/linux-ti-staging/arago-armv8/defconfig
simply contains use-kernel-config=defconfig

I would have thought that replacing this with use-kernel-config=all_new_defconfig
- however if I try and set this variable in my .bbappend it appears to cause an unparsed line
- is it necessary to patch the meta-arago/meta-arago-distro/recipes-kernel/linux/linux-ti-staging/arago-armv8/defconfig file to change this
or am am I barking up the wrong tree?

Thanks again for all the help.
Kind regards,
- Richard

No, just populate the /home/richard/tisdk/sources/meta-ti/recipes-kernel/linux/linux-ti-staging-4.14/ti33x/defconfig file with the content from your all_new_defconfig. In this way the defconfig will be used as main defconfig file. You can also make the bitbake process verbose and see how the defconfig inclusion goes with this command.

MACHINE=am335x-evm bitbake -v linux-ti-staging -c do_configure

Thanks

I appreciate that would work 

However if I start manually changing the contents of a file in the ti-layer It it seems to defeat the purpose of adding our own layer

Is it possible to change that file (in the layer source code) using a task pre-hook from within our added layer?

or alternatively:

Would it be pratical (or possible) to override the do_config that is defined within the ti setup-defconfig.inc
I am presuming that my linux-ti-staging_%.bbappend will be parsed after the original in the ti layer?
So it would probalby end up looking like:

do_configure_remove();

      do_configure() {
         cp ${WORKDIR}/all_new_defconfig ${B}/.config
     }

Thanks again for all the help.

Kind regards,
- Richard

Putting identifying comments at the start and end of my defconfig 

I can confirm that following in my inux-ti-staging_%.bbppend appears to leave what I was looking for in build/.confg

deltask do_configure

do_configure() {
echo "RM_CHECK: executing config copy"
cp ${WORKDIR}/all_new_defconfig.cfg ${B}/.config
}

addtask do_configure before do_compile

I think this should be an acceptable way to go about it?

I appear to be creeping forwards slowly:I'll push on and see if this file remains after the compilation stage

Thanks for the help,

- Richard

Thansk for the help

Richard McAleer said:

Is it possible to change that file (in the layer source code) using a task pre-hook from within our added layer?

Richard McAleer said:

cp ${WORKDIR}/all_new_defconfig.cfg ${B}/.config