Database Info

MTK6575 Based Devices Cyanogenmod

Hi Guys I Want Someone Who Can Help Me To Build CM For MTK6575 .
I Have LG Optimus L4 II E440 Its MTK6575 Based Device And I Have Source Code .
I Think It Will Work On Other Devices .

Even if you have the source code for that device, you can't just build generically for anything with that processor as even if just one part of the device is changes that part would probably cease to function. Also when it comes to building something like that I'll see what I can do once I have a fully functional computer but the source is like 40 GB so it would be a big investment already just to download it. Which version of cm?

dreamwave said:
Even if you have the source code for that device, you can't just build generically for anything with that processor as even if just one part of the device is changes that part would probably cease to function. Also when it comes to building something like that I'll see what I can do once I have a fully functional computer but the source is like 40 GB so it would be a big investment already just to download it. Which version of cm?
Click to expand...
Click to collapse
I Think CM 10.1/10.2 Or CM 11 !
I Have Installed Lubuntu 12.04 And I Will Start Programing From There But I Dont Know From Where I Can Download The CM Build !

vikole said:
I Think CM 10.1/10.2 Or CM 11 !
I Have Installed Lubuntu 12.04 And I Will Start Programing From There But I Dont Know From Where I Can Download The CM Build !
Click to expand...
Click to collapse
I made some 1.5 based rom at one point for my g1 but I remember like...none of it. Once you read up on building android you should be fine. I'll just warn you you will be working with BIG data, probably around 40gb to download.

dreamwave said:
I made some 1.5 based rom at one point for my g1 but I remember like...none of it. Once you read up on building android you should be fine. I'll just warn you you will be working with BIG data, probably around 40gb to download.
Click to expand...
Click to collapse
Can You Help Me ??:highfive::highfive::highfive:

vikole said:
Can You Help Me ??:highfive::highfive::highfive:
Click to expand...
Click to collapse
I'll have to see. I have hard drive issues so I couldn't do it myself but I think I can guide you to a few good guides. There's a really good xdauniversity one I saw at one point I'll try to find.

[DEV] Porting kernel 3.10.x to d2 for Lollipop

As we know, Android Lollipop is being released soon, and it requires a kernel that is 3.10.y, which is not available for our device. I'm not great with kernels and would in no way consider myself a kernel developer, but I have applied the neccessary patches to get the kernel version up to 3.10.0, which can be found here https://github.com/frap129/android_kernel_samsung_d2. Because I'm not a kernel developer, I am looking for some help in at least getting this kernel somewhat ready before the release of 5.0, so we can all get the latest update ASAP. Any and all help is apreciated!

Does your kernel compile and boot on cm11? If it does, there shouldn't be much problems in getting it working on L.

Any news? Does it compile?

frap129 said:
As we know, Android Lollipop is being released soon, and it requires a kernel that is 3.10.y, which is not available for our device. I'm not great with kernels and would in no way consider myself a kernel developer, but I have applied the neccessary patches to get the kernel version up to 3.10.0, which can be found here https://github.com/frap129/android_kernel_samsung_d2. Because I'm not a kernel developer, I am looking for some help in at least getting this kernel somewhat ready before the release of 5.0, so we can all get the latest update ASAP. Any and all help is apreciated!
Click to expand...
Click to collapse
nope android 5.0 doesnt require new kernel, you could build it on 3.0.y like i am doing on my Note 2 oh and as far as i know new nexus devices are still on 3.4.y

Ivan_Meler said:
nope android 5.0 doesnt require new kernel, you could build it on 3.0.y like i am doing on my Note 2 oh and as far as i know new nexus devices are still on 3.4.y
Click to expand...
Click to collapse
yes, but the new Samsung tablets (at least) are being shipped with the 3.10.x kernels.. 'course they're still running kitkat at the moment, but definitely cannot wait to see if/when they get kit kat.
I'll have to report back later after I take pictures of the 'about phone' page lol [if you want proof anyway]

frap129 said:
As we know, Android Lollipop is being released soon, and it requires a kernel that is 3.10.y, which is not available for our device. I'm not great with kernels and would in no way consider myself a kernel developer, but I have applied the neccessary patches to get the kernel version up to 3.10.0, which can be found here https://github.com/frap129/android_kernel_samsung_d2. Because I'm not a kernel developer, I am looking for some help in at least getting this kernel somewhat ready before the release of 5.0, so we can all get the latest update ASAP. Any and all help is apreciated!
Click to expand...
Click to collapse
ztotherad said:
yes, but the new Samsung tablets (at least) are being shipped with the 3.10.x kernels.. 'course they're still running kitkat at the moment, but definitely cannot wait to see if/when they get kit kat.
I'll have to report back later after I take pictures of the 'about phone' page lol [if you want proof anyway]
Click to expand...
Click to collapse
I know samsung does things like that (i have few other devices from them) but hey thats samsung and they are lazy so they dont want to update kernel version after device is relesed so they do this not to feel outdated on softwere side

