yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] hohassan444:
thanks for continuous and great support....however using 7zip in windows i get 2 files (0 & 1 )...extraction of both gives me full ramdisk and zimage in 2 separate folders.
[SuperR Kitchen] bigrammy:
What's your point exactly :confused:

superr has made it quite clear the only reason for unpacking the kernel.elf is to get the info required by the kitchen. :rolleyes:

Unless you have a proven and universal linux script to unpack and repack the Sony Xperia kernel.elf's then please don't bother him as this is very device specific and you should not ask or expect him to do these things for you. :eek:
[SuperR Kitchen] hohassan444:
i don't request him to do something....i just give my observations that may help !
[SuperR Kitchen] bigrammy:
Ref: Sony .sin and .elf

Hi [MENTION=5787964]SuperR.[/MENTION]

This For reference only bro I do not expect or ask for anything so if you wish to use the info that's cool if not that's also cool too :D

Just saves a little google time. :o

http://pastebin.com/4aNV8zTA
[SuperR Kitchen] SuperR.:
Great info, thank you. The only part I am not sure how to deal with are the addresses in these lines:

python mkelf.py -o new_kernel.elf 0@0x00200000 1@0x01200000,ramdisk

Where do these (0@0x00200000 1@0x01200000) come from? They are likely different on every model. unpackbootimg takes care of this on standard boot.img but 7-zip does not as far as I know.

edit: also curious, can kernel.elf be renamed to boot.img and flashed normally or are there additional requirements?
[SuperR Kitchen] bigrammy:
Hmm yes I see your point bro about the kernel and ramdisk address :eek:

Further research on that is required I guess :laugh:

A simple rename of the .elf does not work although boot.img's and recovery.img's do work or at least on my Xperia ZL (Qualcomm) and C4 (Mediatek) and the way I converted the fotakernel.elf to a recovery.img was a little unconventional to say the least :laugh:

Essentially I took a standard same SoC recovery.img unpacked it swapped the kernel and ramdisk then repacked it. :cowboy:

Most Mediatek .img's share the same addressing on the same android versions due to the mediatek kernel source :D

Making the .elf (best option) universal by detecting the the kernel and ramdisk addresses may be problematic as you suggest so I will go back to the drawing board on that :o

Thanks for taking the time to have a look bro your awesome :highfive:
[SuperR Kitchen] shoey63:
[MENTION=4904057][NUT][/MENTION] is the dev who is an expert on kernel.sin/kernel.elf unpacking and repacking. His work for Sony devices is legendary:cowboy:

Have a look at His github repo

Perhaps his scripts can be modified to do a basic unpack/repack for kernel.elf boot images, with his permission and due credit of course ;)
[SuperR Kitchen] bigrammy:
Thanks shoey63 :good:

Agreed NUTs the man when it comes to Sony but I can't see anything obvious in his repo and his online tool failed with the mediatek kernel.elf :(
[MENTION=5787964]SuperR.[/MENTION]

I think readelf in binutils may be able to help us with the addresses see here for usage https://greek0.net/elf.html I should be able to get to my Linux pc in a hour or so to do some testing. :o

Sony/Mediatek boot and recovery .sin Here for the curious. :eek:

I kind of feel like this is hijacking the thread and I don't want to do that but not sure on the best way to communicate with you. :confused:
[SuperR Kitchen] hohassan444:
[MENTION=5787964]SuperR.[/MENTION]..deodexing Xperia rom represents a pain to many of us . the kitchen is unable to deodex it...however following this guide :

http://xdaforums.com/crossdevice-dev/sony/guide-deodexing-10-6-1-0-454-odex-sqfs-t3116313/

I successfully manged to deodex , build and flash xperia rom ( C4 dual...mediatek) using the kitchen.

I think this may help to add support to kitchen.

thanks in advance.
[SuperR Kitchen] SuperR.:
This is a development thread on xda. Let's develop :)

Send me a link to firmware that requires this and I will look into it :)
[SuperR Kitchen] bigrammy:
Thats cool :cool:

Finally I have made some progress after going around in circles for hours to try find a working method of extracting just the .elf from the .sin without having to fire up FlashTool since the sin2elf did not work on these newer sin files :eek:

As chance would have it it's due to another awesome tool UnSIN.exe Here (requires mono but works perfect :D )from the same dev of the deodex method [MENTION=1879618]IgorEisberg[/MENTION] I can now finally move on to the next steps. :good:

I am thinking we may be able to recompile everything as a boot/recovery.img :fingers-crossed:

I will continue to work on the method. :cowboy:

