So earlier I had done a custom installation of NetBSD selecting different sets and installing them from installation media and importing rest from NetBSD’s CDN via http. The sets for reference were kernel(generic), discarding kernel(generic_kaslr) which is the same generic kernel with kernel address space randomization enabled, loadable kernel modules(.kmod files), base(mandatory and required ofc), base 32-bit compatibility(I disabled this because I’m not going to working with 32 bit binaries and legacy software but good to have for daily drivers),config files(/etc), compiler tools(Needed for developemt), Games(old BSD TUI games, not required ), Man pages(troff formatted, gold source of info), Man pages HTML (pre-rendered as HTML instead of troff ), graphics driver firmware(I disabled this, because initially my work is solely TUI based and getting NVME and other peripherals work and getting non-llvmpipe display is my last concern for now), misc(no idea honestly, probably some extra locales, good to have ), recovery tools(Enabled, better than runnnig the installation media again), test programs(enabled, as mostly required for my VMD work), text processing tools(must for troff based man pages), x11 sets(disabled), source and debug sets(installs /usr/src, anyways needed for devel work, better to have now than installing later from github mirror, for debugging we get tools like gdb for a panic kernel). Further I enabled sshd(because using with -nographic means dealing with vt100 or vt220 terminal, they are fine for physical hardware but the buffering isn’t great when virtualising, even setting stty rows and cols, rendering is unpredictable. It sometimes fills screen, sometimes display only in half, so ssh is useful for visual satisfaction pov), enabling ntpd, The ntpd utility is an operating system daemon which sets and maintains the system time of day in synchronism with Internet standard time servers. Then ntpdate, ntpdate sets the local date and time by polling the Network Time Protocol (NTP) server(s) given as the server arguments to determine the correct time. It must be run as root on the local host, better to leave it disabled, leans more towards legacy outdated tech and not much relevant to kernel work. Other options like multicast dns and cgd(similar to Linux’s LUKS encryption), LVM and raidframe disabled because I don’t require redundancy and disk flexibility on qemu virtual disks. Also the reasoning behind, the irregular display with -nographic is ,there is no monitor hence no pixel resolution, no window for qemu to manage, qemu’s serial output just gets piped to whatever terminal application I launched with boot_normal.sh, in my case ghostty. So the screen filling half/full is a rendering issue of the terminal emulator’s own window behaving inconsistently, window manager auto sizing, terminal app remembering a stale size, etc. Its nothing on qemu for fixing it. So a real serial console has no way to report the guest OS, what size is my terminal emulator. So setting stty sizes will also not help, but in case of ssh, it negotiates window size(TIOCWINSZ) and sends SIGWINCH automatically on resize, thus with -nographic the serial console just uses the default which most likely is 80x24.
Also while booting via serial console with -nographic simply choosing normal boot via 1, will boot the system but lack serial port because it expects a VGA display there. So boot using option 3, and use the boot parameters
consdev com0
boot
Upstream source for all QEMU flags are listed here:
https://wiki.qemu.org/Features/
Now comes the entropy part, as soon as I boot into the system I’m greeted with
Welcome to NetBSD!
-- UNSAFE KEYS WARNING:
The ssh host keys on this machine have been generated with
not enough entropy configured, so they may be predictable.
To fix, follow the "Adding entropy" section in the entropy(7)
man page. After this machine has enough entropy, re-generate
the ssh host keys by running:
/etc/rc.d/sshd keyregen
Honestly in the installation phase itself NetBSD will complain lack of entropy and advise either to generate it or fetch it via network, for a VM its fine but still a secure practise to follow on a development environment. Entropy is random unpredictable secrets needed for security,
man entropy # hardware random number generators based on thermal noise in silicon circuits
# others may require operator intervention for security.
Features/VirtIORNG, QEMU Wiki, https://wiki.qemu.org/Features/VirtIORNG # from NetBSD man page
In our case we don’t do a passthrough, that leaves the host vulnerable for the time being the guest is active, so we simply use -device virtio-rng-pci. From qemu’s wiki -device virtio-rng-pci to the QEMU invocation will add the device with a default host backend. As of QEMU 1.3, the default backend is to use the host’s /dev/random as a source of entropy. To modify this source to a real hardware RNG on the host, use:
-object rng-random,filename=/dev/hwrng,id=rng0 \
-device virtio-rng-pci,rng=rng0
# optional parameter to limit the rate of data sent to the guest
-device virtio-rng-pci,max-bytes=1024,period=1000
As its a guest mostly running on userspace, I prefer passing /dev/urandom instead of /dev/hwrng. /dev/urandom is a fast software-based cryptographic pseudorandom generator meant for general applications, while /dev/hwrng provides raw, direct access to a physical hardware random number generator At the end /dev/hwrng writes to /dev/random, if you trust hardware better use /dev/hwrng. Modifying the boot_normal.sh, requires a device shutdown and poweron for the guest, a mere reboot doesn’t seem to work. In NetBSD to shutdown use
halt -p # As root or use doas
To see if changes are taking place inside the NetBSD guest,
netbsd_devel$ doas rndctl -l
Source Estimated bits Samples Type Flags
/dev/random 0 0 ??? collect, v
cd0 0 0 disk collect, v, t
wd0 0 6701 disk collect, v, t
fd0 0 0 disk collect, v, t
hardclock 0 19029 skew collect, t
pms0 0 0 tty collect, v, t
pckbd0 0 0 tty collect, v, t
system-power 0 0 power collect, v, t
autoconf 0 152 ??? collect, t
seed 0 1 ??? collect, v
uvmfault 0 502 vm collect, v, t
# no viornd0 listed, so changes haven't taken place requires halt.
Additionally we may check what flags QEMU launched with using
[~]> pgrep -fa qemu-system-x86_64
1227820 qemu-system-x86_64 -m 4G -smp 4 -drive file=netbsd.img,format=qcow2 -boot c -enable-kvm -virtfs local,path=/home/honken/virtual-machines/NetBSD,mount_tag=hostshare,security_model=none -netdev user,id=network-vm,hostfwd=tcp::2222-:22 -device virtio-net-pci,netdev=network-vm -bios /usr/share/edk2/OvmfX64/OVMF_CODE.fd -object rng-random,filename=/dev/urandom,id=viornd0 -nographic
To confirm the device is visible at the PCI level inside NetBSD we use pcictl and dmesg remains a traditional source.
netbsd_devel$ pcictl pci0 list
000:00:0: Intel 82441FX (PMC) PCI and Memory Controller (host bridge, revision 0x02)
000:01:0: Intel 82371SB (PIIX3) PCI-ISA Bridge (ISA bridge)
000:01:1: Intel 82371SB (PIIX3) IDE Interface (IDE mass storage, interface 0x80)
000:01:3: Intel 82371AB (PIIX4) Power Management Controller (miscellaneous bridge, revision 0x03)
000:02:0: vendor 1234 product 1111 (VGA display, revision 0x02)
000:03:0: Qumranet Virtio 9p Filesystem (prehistoric, subclass 0x02)
000:04:0: Qumranet Virtio Network (ethernet network)
000:05:0: Qumranet Virtio RNG Entropy (prehistoric, subclass 0xff)
netbsd_devel$ doas rndctl -l
Source Estimated bits Samples Type Flags
/dev/random 0 0 ??? collect, v
cd0 0 0 disk collect, v, t
wd0 0 6318 disk collect, v, t
fd0 0 0 disk collect, v, t
hardclock 0 499 skew collect, t
viornd0 512 2 rng estimate, collect, v
pms0 0 0 tty collect, v, t
pckbd0 0 0 tty collect, v, t
system-power 0 0 power collect, v, t
autoconf 0 156 ??? collect, t
seed 0 1 ??? collect, v
uvmfault 0 434 vm collect, v, t
# clearly now viornd0 is present after a fresh boot.
More info using dmesg, if still not present we can check for viornd driver support in kernel, if not fetch using pkgin and use modload to load a module.
dmesg | grep -i -E "virtio|viornd|rnd"
modstat | grep -i virtio
modload viornd
Then after entropy is generated, we regenerate ssh keys and clear stale host keys, then connect via ssh.
/etc/rc.d/sshd keyregen
ssh-keygen -R "[localhost]:2222" # this is the port I opened for the guest, passed via qemu flag
ssh -p 2222 pratyush@localhost # guest user@localhost
Since I can’t always rely on networking to fetch files via some remote repository, I need hostshare for quick access to large files from host to guest. So I attach the VM directory for hostshare, and this acts as an attached disk that can be accessed from /mnt. Earlier in my boot_normal.sh, I had used the QEMU flag
-virtfs local,path=/home/honken/virtual-machines/NetBSD,mount_tag=hostshare,security_model=none \
But the above flag has simply no effect, /mnt has nothing attached to it, because that flag isn’t configured properly, it needs the protocol to be specified. Implemeting of a hostshare via virtfs is a mechanism but OS have different policy to reach that result.
[~]> pgrep -fa qemu-system-x86_64 | grep -o "mount_tag=[a-zA-Z0-9]*"
mount_tag=hostshare
(pratyush)::[~] >> mount_9p hostshare /mnt
mount_9p: No address associated with hostname
(pratyush)::[~] >> doas mount_9p hostshare /mnt
mount_9p: No address associated with hostname
(pratyush)::[~] >> modstat | grep -i puffs
puffs vfs builtin - 0 - putter
(pratyush)::[~] >> modstat | grep -i 9p
vio9p driver builtin - 0 - virtio
(pratyush)::[~] >> doas modload puffs
modload: puffs: File exists
(pratyush)::[~] >> ls /mnt
We can check if the device is attached to PCI/drier level
pcictl pci0 list | grep -i 9p
dmesg | grep -i vio9p
From qemu docs:
https://www.qemu.org/docs/master/system/qemu-manpage.html
Virtfs defines a new virtual filesystem device and expose it to the guest using a virtio-9p-device (a.k.a. 9pfs), which essentially means that a certain directory on host is made directly accessible by guest as a pass-through file system by using the 9P network protocol for communication between host and guests, if desired even accessible, shared by several guests simultaneously. virtfs is actually just a convenience shortcut for its generalized form -fsdev -device virtio-9p-pci. “security_model=security_model” specifies the security model to be used for this export path. Supported security models are “passthrough”, “mapped-xattr”, “mapped-file” and “none”. In “passthrough” security model, files are stored using the same credentials as they are created on the guest. This requires QEMU to run as root. In “mapped-xattr” security model, some of the file attributes like uid, gid, mode bits and link target are stored as file attributes. For “mapped-file” these attributes are stored in the hidden .virtfs_metadata directory. Directories exported by this security model cannot interact with other unix tools. “none” security model is same as passthrough except the sever won’t report failures if it fails to set file attributes like ownership. Security model is mandatory only for local fsdriver. Also by default the hostshare is read-write, but can be set to readonly=on.
More info on the 9plan file sharing protocol:
man mount_9p
man vio9p
https://ericvh.github.io/9p-rfc/
https://doc.cat-v.org/plan_9/4th_edition/papers/names # use of namespaces, plan9s central idea uniform namespaces, everything is a file by Rob Pike et al
https://docs.kernel.org/filesystems/9p.html
https://github.com/chaos/diod/blob/master/protocol.md # The 9P2000.L protocol spec itself, maintained in the v9fs project
https://github.com/NetBSD/src/tree/trunk/sys/fs/puffs # client code under /sys/dev/pci
https://www.qemu.org/docs/master/system/qemu-manpage.html # central doc, search for virtfs or fsdev
so apply changes to qemu flags in boot_normal.sh
```bash
-fsdev local,security_model=none,id=fsdev0,path=/home/honken/virtual-machines/NetBSD \
-device virtio-9p-pci,fsdev=fsdev0,mount_tag=hostshare
Then in the NetBSD guest
doas mount_9p -c -u /dev/vio9p0 /mnt
(pratyush)::[~] >> ls /mnt
NetBSD-10.1-amd64.iso boot_install.sh netbsd-internals-en.pdf.gz pkgsrc.pdf
NetBSD-11.0-amd64.iso boot_normal.sh netbsd.img
NetBSD-11.0_RC2-amd64-dvd.iso netbsd-en.pdf notes.txt
If dmesg shows vio9p0 is connected, but the device is still not present, then we must check if device node exists. If its missing then we create it using MAKEDEV, because some virtio device nodes aren’t created and requires manual intervention via MAKEDEV.
ls -la /dev/vio9p*
cd /dev
doas ./MAKEDEV vio9p
The above process is highly unlikely, the virtfs mounting works only by plan9 file transfer protocol because of uniform namespaces. This makes the VM ready for the NetBSD specific study.
As I had pkgin enabled while installing by installer, I will be installing git bash nvim, one crucial detail is pkgin fetches precompiled tarballs for the specific architecture from ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/$arch/$branch/All. These tarballs are built for a snapshot of pkgsrc, so a lot of time pkgin throws error because of dependency mismatch. In that case pkgsrc is the only option, and packages need to be compiled. so for example installing links
cd /usr/pkgsrc/www/links
doas make install
# In case to search for a particular application just use
(pratyush)::[/usr/pkgsrc] >> find ./*/wgetpaste
./net/wgetpaste
./net/wgetpaste/CVS
./net/wgetpaste/CVS/Root
./net/wgetpaste/CVS/Repository
./net/wgetpaste/CVS/Entries
./net/wgetpaste/CVS/Tag
./net/wgetpaste/Makefile
./net/wgetpaste/DESCR
./net/wgetpaste/distinfo
./net/wgetpaste/PLIST
./net/wgetpaste/files
./net/wgetpaste/files/CVS
./net/wgetpaste/files/CVS/Root
./net/wgetpaste/files/CVS/Repository
./net/wgetpaste/files/CVS/Entries
./net/wgetpaste/files/CVS/Tag
./net/wgetpaste/files/wgetpaste.conf
./net/wgetpaste/patches
./net/wgetpaste/patches/CVS
./net/wgetpaste/patches/CVS/Root
./net/wgetpaste/patches/CVS/Repository
./net/wgetpaste/patches/CVS/Entries
./net/wgetpaste/patches/CVS/Tag
./net/wgetpaste/patches/patch-wgetpaste
(pratyush)::[/usr/pkgsrc] >> cd net/wgetpaste/
(pratyush)::[/usr/pkgsrc/net/wgetpaste] >> ls
CVS DESCR Makefile PLIST distinfo files patches
pkgsrc is NetBSD package collection,it is a framework for building and maintaining 3rd party software on NetBSD and other UNIX like systems, pkgsrc also works on DragonflyBSD, used to work on MINIX, SmartOS (an Illumos distribution). These have like 1st class support(informally based on use cases, though no such tiering from pkgsrc its highly portable). The notable difference to linux is XDG naming, there are no ~/.config files created by default, these are freedesktop specific conventions, applications don’t require it mandatorily, if it exists it reads it. Same goes with /etc, there is a clean seperation of base system and user installed packages, base packages configs reside in /etc, whereas for 3rd party applications in /usr/pkg/etc, thus the base system remains clean across major releases. As pkgsrc primarily uses bmake to compile and then pkg_add to install and pkg_delete to remove generated binaries, there needs a centralised config file to control compile time options, like gentoo’s /etc/portage/make.conf. In case of NetBSD its /etc/mk.conf. It follows the same pattern, a file doesn’t exist unless its defaults needs to be overridden. All the compile time options are listed in the mk.conf manpage, and the real defaults reside in /usr/pkgsrc/mk/defaults/mk.conf
Now since I will try to port ytm (https://ytm-player.com/), on NetBSD, I need to setup the audio stack.
-audiodev pa,id=snd0 \
-device intel-hda \
-device hda-output,audiodev=snd0
But my host Gentoo system is configured to use pipewire as a sound server than pulseaudio, this still works because pipewire has a running socket for maintaining pulseaudio compatibility.
└[~]> pactl info
Server String: /run/user/1000/pulse/native
Library Protocol Version: 35
Server Protocol Version: 35
Is Local: yes
Client Index: 404
Tile Size: 65472
User Name: honken
Host Name: Pratyush-PC
Server Name: PulseAudio (on PipeWire 1.6.7)
Server Version: 15.0.0
Default Sample Specification: float32le 2ch 48000Hz
Default Channel Map: front-left,front-right
Default Sink: alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Speaker__sink
Default Source: alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__Mic1__source
Cookie: 0559:bffe
Now we activate sound interface up in NetBSD
audioctl -a
If my host was OpenBSD then I would have had to use -audiodev sndio, because sndio is OpenBSD’s audio driver. In Linux we have ALSA(Advanced Linux Sound Architecture),along with libasound, a userspace library that exposes the framwork to programs.Now pulseaudio is a sound server on top of it, it mixes the sound, routes to different outputs, per app streams. Pipewire is newer sound server, written from scratch, it has broader scope, implements both pulseaudio and JACK’s(pro audio low latency server) functionality.Unifies audio and video/screen capturing routing, opens pulseaudio compat socket and hence pactl info works.
The approach of *BSD to sound server, NetBSD is the 1st to implement the existing 386BSD stack, and in 1999 release notes of 1.4, bring the “audio” stack. Then OpenBSD is born out of forking NetBSD and implements improvenments over audio, and later created something new entirely called “sndio”.
man audio
FreeBSD’s approach was very different, its sound and pcm driver was influenced and compatible with 4FrontTechnologies OSS(Open Sound System) API.Unlike Linux userspace servers, FreeBSD does the mixing in the kernel level itself via virtual channels, that requires more exclusive handling request. Illumos audio architecture is SADA(Sun Audio Device Architecture),its mostly device driver along with local API oriented. **Case study to read: closest thing to “network transparent audio” in Unix history generally was NAS (Network Audio System, from NCSA, later Network Computing Devices) — a genuinely X11-inspired audio equivalent, but it was cross-platform third-party software, never Solaris’s own native stack, and never gained the ecosystem traction X11 did — most systems (including Solaris) just didn’t prioritize networked audio the way display was prioritized.
Further we can list available audio drivers
└[~]> qemu-system-x86_64 -audiodev help
Available audio drivers:
none
alsa
dbus
oss
pa
pipewire
sdl
wav
For audio peripheral emulation we can list options
[~]> qemu-system-x86_64 -device help | grep -i hda
name "hda-duplex", bus HDA, desc "HDA Audio Codec, duplex (line-out, line-in)"
name "hda-micro", bus HDA, desc "HDA Audio Codec, duplex (speaker, microphone)"
name "hda-output", bus HDA, desc "HDA Audio Codec, output-only (line-out)"
name "ich9-intel-hda", bus PCI, desc "Intel HD Audio Controller (ich9)"
name "intel-hda", bus PCI, desc "Intel HD Audio Controller (ich6)"
As there is audio handling via pipewire I prefer that:
-audiodev pipewire,id=snd0 \
-device intel-hda \
-device hda-output,audiodev=snd0
# worth noting available options are hda-output(strictly output), hda-duplex(receives input + gives output) and hda-micro(more for microphone and output).
Since this blog has already streched long, I would end it here, with next blog expalaining creation of a pkg and installation, then optimisations using LLVM/Clang, and methods to override the default gcc compiler.
]]>So qemu stands for quick emulation, its for most part a software level emulator, that can emulate different architecture via TCG (Tiny Code Generator) emulation,more info here:
https://www.qemu.org/docs/master/devel/index-tcg.html
So from upstream docs, whenever qemu encounters a code block of a particular ISA, it converts it to native ISA code block using a dynamic translator, and QEMU’s dynamic translator backend is TCG. QEMU is foremost a userspace process that emulates disk controllers, network cards, GPU, USB, BIOS/UEFI, and can use KVM to implement the processor natively. KVM is a linux driver, the kernel needs to be compiled with this module but this module is only useful if the hardware supports it. At hardware level it needs extensions like Intel VT-x or AMD-V. So this turns the Linux kernel into a type-1 hypervisor. Type-1 also called bare metal hypervisor, gives almost native level performance like Xen hypervisor, type-2 is mostly software level emulation and then there is type-3, that is more of a hybrid like KVM/QEMU, that can perform both of the above, QEMU is simply a type-2 but combining with KVM turns it closer to type-1. KVM is the cpu acceleration backend, without it qemu just simply fallbacks to TCG based emulation. KVM is very much Linux specific, though it has been ported earlier to Illumos, which then moved to FreeBSD based bhyve hypervisor. NetBSD uses NVMM (NetBSD Virtual Machine Monitor) its own native hypervisor. QEMU has native support for it, like for Linux host we pass -enable-kvm, we use -accel-nvmm. In both cases we need a simple check at /dev. For linux /dev/kvm needs to exist if not load the module, for NetBSD /dev/nvmm needs to be present.
Basically hypervisor is a software that creates and manages vm’s by controlling cpu/memory/device access on their behalf(guest os).Type 0 runs on a privileged layer, basically ring 0 in terms of Intel’s hardware. Rings are basically like modes, but modern hardware has multiple modes other than just the krnel and user mode. So existence of kvm module on Linux makes the whole OS along with QEMU act like a type 1. Xen is a different case.
https://wiki.xenproject.org/wiki/Main_Page
With kVM/QEMU , Linux host acted as a VMM/hypervisor, it had the control of starting/stopping the hypervisor. In case on Xen, it calls the guest OS running on it as “domains”. A special OS is tagged dom0, that can control the hypervisor and start/stop other guest OS’s. From the Xen wiki, the hypervisor supports two primary types of virtualization: paravirtualization (PV) and hardware virtualized machine (HVM) also known as “full virtualization”. Paravirtualization uses modified guest operating systems that we refer to as “enlightened” guests. These operating systems are aware that they are being virtualized and as such don’t require virtual hardware devices. Instead they make special calls to the hypervisor that allow them to access CPUs, storage and network resources. In contrast, HVM guests need not be modified, as the hypervisor will create a fully virtual set of hardware devices for the machine resembling a physical x86 computer. This emulation requires more overhead than the paravirtualization approach but allows unmodified guest operating systems like Microsoft Windows to run on top of the hypervisor. HVMs are supported through virtualization extensions in the CPU. Several iterations of these extensions have been introduced in the last decade or so, collectively known as Intel VT and AMD-V and development continues. The technology is now prevalent; all recent servers, many desktops and some mobile systems should be equipped with at least some extensions. Xen virtualization is now seen as on a spectrum, with PV at one end and HVM at the other. In between are various enhancements to improve performance: HVM with PV drivers, PVHVM or “Paravirtualization on HVM”, and most recently PVH. Since KVM is bolted at the Linux kernel itself, Xen doesn’t work like that, it has its own minimal microkernel like layer that boots before any OS,then it starts a privileged domain dom0, which starts other VM’s. To check if the existing kernel has Xen support:
zgrep XEN /proc/config.gz
In my case, output looks like this and the kernel supports it.
└[~]> zgrep XEN /proc/config.gz
CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_512GB=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_PV_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_PVHVM_GUEST=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_XEN_PVH=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PV_MSR_SAFE=y
CONFIG_PCI_XEN=y
CONFIG_KVM_XEN=y
CONFIG_NET_9P_XEN=m
CONFIG_XEN_PCIDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_FRONTEND=m
CONFIG_XEN_BLKDEV_BACKEND=m
CONFIG_XEN_SCSI_FRONTEND=m
CONFIG_NETXEN_NIC=m
CONFIG_XEN_NETDEV_FRONTEND=m
CONFIG_XEN_NETDEV_BACKEND=m
CONFIG_INPUT_XEN_KBDDEV_FRONTEND=m
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_TCG_XEN is not set
CONFIG_XEN_WDT=m
# CONFIG_DRM_XEN_FRONTEND is not set
CONFIG_XEN_FBDEV_FRONTEND=y
CONFIG_SND_XEN_FRONTEND=m
CONFIG_USB_XEN_HCD=m
CONFIG_MMC_SDHCI_XENON=m
CONFIG_XEN_BALLOON=y
CONFIG_XEN_BALLOON_MEMORY_HOTPLUG=y
CONFIG_XEN_MEMORY_HOTPLUG_LIMIT=512
CONFIG_XEN_SCRUB_PAGES_DEFAULT=y
CONFIG_XEN_DEV_EVTCHN=m
CONFIG_XEN_BACKEND=y
CONFIG_XENFS=m
CONFIG_XEN_COMPAT_XENFS=y
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
CONFIG_XEN_GNTDEV=m
CONFIG_XEN_GRANT_DEV_ALLOC=m
# CONFIG_XEN_GRANT_DMA_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_PCI_STUB=y
CONFIG_XEN_PCIDEV_BACKEND=m
# CONFIG_XEN_PVCALLS_FRONTEND is not set
# CONFIG_XEN_PVCALLS_BACKEND is not set
CONFIG_XEN_SCSI_BACKEND=m
CONFIG_XEN_PRIVCMD=m
CONFIG_XEN_PRIVCMD_EVENTFD=y
CONFIG_XEN_ACPI_PROCESSOR=m
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_SYMS=y
CONFIG_XEN_HAVE_VPMU=y
CONFIG_XEN_FRONT_PGDIR_SHBUF=m
CONFIG_XEN_UNPOPULATED_ALLOC=y
CONFIG_XEN_GRANT_DMA_OPS=y
CONFIG_XEN_VIRTIO=y
# CONFIG_XEN_VIRTIO_FORCE_GRANT is not set
# clearly CONFIG_XEN_DOM0=y, CONFIG_XEN_PV=y, CONFIG_XEN_PVHVM=y is set, hence the kernel has builtin support.
Mechanisms that enable guest and host communication -:
MMIO/PIO - memory mapped I/O or port I/O, it is the old/boomer solution, the guest thinks its talking to real hardware registers, when it reads/writes those addresses,the CPU traps out of guest mode (via KVM), returns control to QEMU, then QEMU’s device emulation code interprets what the guest wanted and updates emulated device state. This is the mechanism behind the e1000 Network Interface Controller, ide disk controller works. Qemu pretends to be real hardware down to register level.
Virtio - This is the modern alternative, like virtio-net-pci, virtio-gpu-pci, virtio-rng. Instead of pretending to be real hardware, virtio is a paravirtualized interface, th guest OS clearly knows its talking to a virtualised environment and uses a purpose built protocol: shared memory ring buffers(virtqueues) that both guest and QEMU can read/write to.Also there exists a lightweight notification mechanism called ioeventfd/irqfd, kernel level avoids trapping to qemu userspace for notifcation itself.This method has far less overhead than MMIO/PIO, which emulates hardware at register level.So only thing is NetBSD needs virtio guest drivers like viornd, vioif, etc.
Modern systems invlove heavy usage and presence of GPU’s. We need is virgl/virglrenderer, its layered on top of virtio-gpu. The guest’s Mesa driver will serialize the OpenGL/Gallium commands to a command buffer, write it to the virtqueue like other virtio traffic. Now the host will read the command buffer and display it as a real OpenGL/Vulkan calls against the host’s GPU driver. In my case it is IRISxe. virglrenderer, is a library that qemu links itself to is what reads the command buffer. So, the communication channel is virtio(shared memory + virtqueue), and virglrenderer is the translator sitting on the host end. Parameters like -display gtk,gl=on is important, as the display backend will need its own GL context to composite the result. gl=on, tells QEMU’s GTK frontend to set that up.
The similar mechanism is followed for sound, virtio-sound is the interface, its newer compared to others and has lesser universal support, truth being QEMU still mostly relies on semi-emulated devices like intel-hda (emulating a real Intel HDA controller), paired with a host audio backend like -audiodev-pa for pulseaudio, others like alsa,sdl also exists. The guest HDA driver follows the MMIO path. Then QEMU translates it to calls against the host’s audio system. Another aspect is existence of a shared folder. It uses different protocol, the Plan 9’s filesystem protocol, carried over virtio (virtio-9p) as the transport. Guest mounts it as a real filesystem (mount_9p), the only difference here is every file operation (read/write/open/stat) is serialized as a 9p protocol message, gets sent to virtqueue, and qemu translates it into a real syscall against the host directory listed by the -virtfs parameter.
So the pattern we follow is if any virtio* variant exists, we use it or else we go to MMIO mechanism. Other parameters that we might use, is virtio-blk-pci instead of default IDE style -drive interface. Useful for faster disk I/O for heavy build workloads. We need is vioblk driver support for the host, in my case NetBSD. Next in the line is actual core counts and threads, we have to use -smp cores=4,threads=1 style topology control. We will need this while creating our own pkgsrc builds. For even heavier usage we might need -object memeory-backend-memfd + hugepages.
The core part, is how exactly is the host going to emulate a hardware it doesn’t even support. NetBSD doesn’t have any support for raptor lake series and IRISxe integrated graphics card. For the most part processors and GPU’s are never written from scratch nowadays, they follow a template that reamins fairly common across generations, the only factors that change is introduction of newer parameters/options availability. Something else that might change is how the template is being handled at the backend. Say for GPU’s, modern Intel GPU’s like IRISxe and ARC, use gallium drivers, it is a core part of MESA library’s 3D project, fairly newer ones like IRISxe handles these gallium calls via OpenGL. The gallium3D architecture was introduced in 2008 by Tungsten graphics to modernize MESA 3D project, so its like a protocol. Older Intel GPUs relied on i965 driver, so the community ported the older drivers to gallium via crocus project, because those drivers were hard to maintain.So from Intel’s Gen8 (Broadwell) to current IRISxe these use iris drivers based on gallium3D project. Now vulkan is a different case,it uses the Intel’s ANV driver. Gallium was developed to trace older API’s of OpenGL, but vulkan is low level, where engines need to manage their own memeory and scheduling. Vulkan drivers bypass the Gallium drivers to talk to the hardware directly.
Similarly this remains true across processors. All these generations are based on X86_64 ISA. Thus instruction set across them have to be the same, so they execute the same byte codes. What differs is the extended instruction set support, like AVX2, AVX-512, SIMD extensions. So say a binary compiled with AVX-512 will crash on older generation (SIGILL) which doesn’t have any such support. That differetiates compiler flags like -march=native and -march=x86-64-v2, the latter targetting feature level and former targeting a specific chip. Another difference is microarchitecture and CPUID. The internal implementations like pipeline depth, cache sizes, branch predictor design, core/thread topology, these execute at different speeds, so performance and efficiency varies. CPUID is the mechanism by which any software (OS, hypervisor and even userspace) queries what instructions a CPU has, something like a compiler or JIT calls CPUID to discover what is it running on, to choose the execution path. Thats the sole reason a flag like -cpu host in qemu script is important.
So how is NetBSD able to boot as a VM but fails to boot from a live environment or I should rather say boot image, as NetBSD doesn’t really have a traditional linux like live environment,though users can use console by exiting the installer. The fact being its well known to me the NetBSD media, fails to recognize my NVME disk, so clearly on bleeding edge hardware CPU never fails but its the peripherals, NetBSD’s tree just doesn’t have any drivers for these peripherals, any these prripherals can be anything from NVME disk controller, to wifi chipset, USB4/thunderbolt controller, exact ACPI quirk table, exact PCIe root table,also secure boot interactions. NetBSD’s media just is unable to parse ACPI on the table my device firmware emits, even possibility is install ,edia can’t get display output through the specific GPU’s boot time framebuffer path because of KMS/UEFI GOP mismatch. Its just the kernel can’t talk to the actual hardware its trying to boot on. So by virtualization, the hypervizor like KVM/QEMU or Xen never expose these peripherals, unless we detect some peripherals are supported i.e the drivers exist in the tree/kernel, so we decide to do a PCI passthrough. They try to pass a decade old stable virtual chipset like QEMU’s q35/i440fx, emulated ICH9/PIIX4 AHCI disk controller (or virtio-blk), emulated e1000 NIC (or virtio-net), a standard VGA or virtio-gpu framebuffer for boot output. Same goes with Xen, Xen HVM guests use qemu too, it just runs as qemu-dm inside dom0, providing the exact virtio* interfaces. Its a policy that Xen choose because maintaining such virtual peripherals is a huge ask, which QEMU already solved. While for Xen PV guests, which is Xen’s older mode, came before KVM, Xen uses its own seperate paravirt device protocol that involves Xen PV drivers, that has a frontend and a backend. Frontend in the guest and backend in dom0. Architecturally similar to virtio(shared memory ring buffers + lightweight notification), it was Xen’s own independently designed protocol. QEMU’s virtio was created later and partially the design idea was influenced from Xen’s PV, to be hypervisor agnostic usable by KVM or Xen. From my earlier output of:
zgrep XEN /proc/config.gz
CONFIG_XEN_BLKDEV_FRONTEND/BACKEND
CONFIG_XEN_NETDEV_FRONTEND/BACKEND
CONFIG_XEN_PVH=y
Means we have those preconfigured. Modern Xen deployments use PVH mode, which is enabled in our kernel config.
Most importantly if the hardware is supported, its better we utilise it directly to get native performance rather than using some vir* interface, the mechanism is PCI passthrough. Specifically in case of say CPU, we can use KVM/QEMU to run it natively via VT-x. The CPU has two modes VMX root(hypervisor mode) and VMX non-root(guest mode). When NetBSD executes a normal instruction like arithmetic or memory access, we can choose to run it directly on the physical Raptor Lake core, at native speed, that requires no translation via qemu’s TCG. The CPU runs in some elevated mode while running KVM/QEMU, its lower than kernel mode but miles higher than user mode, so if the guest tries something that requires privileged like writing to a control register or doing raw I/O port access, touching interrupt controllers, the CPU trips up a trap or interrupt(non-maskable) to call a VM-exit. This then hands control to the hypervisor(Xen/KVM) which decides what to do, then resumes the guest(VM-entry). So its basically balancing between running on raw hardware and emulating when boundaries cross. The way to implement the PCI passthrough differs. With KVM/QEMU it uses VFIO (Virtual function I/O) passthrough, Xen uses the same mechanism, but the policy differs. It doesn’t use Linux’s VFIO framework, but has its own implementation. Xen has PCI passthrough configured in guest’s domain config file used by x1 create by the pci directive.
pci = [ '0000:01:00.0' ]
Format being (bus:device.function of target device, same as lspci shows). For KVM/QEMU the IOMMU (Input output memory management unit) lets a specific PCIe device be isolated into its own protection domain and mapped to guest’s address space. The guest talks to real device registers directly, with IOMMU enforcing that it can only DMA into memory which has been granted, so it protects the host from a misbehaving/malicious guest driver. Requirement is IOMMU enabled in firmware, VT-d in UEFI. On Intel we need to check:
[~]> sudo dmesg | grep -i iommu
[ 0.077643] DMAR-IR: IOAPIC id 2 under DRHD base 0xfed91000 IOMMU 1
[ 0.417408] pci 0000:00:02.0: DMAR: Skip IOMMU disabling for graphics
[ 0.469648] iommu: Default domain type: Translated
[ 0.469648] iommu: DMA domain TLB invalidation policy: lazy mode
[ 0.588447] DMAR: Intel-IOMMU force enabled due to platform opt in
[ 0.588687] pci 0000:00:02.0: Adding to iommu group 0
[ 0.588716] pci 0000:00:00.0: Adding to iommu group 1
[ 0.588723] pci 0000:00:04.0: Adding to iommu group 2
[ 0.588734] pci 0000:00:06.0: Adding to iommu group 3
[ 0.588743] pci 0000:00:07.0: Adding to iommu group 4
[ 0.588750] pci 0000:00:08.0: Adding to iommu group 5
[ 0.588760] pci 0000:00:0d.0: Adding to iommu group 6
[ 0.588766] pci 0000:00:0d.2: Adding to iommu group 6
[ 0.588774] pci 0000:00:0e.0: Adding to iommu group 7
[ 0.588781] pci 0000:00:12.0: Adding to iommu group 8
[ 0.588792] pci 0000:00:14.0: Adding to iommu group 9
[ 0.588798] pci 0000:00:14.2: Adding to iommu group 9
[ 0.588807] pci 0000:00:14.3: Adding to iommu group 10
[ 0.588817] pci 0000:00:15.0: Adding to iommu group 11
[ 0.588824] pci 0000:00:15.1: Adding to iommu group 11
[ 0.588832] pci 0000:00:16.0: Adding to iommu group 12
[ 0.588845] pci 0000:00:1f.0: Adding to iommu group 13
[ 0.588852] pci 0000:00:1f.3: Adding to iommu group 13
[ 0.588859] pci 0000:00:1f.4: Adding to iommu group 13
[ 0.588866] pci 0000:00:1f.5: Adding to iommu group 13
[ 2.176329] pci 10000:e0:06.0: Adding to iommu group 7
[ 2.177396] pci 10000:e1:00.0: Adding to iommu group 7
[~]> sudo lspci -nnk
0000:00:00.0 Host bridge [0600]: Intel Corporation Raptor Lake-P/U 4p+8e cores Host Bridge/DRAM Controller [8086:a707]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: igen6_edac
Kernel modules: igen6_edac
0000:00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris Xe Graphics] [8086:a7a0] (rev 04)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: i915
Kernel modules: i915, xe
0000:00:04.0 Signal processing controller [1180]: Intel Corporation Raptor Lake Dynamic Platform and Thermal Framework Processor Participant [8086:a71d]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: proc_thermal_pci
Kernel modules: processor_thermal_device_pci
0000:00:06.0 System peripheral [0880]: Intel Corporation RST VMD Managed Controller [8086:09ab]
0000:00:07.0 PCI bridge [0604]: Intel Corporation Raptor Lake-P Thunderbolt 4 PCI Express Root Port #0 [8086:a76e]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: pcieport
Kernel modules: shpchp
0000:00:08.0 System peripheral [0880]: Intel Corporation GNA Scoring Accelerator module [8086:a74f]
Subsystem: Dell Device [1028:0c14]
0000:00:0d.0 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 USB Controller [8086:a71e]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
0000:00:0d.2 USB controller [0c03]: Intel Corporation Raptor Lake-P Thunderbolt 4 NHI #0 [8086:a73e]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: thunderbolt
Kernel modules: thunderbolt
0000:00:0e.0 RAID bus controller [0104]: Intel Corporation RST Volume Management Device Controller [8086:a77f]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: vmd
Kernel modules: vmd
0000:00:12.0 Serial controller [0700]: Intel Corporation Alder Lake-P Integrated Sensor Hub [8086:51fc] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: intel_ish_ipc
Kernel modules: intel_ish_ipc
0000:00:14.0 USB controller [0c03]: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller [8086:51ed] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
0000:00:14.2 RAM memory [0500]: Intel Corporation Alder Lake PCH Shared SRAM [8086:51ef] (rev 01)
Subsystem: Dell Device [1028:0c14]
0000:00:14.3 Network controller [0280]: Intel Corporation Raptor Lake PCH CNVi WiFi [8086:51f1] (rev 01)
Subsystem: Intel Corporation Wi-Fi 6E AX211 160MHz [8086:4090]
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
0000:00:15.0 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 [8086:51e8] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
0000:00:15.1 Serial bus controller [0c80]: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 [8086:51e9] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: intel-lpss
Kernel modules: intel_lpss_pci
0000:00:16.0 Communication controller [0780]: Intel Corporation Alder Lake PCH HECI Controller [8086:51e0] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: mei_me
Kernel modules: mei_me
0000:00:1f.0 ISA bridge [0601]: Intel Corporation Raptor Lake LPC/eSPI Controller [8086:519d] (rev 01)
Subsystem: Dell Device [1028:0c14]
0000:00:1f.3 Multimedia audio controller [0401]: Intel Corporation Raptor Lake-P/U/H cAVS [8086:51ca] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: sof-audio-pci-intel-tgl
Kernel modules: snd_soc_avs, snd_sof_pci_intel_tgl, snd_hda_intel
0000:00:1f.4 SMBus [0c05]: Intel Corporation Alder Lake PCH-P SMBus Host Controller [8086:51a3] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: i801_smbus
Kernel modules: i2c_i801
0000:00:1f.5 Serial bus controller [0c80]: Intel Corporation Alder Lake-P PCH SPI Controller [8086:51a4] (rev 01)
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: intel-spi
Kernel modules: spi_intel_pci
10000:e0:06.0 PCI bridge [0604]: Intel Corporation Raptor Lake PCI Express 4.0 Graphics Port [8086:a74d]
Subsystem: Dell Device [1028:0c14]
Kernel driver in use: pcieport
Kernel modules: shpchp
10000:e1:00.0 Non-Volatile memory controller [0108]: Sandisk Corp PC SN740 NVMe SSD (DRAM-less) [15b7:5015] (rev 01)
Subsystem: Sandisk Corp PC SN740 NVMe SSD (DRAM-less) [15b7:5015]
Kernel driver in use: nvme
Kernel modules: nvme
So we have to find the vendor:devie ID, then bind it to vfio-pci, either using kernel driver ovverride at boot or driverctl/manual echo to /sys/bus/pci/drivers/vfio-pci/bind
Also IOMMU device groups matter, devices in the same group gets passed through together, there is no option to split them. An example being
└[~]> sudo find /sys/kernel/iommu_groups/ -maxdepth 1 -type d
/sys/kernel/iommu_groups/
/sys/kernel/iommu_groups/7
/sys/kernel/iommu_groups/5
/sys/kernel/iommu_groups/13
/sys/kernel/iommu_groups/3
/sys/kernel/iommu_groups/11
/sys/kernel/iommu_groups/1
/sys/kernel/iommu_groups/8
/sys/kernel/iommu_groups/6
/sys/kernel/iommu_groups/4
/sys/kernel/iommu_groups/12
/sys/kernel/iommu_groups/2
/sys/kernel/iommu_groups/10
/sys/kernel/iommu_groups/0
/sys/kernel/iommu_groups/9
┌[honken@Pratyush-PC] [/dev/pts/4]
└[~]> sudo ls /sys/kernel/iommu_groups/12/devices
0000:00:16.0
┌[honken@Pratyush-PC] [/dev/pts/4]
└[~]> sudo ls /sys/kernel/iommu_groups/7/devices
0000:00:0e.0 10000:e0:06.0 10000:e1:00.0
The only qemu flag in need is -device vfio-pci,host=
For writing the installer script, we need two bash scripts, one boots the NetBSD image into the QEMU disk, and second boots into the disk. I call the 1st one boot_install.sh and 2nd one boot_normal.sh
# create a qemu disk image to install the NetBSD image, I will allocate myself 100G
mkdir -p ~/virtual-machines/NetBSD
cd ~/virtual-machines/NetBSD
qemu-img create -f qcow2 netbsd.img 100G
# qcow2 is qemu copy on write version 2
cat ./boot_install.sh
#! /usr/bin/bash
qemu-system-x86_64 \
-m 4G \
-smp 4 \
-cdrom NetBSD-11.0-amd64.iso \
-drive file=netbsd.img,format=qcow2 \
-boot d \
-enable-kvm \
-virtfs local,path=/home/honken/virtual-machines/NetBSD,mount_tag=hostshare,security_model=none \
-netdev user,id=network-vm \
-device virtio-net-pci,netdev=network-vm \
-bios /usr/share/edk2/OvmfX64/OVMF_CODE.fd \
-nographic
cat ./boot_normal.sh
#! /usr/bin/bash
qemu-system-x86_64 \
-m 4G \
-smp 4 \
-drive file=netbsd.img,format=qcow2 \
-boot c \
-enable-kvm \
-virtfs local,path=/home/honken/virtual-machines/NetBSD,mount_tag=hostshare,security_model=none \
-netdev user,id=network-vm,hostfwd=tcp::2222-:22 \
-device virtio-net-pci,netdev=network-vm \
-bios /usr/share/edk2/OvmfX64/OVMF_CODE.fd \
-object rng-random,filename=/dev/urandom,id=viornd0 \
-device virtio-gpu-gl-pci \
-nographic
Now we make them executable
chmod +x boot_install.sh
chmod +x boot_normal.sh
Launch the installer, configure and then boot up the VM
./boot_install.sh
./boot_normal.sh
Second stage is to write sm6115-samsung-gta4l.dts, though this may sound simple, but the most horrific part is the vendor actually never provides a single file dts for T505(specific model), and hence we used dtc(Open Firmware device tree compiler), to get a working dts straight out of the dtbo image provided by the bootloader to the kernel on system boot. Well the issue is, dtc is based on reverse engineering, and the whole basis of reverse engineering is assumption based on behaviour. Not to say that the extracted dts is going to be inaccurate, but it means it has chances of being incomplete.
Then we move to the 3rd stage, where we will use the written dts file(mainline compatible) and store it locally on pmaports kernel package. Step 4 will be generate pmbootstrap builds using linux-postmarketos-qcom-sm6115 (mainline kernel), the DTB compiled from the DTS we write and Alpine rootfs(As pmos is based on ALpine linux). Step 5 will be pmbootstrap packaging everything into boot.img(kernel + DTB + pmos initramfs), here we may have to tackle partition space related issues. Step 6 will be flashing via heimdall(Samsung device,odin protocol implemented at hardware level, so we don’t have much realistic chance of bricking).
If step 3,4 and 5 are a success, we replicate it by booting,check dmesg, and iterating to build a complete DTS, as the plan is to move in accordance with peripheral priority. P1: UFS + USB + serial console (boot critical) P2: Regulators (supporting everything above and below) P3: Display + touch + power keys (usability) P4: WiFi + BT + modem (connectivity)
Before moving it is important we get a heavy theoritical grasp of whats inside the chasis and what behaviour to expect. As we know SM6115 is supported in mainline kernel, so we do have SoC base, but if SoC is supported it doesn’t mean a specific device using the SoC has a mainline dts. The SoC clock drivers,regulators and core peripherals work flawlessly but the board specific DTS for gta4l doesn’t exist upstream yet, so we will be writing it.
The pmos wiki lists “Display broken”, a broken display might refer to “black screen” i.e kernel can’t initialise the DSI panel, so we will need serial UART or pstore to debug. Serial UART( Universal asynchronous receiver-transmitter ),Hardware protocol for serial communication. “Asynchronous” means no shared clock between sender and receiver — they agree on baud rate (115200 in this case,we got it from the extracted dts file) beforehand and that’s how they stay in sync. For a hardware serial port on qcomm devices its ttyMSM0. The kernel sends all boot messages to it in real time, before display initializes,before USB comes up or any other mechanism.
Our cmdline has the parameter:
console=ttyMSM0,115200n8
earlycon=msm_geni_serial,0x4a90000
Hence the kernel will output to UART from the very first boot message,the issue being to actually read it we need a physical UART adapted connected to test pads on the PCB(printed circuit board - it is the physical board inside the tablet on which all the chips are soldered). UART test pads are small copper pads on the PCB that the manufacturer uses during factory testing to read serial output. On most consumer devices Samsung doesn’t expose them as a proper connector,they’re just bare pads you’d need to solder thin wires to and connect to a USB-UART adapter to read the serial output on our PC. PStore stands for persistent storage,A kernel subsystem that writes the last kernel log to persistent storage (reserved RAM or flash) before a crash. After a reboot you can read what the kernel printed just before it panicked.
cat /sys/fs/pstore/dmesg-ramoops-0
# this is how we read and debug a kernel panic that reboots the device before we can even read the dmesg.
pstore is wired in via the ramoops node, we will include it,as it costs nothing and saves us if the kernel panics on first boot. Also, “Oops” is kernel terminology for a non-fatal kernel error/crash. ramoops = RAM-based oops logger.
We also take a close look at the android stack Android apps(APK’s) –> Android frameworks(ART,Binder,..)–> Android HALs –> Linux Kernel(with qcomm downstream patches).
In case of pmos, the stack looks like Alpine linux userspace(apk(alpine package) packages,musl,..) –> Linux kernel(downstream/mainline).
Downstream kernels are easier to work with because the vendor distributed android version was in some way compatible with that Linux major version, as Linux doesn’t have a stable ABI, the pattern changes drastically. On the PCB, SoC is the main chip, it integrates CPU,GPU,modem,ISP,DSP,memory controller, and peripheral controllers(like I2C,SPI,UART,USB) everything on it. So SoC has it dts already defined in the mainline in our case, so the difference between SoC and device board(for gta4l) is
SoC (SM6115) — same across all devices using it
Kryo 260 CPU cores
Adreno 610 GPU
Qualcomm modem (LTE)
QCA BT/WiFi controller
Peripheral buses (I2C, SPI, UART…)
Clock/regulator controllers
Board (Samsung gta4l) — unique per device Which I2C bus the touchscreen is on Which GPIO resets the display Which PMIC regulator powers what Panel type (DSI, timing parameters) Battery charger IC model Physical routing of all the above
Hence we know that SoC drivers are upstream, the clock,the regulators, the adreno 610 GPU driver. What isn’t present is the board DTS(device tree source) for gta4l specifically. This DTS file knows the touch screen is located on say I2C bus 3,panel reset on GPIO 47, display DSI timing is X, and so on. We know there is gta4l sibling gta4lwifi, even if it had mainline support we simply couldn’t use it because the board might be the same but peripherals might be connected or communicate to a different bus. Though it would be miles easier to take it as reference to create the DTS. Downstream kerenl isn’t just older kernel, its a fork of an older kernel with a massive out of tree patches from qcomm and vendor specific patches from samsung that never made it up for mainline submission/merge. The reason might be vendor gatekeeping or not satisfying the kernel standards, or android specific interfaces like ION allocator, sync fences built into drivers. Mainline is what we refer to as Linus’s tree, where the same hardware gets implemeted cleanly. The hardware specific code there follows kernel subsystem APIs, which is approved by maintainers. Thus downstream kernel is static support, as its built on top of older kernel with massive out of tree blobs, it has no continuation like the mainline counterpart that receives constant support because of ongoing development.
One of the main distinction is the android specific downstream kernel code, the actual drivers which are written in C, can’t be simply reused because
// downstream code uses:
ion_alloc() // Android ION allocator - removed from mainline
sync_fence_create() // Android sync framework - replaced by dma-fence
mdss_fb_* // Samsung display subsystem - not in mainline
So what we understand is the drivers in the kernel exist to pass control to the hardware, which is a binary, commonly referred to as device firmware. What isn’t cleanly portable is the driver itself.
Another important distinction is the dts and dtsi. From the mainline tree, we can look it from the cloned linux repo,
arch/arm64/boot/dts/qcom/sm6115.dtsi # file exists
This direcotry holds CPU nodes,Adreno 610 DRM/KMS driver, btqca driver,clock controller(gcc-sm6115),interconnect nodes, USB,I2C and SPI controllers. Hence our job is writing the sm6115-samsung-gta4l.dts, The .dtsi (i = include) defines all SoC-level nodes like CPU, clocks, interconnects, peripheral controllers, all of which ,with status = “disabled” by default. Our board .dts enables the ones our device uses and fills in board-specific properties.
Another important aspect is the booting criteria -: Android devices handle process and wakelocks differently because they were meant for handheld devices. For eg, say Lineage os holds “Boot” and “userdata” partition, the boot contains the android kernel(we refer it as downstream) + android ramdisk(loads the minimal kernel into memory). Whereas userdata partition holds the android userspace which is ART and framworks along with apps.
After say a theoritical pmos flash, boot partition holds the mainline kernel + pmos initramfs, the userdata partition holds alpine linux rootfs(in our case musl, blueZ, systemd ..). What we don’t dare to touch is the bootloader, the bootloader is layered and holds a hardware level watchdog, so if accidently a different image is flashed, after a certain amount of time the device enters bootloader(samsung refers it as download mode).
Hence the full chain of android booting looks like -:
XBL (Qualcomm bootloader)
→ ABL (Android bootloader)
→ reads BOOT partition
→ loads your pmOS kernel + DTB into RAM
→ kernel boots, reads DTB, initializes hardware
→ mounts Alpine rootfs from USERDATA
→ systemd starts
The main question is where does our superstar the DTS actually resides? There is dual possibility, path A - local(inside pmsports kernel package directory,pmbootstrap compiles it and includes it in the boot image). path B - we submit it to mainline kernel tree as a proper patch. It then resides in “arch/arm64/boot/dts/qcom/sm6115-samsung-gta4l.dts” . Well the tracersal path is A to B in this case, we iterate with A as we are going to build the dts in stages with priority(as mentioned earlier).
More info on the 2 stage bootloader and the watchdog - If a broken DTS is built into the boot.img and flashed, the qcomm bootloader(XBL -> ABL) does not validate the dtb contents at all. So we don’t get thrown to the download mode, the bootloader boots successfully but peripherals/components remain dysfunctional. The bootloader behaviour is also reliant on how wrong the DTS was, which generated the DTB.
Case-1:
Wrong compatible string
.kernel boots, driver doesn't bind, device just absent
.dmesg shows - no driver found
.everything else works fine
Case-2:
Wrong GPIO number for display reset
.kernel boots, display stays black
.SSH in via USB networking, read dmesg,we fix it
Case-3:
Wrong regulator reference
.kernel panics during probe, or device reboots
.flash corrected boot.img, we try again
Case-4:
Completely malformed DTS syntax
.DTB compilation fails at build time
.pmbootstrap won't even produce boot.img
.never reaches the device
The safety net here is USB networking. pmOS initramfs brings up USB networking automatically even before the rootfs mounts. So even with black screen, no touch, nothing working, we can always
# Device shows up as USB ethernet on our PC
ssh user@<ip address>
# Then read kernel log
dmesg | grep -i "error\|fail\|panic"
Thus earlier we had choosen none as UI and dropbear for a minimal ssh client.Console over ssh is our debugging interface. The only case where a reflash might be needed is , kernel panics at boot and device reboots into download mode after watchdog timeout.Then we just reflash the fixed boot.img. Minimal chances of bricking. Watchdog is in hardware, its a timer register in the SoC itself,qcomm refers it as APPS_WDOG.Completely independent of the vendor or any samsung firmware or security policy. Watchdog will work independent of the OS, it resides at the silicon level itself.
The last part being the PIT, a partition table, it describes where partitions live on eMMC(Embedded Multimedia Card),its essentially a soldered-on SD card. Flash storage (NAND) with a controller chip, packaged together and soldered directly to the PCB. The “embedded” means it’s not removable like a regular SD card. No boot conditions are stored in the PIT. These are qcomm firmware partitions, which remain same as stock and are untouched like XBL,TZ,ABL,..
]]>First, i would define some terminologies that basically defines the whole underlying technology that makes android different from mainstream Linux based distributions. Starting from bootloader and partitions, most of the desktop os, lets you define partitions that includes a UEFI/BIOS partition, / (root partition), and an optional swap partition. This is usually a common use pattern, though a user can split the partitions based on utility, like creating a separate tmpfs, if a machine has low memory and is suited for a compilation heavy environment. A separate /var if intended for a mail server. But android intended for handheld devices works in a heavy environment of embedded systems. Thus it includes multiple partitions that holds binary blobs for hardware like camera, flash light, speakers and multiple such embedded hardware. Another example being bluetooth, Android uses its own bluetooth stack (Fluoride/Gabeldorsche), talking to hardware via a vendor HAL. Whereas pmos uses bluez. As linux distributions expect every code to exist in either the kernel or as loadable modules, this behaviour creates conflicts, and so lot of times peripherals just don’t work in pmos. While BlueZ,which talks to hardware via HCI (Host Controller Interface),the standard protocol. The chip itself speaks HCI regardless of OS. Therefore when a utility/software requires a camera access, the android kernel consists of the device driver, that has the ability to interact with the binary blob (firmaware) situated in the partition, these drivers then pass on the control to the binary, which performs the action. Other than that android has another defining concept of slots, older devices and even many lower end devices make use of single slot mechanism (A slot), while latest and higher end devices make use of dual slots (A/B) to manage upgrades.
While in general the android environment seems more inaccessible to changes compared to desktop counterparts, its actually the opposite. Android devices lets a super user have complete access including the bootloader, which if undergoes modification or accidental deletion makes the system unbootable, commonly referred as “hard bricking”. While soft bricking is recoverable, which includes flashing the wrong boot image. But scenarios exist where hard bricking is possible if a user flashes a wrong recovery and boot images. MOst important defining concept in android ecosystem being three images, vbmeta, dtbo, recovery.img and boot.img. vbmeta checks for signature of boot.img, so if a wrong/unrealted device boot.img is flashed, android will refuse to boot and will take to recovery partition. Next comes dtbo, which is a binary file, produced from dts (device tree source), it defines how the entire board is defined on the SoC(System on Chip). As android being part of embedded system, it is meant to be space efficent. This dts tells the kernel, how the board is defined, which peripheral is connected to which port. As Linux kernel is highly portable, it runs on many embedded hardware, so the concept of dts is not alien to the OS itself, the issue lies in dts naming conventions.
Here, I will define two kernel sources, upstream and downstream. Upstream being the latest branch of linux kernel or a kernel compatible with kerenl.org’s releases. Whereas downstream being the AOSP based kernel shipped by the vendor. So the dts file structure defining is what decides portability. Understanding of the device board thats slapped on top of the SoC is crucial.
So to get the images, kernel source tree and dts files(though most of the vendors rarely release this, vendors mostly try to release as less as possible without violating the GPL licenced parts of Android). Well we can always extract these images from a running system using adb(android debug bridge). Most vendors have a dedicated channel for releasing these software components, here we are trying to port a samsung galaxy tab A7, model : SM-T505, device codename : gta4l. For samsung the dedicated release channel is :
https://opensource.samsung.com/
As I’m running Lineage OS currently on this tablet, its comparatively easier, as I can get all the sources from Lineage’s git repo. This also has a massive advantage, that everytime I need not rely on odin/heimdall instead I can use fastbootd.
https://wiki.lineageos.org/devices/gta4l/
https://github.com/LineageOS/lineage_wiki/blob/main/_data/devices/gta4l.yml
The gta4l.yml file contains device specification and Lineage maintainer details, as Lineage provides complete working custom ROM for official devices, these config are highly reliable source.
architecture: arm64
battery: {capacity: 7040, removable: false, tech: 'Li-Po'}
before_install: {instructions: 'needs_specific_android_fw', lineage_version: 20, version: '12'}
before_recovery_install: samsung_qcom
bluetooth: {profiles: [A2DP], spec: '5.0'}
cameras:
- {flash: None, info: '8 MP (Primary)'}
- {flash: None, info: '5 MP (Front Facing)'}
codename: gta4l
cpu: Kryo 260
cpu_cores: '8'
cpu_freq: 4 x 2.0 GHz + 4 x 1.8 GHz
current_branch: 23.2
dimensions: {depth: 7, height: 157.4, width: 247.6}
download_boot: With the device powered off, hold <kbd>Volume Down</kbd> + <kbd>Volume Up</kbd> then connect USB cable to PC.
firmware_update: firmware_update_samsung_gta4l
gpu: Qualcomm Adreno 610
image: gta4l.png
install_method: samloader_rs
kernel: {repo: android_kernel_samsung_sm6115, version: '4.19'}
maintainers: [chrmhoffmann]
models: [SM-T505, SM-T505C, SM-T505N, SM-T507]
name: 'Galaxy Tab A7 10.4 2020 (LTE)'
network: [2G GSM, 2G CDMA, 3G UMTS, 4G LTE]
peripherals: [3.5mm jack, Accelerometer, Compass, GPS, Gyroscope, Light sensor, Proximity sensor, USB OTG]
quirks: [ims]
ram: 3 GB
recovery_boot: Reboot and immediately hold <kbd>Volume Up</kbd> + <kbd>Power</kbd> while the device is connected to a PC via USB cable.
recovery_partition_name: recovery
release: 2020-09
screen: {resolution: '2000x1200', size: 10.4, technology: 'TFT LCD'}
sdcard: {size_max: '1 TB'}
soc: Qualcomm SM6115 Snapdragon 662
storage: 32 GB
tree: android_device_samsung_gta4l
type: tablet
vendor: Samsung
vendor_short: samsung
versions: [20, 21, 22.1, 22.2, 23.0, 23.2]
wifi: 802.11 a/b/g/n/ac
For now the priority is to get a bootable image with display and touch sensors working, once we get to that stage, next focus would be on audio, bluetooth and getting a complete desktop environment working. From the yml file, the SoC is “Qualcomm SM6115 Snapdragon 662”.Thats clearly a good thing, because a SoC based on Qualcomm is most likely to have the device tree in linux mainline kernel, unlike mediatek which seems to be bit opaque or rather say uninterested. So here I will list all the links that I will commonly refer to create and understand valid dts files and as well as look into its sibling devices that may be supported.
https://wiki.postmarketos.org/wiki/Samsung_Galaxy_Tab_A7_(samsung-gta4lwifi)
https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_460/662_(SM4250/SM6115)
Though pmos doesn’t list any active user for T505 itself, but its sibling the gta4lwifi has some work in progress, which is a good sign. So now we setup the pmbootstrap , which is the central command-line application for postmarketOS development. Among other things, it allows building packages, creating installation images and flashing them to your device.
Installing pmbootstrap from GURU repository in Gentoo:
sudo emerge -avq dev-util/pmbootstrap
pmbootstrap working directory is
$HOME/.local/var/pmbootstrap/cache_git/pmaports
Also I will create another directory in my home, to have easy access to the source files and organising the project directory
mkdir ~/postmarketos
cd ~/postmarketos
┌[honken@Pratyush-PC] [/dev/pts/4] [main]
└[~/postmarketos]> pmbootstrap init
[19:33:21] Location of the 'work' path. Multiple chroots (native, device arch, device rootfs) will be created in there.
[19:33:21] Work path [/home/honken/.local/var/pmbootstrap]:
[19:33:23] Location of the 'pmaports' path, containing package definitions.
[19:33:23] pmaports path [/home/honken/.local/var/pmbootstrap/cache_git/pmaports]:
[19:33:25] Choose the postmarketOS release channel.
[19:33:25] Available (13):
[19:33:25] * edge: Rolling release / Most devices / Occasional breakage: https://postmarketos.org/edge
[19:33:25] * v25.12: Latest release / Recommended for best stability
[19:33:25] * v25.06: Old release (unsupported)
[19:33:25] Channel [edge]:
[19:33:26] Choose your target device vendor (either an existing one, or a new one for porting).
[19:33:26] Available vendors (107): acer, alcatel, amazon, amediatech, amlogic, apple, ark, arrow, asus, ayaneo, ayn, bananapi, barnesnoble, beelink, blackberry, bq, clockworkpi, cubietech, cutiepi, dell, dongshanpi, epson, essential, fairphone, finepower, fly, fxtec, generic, goclever, google, gp, hisense, hp, htc, huawei, inet, infocus, jolla, khadas, klipad, kobo, lark, leeco, lenovo, lg, librecomputer, linksys, lynx, mangopi, medion, meizu, microsoft, mnt, mobvoi, motorola, nextbit, nobby, nokia, nothing, nvidia, odroid, oneplus, oppo, ouya, pine64, planet, pocketbook, postmarketos, powkiddy, purism, qcom, qemu, qualcomm, radxa, raspberry, realme, rockchip, samsung, semc, sharp, shift, sipeed, solidrun, sony, sourceparts, sqfmi, starway, surftab, t2m, thundercomm, tokio, tolino, trekstor, valve, vernee, vivo, volla, wd, wexler, wiko, wileyfox, xiaomi, xunlong, yu, zhihe, zte, zuk
[19:33:26] Vendor [qemu]: samsung
[19:33:32] Devices are categorised as follows, from best to worst:
* Main: ports where mostly everything works.
* Community: often mostly usable, but may lack important functionality.
* Testing: anything from "just boots in some sense" to almost fully functioning ports.
* Downstream: ports that use a downstream kernel — very limited functionality. Not recommended.
Available devices by codename (42): a32 (downstream), a51 (downstream), chagallwifi (testing), codina (testing), codina-tmo (testing), coreprimevelte (community), e7 (testing), espresso10 (community), espresso7 (community), expressatt (testing), exynos7 (testing), exynos9820 (testing), fortuna (testing), fortunaltezt (testing), gavini (testing), golden (testing), grandmax (testing), gt510 (testing), gt58 (testing), i9100 (testing), j3ltetw (testing), j4lte (downstream), j5 (testing), j5x (testing), janice (testing), jflte (testing), klimtlte (testing), kona (testing), kyle (testing), loganrelte (testing), lt01 (testing), lt03lte (testing), m0 (community), m20lte (downstream), m3 (testing), n1awifi (testing), n2awifi (testing), p4note (testing), rossa (testing), skomer (testing), starqltechn (community), v1awifi (testing)
[19:33:32] Device codename: gta4l
[19:33:46] The specified device ('samsung-gta4l') could not be found in existing ports.
If you're trying to select a device that is supported, check the following:
* Make sure you spelled the vendor name and codename correctly.
* Check if you're on the right release branch. Devices in the 'downstream' category are only available on the 'edge' branch; if you selected a stable branch, run pmbootstrap init again and select 'edge'.
* If the device is supported by a generic port, type in the vendor and codename of the generic port.
If you want to create a new device port, follow the guide at <https://postmarketos.org/porting/>.
[19:33:46] Do you want to create a new device port? (y/n) [y]: y
[19:34:13] What type of port are you creating?
[19:34:13] * mainline: Port using upstream/mainline kernel, compatible with upstream user space.
[19:34:13] * downstream: Port using downstream kernel, using the original (e.g. Android) kernel sources, at least partially incompatible with upstream user space.
[19:34:13] Type? (mainline/downstream): mainline
[19:34:27] Generating new aports for: samsung-gta4l...
[19:34:27] Device architecture (x86/loongarch64/s390x/riscv64/armv7/ppc64le/aarch64/x86_64) [aarch64]:
[19:34:32] Who produced the device (e.g. LG)?
[19:34:32] Manufacturer: samsung
[19:34:38] What is the official name (e.g. Google Nexus 5)?
[19:34:38] Name: Samsung Galaxy Tab A7
[19:34:56] In what year was the device released (e.g. 2012)?
[19:34:56] Year: 2020
[19:35:01] What type of device is it?
[19:35:01] Valid types are: desktop, laptop, convertible, server, tablet, handset, watch, embedded, vm
[19:35:01] Leave empty if this property is defined elsewhere, e.g. in Devicetree or ACPI
[19:35:01] Chassis: tablet
[19:35:12] Does the device have a sdcard or other external storage medium? (y/n) [n]: y
[19:35:17] Which flash method does the device support?
[19:35:17] Flash method (0xffff/fastboot/heimdall/mtkclient/none/rkdeveloptool/uuu) [none]: fastboot
[19:38:10] You can analyze a known working boot.img file to automatically fill out the flasher information for your deviceinfo file. Either specify the path to an image or press return to skip this step (you can do it later with 'pmbootstrap bootimg_analyze').
[19:38:10] Path:
[19:38:35] *** pmaport generated: /home/honken/.local/var/pmbootstrap/cache_git/pmaports/device/testing/device-samsung-gta4l
[19:38:35] Username [user]: nandiprh
[19:39:00] Available providers for postmarketos-base-ui-audio-backend (2):
[19:39:00] * pulseaudio: Use pulseaudio as the audio backend. (default)
[19:39:00] * pipewire: Use pipewire as the audio backend. (but may not work with all devices)
[19:39:00] Provider [default]: pipewire
[19:39:50] Available providers for postmarketos-base-ui-wifi (2):
[19:39:50] * wpa_supplicant: Use wpa_supplicant as the WiFi backend. (default)
[19:39:50] * iwd: Use iwd as the WiFi backend (but may not work with all devices)
[19:39:50] Provider [default]: iwd
[19:40:23] Available providers for postmarketos-usb-moded-default-profile (2):
[19:40:23] * developer: Make 'developer mode' the default usb-moded profile (always enables usb networking) (default)
[19:40:23] * charging: Make 'charging mode' the default usb-moded profile (usb networking must be manually enabled)
[19:40:23] Provider [default]:
[19:40:49] Available user interfaces (17):
[19:40:49] * none: Bare minimum OS image for testing and manual customization. The "console" UI should be selected if a graphical UI is not desired.
[19:40:49] * buffyboard: Plain framebuffer console with modern touchscreen keyboard support
[19:40:49] * console: Console environment, with no graphical/touch UI
[19:40:49] * fbkeyboard: Plain framebuffer console with touchscreen keyboard support
[19:40:49] * gnome: (Wayland) Gnome Shell
[19:40:49] * gnome-mobile: (Wayland) Gnome Shell patched to adapt better to phones (Experimental)
[19:40:49] * i3wm: (X11) Tiling WM (keyboard required)
[19:40:49] * lxqt: (X11) Lightweight Qt Desktop Environment (stylus recommended)
[19:40:49] * mate: (X11) MATE Desktop Environment, fork of GNOME2 (stylus recommended)
[19:40:49] * openbox: (X11) A highly configurable and lightweight X11 window manager (keyboard required)
[19:40:49] * os-installer: UI for installing postmarketOS
[19:40:49] * plasma-bigscreen: (Wayland) 10-feet variant of Plasma, made for big screen TVs
[19:40:49] * plasma-desktop: (Wayland) KDE Desktop Environment (works well with tablets)
[19:40:49] * shelli: Plain console with touchscreen gesture support
[19:40:49] * sxmo-de-dwm: Simple Mobile: Mobile environment based on SXMO and running on dwm
[19:40:49] * sxmo-de-i3: Simple Mobile: Mobile environment based on SXMO and running on i3
[19:40:49] * windowmaker: (X11) Window manager inspired by the NeXTSTEP user interface (stylus recommended)
[19:40:49] * xfce4: (X11) Lightweight desktop (stylus recommended)
[19:40:49] NOTE: 13 UIs are hidden because "deviceinfo_drm" is not set (see https://postmarketos.org/deviceinfo).
[19:40:49] User interface [console]: none
[19:42:58] WARNING: systemd requires kernel version 5.4. Installing systemd with older kernel may result in non-bootable system. Get more information for systemd requirements at https://github.com/systemd/systemd/blob/main/README
[19:42:58] Based on your UI selection, 'default' will result in not installing systemd.
[19:42:58] Install systemd? (default/always/never) [default]: systemd
[19:43:30] ERROR: Input did not pass validation (regex: ^(default|always|never)$). Please try again.
[19:43:30] Install systemd? (default/always/never) [default]: always
[19:43:40] Additional options: extra free space: 0 MB, boot partition size: 256 MB, parallel jobs: 16, ccache per arch: 5G, sudo timer: False, mirror: http://mirror.postmarketos.org/postmarketos/
[19:43:40] Change them? (y/n) [n]: y
[19:44:06] Set extra free space to 0, unless you ran into a 'No space left on device' error. In that case, the size of the rootfs could not be calculated properly on your machine, and we need to add extra free space to make the image big enough to fit the rootfs (pmbootstrap#1904). How much extra free space do you want to add to the image (in MB)?
[19:44:06] Extra space size: 0
[19:45:36] What should be the boot partition size (in MB)?
[19:45:36] Boot size [256]:
[19:45:40] How many jobs should run parallel on this machine, when compiling?
[19:45:40] Jobs [16]:
[19:45:56] We use ccache to speed up building the same code multiple times. How much space should the ccache folder take up per architecture? After init is through, you can check the current usage with 'pmbootstrap stats'. Answer with 0 for infinite.
[19:45:56] Ccache size [5G]:
[19:46:01] pmbootstrap does everything in Alpine Linux chroots, so your host system does not get modified. In order to work with these chroots, pmbootstrap calls 'sudo' internally. For long running operations, it is possible that you'll have to authorize sudo more than once.
[19:46:01] Enable background timer to prevent repeated sudo authorization? (y/n) [n]: y
[19:46:16] Selected mirror: http://mirror.postmarketos.org/postmarketos/
[19:46:16] Change mirror? (y/n) [n]: y
[19:46:23] Download https://postmarketos.org/mirrors.json
[19:46:24] list of available mirrors:
[19:46:24] [1] mirror.postmarketos.org (Falkenstein, Germany)
[19:46:24] [2] postmarketos.craftyguy.net (Santa Clara, CA, USA)
[19:46:24] [3] mirror.sajattack.xyz (Victoria, BC, Canada)
[19:46:24] [4] mirror.math.princeton.edu (Princeton, NJ, USA)
[19:46:24] [5] mirrors.aliyun.com (Hangzhou, China)
[19:46:24] [6] mirrors.tuna.tsinghua.edu.cn (Beijing, China)
[19:46:24] [7] mirrors.bfsu.edu.cn (Beijing, China)
[19:46:24] [8] mirrors.ustc.edu.cn (Anhui, China)
[19:46:24] [9] mirror.nju.edu.cn (Nanjing, Jiangsu, China)
[19:46:24] [10] alpine.sakamoto.pl (Warsaw, Poland)
[19:46:24] [11] distrohub.kyiv.ua (Kyiv, Ukraine)
[19:46:24] [12] mirror-sg.mainlining.org (Singapore, Singapore)
[19:46:24] [13] ftp.halifax.rwth-aachen.de (Aachen, Germany)
[19:46:24] choose 'best' to select the one closest to you
[19:46:24] Select a mirror [1]:
[19:46:37] Additional packages that will be installed to rootfs. Specify them in a comma separated list (e.g.: vim,file) or "none"
[19:46:37] Extra packages [none]: vim,dropbear,nano,strace,evtest,usbutils,tree
[19:48:15] Your host timezone: Asia/Kolkata
[19:48:15] Use this timezone instead of GMT? (y/n) [y]: y
[19:48:20] Choose your preferred locale, like e.g. en_US. Only UTF-8 is supported, it gets appended automatically. Use tab-completion if needed.
[19:48:20] Locale [en_US]:
[19:48:25] Device hostname (short form, e.g. 'foo') [samsung-gta4l]:
[19:48:29] SSH public keys found (2):
[19:48:29] * /home/honken/.ssh/id_ed25519.pub
[19:48:29] * /home/honken/.ssh/id_ed25519.pub.pub
[19:48:29] See https://postmarketos.org/ssh-key-glob for more information.
[19:48:29] Would you like to copy these public keys to the device? (y/n) [n]: y
[19:48:36] After pmaports are changed, the binary packages may be outdated. If you want to install postmarketOS without changes, reply 'n' for a faster installation.
[19:48:36] Build outdated packages during 'pmbootstrap install'? (y/n) [y]: y
[19:49:04] DONE!
The above selections are based on my preferences, iwd is modern and integrates better with systemd, I choose pipewire because it was designed with bluetooth in mind from start, and bluetooth is a must for me. The above extra packages are for basic utilities like vim and nano for text editing, dropbear for a lighweight ssh client, strace syscalls a process makes, highly useful when a daemon fails silently without providing any errors.
strace daemon_name # shows what a daemon is doing at kernel level
evtest reads raw inputs from /dev/input/event* devices, evtest detects if kernel is receiving any input before any UI layer is involved.
After pmbootstrap init completes, check the status.
└[~/postmarketos]> pmbootstrap status
Channel: systemd-edge (pmaports: main, dirty)
Device: samsung-gta4l (aarch64)
UI: none
systemd: yes ('always' selected in 'pmbootstrap init')
Then check if the device info is intact, and hasn’t undergone any accidental changes.
└[~/postmarketos]> cat ~/.local/var/pmbootstrap/cache_git/pmaports/device/testing/device-samsung-gta4l/deviceinfo
# Reference: <https://postmarketos.org/deviceinfo>
# Please use double quotes only. You can source this file in shell
# scripts.
deviceinfo_format_version="0"
deviceinfo_name="samsung Samsung Galaxy Tab A7"
deviceinfo_manufacturer="samsung"
deviceinfo_codename="samsung-gta4l"
deviceinfo_year="2020"
deviceinfo_dtb=""
deviceinfo_arch="aarch64"
# Device related
deviceinfo_chassis="tablet"
deviceinfo_external_storage="true"
# Bootloader related
deviceinfo_flash_method="fastboot"
deviceinfo_kernel_cmdline=""
deviceinfo_generate_bootimg="true"
deviceinfo_flash_pagesize="2048"
deviceinfo_bootimg_qcdt="false"
deviceinfo_dtb_second="false"
For now this looks fine to me, also above I choose fastboot as flashing method rather than heimdall because my device currently runs lineage os, so I do have access to userspace level fastbootd, which is much simpler and faster. Though in most cases heimdall should be preferred because its intended to be used for samsung devices,as samsung devices use their own odin protocol.
So here we are done with the initial setup, and we can now setup the working directory to clone the mainline kernel, install any required packages, inspect the device partitions and extract the dts files. Though for my device I can simply refer to the LineageOS tree, I will include every option that might be useful for future use cases. Now we need is adb and the device to be ported need to have debugging enabled in developer options. Also great to have rooted usb debugging to be enabled, by default LineageOS ships with this option enabled in its kernel.
Now we can extract the dtbo image
[~]> adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
R9ZR502N5LJ unauthorized
┌[honken@Pratyush-PC] [/dev/pts/3]
└[~]> adb root
restarting adbd as root
┌[honken@Pratyush-PC] [/dev/pts/3]
└[~]> cd postmarketos
┌[honken@Pratyush-PC] [/dev/pts/3] [main]
└[~/postmarketos]> adb pull /sys/firmware/fdt ~/postmarketos/gta4l_extracted.dtb
/sys/firmware/fdt: 1 file pulled, 0 skipped. 20.0 MB/s (817870 bytes in 0.039s)
┌[honken@Pratyush-PC] [/dev/pts/3] [main ⚡]
└[~/postmarketos]> ls
gta4l_extracted.dtb
# If adb root is unavailable, make use of
$ adb shell su -c "cat /sys/firmware/fdt" > gta4l_extracted.dtb
Currently we have the merged DTB the bootloader passed to the kernel at boot. Base SoC dtb and device specific dtbo overlay applied, hence the complete hardware description. As earlier stated we need is the DTS file, but we do have the binary generated from it ,the dtc (Open Firmware device tree compiler).
sudo emerge -av sys-apps/dtc
└[~/postmarketos]> dtc -I dtb -O dts -o ~/postmarketos/gta4l_extracted.dts ~/postmarketos/gta4l_extracted.dtb
/home/honken/postmarketos/gta4l_extracted.dts: Warning (label_is_string): /soc/qcom,cam_smmu/msm_cam_smmu_ope:label: property is not a string
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l1@4000:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l2@4100:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l3@4200:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l4@4300:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l5@4400:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l6@4400:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l7@4400:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/qcom,msm-audio-apr/qcom,q6core-audio/lpi_pinctrl@ac40000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/rx-macro@a600000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (reg_format): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/tx-macro@a620000:reg: property has invalid length (8 bytes) (#address-cells == 2, #size-cells == 1)
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /memory: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/wake-gic: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,cpufreq-hw: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/ref_gnd: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/vref_1p25: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/die_temp: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/vph_pwr: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/vcoin: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/xo_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/pa_therm0: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/quiet_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/camera_flash_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/vadc@3100/emmc_ufs_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/adc_tm@3500/pa_therm0: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/adc_tm@3500/quiet_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/adc_tm@3500/xo_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/adc_tm@3400/camera_flash_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pm6125@0/adc_tm@3400/emmc_ufs_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/ref_gnd: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/vref_1p25: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/die_temp: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/vph_pwr: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/vbat_sns: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/usb_in_i_uv: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/usb_in_v_div_16: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/chg_temp: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/bat_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/bat_therm_30k: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/bat_therm_400k: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/bat_id: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/i_parallel: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/v_i_int_ext: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/v_i_parallel: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/conn_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/vadc@3100/skin_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@2/adc_tm@3500/skin_therm: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@3/qcom,pwms@b300/lpg@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@3/qcom,pwms@b300/lpg@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,spmi@1c40000/qcom,pmi632@3/qcom,pwms@b300/lpg@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/tpdm@8a26000: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/tpdm@899c000: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/ad-hoc-bus: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/spi@4a80000/novatek@0/novatek-mp-criteria-720C@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/spi@4a80000/novatek@0/novatek-mp-criteria-720E@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/spi@4a80000/novatek@0/novatek-mp-criteria-720F@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/spi@4a80000/novatek@0/novatek-mp-criteria-7215@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,kgsl-3d0@5900000/qcom,gpu-cx-ipeak/qcom,gpu-cx-ipeak@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,kgsl-3d0@5900000/qcom,gpu-cx-ipeak/qcom,gpu-cx-ipeak@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,msm-audio-apr/qcom,q6core-audio/msm_cdc_pinctrl@18: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000/va_swr_master/wcd937x-tx-slave: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/rx-macro@a600000/rx_swr_master/wcd937x-rx-slave: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_dsi0_pll: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_td4330_truly_v2_cmd/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_td4330_truly_v2_cmd/qcom,mdss-dsi-display-timings/timing@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_td4330_truly_v2_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_td4330_truly_v2_video/qcom,mdss-dsi-display-timings/timing@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_nt36525_truly_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_r66451_hd_plus_90hz_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_r66451_hd_plus_90hz_cmd/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102_inx_fhd_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_sim_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_inx_fhd_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_txd_inx_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_hlt_auo_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_txd_auo_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_nt36523_lce_panda_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_nt36523_hlt_auo_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_txd_auo_al_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_lide_hsd_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_nt36523_lide_hsd_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_nt36523_txd_inx_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_ft8201ab_lide_hsd_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_tianma_tianma_al_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_hx83102e_djn_jdi_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_mdp/qcom,mdss_dsi_ft8201ab_tianma_tianma_video/qcom,mdss-dsi-display-timings/timing@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_rotator: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_dsi0_ctrl: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,mdss_dsi_phy0: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,csiphy0: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,csiphy1: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,csiphy2: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,cci0: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/msm_cdc_pinctrl@92: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/msm_cdc_pinctrl@106: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,wb-display@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,msm_notifier@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,camera-flash@0: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,camera-flash@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/qcom,camera-flash@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/sn_fuse: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /soc/sec_boot_fuse: node has a reg or ranges property, but no unit name
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@1/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@1/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@1/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@1/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@2/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@2/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@2/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@2/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@3/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@3/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@3/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@3/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@4/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@4/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@4/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@4/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@5: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@5/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@5/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@5/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@5/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@6: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@6/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@6/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@6/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@6/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@7: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@7/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@7/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@7/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@7/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@8: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@8/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@8/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@8/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@8/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@9: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@9/inputbooster,resource/resource@1: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@9/inputbooster,resource/resource@2: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@9/inputbooster,resource/resource@3: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_vs_reg): /input_booster/booster_key@9/inputbooster,resource/resource@4: node has a unit name, but no reg or ranges property
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/ssusb@4e00000/qcom,usbbam@0x04f04000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/ssusb@4e00000/qcom,usbbam@0x04f04000: unit name should not have leading 0s
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/kgsl-smmu@0x59a0000/gfx_0_tbu@0x59c5000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/apps-smmu@0xc600000/anoc_1_tbu@0xc785000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/apps-smmu@0xc600000/mm_rt_tbu@0xc789000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/apps-smmu@0xc600000/mm_nrt_tbu@0xc78d000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unit_address_format): /soc/apps-smmu@0xc600000/cdsp_tbu@0xc791000: unit name should not have leading "0x"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (pci_device_reg): Failed prerequisite 'reg_format'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (simple_bus_reg): Failed prerequisite 'reg_format'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l1@4000: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l1@4000: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l2@4100: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l2@4100: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l3@4200: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l3@4200: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l4@4300: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l4@4300: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l5@4400: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l5@4400: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l6@4400: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l6@4400: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l7@4400: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/i2c@4a84000/qcom,pm8008@9/qcom,pm8008-regulator/qcom,pm8008-l7@4400: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/lpi_pinctrl@ac40000: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/lpi_pinctrl@ac40000: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/rx-macro@a600000: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/rx-macro@a600000: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/tx-macro@a620000: Relying on default #address-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_default_addr_size): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/tx-macro@a620000: Relying on default #size-cells value
/home/honken/postmarketos/gta4l_extracted.dts: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size'
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/i2c@4a84000/wsa881x-i2c-codec@e: Missing property '#gpio-cells' in node /soc/qcom,msm-audio-apr/qcom,q6core-audio/msm_cdc_pinctrl@18 or bad phandle (referred from qcom,wsa-analog-clk-gpio[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/i2c@4a84000/wsa881x-i2c-codec@e: Missing property '#gpio-cells' in node /soc/msm_cdc_pinctrl@106 or bad phandle (referred from qcom,wsa-analog-reset-gpio[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/qcom,msm-audio-apr/qcom,q6core-audio/lpi_pinctrl@ac40000: Missing property '#gpio-cells' in node /soc/qcom,rpm-smd/rpm-regulator-ldoa17/regulator-l17 or bad phandle (referred from qcom,num-gpios[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000: Missing property '#gpio-cells' in node /soc/wake-gic or bad phandle (referred from qcom,is-used-swr-gpio[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/va-macro@a730000: Missing property '#gpio-cells' in node /soc/qcom,msm-audio-apr/qcom,q6core-audio/va_swr_clk_data_pinctrl or bad phandle (referred from qcom,va-swr-gpios[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/qcom,msm-audio-apr/qcom,q6core-audio/bolero-cdc/rx-macro@a600000: Missing property '#gpio-cells' in node /soc/qcom,msm-audio-apr/qcom,q6core-audio/rx_swr_clk_data_pinctrl or bad phandle (referred from qcom,rx-swr-gpios[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (gpios_property): /soc/qcom,msm-audio-apr/qcom,q6core-audio/sound: Missing property '#gpio-cells' in node /soc/msm_cdc_pinctrl_pri or bad phandle (referred from qcom,pri-mi2s-gpios[0])
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@2: graph node unit address error, expected "1"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@3: graph node unit address error, expected "2"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@4: graph node unit address error, expected "3"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@5: graph node unit address error, expected "4"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@6: graph node unit address error, expected "5"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@7: graph node unit address error, expected "6"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9800000/ports/port@8: graph node unit address error, expected "7"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@9832000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@9862000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@98c0000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@9810000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8a04000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8944000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8861000/ports/port@2: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8861000/ports/port@3: graph node unit address error, expected "1"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@2: graph node unit address error, expected "1"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@3: graph node unit address error, expected "5"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@4: graph node unit address error, expected "7"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@5: graph node unit address error, expected "8"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@6: graph node unit address error, expected "a"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@7: graph node unit address error, expected "c"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@8: graph node unit address error, expected "d"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tpda@8004000/ports/port@9: graph node unit address error, expected "f"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8005000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8005000/ports/port@2: graph node unit address error, expected "6"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8005000/ports/port@3: graph node unit address error, expected "5"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8005000/ports/port@4: graph node unit address error, expected "5"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8041000/ports/port@1: graph node unit address error, expected "5"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8041000/ports/port@2: graph node unit address error, expected "6"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8041000/ports/port@3: graph node unit address error, expected "7"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8042000/ports/port@5: graph node unit address error, expected "6"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8045000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/funnel@8045000/ports/port@2: graph node unit address error, expected "1"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/tmc@8047000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_port): /soc/replicator@8046000/ports/port@1: graph node unit address error, expected "0"
/home/honken/postmarketos/gta4l_extracted.dts: Warning (graph_child_address): Failed prerequisite 'graph_port'
┌[honken@Pratyush-PC] [/dev/pts/3] [main ⚡]
└[~/postmarketos]> ls
gta4l_extracted.dtb gta4l_extracted.dts
└[~/postmarketos-old]> ls ~/.local/var/pmbootstrap/cache_git/pmaports/device/testing/device-samsung-gta4l/
# Should contain:
# APKBUILD
# deviceinfo
APKBUILD deviceinfo modules-initfs
┌[honken@Pratyush-PC] [/dev/pts/1]
└[~/postmarketos-old]> cat ~/.local/var/pmbootstrap/cache_git/pmaports/device/testing/device-samsung-gta4l/deviceinfo ; cat ~/.local/var/pmbootstrap/cache_git/pmaports/device/testing/device-samsung-gta4l/APKBUILD
# Reference: <https://postmarketos.org/deviceinfo>
# Please use double quotes only. You can source this file in shell
# scripts.
deviceinfo_format_version="0"
deviceinfo_name="samsung Samsung Galaxy Tab A7"
deviceinfo_manufacturer="samsung"
deviceinfo_codename="samsung-gta4l"
deviceinfo_year="2020"
deviceinfo_dtb=""
deviceinfo_arch="aarch64"
# Device related
deviceinfo_chassis="tablet"
deviceinfo_external_storage="true"
# Bootloader related
deviceinfo_flash_method="fastboot"
deviceinfo_kernel_cmdline=""
deviceinfo_generate_bootimg="true"
deviceinfo_flash_pagesize="2048"
deviceinfo_bootimg_qcdt="false"
deviceinfo_dtb_second="false"
# Reference: <https://postmarketos.org/devicepkg>
maintainer=""
pkgname=device-samsung-gta4l
pkgdesc="samsung Samsung Galaxy Tab A7"
pkgver=1
pkgrel=0
url="https://postmarketos.org"
license="MIT"
arch="aarch64"
options="!check !archcheck"
depends="
linux-CHANGEME
mkbootimg
postmarketos-base
"
makedepends="devicepkg-dev"
source="
deviceinfo
modules-initfs
"
build() {
devicepkg_build $startdir $pkgname
}
package() {
devicepkg_package $startdir $pkgname
}
sha512sums="(run 'pmbootstrap checksum device-samsung-gta4l' to fill)"
We shall now get a look of the partition table
└[~/postmarketos]> fastboot getvar all
(bootloader) battery-part-status:unsupported
(bootloader) cpu-abi:arm64-v8a
(bootloader) super-partition-name:super
(bootloader) battery-voltage:4364
(bootloader) is-force-debuggable:no
(bootloader) treble-enabled:true
(bootloader) is-userspace:yes
(bootloader) max-fetch-size:0x10000000
(bootloader) partition-size:userdata:0x577C7BE00
(bootloader) partition-size:cache:0xC800000
(bootloader) partition-size:rpm:0x80000
(bootloader) partition-size:storsec:0x20000
(bootloader) partition-size:mdtp:0x2000000
(bootloader) partition-size:ssd:0x40000
(bootloader) partition-size:mmcblk0:0x747C00000
(bootloader) partition-size:recovery:0x62C0000
(bootloader) partition-size:misc:0x100000
(bootloader) partition-size:vbmeta:0x10000
(bootloader) partition-size:super:0x157000000
(bootloader) partition-size:metadata:0x1000000
(bootloader) partition-size:dtbo:0x1800000
(bootloader) partition-size:boot:0x6000000
(bootloader) partition-size:system:0x5F4C9000
(bootloader) partition-size:vendor:0x213F0000
(bootloader) partition-size:product:0x97757000
(bootloader) partition-size:odm:0x1A0000
(bootloader) version-vndk:
(bootloader) partition-type:userdata:raw
(bootloader) partition-type:cache:raw
(bootloader) partition-type:rpm:raw
(bootloader) partition-type:storsec:raw
(bootloader) partition-type:mdtp:raw
(bootloader) partition-type:ssd:raw
(bootloader) partition-type:mmcblk0:raw
(bootloader) partition-type:recovery:raw
(bootloader) partition-type:misc:raw
(bootloader) partition-type:vbmeta:raw
(bootloader) partition-type:super:raw
(bootloader) partition-type:metadata:raw
(bootloader) partition-type:dtbo:raw
(bootloader) partition-type:boot:raw
(bootloader) partition-type:system:raw
(bootloader) partition-type:vendor:raw
(bootloader) partition-type:product:raw
(bootloader) partition-type:odm:raw
(bootloader) battery-serial-number:unsupported
(bootloader) has-slot:userdata:no
(bootloader) has-slot:cache:no
(bootloader) has-slot:rpm:no
(bootloader) has-slot:storsec:no
(bootloader) has-slot:mdtp:no
(bootloader) has-slot:ssd:no
(bootloader) has-slot:mmcblk0:no
(bootloader) has-slot:recovery:no
(bootloader) has-slot:misc:no
(bootloader) has-slot:vbmeta:no
(bootloader) has-slot:super:no
(bootloader) has-slot:metadata:no
(bootloader) has-slot:dtbo:no
(bootloader) has-slot:boot:no
(bootloader) has-slot:system:no
(bootloader) has-slot:vendor:no
(bootloader) has-slot:product:no
(bootloader) has-slot:odm:no
(bootloader) security-patch-level:2026-07-01
(bootloader) vendor-fingerprint:samsung/gta4leea/gta4l:12/SP1A.210812.016/T505XXS8CXG1:user/release-keys
(bootloader) hw-revision:0
(bootloader) current-slot:
(bootloader) serialno:R9ZR502N5LJ
(bootloader) product:gta4l
(bootloader) version-os:16
(bootloader) first-api-level:29
(bootloader) slot-count:0
(bootloader) max-download-size:0x10000000
(bootloader) version:0.4
(bootloader) version-baseband:
(bootloader) is-logical:userdata:no
(bootloader) is-logical:cache:no
(bootloader) is-logical:rpm:no
(bootloader) is-logical:storsec:no
(bootloader) is-logical:mdtp:no
(bootloader) is-logical:ssd:no
(bootloader) is-logical:mmcblk0:no
(bootloader) is-logical:recovery:no
(bootloader) is-logical:misc:no
(bootloader) is-logical:vbmeta:no
(bootloader) is-logical:super:no
(bootloader) is-logical:metadata:no
(bootloader) is-logical:dtbo:no
(bootloader) is-logical:boot:no
(bootloader) is-logical:system:yes
(bootloader) is-logical:vendor:yes
(bootloader) is-logical:product:yes
(bootloader) is-logical:odm:yes
(bootloader) battery-soc:100
(bootloader) secure:yes
(bootloader) dynamic-partition:true
(bootloader) system-fingerprint:samsung/gta4leea/gta4l:12/SP1A.210812.016/T505XXS8CXG1:user/release-keys
(bootloader) version-bootloader:T505XXS8CXG1
(bootloader) unlocked:yes
all:
Finished. Total time: 0.278s
I’m not pasting the heimdall print-pit output, because its not viable here, but we will extract it and it will remain a good source of comparison
heimdall print-pit
Now we need to clone some important repos, for reference, the device tree from lineage and the android kernel common to the snapdragon 6115.
git clone https://github.com/LineageOS/android_device_samsung_gta4l
git clone https://github.com/LineageOS/android_kernel_samsung_sm6115
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git --depth=1 --no-checkout
# Also as this a work spanning across months, its reccommended to run "git pull" once a while to ensure we are working with the latest developments.
I would end the part-I with referencing fastboot, adb and heimdall sources, also providing some essential commands.
Official docs:
https://developer.android.com/tools/adb
Source:
https://android.googlesource.com/platform/packages/modules/adb
Official docs:
https://developer.android.com/tools/fastboot
Protocol spec:
https://android.googlesource.com/platform/system/core/+/refs/heads/main/fastboot/README.md
Fastbootd (userspace fastboot) specifically:
https://source.android.com/docs/core/architecture/bootloader/fastbootd
Official repo (Henrik Grimler's maintained fork):
https://gitlab.com/BenjaminDobell/Heimdall
reference:
https://gitlab.com/BenjaminDobell/Heimdall/-/blob/master/README.md
Flashing guide:
https://wiki.postmarketos.org/wiki/Flashing
Samsung specific:
https://wiki.postmarketos.org/wiki/Samsung_Galaxy_flashing
Samsung Odin protocol (Heimdall is its open implementation):
https://wiki.postmarketos.org/wiki/Odin
PIT file format:
https://wiki.postmarketos.org/wiki/Partition_Information_Table
Android protocol, runs from recovery (fastbootd) requires LineageOS recovery to be present, Samsung removes it from their vendor distributed/ stock ROM Fastboot operations-(top choice)
fastboot getvar all # reading partition table
fastboot flash boot boot.img # flashing boot image
fastboot flash recovery recovery.img # flashing recovery image
fastboot devices # device detection
fastboot reboot
fastboot reboot recovery
fastboot reboot bootloader # reboots to download mode
fastboot get_staged dtbo.img # needs inquiry from my end
fastboot flash --read dtbo.img # needs inquiry
Fastboot doesn’t support reading partitions(This oeration is like extracting images and not to be confused with reading partition table, which gives the info of disk structure)
Heimdall is reverse engineered based on Samsung’s Odin protocol, Download mode, always available at hardware level, independent of installed OS Heimdall operations
# Needs to be in download mode, or else heimdall operations don't work.
heimdall print-pit # print partition-table
heimdall flash --BOOT boot.img # flash boot partition
heimdall flash --RECOVERY recovery.img # recovery partition
heimdall download --BOOT lineage_boot.img # extracting a partition
heimdall download --DTBO dtbo.img # reading dtb partition, heimdall cannot extract dtb from a live running kernel, only adb can do so
heimdall detect # detect devices
Android Debug Bridge, normal boot or recovery requires USB debugging enabled or recovery ADB
adb root
adb pull /dev/block/by-name/boot lineage_boot.img
# adb with su
adb shell su -c "dd if=/dev/block/by-name/boot of=/sdcard/boot.img"
adb pull /sdcard/boot.img lineage_boot.img
# extracting dtb fom live running kernel
adb pull /sys/firmware/fdt gta4l_extracted.dtb
# ADB with root
adb shell su -c "dd if=/dev/block/by-name/DTBO of=/sdcard/dtbo.img"
adb pull /sdcard/dtbo.img .
adb devices # device detection
With this we have setup the toolchain required, and this will mark the end of Part-I from my end. I’m planning to actually write next on the detection of board configuration from the gta4l tree. Then gather more sources on dts writing conventions of android and linux. After that we will start writing the dts file for mainline linux kernel, for which we will consider a reference device listed on linus branch, as there are devices that make use of 6115.dts
My idea is to divide the components or peripherals in a hierarchy/priority p1.Critical-like ufs storage, serial console and usb p2.usability-touchscreen, display, power keys,.. p3.connectivity-wifi,bluetooth,modem,.. p4.supporting cast-regulators,cast,..
Well its already too long,I shall close it here.
Thankyou !
]]>Eventually I ditched NixOS and distrohopped a lot, in this process I grasped some of the Linux specific concepts, along with multitudes of applications that bundled with the Linux kernel to make it usable as a distribution. So I adopted a hybrid approach, using Nix in Gentoo ! The fact being all the system level packages being installed by portage via Gentoo repo and user level applications via Nixpkgs. This let me access nix shell, nix build and nix develop, but also the tradeoff being loosing the Nixos generation rollbacks and a good level of declarativity that was only possible in NixOS. But the plus point being gaining access to the FHS again. For the very fact I switched from Openrc to systemd to gain more of nix automation of declaring daemons, as nix being tightly coupled with systemd as an init system.
For a multi user installation, it is important for every user to have access to a main nix conf which is situated in /etc/nix/nix.conf , further user level changes can be invoked in ~/.config/nix for a single user. Also nix never gives a user permit to build nixpkgs or a better term would be nix derivations. It is handled by nix builders, the number of nix builders can be defined in nix.conf to tightly couple it with available cpu cores, or else the default builders remain 8 in number. Unlike Gentoo’s portage whose historial behaviour has been compiling from source, nix uses cachix to rather install nixpkgs via cache.nixos.org .
Well a very important distinction is to separate the fact that rather than treating nix as a package manager it is foremost a buil system in my opinion, and thus nix doesn’t really have a concept of package distribution via repositories. Rather the conventional method is to use nix channels and define one of either the current release of NixOS or the unstable one. For users who choose to proceed via flakes (has been experimental since a decade, but around 70%(rough estimate, source: trust me bro!) of users utilise this feature), which introduces a great concept of lock file along with flake registry to decide the input and output. The lock file makes reproducibility pinned via version locking with the help of flake.lock (auto generated via flake.nix, and must be treated as a readonly file.), well this was inspired by Rust’s cargo , and the way it pinned versions of crates in a toml file.
The nix.conf file I use in my system.
build-users-group = nixbld
experimental-features = nix-command flakes
max-jobs = auto # use all cores for parallel builds
cores = 0 # 0 = use all cores per job
#build-dir = /tmp/nix-build # build on tmpfs if you have RAM to spare
builders-use-substitutes = true
min-free = 1073741824 # trigger GC when < 1GB free (in bytes)
max-free = 5368709120 # stop GC when 5GB is free
auto-optimise-store = true # hardlink identical files in store
sandbox = true
sandbox-fallback = false # don't silently disable sandbox on failure
extra-sandbox-paths = /etc/ssl/certs /etc/resolv.conf # network builds need these
allow-import-from-derivation = false # stricter, catches impure eval patterns
pure-eval = false # set true per-command if you want strictness
restrict-eval = false
log-lines = 50 # show more context on build failure
show-trace = true # full eval trace on errors (very useful)
keep-outputs = true # keep build deps (useful for dev shells)
keep-derivations = true # keep .drv files for debugging
ssl-cert-file = /etc/ssl/certs/ca-certificates.crt
But this file just cannot handle every nix feature, the ni ecosystem has to offer. Sure this is enough to invoke and install packages via the traditional method of nix-env -iA
In my system I prefer to define both the flake registry and home-manager file in a single directory, which is ~/.config/home-manager, though it can be defined in any directory the user decides to.
My complete flake registry
{
description = "Home Manager configuration of Pratyush";
inputs = {
# Specify the source of Home Manager and Nixpkgs.
nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
home-manager = {
url = "github:nix-community/home-manager";
inputs.nixpkgs.follows = "nixpkgs";
};
nixgl = {
url = "github:nix-community/nixGL";
inputs.nixpkgs.follows = "nixpkgs";
};
nur = {
url = "github:nix-community/NUR";
inputs.nixpkgs.follows = "nixpkgs";
};
caelestia-shell = {
url = "github:caelestia-dots/shell";
inputs.nixpkgs.follows = "nixpkgs";
};
};
outputs =
inputs@{ nixpkgs, home-manager, nixgl, nur, caelestia-shell, ... }:
let
pkgs = import nixpkgs {
system = "x86_64-linux";
#pkgs = nixpkgs.legacyPackages.${system};
overlays = [ nixgl.overlay ];
};
in
{
homeConfigurations.honken = home-manager.lib.homeManagerConfiguration {
inherit pkgs;
# Specify your home configuration modules here, for example,
# the path to your home.nix.
modules = [ ./home.nix ];
extraSpecialArgs = { inherit inputs; };
};
};
}
One of the special inputs thats defined here is it defines unstable channel as the nixpkg input source. The home manager module and NUR(nix user repository), and nixgl. The biggest caveat most of the standalone nix users face is that cli applications run flawlessly like any native package, but the gui applications abort due to non availability of openGL related sources, that are utilised via shared libs in a traditional distriubution.Since every nixpkg is isolated in /nix, there isn’t a streamlined way to share them among each other in the nix sandboxed environment, without creating a flake that defines a particular environment. The NixGL project works as a wrapper to this gui applications to let the nixpkgs access the graphics driver of the system. This can be defined as a generic graphics driver or particularly for Intel via the mesa-opengl, nvidia and even AMD.
More info here: https://github.com/nix-community/nixgl
In a nix shell, the wrapper can be passed along with a gui application say xyz, in the form of nixGL xyz (For applications utilising openGL) or nixVulkan xyz (for modern applications utilising vulkan).
But the issue being home manager being declarative, and usually doesn’t allow direct bindings as such, thus it requires a wrapper script be defined.
{ config, pkgs, inputs,... }:
let
nixGLWrap = pkg: pkgs.runCommand "${pkg.name}-nixgl" {} ''
mkdir -p $out/bin $out/share/applications
for bin in ${pkg}/bin/*; do
binname=$(basename $bin)
cat > $out/bin/$binname << EOF
#!/bin/sh
exec ${pkgs.nixgl.nixGLIntel}/bin/nixGLIntel $bin "\$@"
EOF
chmod +x $out/bin/$binname
done
if [ -d ${pkg}/share/applications ]; then
for d in ${pkg}/share/applications/*.desktop; do
sed "s|Exec=${pkg}/bin/|Exec=$out/bin/|g" $d \
> $out/share/applications/$(basename $d)
done
fi
'';
in
{
home.username = "honken";
home.homeDirectory = "/home/honken";
home.stateVersion = "26.05";
nixpkgs.config.allowUnfree = true;
home.packages = with pkgs; [
ripgrep
fd
btop
htop
thunderbird
(nixGLWrap librepods)
gimp
opencode
weechat
aria2
elinks
dconf
qutebrowser
yt-dlp
gallery-dl
(nixGLWrap brave)
alpaca
blanket
libreoffice
(nixGLWrap jellyfin-desktop)
baobab
showtime
decibels
(nixGLWrap chromium)
proton-pass
gnome-firmware
gnome-calendar
gnome-clocks
gnome-system-monitor
gnome-weather
(nixGLWrap sushi)
(nixGLWrap obs-studio)
(nixGLWrap vlc)
gowall
# fdroidserver
android-studio
halloy
];
# Git
programs.git = {
enable = true;
settings.user = {
name = "Pratyush";
email = "nandipratyush1917@gmail.com";
};
};
# Shell
programs.zsh = {
enable = true;
autosuggestion.enable = true;
syntaxHighlighting.enable = true;
oh-my-zsh = {
enable = true;
plugins = [ "git" "docker" ];
theme = "darkblood";
};
};
# Enable fzf and automatically hook it into Zsh
programs.fzf = {
enable = true;
enableZshIntegration = true;
};
wayland.windowManager.sway = {
systemd.enable = true;
xwayland = true;
};
programs.home-manager.enable = true;
targets.genericLinux.enable = true;
xdg.enable = true;
xdg.mime.enable = true;
targets.genericLinux.gpu.enable = true;
targets.genericLinux.nixGL.defaultWrapper = "mesa";
targets.genericLinux.nixGL.vulkan.enable = true;
systemd.user.sessionVariables = config.home.sessionVariables;
# For electron apps to use wayland server instead of xwayland
home.sessionVariables = {
NIXOS_OZONE_WL = "1";
};
qt.enable = true;
gtk.enable = true;
}
To apply changes
home-manager switch --flake ~/.config/home-manager#honken
The standard command is “home-manager switch –flake <directory name(can be relative or absolute)>#
┌[honken@Pratyush-PC] [/dev/pts/3]
└[~]> home-manager switch --flake ~/.config/home-manager#honken
warning: Git tree '/home/honken/.config/home-manager' is dirty
evaluation warning: 'system' has been renamed to/replaced by 'stdenv.hostPlatform.system'
Starting Home Manager activation
Activating checkExistingGpuDrivers
GPU drivers require an update, run
sudo /nix/store/cpj89f3jpz68dg8yrj89qgf2k2jr4mli-non-nixos-gpu/bin/non-nixos-gpu-setup
Activating checkFilesChanged
Activating checkLinkTargets
Please do one of the following:
- In standalone mode, use 'home-manager switch -b backup' to back up files automatically.
- When used as a NixOS or nix-darwin module, set either
- 'home-manager.backupFileExtension', or
- 'home-manager.backupCommand',
to move the file to a new location in the same directory, or run a custom command.
- Set 'force = true' on the related file options to forcefully overwrite the files below. eg. 'xdg.configFile."mimeapps.list".force = true'
Existing file '/home/honken/.config/user-dirs.dirs' would be clobbered
┌[honken@Pratyush-PC] [/dev/pts/3] [1]
└[~]> sudo /nix/store/cpj89f3jpz68dg8yrj89qgf2k2jr4mli-non-nixos-gpu/bin/non-nixos-gpu-setup
As a particular note, unlike NixOS, on non-nixos systems it cannot replicate system level fuctionalities, because other users cannot access the nixpkgs installed by another user, which is a part of nix security framework. Though every package resides in /nix, these are hashed, alongwith the fact that in NixOS, /etc is just a symlink to a file in defined in the nix store. Therefore it limits functionalities like a full fledged desktop environment or running systemd service via elevated privileges.
A rather common example is ssl/tls cert error. In my Gentoo system, after a long time update, ssl and tls certs need manual update,as it gives choices to preserve either the old certs, merge them or completely discard them. A better way of dealing with such errors are:
An example error -
└[~]> nix shell nixpkgs#mpv
warning: unable to download 'https://channels.nixos.org/flake-registry.json': Problem with the SSL CA cert (path? access rights?) (77) error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt; using cached version
error:
… while fetching the input 'https://channels.nixos.org/nixpkgs-unstable/nixexprs.tar.xz'
error: Failed to open archive (Source threw exception: error: unable to download 'https://channels.nixos.org/nixpkgs-unstable/nixexprs.tar.xz': Problem with the SSL CA cert (path? access rights?) (77) error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt).
To resolve this:
[honken@Pratyush-PC] [/dev/pts/0]
└[~]> ls -la /etc/ssl/certs/ca-certificates.crt
wc -l /etc/ssl/certs/ca-certificates.crt
-rw-r--r-- 1 root root 0 Jul 26 15:44 /etc/ssl/certs/ca-certificates.crt
0 /etc/ssl/certs/ca-certificates.crt
┌[honken@Pratyush-PC] [/dev/pts/0]
└[~]> equery list ca-certificates
* Searching for ca-certificates ...
[IP-] [ ] app-misc/ca-certificates-20260223.3.112.4-r1:0
┌[honken@Pratyush-PC] [/dev/pts/0]
└[~]> stat /etc/ssl/certs/ca-certificates.crt
File: /etc/ssl/certs/ca-certificates.crt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 0,37 Inode: 33467139 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-07-11 21:49:58.032469032 +0530
Modify: 2026-07-26 15:44:46.262194686 +0530
Change: 2026-07-26 15:44:46.262194686 +0530
Birth: 2026-07-11 21:49:58.032469032 +0530
┌[honken@Pratyush-PC] [/dev/pts/0]
└[~]> curl -v https://channels.nixos.org/flake-registry.json -o /dev/null
* Host channels.nixos.org:443 was resolved.
* IPv6: 2a04:4e42:25::347
* IPv4: 151.101.209.91
* HTTPS-RR: 0 .
* Trying [2a04:4e42:25::347]:443...
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [1564 bytes data]
* SSL Trust Anchors:
* error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt
* SSL Trust Anchors:
* error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt
* closing connection #0
curl: (77) error adding trust anchors from file: /etc/ssl/certs/ca-certificates.crt
In gentoo linux, the upstream solution is to update ca-certificates manually or use dispatch-conf to edit changes in /etc . In general dispatch-conf method is bound to fail here as these certificates are distriburted by Mozilla. So to check if the certs are actually installed
ls /usr/share/ca-certificates/mozilla/ | wc -l
If the above number is non-zero that means the certs exist, and are available for the system.
sudo update-ca-certificates
Then the existence and working can be verified via
[~]> wc -l /etc/ssl/certs/ca-certificates.crt
curl -sI https://channels.nixos.org/flake-registry.json
3532 /etc/ssl/certs/ca-certificates.crt
HTTP/2 200
cache-control: max-age=300
content-security-policy: default-src 'none'; style-src 'unsafe-inline'; sandbox
content-type: text/plain; charset=utf-8
etag: "1aafb6e6c07c1dd62e0e90683d9a5b9ac410cb9628e1cca8f4c8fd275e48e875"
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
x-frame-options: deny
x-xss-protection: 1; mode=block
x-github-request-id: 16E6:261A5D:2A575D:6C7756:6A65FBBD
via: 1.1 varnish, 1.1 varnish
x-timer: S1785068479.888953,VS0,VE216
cross-origin-resource-policy: cross-origin
x-fastly-request-id: d951300431378566cb74e4bebad996b6f8698dee
expires: Sun, 26 Jul 2026 12:26:19 GMT
source-age: 0
access-control-allow-origin: *
accept-ranges: bytes
age: 0
date: Sun, 26 Jul 2026 12:21:19 GMT
x-served-by: cache-bom-vanm7210037-BOM, cache-bom-vanm7210051-BOM
x-cache: MISS, MISS
x-cache-hits: 0, 0
vary: Authorization,Accept-Encoding
content-length: 9653
Thankyou !
]]>well currently Im going to document porting guides and system level optimisations for gentoo along with scripts I use with nix package manager.Which includes compiler optimisations via llvm/clang and using GCC as fallback if aggressive optimisations alongwith other linkers break package compilation.
Porting guides include the porting of my galaxy tablet A7 to derfest(a popular custom ROM) and most importantly my work on progress of porting it to postmarketOS running via mainline kernel, which drastically differs from running via downstream kernel.
My Interests lie towards systems programming honestly, tho currently Im learning it on my own, but you may check out my review papers and the respective source codes of the simulators and programs Ive used for demonstration.
Thankyou !
]]>