Conversation

Replying to

and

I don't think we had a commit fixing it for the non-XL variant but I remember it being an issue. It's probably a similar issue. In my experience, both in-tree and out-of-tree Linux kernel driver modules are often broken when built into the kernel instead of dynamically loaded.

1

2

Replying to

and

It's easier to build them into the kernel than dealing with building modules and putting them in vendor. For GrapheneOS we can't even do that as a workaround for issues like this because we want dynamic kernel modules disabled. Easiest solution is probably dynamically loading it.

1

1

Replying to

and

this rings any bells?

1

1

Replying to

and

I think your best bet to figure out if this is the issue is disabling the module in your kernel build and disabling the sanity checks for kernel module loading so that the init scripts in vendor can successfully load the stock OS build of the HTC battery module from there.

1

2

Replying to

and

It's entirely possible to build it as a dynamic kernel module and include it in vendor, but it's easier to build it into the kernel which is why most aftermarket OS builds take that approach. Stock OS uses dynamic modules to optimize loading time and make kernels more generic.

1

1

Replying to

and

It's a recurring issue that we deal with across a bunch of drivers. The drivers only work if their firmware and configuration files are usable when they're initialized and they often assume that those are available when they're loaded. If built into the kernel, they're broken.

2

4

Replying to

and

this... requires enough effort that I might just live with partially broken charging. especially given that I still haven't fixed the problem with the USB3 pairs in the connector that makes `adb sideload` very hard to use

1

1

Replying to

and

Based on that error message, I'm fairly certain that the battery driver or battery is the issue though. If you look at drivers/power/htc_battery.c, you can see it's involved in negotiating the charging rate. Since there's thermal throttling, etc. batteries are very involved.

2

2

Replying to

and

honestly I just find the normal part of the AOSP build system bad enough, the thought of doing something with the kernel instills dread

1

6

Replying to

and

(it's the LineageOS kernel build integration, I have absolutely no idea how it works)

1

1

Replying to

and

We use the AOSP way of building it separately and including it in the AOSP build as a prebuilt. Qualcomm has always included a way to run the kernel build in-tree via a wrapper in each kernel source tree as a hack for development. LineageOS turned that into a generic system.

6:13 AM · Jan 23, 2021Twitter Web App

Replying to

and

I like that it exists. I want to build LineageOS and I don't want to build the kernel. well, I normally don't. when I do, like here, it causes issues...

1

3

Replying to

and

The LineageOS approach means that you're probably building the kernel as part of building the rest of the OS as opposed to AOSP where you would be using a prebuilt unless you decide to build the kernel before building the rest of the OS.

3

Replying to

and

I don't like running a totally separate build system within the AOSP build system. It takes a ridiculous amount of time and memory to link the Linux kernel with full LTO and it doesn't use kati so it doesn't handle incremental builds well so I really prefer the AOSP approach.

1

4

Replying to

and

Why LTO? Does it have extended hardening properties or is it just 3% optimizing non-bottlenecks?

2

Show replies