PS: for a standard all in one unpacking of the .sin > .elf > kernel and ramdisk.gz > unpacked ramdisk DoomLord's unpack-kernelsin.pl Thread here seems to work just fine
[SuperR Kitchen] andy_zhang:
Good tool

VS985 USER
[SuperR Kitchen] SuperR.:
Thanks for continuing work on this. It is not ideal to require mono to use the kitchen so I may just stick with pre-extracted elf files. I guess the main thing to figure out is a universal way to repack kernel.elf. After that we can either figure out how to convert(?) kernel.elf to boot.img, or add the required info to the updater-script to flash kernel.elf as it is.
[SuperR Kitchen] bigrammy:
Hi,

I agree 100% about "mono" and it should be down to the individual to ensure they have a valid kernel/boot/fotakernel.elf file and system.img for the kitchen to use.

The UnSIN.exe works perfect for extracting both without needing to use "FlashTool" to pull the boot.elf and system.img. I can't find anything "Linux" that does the same job which is unusual as I am sure it would not be too difficult for someone who knows what they are doing.

DoomLord's tool works well but goes past the point I/we want it to stop :( It would be "Nice" to be able to pause it on pulling the .elf so we could run readelf on the extracted .elf to grab the addresses required for repacking it. :eek:

I can do all things you list manually but getting all this to work in a "proper manner" is a little bit more difficult :laugh:

I will keep notes as I go and stick them on pastebin for you to look at occasionally so that I don't bore everyone else in the thread with my ramblings :laugh:
[SuperR Kitchen] SuperR.:
I am happy to script it if you post the commands you are using and what you are looking for in the terminal output if applicable :)
[SuperR Kitchen] ambasadii:
it will be perfect if you can add option for stock kernel after unpack boot.img :

SELinux to permissive patch

Ramdisk's fstab patch

btw great job [MENTION=5787964]SuperR.[/MENTION]
[SuperR Kitchen] IZI.Xav:
Hi guys, I wanted to congratulate the author of the kitchen really good job.

I only use the kitchen from now.

Thanks SuperR :good:
[SuperR Kitchen] hohassan444:
1 - download xperifirm from this thread

http://xdaforums.com/crossdevice-dev/sony/pc-xperifirm-xperia-firmware-downloader-t2834142

2 - open it ...select c4 ...dual..then download it

3 - download flashtool

http://www.flashtool.net/index.php

this program to convert system.sin to system.img ( from tool menu...sin editor..select extract)

again thanks for your support.
[SuperR Kitchen] SuperR.:
That is all way too much. Please send link to system.img/boot.img already extracted. Thanks
[SuperR Kitchen] monx®:
hi. i hv Sony Xperia Z5 DUAL E6683 (firmware v: E6683_32.0.A.6.209_1298-9654_R4B)

Whenever i repack my stock kernel, system boots but seems my network is locked & device asking for 'sim network unlocking pin'. When revert to stock kernel, everything goes to normal. Please advice.
[SuperR Kitchen] bigrammy:
Haahaa that's exactly why I am working on this there are far too many steps with Sony firmware. :eek:

I need help with this cmd

find . | cpio -o -H newc | gzip > 1

which probably works fine in windows but in linux it places a copy of it's self in the archive doubling it's size :mad:

Everything works fine and I can repack the elf with the correct addresses but the ramdisk size is larger due to the extra copy of it's self if that makes sense :silly:

eg: I cpio the contents of ramdisk to "1" then compress "1" to new "1" but I endup with the ramdisk contents in "1" and another gz"1" in the same file so it doubles the size :crying:

Ok just had a Idea :o I will read through some boot.img scripts as they must do the same. :laugh:

Nearly there I hope..

---------- Post added at 02:15 AM ---------- Previous post was at 02:10 AM ----------

How are you repacking the stock kernel :confused:
[SuperR Kitchen] SuperR.:
I just tried the command you posted. I get a file named 1 located inside the unpacked ramdisk dir, and inside that file is a file named 1. This is the correct behavior for that command. It is also consistent with the way the original kernel.elf is packed. I hope I did not misunderstand, sorry if I did :)
[SuperR Kitchen] monx®:
[MENTION=3924647]bigrammy[/MENTION]

1- u can create the output in parent folder

__________ | gzip > ../1

2- too long to elaborate.

[MENTION=5787964]SuperR.[/MENTION]

if im using Windows based kitchen, repacked kernel boots fine w/o sim network lock issue. by using this kitchen, which i feel more comfortable when running it on ubuntu, the kernel is giving me sim network lock problem. please help. i will send link with repacked boot.img on both platforms. both are 100% identical when unpacked w/o any changes.
[SuperR Kitchen] hohassan444:
I will try to upload it to mega.....it will take some time.
[SuperR Kitchen] shoey63:
Don't worry bro. SuperR is a patient man ;)
[SuperR Kitchen] bigrammy:
Your correct bro but the size is wrong it's double packed with the ramdisk contents twice :laugh: see below. ;)

