A fast way to flash incrementally compiled kernels

changed the description

By ryang on 2018-10-01T18:24:26

Thank's a lot for opening this issue!

That's funny because I would have said that re-flashing the kernel was the easy part. (and that something like "sudo fastboot flash kernel zImage" would do good while taking few seconds).

If you can explain in details how to incrementally xcompile and modify kernel sources/config for a given device starting from current state of sources, I would be very interested, it would probably avoid me many trial and error testing.

By Pierre Parent on 2018-10-01T19:33:08

That's funny because I would have said that re-flashing the kernel was the easy part. (and that something like "sudo fastboot flash kernel zImage" would do good while taking few seconds).

Devices can differ in the flashing process. Some devices don't even have fastboot. While there may be easier ways to update a kernel for some devices that may not be the case for all. This is somethign that pmbootstrap could possibly handle in device agnostic way behind the scenes.

If you can explain in details how to incrementally xcompile and modify kernel sources/config for a given device starting from current state of sources, I would be very interested, it would probably avoid me many trial and error testing.

Set up a build environment from the kernel source directory with envkernel.sh. There's more detail about using envkernel.sh here:
https://wiki.postmarketos.org/wiki/Mainlining_Guide#envkernel.sh

Run make <defconfig> on the first compile and subsequently if the config is modified. When the source code is modified run make to do an incremental compile.

The step that is device specific is flashing the the compiled kernel.

The zImage will be in .output/arch/arm/boot/zImage. If a device uses appended dtb then you may need to do that manually. Looks like hammerhead does. NOTE: This is completely untested but in theory I think this is how it goes for hammerhead.

Append the dtb manually

$ cat .output/arch/arm/boot/zImage .output/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dtb > .output/arch/arm/boot/zImage-dtb

Flash the zImage

$ fastboot flash zimage .output/arch/arm/boot/zImage-dtb

By ryang on 2018-10-01T21:01:34

Thank's a lot!

Set up a build environment from the kernel source directory with envkernel.sh. >There's more detail about using envkernel.sh here:

Ok but first I need to clone kernel sources manually? (Otherwise I get "ERROR: This folder is not a linux source tree: /home/pparent/git/pmbootstrap" ) How do I make sure that I get the exact same version as the current sources used for my device in the binary form?

make

And I don't get how will this know for which arch to compile and which configuration to apply if we did not specify anything before?

By Pierre Parent on 2018-10-01T21:40:16

Ok but first I need to clone kernel sources manually?

Yes. hammerhead is using linux-postmarketos-qcom so git clone the source.

How do I make sure that I get the exact same version as the current sources used for my device in the binary form?

Checkout the revision in aports/main/linux-postmarketos-qcom/APKBUILD.

And I don't get how will this know for which arch to compile and which configuration to apply if we did not specify anything before?

envkernel.sh will use the device you set when you ran pmbootstrap init. If you've chosen hammerhead then ARCH=arm is already set.

Use the config that linux-postmarketos-qcom is compiled with:
aports/main/linux-postmarketos-qcom/config-postmarketos-qcom.armhf

Normally the config is in the kernel source. You could just copy config-postmarketos-qcom.armh temporariliy to arch/arm/config/hammerhead_defconfig. Then do make hammerhead_defconfig.

By ryang on 2018-10-01T22:02:28

Ok thank's a lot it's very clear!

Maybe we can add all this info on the wiki.

And I found the cause of our backlight issue on Nexus 5. Solving it should be easy now! (See other issue).

By Pierre Parent on 2018-10-01T22:10:51

Regarding the methods in the "Installing an updated kernel" section: I think it would be good if we did not require to have a working kernel running in order to incrementally update the kernel. Otherwise, if you compile a kernel that doesn't boot, you won't be able to use the incremental update unless you flash another kernel first (which breaks the workflow).

Maybe implement something like this: $ pmbootstrap flasher flash_kernel --kernel=path/to/current/kernel

(the tricky path would be calling mkinitfs with the custom kernel and saving the resulting boot.img and other files in a temporary directory. mkinitfs does not only generate the initramfs in postmarketOS, but also the boot.img file and other image formats that combine the initramfs and kernel.)

We could even add an alias in envkernel.sh to quickly flash the kernel from the source folder, without specifying the path, once we have that. (For example: "flash".)

EDIT: not all devices are Android devices/have adb support. So if we could do it with pmbootstrap flasher, we should be able to make it work for all devices where pmbootstrap flasher is already working.

By Oliver Smith on 2018-10-09T06:07:42

added help wanted label

I've had a mock up of method 2d mentioned in the original post which I fleshed out some more.
https://gitlab.com/ryang2678/pmbootstrap/commits/feature/wip-package-envkernel

The philosophy is that the kernel developer will:

use envkernel to compile their source code
- perform other device/kernel specific steps that are required to build a working kernel.
run pmbootstrap envkernel to create an apk package
do what ever with that package (i.e. pmbootstrap flasher flash_kernel)

