Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ZTE Nubia N3 NX608J #107

Open
VGerris opened this issue Jul 8, 2020 · 5 comments
Open

ZTE Nubia N3 NX608J #107

VGerris opened this issue Jul 8, 2020 · 5 comments

Comments

@VGerris
Copy link

VGerris commented Jul 8, 2020

This is the repit-dump.log from a ZTE Nubia N3 (NX608J) with android 7.1.
I would like to be able to flash an Android 9 or 10 ROM from similar models like the Redmi Note 6 pro or Max 2.
I need a working vendor partition for that, is that possible?

I used TWRP 3.2.1-0 compiled by nemo-nemo to run the dump by using fastboot boot recovery-image.img .
Rom is official as supplied , perhaps modified with gapps by vendor.
No repartitioning was done.

repit-dump.log

Thanks for your help!

@Lanchon Lanchon changed the title ZTE Nubia N3 NX608J - repit repartition with vendor request ZTE Nubia N3 NX608J Jun 26, 2023
@Lanchon
Copy link
Owner

Lanchon commented Jun 26, 2023

your device is almost surely affected by #55.

I need a working vendor partition for that, is that possible?

REPIT cannot add or remove partitions.

@VGerris
Copy link
Author

VGerris commented Jun 26, 2023 via email

@Lanchon
Copy link
Owner

Lanchon commented Jun 26, 2023

it is not huawei, its qualcomm. they provide devel boards for the chips and a customized complete android distro, including bootloaders, in source form. these BLs check the PT signature if configured to, and i suppose checks are on by default.

given that this phone is 2018 and that qualcomm started enforcing PT signatures around 2014 i think, this phone PT is 99% likely to be protected.

porting android is more than running a GSI. different android versions require different kernel versions, and the kernel is of course not included in GSI images. running an newer kernel on an old device is serious porting work, as google and OEMs don't mainline their kernel patches.

if your view is utilitarian, just throw away the phones and buy community supported phones. if you want to learn, you can try porting android to your device. note that this is a lot of work, and will cost you much more than the value of a couple of old phones.

@VGerris
Copy link
Author

VGerris commented Jun 27, 2023 via email

@Lanchon
Copy link
Owner

Lanchon commented Jun 27, 2023

assuming a port for a very similar device does not exist...

you'd start by porting the kernel. for that you very much need the current OEM kernel sources. you have the right to it but not all manufacturers comply with GPL. with that, you'd select a tree from which you think the OEM worked to produce the OEM sources (mainline, google android kernel, codeaurora, etc). now you'd start to compare the OEM sources with different points in tree history, and finally choose a specific point as the closest.

there will be many differences, such as many cherripicked commits or out of tree changes by the OEM. try to express the OEM sources as some tree state + cherrypicks as much as possible, with minimum OEM changes. this is an art form.

now you have a maintained tree + some OEM changes. so you can "fastforward" the tree to the necessary version for your new android and port the OEM changes (hopefully few) to the new tree state. you should end up with a newer kernel with the right drivers for your device.

before starting, check that building the OEM sources actually produces a working kernel that works with the OEM system or a GSI. after finishing kernel work, you should end with a newer kernel that runs the old system, as userland compatibility is almost never broken on linux. at this point, a newer GSI should work. now its time to start porting android itself.

LVM is a really simple mainlined device stack. just turning on a flag during kernel compile will include it. for simplicity it should be linked in and not a loadable module, given that you'll probably need it to access the partition where the modules are.

btw, loadable modules are very much a part of the kernel and not the userland. building a new kernel requires that you also build all loadable modules, sources of which the OEM hopefully gave you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants