Help building LineageOS for LeEco (LeTV) LeMax 1 (X900/Max1) CN

[htimsxela]

Finished building. Time to test...

Note: don't be misled by the 45:04 elapsed time on picture. It took hours and hours to fix all the stuff.

 

[htimsxela]

Some news regarding the overall progress with LineageOS.

I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.1.x running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).

Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:

As usual, I'll keep you posted.

Didn't boot. Again.

For 15.1, when phone is turned on, it starts loading and, before showing the ROM logo, it gets back to penguin screen (bootloader).
For 14.1, when phone is turned on, it starts loading and, before showing the ROM logo, it reboots into recovery.

I've been reading that maybe the modem image is not compatible with newer versions of Android. It could be the case.

But I don't give up easy, so now I'll try a new approach. Long ago I found out OnePlus 2 is very similar to X900/Max1 in terms of architecture. The front and rear cameras are different though. OnePlus 2 uses OV sensors while X900/Max1 uses Sony IMX230 sensors (at least for front camera). So the plan now is to compile a oneplus2 variant to suit the X900.

Again, let's see if that will work...

 

[htimsxela]

More news.

For those in a hurry, just read this: it builds (again), but doesn't boot (again).

Keep reading if you want to know more.

I fully updated the device tree. You can see on github I have now 4 repositories:

1. https://github.com/alexsmithbr/android_device_letv_max1 <- the main device tree
2. https://github.com/alexsmithbr/android_device_letv_common <- common tree for letv devices
3. https://github.com/alexsmithbr/android_kernel_letv_max1 <- max1 kernel tree (unmodified from leeco)
4. https://github.com/alexsmithbr/android_vendor_letv_max1 <- vendor device tree for main device

I just copied the OnePlus2 structure and adapted accordingly, so android_device_letv_max1 was android_device_oneplus_oneplus2 and android_device_letv_common was android_device_oppo_common.

Inside trees #1 and #2, I replace everything related to "oneplus" for "letv" and everything related to "oneplus2" for "max1". Of course I looked at the code to fix any bugs this could cause.

Then I gave it a run and it built just fine.

I'm not surprised it didn't boot, since I didn't copy any vendor files from Max1 into vendor folder yet. Now I'll have to do it and see how it goes.

One interesting thing is that when I try to flash the new ROM, the assert function fails saying "This package is for device: x900,X900,x900+,X900+,max1,Max1,MAX1; this device is ." It seems like my recovery (twrp 3.0.0) is not being able to use getprop("ro.product.device") correctly, as device name is coming empty. So, in order to install the ROM, I had to temporarily patch /build/make/tools/releasetools/edify_generator.py so that it would accept my device. I did this by updating def AssertDevice(self, device): function. I just added a 1 == 1 before the test, so it will install despite the device I'm trying to use. It is dangerous, but I'm not publishing this ROM until I can boot it, so it's only dangerous for me.

Next steps:

- fixing proprietary-files.txt and populate vendor/letv/max1 folder, then build again.
- I'm thinking about compiling twrp as well. Maybe working with a recovery image will be faster and, once I get it working, I can come back to the full android development.

 

[htimsxela]

TWRP 3.2.1-0 for LeEco (Letv) Le Max - max1/x900

Thanks to ABM30, we got a x1 twrp-3.2.1-0 image which is compatible with x900 phones.

And thanks to LeGi0NeeR, we got twrp-3.2.3-0 for x1, which works for max1/x900 as well (I just tested it).

I tweaked version 3.2.3-0 it a little bit so that we can backup all max1/x900 partitions and it identifies the phone as "X900", not as "Le 1 Pro". The modified image is here:

https://mega.nz/#!DQMySa5I!iigFfAKl3v8MpnmxsLA4v36DegoHYFQEkOYUWZKewYc

If it works for you too, please let me know.

 

[htimsxela]

Regarding the port to a newer Android, I got this message which is really inspiring!

4) Direct upgrade from Lollipop ROMs to Nougat+ ROMs is not possible for x800/x900 CN, you have to install firstly some Marshmallow ROM to update some basic partitions:
https://xdaforums.com/leeco-le1-pro/help/letv-x800-cn-img-boot-t3843901

