ROCK Pi X - Custom/tuned Linux kernel

But is it possible to retrieve information from the IC? Could it act like a regular USB-C port in the case that I’m using battery power?

I added USB-C software support just in case, but without any PD protocol support.
FUSE also added.

Debs are republished with same names.

The PD/QC protocol IC doesn’t talk to the processor. It only talks to the power adapter.

Didn’t workout for me with a fresh install of Ubuntu 20.04, error on the last command.

could you advise on the removal command.

dpkg --remove …?

Thank you.
Looking forward to it being compatible.

Updated to Linux 5.8.17.

Patches rebased against new kernel:

1 Like

Are you gonna be updating the patches for 5.9?

No. It’s too much work to rebase for every series, and nothing about 5.9 is particularly earth-shattering for the Rock Pi X’s components/Silvermont.

ZSTD compression?

can this kernel support GPIOs and SPI port? where is the .config file?

.config is in the deb, just run ar -x blahblah.deb and then tar -xf data.tar.xz.

Try it, I enabled everything that made sense for this board.

cat boot/config-5.8.17 | grep 'GPIO\|SPI' | grep -v '^#'
1 Like

So perhaps maybe for 5.10?

Also it seems you didn’t update the patches, as I keep getting failed builds during the patch phase…

The patches in my build tree match what are posted. It must be a problem with your build process as these apply cleanly to the 5.8.17 sources.

build-host $ md5sum *.patch
3b507ca4337a078e01542143de2ddae8  brcmfmac-5.8.patch
de39747f4146bdec5ff461784c79cd58  lto-5.8.patch
2ec0ded441d2ed15357e8bbd36af25b8  mtune-silvermont.patch
me@test:~/sandbox/linux-5.8.17$ patch -Np1 -i ~/Downloads/brcmfmac-5.8.patch 
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/fwsignal.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.h
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
patching file drivers/net/wireless/broadcom/brcm80211/brcmfmac/fweh.c
me@test:~/sandbox/linux-5.8.17$ patch -Np1 -i ~/Downloads/lto-5.8.patch 
patching file Documentation/kbuild/lto-build.rst
patching file Makefile
Hunk #3 succeeded at 949 (offset -4 lines).
Hunk #4 succeeded at 1130 (offset -4 lines).
Hunk #5 succeeded at 1772 (offset -4 lines).
patching file arch/x86/Kconfig
patching file arch/x86/kernel/alternative.c
patching file arch/x86/purgatory/Makefile
patching file arch/x86/realmode/Makefile
patching file drivers/firmware/efi/libstub/Makefile
Hunk #1 succeeded at 56 (offset -1 lines).
Hunk #2 succeeded at 123 (offset -1 lines).
patching file drivers/gpu/drm/amd/amdkfd/kfd_iommu.c
patching file drivers/media/platform/sti/delta/delta-ipc.c
patching file drivers/misc/lkdtm/Makefile
patching file drivers/xen/time.c
patching file include/asm-generic/export.h
patching file include/asm-generic/
Hunk #1 succeeded at 439 (offset 2 lines).
patching file include/linux/compiler_attributes.h
patching file include/linux/export.h
patching file include/linux/init.h
patching file include/linux/linkage.h
patching file init/Kconfig
patching file kernel/Makefile
patching file kernel/bpf/core.c
patching file kernel/locking/spinlock.c
patching file scripts/Makefile
patching file scripts/
patching file scripts/Makefile.crc
patching file scripts/Makefile.lib
patching file scripts/Makefile.lto
patching file scripts/Makefile.modfinal
patching file scripts/elf_file_offset
patching file scripts/gcc-ld
patching file scripts/genksyms/genksyms.c
patching file scripts/genksyms/genksyms.h
patching file scripts/genksyms/parse.y
patching file scripts/kallsyms.c
Hunk #4 succeeded at 145 with fuzz 2 (offset 10 lines).
Hunk #5 succeeded at 173 (offset 14 lines).
Hunk #6 succeeded at 188 (offset 14 lines).
Hunk #7 succeeded at 411 (offset 14 lines).
Hunk #8 succeeded at 434 (offset 14 lines).
Hunk #9 succeeded at 478 (offset 14 lines).
Hunk #10 succeeded at 528 (offset 14 lines).
Hunk #11 succeeded at 565 (offset 14 lines).
Hunk #12 succeeded at 846 (offset 14 lines).
Hunk #13 succeeded at 859 (offset 14 lines).
Hunk #14 succeeded at 889 (offset 14 lines).
patching file scripts/
patching file scripts/mod/modpost.c
Hunk #1 succeeded at 1988 (offset 9 lines).
Hunk #2 succeeded at 2014 (offset 9 lines).
Hunk #3 succeeded at 2031 (offset 9 lines).
Hunk #4 succeeded at 2076 (offset 9 lines).
Hunk #5 succeeded at 2114 (offset 9 lines).
patching file scripts/patchfile.c

Found some cycles this weekend, decided to rebase everything onto 5.9(.8) this weekend and got it booted… doing some testing prior to releasing.

Andi Kleen may have stopped supporting the FLTO patches (as Clang LTO is supported instead for 5.10rc presumably?) and I don’t know how long I can keep them going as it’s very detailed kernel work.

There was a tricky little optimization that broke the LTO builds hopping from 5.8 to 5.9 that I had to figure out that would have ordinarily been a part of those patches.

1 Like

Kernel 5.9.8 binary and patches posted.

New patch set lto-tjs.patch is my patches on top of Andi Kleen’s LTO patches. It was needed because they now do pointer comparison for some optimization, and the LTO was reordering the functions during the link step that broke the pointer comparison optimization.

Big sigh of relief - managed to front-port the patches to 5.10(-rc4) tonight, which turned out to be even harder than 5.9. 5.10 is designated to be an LTS kernel, so even if future version become too hard to continue to support for GCC LTO, we can ride the LTS wave out on the Rock Pi X for awhile!

Same thing, will test some and wait for 5.10 release before publishing binaries.

Fantastic! Thanks a lot!

Maybe put your patches in a Github repo?

Thanks @tjcs90 for your efforts! Does the kernel you built contain lvm / device mapper modules?

I tried to boot my fresh Debian 10 installation with it, but it failed to an “Incompatible libdevmapper 1.02.155” error, which might be because I installed my system on top of LVM.

If that’s the case would you mind including LVM / device mapper (dm) support in your next build?

@tjcs90 would you be willing to share the kernel .config you used?

Any chance you’ll make an upgrade to 5.12?