That works bro just one strange thing see line 229 maybe you and Superr and whoever is intrested can see my progress On pastebin Here

They should make him Saint SuperR :angel: :laugh:
[SuperR Kitchen] SuperR.:
The few extra bytes are probably due to a different compression level. Try this command instead when repacking the ramdisk

find . | cpio -o -H newc | gzip -9 > ../1
[SuperR Kitchen] bigrammy:
Yes bro I am not too worried about the extra few bytes but if you see line 229 on pastebin you will see what I mean :o

I would rather keep the compression level as close to the stock as possible just incase the system has problems extracting a higher level. :eek:
[SuperR Kitchen] SuperR.:
I see the reported directory difference and I am not sure where it comes from. However, why not unpack 1~ using cpio by replacing line 68 of your pastebin log with the following:

cd ramdisk
cpio -i < ../1~
[SuperR Kitchen] bigrammy:
Yes that works too :D

bigrammy@bigrammy-Dell-System-Vostro-3750:~/Desktop/elf/ramdisk$ cpio -i < ../1~8861 blocks
bigrammy@bigrammy-Dell-System-Vostro-3750:~/Desktop/elf/ramdisk$ ls
charger file_contexts init.environ.rc init.qcom.sh init.sony.rc init.zygote32.rc sbin sys
crashtag fstab init.qcom.class_core.sh init.qcom.syspart_fixup.sh init.target.rc logo.rle seapp_contexts system
data fstab.qcom init.qcom.early_boot.sh init.rc init.trace.rc proc selinux_version ueventd.qcom.rc
default.prop init init.qcom.rc init.sony-device.rc init.usbmode.sh property_contexts sepolicy ueventd.rc
dev init.class_main.sh init.qcom.rmnet.sh init.sony-platform.rc init.usb.rc res service_contexts
bigrammy@bigrammy-Dell-System-Vostro-3750:~/Desktop/elf/ramdisk$
[SuperR Kitchen] bigrammy:
Just for info :)

Unpacking stock 1~ gives 8861 blocks

Repacking gives 8862 blocks

Unpacking the Repacked 1~ gives 8862 blocks

Then Repacking it again gives 8862 blocks

So it does not keep on growing :good:

Back on shift in the morning so thats all from me for a few days you will be glad to hear. :laugh:
[SuperR Kitchen] SuperR.:
Give this a try if you don't mind. Threw together a script for testing. Copy a kernel.elf into the project directory and run ./bootelf from the terminal. It will unpack the kernel.elf. Run the script again and it will repack it. We need to know if it boots after repacking as well. Let me know how it goes :)

edit: newer version of the kernel.elf test script below
[SuperR Kitchen] bigrammy:
Wow Thanks bro looks good :good:

I wont be able to test it until Sunday :(

I have to go out now then work for Friday and Saturday (15hour shifts with the travel) so I am not fit for anything :laugh:

I swing onto nights Sunday so hope to get time on the swing over. :fingers-crossed:
[SuperR Kitchen] SuperR.:
Need sony testers!!!!!

I made some adjustments to the kernel.elf test script that may add support for many other models that use kernel.elf. Sadly I can't test any of it because I only have the C4 kernel.elf and I don't have a Sony to test with.

Some kernel.elf files have up to 4 files when you unpack (0, 1, 2, 3) compared to the C4 which only has 2 files (0, 1)

0 = zimage

1 = ramdisk

2 = rpm

3 = cert

The script now checks to see if rpm and cert exist and if so do what needs to be done. I have absolutely no experience with Sony devices or kernel.elf so let me know if something is terribly wrong.

Thanks to [MENTION=5245329]Mostafa.Alaa[/MENTION] if this ends up supporting Xperia P/U and others that may include these additional files. I used some of the info from this post :)
[SuperR Kitchen] bigrammy:
Thanks bro I just run a quick test with the older script on my fotakernel.elf (renamed to kernel.elf) and all went smooth :good:

The addresses looked correct too :good:

Just one more problem flashing the .elf :laugh:

bigrammy@bigrammy-Dell-System-Vostro-3750:~/Desktop/superr$ fastboot flash fotakernel fotakernel.elf
target reported max download size of 134217728 bytes
sending 'fotakernel' (12458 KB)...
OKAY [ 0.500s]
writing 'fotakernel'...
FAILED (remote: image is not a boot image)
finished. total time: 0.504s

