[DEV] MultiROM WIP discussion [flounder][arm64] - Nexus 9 General

I thought I'd post here my (and the people who helped me) progress on porting MultiROM to the HTC Nexus 9.
Contributors (so far, tell me if I miss anyone)
@Bogdacutu for his port of MultiROM on the Shield Tablet (The arm stuff)
@USBhost for testing as well as helping with the patch (patch is still WIP, more on this later)
@Tasssadar for MultiROM all together
@Unjustified Dev for his influence
Progress
Working: Multirom TWRP has been successfully compiled for flounder and has working ADB and MTP.
Partially Working WIP: MultiROM boot selector source has been ported to work with arm64. The multirom boot selector compiles for flounder in zip format and launches at device boot. However, touch does not work and there is no ADB at the moment.
Not Working WIP: The kexec hardboot patch currently does not work so the Nexus 9 is currently unable to boot another ROM other than the primary one.
Source
All sources can be found here (I know some of them may not work and may be a little messy but this is still a work in progress)
Device Tree
Kernel
MultiROM
MultiROM TWRP
Building Notes
I compile this with the CyanogenMod Device Tree. Instructionsfor building multirom can be found on the multirom wiki found here
Note: adbd and kexec-tools need to be replaced with these versions that are arm64 compatible
adbd kexec-tools
If you would like to contact me on hangouts about this, please PM me your Gmail.

Reserved

One more

I might have found a repository that may help us out with the kexec hardboot patch on arm64.
There are many commits here that relate to kexec on arm64

Very glad to hear!! Sooper work :thumbup::thumbup: :beer:

This may also pose useful for the arm64 instructions
...

Looks like kexec-tools may need to have a lot of changes for arm64.
There are the changes made on a more recent version or android tools (not the one for android/multi-rom). I think this commit may be helpful but changes would have to be made.

Re-based many of the repositories on MR64 the other day. Now I need to test....
Also, the kexec tools function for flounder is completely re-written so maybe kexec will work?
I'll have to try to test when I have a lot of free time...

Is this going to work to get Linux kexecboot working? I really would like to have Linux running natively on this tablet....

Any updates on the project?

Any news on this, hoping for developments so that progress can be made for oneplus2 and multirom?
Thanks

Hello, and whether support for Nexus 9?

@Hashbang173
What's the status of this ?

omerjerk said:
@Hashbang173
What's the status of this ?
Click to expand...
Click to collapse
I have tabled development for this until further notice.

Hashbang173 said:
I have tabled development for this until further notice.
Click to expand...
Click to collapse
Is there any deving goin on on this? I think its way too hard. kexec isnt x64 compatible. (The binary itself isnt. How will youll port hardboot ) First we will have to add x64 support to that. I have seen your commits. That isnt x64 supported too.
Please update me on this, im building on op2 if this works. Thanks <3

regalstreak said:
Is there any deving goin on on this? I think its way too hard. kexec isnt x64 compatible. (The binary itself isnt. How will youll port hardboot ) First we will have to add x64 support to that. I have seen your commits. That isnt x64 supported too.
Please update me on this, im building on op2 if this works. Thanks <3
Click to expand...
Click to collapse
I'm no dev but could this be helpful for kex ec on ARM64? https://www.spinics.net/lists/arm-kernel/msg462969.html

Hashbang173 said:
I have tabled development for this until further notice.
Click to expand...
Click to collapse
I know you've put this project on hold for the time being, but I would like to jump in on this dev-tastic venture. I got a Nexus 9 (LTE) for Christmas*, and wanted to let you know that you don't have to bear the burden of building/testing/debugging/etc. all by yourself. I am fairly well versed in the mechanics of MultiROM, and have been (and still am) a user of MR on my Nexus 7 (2013) since v28 . . and honestly, without MR on my Nexus 7, I probably wouldn't have the pen. testing abilities that have enabled me to offer those additional services to my clients (i.e., security consultation, data breach prevention, etc.).
My point is that I owe a lot to Tasssadar and the "MultiROM for Android" concept in general, so I am happy to give back in any way that I can.
The Nexus 9 has been my dream Android device ever since the rumor mill was buzzing with notions of a Nexus tablet with an ARM v8 (ARM64) based Tegra variant!!
Let me know if/when you wanna get this thing off the ground again, and I'll make myself available as much as possible.
FULL DISCLOSURE: Although I am fairly versed regarding MultiROM and it's mechanics (kexec-hardboot, modifications to TWRP, etc.), I don't have much experience when it comes to ARM v8. However, I am pretty fluent regarding desktop x64 programming applications and coding, so it shouldn't be too hard for me to wrap my head around this whole ARM v8, 64-Bit SoC/MoP revolution. If you (or anyone who knows) could fill me in on the challenges we are facing regarding kexec and hardboot in a 64-bit scenario, that'd be swell. In the mean time, I will do my best to get up to speed regarding the repos & commits you have referenced/linked up to this point.
THANK YOU FOR ALL OF YOUR HARD WORK THUS FAR, AND LET'S GET 'ER DONE MY FRIENDS!!
:fingers-crossed:
*BEST . . CHRISTMAS . . PRESENT . . EVER!!!!!!
Thanks Mom!!

