Conversation
Edited 4 months ago
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
6
5
2
@longnoserob fair point, excluding memory regions for TrustZone etc wouldn't hurt either blobcatblep
0
0
0

์ง€์ง€ แš ื“ (Jiji Freya Daniel) ๐Ÿขโœจ๐Ÿงก

@elly if you're a bit unlucky, you may need to deal with power management right away already ๐Ÿ˜ฌ

0
0
1

@elly Its less about the kernels being useful, and more about onboarding. Some people may not know anything about kernel hacking, and downstream kernels give a relatively easy way to get at least something working immediately. This can then springboard into the contributor wanting to keep working and transition to mainline development. The only issue is how to facilitate that transition without asking them to get a master's degree before doing anything.

1
0
0

@justsoup @elly surely also it depends on what you want to do with the device. If your use case is e.g telephoning people, or taking photos, downstream kernels on most devices are more likely to give you that sooner even if they can't run gnome or whatever

0
0
1

@elly while not immediately required watchdog should be high on the list of what to support unless it is or can be disabled in the boot loader. very frustrating to have a device which boots but resets after X seconds.

0
0
1

@elly elly you should have a blog. or wiki. or osmething

1
0
1
@domi @elly
she should write a book on the stuff she knows and call it "the chymical wedding of Segfault Dominisha"
1
0
0
@moses_izumi @domi I've been procrastinating making a blog for 5 years throwing-hands-up-crying

Deploying nginx, getting familiar with hugo (and picking a theme, so many options...) or writing something by hand, protecting against LLM scraping these days just sounds like a lot of work
3
0
1
@elly @moses_izumi @domi even after all of that, you have to sit down and write the posts, which is even harder
1
0
0

@elly

> You more-or-less need the following to get into initramfs:

oh hey, fun, i was *just* testing that with an old ARMv6 SoC! the list is:

- CPU node
- Memory node (which on these old devices can be pulled from atags anyways)
- UART (earlyprintk ftw)
- Timer (clocksource, sched_clock and clockevents - otherwise it hangs on "Calibrating delay loop..." unless you pass lpj= to cmdline
- ...and that's it!

0
0
0
@weirdtreething @domi @elly
I'd consider publishing anything that resembles a guide/tutorial onto some existing public GIT forge.

It's what @zen did with his "Bootloader Unlock Hall of Shame" (one of the better Android resources out there)
2
0
0

@moses_izumi @domi @elly @weirdtreething i'm sorry, can you please stop tagging me in every mention of the wiki ๐Ÿ˜ญ i haven't been involved with it for a hot minute (a year atp?)

0
0
0

@moses_izumi @domi @elly @weirdtreething @zen Second this, a versionned markdown collection is even better than a website to me in many ways
Maybe my grandmother would have trouble browisng it, but I don't think she's your target audience

0
0
0
@elly @domi @moses_izumi don't you get it? the fedi is the website? :p
0
0
1

@elly @domi @moses_izumi I'd be happy to host a small static site if desired.

1
0
0
@justin @domi @moses_izumi hosting isn't a problem, actually finding time and motivation to sit down and deploy everything around it certainly is
1
0
0