How to develop for NO effectively without excessive build times?

Development Development & Testing
1

Can someone help me with what is the recommended process for developing code for the latest NO version in a sensible way without excessive build times?

I want to make changes to the code in the common_drivers repo. Currently, I make changes in that repo then create a patch file in the main coreelec repo under CoreELEC\projects\Amlogic-ce\devices\Amlogic-no\patches\common_drivers\Patch.patch. When I then build the code, the changes in the patch file do not take effect.

To make the changes apply to the build, I’ve found I need to also make a changes in a patch file for linux in the path CoreELEC\projects\Amlogic-ce\devices\Amlogic-no\patches\linux\dummy.patch.

This works, but each build is taking ~ 1 hour. On the same machine/setup the changes to the same part of the code for -NG builds (in the linux-amlogic repo), only take a few minutes.

Is the much longer build times expected when using the new kernel? Or is there a better way to apply the patches that would result in a shorter build time?

2

I just went through this and was recommended to just clone git repo into sources directory for every package you modify.
And set PKG_URL=""

  • projects/Amlogic-ce/packages/linux/sources
  • projects/Amlogic-ce/packages/mediacenter/kodi/sources

It’s probably the same for common_drivers.
Then packages get rebuilt for every change without dealing with patch files.

3

Another option is to build only changed files which takes only fraction of whole package build time.

# remove linux package stamp file
rm build.CoreELEC-Amlogic-no.aarch64-22/.stamps/linux/build_target

# change files in folder build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2c3e329b7dec94edae5e9fb5f33669239c384436
# like yours build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2c3e329b7dec94edae5e9fb5f33669239c384436/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c

# build linux package
./scripts/build linux

# linux kernel file is build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2c3e329b7dec94edae5e9fb5f33669239c384436/arch/arm64/boot/Image.lzo
# and can be copied directly to your device as kernel.img and reboot

# if build success
make

# when you are done make a proper patch
# or make a repo in build folder (git init, ...) and create patch directly from there

But back to original question: editing patch file projects\Amlogic-ce\devices\Amlogic-no\patches\common_drivers\Patch.patch should make linux cleaned and rebuild. And changes from this patch are applied. No need to touch linux package.

5

After creating a patch for common_drivers, doing

rm build.CoreELEC-Amlogic-no.aarch64-22/.stamps/linux/build_target

./scripts/build linux

# if build ok
make

worked and only took a few minutes.

Well that is not happening, nothing gets rebuilt and looking at the source files in build.CoreELEC-Amlogic-no.aarch64-22 the patch hasn’t been applied.

6

Seems you are right: patch in projects/Amlogic-ce/devices/Amlogic-no/patches/common_drivers doesn’t trigger linux package rebuild.
It must be in package folder projects/Amlogic-ce/packages/linux-drivers/amlogic/common_drivers/patches.

Which means what you wrote above is also wrong: removing linux stamp file and build linux again doesn’t apply patch either.

7

You are right, I didn’t check it properly the patch wasn’t being applied.

Putting it in the packages folder does work, but also takes a very long time. How is development on the new kernel meant to be do done? It is an order of magnitude slower than for 4.9 (or from memory even the original 5.x kernel), surely that is not how the CE team is working?

8

I wrote above: remove linux stamp, change directly in build folder, build package and image.
If change is only in kernel.img then copy it directly and reboot. Same applies for SYSTEM when used with toram boot argument. For kodi you can also mask kodi service on device and copy kodi.bin and run it directly. There are multiple options. Write directly what you are doing and we will find the most optimized way of work.

The compile time is what it is. Be glad we don’t build with CFI anymore where it was crazy slow even on fast machine. I think the time is longer because of using clang compiler (because of loading dovi.ko). With gcc it should be faster but as I wrote not usable.

9

Can you expand on how to do this? I was only aware of the option of running make and then updating with the .tar.

At the moment, just adding a print statement,

    pr_info("test print 1\n");

in amdv.c before this line common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c at 57d3e1da32f3ee14043a8fdd3e1c7a8aa7b674ff · CoreELEC/common_drivers · GitHub

10

Read my post 3 above, I add few more lines to it.

11

I use just some “helper” scripts.

For changes in kernel.img:
kernel.img (985 Bytes)

And one script when something should be changed dirty in SYSTEM:
system.sh (2.4 KB)

For SYSTEM the paramter toram is need in config.ini.

Like for amdv.c kernel.img does apply.

12

@doppingkoala, how it is going? Builds any faster or you still need some help?

13

Thanks for asking,

I’ve been able to get the kernel to far more sensibly using the steps you both gave. For some reason, equivalent changes in 4.9 still happen far faster though.

