How to Decompress & Compress a .fota file? I have tried using the Wave Remaker to decompress the fota file but i dont think its working. Can you tell me how to do it? I'm trying to make the fota file to allow boot Ice Cream Sandwich 4.0. I may not have that much experience in doing that but i just want to give it a try
FOTA file isn't compressed any way. It's pure ARM32 code.
Then how did you make the fota file able to allow Alpha Froyo version? Should we use ubuntu for that? Since fota is a proprietary file of bada, Google is of no help.
You need a big background on ARM architecture to understand this
You need to disassemble fota file first with a disassembler like IDA Pro
Then understand its ARM code (At least some of it)
Then write your own fota file
I guess that you know nothing about ARM so learn first
Best Regards
mylove90 said:
You need a big background on ARM architecture to understand this
You need to disassemble fota file first with a disassembler like IDA Pro
Then understand its ARM code (At least some of it)
Then write your own fota file
I guess that you know nothing about ARM so learn first
Best Regards
Click to expand...
Click to collapse
Thanks for your reply. I started taking online lessions after Rebellos told about the ARM32 form. Just got a GDB Assembler and a GDB Debugger. Now trying to understand the basics.
I'd rather get IDA disassembler and FASM-ARM assembler and play with these files
http://code.google.com/p/badadroid/source/browse/#svn/trunk/FOTA
Rebellos said:
I'd rather get IDA disassembler and FASM-ARM assembler and play with these files
http://code.google.com/p/badadroid/source/browse/#svn/trunk/FOTA
Click to expand...
Click to collapse
Thanks Seems much Easier. I will play with these files and try to boot ics using the previous method of installing android.
if you want to boot ICS there will be no changes likely to be necessary on the fota side, its just our bootloader and it will execute an ICS kernel if you give it one.
the reason we have no ICS is simply because we lack experienced people to develop drivers for the ICS kernel, same reason goes for why gingerbread work has been slow.
if you want iCS working i'm afraid that no amount of working on the fota is likely to change this, kernel and platform driver code is needed.
If you want to simple boot any ARMLinux kernel - the mandatory is S5PV210 CPU driver inside of it. No matter if it's Eclair, ICS or Ubuntu. If you've got correct CPU driver - it will start (till some point, other drivers like for screen are nice to have too) and print debug into UART. FOTA doesn't need to change. Just replace zImage with any other you wish, compiled with the same EntryPoint as SGS kernel zImage (0x32000000, you can find it in in kernel/arch/arm/mach/s5pv210/Makefile.boot AFAIR)
Thanks for your help guys Tried to boot ICS Cyanogenmod 9.x of SGS. But i just shows the Boot Screen, I think fota file is showing the boot screen. And i used the Zimage and sbl file from the latest build from the tutorial thread. I tried to delete some apk files from the Apps folder thinking the apps are giving it some load. Can i use the same Zimage and sbl files or should i try to modify them? Again Thanks for helping
Edit 1:
So i need a kernal for ICS which will allow the our bootloader to boot in? There are some devs who i know have experience in it. But they are mostly from the US so they won't have the devices. So i will start learning the art of creating kernals though it will take some light years for me to understand them
well what did you try? if you try an i9000 ICS ROM (that means platform files) with our froyo kernel it likely won't work as the android platform versions usually have to match with specific kernel versions.
the image you would have seen would have been the static boot image our kernel shows on init of the display driver, since things like the init and device arrangement might be different they wouldn't matchup and so it halted.(basically it's an identical effect to what would happen if you removed the android platform filesystems completely and then executed the kernel)
nbates66 said:
well what did you try? if you try an i9000 ICS ROM (that means platform files) with our froyo kernel it likely won't work as the android platform versions usually have to match with specific kernel versions.
the image you would have seen would have been the static boot image our kernel shows on init of the display driver, since things like the init and device arrangement might be different they wouldn't matchup and so it halted.(basically it's an identical effect to what would happen if you removed the android platform filesystems completely and then executed the kernel)
Click to expand...
Click to collapse
Ok. I got the GB Kernel sources from the Open Source Project. But there is no Sources for kernel for ICS for SGS. So going to start some development for kernel. But using the sources how to inject the kernel with our bootloader to allow the booting process?
Related
Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave
Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?
yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/
Your not going to able to sign it without Samsung's signatures... and good luck finding those
yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.
just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days
So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.
For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage
Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.
DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...
Finally managed to build a zImage, but now trying to build a *.nbh file with it. I've git both bootenv, tinboot, and also the latest kernel commit for 2.6.32.
Compressed initrd.lzma down to 1.1MB (original initrd.lzma was about 950KB, but with it, still got the error), and my zImage is 1.9MB, but I continue to get this error whenever I run this:
Code:
./compilekaiser
Code:
tinboot.S: Assembler messages:
tinboot.S:142: Error: attempt to move .org backwards
./arm-none-eabi-objcopy: 'tinboot.o': No such file
cat: tinboot: No such file or directory
=== yang v1.1: Yet Another NBH Generator
=== (c) 2008 Pau Oliva Fora - pof @ XDA-Developers
[] Output NBH file: KAISIMG-PANEL3-320-TILT4-FROYO.NBH
[] Input files: output.nb
[] Input types: 0x400
[] SignMaxChunkSize: 64
[] Device: KAIS****
[] CID: 11111111
[] Version: 1.0.MARTIN
[] Language: WWE
[] 0x400 --> output.nb
Done!
I've done some searches, and found that I have to decrease the size of my initrd, but not sure what else to strip from it, and also my zImage is base built, and the size really doesn't change whenever I change any options in menuconfig.
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
Click to expand...
Click to collapse
Thanks! Using the default initrd.lzma did the trick. Now if only the bootenv git was updated with this compressed initrd. xD
Currently using a custom kernel I built. Made some changes to yaffs2, mtd, and NAND configuration. Had a crash on initial boot, did a soft reset and phone came back with no corruption, and my "bad block 160" went away. I'm currently testing it for 24hrs, then if all goes well, I'm going to go a week and report back.
Though currently I have no bluetooth, as the module isn't loading.. Will look into that, and try and see if it's build related, and if the module can be loaded manually.
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
l1q1d said:
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
Click to expand...
Click to collapse
Currently bluetooth is not my concern, though I did get it running, by loading the modules manually using 'modprobe', but I have no idea how well the bluetooth subsystem works in its current state, but it does turn on, and do a search of nearby devices.
My main concern is my NAND configuration. So far no issues as of yet, but will know more when 1.5days elapses. Had an issue last night with the phone app crashing with acore failing, but coming back after rebooting the phone with no data loss.
Gmail app also crashed, but after 2 crashes it reloaded (possibly some data loss), and started re-syncing my email.
Besides those two, no real issues yet.
Krazy-Killa said:
Besides those two, no real issues yet.
Click to expand...
Click to collapse
What have you changed, just options in the defconfig?
scooter1556 said:
What have you changed, just options in the defconfig?
Click to expand...
Click to collapse
Enabled yaffs ECC support, but forced it to use the same ECC as the NAND driver. Enabled NAND ECC support inside the driver itself, as well as other changes.
Also left block refreshing, background processing, and left force chunk erase check enabled.
Had to disable EXT2, and EXT4 file system support to decrease kernel size, but for my case, don't need them as I'm using full NAND install anyways.
Currently approaching 18hrs, with no issues, installed more apps with no issues with corruption, still getting random FCs with core apps, but they re-enable afterwards (Most likely isolated, so not a real concern at the moment). Once i approach 18hrs, I'll do a safe reboot, and see what happens there.
My bad block 160 came back, but that's the only bad block that has returned, no new ones as of yet.
I'm hoping to concentrate my efforts on working on cpu scaling, whether it be using CPUFreq, or a kernel hack... I'm actually interested in knowing how Myn got his Rogue Tools to adjust the CPU Scale dynamically. As I'm thinking (though horrible at coding), of writing a kernel module to dynamically adjust the CPU core based on activity of the core.
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
Click to expand...
Click to collapse
I'll most likely contact Myn first chance I get. Been busy with family matters as of late.
Built a new kernel yesterday morning, and showing promise. Phone goes into a very deep sleep now (literally have to wait 5-10 seconds for the phone to respond like when a PC wakes from suspend), and actually shows improvement in battery life while in sleep mode but massive increase in battery usage when phone is waking, so may have to change how the phone sleeps.
Phone stability has increased as well. Despite the slow time it takes to wake, the phone has yet to crash, or slow down performance wise.
NAND is also showing improvement. Did a soft reset last night, phone restarted without problem, and no loss of data or any yaffs tragedy errors. Still installing apps at the moment. Data partition is at 45MB out of 101MB.
Free RAM is at 35MB while on home screen.
Currently using Radio 1.70.19.09, and HardSPL 3.56.
If all goes well, tonight I may post my kernel flavor as well.
*EDIT* Anyway that the bootenv git repo be updated with what's being used in initrd.lzma file?
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
tiagoclc said:
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
Click to expand...
Click to collapse
Currently running into a problem with the acore being corrupted, which doesn't make since as it's in /system.
I'm testing out having CompCache running but not JIT, as each time acore gets messed up the JIT was enabled.
If all goes well tomorrow, I may post the updated kernel and and androidupdate.tgz file with modules.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
Click to expand...
Click to collapse
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Click to expand...
Click to collapse
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Can parted be moved from initrd to the android rom?
That saves a ton of space, and allows all to fit.
NO, parted is needed for atools - sd partitioner, i change both the 2.6.25 and the 2.5.32 to lzma initrd for it.
n2rjt said:
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Click to expand...
Click to collapse
I haven't had a problem with repacking initrd.lzma. I've kept mine below 975KBs, which is perfect for me.
Also as far as using what Rogue Tools uses, I've determined it wouldn't be a good system to code, as it requires to phone to sleep first before the new clock settings take effect.
I'll continue to look into the cpu coding, to find why scaling is not being recognized by the kernel. For now, I'm going to try and downclock the cpu core to 250MHz to see how much of a difference I get in battery life, but I suspect I won't get much since the voltage isn't being changed.
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
Hi! Could you share what you did to slove the problem "tinboot.S:142: Error: attempt to move .org backwards".Thank you in advance.
Kernel plus initrd are too large if you get that message. First be sure your initrd is built with hardlinks to busybox. If that is still too large try fewer kernel features. For me, the standard kernel and bootenv fit. What sizes are the zImage and initrd.lzma files for you?
Sent from my Android on HTC Kaiser using XDA App
Man I need to read up on all the new Linux stuff... I'm so far behind I'm getting lost.
Personally I want to pack initrd and everything else into a package along with a singular build (current 2.2 8/25/2011) and just make one install package for everything. That way I can pack the install, updates and kernel into one kaisimg.
Keep up the good work guys!!!
The starting idea is wrong!
The multiple file: the nbh for kernel and initrd and the tgz file are setted up for large compatibility (multiple device use them). So creating a nbh only for kaiser is a bad idea.
Also you need to create a nbh for every single parameter in atools (like screen, keyboard, panel) it's crazy!
On Samsung phones I guess you can turn root on/off by changing the variable in default.prop, but I have my phone rooted and it says ro.secure=1. How would I modify the bootloader? What would I look for to find out what I'm talking about?
I would like to try compiling my own kernel too. XDA University has information about compiling the kernel, but it is kind of unclear about how to put the actual package together though, or at least confusing. It says just zip the image and .ko files together and then it is good to flash, but then gives a file structure tree with unknown files? I downloaded a kernel to test from this site and the file structure was different, and it also reset the whole phone to get the job done.
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Akopps said:
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Click to expand...
Click to collapse
Simg2img works fine for me as does make_ext4fs.
I use these 2 binaries all the time and can unpack and repack system images no problem.
Either you're using the wrong versions or your syntax is wrong.
There's also a toolkit available somewhere that you can compile on Linux which will build all the necessary binaries.
However at the moment the name escapes me.
EDIT : here we go.
https://forum.xda-developers.com/showthread.php?t=2600364
linux meanwhile have a package for simg2img
Code:
sudo apt-get install android-tools-fsutils
sudo yum install android-tools
Here a complete guide. Tested on product.img.lz4 inside CSC tar.
samsung android 10 pack repack img.lz4
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10 - samsung-android-pack-repack.sh
gist.github.com
make_ext4fs does not work on newer android versions. You must use latest img2simg to convert a raw img to sparse image (it works on android 10)
Akopps said:
I have tried to look up what it takes to unpack a T800_whatever.tar.md5, mod it, and then put it back together, and frankly I think none of the guides I have seen work. They're too outdated, and Samsung changed something. The whatever.tar.md5 file is no longer a tar archive with md5 sum attached to it, but it is now a tar archive, with some metadata, and md5 checksum attached.
The next issue is how to convert a sparse system.img back into non-sparse one after it was modified. One tool simg2img, which many recommend, doesn't seem to work, and another tool called make_ext4fs seems to be impossible to build from source because nobody has provided the damn instructions on how to build it. The typical open source Linux/Unix software in 99% of cases comes with makefiles and configurations scripts and (don't laugh) README files which make building software easy. But google's sources seems to have none of that. Some web sites suggest a specific gcc command to build it, but of course it won't work on _my_ specific Linux laptop (CentOS). I can't believe this stuff has to be so hard. This is just sloppy packaging and software distribution on google's part.
Click to expand...
Click to collapse
renzofilini said:
Here a complete guide. Tested on product.img.lz4 inside CSC tar.
samsung android 10 pack repack img.lz4
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10
Procedure to modify a product.img.lz4 used by Samsung Android phones with Android 10 - samsung-android-pack-repack.sh
gist.github.com
Click to expand...
Click to collapse
Hi. Do I get it right that this won't affect the bootloader, thus the Knox bit?
Hello to all!
I'm an heavy oneplus user, currently with Nord, but i'm try to use my old but Gold Oneplus 3 to run Klipper+Moonraker+Fluidd.
Klipper side everything is perfect, still remains one big issue: there is no kernel compiled for OP3 which has USB_SERIAL_CH341 driver enabled.
I'm trying to build but without success. Here is what i've done under Linux Mint latest version.
First of all i've installed a lot of packages, i cant remember all because i used various guides since initially i was not able neither of finish compilation.
Then i've downloaded:
kernel source: https://github.com/lin16-microg/android_kernel_oneplus_msm8996/tree/lin-16.0-mse2
from this ROM thread, which is the rom im still using: https://forum.xda-developers.com/t/...ened-lineageos-16-0-for-oneplus-3-3t.4034869/
initially i've tried to use EVAgcc toolchain, but it was impossible to finish to build. Then i switched to AOSP toolchains:
32bit: https://android.googlesource.com/pl...inux-androideabi-4.9/+/refs/heads/pie-release
64bit: https://android.googlesource.com/pl...64-linux-android-4.9/+/refs/heads/pie-release
With Them i was able to compile from source, but before doing i modified the file called "lineageos_oneplus3_defconfig" by adding "USB_SERIAL_CH341=y" just under the "USB_SERIAL=y" in order to have the serial driver compiled and loader (if i have understood right?).
to build i've used from inside kernel source cloned directory:
>make clean
>make mrproper
>ARCH=arm64 SUBARCH=arm64 CROSS_COMPILE=googletoolpath/bin/aarch64-stuffs- CROSS_COMPILE_ARM32=googletoolpath/bin/arm-stuffs- make O=out lineageos_oneplus3_defconfig
>ARCH=arm64 SUBARCH=arm64 CROSS_COMPILE=googletoolpath/bin/aarch64-stuffs- CROSS_COMPILE_ARM32=googletoolpath/bin/arm-stuffs- make O=out Image -j2
in this way i've obtained an Image (not a zimage since with zimage returned error).
Then i unpacked the stock boot.img with Android Image Kitchen, substituted boot.img-kernel file (which is an archive..?) with the compiled image renamed.
Finally i repacked everything.
Tried to flash the repacked boot img but no boot, the phone returns to fastboot screen.
I've noticed that my newboot.img is around 25mb insted of around 12mb like the stock one present in the Rom.zip
Probably the error resides in how i've managed to unpack and repack the kernel image..
Do someone see some heavy error which can cause the problem? What can i try?
From a side, as automation engineer, i want to learn and try to do it by myself, but on the other side, if someone is able to compile it for me with serial CH341 driver enabled a beer is assured.
Thanks all to have read up to now and for any advice
not sure that's important but you forgot to gzip kernel before repacking. I recommend to compile with configuration of running kernel from device /proc/config.gz first.
alecxs said:
not sure that's important but you forgot to gzip kernel before repacking. I recommend to compile with configuration of running kernel from device /proc/config.gz first.
Click to expand...
Click to collapse
I've to try because it is not gzipped by default, the problem is that I don't found all in one scripts or config file as the one mentioned by you. I would never thought that rebuild a kernel were so tricky.