Related
Hiya I am interested in compiling my own version of the android project from the latest sources for Hero but I am having a little bit of trouble, I have been attempting to follow this guide android.modaco.com/index.php?showtopic=301857&view=findpost&p=1179830 but it does not seem to make a lot of sense to me. For instance there is no .repo/local_manifest.xml file only a .repo/manifest.xml file and editing this as outlined gives me an error. Could somebody point me in the direction of a fairly noob friendly guide for this kind of stuff, thanks a lot.
Conb123
P.S Sorry about the dodgy link, newbie restrictions prevented me from formatting it properly
this should be in Q&A Section not development really. But im looking for this too! installed ubuntu using Wubi set up JDK,SDK testsign etc and repo but god knows how to do it all! I only want to port cyanogenROM
follow this: http://source.android.com/download
when you got everything synced you can basically type "make" and watch it compile for a while. i managed to do it with just above zero knowledge about compiling.
if you want the cyanogen sources try it with the according repo. i have zero idea about vendor overlays, as i needed to compile only the recovery (watched two hours of eclair compiling, then was told i need cupcake sources and can compile the recovery only...)
Yes I am aware of how to get sources and how to compile them, I am fairly well versed in linux. But I do not know how I can compile it into a usable rom for hero.
the result of the compiling are image files that can be flashed to the phone: system.img etc. you can extract them using unyaffs.
I ran the make command, but i really have no idea what to do from there. What is the end result of doing the first make command? Im fairly sure that it is not a single .img file you can flash onto your phone. You need to make a kernal if i am correct(anyone know how to do this?)
the result of the compiling is at least a system.img. if you compiled it correctly you can flash that to /system partition. further you need a boot.img, which also contains the kernel. the the rom-cooking howto in dev section how to create one, or just get one from a working rom.
fwiw, the .img files are in out/target/product/generic/ (although there probably is a device specific directory in there if you handled the vendor overlay correctly. <- this is just a guess, i have actually no idea).
Wanna link us to that how to thread? I cant seem to find a complete one with working links.
http://forum.xda-developers.com/showthread.php?t=551711
Hi, I'm trying to build CM13 for my phone, using UBUNTU.
The last thing I modified was kernel header files, and after modifying some of them, I tried to build full(make bacon or brunch) rom sources. But, it looks like it does not work, but there comes out no error. Just stuck in reading makefiles.
Accroding to make bacon -d command, it is stuck at build/core/cleanspec.mk.
I left this for about 10 mins, but nothing has changed.. I know that if it is normal, this should not be this long.
Google searched already but didn't find any helpful threads for me, so I'm asking here for some help. I already did make clean or make clobber whatever things that erases old files, and also tried for rm -rf ~/.ccache but does not work. Also tried to change toolchain but doesn't work.
ANY HELPFUL THREADS OR ANSWERS WOULD BE REALLY APPRECIATED!
"Blobs" are the files specific to each device that we need in order to compile custom ROMS that work on our device. The process of finding them is tedious and slow... I have been picking away at them for months when I have time. There are over 600 files so far! But there are also references to files that are not being found. They are either missing, or they are not located where they are expected to be located. This is where I need help.
So, if you want to help, go HERE:
https://github.com/mightysween/android_vendor_motorola_payton
and look through the proprietary-files.txt file for anywhere that it says "warning".... and then search inside of the firmware (working on 8.0+ now, not 7.1 please) and try to track down the file that it says is missing [obviously, you will need a system dump, or to search on a rooted device]. If you find it, please post below like this:
LINE NUMBER OF THE WARNING (from github)
PATH TO THE MISSING FILE (relative to /system... in other words, don't inlude your own local path)
Once this file is complete, we can use it to automatically pull the correct vendor files into our build environments... having a working recovery, active kernel developement and completed vendor blobs should open us up to more development efforts.
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
mightysween said:
Also, if anyone has done any testing and knows of other proproetary files that are needed, please post them here so I can include them.
My time at the computer to work on this is really limited, so I have only identified a dozen or so daemons that definitely call for proprietary libs... I am sure there are more
Click to expand...
Click to collapse
Do you have a link to a system dump?
TheBassDude said:
I would love to pitch in on this but have zero experience with anything related to development. Do you think I could still be of help? Sounds like a basic enough task that it wouldn't be too difficult. Let me check and see that I understand the process.
Went to github and looked at proprietary-files.txt. The first warning I found was in line 49: "blob file libpn553_fw.so missing or broken". Then searched for that file in my device's system folder using ES File Explorer with Root Explorer enabled.
So is this what you're looking for?
49
/system/vendor/firmware/libpn553_fw.so
---------- Post added at 14:31 ---------- Previous post was at 14:07 ----------
I'd like to contribute in some way but if this is best not left to a complete noob then I totally understand
Click to expand...
Click to collapse
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
QWZR said:
Do you have a link to a system dump?
Click to expand...
Click to collapse
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
Mine gets here next week
mightysween said:
Nah, too big to conveniently upload... but if you are rooted, you can use the phone to search
Click to expand...
Click to collapse
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
Any way that works is fine by me
I am on the road a lot and just don't have enough time to sit and work on it... so it is taking months. I bet a few people helping could finish it in a matter of hours.
I am hoping to have a few hours next week to work on it. But the sooner this is done, the sooner I can shift to trying to compile Lineage OS with working hardware.
BTW, Lineage *does* compile if I comment out all the stuff causing make errors... not much works, obviously.
The next step will be compiling with these blobs, then logging all the new errors and chasing down all the additional broken symlinks... and then adapting the kernel as needed.
Then, MAYBE we can get a base Lineage tree up and open up the X4 to building for other roms. I know someone started a skeleton tree for Carbon already on Github... they are likely just waiting for the completed device tree, too.
mightysween said:
Thanks, that is all there is to it
Just time consuming (especially after the first 500)...lol
Click to expand...
Click to collapse
ebrandsberg said:
If you have root on the system you can find the files for, you should be able to find any given filename with:
find / -name "filename" -print
And it should output any filenames that match. I don't have time at the moment to dig into this any more, but would this resolve much of it?
Click to expand...
Click to collapse
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
BLuFeNiX said:
I don't own this device yet, but I was thinking of getting one. I figured this might help you all out (you'll need to be running linux):
First, let's get a list of all the files on the phone, to make searching faster.
Code:
adb shell
su
find / > /sdcard/allfiles.txt
exit
exit
adb pull /sdcard/allfiles.txt
Now you should have allfiles.txt on your machine. Also grab the proprietary-files.txt, and then run this:
Code:
grep -Po '(?<=(blob file )).*(?= missing or broken)' proprietary-files.txt | xargs -I @ grep "@" allfiles.txt
That should find the paths of all the missing files (except the ones marked "wildcard")
Click to expand...
Click to collapse
Thanks, I had recently completed this, but your code worked fantastic for double checking, and actually helped me find one that I had missed :good:
Now, on to identifying any more daemons that need proprietary files... and then assembling the tree itself... PROGRESS!
PHASE 1 is complete!
https://github.com/mightysween/android_vendor_motorola_payton
I am 99% sure that this is only ~75% of what will be needed to actually build LOS15. But it is a good foundation to work off of now.
My plan is to start attempting to compile LOS and take error logs to chase down the remaning missing stuff. LOTS to be done still to get to that point...hoping for some other builders/devs to materialize here and help out
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
christianrj said:
Hi! Just a question: it´s mandatory to use A/B partition scheme to build a custom ROM for this device or it will be possible to use a traditional partition scheme and free up some GBs of internal storage for use?
Click to expand...
Click to collapse
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
mightysween said:
It would seem that we will still be stuck with A/B, as the bootloader does the initial check of the active slot. Perhaps there may be some clever ways around this in the future...but nothing I will be tackling.
Click to expand...
Click to collapse
You would probably need a custom kernel to do it properly. The bootloader passes a kernel param (androidboot.ro.boot.slot_suffix) specifying which slot to use. In the absense of a kernel param, the value is read from the ro.boot.slot_suffix build property.
That being said, you might be able to just repartition your device to only have 1 slot, flash your ROM, and use
Code:
fastboot --set-active=_a
. If your ROM has disabled OTA updates from the OEM, you should be fine.
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
@vache at the Moto G5 Plus forums has already managed it using the /oem partition which is otherwise unused for custom ROMs
Hariiiii said:
I don't know if any of you have seen this article, but it seems promising that it might not be too difficult to achieve for this device:
https://www.xda-developers.com/xiaomi-redmi-note-4-project-treble/
Click to expand...
Click to collapse
Cool... seems it may be possible. Will follow the progress on the Redmi and G5 devices
navenedrob said:
I'm going to get an X4 in the coming weeks. I'd like to help with this soon. I'm a seasoned developer by trade and can collab on GitHub. Hope to be able to start working with you soon. :good:
Click to expand...
Click to collapse
The more I am reading about enabling Treble, the more I think it is entirely possible.... and probably the best direction to focus our efforts.
Seems like we have partitions that could be used as /vendor. I am reading up on exactly how the Treble vendor partition is set up. Tricky, but not implausible.
EDIT: Actually, none of the partitions we could potentially re-purpose for /vendor are big enough. So, it may be harder on this device than on others. It may require repartitioning.
First time posting and I wanted to say thank you to all the excellent talent here on XDA! None of this would have been done without the work of so many people.
I have a Moto G Play (2021) (XT2093-4) that I recently purchased (Best Buy - $159 US/Carrier Unlocked) and I wanted to document my adventure in to rooting, making '/system' RW, and fixing the missing LED notification light (hint: I used the charging light) (hint^2: It's not required to make '/system' RW in order to fix the LED notification light - I just wanted more control over my phone).
First, "OEM unlocking" was greyed out for me, but became available after several days of having the phone online with a SIM card.
I followed the instructions here to unlock the bootloader and root with Magisk (Non-TWRP). Along with these instructions.
Once bootloader is unlocked, you will need the 'boot.img' file from your stock firmware. I used the "Rescue and Smart Assistant" utility to grab a copy of the stock firmware (GUAMNA_RETAIL_QZAS30.Q4_39_35_9_subsidy_DEFAULT_regulatory_DEFAULT_CFC.xml) and extracted the "boot.img" file for the next steps.
Continue installing Magisk (Filenames may be different! Don't just copy and paste.):
Code:
adb install Magisk-v23.0.apk
adb push boot.img /sdcard/Download
(Follow the instruction on your phone to patch 'boot.img' in Magisk)
adb pull /sdcard/Download/magisk_patched-23000_aKKMt.img
adb reboot bootloader
fastboot flash boot_a magisk_patched-23000_aKKMt.img
fastboot flash boot_b magisk_patched-23000_aKKMt.img
You should now have a working, rooted Moto G Play. You can just stop here and have fun with your phone, but I noticed that even with root, the system partition was not RW.
I followed these instructions to make '/system' writable (Note: you will need the 'sysrw_repair.zip' that's included in the bundle and a Linux system):
Code:
adb push systemrw_1.32_flashable.zip /data/local/tmp/
adb shell
su
cd /data/local/tmp/
unzip systemrw_1.32_flashable.zip
cd systemrw_1.32/
chmod +x systemrw.sh
./systemrw.sh in=`ls -l /dev/block/by-name/super | awk '{print $NF}'` out=/data/local/tmp/systemrw_1.32/img/super_original.bin size=50
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
(On another Linux terminal)
Code:
cd /path/to/unzipped/sysrw_repair/dir/
chmod +x sysrw_repair.sh
./sysrw_repair.sh
This results in a new folder (img) with a rather large bin file (super_original.bin).
(Back on the phone adb)
Code:
exit # Exit root
exit # Exit adb
adb reboot bootloader
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
You should be able to login and have a writable '/system':
Code:
adb shell
su
mount -o rw,remount /
No errors should appear.
Last, I like having an LED indicator that tells me that I have an SMS/MMS notification waiting. Motorola thought it would be wise to eliminate that feature altogether instead of having the option to enable it. So, I forced it back on using a startup script that dumps the notifications and greps for some key words. And, if it finds something, it "breaths" the charging LED. The script loops until the notification is gone, then keeps checking for new notifications every 30 seconds. (Note: the "/data/adb/service.d/" directory is used by Magisk like an INIT service):
(Still root on the phones adb)
Code:
cd /data/adb/service.d/
cat <<EOF > ledfix.sh
#!/bin/sh
while true; do
if dumpsys notification | egrep NotificationRecord | egrep sms > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) == 0 ]]
then
echo 1 > /sys/class/leds/charging/breath
sleep 2
continue
else
sleep 2
continue
fi
elif egrep 'Charging' /sys/class/power_supply/battery/status > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) -ne 0 && $(cat /sys/class/leds/charging/brightness) -ne 0 ]]
then
echo 0 > /sys/class/leds/charging/breath
echo 255 > /sys/class/leds/charging/brightness
elif [[ $(cat /sys/class/leds/charging/breath) == 0 && $(cat /sys/class/leds/charging/brightness) == 0 ]]
then
echo 255 > /sys/class/leds/charging/brightness
else
continue
fi
else
echo 0 > /sys/class/leds/charging/breath
echo 0 > /sys/class/leds/charging/brightness
fi
sleep 30
done
EOF
chown 0.0 ledfix.sh
chmod 0755 ledfix.sh
reboot
Now, the charging light will fade off and on about every 2 seconds if there's an SMS/MMS notification waiting. And will check for notifications every 30 seconds. I'm sure someone can come up with a better way of doing this, but this was a nice quick-and-dirty way to get what I wanted.
Hope this helps!
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
PROFSLM said:
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
Click to expand...
Click to collapse
You can also get the firmware from
Lolinet Mirrors
https://t.me/MotoUpdatesTracker
Search for Firmware by codename, software channel, Software Version, and build #
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
mario0318 said:
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
Click to expand...
Click to collapse
I know!
I don't know what triggers that light to come on. I even waited until the battery was at 6% and the light still never came on.
So, I updated the script above to make the light go full brightness if the battery is charging. The order matters, so if a notification comes in while charging, it'll "breath" the LED. Also, if the battery is full, then the light will turn off. Kind of telling you that it's time to unplug.
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
jorduino said:
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
Click to expand...
Click to collapse
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
mario0318 said:
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
Click to expand...
Click to collapse
Im not completely sure how to get the right file, but I think the first time it was the wrong one, but then when i got what i thought was the right one, it just didn't work at all and I had to recovery flash it. I had just updated so maybe the correct image wasn't available yet. Im going to try again though
Oh! Hello @latentspork. Thanks for your interest in my SystemRW project. I just came across this thread randomly...
I'm happy you got my script to work on your Motorola device by using the included sysrw_repair script
Please feel free to send me your log files from script folder. Thanks. It's useful for further development of the script
latentspork said:
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
Click to expand...
Click to collapse
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Yes that's true the included sysrw_repair script (Linux only) pulls the image files from the phone to your computer and attempts to run the same lpmake command with the same arguments that just failed with error 73 on the phone itself and now all of a sudden it just works in Linux. Go figure.
latentspork said:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Click to expand...
Click to collapse
Why would you delete the super_original.bin ? That's your stock read-only super image which by default is automatically dumped by script for backup purposes in case you ever get a bootloop.
And if you launch the script by specifying a custom input value (in=x) like in your example above then you won't even have a super_original.bin file to begin with because script will skip the whole dumping of original super image process.
latentspork said:
This results in a new folder (img) with a rather large bin file (super_original.bin).
Click to expand...
Click to collapse
I think you mean super_fixed.bin
latentspork said:
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
Click to expand...
Click to collapse
Here in your instructions you are manually flashing the wrong file. Shouldn't you be flashing super_fixed.bin to your super partition?
Usually I only flash the super_original.bin to get back out of a bootloop...
latentspork said:
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
Click to expand...
Click to collapse
See that's why I included that automatic flash() function in the repair script. Then you don't have to worry about manually flashing the wrong file to your super partition
Enjoy a fully read/write-able device!
Great news! New SystemRW version coming soon!
@lebigmac
I really appreciate the reply and the tool! It did work really well on my model (XT2093-4).
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Click to expand...
Click to collapse
I only assumed that "Error 73" was caused by insufficient space, because the phone really did run out of space. I noticed that the phone was out of space because I got a home screen notification warning, asking me to free up space. I confirmed it with a "df -h" at the shell. Apparently, the OS takes up almost 15GB. When you add the ".img" files, there's only about 5GB left. There wasn't enough room to complete the ".bin" file. Maybe I could have used an SD card or something.
You're probably correct in that "Error 70" is the correct error for that, but on my phone, I never saw that error. I did notice that the tool was still trying to write data as the phone ran out of space, then it would throw the "Error 73". Maybe it didn't register the lack of space, or just an oddity with my model? No idea.
Why would you delete the super_original.bin ?
Click to expand...
Click to collapse
This is the file that was created when I initially ran the "./systemrw.sh" command on the phone. The result of running the command on the phone were several ".img" files and a very large "super_original.bin", but it was incomplete because the command threw an "Error 73". I was following your instructions, and I noticed that the output name of the file was "original" instead of "fixed". I probably could of outputted it to a new name to reduce confusion, but I didn't really care too much about the name as long as I had a working file.
I think you mean super_fixed.bin
...
Shouldn't you be flashing super_fixed.bin...
Click to expand...
Click to collapse
Normally, yes. But the Linux script also outputted the filename "super_original.bin". Again, as long as it worked, I was okay with it. The commands I used above were the exact commands that I ran at the time. I copied them from the terminal consoles I was using. So I don't know why it wasn't outputting the correct filename (again, I was following your instructions and was a little confused that the names came out differently - I just figured I was doing something wrong like not use the proper output command or something).
Then you don't have to worry about manually flashing the wrong file to your super partition...
Click to expand...
Click to collapse
I was really just being cautious because my previous phone broke and I didn't have a fallback.
But, at no point were there two bin files (original and fixed), so there wasn't much confusion. Where I originally had just ".img" files before running the script, I now had a single ".bin" file. I knew that was the file I needed.
But again, thank you for all the hard work on this tool! I was reading that it's worked on lots of different model phones, and it's always good to see the open source community doing things that help all kinds of people.
For moto notification for this phone at least use https://play.google.com/store/apps/details?id=br.com.itsmeton.motoledreborn or moto led reborn from the play store it just works
Hi, sorry. This can be removed. I put it in place because I was having issues with the xda app. For whatever reason, every time I tried to share this particular post, it would share a link for the post which I used originally, rather than the current post. I knew that if I commented I could get back here easily on my PC.
So what is the place holder for
Hi everyone
I've been working on getting twrp to boot on our borneo device for a week or so, borrowed I the device tree made by mistersmee for the g9 power since the two devices are almost completely the same
https://github.com/TeamWin/android_device_motorola_cebu
heres where I'm at:
https://github.com/touchpro/twrp_device_motorola_borneo
The only thing I cant seem to get working is the touchscreen. I realize others have tried before me already and had the same non working touchscreen, I believe the majority of us have an Ilitek touchscreen while others have focaltech or nova. I got the driver framework up and recognizing it exists from dmesg output but cant seem to get any actual touch input to register. You can look at my changes to android 11 twrp in the github above by selecting branch twrp-android-11 and using a diff program. I use meld in ubuntu.
if you want to build for yourself and help out: (i'd use ubuntu 20.04, i tried 20.10 first but one of the packages is too new and doesnt like the toolchain)
follow the instructions here to set up your build environment
mkdir twrp (you can name this whatever you want)
cd twrp
repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
repo sync
add the device tree above to twrp/device/motorola/borneo
also add this to device in twrp/device/qcom/twrp-common
make your changes inside device/motorola/borneo then
. build/envsetup.sh
export LC_ALL=C
lunch omni_borneo-eng
mka -jx clobber && mka -jx recoveryimage (-jx is number of cores you have, i have quad core i7 with hyperthreading so i use -j8. personal preference really)
your completed build will be in twrp/out/target/product/borneo as recovery.img
reboot to fastboot (adb reboot bootloader) and type
fastboot boot recovery.img
see if your changes worked! look forward to seeing what you guys can do
mine for later
Have not had the time to toss together a build environment for this, since I'd have set up the entire OS and beyond for that task, since my only Linux is Garuda in a much too small VM that is nowhere near right for that., been only hacking my way through it with Android Image Kitchen in Windows and some other utilities to get touch support in my 3.5.2.10-0 cebu source image.
It works perfectly if booted into TWRP just takes about 30-seconds before touch enables itself fully, but not when flashed (fastboot or applied internally via DD, or using a modified TWRP zip via Magisk that has had my ramdisk swapped into it).
When flashed, touch simply will not function, so something is obviously not being carried over properly so when being loaded from the recovery partition it seems, despite it being the exact same ramdisk (I extracted the recovery img, pulled out my ramdisk, popped it back into a whole new image, booted it and it had touch, so I know it's supposed to have the data there but likely needs a full from the ground up build of TWRP to behave on flashed installs.
@whoshotjr2006, had any more luck with your building of it? I can test or anything you may need in your own efforts, but just have no time for the actual building of it to tinker.
Oh, and thought you should know this works if you were wanting to go RW for System, but you'll have to use Linux due to falling prey to Error 73 https://forum.xda-developers.com/t/script-android-10-universal-mount-system-r-w-read-write.4247311/. I put mine back because it didn't seem to behave quite right there, but could be useful in your own tinkering.
OK, got it where it is fully flashable and bootable with touch for mine. Used Android Image Kitchen, unpacked TWRP image that boots with touch working, copied out the kernel and ramdisk from split_img folder, extracted stock recovery, replaced those 2 items with properly renamed versions and then repacked it with --original argument, and then it boots and flashes properly. Just a quick hack on it, but functional for those that need it.
This should be easy to combine in your /vendor/lib/modules from your own, as well as /vendor/firmware as long as you're rooted to pull it, into your TWRP ramdisk before putting it into the stock recovery this way. So you can get fully functioning touch for any display type in use.
whoshotjr2006 said:
Hi everyone
I've been working on getting twrp to boot on our borneo device for a week or so, borrowed I the device tree made by mistersmee for the g9 power since the two devices are almost completely the same
https://github.com/TeamWin/android_device_motorola_cebu
heres where I'm at:
https://github.com/touchpro/twrp_device_motorola_borneo
The only thing I cant seem to get working is the touchscreen. I realize others have tried before me already and had the same non working touchscreen, I believe the majority of us have an Ilitek touchscreen while others have focaltech or nova. I got the driver framework up and recognizing it exists from dmesg output but cant seem to get any actual touch input to register. You can look at my changes to android 11 twrp in the github above by selecting branch twrp-android-11 and using a diff program. I use meld in ubuntu.
if you want to build for yourself and help out: (i'd use ubuntu 20.04, i tried 20.10 first but one of the packages is too new and doesnt like the toolchain)
follow the instructions here to set up your build environment
mkdir twrp (you can name this whatever you want)
cd twrp
repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
repo sync
add the device tree above to twrp/device/motorola/borneo
also add this to device in twrp/device/qcom/twrp-common
make your changes inside device/motorola/borneo then
. build/envsetup.sh
export LC_ALL=C
lunch omni_borneo-eng
mka -jx clobber && mka -jx recoveryimage (-jx is number of cores you have, i have quad core i7 with hyperthreading so i use -j8. personal preference really)
your completed build will be in twrp/out/target/product/borneo as recovery.img
reboot to fastboot (adb reboot bootloader) and type
fastboot boot recovery.img
see if your changes worked! look forward to seeing what you guys can do
Click to expand...
Click to collapse
finally having time to try to build an environment. Making a generic VM and will post it when done and easy to use, but running into some issues in my getting it to a point to test its success even. The steps you provided, missed a needed command "sudo ln -s /usr/bin/python3 /usr/bin/python" if using the 20.04 Ubuntu. But then how do you "add the device tree" as you put it? I'm normally a repacker to get things working, versus building things. I'm sure downloading the zip of the code and loading it into those folders is bound to break something as it always does when it comes to using links and ramdisks.
Perhaps you can provide more clear instructions of what you mean by that and I could finally gladly be able to contribute to this as more than a hackish throw-together process, since the description you provided "add the device tree" yields no meaningful results for any process for that to be pieced together from other builders.
git clone -b main https://github.com/touchpro/twrp_device_motorola_borneo.git
or you can just download the zip from my github, the only time it breaks symlinks so far that i know of is when you download a kernel in a zip file instead of git cloning it
take the twrp_device_motorola_borneo files and put them in /device/motorola/borneo and you should be good to go
whoshotjr2006 said:
repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0
Click to expand...
Click to collapse
That won't work, as it doesn't seem to have a twrp-10.0 as it looks to be depreciated, https://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni/tree/twrp-10.0-deprecated. How'd you get yours, or did you mean 9.0?
repo init --depth=1 -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-10.0-deprecated
Twrp has always been built in an omnirom build environment but with a11 they switched to being built in an aosp environment. Twrp-10.0-deprecated they recently renamed to add the deprecated tag on but thats the one for android 10 that I initially used
Got my build environment set up and can upload the image in a bit if anyone wants it. @whoshotjr2006
using your steps it builds, but even having modified the firmware and modules to include the changes I put into mine to have it have touch support, it still will not. But the hacked android image kitchen one works just fine, which makes absolutely no sense when there are no errors, only warnings reported, but even those all look to be minor type casting of variables that I've noticed.
remind me again where you found that twrp that youve used android image kitchen on? was it from moto g9 power or another device? if you can let me know ill look through device trees and see what they have that we dont
seems like maybe its not insmod'ing the .ko file for your touchscreen, or it is and your touchscreen needs a firmware check/update at load. you'll have to remind me again which touchscreen you have (sorry its been a minute i've been busy) and we can look through other's device trees at the firmware loading portion
whoshotjr2006 said:
remind me again where you found that twrp that youve used android image kitchen on? was it from moto g9 power or another device? if you can let me know ill look through device trees and see what they have that we dont
seems like maybe its not insmod'ing the .ko file for your touchscreen, or it is and your touchscreen needs a firmware check/update at load. you'll have to remind me again which touchscreen you have (sorry its been a minute i've been busy) and we can look through other's device trees at the firmware loading portion
Click to expand...
Click to collapse
Source I used in AIK was cebu's 3.5.2.10-0 from https://twrp.me/motorola/motorolamotog9power.html. used AIK to unpack it.
To get touch using my quick hack, I just dropped in my matching .bin's from /vendor/firmware plus my ilitek_fw.bin to go with their novatech*.bin's and NT36xxx_MP_Setting_Criteria_601E.csv in place of their NT36xxx_MP_Setting_Criteria_6026.csv (deleted theirs).
Then also popped in my /vendor/lib/modules (minus audio ones).
At that point in tinkering it boots with touch. But fails to keep touch on booting into recovery.
Then I stumbled upon some obscure guidance about something in the kernel in recovery not initializing the touch on some devices and potentially being able to hex edit it after manually extracting the kernel using a hex editor. And then unpacked my booting version again, saw the kernel already separated out and pulled that and my ramdisk from split_image folder. cleaned up. unpacked the stock recovery. replaced with appropriately named kernel and ramdisk files and used the repack --original. Flashed it and it booted with perfect touch, just takes about 30-seconds on start before it's responsive. I have mine encrypted still so must input a passcode and just tap on the log button a few times till I know it's working then input my code and off it goes working normally.
Should not have anything too crazy different. I think the only thing I did was delete the etc file from the cebu, replacing it with an etc folder with a recovery.fstab and twrp.fstab I had scavenged from @svoc 's 3.4.0.0 (https://forum.xda-developers.com/t/working-twrp-but-very-unofficial-but-very-useful.4313665/ of which touch did not work for me, but it booted perfectly enough to extract my firmware and lib modules initially to put into my 3.5.2.10-0). Since every time I'd use Android Image kitchen to extract the cebu image it complained about things in /etc, and that was the only difference I could find between 3.5.2.10-0 and the 3.4.0.0. That is the only potential thing I did that could be of unknown consequence.
whoshotjr2006 said:
(sorry its been a minute i've been busy)
Click to expand...
Click to collapse
And never be sorry, you're helping out here, we understand, just like if you're waiting on a response back, that you're as understanding too
Compiled, touch working when booting it. Only change I made was to add my files as I outlined before, but into the firmware and lib folders respectively, but also edited the load_ts_firmware.sh to ensure nova and chiptone are no longer commented out. Flashed and has touch fully working as well. So it should be an easy build if I can get it working.
Edit: And touch does not take 30+ seconds per the 3.4.0.0 @svoc version I believe because it's not re-flashing the display code. So that could be why some perm lose touch, and I just got VERY lucky with mine to not.
Yes you are right all I did was put the touch screen driver in the twrp and send it to you that is why it takes less then 30 secs to do no need to recomile it each time just add your files in it and rezip it