What it does is set up an abuild in chroot native (/home/pmos/build). The kernel build output (located in chroot_native /mnt/linux/.output) is symlinked to /home/pmos/build/src. Then it uses abuild to package the build output (abuild rootpkg). The rootpkg command runs prepare() and packaging steps.

Example:
Compile the kernel.

cd ~/code/linux
source ~/pmbootstrap/helpers/envkernel.sh
make tegra_postmarketos_defconfig
make -j6

Package and flash the kernel.

pmbootstrap envkernel --package linux-samsung-p4wifi
pmbootstrap flasher flash_kernel

Caveats:

Some kernels have oddities in the APKBUILD prepare() and build() step.
These things the kernel developer are required to run themselves in the processes of compiling a ready to package kernel.
Examples:
- i9100 has some isorec things to prepare.
- linux-postmarketos-qcom has some dtbTool command in the build() step.
Subpackages aren't been packaged.
- The linux-postmarketos-* kernels have a dev subpackage. That isn't packaging properly at the moment so I'm setting subpackages="".

A benefit of this method is that loadable kernel modules are also easily updated when you have a working kernel. The kernel package can be served locally with the python webserver.

By ryang on 2018-10-12T18:51:14

@ryang2678: correct me if I'm wrong, but I think all the caveats can be solved by simply using build --src:

Compile the kernel (optional).

cd ~/code/linux
source ~/pmbootstrap/helpers/envkernel.sh
make tegra_postmarketos_defconfig
make -j6