They have a Multirom version working for the Nexus 6P which is an arm64 device using the kexec method. Here is the link if it helps you devs.
http://forum.xda-developers.com/nexus-6p/development/mod-multirom-v33-beta-1-t3313291

rifraf1 said:
They have a Multirom version working for the Nexus 6P which is an arm64 device using the kexec method. Here is the link if it helps you devs.
http://forum.xda-developers.com/nexus-6p/development/mod-multirom-v33-beta-1-t3313291
Click to expand...
Click to collapse
yep, I ported it to clark already, maybe I'll try porting it to flounder in the future

Multirom for yureka aka tomato (64bit snapdragon 615) is also coming today with kexec-hardboot patch. Hope other devices also get this fast

Related

Slight clarification for DEV's trying to port CM

THIS IS NOT A ARM DEVICE ! This is x86. Porting CM to this device would be an incredibly complex task as alot of CM code is ARM dependent. You are going about this the wrong way , these are two completely unrelated CPU architectures , you need to look at the Android X86 projects that are out there which I will link too at the end of the post.
ARM is vastly different from x86 and you can't run code designed for one on the other.
NO ROM for ARM will work on this , meaning no CM , no AOKP , no MiUi , and not even AOSP etc.
You need to work with the Android x86 sources provided by either Intel or the community x86 port.
Links :
http://www.android-x86.org
https://01.org/projects/android-intel-architecture
http://androvm.org/blog/
All these projects are FORKS of android highly modified to work on x86 !
lgstoian said:
THIS IS NOT A ARM DEVICE ! This is x86. Porting CM to this device would be an incredibly complex task as alot of CM code is ARM dependent. You are going about this the wrong way , these are two completely unrelated CPU architectures , you need to look at the Android X86 projects that are out there which I will link too at the end of the post.
ARM is vastly different from x86 and you can't run code designed for one on the other.
NO ROM for ARM will work on this , meaning no CM , no AOKP , no MiUi , and not even AOSP etc.
You need to work with the Android x86 sources provided by either Intel or the community x86 port.
Links :
http://www.android-x86.org
https://01.org/projects/android-intel-architecture
http://androvm.org/blog/
All these projects are FORKS of android highly modified to work on x86 !
Click to expand...
Click to collapse
What about use a base of stock roms and make the things work??? I know Cm its for armv, but all its adaptable,
Enviado desde mi XT890 usando Tapatalk 2
as for MIUI (there already is a MIUI port on the razr i, not complet I think, but it exist). MIUI is mostly a framework mod.. this is platerform independant AFAIK.
I don't think CM & Cie are so dependant of the SoC architecture. There's lot of différences between some ARM SoC .. maybe more than you can imagine. If CM can be adapt to so many device with so many ARM SoC witch a so différent, why not for a x86 Soc ?
I think you're a little bit pessimist here...
I didn't say it's impossible but it's more complex then a normal port for an ARM device. The issue is it requires more knowledge on the issue and will eat far more time. A CM port to x86 is a very unlikely goal for a single dev , and I'm saying this because a few months ago I discussed this issue with the people behind Android x86.
So a talented DEV will be able to achieve this but it will take time and a bigger struggle , that's why to start of developing for this device it would be more reasonable to look at Android code already ported to x86.
lgstoian said:
THIS IS NOT A ARM DEVICE ! This is x86. Porting CM to this device would be an incredibly complex task as alot of CM code is ARM dependent. You are going about this the wrong way , these are two completely unrelated CPU architectures , you need to look at the Android X86 projects that are out there which I will link too at the end of the post.
ARM is vastly different from x86 and you can't run code designed for one on the other.
NO ROM for ARM will work on this , meaning no CM , no AOKP , no MiUi , and not even AOSP etc.
You need to work with the Android x86 sources provided by either Intel or the community x86 port.
Links :
http://www.android-x86.org
https://01.org/projects/android-intel-architecture
http://androvm.org/blog/
All these projects are FORKS of android highly modified to work on x86 !
Click to expand...
Click to collapse
Sure there is some ARM dependent code in the repos but most of android doesn't really depend on the arch (like apps using the sdk dont need to be recompiled for working on the I, see play store apps). I have worked with o1 and android-x86 and there isn't really that much change from CM and android-x86, just some extra optimizations for x86 which can be added in later.
There are plenty of device on where even custom rom seems to be impossible. mostly because of a locked bootloader.
Look at the Motorola Defy. At the beginning, the development of a custom rom like CM was pretty impossible.... but they did it. They did it so far that the Defy became one of must used device with Cyanogenmod. And you now the most astonishing? It's thanks to only 2 devs.
I think bypassing a locked bootloader like the Moto one is far more tricky than adapting a CM ROM to a x86 SoC (while the device is natively unlocked).
AFAIK, android-x86 project is not so close to the Android we have on our phone.
When you develop a custom rom you can either take the AOSP source and try to put it on your phone : the tricky way. Mainly when you don't have access to the source of the drivers (ARM or x86 .. same fight)
Or you can take the official rom and mod it to reach the AOSP/CM/MUI/etc level. And I think on most device it's the way to go (unless the manufacturer release all the source code of the device.... something that never appends).
lgstoian said:
THIS IS NOT A ARM DEVICE ! This is x86. Porting CM to this device would be an incredibly complex task as alot of CM code is ARM dependent. You are going about this the wrong way , these are two completely unrelated CPU architectures , you need to look at the Android X86 projects that are out there which I will link too at the end of the post.
ARM is vastly different from x86 and you can't run code designed for one on the other.
NO ROM for ARM will work on this , meaning no CM , no AOKP , no MiUi , and not even AOSP etc.
You need to work with the Android x86 sources provided by either Intel or the community x86 port.
Links :
http://www.android-x86.org
https://01.org/projects/android-intel-architecture
http://androvm.org/blog/
All these projects are FORKS of android highly modified to work on x86 !
Click to expand...
Click to collapse
You really know what you are talking about? As others already mentioned above CM is in most a framework - porting android to x86 seems to be not such a big gap as motorola did it already and for sure you can run android on your pc - do you own an arm pc (in this case i think an rasperry pi...). The toolchain remains the same so why you make such a story out of it? Are you a razr i owner or do you just want to frighten all razr i devs and owners awaiting a CM port??
ARM architecture is different in some points but most of the work will do the compiler and to be honest i think there will be some more x86 phones in the future, intel never developed it for one or two phones....
So what is your intention with this topic??
kind regards.
lord0815 said:
So what is your intention with this topic??
Click to expand...
Click to collapse
That's what I'm wondering. Any dev that's taking on this task obviously knows it's going to take a bit of extra work. It would have been different had the OP offered some help and advice, but he just posted the obvious while making it seem like a bigger deal than it is (at least I'm guessing it's not as big a deal as he makes it seem, considering the other posts in this thread). Nothing but fear mongering and pessimism at this point. Sure, we will have to wait a bit for the devs to figure things out, but I know enough of them picked up this phone that something will eventually come. Plus, there seems to be a bit of dev interest in the Intel Yolo as well.
I don't know much about porting or developing and getting cm to run with all the necesary source and drivers is probably not easy but I do know that one of the basic options when running the build/make command for AOSP and CM is an x86 build for emulation. So basic x86 infrastructure exists does that ensure compatibility with this phone maybe not but it might help and certainly it would still require SOC and device optimization drivers but its probably the better place to start then tackling trying to port ARM based code and drivers.
However in the meantime my thinking is maybe a CM style rom could be achieved by first stripping down the rom making it "blurless" and then porting CM features especially since the latest Moto ROM's are comparatively closer to stock then sense or touchwiz. Of course I don't have the phone yet its in England waiting to be brought to me.

Anyone have resources for porting ROMs?

I've been wanting to get into porting ROMs, although I'm not too sure how to go about it. I have a few in mind I'd like to attempt to bring to our device. Does anyone have any resources/links/videos on how to go about porting? Everything would be greatly appreciated
Which ROMs do you have in mind? I might be able to help.
P.S: You can look in the LineageOS porting instructions for our device, if that's going to help you!
proudlytm said:
Which ROMs do you have in mind? I might be able to help.
P.S: You can look in the LineageOS porting instructions for our device, if that's going to help you!
Click to expand...
Click to collapse
A few of the ones I've been thinking would be a good fit for this phone is the Pure Nexus Project, Slim7 (Want to get a fully working build of that going, love Slim7 haha), OmniRom, and lastly a MIUI port once I get the basics down.
I use macOS, but also have a virtual machine for both Windows 7 & 10 and Ubuntu and Fedora so any guides across any platforms help.
fireball0093 said:
A few of the ones I've been thinking would be a good fit for this phone is the Pure Nexus Project, Slim7 (Want to get a fully working build of that going, love Slim7 haha), OmniRom, and lastly a MIUI port once I get the basics down.
I use macOS, but also have a virtual machine for both Windows 7 & 10 and Ubuntu and Fedora so any guides across any platforms help.
Click to expand...
Click to collapse
I know different ROMs use different structures for device trees, but here's a guide to compiling Lineage 14.1 to the G4 Play. This guide is made for Ubuntu 14.04/15.04/16.04, but Fedora might be able to work as well as long as you can get the proper packages installed during the prerequisite steps:
http://wiki.lineageos.org/harpia_build.html
It may not help much with other ROMs, since I'm not sure if the other ROMs support using CM/Lineage based device trees to build, but this will give you the basic instructions on how to download source, get the proprietary blobs/device tree you need, and compile everything to a working zip.
As for actually making device trees for other ROMs to use during compilation, that I don't know myself, and was never really able to find out.
I build on Fedora. If you're using Fedora 25, use these steps to set up a build environment: https://gist.github.com/sultanqasim/09f19221c67c71edd099eb86c6a92467

