Linux 4.7.2 with Novena patchset applied

I tried installing this kernel on my novena last night unsuccessfully.  Compilation went well and applying the patches did too, but upon boot the kernel reports as panic and each cpu core halts.  it tries to reboot but is unable to, so the system is halted.  Not sure what could have gone wrong. I'll try it again this evening though.

For convenience, I've just built a novena patched (but otherwise vanilla) 4.7.2 kernel zImage, novena.dtb and module set, and uploaded it on the novena-kernel-patches release page, here.

It's only about 102MiB compressed. You can download this and try booting from it, so (doing this as root, for simplicity, and assuming your /boot is mounted):

~ # wget -c https://github.com/sakaki-/novena-kernel-patches/releases/download/v4.7.2/4.7.2-build.tar.xz
~ # tar -xJf 4.7.2-build.tar.xz
~ # cd 4.7.2-build
4.7.2-build # cp -r place_in_lib_modules/4.7.2 /lib/modules/
4.7.2-build # mv /boot/zImage{,.bak}
4.7.2-build # mv /boot/novena.dtb{,.bak}
4.7.2-build # cp place_in_boot/{zImage,novena.dtb} /boot/
4.7.2-build # sync

Then try a reboot and see what happens.

Best, sakaki

One thing I forgot to ask was whether the kernel was panicking before or after starting init (systemd, assuming your base distro is Debian).

As a further diagnostic therefore, I've uploaded a version of the novena-patched 4.7.2 kernel which includes a tiny, integral busybox-based initramfs to the novena-kernel-patches release page, here. It is only 7MiB.

You can copy the file (zImage-busybox) to your /boot directory (renaming to zImage) with the accompanying novena.dtb, and try booting from this (no need for a module set). If successful, it should quickly drop you to a busybox (ash) console root shell. If this works and lets you do things like "ls /" and mount partitions from /dev/sda (or whatever), you can be reasonably sure that the patched 4.7.2 kernel itself works with your Novena, and that any problems lie later (during systemd init, and/or module loading).

Unfortunately I don't have access to a laptop configuration machine and so have had to do most of the testing on a "just the board" system (and some further tests on a desktop), so it is quite possible there is a hardware issue with the patchset that I haven't anticipated.

Any feedback from your tests would be very much appreciated!

hth, sakaki

Hi again,

a bit of fun with kdb, but I think this should be fixed now. Turns out the problem was not with the patches per se but with some other code that had changed between 4.4 and 4.7.2, in drivers/gpu/drm/imx/imx-ldb.c -> imx_ldb_bind(...).

Specifically, the 4.4 code used to do a two-stage endpoint lookup:

        port = of_graph_get_port_by_id(child, imx_ldb->lvds_mux ? 4 : 2);
        if (port) {
            struct device_node *endpoint, *remote;

            endpoint = of_get_child_by_name(port, "endpoint");

but this changed by 4.7.2 to a single-step lookup:

        ep = of_graph_get_endpoint_by_regs(child,
                           imx_ldb->lvds_mux ? 4 : 2,
                           -1);

Unfortunately the new  of_graph_get_endpoint_by_regs(...) call kills the kernel and stops the boot (if you have an eDP daughter card fitted, so it doesn't affect "just the board" Novenas).

I've pushed a change to novena-kernel-patches to revert to the old, two-stage lookup, and the resulting kernel is booting fine on my loaner laptop-spec Novena.

Assuming you still have the 4.7.2 tarball around (simply wget it again, if not), you can do the following to test this new kernel:

~ $ cd novena-kernel-patches
novena-kernel-patches $ git pull
(to fetch the updated patch)
novena-kernel-patches $ cd..
~ $ rm -rf linux-4.7.2
~ $ tar -xJf linux-4.7.2.tar.xz
~ $ cd linux-4.7.2
linux-4.7.2 $ ../novena-kernel-patches/apply-patches.sh
( assuming that went OK, then proceed )
linux-4.7.2 $ make novena_defconfig
linux-4.7.2 $ make -j4 zImage modules dtbs
( this will take some time! )
linux-4.7.2 $ sudo make modules_install
( assuming your /boot is mounted, do: )
linux-4.7.2 $ cd /boot
boot $ sudo mv zImage{,.bak}
boot $ sudo mv novena.dtb{,.bak}
boot $ sudo cp "${HOME}/linux-4.7.2/arch/arm/boot/zImage" .
boot $ sudo cp "${HOME}/linux-4.7.2/arch/arm/boot/dts/imx6q-novena.dtb" novena.dtb
boot $ sync

Then reboot!

Please let me know if this update works for you; if so, I will update the gentoo images with the modified kernel in the next day or so.

Thanks again for reporting the issue, and apologies for the inconvenience caused ><

Best, sakaki

Not sure - there have been a number of commits to drivers/of/base.c (where of_graph_get_endpoint_by_regs lives) since 4.7.2, some of which may potentially change the behaviour seen (for example, 34276bb). Best thing is probably to merge the patchset against 4.8.1 (using the newer, single lookup semantics) and see if the issue is already fixed. I'll do that at some point but next up is an 'install-to-sata' utility that supports LVM over LUKS ^-^

Best, sakaki

PS the 4.7.2 Novena patch for  drivers/gpu/drm/imx/imx-ldb.c (0012) will need modification/removal for 4.8.x in any case, since this now supports drm_bridges directly (dc80d70).

I got the hardened, deblobbed 4.7.2 kernel working, thanks sakaki!  The only issue I had was that '/dev/mmcblk0' got renamed to '/dev/mmcblk1', which caused '/etc/fstab' to throw a fit until I "fixed" it by updating the entry.  Not sure what caused the change, though.

Hi, Just posting to report success. 4.7.2 working fine for me on first try.
Thanks for your work on this, Sakaki.

Has anyone gotten the 4.7.2 to work an encrypted root disk? I cannot do that with the current novena_defconfig, and I have a feeling there is an option I am not enabling (I am able to make a uInitrd for with this guide):

https://github.com/umiddelb/armhf/wiki/ … ARM-device

(note to disable CONFIG_DEBUG_INFO=y so the initramfs isn't huge)

and I got past the "cannot initialize device-mapper" error with this guide:

https://unix.stackexchange.com/question … ice-mapper

The latest error is that it could not find AES-XTS-128, but that was loaded as a module. I am recompiling with a suggestion form this post:

https://www.kosagi.com/forums/viewtopic … d=642#p642

I am also using the config from /proc/config.gz right now instead of the novena_defconfig one.

EDIT: I tried both, and got an error of "unknown symbol GLOBAL_OFFSET_TABLE" and still had the error of "Check that kernel supports aes-xts-plain64 cipher". I also tried pulling off the patches to get it working in the 4.4.90 kernel (as 4.4 will be supported until 2022), but I got a blank screen on it. When I have some more time, I will hook up the SPI port and see if I see more, and if I can actually compile xobs linux-novena and get it to boot with the encrypted hard drive.