galliumos-distro
galliumos-distro copied to clipboard
WIP: Refreshing GalliumOS kernel patches onto Linux 5.10 LTS
Issue thread for working on bringing existing GalliumOS patches forward.
I wanted to start by first building GalliumOS as @reynhout described:
$ git clone https://github.com/galliumos/linux;
:
$ cd linux
$ git checkout origin/v4.16.18-galliumos
:
$ touch scripts/package/FORCE
$ make deb-pkg
This has issues on Ubuntu 20.04, http://lkml.iu.edu/hypermail/linux/kernel/1904.2/06680.html:
In file included from scripts/selinux/genheaders/genheaders.c:19:
./security/selinux/include/classmap.h:247:2: error: #error New address family defined, please update secclass_map.
247 | #error New address family defined, please update secclass_map.
| ^~~~~
I think the next step should be to set up a Dockerfile to get the right userland.
This Dockerfile appears to work:
FROM ubuntu:bionic
# # from https://www.kernel.org/doc/html/v4.15/process/changes.html
# GNU C 3.2 gcc –version
# GNU make 3.81 make –version
# binutils 2.20 ld -v
# util-linux 2.10o fdformat –version
# module-init-tools 0.9.10 depmod -V
# e2fsprogs 1.41.4 e2fsck -V
# jfsutils 1.1.3 fsck.jfs -V
# reiserfsprogs 3.6.3 reiserfsck -V
# xfsprogs 2.6.0 xfs_db -V
# squashfs-tools 4.0 mksquashfs -version
# btrfs-progs 0.18 btrfsck
# pcmciautils 004 pccardctl -V
# quota-tools 3.09 quota -V
# PPP 2.4.0 pppd –version
# isdn4k-utils 3.1pre1 isdnctrl 2>&1|grep version
# nfs-utils 1.0.5 showmount –version
# procps 3.2.0 ps –version
# oprofile 0.9 oprofiled –version
# udev 081 udevd –version
# grub 0.93 grub –version || grub-install –version
# mcelog 0.6 mcelog –version
# iptables 1.4.2 iptables -V
# openssl & libcrypto 1.0.0 openssl version
# bc 1.06.95 bc –version
# Sphinx[1] 1.3 sphinx-build –version
WORKDIR /devel/linux
RUN apt update && apt install -y git
RUN git clone https://github.com/galliumos/linux /devel/linux && git checkout origin/v4.16.18-galliumos
RUN apt install -y gcc make libncurses-dev m4 bison \
flex jfsutils libcrypto++6 libcrypto++-dev libfl-dev libopagent1 \
libjvmti-oprofile0 oprofile pcmciautils quota reiserfsprogs \
zlib1g-dev libelf-dev libssl-dev vim bc
RUN apt install -y liblz4-tool dpkg-dev
ADD .config /devel/linux/.config
RUN touch scripts/package/FORCE && make -j `nproc` deb-pkg
The .config
file is attached as config.txt. It was produced by basically holding enter during the config process on the initial make run. config.txt
I've yet to actually test booting the resulting vmlinux.
Be careful if you use the devicemapper
storage backend rather than local; you only get 10GB by default.
OK. I built three resulting .debs (linux-{libc-dev,image-4.16.18+,headers-4.16.18+}) and have installed them on a freshly installed GalliumOS 3.1 auron_paine / C740.
They boot without a hiccup, great. Next is to roll the repo forward.
Edit: attached the dmesg to watch for dmesg regressions (apparently that's how they test pulling the kernel forward in OpenWrt.)
I tried again with v5.4 and everything worked fine, but it's not what I wanted.
Notes:
- I looked a little closer through the GalliumOS repo and found galliumos/bin/apply_patches. I never ran this, so lifting patches from v4.16.18+-galliumos to v5.4 was not useful.
- I noted the presence of galliumos/config and used it when rebuilding v5.4.
Since the work here is slowly evolving I figure I should probably create a git repo containing the build system as Dockerfiles.
Issues applying patches:
-
galliumos/diffs/add-touchpad-touchscreen-support.diff
This one looks like it has been superseded by thechromeos_laptop
driver, according to 7cf432bf058. This patch gets rejected in part, resulting indrivers/input/touchscreen/atmel_mxt_ts.c.rej
.- [ ] TODO: Test C720P without
galliumos/diffs/add-touchpad-touchscreen-support.diff
on v4.16.18-galliumos and on v5.4.
- [ ] TODO: Test C720P without
-
add-aufs-4.16.diff
It's this diff that causes the bulk of the rejections. Is it possible to simply drop aufs? If not, perhaps we should switch this out for https://github.com/pld-linux/kernel/blob/master/kernel-aufs5.patch? Here's the commit for 5.4.14.
That's about it. Nothing else gets rejected.
Correction: 379bc100232acd45b19421bd0748f9f549da8a8a actually prevents galliumos/diffs/avoid-drm-i915-pps-state-mismatch.diff from applying. I followed the commit and re-pointed the patch from drivers/gpu/drm/i915/intel_dp.c
to drivers/gpu/drm/i915/display/intel_dp.c
. Here's are the two hunks that get rejected:
--- drivers/gpu/drm/i915/display/intel_dp.c
+++ drivers/gpu/drm/i915/display/intel_dp.c
@@ -5190,11 +5190,11 @@ intel_pps_readout_hw_state(struct intel_dp *intel_dp, struct edp_power_seq *seq)
PANEL_POWER_DOWN_DELAY_SHIFT;
if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
- seq->t11_t12 = ((pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
- BXT_POWER_CYCLE_DELAY_SHIFT) * 1000;
+ seq->t11_t12 = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
+ BXT_POWER_CYCLE_DELAY_SHIFT;
} else {
- seq->t11_t12 = ((pp_div & PANEL_POWER_CYCLE_DELAY_MASK) >>
- PANEL_POWER_CYCLE_DELAY_SHIFT) * 1000;
+ seq->t11_t12 = (pp_div & PANEL_POWER_CYCLE_DELAY_MASK) >>
+ PANEL_POWER_CYCLE_DELAY_SHIFT;
}
}
@@ -5360,12 +5363,10 @@ intel_dp_init_panel_power_sequencer_registers(struct intel_dp *intel_dp,
if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
- pp_div |= (DIV_ROUND_UP(seq->t11_t12, 1000)
- << BXT_POWER_CYCLE_DELAY_SHIFT);
+ pp_div |= seq->t11_t12 << BXT_POWER_CYCLE_DELAY_SHIFT;
} else {
pp_div = ((100 * div)/2 - 1) << PP_REFERENCE_DIVIDER_SHIFT;
- pp_div |= (DIV_ROUND_UP(seq->t11_t12, 1000)
- << PANEL_POWER_CYCLE_DELAY_SHIFT);
+ pp_div |= seq->t11_t12 << PANEL_POWER_CYCLE_DELAY_SHIFT;
}
/* Haswell doesn't have any port selection bits for the panel
Work continues to be done in the above tree. Instead I am targeting v5.9.8 as this is what @reynhout has dropped into github.com/galliumos/linux. In a few weeks the Linux 5.10 LTS will be out and that should be a short quick step forward from v5.9.8, so it may be worth targeting for GalliumOS 4.0 LTS.
To test the new aufs, I'll need to grab the 3.1 ISO, and use isorespin to unpackage / repackage it -- in between, mounting the squashfs, chrooting into and updating the kernel .debs, and repackaging it.
https://sethc23.github.io/wiki/1_POSTS/2016-03-10-modifying-linux-filesystem-and-live-cd-via-chroot/ is recommended by reynhout
The 5.10.1 LTS has been released. It also looks like the aufs folks have refreshed their patches already:
https://github.com/pld-linux/kernel/blob/master/kernel-aufs5.patch
The build of the refresh of GalliumOS's patches (including that aufs patch) onto 5.10.1 here was successful; remains to be seen whether it boots, though.
Link to .tar of the build: https://paste.c-net.org/ConkedIrishman
Built with: https://github.com/Hurricos/galliumos-builder (pointing at v5.10.1-galliumos as linux
from here).
Sadly I have just sold my very expensive spare RELM motherboards last year, so I cannot debug particularly well.
Did you have any devices not work as expected though?
Thanks for checking, great.
I heard something from Phoronix about HSW GT1 graphics being busted? https://www.phoronix.com/scan.php?page=news_item&px=Intel-Haswell-GT1-Busted
I should check this on a PEPPY or WOLF.
@Hurricos I just followed all the docs I could on Apollo Lake and my Chromebook 15 SAND and ended up here. I started to read on building the kernel but unpacked this instead https://paste.c-net.org/ConkedIrishman and installed the headers, image, and libc.
Upon reboot uname -r returned 5.10+ or something similar. I started to write an update earlier this week on this thread but didn't really have anything new to add. Audio issues and suspend/resume persist. Audio was not working by default, but I did not inspect sinks or sources. I shut the lid to test suspend/resume on this new kernel and the TPM locked the system out and is now begging for recovery.
Are there additional steps to the build besides installing those packages? I'm going to jump back a step and start a build using your helper, and also recover, reinstall, and reboot into 5.10 again.
I think my helper has some commits that need to be pushed to it. Specifically the linux
submodule needs updating, and the Makefile needs some cleanup and better git plumbing commands.
If you find patches that do help with the Apollolake platform validation, please post them in a new issue and ping me to try building them in so I can run some new builds.
I think patches are the only honest way to deal with this, so I'd like to make sure they're as easy as possible to test for the largest crowd possible.
I'm fairly new to linux builds, but learning quick and have a baytrail device available for testing if interested