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.