Helpful Kirin AOSP development cheat sheet

kirin-aosp-helper.md

Kirin AOSP helper

A helpful cheat sheet for people interested in Huawei Kirin AOSP development
This thing is WIP right now, so please have some patience, thank you!

• Important things to know
• The Partition table
• Basic bringup

Important things to know

• You have to be aware of that all EMUI versions are pretty different in almost all things (kernel, blobs, partition table, dtbs, etc.). Huawei OTAs are also resizing the ptable, so because of that, for example, all EMUI 8 devices (launched or upgraded) got Treble support (In fact EMUI 5 had a vendor partition already but that was smaller than on EMUI 8).
• Huawei likes to "backport" features which aren't even existing on AOSP yet, there are alot of good examples: vendor partition on EMUI 5 (on AOSP since Android 8.0), odm partition on EMUI 8/9 (on AOSP since Android 10), AVB2 with vbmeta partitions (disabled until EMUI 10) on EMUI 8 (on AOSP since Android 9), (pretty unrelated to development but why not) fullscreen gestures on EMUI 8.2(?) and 9.x (on AOSP since Android 10) and way way more things.
• Try to get the latest and most fully functional (!!!) kernel source you can get for your platform, here are some examples: Hi6250 EMUI 5.0: Prague, Hi6250 EMUI 5.1: RNE (RNE has broken tzdriver, port from PRA-5; BND one has broken OMX for some reason), Hi6250 EMUI 8: AGS2 (working calls on recent PRA/WAS firmware with jan 2021 secpatch; broken wifi drivers, port from FIGO-8 or LELAND-8), Hi6250 EMUI 9: AGS2 HarmonyOS 2.0.0 (from November 2021, working fine with ANNE's 9.1.0.401 firmware, aka. Jan 2022 secpatch).
• Unfortunately, we can't reproduce the DTS.img yet, which has the DTBs. This means, we can't change stuff in the kernel device tree, which might be pretty pain in some cases, for example we need hacks like this to kill the device tree fstab which is fucked up anyways, specially on EMUI 8. For more infos about DTS.img, I will do a research repository, which I will link here once it's done.
• Huawei is known to update the kernel version with new Android releases (EMUI 4 uses 3.10, EMUI 5 4.1, EMUI 8 4.4, EMUI 9 4.9, EMUI 10 and newer 4.14). Just slapping EMUI x kernel on EMUI y doesn't work sadly, this requires to use their blobs, and most important, you need the EMUI x's dtbs, meanwhile you can't use EMUI x's DTS.img on EMUI y due to a "different format" (the bootloader rejects it), reproducing DTS.img isn't an option yet, or if you are "pro enough" and you have alot of time to waste and you want to go through the pain, you can either adapt the complaining drivers for EMUI y's dtbs, or the port EMUI y's drivers to EMUI x's kernel. But thats only for big pros, I would say.
• If you need kernel logs because your kernel doesn't work then you only have 1 option: pstore. Pstore is already enabled in the kernel and you will always get one as long as the kernel actually works. Last_kmsg doesn't exist (qcom noises). Sometimes, there might be useful logs in /splash2 partition for alot of things. If that isn't enough, and you need bootloader logs, you can check /proc/balong/log. It gives you the current and last bootloader log.
• Good to know about the fastboot mode, there are 2 types of unlock. User unlock which you can unlock using fastboot oem unlock 1234567890ABCDEF, it always you flash some basic partitions + unsigned images (non stock). Then theres factory unlock / fblock, (only applies to devices older than EMUI 8.x, sometimes EMUI 9.x too) which can be triggered by fastboot oem hwdog certify set 0 on fully unlocked board firmware fastboots, or also using the nvme tool by @R0rt1z2. The unlock "flag" is basically in the nvme partition. As the name tells you already, It allows you to do everything in fastboot.

The Partition table

Now we gonna look at some huawei partitions. First important side note

• EMUI 5 and older uses regular boot.img and recovery(2).img, since EMUI 8 they are splitted up into kernel, ramdisk (only 8, 10 and newer), (e)recovery_ramdisk and (e)recovery_vendor. Those images are basically regular bootimages with either kernel+cmdline, real offsets (which the bootloader cares about!!!!) and no ramdisk or a normal bootimage with ramdisk, the "default" offsets (they dont matter) and dummy kernel+cmdline. Those splitups are resolved on both EMUI 8 and EMUI 9 platform using a custom mkbootimg makefile. The "HW_MKBOOTIMG" is a edited mkbootimg by huawei which is in the kernel source to reproduce the 100% same offsets for the kernel.img. Now I'm going to list some partitions on huawei devices:
• xloader: part of the bootloader, erase in fastboot to get into USB SER (IDT/Testpoint) mode.
• fastboot: the main part of the bootloader, DO NOT ERASE IT OR FLASH ONE WHICH DOESNT MATCH WITH THE XLOADER, ELSE YOUR DEVICE WILL BRICK AND ONLY TESTPOINTING WILL SAVE YOU!!!
• fw_lpm3, fw_hifi, sensorhub: firmware
• teeos, trustfirmware, sec_storage: TEE
• splash2: logs
• cust, version: EMUI parts (unused on AOSP)
• product: contains EMUI parts and on EMUI 5 also device specific configs etc., this will be fun when doing Pie and newer..., partition too small for AOSP product, can just be dropped on EMUI 8 and newer.
• odm (EMUI 8 and newer): contains device specific configs, instead in product like on EMUI 5, can be built from src.
• preas (EMUI 8 and newer): contains Google apps on EU firmware and some launcher stuff (gets mounted by dt fstab)
• preavs (EMUI 8 and newer): contains the widevine hal (move it to vendor, gets mounted by dt fstab)
• preload (EMUI 9 and newer): preinstalled apps I guess, mounted by dt fstab.
• nvme: contains device infos like SN, macs, unlock code, etc. DO NOT TOUCH!!
• oeminfo: contains device model and region, on newer phones (k970) also stuff from nvme and imeis, DON'T TOUCH!!!
• modem_fw, modemnvm_update: modem firmware
• modemnvm_*: contains your imei and other ril related stuff, DO NOT TOUCH!!!

Basic bringup

Hello good sir! I recently was given a huawei mate 9 kirin960. Ive been installing native linux on it. It boots to desktop (framebuffer) One of the big issues Ive had is of course the bootloader/dts partition. Im keeping the android at 7, for a bunch of reasons. I am able to make a bootable dts partition using the dtbTool in the tools folder from the opensource release. But the bootloader likes to mangle it in weird and varying ways. I didnt know if you had more luck or possibly any open source tools for the dts generation. Its tempting when using the dtbTool to point it to the dtc in the kernel source folder (and indeed errors less) but it doesnt support -@ so at best you will get fastboot to work but linux/android will die quickly in. To create a working one;
ill use binwalk -e to extract the ripped partition
binwalk -e partition.img

add .dtb to each file
for i in srcs/*; do mv $i $i.dtb ; done

de-compile them;
for i in srcs/*; do dtc -@ -I dtb -O dts -o $i.dts $i ; done

make my changes then recompile them
for i in srcs/*; do dtc -@ -I dts -O dtb -o $i.dtb $i ; done

Now use the closed source tool to make the image,
../open-source-release/kernel/tools/dtbTool -o new-dts.img srcs/

For reasons I havent looked into, the dtbTool needs to stay in its kernel source directory, It also looks for and fails to find .vrl files for the dtb's. No idea what that is. So far you have been the best and only resource for development on this device. My current fear is that without access to being able to upload custom Tee apps, Ill be without a lot of needed things. My very very limited experience with trustzone stuff has been absolutely no access to devices connected to it any other way except thru trustzone, yet the kernel sources for sum of these devices have ifdef's for if trustzone is disabled, so possibly I may have access to the required IO on some of those devices? To be more clear it seems slightly possible that trustzone is optional on some sensors etc? Have you seen that? Any ideas on what hardware definitely wont work without it? Id love to get the root signing key and replace bootloader with hikey960's but looking less possible everyday. I have a kernel Ive been backporting kexec too (android 7 release kernel 4.1 uhg) It currently dies at the software reboot, I believe its a cpu spin issue will try with only one core enabled later today. With that I can use it as a bootloader and swap out the kernel and dtb correctly. Ive also looked at little at the atcmdserver which seems like a goldmine for extracting hidden resources, but haven't gotten very far. The other thing Im curious about is the options for fastboot that live in device tree. Not entirely sure how safe it is to play with those on the off chance it sets efuses based of those options or not. Do you have any understanding of those options? The last question I have is during boot it says efuse = 0. Years ago I had a phone that said something similar and it meant the brom had not been fused to read only and could be replaced, seems unlikely to be the same here but thought id ask. Thank you very much for the write up! Very awesome, lots of great info, and written better/more clear then I could ever hope to do!

Hello good sir! I recently was given a huawei mate 9 kirin960. Ive been installing native linux on it. It boots to desktop (framebuffer) One of the big issues Ive had is of course the bootloader/dts partition. Im keeping the android at 7, for a bunch of reasons. I am able to make a bootable dts partition using the dtbTool in the tools folder from the opensource release. But the bootloader likes to mangle it in weird and varying ways. I didnt know if you had more luck or possibly any open source tools for the dts generation. Its tempting when using the dtbTool to point it to the dtc in the kernel source folder (and indeed errors less) but it doesnt support -@ so at best you will get fastboot to work but linux/android will die quickly in. To create a working one; ill use binwalk -e to extract the ripped partition binwalk -e partition.img

add .dtb to each file for i in srcs/*; do mv $i $i.dtb ; done

de-compile them; for i in srcs/*; do dtc -@ -I dtb -O dts -o $i.dts $i ; done

make my changes then recompile them for i in srcs/*; do dtc -@ -I dts -O dtb -o $i.dtb $i ; done

Now use the closed source tool to make the image, ../open-source-release/kernel/tools/dtbTool -o new-dts.img srcs/

For reasons I havent looked into, the dtbTool needs to stay in its kernel source directory, It also looks for and fails to find .vrl files for the dtb's. No idea what that is. So far you have been the best and only resource for development on this device. My current fear is that without access to being able to upload custom Tee apps, Ill be without a lot of needed things. My very very limited experience with trustzone stuff has been absolutely no access to devices connected to it any other way except thru trustzone, yet the kernel sources for sum of these devices have ifdef's for if trustzone is disabled, so possibly I may have access to the required IO on some of those devices? To be more clear it seems slightly possible that trustzone is optional on some sensors etc? Have you seen that? Any ideas on what hardware definitely wont work without it? Id love to get the root signing key and replace bootloader with hikey960's but looking less possible everyday. I have a kernel Ive been backporting kexec too (android 7 release kernel 4.1 uhg) It currently dies at the software reboot, I believe its a cpu spin issue will try with only one core enabled later today. With that I can use it as a bootloader and swap out the kernel and dtb correctly. Ive also looked at little at the atcmdserver which seems like a goldmine for extracting hidden resources, but haven't gotten very far. The other thing Im curious about is the options for fastboot that live in device tree. Not entirely sure how safe it is to play with those on the off chance it sets efuses based of those options or not. Do you have any understanding of those options? The last question I have is during boot it says efuse = 0. Years ago I had a phone that said something similar and it meant the brom had not been fused to read only and could be replaced, seems unlikely to be the same here but thought id ask. Thank you very much for the write up! Very awesome, lots of great info, and written better/more clear then I could ever hope to do!

Hey,

We are currently porting LineageOS on a couple of kirin devices (which includes hi3660 "aka kirin 960" as well).

You can look at the current sources here https://github.com/hisi-oss.

By far we almost got most of the things working on them (that includes trustzone [1] [2]) "it should work the same on EMUI 5" (to reply on your question, without trustzone, all the services that relies on it won't work "such as fingerprint, gatekeeper 'responsible of setting the password on the lockscreen', keymaster 'required for encryption' and the proprietary security services huawei introduced".

Honestly talking, using such old bases is not worth it imho, especially since huawei shipped multiple variants and not everything is covered by those in the old fw's. Also, those old kernels and proprietary blobs won't play well with newer Android versions (for ref, see hi6250-8 "aka hi6250 EMUI 8" patching list [3] "and we haven't done yet").

Not sure about atcmdserver usefulness, since we aren't currently shipping it "is used to communicate with balong modem".

Unfortunately i can't give an answer on why you get that efuse error, that's out of my knowledge.

One of the blocker we are currently dealing with is actually OSS DTB. We haven't tried something yet due to the remaining issues in the LineageOS port.

Would be cool if you have a telegram account or something to contact you btw :D, maybe we can figure out something regard it.

Regards.

oh very cool. i just found the kernels header for the the modem dtb in load_image which had a very similiar format. Also just stumbled on hikeys mkdtimg for kirin960 and a quick look in hex editor on a dts.img it made started with correct magic so ill test more. For me im installing actual linux on it, so far so good except the bootloader stuff which i can get thru, is this stupid trustzone (its connected to mali,bluetooth,sound etc.. just dunno how much or if its required for them all). I have no intention of running android stuff in background like a lot of projects. And for me an 8core 4gb of ram linux box in my pocket is just fn sweet :) But im super glad you guys are working on things! im fairly certain i can helpout with things like the dtb piece you mentioned. Also this kernel version is just aweful, ive written various kernel patches just to get it booting linux userland but prefer to save my efforts till i can boot something considerably newer. It will have to be at least new enuff to already have or be easily ported to with panfrost.Are you guys married to Mali binarys or are things like panfrost used when possible? And just a sidenote these old huawei's also have wifi cards compatible with nexmon. i rambling, im sorry but i would use any of those msging services you mentioned just let me know and ill signup.

…

On Tue, 26 Mar 2024, 2:38 pm Giovanni Ricca, ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ Hello good sir! I recently was given a huawei mate 9 kirin960. Ive been installing native linux on it. It boots to desktop (framebuffer) One of the big issues Ive had is of course the bootloader/dts partition. Im keeping the android at 7, for a bunch of reasons. I am able to make a bootable dts partition using the dtbTool in the tools folder from the opensource release. But the bootloader likes to mangle it in weird and varying ways. I didnt know if you had more luck or possibly any open source tools for the dts generation. Its tempting when using the dtbTool to point it to the dtc in the kernel source folder (and indeed errors less) but it doesnt support -@ so at best you will get fastboot to work but linux/android will die quickly in. To create a working one; ill use binwalk -e to extract the ripped partition binwalk -e partition.img add .dtb to each file for i in srcs/*; do mv $i $i.dtb ; done de-compile them; for i in srcs/*; do dtc -@ -I dtb -O dts -o $i.dts $i ; done make my changes then recompile them for i in srcs/*; do dtc -@ -I dts -O dtb -o $i.dtb $i ; done Now use the closed source tool to make the image, ../open-source-release/kernel/tools/dtbTool -o new-dts.img srcs/ For reasons I havent looked into, the dtbTool needs to stay in its kernel source directory, It also looks for and fails to find .vrl files for the dtb's. No idea what that is. So far you have been the best and only resource for development on this device. My current fear is that without access to being able to upload custom Tee apps, Ill be without a lot of needed things. My very very limited experience with trustzone stuff has been absolutely no access to devices connected to it any other way except thru trustzone, yet the kernel sources for sum of these devices have ifdef's for if trustzone is disabled, so possibly I may have access to the required IO on some of those devices? To be more clear it seems slightly possible that trustzone is optional on some sensors etc? Have you seen that? Any ideas on what hardware definitely wont work without it? Id love to get the root signing key and replace bootloader with hikey960's but looking less possible everyday. I have a kernel Ive been backporting kexec too (android 7 release kernel 4.1 uhg) It currently dies at the software reboot, I believe its a cpu spin issue will try with only one core enabled later today. With that I can use it as a bootloader and swap out the kernel and dtb correctly. Ive also looked at little at the atcmdserver which seems like a goldmine for extracting hidden resources, but haven't gotten very far. The other thing Im curious about is the options for fastboot that live in device tree. Not entirely sure how safe it is to play with those on the off chance it sets efuses based of those options or not. Do you have any understanding of those options? The last question I have is during boot it says efuse = 0. Years ago I had a phone that said something similar and it meant the brom had not been fused to read only and could be replaced, seems unlikely to be the same here but thought id ask. Thank you very much for the write up! Very awesome, lots of great info, and written better/more clear then I could ever hope to do! Hey, We are currently porting LineageOS on a couple of kirin devices (which includes hi3660 "aka kirin 960" as well). You can look at the current sources here https://github.com/hisi-oss. By far we *almost* got most of the things working on them (that includes trustzone [1] <hisi-oss/android_kernel_huawei_hi3660@c2a9f9b> [2] <hisi-oss/android_kernel_huawei_hi3660@9631f81>) "it should work the same on EMUI 5" (to reply on your question, without trustzone, all the services that relies on it won't work "such as fingerprint, gatekeeper 'responsible of setting the password on the lockscreen', keymaster 'required for encryption' and the proprietary security services huawei introduced". Honestly talking, using such old bases is not worth it imho, especially since huawei shipped multiple variants and not everything is covered by those in the old fw's. Also, those old kernels and proprietary blobs won't play well with newer Android versions (for ref, see hi6250-8 "aka hi6250 EMUI 8" patching list [3] <https://github.com/hisi-oss/android_device_huawei_hi6250-8-common/blob/lineage-20/extract-files.sh#L61> "and we haven't done yet"). Not sure about atcmdserver usefulness, since we aren't currently shipping it "we might be wrong about that btw". Unfortunately i can't give an answer on why you get that efuse error, that's out of my knowledge. One of the blocker we are currently dealing with is actually OSS DTB. We haven't tried something yet due to the remaining issues in the LineageOS port. Would be cool if you have a telegram account or something to contact you btw :D, maybe we can figure out something regard it. Regards. — Reply to this email directly, view it on GitHub <https://gist.github.com/A2L5E0X1/1e6564ab4479a13e7e5362c7c9ddca5f#gistcomment-5002057> or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAWMPZ277OQ7AIUGNAC2ZTY2G6CZBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTCNJXGY3DONBVU52HE2LHM5SXFJTDOJSWC5DF> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

I did throw the the eumi ver 9 device tree in my dts partition, then patched the kernels partition layout, do_mounts, and a couple of hard coded version numbers it was grabbing from boot loader on my android 7 eumi 5. It read the device tree fine but wouldnt boot my linux install. I'm guessing it was one or more of my patches but at least it proved the device-tree side worked. A quick note Im using the dtbTool from the eumi 5 open source release the eumi9 source release has one as well but they differ, not sure how. Im greatful for the trustzone patches, maybe if I can find a good working replacement for teecd / libteec, I could get away with using the stock ta's . As it stands the source code they release for those things is for the arm64 server line and Im dubious how much in common they will have. The atcmdserver does talk to the modem but def has the keys to the kingdom. As it was huawei's gauranteed repair route, in fact you can still see the at command equivalent listed in comments for all more powerful config stuff. Can even read bootloader unlock code plain text, setup and perform the various recovery methods etc. Its a shame close to nothing exists for info on it. Ill signup for telegram sometime today, maybe I can grab the OSS dtb you mentioned and give it a drive by.

Hey,I have researched about huawei a lot.I have a Kirin659 phone.I found an interesting thing.I have unlocked my bootloader and got root access.But I cannot write xloader partition using dd command.It shows that "operation not permitted".But I can use dd command to write other partition like cache.But selinux is permissive and I have full root access.And I cannot write xloader in twrp too.So how does the system prevent the write access to xloader?

I learned the hard way that you should NEVER MODIFY OR FLASH A WRONG dts.img. I made the mistake of flashing a modified dts.img, and it caused my device to go into a HARD BRICK state. The screen didn't work, and I couldn't even boot into recovery or fastboot mode.

After countless attempts, I finally managed to use Android Utility Pro (AUP) to get my device into factory fastboot mode and restore the firmware.

WARNING:

DO NOT EXPERIMENT WITH dts.img! If it's incorrect or modified, you won’t be able to fix it easily, and testpoint might not save you.

Testpointing does save you from such bricks, but yeah if you flashed a invalid dts it bricks because it’s also used by fastboot/xloader, but it should actually drop you into fastboot. But whatever, in case it doesn’t you can testpoint in order to flash a valid dts image again. Von: Ciptik ***@***.***> Gesendet: Mittwoch, 30. April 2025 00:44 An: Ciptik ***@***.***> Cc: Author ***@***.***> Betreff: Re: A2L5E0X1/kirin-aosp-helper.md @Ciptik commented on this gist.

…

--------------------------------------------------------------- I learned the hard way that you should NEVER MODIFY OR FLASH A WRONG dts.img. I made the mistake of flashing a modified dts.img, and it caused my device to go into a HARD BRICK state. The screen didn't work, and I couldn't even boot into recovery or fastboot mode. After countless attempts, I finally managed to use Android Utility Pro (AUP) to get my device into factory fastboot mode and restore the firmware. WARNING: DO NOT EXPERIMENT WITH dts.img! If it's incorrect, you won’t be able to fix it easily, and testpoint might not save you. — Reply to this email directly, [view it on GitHub](https://gist.github.com/A2L5E0X1/1e6564ab4479a13e7e5362c7c9ddca5f#gistcomment-5560667) or [unsubscribe](https://github.com/notifications/unsubscribe-auth/APWC2UY3V7R644D4TCXBNYD2376BVBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTCNJXGY3DONBVU52HE2LHM5SXFJTDOJSWC5DF). You are receiving this email because you authored the thread. Triage notifications on the go with GitHub Mobile for [iOS](https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675) or [Android](https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub).

@A2L5E0X1 Thanks for your reply!

Just to clarify from my own experience: In my case, the phone in regular fastboot mode wouldn't allow me to flash all partitions. For instance, when I tried flashing the dts.img, I received the error: Command not allowed. Only factory fastboot mode allows flashing the required partitions. To access this mode, I had to use AUP to load specific binary components like xloader, uce, and fastboot.

However, after flashing the incorrect dts.img, AUP would get stuck while loading certain files, showing the error: "Download hi63xx DDR [1] ...device rejected component header". I was fortunate that, after hundreds of attempts, all files were eventually loaded successfully.

Regarding testpointing: from my experience on a Kirin 710 (and possibly others), it can only load the device into factory fastboot mode, but it cannot flash individual images onto the internal eMMC storage. So, if you've modified the dts.img manually, you could end up in a situation where recovery becomes extremely difficult, and testpointing might not fully resolve the issue.

yeah the bootloader uses the dts files to setup/use the lcd, so if anything goes wrong, no lcd. I havent worked on my kirin in months but if memory serves the app that creates the dts files thats in the kernel source also wants to add dts files for the modem. It gives a cryptic less then helpful worded warning about it, not sure what if any consequences come from not supplying it. On my more modern qualcomm devices, the bootloader uses its own built-in lcd init, that includes gpio manipulation thats undocumented, so rotating the screen in X11 breaks it (cuz it requires reinitializing the screen) wayland works but its infancy causes other issues. I only mention it because in the end having all the lcd in dts is a good thing (once dts creation becomes easy/painless) but trust me brother i umderstand your pain.

…

On Tue, Apr 29, 2025, 6:43 PM Ciptik ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ I learned the hard way that you should NEVER MODIFY OR FLASH A WRONG dts.img. I made the mistake of flashing a modified dts.img, and it caused my device to go into a HARD BRICK state. The screen didn't work, and I couldn't even boot into recovery or fastboot mode. After countless attempts, I finally managed to use Android Utility Pro (AUP) to get my device into factory fastboot mode and restore the firmware. WARNING: DO NOT EXPERIMENT WITH dts.img! If it's incorrect, you won’t be able to fix it easily, and testpoint might not save you. — Reply to this email directly, view it on GitHub <https://gist.github.com/A2L5E0X1/1e6564ab4479a13e7e5362c7c9ddca5f#gistcomment-5560667> or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAWMPZVQMUQCGQGMQHIVJT2376BVBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTCNJXGY3DONBVU52HE2LHM5SXFJTDOJSWC5DF> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

Tbf a better way to handle mainline / "use" a built-from-source dtb is to completely leave dts partition alone and implement a way to load a custom dtb from the boot image (for example https://github.com/ivoszbg/uniLoader).

Crap forgot to mention, multiple levels of "unlocked bootloader" i was lucky enuff to have a mate 9 which could be unlocked more without consequences. If you used potatoenv to unlock I dont believe it does the flock by default. Mine was a kirin960 wich its claimed the only model supported without issues if enabling flock. I have a fork for potatoe's opensource python version but its currently set just for the 960. But a quick look for the flock stuff should get you going in fastboot. if it helps heres my fork https://github.com/bm16ton/macncheese

…

On Thu, May 1, 2025, 11:42 AM benjamin maddocks ***@***.***> wrote: yeah the bootloader uses the dts files to setup/use the lcd, so if anything goes wrong, no lcd. I havent worked on my kirin in months but if memory serves the app that creates the dts files thats in the kernel source also wants to add dts files for the modem. It gives a cryptic less then helpful worded warning about it, not sure what if any consequences come from not supplying it. On my more modern qualcomm devices, the bootloader uses its own built-in lcd init, that includes gpio manipulation thats undocumented, so rotating the screen in X11 breaks it (cuz it requires reinitializing the screen) wayland works but its infancy causes other issues. I only mention it because in the end having all the lcd in dts is a good thing (once dts creation becomes easy/painless) but trust me brother i umderstand your pain. On Tue, Apr 29, 2025, 6:43 PM Ciptik ***@***.***> wrote: > ***@***.**** commented on this gist. > ------------------------------ > > I learned the hard way that you should NEVER MODIFY OR FLASH A WRONG > dts.img. I made the mistake of flashing a modified dts.img, and it caused > my device to go into a HARD BRICK state. The screen didn't work, and I > couldn't even boot into recovery or fastboot mode. > > After countless attempts, I finally managed to use Android Utility Pro > (AUP) to get my device into factory fastboot mode and restore the firmware. > > WARNING: DO NOT EXPERIMENT WITH dts.img! If it's incorrect, you won’t be > able to fix it easily, and testpoint might not save you. > > — > Reply to this email directly, view it on GitHub > <https://gist.github.com/A2L5E0X1/1e6564ab4479a13e7e5362c7c9ddca5f#gistcomment-5560667> > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ADAWMPZVQMUQCGQGMQHIVJT2376BVBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTCNJXGY3DONBVU52HE2LHM5SXFJTDOJSWC5DF> > . > You are receiving this email because you commented on the thread. > > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> > . > >

yeah in the end i hacked the kernel for both dts and initrd loading from alternate locations, so big thumbs up for that solution

…

On Thu, May 1, 2025, 11:48 AM benjamin maddocks ***@***.***> wrote: Crap forgot to mention, multiple levels of "unlocked bootloader" i was lucky enuff to have a mate 9 which could be unlocked more without consequences. If you used potatoenv to unlock I dont believe it does the flock by default. Mine was a kirin960 wich its claimed the only model supported without issues if enabling flock. I have a fork for potatoe's opensource python version but its currently set just for the 960. But a quick look for the flock stuff should get you going in fastboot. if it helps heres my fork https://github.com/bm16ton/macncheese On Thu, May 1, 2025, 11:42 AM benjamin maddocks ***@***.***> wrote: > yeah the bootloader uses the dts files to setup/use the lcd, so if > anything goes wrong, no lcd. I havent worked on my kirin in months but if > memory serves the app that creates the dts files thats in the kernel source > also wants to add dts files for the modem. It gives a cryptic less then > helpful worded warning about it, not sure what if any consequences come > from not supplying it. On my more modern qualcomm devices, the bootloader > uses its own built-in lcd init, that includes gpio manipulation thats > undocumented, so rotating the screen in X11 breaks it (cuz it requires > reinitializing the screen) wayland works but its infancy causes other > issues. I only mention it because in the end having all the lcd in dts is a > good thing (once dts creation becomes easy/painless) but trust me brother i > umderstand your pain. > > On Tue, Apr 29, 2025, 6:43 PM Ciptik ***@***.***> wrote: > >> ***@***.**** commented on this gist. >> ------------------------------ >> >> I learned the hard way that you should NEVER MODIFY OR FLASH A WRONG >> dts.img. I made the mistake of flashing a modified dts.img, and it caused >> my device to go into a HARD BRICK state. The screen didn't work, and I >> couldn't even boot into recovery or fastboot mode. >> >> After countless attempts, I finally managed to use Android Utility Pro >> (AUP) to get my device into factory fastboot mode and restore the firmware. >> >> WARNING: DO NOT EXPERIMENT WITH dts.img! If it's incorrect, you won’t be >> able to fix it easily, and testpoint might not save you. >> >> — >> Reply to this email directly, view it on GitHub >> <https://gist.github.com/A2L5E0X1/1e6564ab4479a13e7e5362c7c9ddca5f#gistcomment-5560667> >> or unsubscribe >> <https://github.com/notifications/unsubscribe-auth/ADAWMPZVQMUQCGQGMQHIVJT2376BVBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVEYTCNJXGY3DONBVU52HE2LHM5SXFJTDOJSWC5DF> >> . >> You are receiving this email because you commented on the thread. >> >> Triage notifications on the go with GitHub Mobile for iOS >> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> >> or Android >> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> >> . >> >> >

I'm building a custom ROM based on AOSP 15 with minimal configuration, but the system gets stuck before showing the boot logo and reboots after ~70 seconds. The logs repeatedly show the following errors:

[  11.405s][init] Control message: Could not find 'aidl/android.security.maintenance' for ctl.interface_start from pid: 521 (/system/bin/servicemanager)
[  11.483s][init] Control message: Could not find '[email protected]::IKeymasterDevice/default' for ctl.interface_start from pid: 522 (/system/system_ext/bin/hwservicemanager)
...
[  12.405s][init] Control message: Could not find 'aidl/android.security.maintenance' for ctl.interface_start from pid: 521 (/system/bin/servicemanager)
[  12.483s][init] Control message: Could not find '[email protected]::IKeymasterDevice/default' for ctl.interface_start from pid: 522 (/system/system_ext/bin/hwservicemanager)

I fixed the keymaster error by adding [email protected] and [email protected] to PRODUCT_PACKAGES, and that part of the log is now gone.

However, the aidl/android.security.maintenance error persists:

[  11.637s][init] Control message: Could not find 'aidl/android.security.maintenance' for ctl.interface_start from pid: 520 (/system/bin/servicemanager)
...
[  69.678s][init] Control message: Could not find 'aidl/android.security.maintenance' for ctl.interface_start from pid: 520 (/system/bin/servicemanager)
[  70.459s][init] Control message: Could not find 'aidl/android.security.maintenance' for ctl.interface_start from pid: 520 (/system/bin/servicemanager)
[  70.459s][init] InitFatalReboot: signal 6

I’ve tried adding both keystore2 and android.security.maintenance-rust to PRODUCT_PACKAGES, but it didn’t help. Building targets like android.security.maintenance or android.security.maintenance-service using m fails with "unknown target".

Also, m fails entirely due to:

Cannot find framework matrix at FCM version 3: No such file or directory

despite specifying both manifest.xml and compatibility_matrix.xml.

So I build using make systemimage vendorimage, which completes successfully, but the device still fails to boot.

Has anyone faced a similar issue?

Hey,do you know the usb dload mode of Huawei?When you go into erecovery or press all the hardware buttons to power on,then connect usb cable between computer and phone.You will see DBAdapter Reserved Interface Port and PCUI port.Have anyone analyzed these ports?I have seen some paid tools use these port to write imei and send update.app to devices to achieve flashing stock firmware.
I use Wireshark to get the communication between host and phone when using these paid device.

It will send image header first for each image stored in update.app.

Then after receiving the response from phone,the tool starts sending the real image to the phone.But the sended data is different from the data from update.app.
Such as CRC.img,the tool sends

But in update.app,the CRC.img's actually data is

It is completely different!I think the tool encrypts the data before sending the data to the phone.But I don't know what encryption algorithm it uses.
Have anyone know any information about DBAdapter port or the usb dload mode in erecovery?
There is almost no information about them on the Internet.
Need help!Thanks!

Hey,do you know the usb dload mode of Huawei?When you go into erecovery or press all the hardware buttons to power on,then connect usb cable between computer and phone.You will see DBAdapter Reserved Interface Port and PCUI port.Have anyone analyzed these ports?I have seen some paid tools use these port to write imei and send update.app to devices to achieve flashing stock firmware. I use Wireshark to get the communication between host and phone when using these paid device. It will send image header first for each image stored in update.app. Then after receiving the response from phone,the tool starts sending the real image to the phone.But the sended data is different from the data from update.app. Such as CRC.img,the tool sends But in update.app,the CRC.img's actually data is It is completely different!I think the tool encrypts the data before sending the data to the phone.But I don't know what encryption algorithm it uses. Have anyone know any information about DBAdapter port or the usb dload mode in erecovery? There is almost no information about them on the Internet. Need help!Thanks!

Hi,

It’s possible that a paid tool unpacks UPDATE.APP into separate .img files — similar to what Huawei Update Extractor or Android Utility Pro do.

Try extracting UPDATE.APP this way, and then inspect crc.img using:

hexdump -C crc.img

Then compare the result with what the tool is sending (as shown in your third screenshot).

Hey,do you know the usb dload mode of Huawei?When you go into erecovery or press all the hardware buttons to power on,then connect usb cable between computer and phone.You will see DBAdapter Reserved Interface Port and PCUI port.Have anyone analyzed these ports?I have seen some paid tools use these port to write imei and send update.app to devices to achieve flashing stock firmware. I use Wireshark to get the communication between host and phone when using these paid device. It will send image header first for each image stored in update.app. Then after receiving the response from phone,the tool starts sending the real image to the phone.But the sended data is different from the data from update.app. Such as CRC.img,the tool sends But in update.app,the CRC.img's actually data is It is completely different!I think the tool encrypts the data before sending the data to the phone.But I don't know what encryption algorithm it uses. Have anyone know any information about DBAdapter port or the usb dload mode in erecovery? There is almost no information about them on the Internet. Need help!Thanks!

Hi,

It’s possible that a paid tool unpacks UPDATE.APP into separate .img files — similar to what Huawei Update Extractor or Android Utility Pro do.

Try extracting UPDATE.APP this way, and then inspect crc.img using:

hexdump -C crc.img

Then compare the result with what the tool is sending (as shown in your third screenshot).

No,It is also different from CRC.img.

Unfortunately, it seems that we, along with other users, have received too little input data to analyze this issue properly. For example, to unlock the bootloader on devices with a Kirin chip, you can use Android Utility Pro or PotatoNV. Searching for a new flashing method only makes sense if it allows us to flash any custom .img images. Otherwise, we won’t be able to install open-source firmware. Unlocking the bootloader or enabling partition writing is just a small part of the success.

For instance, my phone runs a 4.9.148 kernel from an EMUI 9 firmware, and GSI Android 10 works well with it. However, newer versions of system.img can’t find the 28.cil policy file in the system partition, and booting fails. Because of this, I have to build a custom vendor.img. My issue with 'aidl/android.security.maintenance' might be related to the fact that AOSP 15 can’t register the service through the Binder IPC interface due to the old kernel. The source code for a newer Huawei kernel is available, but I don’t know how to compile it.

As far as I understand, in AOSP, the kernel used for booting is located in boot.img, whereas in Huawei devices, it’s in a separate kernel.img partition limited to 24 MB. It’s unclear whether the kernel can be built separately using toolchains, or if it’s necessary to follow the official guide at https://source.android.com/docs/setup/build/building-kernels, downloading the full environment and placing the kernel source directory into it. Alternatively, maybe there's a way to build it using the AOSP 15 project environment itself — but I’m not sure how to approach it.

Unfortunately, it seems that we, along with other users, have received too little input data to analyze this issue properly. For example, to unlock the bootloader on devices with a Kirin chip, you can use Android Utility Pro or PotatoNV. Searching for a new flashing method only makes sense if it allows us to flash any custom images. Otherwise, we won’t be able to install open-source firmware. Unlocking the bootloader or enabling partition writing is just a small part of the success..img

For instance, my phone runs a 4.9.148 kernel from an EMUI 9 firmware, and GSI Android 10 works well with it. However, newer versions of can’t find the policy file in the system partition, and booting fails. Because of this, I have to build a custom . My issue with might be related to the fact that AOSP 15 can’t register the service through the Binder IPC interface due to the old kernel. The source code for a newer Huawei kernel is available, but I don’t know how to compile it.system.img``28.cil``vendor.img``'aidl/android.security.maintenance'

As far as I understand, in AOSP, the kernel used for booting is located in , whereas in Huawei devices, it’s in a separate partition limited to 24 MB. It’s unclear whether the kernel can be built separately using toolchains, or if it’s necessary to follow the official guide at https://source.android.com/docs/setup/build/building-kernels, downloading the full environment and placing the kernel source directory into it. Alternatively, maybe there's a way to build it using the AOSP 15 project environment itself — but I’m not sure how to approach it.boot.img``kernel.img

Hey,I know a bootrom exploit which allows you to get temporary bootloader unlock without any paid tools.
And if oem unlock commands exists,you can patch fastboot to force it unlock your device!
So we can work together to makecan opensource tool.

Unfortunately, it seems that we, along with other users, have received too little input data to analyze this issue properly. For example, to unlock the bootloader on devices with a Kirin chip, you can use Android Utility Pro or PotatoNV. Searching for a new flashing method only makes sense if it allows us to flash any custom images. Otherwise, we won’t be able to install open-source firmware. Unlocking the bootloader or enabling partition writing is just a small part of the success..img
For instance, my phone runs a 4.9.148 kernel from an EMUI 9 firmware, and GSI Android 10 works well with it. However, newer versions of can’t find the policy file in the system partition, and booting fails. Because of this, I have to build a custom . My issue with might be related to the fact that AOSP 15 can’t register the service through the Binder IPC interface due to the old kernel. The source code for a newer Huawei kernel is available, but I don’t know how to compile it. system.img28.cilvendor.img'aidl/android.security.maintenance' As far as I understand, in AOSP, the kernel used for booting is located in , whereas in Huawei devices, it’s in a separate partition limited to 24 MB. It’s unclear whether the kernel can be built separately using toolchains, or if it’s necessary to follow the official guide at https://source.android.com/docs/setup/build/building-kernels, downloading the full environment and placing the kernel source directory into it. Alternatively, maybe there's a way to build it using the AOSP 15 project environment itself — but I’m not sure how to approach it. boot.imgkernel.img

Hey,I know a bootrom exploit which allows you to get temporary bootloader unlock without any paid tools. And if oem unlock commands exists,you can patch fastboot to force it unlock your device! So we can work together to makecan opensource tool.

@hicode002, hi. I can try to help with developing the utility, but I can’t promise much — I probably have less experience in this area than you do.
I’m not sure how to contact you outside of GitHub to communicate in a more convenient way.

Unfortunately, it seems that we, along with other users, have received too little input data to analyze this issue properly. For example, to unlock the bootloader on devices with a Kirin chip, you can use Android Utility Pro or PotatoNV. Searching for a new flashing method only makes sense if it allows us to flash any custom images. Otherwise, we won’t be able to install open-source firmware. Unlocking the bootloader or enabling partition writing is just a small part of the success..img
For instance, my phone runs a 4.9.148 kernel from an EMUI 9 firmware, and GSI Android 10 works well with it. However, newer versions of can’t find the policy file in the system partition, and booting fails. Because of this, I have to build a custom . My issue with might be related to the fact that AOSP 15 can’t register the service through the Binder IPC interface due to the old kernel. The source code for a newer Huawei kernel is available, but I don’t know how to compile it. system.img28.cilvendor.img'aidl/android.security.maintenance' As far as I understand, in AOSP, the kernel used for booting is located in , whereas in Huawei devices, it’s in a separate partition limited to 24 MB. It’s unclear whether the kernel can be built separately using toolchains, or if it’s necessary to follow the official guide at https://source.android.com/docs/setup/build/building-kernels, downloading the full environment and placing the kernel source directory into it. Alternatively, maybe there's a way to build it using the AOSP 15 project environment itself — but I’m not sure how to approach it. boot.imgkernel.img

Hey,I know a bootrom exploit which allows you to get temporary bootloader unlock without any paid tools. And if oem unlock commands exists,you can patch fastboot to force it unlock your device! So we can work together to makecan opensource tool.

@hicode002, hi. I can try to help with developing the utility, but I can’t promise much — I probably have less experience in this area than you do. I’m not sure how to contact you outside of GitHub to communicate in a more convenient way.

Hey,you can telegram me.
t.me/hicode002

Unfortunately, it seems that we, along with other users, have received too little input data to analyze this issue properly. For example, to unlock the bootloader on devices with a Kirin chip, you can use Android Utility Pro or PotatoNV. Searching for a new flashing method only makes sense if it allows us to flash any custom images. Otherwise, we won’t be able to install open-source firmware. Unlocking the bootloader or enabling partition writing is just a small part of the success..img
For instance, my phone runs a 4.9.148 kernel from an EMUI 9 firmware, and GSI Android 10 works well with it. However, newer versions of can’t find the policy file in the system partition, and booting fails. Because of this, I have to build a custom . My issue with might be related to the fact that AOSP 15 can’t register the service through the Binder IPC interface due to the old kernel. The source code for a newer Huawei kernel is available, but I don’t know how to compile it. system.img28.cilvendor.img'aidl/android.security.maintenance' As far as I understand, in AOSP, the kernel used for booting is located in , whereas in Huawei devices, it’s in a separate partition limited to 24 MB. It’s unclear whether the kernel can be built separately using toolchains, or if it’s necessary to follow the official guide at https://source.android.com/docs/setup/build/building-kernels, downloading the full environment and placing the kernel source directory into it. Alternatively, maybe there's a way to build it using the AOSP 15 project environment itself — but I’m not sure how to approach it. boot.imgkernel.img

Hey,I know a bootrom exploit which allows you to get temporary bootloader unlock without any paid tools. And if oem unlock commands exists,you can patch fastboot to force it unlock your device! So we can work together to makecan opensource tool.

@hicode002, hi. I can try to help with developing the utility, but I can’t promise much — I probably have less experience in this area than you do. I’m not sure how to contact you outside of GitHub to communicate in a more convenient way.

Hey,you can telegram me. t.me/hicode002

Hi @hicode002! I tried using your Telegram contact, but it seems like the account is currently suspended or unavailable. Just wanted to check in — is everything alright?