I will try dd it via adb. :eek:

---------- Post added at 09:55 PM ---------- Previous post was at 09:16 PM ----------

Hi [MENTION=5787964]SuperR.[/MENTION]

Sorry say repacked version Failed to boot :(

Stock one booted fine.

I will do some more work on Sunday :)

I am going to bed now :D
[SuperR Kitchen] Maw2607:
Superrrrrrrrr kitchen on archlinux

Anyone on archlinux who manage to start the kitchen. I try but need some dependencies and i can't find some like on ubuntu.

If someone can give me the terminal command to install the needed dependencies (with yaourt or pacman).

Thanks in advance.

PS: I'm a noob on linux and i don"t know why i try archlinux it take me 2 weeks to make it work on my laptop in dual boot but i think i like it ;)
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

FYI - Chainfire has an updated Beta zip that properly outputs the SuperSU script output to the recovery console. It means that the "Installing SuperSU..." line is no longer necessary if using that zip, as the SuperSU installer output is sufficient for identifying that portion of the install. I do recommend keeping a blank ui_print after the install however, as there is no space at the end of the install.

http://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post64921761#post64921761

I'm not sure if [MENTION=4544860]osm0sis[/MENTION] will be making a similar update to his Busybox installer, but I'll keep my eyes open in case he does ;).
[SuperR Kitchen] osm0sis:
Haha yeah, I will, was just waiting on Chainfire's lead. No surprise, he came up with something far more clever than I could have! I've got a couple more fixes planned to accommodate Cyanogen Recovery removing busybox (so mount commands would fail), stuff like that. Working the next couple days so probably after that. :)
[SuperR Kitchen] SuperR.:
v1.0.1.6

Changes:

Updated SuperSU to BETA 2.67.

Removed Installing SuperSU text from the updater-scripts.
[SuperR Kitchen] Kamy:
[MENTION=5787964]SuperR.[/MENTION]

Thank you for support and update. I successfully tried to extract and then flash a rom using this tool. That's great all could be done quickly and convenient. Though I have difficulty deodexing it. It actually delete all odex files than deodexing it. I am not sure whether there is any settings or other dependency I need to use. Already installed dependencies mentioned in OP though. I am on Note5 TW 5.1.1.
[SuperR Kitchen] SuperR.:
That is strange. I just deodexed the Note 5 SM-N920I 5.1.1 firmware without issue. Are you sure there are no classes.dex files inside the apks?

It should not be a dependency issue if the kitchen runs. It checks for them before allowing you to do anything.
[SuperR Kitchen] Kamy:
Got it thanks for heads up. There is java problem at my side. I tried to deodex again and then I saw the message. Would check and try to solve it.

Edit: it's working now.
[SuperR Kitchen] anandmore:
Only one question

Can I set this up on windows 8.1 64bit because I don't see that you have mentioned it in the post.

Thank you for the help

✌
[SuperR Kitchen] fhem:
Really!!!!!!!!!!!!!! ----> Asked and answered. :cool::good::good:
[SuperR Kitchen] Captain_Throwback:
The thread title clearly says "LINUX" in it.

---------- Post added at 10:11 AM ---------- Previous post was at 10:09 AM ----------

@SuperR.

FYI

http://xdaforums.com/showthread.php?p=64929691

(you won't need the "Installing Busybox" ui_print or the space after it once updating this either :)).
[SuperR Kitchen] Er. Aditya:
when signing zip i got

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:3236)

at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)

at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)

at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)

at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)

at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)

at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:331)

at com.android.signapk.SignApk.copyFiles(SignApk.java:422)

at com.android.signapk.SignApk.main(SignApk.java:490)

and error while signing
[SuperR Kitchen] SuperR.:
v1.0.1.7

Changes:

Updated BusyBox installer by [MENTION=4544860]osm0sis[/MENTION].

Removed Installing Busybox text from the updater-scripts.

Increased java vm heap space to 2048m to hopefully prevent the signing error for sparse_dat and raw_img roms.

NOTE: I am not sure if this will fix the signing error on sparse_dat and raw_img zips. I have also included commented code to disable asking if you want to sign sparse_dat and raw_img roms. We may need to go that way if this release does not fix the issue. It might fix it if you are running 64-bit Linux and have more than 4GB ram. Unfortunately I have not found any better solutions to this problem. It seems as though java vm runs out of memory while creating the signed zip. Any suggestions are welcome :)
[SuperR Kitchen] hohassan444:
this is the link to mega
[SuperR Kitchen] Scott:
[MENTION=5787964]SuperR.[/MENTION] This kitchen is very impressive! Good job!
[SuperR Kitchen] bcrichster:
Why are you removing SuperSu and busy box texts from updater-script?