Whoops! I read somewhere that the newly expanded SELinux permissions had some dependency on the 3.10.y kernel. Oh well, I guess Ill just test it anyways so I can brag that I have a newer kernel than anyone else if it works

frap129 said:
Whoops! I read somewhere that the newly expanded SELinux permissions had some dependency on the 3.10.y kernel. Oh well, I guess Ill just test it anyways so I can brag that I have a newer kernel than anyone else if it works
Click to expand...
Click to collapse
That would definitely be awesome! Be sure to report back your results. I'm not an experienced ROM or kernel developer, but I'll be attempting on bringing a pure AOSP 5.0.0_r2 to my GS3. I'm not sure how successful I'll be, but my first step involved me planning on copying over our vendor repo from CM's M11 or M12 release (whenever that gets out) and trying to build Lollipop against it.

polarEskimo said:
That would definitely be awesome! Be sure to report back your results. I'm not an experienced ROM or kernel developer, but I'll be attempting on bringing a pure AOSP 5.0.0_r2 to my GS3. I'm not sure how successful I'll be, but my first step involved me planning on copying over our vendor repo from CM's M11 or M12 release (whenever that gets out) and trying to build Lollipop against it.
Click to expand...
Click to collapse
I was planning on working on that as well over the weekend.

polarEskimo said:
That would definitely be awesome! Be sure to report back your results. I'm not an experienced ROM or kernel developer, but I'll be attempting on bringing a pure AOSP 5.0.0_r2 to my GS3. I'm not sure how successful I'll be, but my first step involved me planning on copying over our vendor repo from CM's M11 or M12 release (whenever that gets out) and trying to build Lollipop against it.
Click to expand...
Click to collapse
You will need to change many things in device tree to get it compile oh and dont forget to disable cm overlays

Ivan_Meler said:
You will need to change many things in device tree to get it compile oh and dont forget to disable cm overlays
Click to expand...
Click to collapse
I'm very new to the AOSP build process and didn't have much luck last night getting the CM device sources to play nicely with AOSP. I'm finding it difficult to find any relevant guides on porting over the CM device trees to pure AOSP. If you or anyone else can help by explaining the process or pointing to a guide that I may have missed, I'd be grateful. Plus the more people we have collaborating on his, the better our chances of getting Lollipop on our devices.

I'm working on porting 5.0 to our phone, tweaked the device tree and got the build running but (as expected) i'm running into SEpolicy hell. The new selinux implementation in lollipop is proving to be trouble. I've just made a few more edits and the build is moving along, I'll post results shortly.
If anyone cares to help I'll walk you through what I've done so far. One thing to note is you need to adjust vendorsetup.sh to say full_d2lte-eng instead of cm_d2lte-eng and create AndroidProducts.mk that points at full_d2lte.mk (you can use the hammerhead device tree as a reference to do this)
That will get your device tree to regester properly. If you don't do the above you'll get a "no config makefile found" error when you try to select d2lte with lunch.
As far as the actual tree, you're gonna wanna grab device/samsung/d2lte, device/samsung/msm8960-common, vendor/samsung/d2lte, vendor/samsung/msm8960-common, vendor/cm, vendor/cyngn, and kernel/d2.
You'll also need a couple things from /hardware, namely hardware/samsung. There's a couple things you'll need to remove from msm8960-common in /device, I can't remember the specific file name but the error message will tell you.
Follow those instructions and you'll get where I'm at, with the build crapping out on SEpolicy