Compile the kernel again (but we're using ccache, so it is fast), package and flash the kernel:

pmbootstrap build --src=~/code/linux linux-samsung-p4wifi
pmbootstrap flasher flash_kernel

By Oliver Smith on 2018-10-15T20:32:10

Yeah build --src is fast. I thought there might be faster way especially when running on mechanical hard drives. Previously I was using a basic shell script to repackage a boot.img with the zImage. Then it adb sideloads it.

I've thought about maybe implementing this by calling pmbootstrap as an API or something rather than built in. It's mostly a bunch of calls to chroot run and a couple calls to modify the APKBUILD.

By ryang on 2018-10-15T21:34:13

@ollieparanoid

Compile the kernel again (but we're using ccache, so it is fast), package and flash the kernel:
pmbootstrap build --src=~/code/linux linux-samsung-p4wifi
pmbootstrap flasher flash_kernel

I know that flasher flash_kernel triggers the mkinitfs script but I think it creates a boot.img with the old kernel (the one installed in the chroot), or the build --src also updates the package installed in the chroot?

When I rebuild a package (e.g. pmbootstrap build device-aaa-bbb --force) I usually run something like pmbootstrap chroot -r -- apk add -u /mnt/pmbootstrap-packages/armhf/device-aaa-bbb-0.0.1-r0.apk before triggering a pmbootstrap flasher flash_kernel again

By Daniele Debernardi on 2018-10-15T22:01:55

@drebrez: right, from reading the code it seems like we do not update the packages in the rootfs chroot before flashing. (We could add that though, to support this workflow.)

Yeah build --src is fast. I thought there might be faster way especially when running on mechanical hard drives. Previously I was using a basic shell script to repackage a boot.img with the zImage. Then it adb sideloads it.

This sounds pretty cool, but it seems to be hard/impossible to both save the user from compiling the kernel again, but at the same time supporting all the special cases from the APKBUILDs (isorec, dtbtool) as you pointed out. (Now that I've read your patches, I understand why that is the case.)

I've thought about maybe implementing this by calling pmbootstrap as an API or something rather than built in. It's mostly a bunch of calls to chroot run and a couple calls to modify the APKBUILD.

I'm interested in how this would look like, would you like to write up some pseudo code to illustrate this?

By Oliver Smith on 2018-10-17T07:54:32

I'm interested in how this would look like, would you like to write up some pseudo code to illustrate this?

I hadn't thought that part through very much. I was mostly thinking from utility standpoint. I guess the args param would be required for such calls. I don't know how possible that is.

By ryang on 2018-10-18T00:29:07

@ollieparanoid We should improve the combination pmbootstrap build --src=... with pmbootstrap flasher flash_kernel

I just tried a bit and something strange happened.

Here is what I've done:

build current kernel package with pmbootstrap build linux-samsung-klte

now ~/.local/var/pmbootstrap/packages/armhf contains linux-samsung-klte-3.4.113-r0.apk

build kernel package with pmbootstrap build --src=/path/to/sources linux-samsung-klte

now packages folder contains linux-samsung-klte-3.4.113-r0.apk and linux-samsung-klte-3.4.113_p20181110001756-r0.apk

zap and create device chroot pmbootstrap chroot -r
install the kernel apk add linux-samsung-klte

the latest version gets installed (linux-samsung-klte-3.4.113_p20181110001756-r0.apk)

run pmbootstrap flasher flash_kernel

it will install all the remaining required packages, create the initfs and flash it

build again the package with pmbootstrap build --src=/path/to/sources linux-samsung-klte

now the package folder contains a new kernel package with a higher number

run pmbootstrap flasher flash_kernel again

(020114) [00:49:23] (rootfs_samsung-klte) calculate depends of device-samsung-klte, device-samsung-klte-kernel-downstream (pmbootstrap -v for details)
(020114) [00:49:25] WARNING: Package 'linux-samsung-klte' in your aports folder has version 3.4.113-r0, but the binary package repositories already already have version 3.4.113_p20181110013854-r0! See also: <https://postmarketos.org/warning-repo2>
(020114) [00:49:25] (rootfs_samsung-klte) install
(020114) [00:49:25] (rootfs_samsung-klte) % apk --no-progress add -u --virtual .pmbootstrap /mnt/pmbootstrap-packages/armhf/linux-samsung-klte-3.4.113-r0.apk
(1/2) Downgrading linux-samsung-klte (3.4.113_p20181110001756-r0 -> 3.4.113-r0)
(2/2) Installing .pmbootstrap (0)
...

Any idea why the downgrading?

By Daniele Debernardi on 2018-11-10T01:18:43

@ryang2678 here is what I'm using for building and flashing the just built kernel:

$ pmbootstrap build --src=~/Development/kernel-dev/android_kernel_samsung_msm8974/ linux-samsung-klte
$ pmbootstrap chroot -r -- sh -c "apk del linux-samsung-klte && apk add linux-samsung-klte"
$ pmbootstrap flasher flash_kernel

By Daniele Debernardi on 2018-11-10T14:41:39

@ollieparanoid I've investigated a bit and I think the problem is in this piece of code of apk.py

# Local packages: Using the path instead of pkgname makes apk update
# packages of the same version if the build date is different
packages_todo = replace_aports_packages_with_path(args, packages_todo, suffix, arch)

which returns the package with the version of the APKBUILD and not the latest version inside the repository.

When building a package with --src it creates a version with the date inside, the install_is_necessary function correctly identify that there is a new package version

data_installed["version"] = 3.4.113_p20181116230450-r0
data_repo["version"] = 3.4.113_p20181116231301-r0
compare = pmb.parse.version.compare(data_installed["version"], data_repo["version"])
compare is -1 # b) Repo newer

I'm not sure how to solve this...

EDIT: this might work, but don't know if it breaks some other logic

diff --git a/pmb/chroot/apk.py b/pmb/chroot/apk.py
index 9b04a101..29be8cdf 100644
--- a/pmb/chroot/apk.py
+++ b/pmb/chroot/apk.py
@@ -168,10 +168,9 @@ def replace_aports_packages_with_path(args, packages, suffix, arch):
     for package in packages:
         aport = pmb.build.find_aport(args, package, False)
         if aport:
-            apkbuild = pmb.parse.apkbuild(args, aport + "/APKBUILD")
+            data_repo = pmb.parse.apkindex.package(args, package, arch, False)
             apk_path = ("/mnt/pmbootstrap-packages/" + arch + "/" +
-                        package + "-" + apkbuild["pkgver"] + "-r" +
-                        apkbuild["pkgrel"] + ".apk")
+                        package + "-" + data_repo["version"] + ".apk")
             if os.path.exists(args.work + "/chroot_" + suffix + apk_path):
                 package = apk_path
         ret.append(package)

By Daniele Debernardi on 2018-11-21T06:50:34

@drebrez: thanks for investigating this, and sorry for the answering delay. I'll look into this in detail tomorrow.

By Oliver Smith on 2018-11-20T08:36:32

@ollieparanoid I've used the change I posted for the last few days and I didn't noticed any breaks in other operations.

With that change I simply rebuild the kernel package and flash and everything is upgraded automatically.

$ pmbootstrap build --src=~/Development/kernel-dev/android_kernel_samsung_msm8974/ linux-samsung-klte
$ pmbootstrap flasher flash_kernel

Then we will need someway to build a new package when using the envkernel.sh and the mainline kernel sources

By Daniele Debernardi on 2018-11-20T09:07:42

mentioned in commit wiki@b7eb3765

By postmarketOS Wiki bot on 2018-11-21T06:42:40

mentioned in issue #1685 (closed)

By Oliver Smith on 2018-11-21T06:54:09

mentioned in issue #1686 (closed)

By Oliver Smith on 2018-11-21T06:59:09

mentioned in issue #1687

By Oliver Smith on 2018-11-21T06:59:20

I have read through the whole thread again. It's gotten a bit confusing due to the various topics mixed in, so I have split it up:

#1685 (closed): pmbootstrap downgrades packages built with --src (the bug @drebrez found)
#1686 (closed): A fast way to flash incrementally compiled kernels (part II)
#1687: pmbootstrap API

Also I've updated the wiki page and linked to the hammerhead related Q&A provided above.

By Oliver Smith on 2018-11-21T07:02:32

closed

By Oliver Smith on 2018-11-21T07:02:32

A fast way to flash incrementally compiled kernels

Set up envkernel

Incremental compiles

Installing an updated kernel

Child items ...

Activity