If I Help, just hit the Thanks button! :cool:

Sent from my Xper!m3nt - ZTE N9515
[SuperR Kitchen] SuperR.:
The new versions of both have been updated to allow their own output to display in the recovery window :)
[SuperR Kitchen] bcrichster:
As in manually typing whatever you want.. or do the flashing process items (SuperSu/busybox) have their own text output generated by themselves?

If I Help, just hit the Thanks button! :cool:

Sent from my Xper!m3nt - ZTE N9515
[SuperR Kitchen] shoey63:
The output of their own respective updater scripts is what will be displayed.
[SuperR Kitchen] SuperR.:
v1.0.1.8

Changes:

Added support for odex*.sqsh extraction when deodexing some Sony roms.

[MENTION=4355438]hohassan444[/MENTION] - Let me know how it goes :)
[SuperR Kitchen] Er. Aditya:
bro same issue again latest kitchen

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:3236)

at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)

at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)

at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)

at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)

at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)

at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:331)

at com.android.signapk.SignApk.copyFiles(SignApk.java:422)

at com.android.signapk.SignApk.main(SignApk.java:490)
[SuperR Kitchen] bcrichster:
Perfect! Good idea, [MENTION=5787964]SuperR.[/MENTION] Hellz Yeah. [emoji41]

If I Help, just hit the Thanks button! :cool:

Sent from my Xper!m3nt - ZTE N9515
[SuperR Kitchen] SuperR.:
I will disable zip signing for sparse_dat and raw_img in the next release unless someone can help figure out how to make it work.

This was not my idea actually. [MENTION=1162986]Captain_Throwback[/MENTION] brought it to my attention that [MENTION=631273]Chainfire[/MENTION] and [MENTION=4544860]osm0sis[/MENTION] updated their zips to enable their own output when flashed from inside a rom zip. Thanks to all of them :)
[SuperR Kitchen] Er. Aditya:
Actually that happened to me on meta data as well...if i remember correctly from couple of days back bro
[SuperR Kitchen] hohassan444:
Works as it should...impressive work!.
[SuperR Kitchen] fhem:
Welcome aboard!!! Glad you are giving this great kitchen a try.
[SuperR Kitchen] SuperR.:
v1.0.1.9

Changes:

Increased java heap size to 3072m for signapk.jar.

Added a check for odex.sqsh when determining deodex status.

NOTE: This seems to have fixed the signing issue for me. The problem is that java runs out of memory while trying to sign the zip. The larger the zip the more memory required. I watched the java process and it used around 2.6GB of ram while signing an 881.7MB zip. If the rom zip is much larger it may still give you an error.
[SuperR Kitchen] Er. Aditya:
so bro what about zips larger then that ?? or is it ok without signing ??
[SuperR Kitchen] SuperR.:
Zips do not "need" to be signed. Signing helps to be sure nothing is corrupt in the zip when flashing. Every file inside the rom is checked against the original. This is not required but is generally preferred. The java heap size can be raised more but some people only have a total of 4GB of ram. You will need to try larger zips to see how it goes. It may be fine the way it is.
[SuperR Kitchen] Er. Aditya:
il skip the signing i guess but even now

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space

at java.util.Arrays.copyOf(Arrays.java:3236)

at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:118)

at java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93)

at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:153)

at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)

at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)

at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:331)

at com.android.signapk.SignApk.copyFiles(SignApk.java:422)

at com.android.signapk.SignApk.main(SignApk.java:490)
[SuperR Kitchen] SuperR.:
You can try changing the heap size. On line 5569 In the superr file in the main kitchen directory, change the following:

java -Xmx3072m

To:

java -Xmx4096m

If that does not work, try raising it more. Let me know what number ends up working for you.

Out of curiosity, how big is the zip you are trying to sign? How much ram do you have? Are you on 32 or 64-bit Linux?
[SuperR Kitchen] Er. Aditya:
il try and let you know bro

i am using note 4 3 gb ram and 64 bit linux and zip is 1.2 gb the strange thing is i also get same signing errors with meta data

just signed a 800 mb rom perfectly brother , also this is my first time for sparse format cant that be edited after final zip up ?? like if i want to replace files in app or priv-app
[SuperR Kitchen] shoey63:
How much ram does your 64 bit Linux have (or how much have you allocated if using a VM)?
[SuperR Kitchen] Er. Aditya:
8gb sir i am not using vm
[SuperR Kitchen] shoey63:
Thanks. Should be more than enough. I'll try on my 16 GB ram linux x64 machine, and see how that goes.