Restl3ss said:
I'm working on porting 5.0 to our phone, tweaked the device tree and got the build running but (as expected) i'm running into SEpolicy hell. The new selinux implementation in lollipop is proving to be trouble. I've just made a few more edits and the build is moving along, I'll post results shortly.
If anyone cares to help I'll walk you through what I've done so far. One thing to note is you need to adjust vendorsetup.sh to say full_d2lte-eng instead of cm_d2lte-eng and create AndroidProducts.mk that points at full_d2lte.mk (you can use the hammerhead device tree as a reference to do this)
That will get your device tree to regester properly. If you don't do the above you'll get a "no config makefile found" error when you try to select d2lte with lunch.
As far as the actual tree, you're gonna wanna grab device/samsung/d2lte, device/samsung/msm8960-common, vendor/samsung/d2lte, vendor/samsung/msm8960-common, vendor/cm, vendor/cyngn, and kernel/d2.
You'll also need a couple things from /hardware, namely hardware/samsung. There's a couple things you'll need to remove from msm8960-common in /device, I can't remember the specific file name but the error message will tell you.
Follow those instructions and you'll get where I'm at, with the build crapping out on SEpolicy
Click to expand...
Click to collapse
Wow, this is awesome. It sounds like you've gotten the furthest than any of us. I appreciate the instructions, but is there any chance you could push your repos to GitHub? And do you think the SELinux stuff you're running into has anything to do with our device being on the 3.4 kernel instead of 3.10?

polarEskimo said:
Wow, this is awesome. It sounds like you've gotten the furthest than any of us. I appreciate the instructions, but is there any chance you could push your repos to GitHub? And do you think the SELinux stuff you're running into has anything to do with our device being on the 3.4 kernel instead of 3.10?
Click to expand...
Click to collapse
It's not a kernel thing so much as a device tree thing. (Kitkat vs lollipop) the policy.conf (along with a few other things) in the device tree is designed for kitkat and isn't playing very nice with the 5.0 source. I'm trying to bang it out a bit by swapping a few C and header files in the build core.
As for my last build, my tweaks got me past where I was but now I'm hanging on a new set of SElinux errors.
I've been at this for less than 12 hours so given that timeframe this looks promising.
I'm trying to think of what the best way to go about this is. I could either try to adapt the tree for the new source or I could try to adapt the source for the old tree (use KitKat SElinux implementation on lollipop). The latter would have more success with root but the former is the correct way to do it (and would get us cyanogenmod 12 faster once they start nightlies, as I can push the changes to gerrit)

Restl3ss said:
It's not a kernel thing so much as a device tree thing. (Kitkat vs lollipop) the policy.conf (along with a few other things) in the device tree is designed for kitkat and isn't playing very nice with the 5.0 source. I'm trying to bang it out a bit by swapping a few C and header files in the build core.
As for my last build, my tweaks got me past where I was but now I'm hanging on a new set of SElinux errors.
I've been at this for less than 12 hours so given that timeframe this looks promising.
I'm trying to think of what the best way to go about this is. I could either try to adapt the tree for the new source or I could try to adapt the source for the old tree (use KitKat SElinux implementation on lollipop). The latter would have more success with root but the former is the correct way to do it (and would get us cyanogenmod 12 faster once they start nightlies, as I can push the changes to gerrit)
Click to expand...
Click to collapse
Again, any chance you can post your source? You don't have to try and work on it on your own. The more people that look at the progressions you made, the better our chances are at success.

polarEskimo said:
Again, any chance you can post your source? You don't have to try and work on it on your own. The more people that look at the progressions you made, the better our chances are at success.
Click to expand...
Click to collapse
I'll push what I've got to github after this experiment

Cyanogen is updating sources to lolipop right now and omni has semi working source so it will be easier to port 5.0 since we wont need to edit device tree that much

Ivan_Meler said:
Cyanogen is updating sources to lolipop right now and omni has semi working source so it will be easier to port 5.0 since we wont need to edit device tree that much
Click to expand...
Click to collapse
Yes but, they have a tentative deadline of dec. 1st to start pushing out the first nightlies. We likely won't be in the first wave either, since d2 is now 3 generations out of date.
I'd much rather just port aosp and have it in 2 weeks rather than wait 3 weeks to even begin work.
Side note. If/when I get this working I'm calling it PotatOS

Managed to work past my problem with SElinux for now, the build has now moved on to... another set of errors!
Build currently hangs at this:
Code:
host C++: libutils_32 <= system/core/libutils/StopWatch.cpp
host C++: libutils_32 <= system/core/libutils/String8.cpp
host C++: libutils_32 <= system/core/libutils/String16.cpp
host C++: libutils_32 <= system/core/libutils/SystemClock.cpp
host C++: libutils_32 <= system/core/libutils/Threads.cpp
host C++: libutils_32 <= system/core/libutils/Timers.cpp
system/core/libutils/Timers.cpp: In function 'nsecs_t systemTime(int)':
system/core/libutils/Timers.cpp:43:13: error: 'CLOCK_BOOTTIME' was not declared in this scope
build/core/binary.mk:618: recipe for target 'out/host/linux-x86/obj32/STATIC_LIBRARIES/libutils_intermediates/Timers.o' failed
make: *** [out/host/linux-x86/obj32/STATIC_LIBRARIES/libutils_intermediates/Timers.o] Error 1
#### make failed to build some targets (01:19 (mm:ss)) ####
Going to bed, will get back at it in the morning. Source should be up on github by tomorrow night

