public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>
To: "Huhulea,
	Nicusor Liviu (DI CTO FDS CES LX SVCS)"
	<nicusor.huhulea@siemens.com>,
	"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: Re: [PATCH] linux-custom: compile only those specified dtbs
Date: Mon, 12 Aug 2024 17:16:30 +0200	[thread overview]
Message-ID: <160d72b6-d23e-46bf-9315-ed30da3a652e@siemens.com> (raw)
In-Reply-To: <DB3PR10MB690833C214CB30C07972D8CFE6852@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM>

Your email client is not yet properly configured to indent / mark
citations. That makes it very hard to find and read your replies. Please
fix.

On 12.08.24 16:44, Huhulea, Nicusor Liviu (DI CTO FDS CES LX SVCS) wrote:
> 
> 
> ________________________________________
> From: Kiszka, Jan (T CED) <jan.kiszka@siemens.com>
> Sent: Friday, August 9, 2024 7:56 PM
> To: Huhulea, Nicusor Liviu (DI CTO FDS CES LX SVCS); isar-users@googlegroups.com
> Subject: Re: [PATCH] linux-custom: compile only those specified dtbs
> 
> On 09.08.24 12:59, 'Nicusor Huhulea' via isar-users wrote:
>> The current implementation makes a full kernel build and that means it will
>> compile all dtbs specified by the bsp makefile e.g arch/arm64/boot/dts/ti/Makefile
>> Currently the required dtbs are given by the DTB_FILES.
>>
>> These changes are checking if the DTB_FILES is specified, compile only those
>> and avoids compiling all the dtbs from the bsp directory. Otherwise build all dtbs
>> specified by the kernel source.
>> Preventing the automatic dtb builds is made by using target specific build
>> commands e.g KERNEL_IMAGETYPE
> 
> Fairly subtle optimization. Can't we identify the default image(s) the
> kernel would build and fill this automatically?
> Yes, we can do that, but I don't think we want that because if there are multiple targets(image types) enabled 
> we wouldn't know what to choose. The reason being the difference between a full build and a specific target build. 
> So far I have identified 2 differences between a full build and a specific target build: one is the dtbs target and the
> other one is the different image types that are produced in one build session. e.g: for arm the kernel might have the 
> configuration to build both zImage and Image.gz(full-build case) but we need only one image for deployment(specific target build).
> However, building all of these images every time might not be necessary, which is where the KERNEL_IMAGETYPE comes into
> the picture hence the reason for these changes. 
> 
>> The compilation of the dtbs accepts the following formats e.g:
>> Kernel Post 6.x:
>> a) full path from the architecture directory:
>>    arch/${ARCH}/boot/dts/bsp_dir/test.dts
>>    arch/${ARCH}/boot/dts/bsp_dir/test.dtb
>> b) relative path from the dts directory: bsp_dir/test.dts
>> c) device tree blob file: bsp_dir/test.dtb
>> Kernel Pre 6.x:
>> The same as on Kernel Post 6.x but without the bsp_dir
>>
>> The differences when building a full build and when using a specific target
>> build are:(tests were made on the machine phyboard-mira on 6.x and 4.x versions)
>> specific target: Build needed 00:02:08, 2219688k disk space linux-phy 6.x
>> full build:      Build needed 00:02:14, 2271528k disk space linux-phy 6.x
>> The time difference: the full build took 6s longer than the specific target build
>> The disk space difference: the full build used 50.6MB more disk space than
>> the specific target build.
> 
> That 50M is build-time space, right? What's the size difference on the
> target?
> Yes, 50M disk space. I don't have a phyboard-mira at my disposal, but I can
> try on a iot2050 board to see the difference on the target.
> 
>> In conclusion the specific target build is slightly faster and uses less
>> disk space.
>>
>> For now the DTB_FILES variable should accept only Device Tree Blobs(.dtb)
>> because some areas still depends on it e.g: do_copy_boot_files, plugins
> 
> We are not yet using dtbo files (overlays) built by the kernel in any
> projects I know, but those would no longer be built then, right?
> Exactly, but these changes are still keeping the full-build case in place
> As you said, because I haven't seen any dtbo files around I left this out for the moment
> and because the changes were starting to be quite big.(can be treated as a follow up on this
> as compiling the dtbo is in line with the dtb)
> 
>>
>> Signed-off-by: Nicusor Huhulea <nicusor.huhulea@siemens.com>
>> ---
>>  meta-isar/conf/machine/imx6-sabrelite.conf    |  2 +
>>  meta-isar/conf/machine/phyboard-mira.conf     |  2 +
>>  .../linux/files/debian/isar/build.tmpl        | 63 +++++++++++++++++--
>>  .../linux/files/debian/isar/install.tmpl      | 12 +++-
>>  meta/recipes-kernel/linux/linux-custom.inc    |  6 ++
>>  5 files changed, 79 insertions(+), 6 deletions(-)
>>
>> diff --git a/meta-isar/conf/machine/imx6-sabrelite.conf b/meta-isar/conf/machine/imx6-sabrelite.conf
>> index e48823d6..bffebdc1 100644
>> --- a/meta-isar/conf/machine/imx6-sabrelite.conf
>> +++ b/meta-isar/conf/machine/imx6-sabrelite.conf
>> @@ -15,4 +15,6 @@ MKUBIFS_ARGS := "-m 0x1000 -e 0x3e000 -c 1500"
>>  UBINIZE_ARGS = "-vv -m 0x1000 -p 0x40000"
>>  IMAGE_FSTYPES ?= "ubi-ubifs"
>>
>> +KERNEL_IMAGETYPE = "zImage"
>> +
>>  DTB_FILES = "imx6q-sabrelite.dtb"
>> diff --git a/meta-isar/conf/machine/phyboard-mira.conf b/meta-isar/conf/machine/phyboard-mira.conf
>> index feec4e54..1d2b3e1c 100644
>> --- a/meta-isar/conf/machine/phyboard-mira.conf
>> +++ b/meta-isar/conf/machine/phyboard-mira.conf
>> @@ -20,6 +20,8 @@ DTB_FILES = "imx6q-phytec-mira-rdk-nand.dtb"
>>
>>  IMAGE_INSTALL += "barebox"
>>
>> +KERNEL_IMAGETYPE = "zImage"
>> +
>>  BAREBOX_CONFIG = "imx_v7_defconfig"
>>  BAREBOX_ENV = "phytec-mira-env"
>>  BAREBOX_BASE_BIN = "barebox-phytec-phycore-imx6q-som-nand-1gib"
>> diff --git a/meta/recipes-kernel/linux/files/debian/isar/build.tmpl b/meta/recipes-kernel/linux/files/debian/isar/build.tmpl
>> index bafc5ca4..90222adc 100644
>> --- a/meta/recipes-kernel/linux/files/debian/isar/build.tmpl
>> +++ b/meta/recipes-kernel/linux/files/debian/isar/build.tmpl
>> @@ -21,15 +21,21 @@ do_build() {
>>      KR=$(${MAKE} O=${KERNEL_BUILD_DIR} -s --no-print-directory kernelrelease)
>>      sed -i "s/@KR@/${KR}/g" ${S}/debian/control ${S}/debian/linux-image-${KERNEL_NAME_PROVIDED}.*
>>
>> -    if echo "${DEB_BUILD_PROFILES}" | grep -q "kernel"; then # Build kernel scripts and tools
>> -        ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} ${KERNEL_EXTRA_BUILDARGS} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}"
>> +    MAKE_COMMON_ARGS="O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} ${KERNEL_EXTRA_BUILDARGS} KCFLAGS=${KCFLAGS} KAFLAGS=${KAFLAGS}"
>> +    if echo "${DEB_BUILD_PROFILES}" | grep -q "kernel"; then
>> +        if [ -n "${KERNEL_IMAGETYPE}" ]; then # Override the default compilation
>> +            ${MAKE} ${MAKE_COMMON_ARGS} ${KERNEL_IMAGETYPE} modules
> 
> You are losing KERNEL_EXTRA_BUILDARGS.
> 
>> +            compile_dtbs
>> +        else # Full build
>> +            ${MAKE} ${MAKE_COMMON_ARGS} ${KERNEL_EXTRA_BUILDARGS}
>> +        fi
>>      elif echo "${DEB_BUILD_PROFILES}" | grep -q "kbuild"; then # Build kernel scripts and tools
>> -        ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} ${KERNEL_EXTRA_BUILDARGS} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" scripts
>> +        ${MAKE} ${MAKE_COMMON_ARGS} ${KERNEL_EXTRA_BUILDARGS} scripts
> 
> Why this change and those 2 below? They look wrong.
> These changes are some optimizations but after carefully inspecting these I saw that I need to fix some ${KERNEL_EXTRA_BUILDARGS} addition
> and loosing in some areas.
> 