When would the SYSTEM script need to be used?

Could you also give some more steps for the kodi.bin? I don’t know how to do the masking that you suggested.

Don’t suppose it is possible to narrow down what is being rebuilt further? Based on the out and the time taken, it seems the vast majority of the time is going into rebuilding objects in drivers/ and only a small portion for objects in common_drivers/

14

True, building 4.9 kernel is faster I assume because of using gcc instead of clang with 5.15.

SYSTEM script is used for copying SYSTEM squashfs file where most of the image reside. Like all the binaries, kernel modules, … and kodi binary.

It depends on a work if kernel needs to be updated or system or both.

If you compile only kodi then just binary build.CoreELEC-Amlogic-no.aarch64-22/build/kodi-dd0179fe95cf0acc60430f5dea4a4ffdb28e65a5/.aarch64-libreelec-linux-gnu/kodi.bin needs to be copied to device somewhere on /storage/ and kodi restarted.

To disable kodi from the image to be started automatically then service needs to be masked
systemctl mask kodi
and after reboot kodi will not be started automatically.

After you build kodi you need to copy kodi.bin and start it manually
./kodi.bin -fs &
and then to stop it
killall kodi.bin

Something like that :thinking:

15

./system.sh kodi

Kodi will be dirty build and SYSTEM will be copied to target and device reboot.

1 Like
16

For kodi only, assuming the new kodi.bin is copied to /storage/downloads, the following work

systemctl stop kodi
mount --bind /storage/downloads/kodi.bin /usr/lib/kodi/kodi.bin
systemctl start kodi

Goes back to the original when device is rebooted or by stopping kodi, running umount /usr/lib/kodi/kodi.bin and then restarting kodi.

17

no need to mount bind, just

systemctl stop kodi
chmod 755 /storage/downloads/kodi.bin
/storage/downloads/kodi.bin -fs &

to stop kodi

killall kodi.bin

18

Bumping this as it appears every single file in the entire kernel is being rebuilt despite only one changing. Is this actually necessary ? Or can it be avoided somehow?

I can put some time into trying to do this if someone can give me some pointers to start with. Taking 45+ minutes for every build is really making the -NO kernel very difficult / impractical to work with… Which is quite annoying given I have worked out how to activate both the second video layer and second OSD layer with the -NO kernel.

19

When using that command you gave it gets stuck on the boot logo forever

20

Then you have some error in your kodi binary. Try with /usr/lib/kodi/kodi.bin binary and you will see it works.

22

build linux
./scripts/build linux

if you run command again
./scripts/build linux
nothing will be build because it already succeed

now modify file build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2722dae9e554249d1339726e4f07a45b4af0313b/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c (mentioned in some post above)

simple change

$ diff aurNp build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2722dae9e554249d1339726e4f07a45b4af0313b/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c-1 build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2722dae9e554249d1339726e4f07a45b4af0313b/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c
--- build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2722dae9e554249d1339726e4f07a45b4af0313b/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c-1 2025-12-29 12:29:34.235974538 +0100
+++ build.CoreELEC-Amlogic-no.aarch64-22/build/linux-2722dae9e554249d1339726e4f07a45b4af0313b/common_drivers/drivers/media/enhancement/amdolby_vision/amdv.c   2025-12-29 12:28:35.668810368 +0100
@@ -17994,6 +17994,7 @@ __setup("recovery_part=", recovery_mode_
 
 int __init amdolby_vision_init(void)
 {
+       pr_info("test print 1 for dirty build\n");
        pr_info("%s:module init\n", __func__);
        if (platform_driver_register(&aml_amdolby_vision_driver)) {
                pr_err("failed to register amdolby_vision module\n");

remove stamp file for linux package to build only changes
rm build.CoreELEC-Amlogic-no.aarch64-22/.stamps/linux/build_target

build linux as usually
./scripts/build linux

you can see line
CC common_drivers/drivers/media/enhancement/amdolby_vision/amdv.o

at the end of build you see package build statistic

Build timing details:
================================
              unpack:      1.766
     pre-build setup:      0.003
           configure:      0.003
                make:     38.282
        make install:      0.030
        copy sysroot:      0.012
     cleanup install:      0.147
--------------------------------
          total time:     40.243

it took 40 seconds (depends on your computer speed) to make new linux kernel

same applies to kodi and most packages (only some can’t be build dirty)

I do this for ages without issues. I’m glad to provide some more informations if needed until you succeed.

I’m not sure why you are saying 45+ minutes for every build: this is time to make build completely new. Which is not needed when you are changing only some packages.