So maybe the problem I was having (getting stuck to the penguin (bootloader) screen is due to this step-by-step upgrade which must be done before we can flash a newer Android version. Experiences will continue and I'll keep you informed.

 

[JayMontana36]

Hey, so I'm that guy you messaged recently on Reddit who was trying to build Lineage for a similar device with the same exact hardware practically/pretty much, taking some notes from what you've done as well as eventually just using the exact device tree with minor modifications from my source device, replacing my source device's kernel source with my target device's kernel source, and getting successful builds but ending up with the same end result/issue you're having (device won't boot/will instead bootloop back into recovery (which I've gotten to work simply by replacing the kernel from the preexisting/precompiled recovery for the source device with the kernel for my target device) without much reason or clue as to why); here's the next step I that I'm currently taking and exploring in attempt to find out/debug why that's happening: ensure that your target/compiled ROM is installed (incase you wiped it in an attempt to try and debug or ensure it wasn't an installation issue), force boot your target boot.img (via fastboot) to ensure it doesn't just go straight into recovery mode, afterwards once it reboots go ahead and let/allow it to boot up on it's own back into recovery (or if it reboots back into the bootloader load directly into recovery mode), and then once in recovery, either under advanced then terminal or via adb shell, enter "cat /proc/last_kmsg" (I actually recommend doing "adb pull /proc/last_kmsg ./kmsg.txt" instead which makes both navigation and reading much easier) and that'll pretty much show you a log of what happened and/or why, which for me happens to be SELinux related, not sure if it/that'll be the same for you but I believe that's the only thing standing in my way now from getting my device working, maybe yours as well. Sorry I took so long.

 

[JayMontana36]

Well, if it's got anything at all to do with SELinux then I'm afraid we're stuck as I've tried literally everything I've come across to try and fix it for my device with no luck/success despite the recovery using the same exact kernel in the proper way I need it to in the system/boot (as in permissive; SELinux is set to permissive in recovery and works properly there but won't/is stuck in system thus causing issues/bootloops). I've tried things from recompiling my kernel with SELinux completely absent which doesn't work since the system checks for it and bootloops with a different SELinux error message stating that it couldn't be found and is missing (so we are required to have it one way or another by Android), recompiling with commandline permissive in device boardconfig and modifying the kconfig files in kernel also does nothing as it still won't boot up successfully, trying to boot with the source device's kernel fails with the DTB error (I also tried combining the kernel sources which I felt was probably not that great of an idea but I tried it anyways and it caused the recompilation to fail, then I tried selectively combining specific things while manually modifying others and that still failed). Literally the only issue that I can see/find for my device via the previous method I've given above in my previous post (the last_kmsg method) is with SELinux which is the direct cause/reason behind the constant rebooting into recovery rather than a successful, with no clear fix nor workaround that actually works.

 

[htimsxela]

Hi, JayMontana36! First of all, thank you very much for taking the time to report your issues. We're on the same boat!

I have a question:

[...] ensure that your target/compiled ROM is installed (incase you wiped it in an attempt to try and debug or ensure it wasn't an installation issue), force boot your target boot.img (via fastboot) to ensure it doesn't just go straight into recovery mode, afterwards once it reboots go ahead and let/allow it to boot up on it's own back into recovery (or if it reboots back into the bootloader load directly into recovery mode), and then once in recovery, either under advanced then terminal or via adb shell, enter "cat /proc/last_kmsg" [...] and that'll pretty much show you a log of what happened and/or why, which for me happens to be SELinux related [...]

Are you trying this with a max1/x900 as well? I ask you that because my phone doesn't seem to have a /proc/last_kmsg file. I saw that LeEco patched this functionality in their kernel and (it seems) they've put sort of a last_kmsg file in "letvconfig2" partition. I mentioned it on the first post of this thread.

Let's join forces, my friend. I believe we're not too far.

 

[JayMontana36]

Are you trying this with a max1/x900 as well? I ask you that because my phone doesn't seem to have a /proc/last_kmsg file. I saw that LeEco patched this functionality in their kernel and (it seems) they've put sort of a last_kmsg file in "letvconfig2" partition. I mentioned it on the first post of this thread.

Nah, my device is the FIH PHX (which actually is for multiple devices, my device in particular is the Luna TG-L800S, though the InFocus M812 also has/uses the same codename and ROMs are crosscompatible across both devices including all the variants of the M812 with minimal effort, even the bootloaders can be run which I've had to do at one point to recover from a somewhat stupid action of mine, which was attempting to flash the OnePlus One X (ONYX) bootloader and firmware to my device which did work (device took it) however resulted in hardbricking I had to recover from rather than the desired result, everything else though works across these as far as I can tell, patching OnePlus One X recoveries with the correct kernel for example works great/perfectly out of the box with no issues whatsoever however for whatever reason the same can't be said for system). Our devices are completely different architectures from what I can tell, most notably yours being arm64 mine being arm/armv7.1 (also different SoCs) but with the same issue, I for one am at a loss though as I have no idea what else to do or try with mine. I've now also tried doing user and userdebug builds rather than the eng builds but no difference either.

Anyways, so if the last_kmsg file for your device is in or on another partition, I'd say take a look at the fstab files to see if anything relevant is listed/shown there and/or patch/replace the one in recovery so that you can mount it much easier from in recovery (likely from commandline); depending upon how they've done that however, it'll either be a filesystem with the last_kmsg file on/in it, or it'll be no filesystem at all but a file/partition that you can read directly from with a text editor (or dd into a file then read afterwards).

 

[htimsxela]

Got it. Well, from my side, I've tried to dump that partition with dd and inspect it, but it seems Letv patch makes it write to the partition only if certain parameters match (kernel version, etc), otherwise kernel messages are completely ignored. It makes it almost impossible to blindly debug the kernel. Anyway, maybe trying to revert this patch would be promising...

As for your side, I'd suggest you to post the last_kmsg file somewhere (maybe a new thread?) and I can try to help you debugging it. I know sepolicies are really troublesome, but we can try. I'm happy to help.

 

[JayMontana36]

Hmm well that's a weird/strange one making it only write if/when something specific matches when it comes to development, but maybe try replacing the newly compiled kernel with the original in the boot image to bypass this, and/or using the original boot image completely to see if the same thing happens? Maybe also take a closer look at the commandline kernel options from the original to see if anything relevant is there for that; I'm not entirely sure if there are any kmsg related commanline options available for/on our kernel versions or if any even exist at all (can't find any) that force it and/or set a destination location.

So, for my device, I've posted in the 2 already established threads relating to custom ROMs for my device (which hasn't really seen much action in 2-3 years apart from a few asking about it, nothing development or update related), though maybe I should/will create my own thread for it but I'm going to wait that off a bit first to see if anything happens with those threads.

Thread 1: https://xdaforums.com/showpost.php?p=78930782&postcount=1246 (not entirely for my device, however does contain a lot of stuff for it)
Thread 2: https://xdaforums.com/showpost.php?p=78930852&postcount=25 (more dedicated to/for my device specifically than the one above is)

My last_kmsg file: https://pastebin.com/ZkmbCmXx

 

[htimsxela]

Wow, you got way further than I'm getting, this I'm sure!

SELinux: avtab: invalid type or class
init: SELinux:  Could not load policy:  Invalid argument
init: failed to load policy: Invalid argument
init: Security failure; rebooting into recovery mode...

The above are the problems with SELinux you're having, right? Have you tried to set kernel into permissive mode, or even disable SELinux temporarily? You can do it by editing your BoardConfig.mk and adding this parameter to BOARD_KERNEL_CMDLINE:

androidboot.selinux=<enforcing|permissive|disabled>

Where:

enforcing = SELinux fully enabled.
permissive = SELinux enabled, but only reporting violations, not blocking.
disabled = SELinux disabled (this works for regular kernels, but I'm not sure it works for Android).

Just for reference, here's my kernel cmdline:

BOARD_KERNEL_CMDLINE := androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 boot_cpus=0-3 androidboot.selinux=disabled

I'm currently testing the "disabled" option.

 

[JayMontana36]

Wow, you got way further than I'm getting, this I'm sure!
Have you tried to set kernel into permissive mode, or even disable SELinux temporarily?

Yeah I've tried numerous ways/methods of getting around SELinux with no luck

Well, if it's got anything at all to do with SELinux then I'm afraid we're stuck as I've tried literally everything I've come across to try and fix it for my device with no luck/success despite the recovery using the same exact kernel in the proper way I need it to in the system/boot (as in permissive; SELinux is set to permissive in recovery and works properly there but won't/is stuck in system thus causing issues/bootloops). I've tried things from recompiling my kernel with SELinux completely absent which doesn't work since the system checks for it and bootloops with a different SELinux error message stating that it couldn't be found and is missing (so we are required to have it one way or another by Android), recompiling with commandline permissive in device boardconfig and modifying the kconfig files in kernel also does nothing as it still won't boot up successfully, trying to boot with the source device's kernel fails with the DTB error (I also tried combining the kernel sources which I felt was probably not that great of an idea but I tried it anyways and it caused the recompilation to fail, then I tried selectively combining specific things while manually modifying others and that still failed). Literally the only issue that I can see/find for my device via the previous method I've given above in my previous post (the last_kmsg method) is with SELinux which is the direct cause/reason behind the constant rebooting into recovery rather than a successful, with no clear fix nor workaround that actually works.

I've also tried replacing the new SELinux contexts and policy files with old ones which throws another different error and still fails, I think SELinux is required to be existent in some way (can't be missing and must be configured correctly) for Android, though presumably it should just work and be able to be bypassed with permissive (though it won't do that outside of recovery mode for whatever reason).

 

[htimsxela]

Hi, people! It's been a while, but I'm back. It's hard to keep the development going while traveling, but believe me: I'm trying.

Ok, so some updates:

Nothing worked yet. Sorry. But I'm now focusing on making boot work. I think this is the starting point. So what I did up to now:

1. Got a copy of my current working boot (based on LightFW.18s-6.0.1.MaX900.Ver.1.0.By.Spz.zip):

adb shell 'su -c "dd if=/dev/block/bootdevice/by-name/boot of=/sdcard/boot"' && adb pull /sdcard/boot /tmp/boot

2. Unpacked it using Android Image Kitchen:

./unpackimg.sh /tmp/boot

Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers
 
Supplied image: boot
 
Setting up work folders...
 
Image type: AOSP
 
Splitting image to "split_img/"...
BOARD_KERNEL_CMDLINE console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 boot_cpus=0-5
BOARD_KERNEL_BASE 00000000
BOARD_NAME 
BOARD_PAGE_SIZE 4096
BOARD_HASH_TYPE unknown
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 01000000
BOARD_SECOND_OFFSET 00f00000
BOARD_TAGS_OFFSET 00000100
BOARD_HEADER_VERSION 0
 
Warning: "unknown" hash type detected; assuming "sha1" type!
 
Unpacking ramdisk (as root) to "ramdisk/"...
 
Compression used: gzip
9442 blocks
 
Done!

3. Repacked it to make sure it works:

./repackimg.sh

Android Image Kitchen - RepackImg Script
by osm0sis @ xda-developers
 
Packing ramdisk (as root)...
 
Using compression: gzip
 
Getting build information...
kernel = boot-zImage
cmdline = console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 boot_cpus=0-5
board = 
base = 00000000
pagesize = 4096
kernel_offset = 00008000
ramdisk_offset = 01000000
second_offset = 00f00000
tags_offset = 00000100
header_version = 0
hash = sha1
 
Building image...
 
Using format: AOSP
 
Done!

4. Flashed image back to phone:

adb reboot bootloader
fastboot flash boot image-new.img
fastboot reboot

5. Tested.

It worked flawlessly, so the next step is to compile the original Letv kernel, change it on boot and see if it boots. To compile the kernel, I'm using the following command lines:

1. Once inside of the kernel dir, create output folder:

mkdir out

2. Create compile structure inside output dir:

make CFLAGS_MODULE="-fno-pic" -C $PWD O=$PWD/out ARCH=arm64 CROSS_COMPILE="/home/android_build/android/lineage/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-" msm8994-perf_defconfig

3. Compile kernel

make -j5 CFLAGS_MODULE="-fno-pic" -C $PWD O=$PWD/out ARCH=arm64 CROSS_COMPILE="/home/android_build/android/lineage/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-" all

I'll get back with the results soon.

 

[htimsxela]

I compared the images from the working ROM and the image generated by my kernel and they are different.

My compiled kernel output:

~/android/tools/split-appended-dtb-master/split-appended-dtb ~/android/lineage/kernel/letv/msm8994/out/arch/arm64/boot/Image.gz-dtb
Found 36 appended dtbs, please check the output.

The output from the ROM I'm using (working one):

~/android/tools/split-appended-dtb-master/split-appended-dtb boot-zImage 
Found 30 appended dtbs, please check the output.

As we can see, 36 vs 30 dtbs, which may mean the kernels are based on different sources. Bad. And using my compiled kernel and flashing boot, it doesn't boot.

 

[JayMontana36]

Well, why not try substituting your compiled kernel from within your newly compiled boot.img with the original oem compiled kernel from the original boot.img? It may also help to take a look at and compare the recovery.img kernels as well, and maybe even also try using those kernels as well.

I was actually just thinking of maybe trying with an older version of Lineage such as Lineage 13 to see if that'd work and as a last hope or resort maybe try Ubuntu Touch and enable/install the feature/function that allows for Android applications to be run on/within it.

I can say that for myself though the kernel replacement trick worked where I took/extracted my original recovery and boot kernel files and replaced/overwrote the ones that are/were meant for the device that my device closely resembles, which in turn caused the recovery to work though sadly still not the ROM but it may still be worth a shot to try honestly. If I try building LineageOS 13 and it works without issue or at the very least starts/boots I will report back to you and suggest trying that so that you can at least have something somewhat better than essentially nothing, and if I fail well I'm researching that Ubuntu Touch a bit and can say that I'm almost definitely gonna try it as a last resort or maybe even before LineageOS 13. Another thing you can also try I suppose is a Lineage (or CM/CyanogenMod) revision/version based upon the stock Android version and then work from there once you have something actually working.

 

[Palm Trees]

What I did for vendor dir:

I compared the tree with Max1 tree, excluding everything that was not found in Max1. The plan is to add more vendor stuff if necessary.

Current tree: https://github.com/alexsmithbr/android_device_letv_max1

What firmware version did you base your vendor tree on?

 

[htimsxela]

What firmware version did you base your vendor tree on?

Hi, Palm Trees! Everything I'm taking from the device is based on the ROM I'm currently using, which is LightFW.18s-6.0.1.MaX900.Ver.1.0.By.Spz.zip. What do you mean by 'firmware version'?

Please see if attached file answers your question.

 

[htimsxela]

Well, why not try substituting your compiled kernel from within your newly compiled boot.img with the original oem compiled kernel from the original boot.img? It may also help to take a look at and compare the recovery.img kernels as well, and maybe even also try using those kernels as well.

Yes, another possibility to try, for sure. Thank you! By the way, trying an older version of LineageOS (CyanogenMod) is also a good approach, since SELinux probably changed for Lineage 15+... Anyway, I think I'll first make sure the kernel works. This will be one less stone on the road.

 

[Palm Trees]

Hi, Palm Trees! Everything I'm taking from the device is based on the ROM I'm currently using, which is LightFW.18s-6.0.1.MaX900.Ver.1.0.By.Spz.zip. What do you mean by 'firmware version'?

Please see if attached file answers your question.

Simply trying to help by saying you're not using the latest stock rom files. Your base rom 18s (LightFW.18s-6.0.1.MaX900.Ver.1.0.By.Spz) might be a hacked together rom. It's better to use the official unaltered stock rom files.

If I was you, I would take everything from the latest official firmware version (5.9.028S). I did a quick comparison using WinMerge between your vendor files from Github with the 28s files. There are differences in a lot of the files. Also, use the 28s boot.img as base instead.

I hope it works out. I've asked @ThE_MarD to share some advice, if he has any for this device's bring up as he is currently bringing up LOS16 for the Le Max Plus/Pro (X910)

Below are links and select details:

1523500103_MAX1_X900 CN FN CEXCNFN5902803208S 5.9.028S //latest fw release (not fastboot images)
Source: http://bug.letv.com/cn/download/phone/32
Direct DL-link: http://ota.scloud.lfengmobile.com/ota/1523500103_MAX1_X900-CN-FN-CEXCNFN5902803208S-5.9.028S.zip
ro.letv.release.version=5.9.028S
ro.product.letv_model=Letv X900+
ro.build.version.release=6.0.1
ro.build.version.security_patch=2017-01-01
ro.build.date=Tue Mar 20 20:00:44 CST 2018
ro.product.model=X900
ro.product.brand=Letv
ro.product.name=max1
ro.product.device=max1
ro.product.board=msm8994
ro.build.fingerprint=Letv/max1/max1:6.0.1/CEXCNFN5902803208S/8:user/release-keys
# BOOTIMAGE_BUILD_PROPERTIES
ro.bootimage.build.date=Tue Mar 20 20:31:41 CST 2018
ro.bootimage.build.fingerprint=Letv/max1/max1:6.0.1/CEXCNFN5902803208S/8:user/test-keys