Don't mix topic, write separate commits then.

>>          if grep -q -E "CONFIG_STACK_VALIDATION=y|CONFIG_HAVE_OBJTOOL=y" ${KERNEL_BUILD_DIR}/.config && [ -d "tools/objtool" ]; then
>> -            ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" tools/objtool || true
>> +            ${MAKE} ${MAKE_COMMON_ARGS} tools/objtool || true
>>          fi
>>          if grep -q "CONFIG_MODULES=y" ${KERNEL_BUILD_DIR}/.config; then
>> -            ${MAKE} O=${KERNEL_BUILD_DIR} ${PARALLEL_MAKE} KCFLAGS="${KCFLAGS}" KAFLAGS="${KAFLAGS}" modules_prepare
>> +            ${MAKE} ${MAKE_COMMON_ARGS} modules_prepare
>>          fi
>>      fi
>>
>> @@ -37,6 +43,53 @@ do_build() {
>>      set +x
>>  }
>>
>> +compile_dtbs() {
>> +    local prefix="arch/${ARCH}/boot/dts/"
>> +
>> +    for dtb in ${DTB_FILES}; do
>> +        # Handle the case where a standalone(with no path .dtb/.dts) file may reside within
>> +        # a specific BSP directory or not(kernel pre-6.x)
>> +        if [[ ("${dtb}" == *.dtb || "${dtb}" == *.dts) && "${dtb}" != */* ]]; then
>> +            bsp_dir=""
>> +            dts_path=""
>> +            if [[ "${dtb}" == *.dtb ]]; then
>> +                dts="${dtb%.dtb}.dts"
>> +            else
>> +                dts="${dtb}"
>> +            fi
>> +
>> +            # recursively search for the dts file in all possible BSP directories
>> +            while IFS= read -r dts_path; do
>> +                if [ -n "${dts_path}" ]; then
>> +                    # Eliminate the prefix and dts to get only the bsp_dir
>> +                    bsp_dir="${dts_path#${prefix}}"
>> +                    bsp_dir="${bsp_dir%${dts}}"
>> +
>> +                    relative_dtb_path="${bsp_dir}${dtb}"
>> +                else
>> +                    relative_dtb_path="${prefix}${dtb}"
>> +                fi
>> +            done < <(find "${prefix}" -type f -name "${dts}")
>> +
>> +        # Check if the path is relative (starts with arch/${ARCH}/)
>> +        # and if it does then extract the relative path from the architecture specific path
>> +        elif [[ "${dtb}" == "${prefix}"* ]]; then
>> +            relative_dtb_path="${dtb#${prefix}}"
>> +        else
>> +            # directly use the given dtb
>> +            relative_dtb_path="${dtb}"
>> +        fi
>> +
>> +        # Check if it's a .dts file
>> +        if [[ "${relative_dtb_path}" == *.dts ]]; then
>> +            #  Change .dts to .dtb
>> +            relative_dtb_path="${relative_dtb_path%.dts}.dtb"
>> +        fi
>> +
>> +        ${MAKE} ${MAKE_COMMON_ARGS} ${relative_dtb_path}
>> +    done
>> +}
>> +
>>  print_settings() {
>>      cat <<EOF
>>  # Build settings:
>> diff --git a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
>> index 00011517..c0a60f4e 100644
>> --- a/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
>> +++ b/meta/recipes-kernel/linux/files/debian/isar/install.tmpl
>> @@ -124,7 +124,17 @@ install_hooks() {
>>
>>  install_dtbs() {
>>      [ -n "${CONFIG_OF}" ] || return 0
>> -    ${MAKE} O=${O} INSTALL_DTBS_PATH=${deb_img_dir}/usr/lib/linux-image-${krel} dtbs_install
>> +    prefix="arch/${ARCH}/boot/dts/"
>> +    src_dir="${O}/${prefix}"
>> +    dst_dir=""
>> +
>> +    dst_dir="${deb_img_dir}/usr/lib/linux-image-${krel}/"
>> +    find "${src_dir}" -type f -name '*.dtb' | while IFS= read -r dtb_file; do
>> +        local relative_path="${dtb_file#"${src_dir}"}"
>> +        mkdir -p "${dst_dir}$(dirname "${relative_path}")"
>> +        cp "${dtb_file}" "${dst_dir}/${relative_path}"
>> +        echo "Copying ${dtb_file} to ${dest_dir}/${relative_path}"
>> +    done
>>  }
>>
>>  install_kmods() {
>> diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
>> index 6aa70fd3..31cc480b 100644
>> --- a/meta/recipes-kernel/linux/linux-custom.inc
>> +++ b/meta/recipes-kernel/linux/linux-custom.inc
>> @@ -76,6 +76,7 @@ TEMPLATE_VARS += "                \
>>      KERNEL_DEBIAN_DEPENDS         \
>>      KERNEL_BUILD_DIR              \
>>      KERNEL_FILE                   \
>> +    KERNEL_IMAGETYPE              \
>>      KERNEL_HEADERS_DEBIAN_DEPENDS \
>>      LINUX_VERSION_EXTENSION       \
>>      KERNEL_NAME_PROVIDED          \
>> @@ -84,12 +85,17 @@ TEMPLATE_VARS += "                \
>>      KAFLAGS                       \
>>      DISTRIBUTOR                   \
>>      KERNEL_EXTRA_BUILDARGS        \
>> +    DTB_FILES                     \
>>  "
>>
>>  inherit dpkg
>>  inherit template
>>  inherit kbuildtarget
>>
>> +DTB_FILES ?= ""
>> +
>> +KERNEL_IMAGETYPE ?= ""
>> +
>>  # Add custom cflags to the kernel build
>>  KCFLAGS ?= "-fdebug-prefix-map=${CURDIR}=."
>>  KAFLAGS ?= "-fdebug-prefix-map=${CURDIR}=."
> 
> Quite a lot of new code for rather moderate optimizations. Maybe we
> should rather filter the built files when installing? That should be
> doable in 3 lines or so.
> 
> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center
> 
> Yes, indeed seems a lot of code but these changes were made having in mind fixing the compilation of those extra dtbs that were not
> belonging to that specific target bsp. And the optimizations are just a side effect(maybe as a bonus), they are not on the foreground. 
> The reason because it's a lot of code is primarily because I wanted to keep the DTB_FILES declarations as is in the upper layers and bring
> new features e.g full architecture path, etc. plus this handles a KERNEL Pre 6.x dtb builds

Again, please split topic-wise. And I'm not yet fully convinced about
the value compared to the extra configuration effort.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/160d72b6-d23e-46bf-9315-ed30da3a652e%40siemens.com.

  reply	other threads:[~2024-08-12 15:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-02 11:41 'Nicusor Huhulea' via isar-users
2024-08-02 17:03 ` 'Jan Kiszka' via isar-users
2024-08-08 12:41   ` 'nicusor.huhulea@siemens.com' via isar-users
2024-08-09 16:57   ` 'Jan Kiszka' via isar-users
2024-08-09 10:59 ` [PATCH v2] " 'Nicusor Huhulea' via isar-users
2024-08-09 10:59   ` [PATCH] " 'Nicusor Huhulea' via isar-users
2024-08-09 16:56     ` 'Jan Kiszka' via isar-users
2024-08-12 14:44       ` 'nicusor.huhulea@siemens.com' via isar-users
2024-08-12 15:16         ` 'Jan Kiszka' via isar-users [this message]
2024-08-13 11:55 ` [PATCH 1/3] linux-custom: optimization on kernel's make command 'Nicusor Huhulea' via isar-users
2024-08-13 11:55   ` [PATCH 2/3] linux-custom: compile only those specified dtbs 'Nicusor Huhulea' via isar-users
2024-08-13 12:33     ` 'Jan Kiszka' via isar-users
2024-08-14 17:37       ` 'nicusor.huhulea@siemens.com' via isar-users
2024-08-13 11:55   ` [PATCH 3/3] phyboard-mira.conf: use a specific target build 'Nicusor Huhulea' via isar-users
2024-08-13 12:10     ` 'nicusor.huhulea@siemens.com' via isar-users
2024-08-13 12:34     ` 'Jan Kiszka' via isar-users
2024-08-13 12:31   ` [PATCH 1/3] linux-custom: optimization on kernel's make command 'Jan Kiszka' via isar-users

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=160d72b6-d23e-46bf-9315-ed30da3a652e@siemens.com \
    --to=isar-users@googlegroups.com \
    --cc=jan.kiszka@siemens.com \
    --cc=nicusor.huhulea@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox