Related
With the Note 3 using device tree (dtb) files, what is the new process to create a bootable kernel image without having to build the entire Android stack along with it? I'm working on porting kexec-hardboot to the CyanogenMod hlte kernel. I've compiled my kernel and it produces a zImage and a zImage-dtb. It also provides several msm8974-sec-hlte-r0X.dtb files in the arch/arm/boot directory which I assume are the compiled device tree images for the various HLTE revisions. I extracted a working kernel using the tools here: https://bitbucket.org/itsmikeramsay/mkbootimg/src and examined the extracted dt.img in a hex editor to find that it appears to contain all of these dtb files together. What tool is used to build this combined dtb image? I tried repacking the kernel I extracted with only my new initramfs (containing the kexecboot binary) and that worked, but repacking it with my new kernel (zImage) along with the old dt.img did not.
EDIT 1: I found this: http://forum.xda-developers.com/showthread.php?t=2469510 Looks like it could be what I'm after.
below, good luck
CalcProgrammer1 said:
With the Note 3 using device tree (dtb) files, what is the new process to create a bootable kernel image without having to build the entire Android stack along with it? I'm working on porting kexec-hardboot to the CyanogenMod hlte kernel. I've compiled my kernel and it produces a zImage and a zImage-dtb. It also provides several msm8974-sec-hlte-r0X.dtb files in the arch/arm/boot directory which I assume are the compiled device tree images for the various HLTE revisions. I extracted a working kernel using the tools here: https://bitbucket.org/itsmikeramsay/mkbootimg/src and examined the extracted dt.img in a hex editor to find that it appears to contain all of these dtb files together. What tool is used to build this combined dtb image? I tried repacking the kernel I extracted with only my new initramfs (containing the kexecboot binary) and that worked, but repacking it with my new kernel (zImage) along with the old dt.img did not.
EDIT 1: I found this: http://forum.xda-developers.com/showthread.php?t=2469510 Looks like it could be what I'm after.
Click to expand...
Click to collapse
I struggled with this for like a month. Download me
This is an updated version of the mkbootimg tools with support for device tree images. I think this is exactly what your looking for. You should be able to just overwrite the zImage and proper headers and it'll boot. Good luck! Message me if you have any issues. The older mkbootimg has issues parsing the device tree tables since it doesn't recognize them.
I got it working. The tools I posted work as well (not sure if they're the same or not, didn't check). My problem was not my build process but that my kernel/ramdisk made boot.img too large (>11.0MB) which made it fail to boot. I enabled XZ compression instead of LZMA and that took 3MB off my kernel size and allowed my build to fit, then it worked fine.
How to use the tools suggested
I was able to use xiaolu/mkbootimg_tools to create a recovery image, and flash my phone successfully. I want to know how to create a boot.img with code that I have compiled myself. I created my own dt.img, thanks to Xiaolu, and placed it in the recovery image mentioned above. I am trying to port a compiled code into my phone.
This version of SafeStrap is based on SafeStrap 3.75 but has a lot of differences with it:
- there is not more the splashscreen during the boot, to enter in Safestrap you have to select BP Tools in the Boot Mode Selection Menu(VolUp&&VolDown+PowerOn)
- has been added a Safe Rom slot that uses the unused partitions:
/preinstall (~ 600mb) for /system
/webtop (~ 1,4gb) for /data
/cache is shared with the Stock Rom slot
- in this version you have 6 slots: the Stock Rom slot, the Safe Rom slot and the four virtual slots
- the Safe Rom slot is faster than any virtual slot and safer than the Stock Rom slot
If you are using the original Safestrap you can simply install this new version over it and you will still have your roms in the virtual slots.
This version of Safestrap works like any other version of Safestrap and you can use the Stock Rom slot and the four virtual slots as you are usually do, the only thing that is a bit complicated is to install an aosp rom in the new Safe Rom slot that i provided in it.
DOWNLOAD AND GUIDE TO USE THE SAFE ROM SLOT
HOW TO POST REQUEST FOR HELP:
You have to entirely read this thread, I do NOT answer redundant question.
I do not answer to requests for help in private, I have neither the time nor the interest in doing so.
Any doubts, questions or requests must be posted in this thread in order to answer a single time and help everyone.
XDA:DevDB Information
Safestrap 3.75 for unused partitions (/preinstall & /webtop) , Tool/Utility for the Motorola Droid 4
Contributors
Mentor.37
Version Information
Status: Stable
Created 2015-02-21
Last Updated 2016-01-05
This thread is not about the ramdisks so do not ask about them.
In case of problems you can build the ramdisk as i explained in the main thread.
Super, i wait for some time for someone to make this. I'v tested this with cm12 to safe slot but blank screen. Some progress in this kexec problem ? Also SS revovery splash screen is not so but as turning of device and keys combo pressing.
I rechecked everything more and more times but seem to me that everything is ok, for now I do really have not idea on where could be the problem.
Solved
Good news, I understood where is the problem with the roms that use a kexec kernel and the problem was not in my modded recovery but in the rom's ramdisk. I'm now running the cm11 in my safe slot.
I will correctly describe how to run a kexec rom in my safestrap version in the next days, for now i'm a bit busy.
Mentor.37 said:
Good news, I understood where is the problem with the roms that use a kexec kernel and the problem was not in my modded recovery but in the rom's ramdisk. I'm now running the cm11 in my safe slot.
I will correctly describe how to run a kexec rom in my safestrap version in the next days, for now i'm a bit busy.
Click to expand...
Click to collapse
could the partitions be formated fs2fs ?
Regards
For now they can be formatted only as you can format the stock rom or any slot in the standard safestrap but should not be difficult add this option in safestrap but i can't ensure you that they will work, as far as i know the aosp roms require an ext3 or ext4 fs for /system and /data.
#Postedit
I have never used safestrap before this my project and for this i did not know it well, now i saw that the f2fs is the fs used for the virtual stlots and yes i can format these partitions as f2fs the first time that the safe slot is selected but for now i'm using the cm11 in this slot with the partitions formatted as ext3 and the rom is really really fast.
Final version
I just uploaded the final version in which i also restored the capability to use the virtual slots.
If you are using my previous debug version or if you are using the original safestrap 3.75 you can simply install this new version over them and you will still have your rom in the safe slot or in the virtual slot.
Yes, i know that i told that the previous was the final version but i just uploaded a little update that fixes a problem in the layout of the new safe slot menu.
Mentor.37 said:
For now they can be formatted only as you can format the stock rom or any slot in the standard safestrap but should not be difficult add this option in safestrap but i can't ensure you that they will work, as far as i know the aosp roms require an ext3 or ext4 fs for /system and /data.
#Postedit
I have never use safestrap before this my project and for this i did not know it well, now i saw that the f2fs is the fs used for the virtual stlots and yes i can format these partitions as f2fs the first time that the safe slot is selected but for now i'm using the cm11 in this slot with the partitions formatted as ext3 and the rom is really really fast.
Click to expand...
Click to collapse
I was thinking to add fs2fs support to the kernel and see how it works, like otterx project.
thanks for your work !
regards
Thank you for great work. I'm now trying CM11 in safe slot. Everything looks great, it run very fast compared to cm12. I have one question: How can I edit cm12 ramdisk.img? I've tried "Android Image Kitchen 2.0" with no luck. Thanks for help.
In the cm12's ramdisk.img there is the file safestrapped.cpio before the real ramdisk so you have to split them with an hex editor (1F 8B 08) then you can extract the ramdisk, edit it, repack it and finally recreate the ramdisk.img reconcatenating with the hex editor the file safestrapped.cpio with the edited ramdisk.
Anyway yesterday night i attached at the main thread two flashable zips that install an edited ramdisk.img with an addon.d script that makes it persistent for the cm11 m12 and for the cm12 nightly. In this way anyone can try these roms in the Safe Slot.
I'm trying the cm12 in the safe slot from yesterday and it works flawless, it is faster than the cm11 used in the same slot, i suppose thank to the ART.
Mentor.37 said:
In the cm12's ramdisk.img there is the file safestrapped.cpio before the real ramdisk so you have to split them with an hex editor (1F 8B 08) then you can extract the ramdisk, edit it, repack it and finally recreate the ramdisk.img reconcatenating with the hex editor the file safestrapped.cpio with the edited ramdisk.
Anyway yesterday night i attached at the main thread two flashable zips that install an edited ramdisk.img with an addon.d script that makes it persistent for the cm11 m12 and for the cm12 nightly. In this way anyone can try these roms in the Safe Slot.
I'm trying the cm12 in the safe slot from yesterday and it works flawless, it is fastest than the cm11 used in the same slot, i suppose thank to the ART.
Click to expand...
Click to collapse
Excellent! It works like a charm! Now i can swap SD-card and internal storage etc... Thank you Mentor!
Thanks, Mentor.
This is a brilliant idea, and it works perfectly.
It seems crazy not to use this, if you don't need /preinstall or /webtop.
Mentor.37 said:
In the cm12's ramdisk.img there is the file safestrapped.cpio before the real ramdisk so you have to split them with an hex editor (1F 8B 08) then you can extract the ramdisk, edit it, repack it and finally recreate the ramdisk.img reconcatenating with the hex editor the file safestrapped.cpio with the edited ramdisk.
Anyway yesterday night i attached at the main thread two flashable zips that install an edited ramdisk.img with an addon.d script that makes it persistent for the cm11 m12 and for the cm12 nightly. In this way anyone can try these roms in the Safe Slot.
I'm trying the cm12 in the safe slot from yesterday and it works flawless, it is fastest than the cm11 used in the same slot, i suppose thank to the ART.
Click to expand...
Click to collapse
Can you also add patch for cm 10.2.1 ?
Anyone can build by itself a ramdisk to use a rom in the Safe Rom slot with these passages:
1) unpacking the ramdisk.img with this command:
Code:
gunzip -c ../ramdisk.img | cpio -i
N.B.: for the roms based on LP the procedure is a bit more complex and i explained it some post above
2) editing the file fixboot.sh as explained in the main thread
3) repacking the new ramdisk.img with this command:
Code:
find . | cpio -o -H newc | gzip > ../ramdisk.img
Excellent work!
Mentor.37 said:
Anyone can build by itself a ramdisk to use a rom in the Safe Rom slot with these passages:
1) unpacking the ramdisk.img with this command:
Code:
gunzip -c ../ramdisk.img | cpio -i
N.B.: for the roms based on LP the procedure is a bit more complex and i explained it some post above
2) editing the file fixboot.sh as explained in the main thread
3) repacking the new ramdisk.img with this command:
Code:
find . | cpio -o -H newc | gzip > ../ramdisk.img
Click to expand...
Click to collapse
For some strange reason I cannot repack new ramdisk.img for cm 10.2.1
I have a problem - the safe slot is there but, it shows that it has 0 MB (0 MB Free) in Data. I still did try to install CM11 (M12) there. It did installed successfully, but after rebooting it stuck (at least I think it did) on the CM boot animation. It stayed there for good half a hour so I thought there is a problem. So i restarted and went back to stock (have CM12 there, I wanted to test a CM11 a bit if it would be snappier as it probably is more developed and than switch those two as CM12 has nightly updates and there is risk of bricking the phone with daily flashes)
Anyway is showing 0 MB in Data normal and /preinstall and /webtop are used anyway or is it wrong?
Thanks!
dutohlav said:
I have a problem - the safe slot is there but, it shows that it has 0 MB (0 MB Free) in Data. I still did try to install CM11 (M12) there. It did installed successfully, but after rebooting it stuck (at least I think it did) on the CM boot animation. It stayed there for good half a hour so I thought there is a problem. So i restarted and went back to stock (have CM12 there, I wanted to test a CM11 a bit if it would be snappier as it probably is more developed and than switch those two as CM12 has nightly updates and there is risk of bricking the phone with daily flashes)
Anyway is showing 0 MB in Data normal and /preinstall and /webtop are used anyway or is it wrong?
Thanks!
Click to expand...
Click to collapse
Both preinstalled and Webtop should have data in them, before you wipe them, what are total sizes?
Sent from my XT907 using Tapatalk
Some of you might face the next error during systemless SuperSU install:
...
- Decompressing ramdisk
failed
--- Failure, aborting
*************************
IMPORTANT NOTICES
*************************
First reboot may take a
few minutes. It can also
...
This means that the ramdisk of your boot image was compressed in a non gzip format.
Unfortunately SuperSU can only decompress and tweak gzip compressed ramdisks up to now.
However i tried to make a little script that will uncompress your boot image/ramdisk and recompress it to gzip then after flashing SuperSU it recompresses the ramdisk to the original format.
This way one can achieve systemless root temporarily on such devices by installing SuperSU.
Idk maybe it can also be used for Magisk???
Download v1.1 (rce_univ.zip):
http://viid.me/qoESak
in case you face any proglems with the above version, try the old one v1.0 (rce_univ_1.0):
http://viid.me/qir1u5
How to:
Boot into TWRP 3.0.0 or above (never tested below) and install rce_univ.zip before and after SuperSU.zip!
Video: http://viid.me/quIbOi
Consider flashing Chainfire's Boot image signer (in case you get soft bricked after the above steps):
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
Detailed description in comment nr.3 (https://forum.xda-developers.com/showpost.php?p=70428981&postcount=3)
Supported ramdisk compressions:
bzip2, lz4, lzo, lzma, xz
Requirements:
Unlocked bootloader on most newer (marshmallow and lollipop) devices
Don't expect it to be working on every device!
The script is basically fool proof. I mean if anything goes wrong it will promt you and quit.
Then you can simply restore your boot partition (if you didn't forget to back it up) and boot up normally and deal with the non rooted idea...
Also it's not supposed to mess up anything that would cost you a hard brick. Soft brick is only possible if you forget to make backup of your boot image or if you get SuperSU intalled and rec_univ.zip cannot recompress your ramdisk (this is pretty much impossible anyways)
Naturally there are those Samsung and Sony devices with some tricky boot images... idk. Never tested but most likely not gonna work.
Probably there will be many devices on which there are not enough space to decompress and recompress ramdisks/boot images in TWRP.
In comment nr. 2 i will collect the devices that are compatible with this script and the method itself.
If you can't find your device there as i said it's fool proof but you better be careful! You can simply test it by backing up your boot images between each install and with the mount mtp function you put it on PC (you can't quit TWRP during the whole process - i mean during step 2) and with carliv image kitchen (https://forum.xda-developers.com/android/development/tool-cika-carliv-image-kitchen-android-t3013658) you check if you can unpack them normally.
Or if you don't care so much you just try and the worst case you reflash your framework...
If you are about to post any errors or complains do it the right way:
- attach recovery.log
- describe your device (model name, firmware version, ...)
- attach your boot image you backed up (upload it somewhere and link it)
If you are about to post a succesful attempt of a not yet added device:
- describe your device (model name, firmware version, ...)
- maybe link to its thread
No promises... and no responsibility i take... !!!
Please don't upload it anywhere else just use link to this thread!
I have to say thanks jcadduono for LazyFlasher boot image patcher script i used for the ramdisk compression exchanger and also thanks goes to Chainfire for SuperSU (especially for the boot image finder srcipt which is took from the SuperSU installer).
The xz archiver was used from XZ Utility For Android by Tukaani http://tukaani.org/xz/ - i hope he doesn't mind. Let me know if he does!
Supported devices until now:
Lg K8 - https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Lg K10 - https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Note 4 n910v (7.1.1 rom) https://forum.xda-developers.com/showpost.php?p=72491391&postcount=18
Detailed description
Systemless root with SuperSU on devices with non gzip compressed ramdisk bootimage
0. Download rce_univ.zip from here: http://viid.me/qir1u5 and download SuperSU (latest or there are some cases that requires earlier versions): https://forum.xda-developers.com/apps/supersu/stable-2016-09-01supersu-v2-78-release-t3452703 and put them on your sd card (external sd card is usually necessary since sometimes TWRP cannot decrypt your data partition/internal sd).
1. Unlock your bootloader
1.1. Additional step for those who has no "...device corrupt..." message during every boot up after unlocking bootloader on Marshmallow and some Lollipop devices(*)
- Boot into TWRP
- on the keep system read only? screen of the TWRP let it allow modifications (swipe!)
- reboot to System
- from now on you should have the message at every boot up
2. Boot into TWRP
- cancel decrypt data
- keep system read only
- go to Backup -> Backup your boot image! Maybe it comes handy later.
- go back from backup to install and install rce_univ.zip right after install SuperSUxxx.zip and then rce_univ.zip again.
- do not wipe anything during and after this step, just reboot! (this might take a while and a few bootloops...)
Video guide: http://viid.me/quIbOi
(3.) Verified boot?
In case of soft brick (or if you're sure you need the proper signature in the end of your boot partition - cos your device has verified boot) try flashing Chainfire's Boot image signer as a very last step before rebooting from TWRP:
https://forum.xda-developers.com/an...signing-boot-images-android-verified-t3600606
(*) on some devices if there is no "device corrupt" message at every boot up after bootloader unlock then anything you do or change in your boot image or system partition your device will not boot up anymore but turning off right after showing you that device corrupt message.
but if you do that trick as written in step 1.1 and that message appears at every boot up then most likely you're goot to go...
You can find some video guides on my thread for the above steps: https://forum.xda-developers.com/lg-k10/how-to/friendly-root-method-lg-k8-k10-t3531223
Pricniple of the installer - rce_univ.zip
What the script does:
Install rce_univ.zip before SuperSU:
1. Finds the boot partition (same way as SuperSU)
2. Dumps the boot image and unpacks it
3. Determines the format the ramdisk was compressed in
4. Uncomresses it then recompresses to gzip (so SuperSU can handle it).
5. Repacks the boot image and flashes it back on boot partition
Here is where you install SuperSU
Install rce_univ.zip after SuperSU:
1. Finds the boot partition
2. Dumps the boot image and unpacks it
3. Reads back the original format of the ramdisk compression
4. Uncomresses it then recompresses the ramdisk with the original compression method(so now the device can handle it).
5. Repacks the boot image and flashes it back on boot partition
As about me:
I was not a complete noob when i started it however it took a lot of effort and time. If you care to understand a bit more what it's about and you want to follow my struggling this is where it started (you can click through the threads):
https://forum.xda-developers.com/apps/supersu/supersu-v2-66-installed-lz4-compressed-t3296508
didn't work at samsung galaxy S2, it only have 8Mb space at boot partition. any solution ?
edit i use LineageOS 14.1 (cm 14.1) android 7.1.1
haris1976 said:
didn't work at samsung galaxy S2, it only have 8Mb space at boot partition. any solution ?
edit i use LineageOS 14.1 (cm 14.1) android 7.1.1
Click to expand...
Click to collapse
Can attach recovery log? And maybe boot image that you backed up in TWRP
this recovery log
haris1976 said:
this recovery log
Click to expand...
Click to collapse
I can not fully open it (no editor can fully load it). Could you zip it and attach compressed or just attach again?
gottlasz said:
Can attach recovery log? And maybe boot image that you backed up in TWRP
Click to expand...
Click to collapse
back up boot from twrp
---------- Post added at 03:23 PM ---------- Previous post was at 03:05 PM ----------
gottlasz said:
I can not fully open it (no editor can fully load it). Could you zip it and attach compressed or just attach again?
Click to expand...
Click to collapse
maybe tommorow i have bad connection when upload recovery & boot with the zip
haris1976 said:
back up boot from twrp
---------- Post added at 03:23 PM ---------- Previous post was at 03:05 PM ----------
maybe tommorow i have bad connection when upload recovery & boot with the zip
Click to expand...
Click to collapse
Okay, you can send it in PM if you want...
gottlasz said:
Okay, you can send it in PM if you want...
Click to expand...
Click to collapse
recovery & boot
haris1976 said:
this recovery log
Click to expand...
Click to collapse
Now i could open the recovery log.
Unfortunately this part means that even if it's a 3.0.2 TWRP something is missing:
"- Found boot partition at: /dev/block/mmcblk0p5- Dumping & unpacking original boot image...WARNING: linker: /tmp/boot_repack/tools/armv7/unpackbootimg: unused DT entry: type 0x6ffffef5 arg 0x560"
Maybe you should try with a newer version of TWRP if there is one.
Or if you follow my older guide which was a manual unpacking and repaking with carliv image kitchen, that could work.
Check my old guide: https://forum.xda-developers.com/lg-k10/how-to/twrp-root-lg-k8-k350n-t3475807
Anyways give me until tomorrow, ill take a look at the script maybe i can avoid this error.
gottlasz said:
Now i could open the recovery log.
Unfortunately this part means that even if it's a 3.0.2 TWRP something is missing:
"- Found boot partition at: /dev/block/mmcblk0p5- Dumping & unpacking original boot image...WARNING: linker: /tmp/boot_repack/tools/armv7/unpackbootimg: unused DT entry: type 0x6ffffef5 arg 0x560"
Maybe you should try with a newer version of TWRP if there is one.
Or if you follow my older guide which was a manual unpacking and repaking with carliv image kitchen, that could work.
Check my old guide: https://forum.xda-developers.com/lg-k10/how-to/twrp-root-lg-k8-k350n-t3475807
Anyways give me until tomorrow, ill take a look at the script maybe i can avoid this error.
Click to expand...
Click to collapse
Same error for me on LG K8 4G Vodafone Spain (LGK350n, build MRA58K, MT6735, Android 6.0), i fix it change booting the TWRP image to k350n10f (k8_10f_twrp.img, https://forum.xda-developers.com/lg-k10/development/recovery-twrp-3-0-2-lg-k8-k350-mtk-t3517894). It avoid for me" Error: Unpacking boot image failed!- Aborting..."
Works like a charm!!! thanks to gottlasz and XDA group!
sorry for my english
You should recompile all the used binaries as static, that should avoid a lot of issues.
Also, don't bother with older Samsung (everything before S3) and older Sony devices (not really sure until when). These use non-standard boot images that are very tricky to patch without outright recompiling. It can be done - I have done it in the past - but it is a major hassle and very errorprone.
Chainfire said:
You should recompile all the used binaries as static, that should avoid a lot of issues.
Also, don't bother with older Samsung (everything before S3) and older Sony devices (not really sure until when). These use non-standard boot images that are very tricky to patch without outright recompiling. It can be done - I have done it in the past - but it is a major hassle and very errorprone.
Click to expand...
Click to collapse
Thank you Master!
I know about the compiling situation, however the problem is that i did not compile anything since the whole stuff is based on jcadduono's LazyFlasher. He compiled the binaries I only tweaked the script and added some stuff... i don't have the resources to compile. Now i'm collecting static binaries to exchange them in the installer in order to solve these compatibility issues.
Basically i just wanted to help some of those unfortunate as me who has lz4 or other compressed ramdisks and unable to intall SuperSU. Well..., at least a handful of them.
New version is up. A few TWRP related compatibility issues are solved.
gottlasz said:
New version is up. A few TWRP related compatibility issues are solved.
Click to expand...
Click to collapse
i test the new version but no luck
this is the recovery log
haris1976 said:
i test the new version but no luck
this is the recovery log
Click to expand...
Click to collapse
How far does supersu intaller goes?
I mean can it unpack your boot image?
Install only supersu and make a recovery log please.
I tried to unpack your boot image with carliv image kitchen and no luck...
I think supersu can't even unpack your boot image and then there is no chance to install it. Even if we could change the ramdisk compression...
Are you sure supersu intaller gives you the same error message as it is stated in the OP?
I believe you have a non standard boot image as chainfire talked about.
It works great on 7.1.1 roms on Note 4 n910v. Thanks!
We can now boot distros with droid4-kexecboot without being locked to the stock initramfs or rootfs :
droid4-kexecboot images
droid4-kexecboot buildroot source
It works by using utagboot generated mmcblk1p8 utags partition to boot the stock kernel to a 4MB buildroot image that can be flashed to the unused mmcblk1p13 bpsw partition. Then it starts kexecboot to use kexec for booting to the selected distro.
Currently supported are recent mainline kernels with the pending LCD patches added. SafeStrap is not necessary but can be booted to. And v3.0.8 legacy kernels installed into SafeStrap rom slots are supported (but need to be manually updated if slot kernels are updated) .
UPDATED: Booting to the stock Android and SafeStrap is now supported out of the box with for pivot_root.
Changes are needed to v3.0.8 kernel config and initramfs to not use CONFIG_CMDLINE_FORCE=y and safestrap/active_slot file and instead just use kernel cmdline to mount the desired rootfs. Distros using the mainline kernel do not have these limitations, and can use the 608MB mmcblk1p22 preinstall, 1.3GB mmcblk1p23 webtop partitions. And the 8GB mmcblk1p25 can also be reformatted to ext4 and used as rootfs if you don't need it for Android. I have not dared to try to reformat mmcblk1p20 system partition, but that too might be usable unless the Motorola bootloader does some checks on it on boot.
There are some experimental patches for initramfs modifications for postmarketos:
https://github.com/postmarketOS/pmbootstrap/pull/1039
But we need also similar Android changes if somebody has time to work on patching and rebuilding LineageOS
Nice, this works with lineage os on slot 1 now. Im currently building postmarketos and a mainline kernel to test
The bootloader refuses to boot with mmcblk1p20 erased. But a empty ext3 partiton is apperently enough to make it happy
IM_back! said:
The bootloader refuses to boot with mmcblk1p20 erased. But a empty ext3 partiton is apperently enough to make it happy
Click to expand...
Click to collapse
Oh interesting I don't think I've seen that. Do you mean the Motorola bootloader refuses to start or kexecboot? Sounds like we should document this and how to fix it if it happens if you can write up something on it for droid4-kexecboot README file.
tmlind said:
Oh interesting I don't think I've seen that. Do you mean the Motorola bootloader refuses to start or kexecboot? Sounds like we should document this and how to fix it if it happens if you can write up something on it for droid4-kexecboot README file.
Click to expand...
Click to collapse
The Motorola booloader goes directly to fastboot if i:
Code:
dd if=/dev/zero of=/dev/block/mmcblk1p20
but
Code:
mkfs.ext3 /dev/block/mmcblk1p20
keeps the Motorola bootloader happy. im not shure if it needs to be ext3 i just whent with that because thats what the stock rom uses. It is extreamly annoying that we can not flash modified system.img's via fastboot. I will experiment a bit more with it and submit a patch to the README file.
I got The mainline kernel to boot, but without a rootfs it dosent do anything usefull of course.
that aside i can't seam to get postmarketos to work. I installed pmos rootfs to the webtop partiton and supplyed kernel command line with PMOS_NO_SAFESTRAP and correct root= but it just boots to a black screen , no uart output either
Do you have something that works that i could take a look at?
IM_back! said:
The Motorola booloader goes directly to fastboot if i:
Code:
dd if=/dev/zero of=/dev/block/mmcblk1p20
but
Code:
mkfs.ext3 /dev/block/mmcblk1p20
keeps the Motorola bootloader happy. im not shure if it needs to be ext3 i just whent with that because thats what the stock rom uses. It is extreamly annoying that we can not flash modified system.img's via fastboot. I will experiment a bit more with it and submit a patch to the README file.
Click to expand...
Click to collapse
Interesting so it seems that the cdt.bin mmcblk1p6 partition tells mbmloader to check some partitions for content and some partitions just for the fs. I wonder if also for example cdrom mmcblk1p16 partition can be modified too that way.
IM_back! said:
I got The mainline kernel to boot, but without a rootfs it dosent do anything usefull of course.
that aside i can't seam to get postmarketos to work. I installed pmos rootfs to the webtop partiton and supplyed kernel command line with PMOS_NO_SAFESTRAP and correct root= but it just boots to a black screen , no uart output either
Do you have something that works that i could take a look at?
Click to expand...
Click to collapse
As a test I only verified that NotKit's kernel mentioned in his postmarketos pull request boots with uart with kexecboot after I noticed he has a patch for gcc6 support and APKBUILD prepare -Werror search and replacement
I enabled CONFIG_EMU_UART_DEBUG=y, disabled CONFIG_CMDLINE_FORCE and configured kexecboot boot.cfg to use CMDLINE=console=ttyO2,115200 [email protected] vram=10300K omapfb.vram=0:8256K,1:4K,2:2040K ro rootwait root=/dev/mmcblk1p13 debug earlyprintk' to boot back to droid4-kexecboot.
tmlind said:
As a test I only verified that NotKit's kernel mentioned in his postmarketos pull request boots with uart with kexecboot after I noticed he has a patch for gcc6 support and APKBUILD prepare -Werror search and replacement
Click to expand...
Click to collapse
FYI, the postmarketos pull request mentioned above has been now merged. And I pushed out updated droid4-kexecboot images last night that now also support booting to the stock Android and SafeStrap.
I will be trying to get this thing to boot for my phone motorola electrify 2. Don't have much of knowledge but atleast trying is not going cost me alot .
mmcblk1p16 partition is usable as alternative ISO storage
tmlind said:
Interesting so it seems that the cdt.bin mmcblk1p6 partition tells mbmloader to check some partitions for content and some partitions just for the fs. I wonder if also for example cdrom mmcblk1p16 partition can be modified too that way.
Click to expand...
Click to collapse
Actually, after some trial and error I managed to turn the cdrom partition (mmcblk1p16) into something more useful. Now my maserati works as a portable "Linux booting device"
When plugged to a computer it behaves by default as a CD-ROM drive, and it's capable of booting a Linux ISO on the PC. Bear in mind that the partition size is slightly above 200 MB, so we have limited space. Apparently if mmcblk1p16 is formatted as ext3, ext4 or contains a filesystem other than ISO, the phone will NOT boot (I had to reinstall the whole Stock firmware a few times).
I could make a mini tutorial with detailed instructions.
So perhaps this partition could be useful for storing a customised read-only distro for the maserati, similar to a Live environment. Or at least capable of booting a minimum environment with essential files.
I'd like to test your kexec files as soon as I can, but still need to understand the whole process. About to receive a second maserati for tests
Cheers!
dinosaur99 said:
Actually, after some trial and error I managed to turn the cdrom partition (mmcblk1p16) into something more useful. Now my maserati works as a portable "Linux booting device"
Click to expand...
Click to collapse
Hey that's great! FYI, one more thing to consider is that I noticed allow-mbmloader-flashing-mbm.bin is more permissive compared to mbm.bin. They seem to parse some permissions table from cdt.bin. I guess it would not be too hard to figure out that format if somebody cares. And I now also wonder if using cdt.bin_patch instead of cdt.bin is even more permissive?
Anyways, do not mess with the mbmloader.bin or allow-mbmloader-flashing-mbm.bin partitions though that can brick the device..
tmlind said:
FYI, the postmarketos pull request mentioned above has been now merged. And I pushed out updated droid4-kexecboot images last night that now also support booting to the stock Android and SafeStrap.
Click to expand...
Click to collapse
Thank you for your excellent work!
Can't boot to safestrap
This is my first approach to boot something other than Android. Not very usable though, but I got this far.
I first installed droid4-kexecboot following instructions on README, and created the boot/boot.cfg on a fresh EXT4 sdcard by copying the sample rom-slot1 and rom-slot2 entries. After reboot, kexecboot shows a very nice graphical menu, and loads successfully all configurations. Unfortunately the slot entries don't work from kexecboot (phone restarts). However I can load Safestrap and boot stock and both ROM slots.
Then I built latest postmarketOS for Droid 4 using pmbootstrap, and selected Weston (one of the lightweight flavours). The result is three files: kernel, initramfs and a disk image containing two partitions. In order to install pmOS into rom-slot2, I wiped all slot2 partitions and installed CM11 as explained here https://wiki.postmarketos.org/wiki/Motorola_Droid_4_(motorola-maserati) . The next steps were done locally on my laptop instead of using ADB (i.e. replace file userdata.img in rom-slot2 directory with the pmOS disk image, and also replace /etc/kexec/ramdisk.img and /etc/kexec/kernel located inside system.img with the new initramfs/kernel). Then rebooted, jumped from kexecboot to Safestrap, and it launched postmarketOS.
USB networking connects right away and SSH works.
The wiki states that Framebuffer graphics works, but I get no screen output. LCD backlight is on. Xwayland and weston are running by default.
All LEDs work.
Touchscreen, vol buttons and keyboard seem to work.
Kernel is 3.0.8.
Finally I managed to boot pmOS with kexecboot. Directory "boot" on mmcblk0p1 contains following files:
Code:
atags # borrowed from safestrap
boot.cfg
devtree # borrowed from safestrap
initramfs-motorola-maserati
vmlinuz-motorola-maserati
Here's a few facts that I don't really understand
kexecboot boots pmOS on rom-slot only if safestrap is configured to boot on that slot, otherwise it boots into something else which responds to ping, but no SSH. Why is this happening if kexecboot overrides safestrap?
Excuse my ignorance, but what is in practice the need for a devtree file, and where am I supposed to obtain it?
The kernel cmdline is apparently overriden by atags file required to boot linux 3.0.8. It seems like boot configuration is hardcoded somehow. But why doesn't it boot regular android slots?
Is it actually possible to pass something like root=/dev/mmcblk0p1 or maybe even get screen working by using a recent kernel?
Sorry if I mixed up too many different topics... just trying to sort the whole thing out.
Thanks!
Is it possible to boot LineageOS with a Linux kernel of 3.20 or higher?
dinosaur99 said:
Here's a few facts that I don't really understand
kexecboot boots pmOS on rom-slot only if safestrap is configured to boot on that slot, otherwise it boots into something else which responds to ping, but no SSH. Why is this happening if kexecboot overrides safestrap?
Excuse my ignorance, but what is in practice the need for a devtree file, and where am I supposed to obtain it?
The kernel cmdline is apparently overriden by atags file required to boot linux 3.0.8. It seems like boot configuration is hardcoded somehow. But why doesn't it boot regular android slots?
Is it actually possible to pass something like root=/dev/mmcblk0p1 or maybe even get screen working by using a recent kernel?
Sorry if I mixed up too many different topics... just trying to sort the whole thing out.
Click to expand...
Click to collapse
Sorry for being slow to respond..
There is an issue with most droid4 images using the 3.0.8 kernel files and init scripts which is the scripts check the SafeStrap config from the mmc for things to mount etc.
This is no longer needed at and the scripts should be just modified to do that only if booted with safestrap. We should now just use standard Linux way meaning
parse the partitions to mount from kernel command line and so on NotKit posted some patches to sort out that as linked in the first post in this thread for the
PostmarketOK pull request. But I don't think those are applied and also the Android Images need to be updated too for LineageOS and then you can just boot
Android from whatever partition you like such as mmcblk0p1 or mmcblk1p25 in the standard Android way.
So omebody just please do standard LineageOS images that don't rely on SafeStrap!
The devtree file is only needed for old 3.0.8 kernels and is non-compatible with the current mainline kernel dtb file omap4-droid4-xt894.dtb. Motorola used custom
device tree properties and it's in big-endian format. The devtree file should be the same as what you have on the eMMC devtree partition mmcblk1p11.
Current mainline kernel still has the LCD patches pending, for v4.19-rc series I posted the pending patches I have to:
https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19
Those are still being worked on though because of omapdrm changing over to use generic displays.
andeaker said:
Is it possible to boot LineageOS with a Linux kernel of 3.20 or higher?
Click to expand...
Click to collapse
See the previous post about v4.19-rc5 kernel status. No idea how much work it would be to get LineageOS images working with the
mainline kernel.. Probably at least the graphics would be an issue. Using TI's Android tree with droid4 patches backported to it might
be a good starting point if somebody wants to experiment with that, TI might have SGX540 support there for other SoCs.
how would i go about getting this working n the droid bionic? im wanting to run maemo-leste, but the latest update switched from just safestrap and ddroid, to this. and apparently trying to stupidly flash this as-is didnt work out
tvall said:
how would i go about getting this working n the droid bionic? im wanting to run maemo-leste, but the latest update switched from just safestrap and ddroid, to this. and apparently trying to stupidly flash this as-is didnt work out
Click to expand...
Click to collapse
Hmm you probably need to stick with SafeStrap for bionic, I don't think bionic uses a utags partition that's needed for the kernel cmdline.
tmlind said:
So omebody just please do standard LineageOS images that don't rely on SafeStrap!
Click to expand...
Click to collapse
I finally got around finishing writing some docs for installing LineageOS to raw partitions, please test
Make back-ups as needed first though.
For instructions, see files PARTITIONS and INSTALL at:
https://github.com/tmlind/droid4-kexecboot
hope this is on-topic - is it possible to use this to boot an OS that's installed on the SD card? I don't have D4 yet, but am waiting to receive one in the next few weeks.
sicelo.m said:
hope this is on-topic - is it possible to use this to boot an OS that's installed on the SD card? I don't have D4 yet, but am waiting to receive one in the next few weeks.
Click to expand...
Click to collapse
Yeah you can boot whatever Linux distro(s) you prefer from the SD card with the current mainline kernel and few pending patches.
That's all work in progress though, certainly usable for tinkering though
I doubt that booting Android on the SD card currently works though.
Hi,
my Samsung GT-I9001 runs with LineageOS 14.1 (Nougat 7.1.2):
https://forum.xda-developers.com/ga...opment/i9001-lineageos-galaxy-s-plus-t3793783
As recovery TWRP 2.8.1.0 (F2FS-support) is installed.
Wenn trying to install Magisk 19.3 using magisk-v19.3.zip via TWRP it does not work: Error message ""Error execute updater binary in zip" and no flash is done.
Any idea what is the reason? The TWRP 2.8.1.0 is the latest version I found for the I9001.
The I tried patching the stock-bootloader via the Magisk-Manager. The bootloader-file is a .tar-file, e.g. in
https://forum.xda-developers.com/showpost.php?p=24831012&postcount=1330.
Magisk works with .tar, too, but seems to exspect an .img-file inside. But inside the I9001-"Boot_loader.tar" is no .img-file but 3 .mbn-files and 1 .bin-file.
So I am asking for help. Is there no way using Magisk with the I9001 (and LineageOS 14.1/TWRP)?
You're not supposed to use the bootloader, but the boot image. Two very different parts of the system setup...
And since you have such an old TWRP you're going to have to use the patching method, but it is very far from certain that your device is compatible. Only way to know is to try though.
Oops. Sorry, my mistake. I am a newbie with this and until I was not aware of boot.img ... I supposed it as the "real" filename of the bootloader. And again learning something new. Thank a lot for teaching.
Fortunately I have made a backup of the stock-ROM with TWRP before flashing the ROM. In the backup I find the file boot.emmc.win. This seems to be the stock-boot.img. Is it corrcect that I only have to rename the file to boot.img?
If the I9001 is not compatible with Magisk, means patching of the boot.img would result in a not working code/boot.img (the patching-procedure itself worked w/o errors, but does thos mean, that the result is o.k.?) - is the real risk bricking the device?
That should be the boot image and it should work fine by just renaming it. But, if it's the boot image from the stock Samsung system it won't work with LineageOS. You'll find the boot image for the ROM inside the ROM zip.
If the boot image is incompatible the Manager will let you know by an error message. Save the installation log if that happens and it could possibly tell you in more detail what went wrong.
If everything goes smoothly and the Manager manages to patch the file without issue and you still end up not being able to boot your device after flashing it you can simply restore the unpatched boot image and everything will be back to normal again.
Thanks for the further explanations. But I am not sure understanding correct.
In my understanding of the Magisk-installation manual I have to use the original boot.img always, in every case.
Do I understand correct that this understanding is wrong and that I have to use for patching with the Magisk-Manager the specific boot.img of the actual running OS? So I have to extract the boot.img of the lineageos-14.1-.tar-file (or rename the boot.emmc.win from one of my later backups of the lineagos-14.1-system)?
I have tested patching meanwhile with the "original" boot.img from the old ("original") backup and also with a boot.img extracted from a complete stock-ROM I have found in the web. Magisk Manager patched both fles w/o problems.
btw: Need the patched file the name "boot.img" or doesn´t matter the ame of the patched file (when flashing with fastboot or Odin)?
Unfortunately - or fortunately - I was not able to flash the patched boot.img to the i9001:
adb can communicate with the i9001 when it is running normal (USB debug enabled) and attached via USB. But although Odin is realizing the i9001 attached in download-mode (what means that the USB-cable is working and the driver are installed) fastboot does not realize the i9001 attached in download-mode. I have tested a lot of cables, ports and USB-drivers - no success.
So I tried to flash the boot.img with Odin. For this the boot.img must be converted to a .tar- (or .tar.md5-)file. When searching for converting-tools I found the explanation how to change the output-format of the patched boot.img in Magisk-Manager to .tar. Unfortunately I do not find this option in the current/latest version of Magisk-Manager. What is wrong - is there a secret, a hidden way to activate this option or is this option available in older versions of Magisk Manager only - and if so can I use an older version only for patching and getting a .tar-boot-image-file?
What the documentation is talking about is indeed the untouched boot image of your currently running OS. Don't mix and match.
When flashing with Odin the image indeed need to be in tar-format. With the current Manager there is no option to change the output format because the Manager will take care of that itself. Feed it a tar file and it'll output a tar file. Unfortunately you'll likely get plain image files from the TWRP backups, so those files will be no good unless you convert them before patching.
But, you might not have to use Odin since you have TWRP. It can flash the patched boot image for you. No computer required...
Again thanks a lot for this teaching. I am a newbie in modifying, tuning, flashing smartphones, and although I have learned a lot in the last weeks there are yet a lot of thing I do not know.
I know that I can flash new OS as .zip-file with TWRP (and other files if the manual says that I have/can do it with TWRP ) but I did not know that I can flash with TWRP a boot.img-file. So I would like to ask for a brief guide how to do this. Or is this the same procedure as flashing any .zip-file?
Addition 1: TWRP 2.8.1.0 does not see/list the .img-Files ....
O.k., found in the web: Directly flashing .img: Version 2.8.4.0 and above ....
So I am back again where I started ... fastboot does not see the i9001 and Odin needs a .tar ...
Addition 2: In reg. of the boot.img of the actual used OS:
I have looked into the "original" flashed lineage-14.1-20180523-UNOFFICIAL-ariesve.zip and found the boot.img. But this boot.img is smaller (4.670 byte) than the boot.emmc.win of it´s backup (5.120 byte). In fact every boot.emmc.win of every TWRP-backup (doesn´t matter what OS I have tested) ist 5.120 bytes and larger than the boot.img of the .tar/.zip-file for flashing (different sizes). So if the files are not identical - how can just simply renaming the boot.emmc.win in boot.img result in a valid boot.img?
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Didgeridoohan said:
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Click to expand...
Click to collapse
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
MarkFalk said:
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
Click to expand...
Click to collapse
Yes. I'm going to forcefully introduce my palm to my face for a moment... Forgot about that tiny but crucial detail.
Just use the boot image file from the LineageOS zip. Patch it and flash the patched image to your device. If you can't get that working I'm going to have to hand this over to someone else, because I have practically zero knowledge on working with Samsung devices and their shenanigans.
Thanks. The small detail of "flashing" into the i9001 is the remaining problem.
As said fastboot does not see the i9001 in it´s download-mode although Odin sees the device and can flash e.g. the bootloader. Odin on the other hand needs a .tar-file and I do not find a way how to converting the (patched) boot.img into a .tar-file that Odin would accept as valid file.
In these cases I usually ask someone like @jenslody or @ianmacd. They usually have a lot more knowledge about Samsung stuff...
I have found a workaround:
1. Make a pure boot-backup with TWRP
2. Copy the backup-folder into/with a new name
3. Copy boot.emmc.win and boot.emmc.win.md5 from the backup to pc or root
4. Rename boot.emmc.win to boot.img
5. Patch boot.img with Magisk-Manager
6. Rename the result to boot.emmc.win
7. Copy boot.emmc.win to the new backup-folder
8. Make a RD5-hash of boot.emmc.win
9. Replace the hash in boot.emmc.win.rd5 with the new hash
10. Copy boot.emmc.win.rd5 to the new backup-folder
11. Boot into TWRP and restore boot from the new folder
It works with the i9001 and lineageOS14.1 and TWRP 2.8.1.0 and the newest Magisk, but it should work with all devices.