Some htc devices are having issues with touch working in recovery and recently @Captain_Throwback made a hack for that.Sir can you explain it to me or refer a post by others. Here's my scenario, I'm having nothing but my stock rom and of course a device tree and vendor blobs but No twrp due to this issue and there is no kernel source for my device so can you explain it to me sir.
Have you checked for kernel source here? https://www.htcdev.com/devcenter/downloads
tys0n said:
Have you checked for kernel source here? https://www.htcdev.com/devcenter/downloads
Click to expand...
Click to collapse
Yeah it is not available my device is htc desire 620g
I already posted instructions for you. It's not a process for a novice. It sounds like you don't even know how to unpack a boot.img, so you should start by searching (XDA, Google) for how to do that.
Captain_Throwback said:
I already posted instructions for you. It's not a process for a novice. It sounds like you don't even know how to unpack a boot.img, so you should start by searching (XDA, Google) for how to do that.
Click to expand...
Click to collapse
I do know how to unpack boot.img and I even built other recoveries from source by making a device tree for my device I don't know that enable touch in recovery thing.
M.A.P said:
I do know how to unpack boot.img and I even built other recoveries from source by making a device tree for my device I don't know that enable touch in recovery thing.
Click to expand...
Click to collapse
I gave you instructions for patching the kernel already. It's the procedure that I follow. I'm not sure what else you want.
Captain_Throwback said:
I gave you instructions for patching the kernel already. It's the procedure that I follow. I'm not sure what else you want.
Click to expand...
Click to collapse
You mean to do this sir Patch the uncompressed kernel binary for touch as indicated below:
Code:
# Replaces string 'recovery' with 'rec0very' so htc_get_bootmode() doesn't know we're in recovery
sed -i -E -e 's/recovery\x00/rec0very\x00/g' <name-of-kernel-file>
You'll then have a patched, uncompressed kernel binary. To compress it, you'll have to find some similar kernel source, and compile it, but replace the "Image" (uncompressed kernel) with your patched one (and make sure it doesn't get overwritten on change), so that you have a kernel binary that's similar in size to the one you started with. Alternatively, you can just leave the kernel uncompressed and repack it back into the image (which will be much larger since the kernel is uncompressed). If it doesn't fit on the partition due to size, you will have to find a way to compress it.
M.A.P said:
You mean to do this sir Patch the uncompressed kernel binary for touch as indicated below:
Code:
# Replaces string 'recovery' with 'rec0very' so htc_get_bootmode() doesn't know we're in recovery
sed -i -E -e 's/recovery\x00/rec0very\x00/g' <name-of-kernel-file>
You'll then have a patched, uncompressed kernel binary. To compress it, you'll have to find some similar kernel source, and compile it, but replace the "Image" (uncompressed kernel) with your patched one (and make sure it doesn't get overwritten on change), so that you have a kernel binary that's similar in size to the one you started with. Alternatively, you can just leave the kernel uncompressed and repack it back into the image (which will be much larger since the kernel is uncompressed). If it doesn't fit on the partition due to size, you will have to find a way to compress it.
Click to expand...
Click to collapse
Yes, isn't that what you're asking for? If your kernel binary is gzipped with an appended dtb, then these are the complete instructions: https://forum.xda-developers.com/ht...ery-twrp-touch-recovery-t3358139/post71574833
Captain_Throwback said:
Yes, isn't that what you're asking for? If your kernel binary is gzipped with an appended dtb, then these are the complete instructions: https://forum.xda-developers.com/ht...ery-twrp-touch-recovery-t3358139/post71574833
Click to expand...
Click to collapse
My device is mtk based sir so I don't have dt.img can you tell me how to do this on mtk devices.
M.A.P said:
My device is mtk based sir so I don't have dt.img can you tell me how to do this on mtk devices.
Click to expand...
Click to collapse
The original method I posted *may* still work. Did you even try it?
Until you try it, why do you keep asking the same question?
Try it. If it doesn't work, then I can't help you.
Captain_Throwback said:
The original method I posted *may* still work. Did you even try it?
Until you try it, why do you keep asking the same question?
Click to expand...
Click to collapse
I think I did it I applied this command to kernel or zimage in terminal thats what I'm supposed to do right? sed -i -E -e 's/recovery\x00/rec0very\x00/g' <name-of-kernel-file>.
M.A.P said:
I think I did it I applied this command to kernel or zimage in terminal thats what I'm supposed to do right? sed -i -E -e 's/recovery\x00/rec0very\x00/g' <name-of-kernel-file>.
Click to expand...
Click to collapse
After you decompress it, yes. Did you decompress it first?
Captain_Throwback said:
After you decompress it, yes. Did you decompress it first?
Click to expand...
Click to collapse
I unpacked it sir and I tried it as it is and also decompressed it with 7zip well if its not to be uncompressed with 7zip then can you suggest me any other method sir.
M.A.P said:
I unpacked it sir and I tried it as it is and also decompressed it with 7zip well if its not to be uncompressed with 7zip then can you suggest me any other method sir.
Click to expand...
Click to collapse
Again, the link I gave you describes that already...extract-vmlinux. I'm not posting back here until you actually read what I already posted for you. I don't know how/if you're kernel is compressed, so you have to figure that out.
I've given you all the tools and information I have; I'm done here.
Captain_Throwback said:
Again, the link I gave you describes that already...extract-vmlinux. I'm not posting back here until you actually read what I already posted for you. I don't know how/if you're kernel is compressed, so you have to figure that out.
I've given you all the tools and information I have; I'm done here.
Click to expand...
Click to collapse
Ok got it
Captain_Throwback said:
Again, the link I gave you describes that already...extract-vmlinux. I'm not posting back here until you actually read what I already posted for you. I don't know how/if you're kernel is compressed, so you have to figure that out.
I've given you all the tools and information I have; I'm done here.
Click to expand...
Click to collapse
Sir, I modified the kernel and now I want to compress it so I got the similar device kernel source to compile and zImage , Image and kernel.bin files are made now can you explain how to compress my kernel.
M.A.P said:
Sir, I modified the kernel and now I want to compress it so I got the similar device kernel source to compile and zImage , Image and kernel.bin files are made now can you explain how to compress my kernel.
Click to expand...
Click to collapse
Read the original instructions I gave you...I will not repeat myself. You'll have to figure the rest out on your own.
Related
Hi.
I noticed the kernel in all the boot images we have here are compressed.
Looks like gzip BUT, when you try to decompress it it just adds a bunch of bytes to the file top.
So is there any way to decompress dell's kernel?
Thanks.
maxrfon said:
Hi.
I noticed the kernel in all the boot images we have here are compressed.
Looks like gzip BUT, when you try to decompress it it just adds a bunch of bytes to the file top.
So is there any way to decompress dell's kernel?
Thanks.
Click to expand...
Click to collapse
I don't think there is at the moment.
We're currently waiting for dell to release the source code for the kernel, like they're legally obliged to
Meltus said:
I don't think there is at the moment.
We're currently waiting for dell to release the source code for the kernel, like they're legally obliged to
Click to expand...
Click to collapse
Thanks, but i mean just decompress.
I made it on windows machine - winrar does the trick. But now i need to compress it back to flash with fastboot.
Btw where is the fastboot topic? Could anyone please point me in the right direction (but not to the search please).
maxrfon said:
Thanks, but i mean just decompress.
I made it on windows machine - winrar does the trick. But now i need to compress it back to flash with fastboot.
Btw where is the fastboot topic? Could anyone please point me in the right direction (but not to the search please).
Click to expand...
Click to collapse
ah, sorry, i thought you meant decrypt.
I'm not sure you could just flash it again after compressing it, wouldn't you need to sign it with google's test keys?
This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon
still working on the actual kernel, will release that next, still have lots of work to do
boot.img MD5- fca41dba8f4699b67fd461a1632b65cf
MAKE BACKUP FIRST
You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--
Code:
adb push boot.img /sdcard/
adb shell
su
dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
reboot
#Thanks Diamondback and friends for offsets
This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
NOT COMPATIBLE WITH CM-9
di11igaf said:
This basically (for right now) the stock kernel image with some tweaks to init.
-unsecure boot.img-(perma- rooted adb shell)
-adb remount(mount /system r/w)
-init.d support added in for init scripts(survive after reboot)
-ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
(Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
-mem and cache tweaks coming soon
still working on the actual kernel, will release that next, still have lots of work to do
boot.img MD5- fca41dba8f4699b67fd461a1632b65cf
MAKE BACKUP FIRST
You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--
Code:
adb push boot.img /sdcard/
adb shell
su
dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
reboot
#Thanks Diamondback and friends for offsets
This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
Click to expand...
Click to collapse
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.
MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.
Click to expand...
Click to collapse
ICS kernel source is on the global download site.
Doktaphex said:
ICS kernel source is on the global download site.
Click to expand...
Click to collapse
Correct but thats an older source code V9.4.2.7 right?
MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?
Click to expand...
Click to collapse
True, I don't know how much they have changed since then. Surely they need to be releasing new source pretty quickly to be in compliance with the license. I don't know enough about that side of things though.
prime has a BLOBSIGN signature in the first 28 bytes of the blob files for prime.
you just need to copy those 28bytes from an existing blob file that works.
this is of course only working on a unlocked prime. then the BLOBSIGN signature is not checked, so anything can be pasted in front of it.
Rayman will update the packblob to include the signature later on.
MasterZen88 said:
Great! I'm not the only one who as this problem. For what ever reason I too cannot get the blob to write.
I've tried running the blobpack -s to sign the blob but after trying to write it to the staging partition its a no go.....
EDIT: how are you working on the kernel if it has not been released yet?? JW, not trying to say your not but it would be cool if someone found a way to edit a compiled kernel.
Click to expand...
Click to collapse
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk
jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!
jermaine151 said:
I'm confused. I thought after our PMs you had it flashing just fine?
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!
Click to expand...
Click to collapse
Flashing blobs does NOT always work. No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...
Asus really screwed up with this Unlocker thing....
MasterZen88 said:
Yes it flashed but later I realize non of my settings/changes took effect.
When I stated it work, I had took the stock kernel/initramfs from asus blob, extracted, made no changes at all, recompile like we talked about in our PM's then flashed it. It work but then after I made changes, recompiled. Non of my changes took effect.
Again Jermaine you have been a BIG help. and can only hope one day I can return the favor!!!
Click to expand...
Click to collapse
No problem. I'm surprised it didn't work for you after you made changes.
Diamondback said:
Flashing blobs does NOT always work. No idea why yet. Directly dd'ing the boot.img to the right place works BETTER than flashing a blob in some cases...
Asus really screwed up with this Unlocker thing....
Click to expand...
Click to collapse
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
MasterZen88 said:
Correct but thats an older source code V9.4.2.7 right?
Click to expand...
Click to collapse
The kernel versions seem to be the same with the latest .15 build as the previous one. I wonder if they just recompiled the same source and that's why the host name changed to Mercury.
EDIT: I'm going to pack this kernel into a flashable blob and attach it here.
jermaine151 said:
No problem. I'm surprised it didn't work for you after you made changes.
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
Click to expand...
Click to collapse
Hmm.. not sure whats going on but I did use this command
Code:
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
To recompile the boot.img then used the new blobtoolsv2 to repack the blob
Code:
blobpack -s kernelblob blob.LNX newboot.img
I know staging is unmounted because I'm using your updater-script
jermaine151 said:
Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");
I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.
Click to expand...
Click to collapse
if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.
so it can easily become a problem if p4 is mounted.
at least thats how i experienced the problem when seen initially.
Dexter_nlb said:
if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.
so it can easily become a problem if p4 is mounted.
at least thats how i experienced the problem when seen initially.
Click to expand...
Click to collapse
That's why I said to always add an unmount("/staging"); to the top of your script. The attached flashable zip works perfectly on the official CWM; staging is not mounted by default, but I told the script to unmount it anyway in case someone with the unofficial CWM tries to flash it. If it's already unmounted, the script just continues.
Anyone may use this as a template for consistently flashing a kernel to staging.
MasterZen88 said:
Hmm.. not sure whats going on but I did use this command
Code:
mkbootimg --kernel boot.img-kernel.gz --ramdisk newramdisk.cpio.gz -o newboot.img
To recompile the boot.img then used the new blobtoolsv2 to repack the blob
Code:
blobpack -s kernelblob blob.LNX newboot.img
I know staging is unmounted because I'm using your updater-script
Click to expand...
Click to collapse
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?
EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.
Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:
http://forum.xda-developers.com/showthread.php?t=1193737
jermaine151 said:
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?
EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.
Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:
http://forum.xda-developers.com/showthread.php?t=1193737
Click to expand...
Click to collapse
Okay that makes sense. One f my changes was to default.prop for insecure boot.img
Code:
ro.secure=0
This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol
MasterZen88 said:
Okay that makes sense. One f my changes was to default.prop for insecure boot.img
Code:
ro.secure=0
This did not show after I flashed. But I will try again in a couple hour's once my workload calms down... SysAdmin life is not easy...lol
Click to expand...
Click to collapse
LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.
jermaine151 said:
LOL! I meant to say default.prop and not init.rc. I totally understand. I used to be a SysSdmin too. Now I moved more towards the networking side of things. Much more calm.
Click to expand...
Click to collapse
Would love to be on that side of the tracks. I'm banging my head against the wall right now trying to figure out how to implement Microsoft System Center Service Manager 2010 and on top of that one of our Citrix Broker boxes went down last night... Not a funny day at all. But I'll keep this thread about Android...for now....
No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.
Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)
So blob flashing obviously has some quirks....
Diamondback said:
No, unfortunately flashing a blob does not always do the same as dd'ing boot.img directly. We recently had a case were someone lost root access. the only way to recover was to directly dd a boot.img.
Flashing the SAME boot.img via blob did not work (nor did any other blob we tested)
So blob flashing obviously has some quirks....
Click to expand...
Click to collapse
I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.
jermaine151 said:
I just haven't see that issue flashing any of my blobs and CM9 is using the same method and it's working. Who knows.
Click to expand...
Click to collapse
We only had it one time too, but one time is enough to scare me further
This whole blob stuff just is crap
Good morning. I'm trying to build the kernel for the M4 aqua, but although sony didn't include it in the guides for doing so, I can see the files inside the tulip in sony's github repository. Then, I guess that it's possible to build a kernel from sony's sources. If anyone did so, could please post and briefly describe the steps? More concretely, the line with the arguments for mkbootimg (or the necessary tool). Thanks in advance
alguien24 said:
Good morning. I'm trying to build the kernel for the M4 aqua, but although sony didn't include it in the guides for doing so, I can see the files inside the tulip in sony's github repository. Then, I guess that it's possible to build a kernel from sony's sources. If anyone did so, could please post and briefly describe the steps? More concretely, the line with the arguments for mkbootimg (or the necessary tool). Thanks in advance
Click to expand...
Click to collapse
You can use the same instruction as How to build AOSP Marshmallow for unlocked Xperia devices to download the source.
attached is the sony.xml file you can use to limit to download only tulip builds.
then you can use the follow in commands
$# cd android
android $# export CROSS_COMPILE=/android/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
add the full path to the above CROSS_COMPILE=/mnt/../../../android/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
android $# cd kernel/sony/msm/
android/kernel/sony/msm $# make ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE aosp_kanuti_tulip_defconfig
android/kernel/sony/msm $# make ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE -j1
if make is successful, copy the kernel from arch\arm64\boot folder and past into device/sony/common-kernel
and build your full aosp or only boot.img with android$# make -j1 bootimage
RohitBopnna said:
You can use the same instruction as How to build AOSP Marshmallow for unlocked Xperia devices to download the source.
attached is the sony.xml file you can use to limit to download only tulip builds.
then you can use the follow in commands
$# cd android
android $# export CROSS_COMPILE=/android/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
add the full path to the above CROSS_COMPILE=/mnt/../../../android/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-
android $# cd kernel/sony/msm/
android/kernel/sony/msm $# make ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE aosp_kanuti_tulip_defconfig
android/kernel/sony/msm $# make ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE -j1
if make is successful, copy the kernel from arch\arm64\boot folder and past into device/sony/common-kernel
and build your full aosp or only boot.img with android$# make -j1 bootimage
Click to expand...
Click to collapse
Thanks a lot for the answer! Today, I had my computer setup with everything needed, with sony's guide. I've only made one modification. Inside the kanuti folder (~/android/device/sony/kanuti/rootdir) there's a file called fstab.kanuti. I changed the /data mountpoint to the second partition in the sdcard (in order to get more internal space, if I make it work someday I will post it inmediately ).Then, after carefully following the steps you gave me, I finally got the boot.img. Flashed it with fastboot flash boot boot.img, but when I powered the phone on, after half a second it shut down. Tried more than once with the same result. I flashed again the original kernel, and it came back to live with no more problems. Do you (or anyone) know where the problem could be? I also saw that the boot.img file weighs 9 MB, while the original kernel.elf extracted from the ftf takes 20 MB of space. Is this usual?
alguien24 said:
Thanks a lot for the answer! Today, I had my computer setup with everything needed, with sony's guide. I've only made one modification. Inside the kanuti folder (~/android/device/sony/kanuti/rootdir) there's a file called fstab.kanuti. I changed the /data mountpoint to the second partition in the sdcard (in order to get more internal space, if I make it work someday I will post it inmediately ).Then, after carefully following the steps you gave me, I finally got the boot.img. Flashed it with fastboot flash boot boot.img, but when I powered the phone on, after half a second it shut down. Tried more than once with the same result. I flashed again the original kernel, and it came back to live with no more problems. Do you (or anyone) know where the problem could be? I also saw that the boot.img file weighs 9 MB, while the original kernel.elf extracted from the ftf takes 20 MB of space. Is this usual?
Click to expand...
Click to collapse
the latest kernel that sony has implemented image.gz-dtb is a compressed kernel with the DTB combined, and this needs bootloader level gzip feature to unzip the kernel and load, which is not present today in our bootloaders. After building your kernel, Use the uncompressed kernel (image file and dtb) to build your boot image with old way, you may have to make changes in you boot build to indicate uncompressed kernel.
RohitBopnna said:
the latest kernel that sony has implemented image.gz-dtb is a compressed kernel with the DTB combined, and this needs bootloader level gzip feature to unzip the kernel and load, which is not present today in our bootloaders. After building your kernel, Use the uncompressed kernel (image file and dtb) to build your boot image with old way, you may have to make changes in you boot build to indicate uncompressed kernel.
Click to expand...
Click to collapse
I'm not really experienced in building kernels, I'm trying to learn a bit with this stuff I'm doing... And this phone hasn't got a lot of information yet. Could you please tell me what you mean with building it the old way?
LOL
You are in the stock rom, aren't you?
So, why would you try building an aosp kernel (which is f**ked up) in your stock rom?
You have to build from kernel-copyleft
There is also a tutorial from sony developer world
http://developer.sonymobile.com/kno...h-a-linux-kernel-from-sony-copyleft-archives/
I think you have to find the right defconfig and change arm to arm64 and aarch64 when necessary
RohitBopnna said:
the latest kernel that sony has implemented image.gz-dtb is a compressed kernel with the DTB combined, and this needs bootloader level gzip feature to unzip the kernel and load, which is not present today in our bootloaders. After building your kernel, Use the uncompressed kernel (image file and dtb) to build your boot image with old way, you may have to make changes in you boot build to indicate uncompressed kernel.
Click to expand...
Click to collapse
Now I got what you explained me. I've been looking for information, and I thought that after running make, the dtb file should be in the boot folder, but there I can only find the image file. How can I create the dtb file separately from the dts?
dani020110 said:
LOL
You are in the stock rom, aren't you?
So, why would you try building an aosp kernel (which is f**ked up) in your stock rom?
You have to build from kernel-copyleft
There is also a tutorial from sony developer world
http://developer.sonymobile.com/kno...h-a-linux-kernel-from-sony-copyleft-archives/
I think you have to find the right defconfig and change arm to arm64 and aarch64 when necessary
Click to expand...
Click to collapse
Now I'm not in stock, I've flashed the AOSP rom available in this post: http://forum.xda-developers.com/m4-aqua/development/5-0-aosgp-based-stock-t3262330. So that shouldn't be a problem, right?
aosgp?? a stock rom with aosp style dude,,base on stock not a real aosp
Sent from my E2353 using XDA-Developers mobile app
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
toknitup420 said:
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
Click to expand...
Click to collapse
It could be missing metadata. Are you starting with this fimware? I can unpack it and locate the files with unique permissions. It may help figure out what is missing. Not using sparse dat is not your issue. set_metadata will work once we track down the problem.
SuperR. said:
It could be missing metadata. Which firmware are you starting with? I can unpack it and locate the files with unique permissions. It may help figure out what is missing. Not using sparse dat is not your issue. set_metadata will work once we track down the problem.
Click to expand...
Click to collapse
Do you want a copy of the current project I have in kitchen. I can upload it to my drive. I just used the zip from the may factory image.
Edit
Wow I just realized that was a link lol. I totally misread lol. Yes I'm using that firmware.
toknitup420 said:
Do you want a copy of the current project I have in kitchen. I can upload it to my drive. I just used the zip from the may factory image.
Edit
Wow I just realized that was a link lol. I totally misread lol. Yes I'm using that firmware.
Click to expand...
Click to collapse
You did not misread, i changed it I will check it out when I get a chance. No need to upload your project.
toknitup420 said:
@superr
I'm having some trouble with ROM builds for the pixel XL. I made a bone stock ROM. It boots but has Bluetooth share force close. I think it's due to not being able to use sparse for perms. Currently trying with may build. I'm on Linux mint 18.1
Click to expand...
Click to collapse
Can you try this updater-script to see if it fixes the issue? There are actually 2 attached, with_vendor and no_vendor in case you extracted vendor too. If you replace it in the kitchen, make sure you zip the ROM manually because the kitchen will change it before zipping based on the files you have.
SuperR. said:
Can you try this updater-script to see if it fixes the issue? There are actually 2 attached, with_vendor and no_vendor in case you extracted vendor too. If you replace it in the kitchen, make sure you zip the ROM manually because the kitchen will change it before zipping based on the files you have.
Click to expand...
Click to collapse
so i cant zip manually because i dont have perms for one file in system. heres a pic. ill just add the script into an existing zip i built from kitchen.was
update
so i was able to move the script into the correct location and zip up the file. however when it flashes the updater script is somehow becoming merged with the original instead of just the new script. it still shows the original script text when flashing.
toknitup420 said:
so i cant zip manually because i dont have perms for one file in system. heres a pic. ill just add the script into an existing zip i built from kitchen.was
update
so i was able to move the script into the correct location and zip up the file. however when it flashes the updater script is somehow becoming merged with the original instead of just the new script. it still shows the original script text when flashing.
Click to expand...
Click to collapse
I will build a rom and upload for you to try. Are you building with vendor included or without?
SuperR. said:
I will build a rom and upload for you to try. Are you building with vendor included or without?
Click to expand...
Click to collapse
I built it without. Do you recommend to build it with vendor. Should that file be root like that. The one that's in that pic I sent.
toknitup420 said:
I built it without. Do you recommend to build it with vendor. Should that file be root like that. The one that's in that pic I sent.
Click to expand...
Click to collapse
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
SuperR. said:
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
Click to expand...
Click to collapse
OK I'll try it now. Good looks.
SuperR. said:
Here is the marlin n2g47o test rom:
https://www.androidfilehost.com/?fid=817550096634774971
It is up to you about vendor. You must have matching vendor and system or the rom will not boot. If you inform users they must flash the corresponding vendor.img along with the rom you don't need to include it. The test rom does not include vendor so make sure you have the correct vendor flashed.
The root file you refer to is actually a directory symlink and should not be there at all. I have fixed this behavior locally and in this test rom. If all works, I will push the update.
Click to expand...
Click to collapse
it flashes with no errors but it wont boot past splash screen.
toknitup420 said:
it flashes with no errors but it wont boot past splash screen.
Click to expand...
Click to collapse
Please try marlin n2g47o test rom 2:
https://www.androidfilehost.com/?fid=745425885120737663
SuperR. said:
Please try marlin n2g47o test rom 2:
https://www.androidfilehost.com/?fid=745425885120737663
Click to expand...
Click to collapse
flash went through without error but still boot looping at splash screen.
toknitup420 said:
flash went through without error but still boot looping at splash screen.
Click to expand...
Click to collapse
Moved to a dedicated thread as this issue is only about Pixel.
I will do more thinking on what could be causing it. I was pretty sure the last rom would fix it but clearly I was wrong lol
SuperR. said:
Moved to a dedicated thread as this issue is only about Pixel.
I will do more thinking on what could be causing it. I was pretty sure the last rom would fix it but clearly I was wrong lol
Click to expand...
Click to collapse
Lol good stuff. Keep me posted. I'll test whatever you throw at me.
toknitup420 said:
Lol good stuff. Keep me posted. I'll test whatever you throw at me.
Click to expand...
Click to collapse
Here is a new approach so I don't have to keep uploading full roms. Use the kitchen to extract the last rom I sent into a new project. In your file manager, navigate to your project directory and delete the 00_project_files directory. Extract the attached file into your project directory. Build rom with kitchen. Test rom.
Next time, you won't need to extract the rom zip again, just replace the 00_project_files directory.
edit: forgot to mention, after replacing the 00_project_files directory with the one in the zip, change perm types to something else, then back to set_metadata. Then build your rom
SuperR. said:
Here is a new approach so I don't have to keep uploading full roms. Use the kitchen to extract the last rom I sent into a new project. In your file manager, navigate to your project directory and delete the 00_project_files directory. Extract the attached file into your project directory. Build rom with kitchen. Test rom.
Next time, you won't need to extract the rom zip again, just replace the 00_project_files directory.
edit: forgot to mention, after replacing the 00_project_files directory with the one in the zip, change perm types to something else, then back to set_metadata. Then build your rom
Click to expand...
Click to collapse
flashing seemed to hang at setting perms. but it eventually went through. still looping at splash screen though.
toknitup420 said:
flashing seemed to hang at setting perms. but it eventually went through. still looping at splash screen though.
Click to expand...
Click to collapse
Can you send the original updater script that booted but did not have bluetooth?
SuperR. said:
Can you send the original updater script that booted but did not have bluetooth?
Click to expand...
Click to collapse
https://drive.google.com/file/d/0B4VEhClrJEWpNnJNVUJTRFV4ODQ/view?usp=sharing
https://drive.google.com/file/d/0B4VEhClrJEWpTmlYWC1CQ0s3LVE/view?usp=sharing
thats the binary and the script. i converted script to binary when i was building rom. this rom boots and runs ok other than bluetooth. its not completely stock though. i have my modded framework settings and system ui apks in there. but they are all signed so i dont think they would mess with anything.
toknitup420 said:
https://drive.google.com/file/d/0B4VEhClrJEWpNnJNVUJTRFV4ODQ/view?usp=sharing
https://drive.google.com/file/d/0B4VEhClrJEWpTmlYWC1CQ0s3LVE/view?usp=sharing
thats the binary and the script. i converted script to binary when i was building rom. this rom boots and runs ok other than bluetooth. its not completely stock though. i have my modded framework settings and system ui apks in there. but they are all signed so i dont think they would mess with anything.
Click to expand...
Click to collapse
Did you convert the new one you just tried after swapping 00_project_files to update-binary? If not, try it please. If so, try without please
I've spent last day automating the guide at https://forum.xda-developers.com/t/guide-t220-t225-flash-a-gsi-on-the-a7-lite-without-twrp.4456821/ into a bash script (linux only)!
Here it is releasing it for anyone that needs it
Code:
I am not responsible whatever happens to your device
by using this script, i have tested it on my own device
and it worked but it may or may not work for you.
I will do my best to help you but that may be limited
as i have other responsibilities in life
Before starting read the third post
UsageDownload the your desired firmware from somewhere like samfw.com and extract it
Download your desired GSI image and extract it
Download otatools-mini, gsi-build script and vbmeta image, place them all together inside one directory (extract the otatools-mini next to the script)
Download patched odin
Run this in Linux or WSL!
Code:
$ ./build-gsi.sh <PATH TO YOUR AP FILE .tar.md5> <PATH TO GSI .img>
And let it do the work, may take a while depending on your PC
You may get something like this in the process, ignore it
Code:
Invalid sparse file format at header magic
Then go into download mode (VOLUME UP and DOWN when plugging in USB) and flash the CUSTOM_AP file you got from the script and BL, CSC from the firmware you used, DO NOT USE HOME_CSC
Reboot into recovery and factory reset (VOLUME UP while booting)!
If you are getting dm-verify error then flash the vbmeta_disabled_R (it needs to be .tar, extract it) in odin as AP and try rebooting again into recovery
DownloadsI used to provide one archive but it was large and i couldnt change the script without reuploading it so i am going to use gist for the script and provide other files separately
ota-tools-mini
build-gsi.sh
Getting HelpIf you want me to help you ALWAYS post full output from the script, and make sure to use the latest script from the gist
I've spent a lot of time trying to make it work with all GSIs but i could not get it to work consistently
By default it works for all smaller GSIs, if you get the following error
Code:
ERROR: Output image is bigger than original super image, rerun the script with correct super image size
Then you will have to manually provide the new super size which i cannot help you with try to guess but it has to be divisible by 512
Not enough free space to expand partition: vendor
error while repacking
i have a lot of space . but it shows me like that
lpmake E 01-15 23:22:16 100 100 builder.cpp:698] [liblp]Not enough free space to expand partition: vendor
i am using debian wsl
Please post full script log in a spoiler or pastebin
sandorex said:
Please post full script log in a spoiler or pastebin
Click to expand...
Click to collapse
Could you try normal AP file not the magisk patched, i do not know how it modifies it
Also from my experience you do not need to patch whole AP file for magisk, you just need to patch the boot.img, zip it then flash it
OK . i will try
i tried with original ap file but same error
dxsyrz said:
i tried with original ap file but same error
Click to expand...
Click to collapse
It seems for some reason your gsi is too big, i managed to reproduce it, ill see if i can fix it
@dxsyrz can you test this one, it should work now
EDIT: i've updated the gist so you can just use that instead
good util but test more.
tom.android said:
good util but test more.
Click to expand...
Click to collapse
It worked for me, i would not release it if it did not work
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
OK sorry to write that message.
sandorex said:
It worked for me, i would not release it if it did not work
Click to expand...
Click to collapse
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
nirogu325 said:
Well, something did not work in my case:
:: Uncompressing super image
super.img.lz4 : decoded 5637366988 bytes
:: Running simg2img
./build-gsi.sh: line 79: /mnt/c/Users/Zero/Desktop/otatools-mini/otatools-mini/simg2img: No such file or directory
^ Despite the files actually existing. You tell me cuz I've no idea (do note I do know how to do this manually, was just trying your script to simplify everything).
Click to expand...
Click to collapse
You need to place otatools-mini in folder next to the script not together with the script
hi i have this problem
izimen said:
hi i have this problem
View attachment 5814501
Click to expand...
Click to collapse
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
sandorex said:
You havs a space in your path, its actually a bug but you can jist move the files to somewhere without spaces
EDIT: Fixed it on gist
Click to expand...
Click to collapse
ok i try
bro it worked thank you I managed to make it work with a GSI and when I try with another I have this error