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?
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.
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.
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.
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?
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.
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/
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