Restl3ss said:
Yes but, they have a tentative deadline of dec. 1st to start pushing out the first nightlies. We likely won't be in the first wave either, since d2 is now 3 generations out of date.
I'd much rather just port aosp and have it in 2 weeks rather than wait 3 weeks to even begin work.
Side note. If/when I get this working I'm calling it PotatOS
Click to expand...
Click to collapse
I'm with you on that, I'd rather have pure AOSP than buggy CM nightlies. Also interesting choice of ROM name lol. Thanks for your hard work and I'm looking forward to pulling down your repos so I can take a stab at these compile-time issues.

[UNOFFICIAL][ROM][10.0/9.0] LineageOS 17.1/16.0 [violet][Q/PIE]

Introduction
A spinoff thread from the previously-supported-official thread by Atman.
This thread will contain my unofficial builds for violet. On the 16.0 version, the only real fix (so far...) have been the fingerprint scanner sepolicy denials. I aim to do monthly/bimonthly builds to keep up to date with security patches, as so far I haven't encountered any other issues (let me know).
On the 17.1 version, I have slowly figured out how to make it work, but it is highly experimental.
The 16.0 ROM is stable (I use it as my daily driver).
If you find any bugs, please do take screenshots, give a way for me to replicate it on my device, and send a logcat. If you're super smart, use a logcat and filter for the keyword so I don't have to do even more digging
Please don't tell me to use PE/Mokee commits.
Yet another update. I've got 17.1 builds working without having to resort to cheap tricks and commits (sort of).
Flash instructions
Same as usual:
Reboot to fastboot and flash recovery with fastboot (You have to use the TWRP linked below. Other versions likely won't boot.)
Reboot to recovery TWRP
Wipe to format data, wipe again to wipe system and cache (not necessary if you're updating, only if you're switching ROMs)
Flash firmware (ADB sideload) (this step is dated. The newer builds have a higher target firmware so you should try to flash without the firmware first, then flash the firmware if the ROM doesn't work.)
Flash the ROM (sideload)
Flash GApps, Magisk, etc. as necessary
Done
Downloads (16.0) (STABLE)
Firmware (Dated firwmare)
Recovery (TWRP)
11-Jun-2021 build (with 05-May-2021 security patch), and MD5 Digest
For previous builds see below
Downloads (17.1)
Here's the 17.1 ROM. Here's the md5 hash. It has the March security patch.
It currently does not boot. If you would like to try and help with development, flash the ROM, and then flash the Chinese Q firmware on top of it (this can be downloaded from xiaomifirmwareupdater). Be warned that there is a risk that the newest android keymaster may re-encrypt your device, which in the worst case may require you to format data and/or reflash recovery and/or flash a fastboot MIUI rom. So, it's a bit risky, but likely won't be an issue.
Credits, Sources, etc.
Too many to mention. Atman Shah for getting this device supported earlier last year. ThE_MarD (Marc Bougoin) for other help. Various other names I've seen - Bruno Martins, Weikai Kong, Wang Han... all of the Lineage dev team. I'm sure I'm missing many people who have been involved in the project. I am new, and very much a latecomer to all of this.
Device Tree: https://gitlab.com/mzha/android_device_xiaomi_violet
Kernel Tree: https://gitlab.com/mzha/android_kernel_xiaomi_violet
Other things see my gitlab: https://gitlab.com/mzha
A telegram group to discuss development for 16.0/17.1: t.me/lineageos_violet
Previous builds
07-Nov-2020 (incl. Oct-2020 security patch), with 07-Nov-2020 MD5 Hash
13-Jul-2020 (incl. Jul-2020 security patch), with 13-Jul-2020 MD5 Hash
11-May-2020 (incl. May-2020 security patch), with 11-May-2020 MD5 Hash

Good to see some devs showing interest on this os
will you be adding any customisation? or does it continue as pure lineage os?

e2vinay said:
Good to see some devs showing interest on this os
will you be adding any customisation? or does it continue as pure lineage os?
Click to expand...
Click to collapse
Pure LineageOS. There's more than enough customised ROMs for violet already in my opinion... and I also don't have that much time

hcnulma said:
Pure LineageOS. There's more than enough customised ROMs for violet already in my opinion... and I also don't have that much time
Click to expand...
Click to collapse
That's great
by any chance will you consider adding signature spoofing support? that would be really great. it would help many users go for microG instead of gapps
I completely understand you're starter.
great work. good luck.
Thank you

e2vinay said:
will you consider adding signature spoofing support?
Click to expand...
Click to collapse
No, but there are a few alternatives:
Merge the changes from this RFC and build it
Download the spoofer from https://download.lineage.microg.org/violet/, or get the (ed)Xposed module, or other possibilities...

Will be official Lineage Os?

Can we expect los 17 soon?

himanshu fulmali said:
Can we expect los 17 soon?
Click to expand...
Click to collapse
As per OP: I'm waiting on both Android 10 firmware blobs + kernel to be released by Xiaomi... I'm not sure how the other ROM devs get around this, if it's easy to forward-port or not. But for now, only LOS 16.

Heyyo @hcnulma good to see you got your thread up and going!
As for 17.1? You can work with your current kernel and cherry-pick the fixes that other maintainers of violet are using and same for the device tree and vendor blobs.
As an example, LeEco msm8996 devives are using kernel source code from Marshmallow just rebased on a CAF Q Tag for our kernel since we never got anything newer...
Even once Xiaomi release their kernel source code for Android 10? It would probably take quite a bit of work to shave it down to what you specifically need and then importing it on top of a fresh CAF tag for the kernel or even more work to try and inplement it into uour current kernel.
To get official builds of LOS 16.0 going again for violet you would need to show that you are capable of fixing any major bugs that arise as well.
https://wiki.lineageos.org/submitting_device.html
anywho, hope this information helps bud!

hcnulma said:
As per OP: I'm waiting on both Android 10 firmware blobs + kernel to be released by Xiaomi... I'm not sure how the other ROM devs get around this, if it's easy to forward-port or not. But for now, only LOS 16.
Click to expand...
Click to collapse
I am pretty sure you can use the pixel experience device tree and kernel to compile the ROM just like every other rom

Thank you. If he is stable enough I will use it to build RR PIE

Zjh0094 said:
Thank you. If he is stable enough I will use it to build RR PIE
Click to expand...
Click to collapse
It's definitely stable...
prajwal2001 said:
I am pretty sure you can use the pixel experience device tree and kernel to compile the ROM just like every other rom
Click to expand...
Click to collapse
From what I understand, using their kernel tree will mean I'll have to change a lot of references in my own device tree, and using their device tree on top of that is essentially just building PE, not Lineage.
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.

Request to create group for discussion in Telegram

hcnulma said:
It's definitely stable...
From what I understand, using their kernel tree will mean I'll have to change a lot of references in my own device tree, and using their device tree on top of that is essentially just building PE, not Lineage.
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.
Click to expand...
Click to collapse
you won't have to make any changes in the kernel as far as I know and as for the device tree you just have to make some changes according to the ROM
as every ROM uses the same device tree
and you won't be making pe instead of lineage as the same device tree and kernel are used in every Q ROM except EvoX which uses crimson kernel

hcnulma said:
It's definitely stable...
Click to expand...
Click to collapse
Thanks. I will use it as my benchmark to build RR pie.
---------- Post added 15th February 2020 at 12:03 AM ---------- Previous post was 14th February 2020 at 11:57 PM ----------
hcnulma said:
In any case, I did find the Snapdragon 675 (ie sm6150) kernel trees for Q in several places, https://github.com/sm6150-dev/android_kernel_xiaomi_sm6150 and https://github.com/PixelExperience-Devices/kernel_xiaomi_sm6150. I'll take a closer look into this...
I did find the most recent CAF kernel under sm6150 here, but there seems to be an issue of this not showing up in /quic/la... Something will be resolved. Hopefully.
Click to expand...
Click to collapse
/quick/la/msm-4.14

prajwal2001 said:
you won't have to make any changes in the kernel as far as I know and as for the device tree you just have to make some changes according to the ROM
Click to expand...
Click to collapse
It is precisely the device tree that I'm worried about. From experience, PE has a lot of platform-specific stuff that Lineage doesn't (and the same the other way), and also from trying to figure out the fix to 16.0 I realised there's a lot of context/definition differences between the two device trees. I'd still give it a look, but I suspect it might be easier to just modify the current 16.0 device tree.
RupeshRN said:
Request to create group for discussion in Telegram
Click to expand...
Click to collapse
https://t.me/lineageos_violet.
Zjh0094 said:
/quick/la/msm-4.14
Click to expand...
Click to collapse
Yeah I already figured it was msm-4.14. Have already cloned it but am also considering cherrypicking changes that other devs have done to their kernel trees from 16.0 -> 17.1 as opposed to starting with the CAF kernel. A work in progress.

Sir I'm noob but mokee dev released android 10 and i think mokee and los are pretty same, will he not help you if you contact him?

An update on where I am:
I'm not sure whether to use the PE or Mokee vendor trees. Neither of them have much resemblance to 16.0 tree I have so cherry picking changes will be a nightmare.
The PE vendor tree has a lot of device-tree-specific commits, which will make it a headache to untangle later on. The Mokee vendor tree also has a lot of differing firmware files, though is a bit more similar to the LOS tree.
I'm doing a bit of experimentation to figure out which one will last better in the long run, since I can't seem to get my hands on any MIUI Android Q firmware blobs.

An update on where I am:
I'm not sure whether to use the PE or Mokee vendor trees. Neither of them have much resemblance to 16.0 tree I have so cherry picking changes will be a nightmare.
The PE vendor tree has a lot of device-tree-specific commits, which will make it a headache to untangle later on. The Mokee vendor tree also has a lot of differing firmware files, though is a bit more similar to the LOS tree.
I'm doing a bit of experimentation to figure out which one will last better in the long run, since I can't seem to get my hands on any MIUI Android Q firmware blobs.

Yet another update. I've got 17.1 builds working without having to resort to cheap tricks and commits (sort of).
Here's the 17.1 ROM. Here's the md5 hash. Needless to say, it's very experimental, not stable in the least (expect to get past boot maybe 70% of the time) - I'm getting very mixed results when experimenting myself. Nevertheless, try it out, see what you get. Install it the same way as usual. Keen to get as many eyes on this as possible

Will there be a Custom Rom?

Does anyone know about this topic?

https://forum.xda-developers.com/mi-note-10/how-to/custom-development-t4018813
In short:there are same some efforts trying to get custom Roms but nothing groundbreaking yet.
I am working on the device tree right now to compile from source. Not ready yet and don't have the device in hand right now (should arrive soon) s.o. else is trying with treble images.

nchantmnt said:
https://forum.xda-developers.com/mi-note-10/how-to/custom-development-t4018813
In short:there are same some efforts trying to get custom Roms but nothing groundbreaking yet.
I am working on the device tree right now to compile from source. Not ready yet and don't have the device in hand right now (should arrive soon) s.o. else is trying with treble images.
Click to expand...
Click to collapse
I thought device tree is something that was used to be leaked from Xiaomi

As far as I can see there is no device tree published by xiaomi for tucana (our device)
Only thing we have rn is kernel source.
But we can create device tree by ourself. There are some basic guides online. Rest is compare with existing device trees for similar devices and copy&paste.
for now I have downloaded k20 device tree, removed everything k20-specific (e. G. Popup Camera) and adapt further files for our device(s)
When my handset arrives (should be today) I can start unlock procedure (should take some time to get the code AFAIK), then I can unlock bootloader, flash custom recovery and see if I can get my device to boot properly after flashing... Then comes troubleshooting.
Right now I am expecting maybe a halfway booting device or broken/missing functionality at best. But we will see

I hope soon

The more people help together the faster we can get some Roms ?

nchantmnt said:
The more people help together the faster we can get some Roms ?
Click to expand...
Click to collapse
If you have a group for this, would you pm?

No group yet, but you still get an pm
Anyone willing to collaborate is welcome to pm me as well

I have seen this Android 9 source code. Is it helpful?
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/tucana-p-oss
I thought this model would have more support and after 4 months there is no Rom. I hope that now that the price is going down more people buy it and we have more community. Thank you for what you know and develop.

ignalop1983 said:
I have seen this Android 9 source code. Is it helpful?
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/tree/tucana-p-oss
I thought this model would have more support and after 4 months there is no Rom. I hope that now that the price is going down more people buy it and we have more community. Thank you for what you know and develop.
Click to expand...
Click to collapse
Just an incomplete kernel sources, I think is useless.

https://www.xda-developers.com/poss...-fcc-certified-snapdragon-730g-penta-cameras/
There will be a lite edition soon. The only difference on hardware is number of pixels.
If its ROM is same or almost the same to current models, we should get some progress around development.

Anything new?

UtkuAblak said:
Does anyone know about this topic?
Click to expand...
Click to collapse
Please look at the existing topics first, before opening another topic!

nchantmnt said:
As far as I can see there is no device tree published by xiaomi for tucana (our device)
Only thing we have rn is kernel source.
But we can create device tree by ourself. There are some basic guides online. Rest is compare with existing device trees for similar devices and copy&paste.
for now I have downloaded k20 device tree, removed everything k20-specific (e. G. Popup Camera) and adapt further files for our device(s)
When my handset arrives (should be today) I can start unlock procedure (should take some time to get the code AFAIK), then I can unlock bootloader, flash custom recovery and see if I can get my device to boot properly after flashing... Then comes troubleshooting.
Right now I am expecting maybe a halfway booting device or broken/missing functionality at best. But we will see
Click to expand...
Click to collapse
Well, just tell me if you need help.

Same here, I am very tempted by the Note 10 but I am waiting for an aosp rom as many people complained about the stock miui rom

Any news or update on this? Would love to buy a Mi Note 10 as their prices have gone down but with the lack of development I'm kind of leaning towards the 9t even tho I'm worried about that front camera as some have had issues. I suspect not many are developing for this device because of the high price. Hopefully whoever said something up there about the Note 10 lite gets custom ROMs going with more devs

I'm still trying here but very short on time. We have some good progress on device tree thanks to someone else (thanks Hlcpereira).

nchantmnt said:
I'm still trying here but very short on time. We have some good progress on device tree thanks to someone else (thanks Hlcpereira).
Click to expand...
Click to collapse
yes he is working on this device.

nchantmnt said:
I'm still trying here but very short on time. We have some good progress on device tree thanks to someone else (thanks Hlcpereira).
Click to expand...
Click to collapse
Awesome news! Thanks :good:

I think the development goes now straight because we have MIUI Stable based on Android 10 now.
Good luck!

[ROM] [UNOFFICIAL] LineageOS 14 for Meizu M5C [MT6737m]

LineageOS (Lineage Android Distribution) members or anyone else on this website is not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in the products you find here before flashing it! YOU are choosing to make these modifications, and if you point the finger at us for messing up your device, we will laugh at you. Your warranty will be void if you tamper with any part of your device / software.
How to Install:
1- Make a backup of your important files
2 - Unlock bootloader with this guide
3 - Flash the TWRP, link here
4 - Move Rom & Gapps (optional) into device storage
5 - Full Wipes
6- Flash Rom & Gapps (gapps are OPTIONAL)
for GAPPS:
Choose Gapps Package ARM64 > 7.1 > Micro and below: visit OpenGAPPS
If during the gapps flash it gives you an error then in the TWRP terminal or on the adb shell you have to execute this command: "mkdir /tmp/bin"
Download:
Releases · XRedCubeX/android_device_meizu_m5c
Contribute to XRedCubeX/android_device_meizu_m5c development by creating an account on GitHub.
github.com
Working:
Boots
Storages
Bluetooth
Wifi
GPS - GNSS
Audio
NOT Working:
Camera
Hotspot
Offline Charging
Special Thanks
LineageOS
Moyster for device trees
Device Tree:https://github.com/XRedCubeX/android_device_meizu_m5c
Vendor Tree: https://github.com/XRedCubeX/android_vendor_meizu_m5c

Assim que possível, irei testar!

Hi Red. I was taking a look at the ROM repository on GitHub, and saw that the default branch is now named cm-13.1. So, are you now working on an Android 6.0 ROM for the M5c?

thiagosousa777 said:
Hi Red. I was taking a look at the ROM repository on GitHub, and saw that the default branch is now named cm-13.1. So, are you now working on an Android 6.0 ROM for the M5c?
Click to expand...
Click to collapse
I have a slight indecision, now I can not carry on the Custom ROM because I do not have the right PC but when I am able to compile it, I will evaluate which one can work better

XRed_CubeX said:
I have a slight indecision, now I can not carry on the Custom ROM because I do not have the right PC but when I am able to compile it, I will evaluate which one can work better
Click to expand...
Click to collapse
I see. I would say that in the long run Lineage 14 would be more worthwhile, since Android 6.0 is becoming outdated, with no support for some apps. But really, I just wanted a ROM to replace Flyme, and its bugs. Also, many of the apps I use don't work, or don't work right on Flyme...
These days I was taking a look at /e/ OS. I've been thinking about venturing into porting this ROM to the M5c. For me it would be a challenge, since I've never done this before. But unfortunately at the moment I also don't have a PC that meets the requirements to compile the ROM

thiagosousa777 said:
I see. I would say that in the long run Lineage 14 would be more worthwhile, since Android 6.0 is becoming outdated, with no support for some apps. But really, I just wanted a ROM to replace Flyme, and its bugs. Also, many of the apps I use don't work, or don't work right on Flyme...
These days I was taking a look at /e/ OS. I've been thinking about venturing into porting this ROM to the M5c. For me it would be a challenge, since I've never done this before. But unfortunately at the moment I also don't have a PC that meets the requirements to compile the ROM
Click to expand...
Click to collapse
I find it useless, just use lineage without gapps and it will be better than /e/, then anyway I don't know where to find the manifest

XRed_CubeX said:
I find it useless, just use lineage without gapps and it will be better than /e/, then anyway I don't know where to find the manifest
Click to expand...
Click to collapse
You are right. However, /e/ has some nice features like e account synchronization, an app store, microG, and some of their apps... Of course we could get that with LineageOS, but it is interesting how /e/ already brings that well integrated and ready.
By the way, I am also looking at other non-Android systems, like Ubuntu Touch...

thiagosousa777 said:
You are right. However, /e/ has some nice features like e account synchronization, an app store, microG, and some of their apps... Of course we could get that with LineageOS, but it is interesting how /e/ already brings that well integrated and ready.
By the way, I am also looking at other non-Android systems, like Ubuntu Touch...
Click to expand...
Click to collapse
Ah beautiful those non-android systems yes, unfortunately we have to forget them because of the prebuilt kernel and unavailable sources

XRed_CubeX said:
Ah beautiful those non-android systems yes, unfortunately we have to forget them because of the prebuilt kernel and unavailable sources
Click to expand...
Click to collapse
Well, from what I've been reading the process is similar to porting LineageOS. You just need the kernel sources and the device specific binary blobs. I'm guessing you know how to get them, don't you?
And the interesting thing is that there is a layer, called Halium, that interacts directly with the hardware. And that is actually what you should port to the desired device. Then you can install any Linux system on top of this layer, like Ubuntu Touch, Plasma Mobile, etc, and these are distributed pre-compiled.

thiagosousa777 said:
Well, from what I've been reading the process is similar to porting LineageOS. You just need the kernel sources and the device specific binary blobs. I'm guessing you know how to get them.
And the interesting thing is that there is a layer, called Halium, that interacts directly with the hardware. And that is actually what you should port to the desired device. Then you can install any Linux system on top of this layer, like Ubuntu Touch, Plasma Mobile, etc, and these are distributed pre-compiled.
Click to expand...
Click to collapse
Mhh ... good, you are informed, however the vendor blobs are bull**** to take, the problem is the kernel sources but Meizu has not released them. However, some time ago I booted a Custom kernel based on ALPS (A custom AOSP from Mediatek to be clear) but the touchscreen doesn't work and I'm looking for a solution around but that I can't find
P.S: Fixing that kernel has great potential, forget android 7, you could also boot android 9 with sources, but as long as they are still working

XRed_CubeX said:
Mhh ... good, you are informed, however the vendor blobs are bull**** to take, the problem is the kernel sources but Meizu has not released them. However, some time ago I booted a Custom kernel based on ALPS (A custom AOSP from Mediatek to be clear) but the touchscreen doesn't work and I'm looking for a solution around but that I can't find
P.S: Fixing that kernel has great potential, forget android 7, you could also boot android 9 with sources, but as long as they are still working
Click to expand...
Click to collapse
I confess I didn't quite understand one thing: so how did you port LineageOS to this device? You didn't need the kernel sources?

thiagosousa777 said:
I confess I didn't quite understand one thing: so how did you port LineageOS to this device? You didn't need the kernel sources?
Click to expand...
Click to collapse
At the time I was doing this lineage, I was with the prebuilt kernel, week ago I had done this kernel port to a twrp and the touch was not working so I left the device alone

XRed_CubeX said:
At the time I was doing this lineage, I was with the prebuilt kernel, week ago I had done this kernel port to a twrp and the touch was not working so I left the device alone
Click to expand...
Click to collapse
Thanks for the clarification! It is a shame that Meizu does this (I wonder if they are not violating the terms of the Linux GPL license by distributing the kernel without publishing the modifications made to the source code).
Anyway, if a solution to this kernel problem related to the touch screen comes up, please let me know. In the meantime I'll keep reading Halium's documentation until a solution comes along, or until I get a compatible phone.

Great work!

Hello. I've been testing this ROM on my M5c and love it. The ROM is very good, fluid, lightweight... the only problem is that the camera doesn't work, as well as the cellular network data. Congratulations for the excellent work.
The ROM will no longer receive bugfixes?

pls compile

publish a release