[GUIDE] [Future] [news and build Oreo] Oreo Go Older Oreo Device and or Trebel Dev

Update News Flash Galaxy note 4 running Oreo 8.1
3-29-18
OMG. I said it here first. 32 bit processors CAN be ported to Oreo. Maybe not trebel yet. Smug emoticon
In just a few days , not even I thought it was possible.
Running Oreo via lineageOS 15.1 with root on my Samsung Galaxy Note 4.
The dev who devotes time to compiling builds @ripee has had his daily downloads of 14.1 for the note 4 has more than doubled. Currently running about 250 users testing builds. SMOKIN.....
Here is the OP
https://forum.xda-developers.com/no...0-unofficial-lineage-15-1-rom-t3760969/page92
Update 2-28-18
OpenGapps 8.1 is released for both arm and arm 64.
That means Oreo can be compiled it 32 bit.
Researching Oreo and Oreo go compiler instructions.
Mebbe I can compile AOSP for my older Note 4 .. So cool
https://forum.xda-developers.com/android/apps-games/arm-unofficial-opengapps-builds-android-t3743495
Updated 1-20-18
Newest musings on top. Oreo Go is currently being modded into an older Sony phone. Awesome
So since I posted this OP...my musings have been correct in these posts.
This came out on XDA, check out the links in it.
https://www.xda-developers.com/android-go-old-android-8-1-oreo/
Android Oreo and android in general is getting closer to Linux . Mainly for the same reasons
I have been installing different distributions of Linux on an older laptop.
1. To learn installing hard to find drivers
2. Learning Linux architecture and commands
3. Learning to build Linux kernel for my device
http:// www.kernel.org
4. Learning to build lineageos14 in general
With these guides
https://forum.xda-developers.com/note-4/general/guide-build-lineageos-14-1-trltexx-t3567885
Thanks @_mone and @ripee
https://forum.xda-developers.com/chef-central/android/how-to-build-lineageos-14-1-t3551484
Thanks @FSadino
5. Actually compiling lineageOS-14 for my two devices I have access to
Galaxy note 4 Verizon thanks to @ripee for his contribution by building daily's at
https://forum.xda-developers.com/note-4/snapdragon-dev/rom-lineageos-14-1-t3536401
And my galaxy tab S2 sm-t710
Thanks to @Bonuzz for getting the camera, mic GPS and Bluetooth working, and posting sources
https://forum.xda-developers.com/tab-s2/development/t710-t715-lineage-14-1-t3713097
Thanks to @Ather for getting Samsung to release their Kernel sources and building a android 7 rom
https://forum.xda-developers.com/tab-s2/development/kernel-poseidonkernel-v1-0-permissive-t3588069
https://forum.xda-developers.com/tab-s2/development/rom-poseidonrom-v1-0-deodexedrooted-t3590228
6. Thinking and musing about things
Symlinks, multi boot, and partitions. ( Treble )
In Linux, I have another partition with downloaded files on another drive
When the kernel boots, the directory tree just sees /data even though it's a separate drive
This is because of a symbolic link that mounts the partition as a folder. This prevents me, from deleting that data with permissions
So the Trebel rules tell the vendor to make a separate partition in the drive but the kernel gets a symbolic link to it, and the user (Google) cannot over write the partition with the critical info..when the ROM gets flashed? correct ?
The bootloader has boot path a, or boot path b.
The user files are in protected memory
So with Linux, when I updated my kernel,
The grub bootloader tells me I can use kernel 4.1.x or 4.2.x when I boot
The kernel loads the drivers
And then looks at the symbolic links to mount the drives.
This is somewhere in the /etc files or somewhere
So Trebel has to be a set of decision trees based on symbic links to hardware
Where all the hardware drivers are independent of the kernel
More musings later. Must build....
**************
Dec 2017 sometime
Thanks to all for viewing my first OP.
I'm just learning about building ROMs, and look forward to this thread to spitball ideas and see what sticks.
If I don't know something its because I am correcting my ignorance.
This won't be an actually development thread, just trying to understand hardware from 30 years of not being in the tech field.
Eventually I will tire or wear out of driving truck, and work with my passion again.
I am a follow the steps kind of mind, so I am learning how the world of Android / Linux works.
If I understand the Trebel development correctly...
https://www.xda-developers.com/goog...ze-android-so-oems-can-update-devices-faster/
IF we can modify the older device drivers to be Trebel compliant, then once they work, then they always should work. And any Trebel ROM can work on Any Trebel Device withOUT compiling over and over.
This should result in an explosion of custom ROMs .
So I am suggesting a repository of drivers per device that are compliant for older devices.
How do we do that?
So here is the Google announcement of Trebel
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html?m=1
Here is the developer preview of ”O”
https://developer.android.com/preview/download.html
It details how to install it on your Trebel Device.
Wow. Just Wow.
OH MY GOODNESS. I would love this on my lg g3, oneplus one, and moto e2. WOW.
TotalNoobTrucker said:
If I understand the Trebel development correctly...
https://www.xda-developers.com/goog...ze-android-so-oems-can-update-devices-faster/
IF we can modify the older device drivers to be Trebel compliant, then once they work, then they always should work. And any Trebel ROM can work on Any Trebel Device withOUT compiling over and over.
This should result in an explosion of custom ROMs .
So I am suggesting a repository of drivers per device that are compliant for older devices.
How do we do that?
Click to expand...
Click to collapse
How do you wanna to do that ?
Vendor files are NOT open-source so you cannot make them treble enabled sadly.
Haxk20 said:
How do you wanna to do that ?
Vendor files are NOT open-source so you cannot make them treble enabled sadly.
Click to expand...
Click to collapse
So far all it looks like ROM dev is trial and error with people posting guides on repeatable success... (Community)
I haven't built a ROM, ( haven't built a compiler computer yet) plus I drive truck 70 hrs a week..
but have read
https://forum.xda-developers.com/chef-central/android/guide-android-rom-development-t2814763/
And
https://forum.xda-developers.com/android/software/how-to-port-samsung-rom-to-samsung-t3481114/
So what's different in the building process? With Trebel?
Google dev page lists an additional partition for drivers called VENDOR
A file called manifest.xml
And a A/B partition.
So assuming I am building a Lineage OS ROM 14.x
In that compile process, everything is compiled in the ROM
Kernel, Lineage front end, AOSP programs etc.
So somewhere in the compiler process the drivers to my N910V are pulled in from somewhere? Github¿?
If they are not open source, they were pulled from system image via ADB or Android image kitchen and uploaded to where?
So i guess we need a guide on how to build Trebel for non Trebel devices. The folks on the other Trebel thread are doing it on newer devices and getting some exciting results.
There is only a couple of Lineage 15.x builds going, but once someone has the Process down to build a Trebel on non / close to Trebel hardware,
It should be repeatable for ANY Oreo and up compiled ROM.
I may not be able to build yet, but since Trebel is the new path, I want to gather Trebel success and Process here. Maybe make a guide..
In conclusion, the drivers may not be open source, but the code is out there somewhere.
Sent from my Lineage OS 14 Samsung Verizon Note 4 from @ripee
My other device is a Samsung T710 running Posiedon 1.0 . Thanks for a stable rooted tablet @Ather
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
So far all it looks like ROM dev is trial and error with people posting guides on repeatable success... (Community)
I haven't built a ROM, ( haven't built a compiler computer yet) plus I drive truck 70 hrs a week..
but have read
https://forum.xda-developers.com/chef-central/android/guide-android-rom-development-t2814763/
And
https://forum.xda-developers.com/android/software/how-to-port-samsung-rom-to-samsung-t3481114/
So what's different in the building process? With Trebel?
Google dev page lists an additional partition for drivers called VENDOR
A file called manifest.xml
And a A/B partition.
So assuming I am building a Lineage OS ROM 14.x
In that compile process, everything is compiled in the ROM
Kernel, Lineage front end, AOSP programs etc.
So somewhere in the compiler process the drivers to my N910V are pulled in from somewhere? Github¿?
If they are not open source, they were pulled from system image via ADB or Android image kitchen and uploaded to where?
So i guess we need a guide on how to build Trebel for non Trebel devices. The folks on the other Trebel thread are doing it on newer devices and getting some exciting results.
There is only a couple of Lineage 15.x builds going, but once someone has the Process down to build a Trebel on non / close to Trebel hardware,
It should be repeatable for ANY Oreo and up compiled ROM.
I may not be able to build yet, but since Trebel is the new path, I want to gather Trebel success and Process here. Maybe make a guide..
In conclusion, the drivers may not be open source, but the code is out there somewhere.
Sent from my Lineage OS 14 Samsung Verizon Note 4 from @ripee
My other device is a Samsung T710 running Posiedon 1.0 . Thanks
Click to expand...
Click to collapse
The OEM needs to add support for treble there is no treble for non-treble devices.
Treble works like so:
Vendor files are stored in separate partition (Those files are edited to work with treble)
Then android just takes those files from there and work.
The vendor files are not in system.img but in /vendors (the partition is mounted here)
Only a few devices have vendor files open source there is possible to make the device treble supported but 99% of devices have vendor files closed and so its not possible for some dev here to make the device supported.
Also A/B is new partition layout:
You have your system on A but once update is available its downloaded onto B and then it just switch them (Don't read about that much so I canbe wrong here).
Also I have build ROM for xperia P and if I wanted to build 8.0.0 I cannot use treble sadly that would have made my job lot easier.
Hmm.
Haxk20 said:
The OEM needs to add support for treble there is no treble for non-treble devices.
Treble works like so:
Vendor files are stored in separate partition (Those files are edited to work with treble)
Then android just takes those files from there and work.
The vendor files are not in system.img but in /vendors (the partition is mounted here)
Only a few devices have vendor files open source there is possible to make the device treble supported but 99% of devices have vendor files closed and so its not possible for some dev here to make the device supported.
Also A/B is new partition layout:
You have your system on A but once update is available its downloaded onto B and then it just switch them (Don't read about that much so I canbe wrong here).
Also I have build ROM for xperia P and if I wanted to build 8.0.0 I cannot use treble sadly that would have made my job lot easier.
Click to expand...
Click to collapse
So where are the Xperia P files you imported into your 8.0 biuld¿ Can't you put them in the vendor folder and see if it boots¿ I presume you have to make a manifest.xml file so the ROM can see the files
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
So where are the Xperia P files you imported into your 8.0 biuld¿ Can't you put them in the vendor folder and see if it boots¿ I presume you have to make a manifest.xml file so the ROM can see the files
Click to expand...
Click to collapse
I haven't done 8.0.0 build yet cause the device got only CM-12.1 and now trying to port 8.0.0 and no putting the files there will not work:
1. Old devices don't have that partition and evenif I reformat it and add it and edited fstab to see it.
2. The files NEEDS TO BE EDITED TO WORK WITH TREBLE. If it was that easy to make partition put there the files and tadaaa treble device then every old device could get 8.0.0 to run but well I don't see threads about it. It's not that easy you NEED THE SOURCES TO MAKE IT TREBLE ENABLED.
Haxk20 said:
I haven't done 8.0.0 build yet cause the device got only CM-12.1 and now trying to port 8.0.0 and no putting the files there will not work:
1. Old devices don't have that partition and evenif I reformat it and add it and edited fstab to see it.
2. The files NEEDS TO BE EDITED TO WORK WITH TREBLE. If it was that easy to make partition put there the files and tadaaa treble device then every old device could get 8.0.0 to run but well I don't see threads about it. It's not that easy you NEED THE SOURCES TO MAKE IT TREBLE ENABLED.
Click to expand...
Click to collapse
Sadly, I think android 8.1 trebel is 64 bit. My note 4 is a 32bit arm71
So I dunno how it could run on my note 4. However the nexus 6 is the same cpu hardware as the note 4
However the nexus 6p is the 8core with 2 other core chipset, which is 64 bit and supported by 8.1 Trebel
So me thinks the older devices are not able to run trebel
Sent from my Samsung SM-N910V using XDA Labs
TotalNoobTrucker said:
Sadly, I think android 8.1 trebel is 64 bit. My note 4 is a 32bit arm71
So I dunno how it could run on my note 4. However the nexus 6 is the same cpu hardware as the note 4
However the nexus 6p is the 8core with 2 other core chipset, which is 64 bit and supported by 8.1 Trebel
So me thinks the older devices are not able to run trebel
Click to expand...
Click to collapse
Yeah that's another problem even if there was a way to edit vendor files treble is 64bit only
If I undertand it correctly, there's another layer between the HAL and the android framework, the HIDL, which decribes the interface of the HAL.
Shouldn't we theorically be able to edit that?
The good news is my sm-t710 is a exynos5433 chipset which supports 64bit. So maybe I will get to play with 8.n someday
android1111 said:
If I undertand it correctly, there's another layer between the HAL and the android framework, the HIDL, which decribes the interface of the HAL.
Shouldn't we theorically be able to edit that?
Click to expand...
Click to collapse
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
As I said above you NEED the vendor file sources then create /vendor partition to add the vendor files there.
Without sources you can't make Treble running.
So if you ever want to play with 8.0 on your phone you should start porting right now.
---------- Post added at 10:42 PM ---------- Previous post was at 10:41 PM ----------
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
I mean porting as the "hard way" = modifying device tree to work with new sources and patching the sources.
Haxk20 said:
As I said above you NEED the vendor file sources then create /vendor partition to add the vendor files there.
Without sources you can't make Treble running.
So if you ever want to play with 8.0 on your phone you should start porting right now.
---------- Post added at 10:42 PM ---------- Previous post was at 10:41 PM ----------
I mean porting as the "hard way" = modifying device tree to work with new sources and patching the sources.
Click to expand...
Click to collapse
I get that to begin the process for non Trebel, that's the idea.
Move all the vendor libraries to the vendor file, and run them through the Google process to make them compliant.
I would have to find a piece of hardware that has the same SoC just to begin.
No wonder the note 4 stalled at 6.0.1, verizion want going to rewrite the code. Just to get to 7. They would rather sell note 8's
Sent from my Samsung SM-N910V using XDA Labs
See scenario 2 on
source android com devices architecture hidl-cpp
We need to code o adapt a passthrough HIDL
It's not a matter of editing a file
TotalNoobTrucker said:
I think so. If you look at the other forum, it seems they're editing only a couple files. The manifest.xml describes what files are the drivers and where to look for them. This is a crucial file, as the drivers are in a separate partition from the system/data partition now. Download one and read it .it's a very simple exchange script
Click to expand...
Click to collapse
It's not a matter of editing a file to tell Android and the kernel where to look for drivers. We are not "editing" manifest.xml, it is generated during the build process. The whole structure and system calls of the drivers is changed to make them suitable for treble. And that is done by the SoC vendor whomever they may be. You can build Oreo to work on older devices by using your existing drivers, but not by using treble, you have to use your existing kernel, and write your own "hooks" into your existing drivers (better be familiar with hex code), and do a LOT of modifications to the Android code. Treble is not intended as a way for older devices to get custom ROMs, as their pre Oreo kernels and drives are not capable.
A N00b's explanation of Project Treble
Okay so I've seen a lot of confusion about how Project Treble does and does not work, so I'm going to provide a small explanation, simplified to a fault, but it'll do:
In ye olden days (Nougat and back), the Android OS was very tightly integrated with the drivers of the system. This made custom firmware very difficult to port (relatively speaking). Certain drivers were more difficult to make workable and as a result you'd have work in progress ROMs that didn't have WI-FI or cameras working, etc. It really was a pain in the butt.
Project Treble changes all of that. What it does is separate the operating system from the drivers, making porting much easier for devices that support it. The problem is that in order to enable this it would require almost a complete rebuild of these drivers, which would in turn require access to the source code and a LOT of work (hence why companies like OnePlus are releasing devices with Nougat so they don't have to use Treble, which is required on all devices that start with Oreo).
In short, COULD Treble be ported to older devices? Yes; Google and Essential have proven that. Is it feasible? Unless you've got some friends at Samsung/HTC/Xiaomi/insert-other-company-here willing to leak source code, no not really. The only device that I could possibly see getting a Treble port is the HTC HD2, simply because that phone is basically the technological equivalent of a cockroach, and I think they may have actually reverse engineered their drivers to get them to work on so many operating systems. I know I've probably made some mistakes in my explanation, but it's my best way if simplifying how this works so that people don't come along, see Treble and expect an Oreo ROM for their Fire Phone or something
2390 said:
Okay so I've seen a lot of confusion about how Project Treble does and does not work, so I'm going to provide a small explanation, simplified to a fault, but it'll do:
In ye olden days (Nougat and back), the Android OS was very tightly integrated with the drivers of the system. This made custom firmware very difficult to port (relatively speaking). Certain drivers were more difficult to make workable and as a result you'd have work in progress ROMs that didn't have WI-FI or cameras working, etc. It really was a pain in the butt.
Project Treble changes all of that. What it does is separate the operating system from the drivers, making porting much easier for devices that support it. The problem is that in order to enable this it would require almost a complete rebuild of these drivers, which would in turn require access to the source code and a LOT of work (hence why companies like OnePlus are releasing devices with Nougat so they don't have to use Treble, which is required on all devices that start with Oreo).
In short, COULD Treble be ported to older devices? Yes; Google and Essential have proven that. Is it feasible? Unless you've got some friends at Samsung/HTC/Xiaomi/insert-other-company-here willing to leak source code, no not really. The only device that I could possibly see getting a Treble port is the HTC HD2, simply because that phone is basically the technological equivalent of a cockroach, and I think they may have actually reverse engineered their drivers to get them to work on so many operating systems. I know I've probably made some mistakes in my explanation, but it's my best way if simplifying how this works so that people don't come along, see Treble and expect an Oreo ROM for their Fire Phone or something
Click to expand...
Click to collapse
So who do we know at Samsung/HTC/Xiaomi ?
Haha.
Or better yet who do we ask there? Do they have only internal development? Customer service? How do some Devs get source code? When a company releases a developers version ( thankfully someone had a way to flash a dev version 5.1.1 of my verizion note 4 so it could get a ROM.. ), does the developers edition phone come with the support and access of developers?
The reason I ask. Is I used to have MSDN access when I worked at [email protected]#$0ft . just asking again. What's the path to be a developer from a builder like Samsung?
Good luck with that
TotalNoobTrucker said:
So who do we know at Samsung/HTC/Xiaomi ?
Haha.
Or better yet who do we ask there? Do they have only internal development? Customer service? How do some Devs get source code? When a company releases a developers version ( thankfully someone had a way to flash a dev version 5.1.1 of my verizion note 4 so it could get a ROM.. ), does the developers edition phone come with the support and access of developers?
The reason I ask. Is I used to have MSDN access when I worked at [email protected]#$0ft . just asking again. What's the path to be a developer from a builder like Samsung?
Click to expand...
Click to collapse
You're going to have better luck getting blood out of a rock than that. Even when they have "developer" editions of phones they don't give you access to their code, that just means it's totally unlocked for you to f*** up or flash ROMs to. The phone manufacturers get the drivers for the SoC from the manufacturer of the chip, and except in binary form that never leaves and stays in house. Only way you're going to get that is by knowing someone who works at Qualcomm, Samsung, etc. who is willing to risk being fired, sued, thrown in jail, or all of the above for stealing the source code and leaking it to you. When a phone manufacturer releases "source code" if you examine it you will find that those closed source drivers are not included, you can build it but a lot of things won't work. (Besides the fact that it is always outdated code).

[INCOMPLETE] [NOT WORKING] Sailfish OS 2.1.4.13

I began some work on Sailfish OS, but as I only have the Moto Z as the daily driver, it is too tiresome and time consuming to continue this.
If someone is willing to give it a try to get it working, you are welcome to use my repos:
https://github.com/Loader009/droid-hal-griffin
https://github.com/Loader009/droid-hal-version-griffin
https://github.com/Loader009/droid-config-griffin
Kernel: https://github.com/Loader009/android_kernel_motorola_msm8996/tree/hybris-14.1
Devtree: https://github.com/Loader009/android_device_motorola_griffin/tree/hybris-14.1
My first test build (not booting - either it is in Sailfish OS but screen is frozen or it is frozen in bootloader):
https://androidfilehost.com/?fid=5862345805528066716
Here is a howto to get the building environment done (pretty hard to get it working)
(you will need to build Sailfish on your native OS, instead in the ubuntu environment
[because the ubuntu environment I used, did not support openjdk8, which is required for the devtree and kernel],
the packages [not the ROM/kernel] need to be build as in the howto described):
https://sailfishos.org/develop/hadk/
It looks like the howto has been updated since I used it last time.
edit: This FAQ is gonna be useful too: https://public.etherpad-mozilla.org/p/faq-hadk
If you need help, please use the IRC channel of that link right above.
In the topic of the IRC channel are some more useful links, be sure to read them before questioning others.
Good luck!
Loader009 said:
I began some work on Sailfish OS, but as I only have the Moto Z as the daily driver, it is too tiresome and time consuming to continue this.
If someone is willing to give it a try to get it working, you are welcome to use my repos:
Click to expand...
Click to collapse
Thanks, I have a spare Moto Z so I may give it a try. I still use SFOS (Sailfish X) at the moment.
mick3_de said:
Thanks, I have a spare Moto Z so I may give it a try. I still use SFOS (Sailfish X) at the moment.
Click to expand...
Click to collapse
I have a spare one too but i won't be able to help much except for testing. I'm very interested in SFOS but never got the chance to try it

Mainline N8000 Progress

Dear fellow developers and users of this great device,
I'm working on mainline support for the p4note device family, I started with the N8010 but this is usable on all the other N80XX devices as well as they are technically all the same aside from the modem.
The current status is that an initial device tree will land in 5.11 with some components still missing but its a good start. I'm working on the rest and also I'm working on Android 11 on top of that.
This post will not be updated any longer, you can find my mainline progress here.
There is also a blog which I'll probably woefully neglect as I'm way too busy with everything in life.
Cheers
An update for my mainline progress, there is kernel logs on the display now! I'm currently working on the touch screen config.
Oh Nice to see.
But i think not many people read the General forum anymore ^^
You might want to mention this in the Dev thread.
Do you have a git repository anywhere? I found a Note 10 8000 hidden in a box and wanted to get a working small working terminal up on the wall at my 3D-Printer/Soldering-workstation, I would be happy to be tinkering around som with the code.
Nevermind, found it.
fldc said:
Do you have a git repository anywhere? I found a Note 10 8000 hidden in a box and wanted to get a working small working terminal up on the wall at my 3D-Printer/Soldering-workstation, I would be happy to be tinkering around som with the code.
Nevermind, found it.
Click to expand...
Click to collapse
Hey, great to hear that you want to tinker with it. Remember that I currently work on rev 6 of the hardware, the version info can be found in the atags of the kernel log. You may run into issues with other revisions but it should be fine.
For the wifi settings, you need the correct nvram file. I'm not yet sure whether you can determine it by the version of the hardware, the current way is a macloader in the current hardware repo.
I extracted the touchscreen firmware from the sources and put them in my buildroot repo. The driver will look for a file called maxtouch.fw on boot.
I hope this helps.
Thank you very much for the pointers, I haven't t really been into kernel development since Samsung Galaxy S2 (9100), but getting a proper Linux installation on this device would fit me perfectly so I would happily try things on my side, keep us posted.

Categories

Resources