Post #1816265

This might be a hot take, but I will never understand why people new to hacking on mobile/embedded devices insist on trying to use vendor-provided sources. Even if you get a kernel source from $vendor (which is not a given, welcome to the magical land of GPL violation) you will run into numerous issues even trying to compile it, only to end up with a pile of legacy crap that will never* work correctly with upstream userspace (unless you resort to using Ubuntu Touch or Droidian, which AFAIK use halium and can use Android HALs). Seriously, if you're new to this and want to learn how to do it *properly* on a completely unsupported SoC, you should: 1. Dump downstream devicetree from running device. It's much easier to understand than vendor sources once you understand how it works: `dtc -I dtb /sys/firmware/fdt -O dts > /storage/emulated/0/Downloads/dumped.dts` (and pull it using adb). 2. Locate UART pins on your device (beware that most ARM SoCs use 1.8V or under) and what's the address for that (for example on MT6789/MT8781 it's `0x11002000`). Using simple-framebuffer is a last resort but you really want functional UART for early bringup. 3. Write initial upstream devicetree and minimal driver set. You more-or-less need the following to get into initramfs: - Clocks - Core cluster definition (in DT) - Possibly reserved-memory (memory regions that shouldn't be used, often used by modem/wifi, gpu, remoteprocs etc) - Interrupt Controller (usually ARM GICv3 unless it's Apple, then AIC) - Pinctrl - UART *(Hopefully not forgetting about anything?)* 4. Go from there (drivers for interconnect, i2c/spi etc). Using kernel trees for the same SoC (even if it's a different vendor) is a protip, it's all $soc_vendor's BSP after all. Or if you're in really deep, throwing kernel modules at ghidra is also an option :akko_shrug: