Related
Hi all, i m new here,
I have been reading this forum and couldnt find thread on how to flash/install Android OS on Windows Mobile 6.1 Professional for Micromax w900.
I have newly purchased a phone "MICROMAX W900" which comes with Windows Mobile 6.1 Professional OS and i m looking to install Android/Maemo OS on it.
So its my request to u all, please point me to it.
Features:
2.0 mega pixel CMOS camera
Windows Mobile 6.1
Pocket MSN
Windows Media Player
Bluetooth
ActiveSync
T-Flash card compatible (Micro SD upto 16 gb)
Touch screen with handwriting recognition
3.2-inch 65K color display
E-mail
Wi-Fi
GPS with integrated MAPS
FM Radio
Here is the Technical specification of phone.
Windows Mobile 6.1 Professional
CE OS 5.2.21041(BUILD 21041.1.6.0)
Processor: Hisilicon-K3
Memory: 81 MB
Expansion slot: In use
Device Info:
ROM VERSION : 01.001.18 IND
ROM DATE: 1/19/2010
RADIO VERSION: 1.07.9324
PROTOCOL VERSION: DV3.0
HARDWARE
CPU: Hisilicon-K3
speed: 460 Mhz
Ram size: 128 MB
Flash size: 256 MB
Data Bus: 32 bit
Storage size: 157.20 MB
Display Resolution: 240x400
Colors: 262144
Identify
Model No: NEXPERIA SY.SOL 5209
Platform: Pocket PC
Thanks for ur time,
Anyways i m happy to provide any more details of the phone, if needed.
Thanks .
just found
hi,
i just found out this.
press & hold
1) volume down + camera key + power key = Factory reset/clean boot
2) Volume up + volume down + power key = Some flashing utility
it gives me this
Checking valid image file
Step 3 error while updating
Card operate : Read retry timeout.
what to do next ?
c'mon guys please help me.
i m really tired of windows mobile os,
Latest update,
I guess i m very closer to find bootloader mode of the phone.
whenever i remove battery and plug USB, windows logo comes and goes and my XP says device not recognized and nothing happens at phone, no 3 stripes of bootloader.
Hello Dear
I am new here. I want to modify my current ROM on Micromax W900. I have surfed and got some info on Updating the ROM. But it says 'Download the ROM for your Device'. I just want to know that from where should I download the ROM for this device.
Thanks in advance...
Regards,
~alliwant
alliwant said:
Hello Dear
I am new here. I want to modify my current ROM on Micromax W900. I have surfed and got some info on Updating the ROM. But it says 'Download the ROM for your Device'. I just want to know that from where should I download the ROM for this device.
Thanks in advance...
Regards,
~alliwant
Click to expand...
Click to collapse
i m still trying to figure that out, but no luck.
i also contacted micromax for giving me technical datasheets of w900, but they said its matter of company protocol issue, IDK what does it means.
anyways, keep trying R n D
TCPMP crash report
i installed tcpmp and while starting it, it gave me crash.txt,
i think here is some useful info. of phone.
Access violation(c0000005) at 784549ec 784549ec)
Read from 784549ec
cpu dump:
R0 = 65bd6f9f
R1 = 00000000
R2 = 65bd6f9f
R3 = ffffcbac
R4 = 01a902d0
R5 = 00012000
R6 = 00012010
R7 = 00000003
R8 = 2595fed8
R9 = 2595fed8
R10 = 784026a8 (common:000016a8)
R11 = 2595fd04
R12 = 65bd6f9f
Sp = 2595fcd8
Lr = 78402798 (common:00001798)
Pc = 784549ec
Psr = 60000010
stack dump:
2595fcd8 783d3f20
2595fcdc 0001318c
2595fce0 2595fed8
2595fce4 86007150
2595fce8 c56d8fd2
2595fcec 783d3f48
2595fcf0 00000000
2595fcf4 66c2252e
2595fcf8 ffffc894
2595fcfc 2595fd04
2595fd00 00011108
2595fd04 00000000
2595fd08 00000000
2595fd0c 87f7b888
2595fd10 00000000
2595fd14 00011424
2595fd18 01ffcc94
2595fd1c 01ffc9e0
2595fd20 2595fed8
2595fd24 66c2252e
2595fd28 ffffc894
2595fd2c 81b05fb8
2595fd30 00000047
2595fd34 66c2252e
2595fd38 00000000
2595fd3c 2595fed8
2595fd40 00000005
2595fd44 87f7b888
2595fd48 00000000
2595fd4c 00011424
2595fd50 01ffcc94
2595fd54 01ffc9e0
2595fd58 2595fed8
2595fd5c 66c2252e
2595fd60 ffffc894
2595fd64 03f66a64
2595fd68 2595fe44
2595fd6c 03f67274
2595fd70 00011424
2595fd74 80000010
2595fd78 2595fdd4
2595fd7c 7c08f544
2595fd80 2595fdac
2595fd84 7c08f544
2595fd88 0000c31b
2595fd8c 03f6bbcc
2595fd90 ffffc894
2595fd94 00000000
2595fd98 0db6af68
2595fd9c 0da90000
2595fda0 0db40000
2595fda4 00000014
2595fda8 86e67de0
2595fdac 00000000
2595fdb0 00000000
2595fdb4 86042940
2595fdb8 81e06d10
2595fdbc 860b6680
2595fdc0 86e67de0
2595fdc4 00000000
2595fdc8 f000fe38
2595fdcc 2595fe10
2595fdd0 81b08744
2595fdd4 00000000
2595fdd8 00004000
2595fddc 00000010
2595fde0 ffffcb48
2595fde4 ffffc894
2595fde8 00000001
2595fdec 81b08c20
2595fdf0 00004000
2595fdf4 00000010
2595fdf8 ffffcb48
2595fdfc 65bd6f9e
2595fe00 66c2252e
2595fe04 00000001
2595fe08 81b05828
2595fe0c 03f66a64
2595fe10 00000000
2595fe14 00000010
2595fe18 66c2252e
2595fe1c 00000000
2595fe20 2595fed8
2595fe24 00000005
2595fe28 01ffc9e0
2595fe2c 00011450
2595fe30 87f7b888
2595fe34 00000000
2595fe38 00011424
2595fe3c 01ffcc94
2595fe40 03f67274
2595fe44 00010000
2595fe48 00000000
2595fe4c 00000000
2595fe50 00000000
2595fe54 00000000
2595fe58 00000001
2595fe5c 00000000
2595fe60 00000000
2595fe64 00000000
2595fe68 00000000
2595fe6c 00000000
2595fe70 00000000
2595fe74 00000000
2595fe78 00000000
2595fe7c 00000000
2595fe80 00000000
2595fe84 00000000
2595fe88 00000000
2595fe8c 00000000
2595fe90 f000fe3c
2595fe94 c203fe7c
2595fe98 81b2819c
2595fe9c 81b2820c
2595fea0 00000000
2595fea4 80000004
2595fea8 00000001
2595feac 00000004
2595feb0 87f7b888
2595feb4 00000000
2595feb8 00000000
2595febc 00010000
2595fec0 006c0070
2595fec4 00790061
2595fec8 00720065
2595fecc 0065002e
2595fed0 00650078
2595fed4 00000000
2595fed8 00000000
2595fedc 00000000
2595fee0 00000000
2595fee4 24000000
2595fee8 00000002
2595feec 00000000
2595fef0 00020000
2595fef4 00000000
2595fef8 2595d000
2595fefc 25940000
2595ff00 7c08f580
2595ff04 2595fe50
2595ff08 00000000
2595ff0c 00000000
2595ff10 00000000
2595ff14 01a919e0
2595ff18 00000000
2595ff1c 00000000
2595ff20 00000000
2595ff24 00000000
2595ff28 00000000
2595ff2c 00000000
2595ff30 00000000
2595ff34 00000000
2595ff38 00000000
2595ff3c 00000000
2595ff40 00000000
2595ff44 00000000
2595ff48 00000000
2595ff4c 00000000
2595ff50 00000000
2595ff54 00000000
2595ff58 00000000
2595ff5c 00000000
2595ff60 00000000
2595ff64 00000000
2595ff68 00000000
2595ff6c 00000000
2595ff70 00000000
2595ff74 00000000
2595ff78 00000000
2595ff7c 00000000
2595ff80 00000000
2595ff84 00000000
2595ff88 00000000
2595ff8c 00000000
2595ff90 00000000
2595ff94 00000000
2595ff98 00000000
2595ff9c 00000000
2595ffa0 00000000
2595ffa4 00000000
2595ffa8 00000000
2595ffac 00000000
2595ffb0 00000000
2595ffb4 00000000
2595ffb8 00000000
2595ffbc 00000000
2595ffc0 00000000
2595ffc4 00000000
2595ffc8 00000000
2595ffcc 00000000
2595ffd0 00000000
2595ffd4 00000000
2595ffd8 00000000
2595ffdc 00000000
2595ffe0 00000000
2595ffe4 00000000
2595ffe8 00000000
2595ffec 00000000
2595fff0 00000000
2595fff4 00000000
2595fff8 00000000
2595fffc 00000000
25960000 ????????
25960004 ????????
25960008 ????????
2596000c ????????
25960010 ????????
25960014 ????????
25960018 ????????
2596001c ????????
25960020 ????????
25960024 ????????
25960028 ????????
2596002c ????????
25960030 ????????
25960034 ????????
25960038 ????????
2596003c ????????
25960040 ????????
25960044 ????????
25960048 ????????
2596004c ????????
25960050 ????????
25960054 ????????
25960058 ????????
2596005c ????????
25960060 ????????
25960064 ????????
25960068 ????????
2596006c ????????
25960070 ????????
25960074 ????????
25960078 ????????
2596007c ????????
25960080 ????????
25960084 ????????
25960088 ????????
2596008c ????????
25960090 ????????
25960094 ????????
25960098 ????????
2596009c ????????
259600a0 ????????
259600a4 ????????
259600a8 ????????
259600ac ????????
259600b0 ????????
259600b4 ????????
259600b8 ????????
259600bc ????????
259600c0 ????????
259600c4 ????????
259600c8 ????????
259600cc ????????
259600d0 ????????
259600d4 ????????
common 78401000-7844c000 obj:0 class:30
General (0x01a917a0)
Language(16)=1600081477
Platform(23)=PocketPC
Ver(25)=502
OS Version(27)=5.02
OEM Info(24)=Hisilicon
TypeNo(26)=1
Model(18)=0
Caps(19)=0x00008001
Processor(17)=ARM 926E
Clock speed(34)=400
ICache(20)=16384
DCache(21)=16384
(37)=10
(38)=0
Advanced (0x01a91ac0)
No backlight keepalive for video(32)=No
Home Screen time out with music playback(45)=No
Old style toolbars(31)=No
No wireless MMX usage(40)=No
Slow video memory(37)=No
Less rotation tearing (slower)(41)=No
Prefer lookup tables over arithmetic(38)=Yes
D-Pad follow screen orientation(56)=Yes
Prefer less buffering over smooth video(54)=No
Use system volume(52)=No
Benchmark from current position(48)=No
Override AVI frame rate based on audio(53)=No
Widcomm BT Audio button support(58)=No
Disable AVC deblocking filter(65)=No
Manual A/V offset +/-(44)=0.00 ms
Soft-drop tolerance(42)=54.99 ms
Hard-drop tolerance(43)=699.95 ms
(59)=No
System Timer (0x01a91e10)
Time(96)=0
Speed(98)=100.00%
Play(99)=No
Wave Output (0x01a91fc0)
Input(32):IN=empty packet format
Input(32):IN=NULL
Output(33):OUT=empty packet format
Total(34)=0
Dropped(35)=0
Volume(81)=100
Mute(82)=No
(89)=0
Quality(83)=2
(90)=No
(91)= (0x01a91fd0)
NULA AOUT p:1 r:1 c: e: p: m:common
OVLA VOUT p:1 r:1 c: e: p: m:common
RAWA FMTB p:1 r:1 c: e: p: m:common
FMTB FMT_ p:1 r:1 c: e: p: m:common
CODC FLOW p:1 r:1 c: e: p: m:common
CCID FLOW p:1 r:1 c: e: p: m:common
NODE p:0 r:1 c: e: p: m:common
FILE STRM p:1 r:1 c:file e: p: m:common
WAVE AOUT p:1 r:1 c: e: p: m:common
RAWI FMTB p:1 r:1 c: e: p: m:common
FMTL FMTM p:1 r:1 c: e: p: m:common
STRM NODE p:1 r:1 c: e: p: m:common
FMTM NODE p:1 r:1 c: e: p: m:common
ADMO CODC p:1 r:1 c: e: p: m:common
STRP FMTM p:1 r:1 c: e: p: m:common
OUTP FLOW p:1 r:1 c: e: p: m:common
ADVP NODE p:1 r:1 c: e: p: m:common
TIMR NODE p:1 r:1 c: e: p: m:common
MEMS STRM p:1 r:1 c: e: p: m:common
PLAT NODE p:1 r:1 c: e: p: m:common
IDCT FLOW p:1 r:1 c: e: p: m:common
SYST TIMR p:1 r:1 c: e: p: m:common
AOUT OUTP p:1 r:1 c: e: p: m:common
VOUT OUTP p:1 r:1 c: e: p: m:common
NULV VOUT p:1 r:1 c: e: p: m:common
FLOW NODE p:1 r:1 c: e: p: m:common
RASX FMTL p:1 r:1 c:
e:asx;wmx;wmweb;wmwebasf;wmwebasx;wvx:V;wax:A
p:and(text,scan(64,stri('<ASX'),0,fwd)) m:common
PLS_ FMTL p:1 r:1 c:audio/x-scpls,audio/scpls els
p:and(text,scan(64,stri('[playlist]'),0,fwd)) m:common
FMT_ FMTM p:1 r:1 c: e: p: m:common
M3U_ FMTL p:1 r:1 c:audio/x-mpegurl,audio/mpegurl e:m3u
p:and(text,gt(512,length),or(eq(lines,1),eq(lines,0))) m:common
This is an Update:
I'm able to successfully extract all the 'dump' files including (Part00.raw, Part01.raw, Part02.raw) and also the '.bin' files from my Micromax using the proper utilities like 'itsutils'. I even successfully converted these files to appropriate 'OS.nb' file. But still i am suffering with some issues and can't able to integrate WM 6.5!
Moreover i think we have to copy the files necessary for Update (.nbk etc.) to the SD Card so that when we enter the Flashing Utility (i.e. Volume Down + Volume Up + Reset) it can automatically update the ROM.
If anyone need help in this beginning procedure please POST a Request here and if anyone would like to help me out for the further procedure please POST a Reply.
Thanks
alliwant said:
This is an Update:
I'm able to successfully extract all the 'dump' files including (Part00.raw, Part01.raw, Part02.raw) and also the '.bin' files from my Micromax using the proper utilities like 'itsutils'. I even successfully converted these files to appropriate 'OS.nb' file. But still i am suffering with some issues and can't able to integrate WM 6.5!
Moreover i think we have to copy the files necessary for Update (.nbk etc.) to the SD Card so that when we enter the Flashing Utility (i.e. Volume Down + Volume Up + Reset) it can automatically update the ROM.
If anyone need help in this beginning procedure please POST a Request here and if anyone would like to help me out for the further procedure please POST a Reply.
Thanks
Click to expand...
Click to collapse
i love u man, u did it.,
if u can copy firmware then, u can upgrade it too., i guess so.
i still couldnt find the key combinations to start bootloader,
I m dying to install any linux distro on it.(maemo/android/dsl)
yes, I would be grateful if u post the method how to do it.
and also i would like to help u by doing experiments on my phone, though i dont know much about it., coz i think i have ****ed my phone already,
it normally doesnt wakes up from sleep mode when battery is less than 40 %.
i also did some reg, changes.
so i m gonna send it to company for sw fix.
and about that, windows 6.5 install, i guess u r right, u have to put files on memory card and boot it in that menu. it will auto upgrade phone.
Thanks a lot. for ur help.
Hello Dear
Well thanks for your Reply. According to me Volume Up + Volume Down + Power is the Bootloader but it automatically skips to Setp:2 or Step:3 and asks for an Update rather than showing the Tri-Color Boot Screen. I think there might be a registry fix or so to fix this problem.
And for extracting the dump follow the Hermes Guide.
Link:
===
wiki.xda-developers.com/index.php?pagename=Hermes_HowtoDumpRom
If you still face any problem feel free to contact me!
Regards,
~alliwant
wooo hooooo...... am so excited!!!
this finally brings a ray of hope for all W900 users to be able to upgrade their ROMs. Awesome work guys......
yup, my fone does the same. skips straight to
Step 3 Error while updating:
File operate : File does not exist.
Restart the machine?
The only option to select is YES.
Can we ever get WM6.5 or Android or WM7 on this phone??
Well the only problem is to how to Flash the cooked ROM? We don't know the file name and format to be stored in the SD Card so that it automatically Updates when we enter into the Flashing Utility by pressing Volume Up + Volume Down + Reset!
can any of you give a short review of this device. I am thinking of buying this.
How is the performance with stock ROM and especially during navigation ?
Upgrade success to wm6.5
Phew ok guys have successfully upgraded to wm6.5 finally after a long research...
hmmmm so guys now the issue is am stuck with wm6.5 chinese looking to cook a an english rom for the micromax w900. any help to cook will be appreaciated. i tried to cook my own rom from the dumps of the phone but it kind of bricked my phone but was kind of lucky as only the flash area was overwritten.
oh guys one more try to upgrade only if you r really frustrated with the wm6.1. the rom which they had given is far more stable and looks good with spb software.
wm6.5 is fast on micromax.haven't checked much of the software's in wm6.5 as am researching on cooking with english. will give a detailed explanation on how to flash and dump later.on to chinese fix hehe
oh yeah just keep your heads up to get a new phone if it gets bricked
alliwant: alliwant i had done the update with a new rom not with my raw files.. could you give a heads up on how you did it... i got the the os.nb files after using the ruu_signed_rom.nbh and also placing the files part01 and 02 in the same directory..let me know if its a new procedure..
thanks,
Update on micrmx w900
alliwant said:
Well the only problem is to how to Flash the cooked ROM? We don't know the file name and format to be stored in the SD Card so that it automatically Updates when we enter into the Flashing Utility by pressing Volume Up + Volume Down + Reset!
Click to expand...
Click to collapse
alliwant i had done the update with a new rom not with my raw files.. could you give a heads up on how you did it... i got the the os.nb files after using the ruu_signed_rom.nbh and also placing the files part01 and 02 in the same directory..let me know if its a new procedure..
Update: ok never mind.. i did a new rom but with part of my raw files ..it was chinese changed it to english but the rom has minor bugs...anyway thinking to port a wm6.5 rom now ...
Hey i have a micromax w900 and tired with the old OS 6.1. Was desperately looking for an upgrade to 6.5. But im a n00b related to flashing and stuff. How safe is upgrading? Bricking the phone means it can never be recovered to working state? Even by Micromax service center??
If you do create a ROM please share it with us so that all W900 users can benefit from it.
Thanks.
[email protected] said:
Hey i have a micromax w900 and tired with the old OS 6.1. Was desperately looking for an upgrade to 6.5. But im a n00b related to flashing and stuff. How safe is upgrading? Bricking the phone means it can never be recovered to working state? Even by Micromax service center??
If you do create a ROM please share it with us so that all W900 users can benefit from it.
Thanks.
Click to expand...
Click to collapse
sharan.blore: have a look at my post at this thread..
http://forum.xda-developers.com/showthread.php?p=7350563&posted=1#post7350563
i have cooked only 6.1 successfully..i will post it once i get some time in the office
it can not be recovered by you..though service center could replace the logic board on the phone so no issues if you have the warranty intact..
Hi Guys, Great work... so far so Good... As a W900 user with 6.1 let me tell you that this phone serves no purpose.
Reason is .... will not sync with Systems running Windows 7.
I demanded an upgrade to win 6.5 at the service center, where they after making various calls advised me not to,,, compatibility issues with the screen... Goes blank they say.
Your inputs would be much appreciated & do keep up the great work.
P.s, has there been any hardware mods in the phone ?
try this
Micromax w900 phone To enter Factory reset menu
just follow the steps....
press & hold volume down + camera + power i get factory reset option on screen
then just press volume UP to confirm..
then all is done ur set is ok now
if u like my post just press thanks button
Hi,
I am working on un-bricking my Optimus One (P500) via JTAG, and I need some additional information.
Here is what I did so far:
- created an LPT to JTAG adapter, called the wiggler
- soldered wires to the JTAG pins on the phone's board as shown here
- downloaded openOCD 0.5 and used this configuration file for the wiggler adapter
- started the giveio driver that is in the drivers/ directory of openOCD
- ran the command "openocd --f wiggler.config.file.cfg" and got the following output:
Code:
Open On-Chip Debugger 0.5.0 (2011-08-09-23:21)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'parport' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
parport port = 0x378
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
dcc downloads are enabled
fast memory access is enabled
6000 kHz
Info : clock speed 500 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: arm9.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 0
Error: unknown EmbeddedICE version (comms ctrl: 0x00000000)
Info : arm9: hardware has 2 breakpoint/watchpoint units
- ran "telnet localhost 4444" and tried issuing debugging commands via jtag
In general I was following the steps described in this wiki. What I saw is that they have certain binary files for their phone which I wasn't able to find for Optimus:
- the IPL and SPL bootolader image files (hboot.img)
- radio image files (radio.img)
- full recovery images
Does anyone know where can we get the same files for Optimus phones? I imagine they can be read off a working phone. Anyone knows how to do this?
Additionally, was anyone able to configure openOCD to work with the MSM7227 chip in this phone? I can't seem to get it to detect the ARM cpu inside it.
Finally, here are some photos of my LPT <-> wiggler <-> JTAG setup.
Suggestions, help, pats on the back appreciated.
Nice! I haven't seen much in the way of hardware work on our phones. I'd be interested in any progress that you make on this. I wish that I could offer more than the pat on the back, but my experience with JTAG is minimal. In any case, good luck!
Sent from my LG-P500 using XDA App
Forgive for my English... I have connected phone to jtag as me to fill in bootloader?
photo my connected i.imgur.com/vUdUV.jpg
myk777 said:
Forgive for my English... I have connected phone to jtag as me to fill in bootloader?
photo my connected i.imgur.com/vUdUV.jpg
Click to expand...
Click to collapse
my openocd.cfg
---------------------------------------------------
interface parport
parport_port 0x378
parport_cable wiggler
jtag_khz 6000
reset_config trst_and_srst srst_pulls_trst
#dream information (or something near it)
set _CHIPNAME lolololo
set _ENDIAN little
set _CPUTAPID 0x12345678
jtag newtap lololo cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
------------------------------------------------------------
some updates
In this message I will try to summarize what we have so far...
[1]
myk777 was able to establish an LTP <-> JTAG connection via the wiggler. Here are the connections he made:
i.imgur.com/vUdUV.jpg
[2]
He also identified the to be ARM1136 with the tap ID 0x203c00e1.
OpenOCD 5.0 contains the configuration file for ARM1136 in the following location:
openocd-0.5.0/target/imx31.cfg
The full documentation for ARM1136 is available here:
google DDI0211K_arm1136_r1p5_trm.pdf
What remains to be done:
A. Configure openocd to use the wiggler and the imx31 to target the ARM1136 chip
B. Try to execute the initial bootloader code (using openocd debugger)
C. Find the binary dumps of the bootloader code for this phone, and try to rewrite it
For A I have the following suggestion:
- set the CPUTAPID=0x203c00e1
- launch openocd with something like this:
openocd -f wiggler.config.file.cfg -f target/imx31.cfg
Has failed flash memory. Has given on repair to service.
Hi guys!
This thread is the closest to my problem with Samsung Galaxy Mini S5570 model. I was on forum with this phone but there I couldn't find any "deeper" thread (most of them ends with "use RiffBox").
So, I have built Clone Wiggler, solder down wires to the JTAG pads and establish connection with bricked phone. Here is what I got from the OpenOCD after start:
Code:
Warn : Adapter driver 'parport' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: MSM7227.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
Warn : gdb services need one or more targets defined
Here is OpenOCD config file:
Code:
interface parport
parport_cable wiggler
adapter_khz 500
#debug_level 3
# CPU settings
set _CHIPNAME MSM7227
set _CPUTAPID 0x203c10e1
#set _ENDIAN little
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
And output from "jtag init" and "scan_chain" after telnet localhost 4444:
Code:
telnet localhost 4444
> jtag init
JTAG tap: MSM7227.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
> scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
0 MSM7227.cpu Y 0x203c10e1 0x203c10e1 4 0x01 0x0f
S5570 has MSM7227 Qualcomm chip and 4Gb OneNand KAT007012C - BRTT flash. I'm aware that there is no luck with OneNAND and OpenOCD, but I still have the hope and strong will
My OpenOCD version is latest 0.6.1
Any reply is more than welcome and thanks in advance.
I have read that MSM7227 has several cores that operate separately. One core is arm9 (modem processor) and the second is arm11 (applications) ... so configuration file is changed and with this OpenOCD config, JTAG is connected to the arm9 modem processor:
Code:
interface parport
parport_cable wiggler
adapter_khz 300
reset_config trst_and_srst srst_pulls_trst
#debug_level 3
# CPU settings
set _CPUTAPID 0x203c10e1
set _TARGETNAME arm9.cpu
set _ENDIAN little
# create jtag
jtag newtap arm9 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
# create target
target create arm9 arm926ejs -endian $_ENDIAN -chain-position $_TARGETNAME
Here is output from the OpenOCD:
Code:
Open On-Chip Debugger 0.6.1 (2012-11-04-19:22)
Licensed under GNU GPL v2
For bug reports, read
Warn : Adapter driver 'parport' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 300 kHz
trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain
arm9
Info : clock speed 250 kHz
Info : JTAG tap: arm9.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
Info : Embedded ICE version 6
Info : arm9: hardware has 2 breakpoint/watchpoint units
After power is attached to the phone I have to press few times power button (not sure about that - screen just flashes) and then press Power + Volume down + Home buttons. Screen is still black but the phone is nicely recognized by the OpenOCD. The next step is "telnet localhost 4444". Every few seconds GDB was printing some lines so I typed in "reset" and "halt". Here are few commands to show the output:
Code:
> halt
Jazelle debug entry -- BROKEN!
invalid mode value encountered 0
ThumbEE -- incomplete support
cpsr contains invalid mode value - communication failure
Polling target failed, GDB will be halted. Polling again in 100ms
target was in unknown state when halt was requested
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x200000d7 pc: 0x003679e0
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Polling succeeded again
> arm9 curstate
halted
> arm9 mdb 2000 100
0x000007d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000007e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x000007f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00000800 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 ................
0x00000810 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 ................
0x00000820 02 00 00 ea 18 28 6f 01 00 00 00 00 3c 45 26 00 .....(o.....<E&.
0x00000830 01 70 a0 e1
> arm reg
System and User mode registers
r0: fffffffb r1: 002fff30 r2: 00000f80 r3: 000000ff
r4: ffffff00 r5: 000000ff r6: 003788cc r7: 0038fabc
r8: 00390320 r9: 00000000 r10: 002fffb0 r11: 00000040
r12: 00390320 sp_usr: ffffffe0 lr_usr: e1a0a002 pc: 003679e0
cpsr: 200000d7
FIQ mode shadow registers
r8_fiq: 000000db r9_fiq: 15c43000 r10_fiq: 00000070 r11_fiq: 00000000
r12_fiq: ffff000c sp_fiq: 00000000 lr_fiq: f000b4bc spsr_fiq: 00000010
Supervisor mode shadow registers
sp_svc: 00000000 lr_svc: 00017118 spsr_svc: 000000d7
Abort mode shadow registers
sp_abt: 002fff1c lr_abt: 0046c140 spsr_abt: 000000d3
IRQ mode shadow registers
sp_irq: 40000030 lr_irq: 009ee8dd spsr_irq: 00000010
Undefined instruction mode shadow registers
sp_und: fffffffc lr_und: ffff0008 spsr_und: 000000db
Well, I hope that Clone wiggler actually communicate with my hard bricked phone. What is the next step and how to unbrick the phone? Please guys give me some hint to move on because I can barely find any quality info about unbricking procedure for S5570. I'm stuck at this point.
In theory bootloader should be loaded to the memory and then written to the NAND (actually OpenNAND). Or is it possible to load a program and run it from OpenOCD to enable communication with Odin?
Thanks in advance and any feedback is more than welcome.
dbunic said:
Hi guys!
This thread is the closest to my problem with Samsung Galaxy Mini S5570 model. I was on forum with this phone but there I couldn't find any "deeper" thread (most of them ends with "use RiffBox").
So, I have built Clone Wiggler, solder down wires to the JTAG pads and establish connection with bricked phone. Here is what I got from the OpenOCD after start:
Code:
Warn : Adapter driver 'parport' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: MSM7227.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
Warn : gdb services need one or more targets defined
Here is OpenOCD config file:
Code:
interface parport
parport_cable wiggler
adapter_khz 500
#debug_level 3
# CPU settings
set _CHIPNAME MSM7227
set _CPUTAPID 0x203c10e1
#set _ENDIAN little
jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID
And output from "jtag init" and "scan_chain" after telnet localhost 4444:
Code:
telnet localhost 4444
> jtag init
JTAG tap: MSM7227.cpu tap/device found: 0x203c10e1 (mfg: 0x070, part: 0x03c1, ver: 0x2)
> scan_chain
TapName Enabled IdCode Expected IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
0 MSM7227.cpu Y 0x203c10e1 0x203c10e1 4 0x01 0x0f
S5570 has MSM7227 Qualcomm chip and 4Gb OneNand KAT007012C - BRTT flash. I'm aware that there is no luck with OneNAND and OpenOCD, but I still have the hope and strong will
My OpenOCD version is latest 0.6.1
Any reply is more than welcome and thanks in advance.
Click to expand...
Click to collapse
Hello there!
Do you finished with succes?I am planning to try recover same phone but with h-jtag.
Any help welcome
szakiz said:
Hello there!
Do you finished with succes?I am planning to try recover same phone but with h-jtag.
Any help welcome
Click to expand...
Click to collapse
Unfortunately no, phone was fixed with riffbox. Thread was inactive for a while and I didn't have success with inspecting/fixing boot loader via Jtag interface. Hope you will have more luck. Cheers!
Xperia J: fast+snappy stock kernel JB (11.2.A.0.21)
The following guide shows how to build the stock sources for you
stock xperia j phone with JB.
When Foxcon adopted the drivers for the xperia j they left in
a huge amount of debug which slows down your phone.
When we finally build our own kernel (Chapter 7)
we optimize it by:
- optimizing kernel for speed (not size)
- remove a huge amount of debug from the drivers
- remove kernel core debug
- remove debug_fs
- build without module support
In my opinion the kernel feels much more snappier afterwards.
The system reacts much more fluent on user inputs and sound
has less hangs than before.
Let me hear how it feels for you and if you like it or not
Maybe you have further modifications. So please post it here.
The last section describes how you can build your own kernel patch files.
0. Prerequisites
1. Extracting the current boot image
2. Splitting the image into kernel, ramdisk and cmdline
3. Unpack the ramdisk
4. Build the sony kernel with the original kernel configuration (.config)
5. Build a new boot image
6. Flash the new boot image to the phone
7. Now for the FUN part: TUNE the sony kernel with the attached patch-file
A: Howto build a patch file by comparing a
fresh extracted kernel sources with your edited sources:
0. Prerequisites
==================
- Device needs to be rooted and bootloader unlocked !!!
- Device needs to be up to date with latest Jelly Bean release 11.2.A.0.21 !!!
- A linux machine as working environment
- free ARM compiler, lite version, EABI, URL:
sourcery.mentor.com/sgpp/lite/arm/portal/release2322
- latest Xperia Jlo sources, URL:
developer.sonymobile.com/downloads/xperia-open-source-archives/open-source-archive-for-build-11-2-a-0-21/
- phyton script 'mkelf.py' to re-/build parition image, URL:
dl-developer.sonymobile.com/tools/image_generation_script_for_Xperia_smartphones.zip
- another basic guide, URL:
developer.sonymobile.com/2011/05/06/how-to-build-a-linux-kernel
1. Extracting the current boot image
======================================
- Install Andrdoid SDK.
- Then add a path to your .bashrc file of your linux host:
linux-w49x:~/my_kernel # echo "export PATH=/root/adt-bundle-linux-x86-20130219/sdk/platform-tools:$PATH" >> ~/.bashrc
linux-w49x:~/my_kernel # . ~/.bashrc
- Enable "USB-Debugging" in the phone seetings
- Start the phone and connect via USB to your linux machine
- At first we copy the sony boot image to the sdcard of the device:
linux-w49x:~ # adb shell
[email protected]:/ $ su
[email protected]:/ # dd if=/dev/block/mmcblk0p3 of=/sdcard/sony_boot.img
40960+0 records in
40960+0 records out
20971520 bytes transferred in 2.078 secs (10092165 bytes/sec)
- Read kernel config of your current kernel and store it on sdcard, too:
[email protected]:/ $ su
[email protected]:/ # cat /proc/config.gz > /sdcard/sony_config.gz
130|[email protected]:/ $ exit
130|[email protected]:/ $ exit
- Transfer both to your linux PC:
linux-w49x:~ # adb pull /sdcard/sony_boot.img
linux-w49x:~ # adb pull /sdcard/sony_config.gz
2. Splitting the image into kernel, ramdisk and cmdline
========================================================
- Basically the image consists of:
* 4k singed sin header with a ?x509? certificate
* kernel
* ramdisk
* cmdline parameters for the kernel
* a lot of empty space (~15 MB)
- Hexdump the image to make it human readable:
linux-w49x:~ # hexdump -C sony_boot.img > dump
linux-w49x:~ # head dump
00000000 7f 45 4c 46 01 01 01 61 00 00 00 00 00 00 00 00 |.ELF...a........|
00000010 02 00 28 00 01 00 00 00 00 80 20 00 34 00 00 00 |..(....... .4...|
00000020 00 00 00 00 00 00 00 00 34 00 20 00 03 00 00 00 |........4. .....|
00000030 00 00 00 00 01 00 00 00 00 10 00 00 00 80 20 00 |.............. .| <== Byte 9/10/11: is kernel start (after 4k sin header)
00000040 00 80 20 00 68 70 3c 00 68 70 3c 00 00 00 00 00 |.. .hp<.hp<.....| <== Byte 9/10/11: is kernel length
00000050 00 00 00 00 01 00 00 00 68 80 3c 00 00 00 40 01 |........h.<[email protected]| <== Byte 9/10/11: is ramdisk start
00000060 00 00 40 01 c6 1b 15 00 c6 1b 15 00 00 00 00 80 |[email protected]| <== Byte 9/10/11: is ramdisk length
00000070 00 00 00 00 04 00 00 00 2e 9c 51 00 00 00 00 00 |..........Q.....| <== Byte 9/10/11: is cmdline start
00000080 00 00 00 00 00 02 00 00 00 02 00 00 00 00 00 20 |............... | <== Byte 9/10/11: is cmdline length (512 characters)
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
- Now read the addresses from behind:
00 10 00 => is 0x001000
68 70 3c => is 0x3c7068
68 80 3c => is 0x3c8068
c6 1b 15 => is 0x151bc6
2e 9c 51 => is 0x519c2e
00 02 00 => is 0x000200
- NOTE: THE NUMBERS WILL BE DIFFERENT FOR YOUR st26i DEVICE !!!
- Use 'dd' to split sony_boot.img into its single parts.
- BUT use the correct numbers from your kernel here:
linux-w49x:~ # dd skip=$((0x001000)) count=$((0x3c7068)) bs=1 if=sony_boot.img of=sony_kernel.img
3960936+0 records out
3960936 bytes (4.0 MB) copied, 66.2326 s, 59.8 kB/s
linux-w49x:~ # dd skip=$((0x3c8068)) count=$((0x151bc6)) bs=1 if=sony_boot.img of=sony_ramdisk.img.gz
1383366+0 records in
1383366+0 records out
1383366 bytes (1.4 MB) copied, 23.1965 s, 59.6 kB/s
linux-w49x:~ # dd skip=$((0x519c2e)) count=$((0x000200)) bs=1 if=sony_boot.img of=sony_cmdline.img
512+0 records in
512+0 records out
512 bytes (512 B) copied, 0.00931558 s, 55.0 kB/s
3. Unpack the ramdisk
=======================
- First unzip ramdisk (should start with 0x1f 0x8b )
linux-w49x:~ # hexdump -C sony_ramdisk.img.gz | head
00000000 1f 8b 08 00 a0 a8 50 51 00 03 ec 3d 69 73 db b8 |......PQ...=is..|
00000010 92 f9 fa f4 2b b0 72 ea cd d8 ab 83 92 cf 64 ca |....+.r.......d.|
00000020 5b 2b 5b b4 ad 7a b6 e4 91 e4 1c b5 f5 4a a1 48 |[+[..z.......J.H|
00000030 48 42 99 57 78 58 f1 ce e4 bf 6f 37 c0 03 a4 a8 |HB.WxX....o7....|
00000040 83 49 66 6a 76 ca aa 38 a6 c0 ee 46 a3 bb d1 68 |.Ifjv..8...F...h|
00000050 a0 01 58 39 55 4e 95 96 a2 28 ea 61 eb 4c 85 df |..X9UN...(.a.L..|
00000060 ca 51 4b ed 2a c5 9f 37 c7 ad a3 ab f6 71 f7 38 |.QK.*..7.....q.8|
00000070 57 7e 16 fd 6e af c1 4b ca 1b af 14 b9 be 2b 8e |W~..n..K......+.|
00000080 dc ea 1c ad c1 6b 65 bf 25 5f b7 d4 d7 4a e8 85 |.....ke.%_...J..|
00000090 f4 89 da 81 d1 98 3b a6 31 63 fe a2 e1 e9 af 5e |......;.1c.....^|
linux-w49x:~ # gunzip sony_ramdisk.img.gz
- Now again, the resulting sony_ramdisk.img should start with 0x30 0x37 0x30.
- Now extract cpio archive to a directory:
linux-w49x:~ # mkdir ramdisk
linux-w49x:~ # cd ramdisk/
linux-w49x:~/ramdisk # cpio -i < ../sony_ramdisk.img
4444 blocks
linux-w49x:~/ramdisk # ls
charger init init.qcom.ril.path.sh init.s1.rc logo.rle sys
data init.Sony.rc init.qcom.sh init.target.rc logo.rle.org system
default.prop init.goldfish.rc init.qcom.usb.rc init.trace.rc proc ueventd.Sony.rc
dev init.qcom.class_core.sh init.qcom.usb.sh init.usb.rc res ueventd.goldfish.rc
fstab.msm7627a init.qcom.class_main.sh init.rc init.usbmode.sh sbin ueventd.rc
- OPTIONAL: You can now modify the ramdisk to your needs... we will
repack it later from here.
4. Build the sony kernel with the original kernel configuration (.config)
===========================================================================
In this section we will just rebuild the sony kernel with its default config.
This step is optional. You might want to SKIP THIS STEP and continue dircetly
with building the optimized kernel (Chapter 7)
- Install the mentioned ARM compiler from Mentor (for URL, see top of page)
- Extract the kernel config we fetched from the device:
linux-w49x:~ # gunzip sony_config.gz
- Extract the sony kernel:
linux-w49x:~ # tar -xf 11.2.A.0.21.tar.bz2
- Add the config to the kernel base directory:
linux-w49x:~ # cp sony_config ./kernel/.config
linux-w49x:~ # cd kernel
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make oldconfig
- OPTIONAL: reconfigure the kernel OR skip this step:
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make menuconfig
- Because the ARM compiler is pretty strict, edit the kernel Makefile in "kernel/Makefile":
- Change this part....
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
else
KBUILD_CFLAGS += -O2
endif
- .. by appending this to the flags:
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,) $(call cc-disable-warning,implicit-function-declaration,) $(call cc-disable-warning,strict-prototypes,) $(call cc-disable-warning,unused-function,) $(call cc-disable-warning,unused-variable,)
else
KBUILD_CFLAGS += -O2 $(call cc-disable-warning,maybe-uninitialized,) $(call cc-disable-warning,implicit-function-declaration,) $(call cc-disable-warning,strict-prototypes,) $(call cc-disable-warning,unused-function,) $(call cc-disable-warning,unused-variable,)
endif
- Finally we build the kernel:
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make
- Time to grab a BIG 0xCOFFEE
5. Build a new boot image
===========================
- Collect the new kernel:
linux-w49x:~ # cp ~/kernel/arch/arm/boot/zImage my_kernel.img
- Pack a new ramdisk (or just take exsiting one)
linux-w49x:~ # cd ramdisk
linux-w49x:~/ramdisk # find . | cpio --quiet -H newc -o | gzip > ../my_ramdisk.img.gz
linux-w49x:~/ramdisk # cd ..
- Pack everything together using mkelf.py from sony (URL, see above):
linux-w49x:~ # python mkelf.py -o my_boot.img [email protected] [email protected],ramdisk [email protected],cmdline
6. Flash the new boot image to the phone
==========================================
- power off device
- vol up + attach usb = fastboot
linux-w49x:~ # fastboot flash boot ./my_boot.img
linux-w49x:~ # fastboot reboot
- If anything goes wrong you can always flash the extraced image using:
linux-w49x:~ # fastboot flash boot ./sony_image.img
linux-w49x:~ # fastboot reboot
7. Now for the FUN part: TUNE the sony kernel with the attached patch-file
=============================================================================
- Basically we disable "module support" as we have none
- Disable A LOT OF DEBUG: debugfs and various debug statments in MSM drivers
- Tune vibration period to be more gentle
- Optimize kernel size for speed and not for size
- Remove kernel and user space process debug infos
- Make sure you unpack the stock sony kernel sources. The sources need to be
fresh and clean!!!
linux-w49x:~ # tar -xf 11.2.A.0.21.tar.bz2
linux-w49x:~ # cd kernel/
- patch the performance tweaks to it. The perf_tweak.patch is appended to this post:
linux-w49x:~/kernel # patch -p3 < ../perf_tweak.patch
patching file ./kernel/power/earlysuspend.c
patching file ./Makefile
patching file ./arch/arm/mach-msm/smd_pkt.c
patching file ./arch/arm/mach-msm/sdio_cmux.c
patching file ./arch/arm/mach-msm/reset_modem.c
patching file ./arch/arm/mach-msm/qdsp5v2/mi2s.c
patching file ./arch/arm/mach-msm/qdsp5v2/audio_out.c
patching file ./arch/arm/mach-msm/modem_notifier.c
patching file ./arch/arm/mach-msm/msm_cpr-debug.c
patching file ./arch/arm/mach-msm/smd_rpcrouter.c
patching file ./arch/arm/mach-msm/ipc_router.c
patching file ./arch/arm/mach-msm/bam_dmux.c
patching file ./arch/arm/mach-msm/qdsp6/msm_q6vdec.c
patching file ./arch/arm/mach-msm/rmt_storage_client.c
patching file ./arch/arm/mach-msm/include/mach/debug_mm.h
patching file ./arch/arm/mach-msm/clock.c
patching file ./arch/arm/mach-msm/sdio_dmux.c
patching file ./arch/arm/mach-msm/msm_cpr.h
patching file ./arch/arm/mach-msm/qdsp5/audio_mp3.c
patching file ./arch/arm/mach-msm/qdsp5/audmgr.c
patching file ./arch/arm/mach-msm/qdsp5/audio_acdb.c
patching file ./arch/arm/mach-msm/qdsp5/audio_lpa.c
patching file ./arch/arm/mach-msm/pm2.c
patching file ./arch/arm/mach-msm/sdio_ctl.c
patching file ./arch/arm/mach-msm/clock-debug.c
patching file ./arch/arm/mach-msm/board-msm7627a-display.c
patching file ./arch/arm/mach-msm/vreg.c
patching file ./arch/arm/mach-msm/board-tamsui-jlo.c
patching file ./arch/arm/mach-msm/clock.h
patching file ./net/netfilter/xt_socket.c
patching file ./include/linux/vibrator_class.h
patching file ./include/linux/bma250.h
patching file ./drivers/media/common/tuners/xc4000.c
patching file ./drivers/tty/serial/msm_serial_hs.c
patching file ./drivers/vibrators/fih_vibrator.c
patching file ./drivers/vibrators/vibrator_class.c
patching file ./drivers/video/msm/msm_fb.c
patching file ./drivers/video/msm/mipi_orise.c
patching file ./drivers/bluetooth/bluesleep.c
patching file ./drivers/usb/otg/msm_otg.c
patching file ./drivers/usb/otg/msm72k_otg.c
patching file ./drivers/usb/gadget/f_diag.c
patching file ./drivers/usb/gadget/u_ctrl_hsuart.c
patching file ./drivers/usb/gadget/f_rmnet_smd_sdio.c
patching file ./drivers/usb/gadget/u_serial.c
patching file ./drivers/usb/gadget/u_bam.c
patching file ./drivers/usb/gadget/f_rmnet_smd.c
patching file ./drivers/input/keyboard/fih_gpio_keys.c
patching file ./drivers/input/keyboard/fih_power_key.c
patching file ./drivers/input/touchscreen/cyttsp_core.c
patching file ./drivers/input/sensor/qpdss702.c
patching file ./drivers/leds/fih_led.c
patching file ./drivers/net/wireless/bcmdhd/wl_linux_mon.c
patching file ./drivers/net/wireless/bcmdhd/Makefile
patching file ./drivers/net/wireless/bcmdhd/dhd_custom_gpio.c
patching file ./drivers/power/fih_bq27520_fuelgauger.c
patching file ./drivers/power/fih_msm_battery.c
patching file ./drivers/gpu/msm/adreno_postmortem.c
patching file ./drivers/gpu/msm/adreno.c
patching file ./drivers/rtc/rtc-msm.c
patching file ./.config
linux-w49x:~/kernel # ARCH=arm CROSS_COMPILE=/root/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi- make
===> repeat steps 5) and 6) but use our new zImage.
A: Howto build a patch file by comparing a
fresh extracted kernel sources with your edited sources:
=========================================================
- Compare two kernel directories and create a patch from it:
linux-w49x:~ # export BASEDIR=$PWD
linux-w49x:~ # cd kernel/
linux-w49x:~/kernel # rm $BASEDIR/perf_tweak.patch
linux-w49x:~/kernel # find -name '*.c' -o -name '*.h' -o -name 'Makefile' -o -name '.config' | xargs [email protected] diff -upN $BASEDIR/kernel/@ $BASEDIR/my_kernel/@ >> $BASEDIR/perf_tweak.patch
Great Tutorial for Xperia J custom Kernel
Thanks .. Really helpful .
numbers were different in mine
dd skip=$((0x001000)) count=$((0x3da520)) bs=1 if=sony_boot.img of=sony_kernel.img
dd skip=$((0x3db520)) count=$((0x11a498)) bs=1 if=sony_boot.img of=sony_ramdisk.img.gz
dd skip=$((0x4f59b8)) count=$((0x000200)) bs=1 if=sony_boot.img of=sony_cmdline.img
I am with locked bootloader ( 1 week old JLo ) will do it as soon I unlock it.
I will also include swap support in kernel config and test .
omg it's so complicated...
have anyone finished it? Will it be released as flashable version ?
Lol ye makes me dizzy!
work on xperia J
this work on xperia J with bootloader locked
For simplicity's sake I like to build my kernels with CyanogenMod, but I'll check out your patch for some useful edits. :good:
Don't want to necro bump threads but....
Massive thanks to OP
I'd been messing around for the last day with trying to compile the .31 stock kernel from source.
Successfully used the above guide to dump the .31 kernel from phone add overclock to .31 source code (from Vengeance 1.42 source) compile, make boot.img and flash. :laugh:
Can I use this patch for the newest JB kernel? will it work?
Hello friends, I'm back again with something I wish to share with you all. I have compiled three files to work flawlessly for ARM devices which will allow users to unpack, edit, and repack their boot.img without the use of a PC and all straight from their device.
---unmkbootimg, mkbootfs, mkbootimg---
Click here for the source on my Github.
Hey guys, since I have made this thread a while back there has been a LOT of changes made to the resource. For starters, it is now a multi call binary. In addition, I have updated mkbootfs for better support, mkbootimg.c has dt support, unmkbootimg.c has dt support, bootimg.h has dt support, as well as adding dtbtool, and dtc. Lets not also forget about lz4 for those whos ramdisks are not gz compressed. I am continuously making changes to the source and the op attachment will not be kept up to date. To stay up to date you will need to build the multi call binary from the source provided by the link above. Just simply run: make multi.
Note:
-- The mkbootimg binary is based upon the AOSP with some added modifications to work in conjunction with unmkbootimg.
-- The unmkbootimg binary is based on the original mkbootimg source but with reverse engineering to compliment its helpful use in extraction and thus providing the needed command to rebuild properly.
-- The mkbootfs binary is based on the source provided within the dsixda kitchen to insure the proper structural repacking of the ramdisk, etc.
Requirements:
-- BusyBox (cpio, gunzip and gzip is mandatory)
-- /System Write Permissions (Does not need to be a modified kernel)
-- Terminal Emulator
-- ES File Explorer (or similar)
-- Hex Editor (or use of DD)
-- Unzip boot_manipulation.zip on your device and copy the three files over to /system/bin. Those three files inside the .zip will be named unmkbootimg, mkbootfs and mkbootimg.
-- EDIT: I have included a flashable zip for these files.
-- Set permissions to rwxr-xr-x (755) on each binary. Note: The flash zip does this already.
-- Open up your android terminal emulator.
-- Now go ahead and pull your boot.img from your device (or use another one if you wish). Here is an example:
Code:
[email protected]:/ # [COLOR="Red"]dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img[/COLOR]
dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
32768+0 records in
32768+0 records out
16777216 bytes transferred in 1.496 secs (11214716 bytes/sec)
[email protected]:/ #
-- Open up your boot.img with the Hex Editor and look for: ANDROID!. Remove everything before it so that the ANDROID! header is the first to be read then save it over top of the boot.img. NOTE: This is only required if you are using a stock boot.img. Here is an example:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 [COLOR="red"]A5 F0 BA B7 B0 43 E3 F8 3C E1 63 55 AE 75 C6 69 ¥ðº·°Cãø<ácU®uÆi[/COLOR]
00000010 [COLOR="red"]11 27 16 2F 51 48 E5 41 6F ED E1 7D C9 61 FB 3B .'./QHåAoíá}Éaû;[/COLOR]
00000020 [COLOR="red"]5F 45 49 EE 48 79 6E 4E FB DE 18 FC A0 F4 9A C3 _EIîHynNûÞ.ü*ôšÃ[/COLOR]
00000030 [COLOR="red"]43 11 35 67 AD 7E 2F D8 F6 E8 B1 4D 7D E0 45 B6 C.5g.~/Øöè±M}àE¶[/COLOR]
00000040 [COLOR="red"]E2 08 5F 0B 56 7F 45 71 3D 38 E2 C4 76 3E 53 EE â._.V.Eq=8âÄv>Sî[/COLOR]
00000050 [COLOR="red"]A4 3D 83 9F A2 BE D5 F4 75 5D B5 08 4E CC 9B BC ¤=ƒŸ¢¾Õôu]µ.NÌ›¼[/COLOR]
00000060 [COLOR="red"]7F 7A 9E 3D 4B 19 1B 91 6D FB 82 A0 B5 A8 38 88 .zž=K..‘mû‚*µ¨8ˆ[/COLOR]
00000070 [COLOR="red"]25 07 B5 1B 74 A2 03 62 BE 78 FA 33 96 A0 32 70 %.µ.t¢.b¾xú3–*2p[/COLOR]
00000080 [COLOR="red"]05 56 50 EF 88 C1 F3 73 E4 C5 73 6A 4E F8 CA 0A .VPïˆÁósäÅsjNøÊ.[/COLOR]
00000090 [COLOR="red"]D7 EF 2A 7F 09 30 21 BF 63 61 35 9A 9B 8A 62 42 ×ï*..0!¿ca5š›ŠbB[/COLOR]
000000A0 [COLOR="red"]28 C2 78 08 B0 CD 94 5F 7E EC F6 BA AD E6 AE 23 (Âx.°Í”_~ìöº.æ®#[/COLOR]
000000B0 [COLOR="red"]3E FD D8 A0 F1 F6 6D E2 D9 1E 2C E5 9F 91 84 92 >ýØ*ñömâÙ.,埑„’[/COLOR]
000000C0 [COLOR="red"]2E F0 6E 3C 1D 2B 1A D5 61 18 B2 F4 E0 66 B5 2F .ðn<.+.Õa.²ôàfµ/[/COLOR]
000000D0 [COLOR="red"]AE 97 9F F8 53 65 CE ED 68 43 4B 2B D5 A1 B6 D9 ®—ŸøSeÎíhCK+Õ¡¶Ù[/COLOR]
000000E0 [COLOR="red"]7D 36 CE A9 CC EC F4 5A 07 D8 99 5A 91 CC 8F 71 }6ΩÌìôZ.Ø™Z‘Ì.q[/COLOR]
000000F0 [COLOR="red"]A1 8D D7 82 C3 20 AB 7A 07 68 10 2D CC F6 A8 F9 ¡.ׂà «z.h.-Ìö¨ù[/COLOR]
00000100 41 4E 44 52 4F 49 44 21 08 D6 56 00 00 80 40 80 ANDROID!.ÖV..€@€
00000110 0E F0 07 00 00 80 80 81 00 00 00 00 00 00 30 81 .ð...€€.......0.
00000120 00 01 40 80 00 08 00 00 00 00 00 00 00 00 00 00 [email protected]€............
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
-- Please note, HTC uses a 256 bit signature prior to the ANDROID! magic found in the boot.img. This may vary with other devices so keep that in mind. To remove the 256 bit junk so the boot.img is read properly you can use a hex editor and delete it or you can use DD. The following dd command I will be using is based on K2_CL in regards to the partition for our boot.img. Please make necessary adjustments to this command by insuring you know the location and where abouts of your own boot.img; Example:
Code:
dd bs=256 skip=1 if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
-- Alright, so we have the unmkbootimg, mkbootfs and mkbootimg located in /system/bin. We have pulled our boot.img and removed the junk before the magic android value: ANDROID!. Let's continue.
-- Go back to your android terminal emulator and change directories to /data/local/tmp. Here is an example:
Code:
[email protected]:/ # [COLOR="red"]cd /data/local/tmp[/COLOR]
cd /data/local/tmp
[email protected]:/data/local/tmp #
-- Now run unmkbootimg. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]unmkbootimg -i boot.img[/COLOR]
unmkbootimg -i boot.img
kernel written to 'kernel' (5690888 bytes)
ramdisk written to 'ramdisk.cpio.gz' (521735 bytes)
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset 0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.img
[email protected]:/data/local/tmp #
-- Before you go any futher, copy all text within your android terminal emulator and paste it in to a text document. I personally use 920 Text Editor from the play store. You will do this so when the time comes you can open it back up and copy/paste the command to rebuild your boot.img as listed (This will save you some time).
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]ls[/COLOR]
ls
boot.img
init.rc
kernel
ramdisk.cpio.gz
[email protected]:/data/local/tmp #
-- Now lets create a folder and lets call it ramdisk. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkdir ramdisk[/COLOR]
mkdir ramdisk
[email protected]:/data/local/tmp #
-- Now lets change directories to that ramdisk folder. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]cd ramdisk[/COLOR]
cd ramdisk
[email protected]:/data/local/tmp/ramdisk #
-- Go ahead and extract ramdisk.cpio.gz. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]gunzip -c ../ramdisk.cpio.gz | cpio -i[/COLOR]
isk.cpio.gz | cpio -i <
1851 blocks
[email protected]:/data/local/tmp/ramdisk #
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]ls[/COLOR]
ls
cwkeys
data
default.prop
dev
fstab.k2_cl
init
init.goldfish.rc
init.qcom.rc
init.qcom.sh
init.rc
init.target.rc
init.target.recovery.rc
init.trace.rc
init.usb.rc
proc
sbin
sys
system
ueventd.goldfish.rc
ueventd.rc
ueventd.target.rc
[email protected]:/data/local/tmp/ramdisk #
-- Now feel free at this point to make your edits within the ramdisk folder. When complete then come back and we shall finish the job.
-- Go ahead and move back out of the ramdisk folder by the following command:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="Red"]cd ..[/COLOR]
cd ..
[email protected]:/data/local/tmp #
-- You should now be in /data/local/tmp/.
-- Lets go ahead and repack the contents found in the ramdisk folder. Here, we will make use of the mkbootfs binary. Please take note that your original is named 'ramdisk.cpio.gz'. Here we will be repacking and renaming it to 'myramdisk.gz'. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkbootfs ./ramdisk | gzip > myramdisk.gz[/COLOR]
mkbootfs ./ramdisk | gzip > myramdisk.gz
[email protected]:/data/local/tmp #
-- Open up your saved text file as instructed earlier and scroll to where you see this:
Code:
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset
0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'conso
le=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o
boot.img
-- Look for --ramdisk ramdisk.cpio.gz and INSURE you change it to --ramdisk myramdisk.gz. Also go ahead and change boot.img to modboot.img. Now copy the mkbootimg command and paste it in to your android terminal emulator. Press enter.
-- There are multiple ways you can apply the new boot.img. The smartest way would be to use fastboot so that you may boot the image vice flashing it in case you screwed something up on your own accord. However, I personally will write the boot.img straight to the boot partition using dd, then I reboot the device. If you wish to do the same then that is fine.
-- Now you have your new Modded Boot Image. Enjoy, and as always... CLICK THANKS if this was helpful to you and....
--- Happy Hunting!!!
MKBOOTIMG-TOOLS
GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: @Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be succesfull. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
xpirt said:
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
Click to expand...
Click to collapse
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
I understand. And the bootloop I said is exactly what happened when packed with old mkbootimg?
xpirt
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Ok. Good, I'll try it out
xpirt
xpirt said:
Ok. Good, I'll try it out
xpirt
Click to expand...
Click to collapse
Sounds good. If it is a stock boot.img then you will need to remove everything before the android magic value (ANDROID!). After that, have at it lol. I will be adding additional code later on that will automatically look for the android magic value and make the necessary changes to it so it reads properly. This will keep others from having to do it themselves. Until then, has to be done by the user since I have hard-coded the magic android value.
Sent from my K2_CL using Tapatalk
Also plan to edit the unpackbootimg file so it will automatically extract the ramdisk archive automatically with out the need of the user having to use the ramdisk.sh file or by manually inputing the commands to do so. Got other plans as well. So a lot of improvements and bonuses are to come. Gonna try and make this thing a beast for arm devices.
Sent from my K2_CL using Tapatalk
OP updated with more in depth instructions/examples. Also, I have taken out the ramdisk.sh file and have also removed the unpackbootimg file. I have implemented unmkbootimg and a remake of the mkbootimg file(s). Works like a boss and gives you all the information you need to rebuild your boot.img. Will work on ALL arm devices. Enjoy.
Added download link to open source. See OP.
Sent from my K2_CL using Tapatalk
OP has been updated. I have included an additional binary called mkbootfs to work in conjuction with the other two given the necessary structural building properties of the boot.img. I have tested this on A LOT of boot.img's and all have been successful. I have also updated the instructions for using these binaries on your android device. Enjoy.
sweet sweet victory!
russellvone said:
sweet sweet victory!
Click to expand...
Click to collapse
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
This is awesome.
Can you share the source code for this?
Sent from my GT-I8730 using Tapatalk
PM Sent
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
PM Sent
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Thank you!
Sent from my GT-I8730 using Tapatalk
OP updated with four photo attachments.
Sent from my K2_CL using Tapatalk
(Probably n00bish) Question:
How do I compile the binaries from the source? By gcc or make?
Beamed from my Galaxy Express using Tapatalk
- for Linux only -
Stock Recovery to TWRP Backup Converter for Android system recovery <3e>
This progam is basically written for unpacking stock recovery android backup userdata_20160823_100259.backup + convert it into custom recovery nandroid backup data.ext4.win000 (but you can create your own TWRP Backups from "any" data source, too)
content and usage of bckp2win.sh is similar to bckp2cwm.sh with some slight modifications. based on previous version, it skips the checksum and unpack /data partition from userdata_00000000_000000.backup then re-pack it as TWRP Backup. optionally the screenlock pattern can be unlocked.
Requirements:
- pc with linux
- ext4 formatted hard disk
may work on ntfs, give a try (in case backup is a partition image)
Requirements (source phone):
- Android system recovery <3e> with
- "backup user data" functionality
- data must not encrypted
- external sdcard
Requirements (target device):
- root
- TWRP custom recovery
- working identical ROM pre-installed (like source phone)
before you start:
download this flashable UPDATE-sdcard.Fix.Permissions-signed.zip from osm0sis @ xda-developers to your phones memory or external sdcard - you might need it later
http://forum.xda-developers.com/showthread.php?t=2239421
TWRP and Internal Storage:
even if TWRP recovery process claims not touching /data/media, it restores files anyway. this is a great advantage side effect as we can easily restore Pictures and Files by simply including it in the backup. However, this will overwrite existing data - please don't use this option unless you know what you're doing!
if apps crashing after restoring from TWRP, this might have to do with Internal Storage - the above flashable zip will fix permissions, ownership and selinux labels for /data/media in case you manually added some files (regarding /data - of course - there is no tool in the world, which can do the same for /data partition - be warned never copy files, just always move files from one linux file system to another, and never use a windows file system)
bckp2win.sh is a linux bash script using GNU tar for creating TWRP archive files from userdata_yyyymmdd_hhmmss.backup files.
in TWRP Backup each data.ext4.win000 file represent a standalone tarball archive - this means each single archive can be unpacked for its own - without concatenating them, or having splitted files spreaded over multiple archives. unfortunately i don't know how they do it (i think TWRP use its own tar implementation), so i decided to write another bash script wich is basically doing the same thing (creating multipart standalone tarball archives):
edit: this is the main converting script (and the only file you need)
multi_tar.sh is not limited to Android system recovery <3e> userdata backup and can be used for any scope of application.
This means you can simply create TWRP Backups from "any" data source. It is summarizing files in a index file until archive size is reached and then archiving from index with GNU tar. This is a very slow procedure but it works. optionally it uses GZIP compression. (i really dont know how to check compressed file size from bash without compressing it, therefore it is compressed twice in a 2 pass way, 1-st pass is for checking size only)
edit: do not download this script, try bckp2win.sh without multi_tar.sh first (press No when asked). it is for splitting large backups only and not required in most cases
twrp_sign.sh is another bash script for creating sha2 checksums especially for TWRP Backups. But checksums can be disabled in TWRP - therefore its optional.
needs ~ 120% of free disk space and takes time about ~ 30 min, enjoy your coffee
[TUTORIAL] How to convert stock backup into TWRP backup
First of all you need to know, that userdata_yyyymmdd_hhmmss.backup files contain user data only. it is NOT a full nandroid backup like TWRP / CWM.
So we can just restore data partition from TWRP:
userdata_20160823_100259.backup -> data.ext4.win000 -> /data
The data partition contains the Internal Virtual SD Card. It is usually not included in TWRP backup. It is your decision to manually copy back to phone (recommended). But you can also restore Internal Virtual SD Card from TWRP:
/data/media/0 -> /storage/emulated/0
IMEI and WiFi MAC-Address:
/data/nvram (NOT recommended)
If there is a copy of NVRAM partition in folder /data/nvram, the script will delete it by default. However, there is a option to use IMEI and WiFi MAC-Address from backup (clone), instead from Phone.
Windows Users please click here
download UNetbootin -> https://unetbootin.github.io <- scroll this page down for tutorial
format USB flash drive FAT32install any Linux Distro to USB flash drive
Reboot your PC from USB flash drive
to access the boot menu while booting your computer:
- press the appropriate key F11 or F12 during the initial startup screen
- select the USB boot option in the BIOS boot menu
- boot Default entry
congratulations, you have
sucessfully entered your
own working Linux system!
it's easy, isn't it?
Now, come back to forum.xda-developers.com
- find Start Menu on upper left corner
- open the "Web Browser" from Favorites
- search for "bckp2win" in google
you can add your Keyboard Layout from: Settings - Keyboard
Note: performance of Firefox badly depends on USB flash drive speed
if it is too slow, try another one, or disable persistence:
- find syslinux.cfg file on USB flash drive
- open syslinux.cfg file with editor
- delete --- persistent from Try Xubuntu without installing entry
- save the changes, reboot from USB flash drive Try Xubuntu without installing entry
However, without persistence it is a read-only Live system and will lose all settings on reboot
Let's begin with preparations
- copy UPDATE-sdcard.Fix.Permissions-signed.zip to microSD card / or
- download UPDATE-sdcard.Fix.Permissions-signed.zip to target phone
- connect the source phone USB cable / or
- insert the microSD card into the PC's SD Card Reader
- copy all userdata_20160823_100259.backup files to any folder on local disk
- download all the zip files from this thread
- unpack zip files to same folder on local disk
run the shell script in Terminal
- do right-click somewhere in the backup folder, select "Open Terminal Here"
- type "sudo bash bckp2win.sh" in Terminal
- check disk space
example: when backup is 2 GB,
Avail must > 2,4 GB (120%)
when backup is 55 GB,
Avail must > 66 GB (120%)
- check file system type
Type must not vfat, fat32
all others allowed
(ntfs, ext4, fuseblk, ...)
this is very important! otherwise it will fail at the end and waste your time, and you won't know the reason. so please check carefully
- select file number to extract
- wait a long time, depends on disk speed and backup size (1~2 min / 1 GB)
Halftime break
- when message appears Press 'y' to unlock: [y/n] - Congratulations! The backup is sucessfully extracted
(if you need to edit/modify/delete files within backup this is the point for break)
- to continue with re-packing:
answer all questions with No
(or just press Enter for default):
Android sparse image (simg2img) support -> No
Flash-Friendly File System (F2FS) support -> No
unlock screenlock pattern -> No
clone old IMEI and Wifi Mac Address -> No
Restore /storage/emulated/0 -> No
use gzip compression -> No
Extract Internal Virtual SD Card to local disk -> Yes
(this will extract /data/media to TWRP folder instead, but exclude it from backup)
- wait for the script is finished
- wait for background processes
(it happens sometimes script finishes too early, if there is a data.ext4.win000 + data.ext4.win0000 file, just wait for the target size 1 GB each file)
- if checksums missing or failed, please manually run twrp_sign.sh again
(successful checksums look like this)
Finally we can restore the new backup
- copy back TWRP folder to phone
- boot into recovery mode
- create a failsafe backup (just in case...)
- move folder to the right location via MTP, or
- Advanced -> File Manager -> TWRP/BACKUPS/<serialno>/<backup folder>
- Options (blue icon on the right bottom) -> Move -> TWRP/BACKUPS/<phone name> -> Swipe to confirm
(in case converted backup is not visible in Restore list...)
- restore converted backup from TWRP
- install the flashable UPDATE-sdcard.Fix.Permissions-signed.zip
(just in case you have added files to data/media...)
- boot the phone
- move/copy all your pictures videos etc from TWRP folder back to phone
Troubleshooting
If you fail at some point please try again with more disk space or gzip compression
phone is not showing up on PC
enable Settings -> Developer options -> Select USB Configuration -> MTP:
- goto Settings -> About phone
- tab Build number seven times until you see a message
- goto Settings -> Developer options
- enable Developer options, confirm Allow development settings
- scroll down to -> Select USB Configuration
- select MTP (Media Transfer Protocol)
My source backup file is not in "userdata_YYYYMMDD_hhmmss.backup" format
This script may work with other archives, but only accept "userdata_YYYYMMDD_hhmmss.backup" pattern as input file name. But you can specify any input file or folder as parameter. the script will scan the folder for known archive types and link files into script folder:
sudo bash bckp2win.sh ~/Android/Backup/TWRP/2016-08-23--10-02-59/data.ext4.win*
mkdir: cannot create directory ‘b2wtmp’: File exists
There was a previous session left, delete the folder ‘b2wtmp’ and try again. You can keep previous session for testing purposes with parameter -f force unpack:
sudo bash bckp2win.sh -f
ERROR: something goes wrong. check disk space
The GNU tar unpacking or archiving process may fail for various reasons. However, you can suppress error messages and skip this exit point for testing purposes with parameter -f force unpack. If you run out of disk space, you can exclude folders from backup with parameter -e --exclude PATTERN, for example:
sudo bash bckp2win.sh -e */com.google.android.googlequicksearchbox*
Bugs & Known Issues
extractTarFork() process ended with ERROR: 255
probably bug in script. at the moment, only solution is manually restoring backup files. i know its annoying but i don't know the reason, yet.
- download GNU tar for android
- unpack the zip and copy the tar binary to phone
- in TWRP, copy tar binary to /cache, then wipe data
- in TWRP, go back to -> Advanced -> Terminal
- in Terminal, change directory to backup folder, then run for each file
Code:
chmod 0755 /cache/tar
cd /external_sd/TWRP/BACKUPS/<phone>/2016-08-23--10-02-59*
/cache/tar --selinux --xattrs -P -vxpf data.ext4.win000
(or for compressed files)
busybox gzip -cd data.ext4.win000 | /cache/tar --selinux --xattrs -P -vxp
Please post here for support i will answer your questions
found a multipart image, merge files
==================
... merged
try to unpack ...failed
try to mount as *...failed
skip first 512 bytes and try to mount again as ext2, as rfs, as fsfs
... failed
no files in folder "data"
exiting script
What can I do ?
My phone model is Bluboo S1 with Android 7.0, before I wiped all out I was made backup with stock backup and now I have TWRP 3.2.1. Now I have phone flashed with BLUBOO_S1_Helio_P25_L_V04_20170908 and is working but I want put my old userdata because I think there is all my 230 apps already installed.
Please check if your userdata_20180926_141645.backup is ext4 image. Each file start with a 512 byte checksum header, followed by partition image. The ext4 Super Block will start at offset 1024 bytes (from partition). The ext4 magic number 0xEF53 you can find at offset 0x38 (from the Super Block start)
We can skip (512 bytes) checksum + (1024 bytes) unused padding, because the Super Block start is at (1536 bytes) = 0x600 in this case
Please note the ext4 magic 0xEF53 at offset 0x638
encrypted files not supported
If the files look like this (no zeros within, after skip 512 bytes checksum) it is probably a raw backup of encrypted data partition
you can check with hexdump
Code:
hexdump -C -n1600 userdata_20180926_141645.backup
Unfortunately, these userdata backups are pretty useless since android 7.0 (encrypted by default), because they will not backup efs/metadata. If you wipe data from stock recovery, the metadata is wiped, too. It is impossible to decrypt data without encryption key (which is stored in metadata).
If you are really lucky maybe its not to late, do a read back of metadata partition with SP Flash Tool. Furthermore, check if userdata backup is encrypted
. . .
If the files look like this (no zeros within, after skip 512 bytes checksum) it is probably a raw backup of encrypted data partition
you can check with hexdump
Code:
hexdump -C -n1600 userdata_20180926_141645.backup
[/QUOTE]
***
there was also too little disk space and I installed the new Ubuntu on the other computer so I'll try it later
if you prefer to re-pack data by yourself, stop the script when it ask for unlock screenlock pattern (CTRL + C)
enter parent directory of data folder
run multi_tar.sh - while first arg is destination and all other args are source folders
Note you can change the output to any file or folder:
replace "data.ext4.win" with "/media/xubuntu/my-drive/Android/my-output-folder/my-file-name"
Code:
sudo bash multi_tar.sh -z -L 1048576 data.ext4.win data --transform 's,^data,/data,'
(with parameters -z for compression and -L for split size, and some string replacement within the archive - replaceing "data" with "/data" in this case)
there are still some bugs i am struggle with, restoring in TWRP fails when a single file within backup is failed.
Please check out my other solution for encrypted backup. You can restore TWRP backup from this zip instead of restoring from TWRP menu
https://forum.xda-developers.com/showthread.php?t=3899918
aIecxs said:
We can skip (512 bytes) checksum + (1024 bytes) unused padding, because the Super Block start is at (1536 bytes) = 0x600 in this case
Click to expand...
Click to collapse
Hi,
i have exact these offset you wrote here but i do not have success to mount my data. Have you an idea what could be wrong on my side?
Code:
000001d0 ab 0a 44 a3 c5 ee 69 fa 44 78 c2 ca ec 13 bb f5 |..D...i.Dx......|
000001e0 38 f4 e7 ca f2 7c 49 e3 a2 a0 d8 1e e3 f9 94 c5 |8....|I.........|
000001f0 f5 f5 3e c2 6a bc 8a 58 1c ef 0e 8a 91 29 c4 99 |..>.j..X.....)..|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000600 00 40 02 00 80 fc 08 00 00 10 00 00 77 e3 00 00 |[email protected]|
00000610 da 10 02 00 00 00 00 00 02 00 00 00 02 00 00 00 |................|
00000620 00 80 00 00 00 80 00 00 00 20 00 00 0f 8e a4 54 |......... .....T|
00000630 0f 8e a4 54 6c 02 ff ff 53 ef 01 00 02 00 00 00 |...Tl...S.......|
Code:
try to mount as ext4
...failed
skip first 512 bytes and try to mount again as ext4
...failed
try to mount as ext3
...failed
skip first 512 bytes and try to mount again as ext3
...failed
try to mount as ext2
...failed
skip first 512 bytes and try to mount again as ext2
...failed
try to mount as rfs
...failed
skip first 512 bytes and try to mount again as rfs
...failed
try to mount as f2fs
...failed
skip first 512 bytes and try to mount again as f2fs
...failed
./bckp2win.sh: Zeile 796: cd: .//b2wtmp: Datei oder Verzeichnis nicht gefunden
WARNING: no files in folder "data"
exiting script
Thanks
script looks buggy, maybe wrong mount options, or it makes a difference when called with "sudo bash bckp2win.sh"
Hello all.
Is there a way to do the inverse (system.ext4.win -> system.img) ? Does anybody know a link to instruction ?
With that system.img, I can then do: Bootloader> fastboot -S 130M flash system system.img
(if bootloader is unlocked).
Thank you everyone.
yes it is possible, check my edited reply later in 10 hours
edit: see reply in other thread
https://forum.xda-developers.com/showthread.php?t=4015725
@e5e197740b what is the error message when using this tool?
aIecxs said:
@e5e197740b what is the error message when using this tool?
Click to expand...
Click to collapse
Do I need a rooted Tablet for this? I'm not sure I understood all the instructions..
Edit:
So I ran bckpwin.sh in an Ubuntu VM, here is the output:
Code:
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
#
#
# This script converts "Android system recovery <3e>" stock recovery file
# "userdata_YYYYMMDD_hhmmss.backup" into custom recovery nandroid backup file.
#
# executing file system must be ext2/3/4 otherwise app permissions will be lost.
#
#
run this script as root. type "sudo -i" or "sudo bash bckp2win.sh".
are you root?
Press 'y' to continue: [y/n] y
2,0G userdata_20200609_220537.backup
2,0G userdata_20200609_220537.backup1
2,0G userdata_20200609_220537.backup2
2,0G userdata_20200609_220537.backup3
2,0G userdata_20200609_220537.backup4
2,0G userdata_20200609_220537.backup5
110M userdata_20200609_220537.backup6
13G total
Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda5 ext4 98G 45G 48G 49% /
WARNING: Make sure enough free disk space - NOT checked during process!!
1) userdata_20200609_220537.backup
select file number to extract (q to quit): 1
1) "userdata_20200609_220537.backup"
try to unpack as tar (multipart image support)
...failed
WARNING: No ext4 magic number detected. Try it anyway? [y/n] y
OPTION: install support for (EXT4) Android sparse image (simg2img)? [y/n] y
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Paket android-tools-fsutils ist nicht verfügbar, wird aber von einem anderen Paket
referenziert. Das kann heißen, dass das Paket fehlt, dass es abgelöst
wurde oder nur aus einer anderen Quelle verfügbar ist.
Doch die folgenden Pakete ersetzen es:
android-sdk-libsparse-utils android-sdk-ext4-utils
E: Für Paket »android-tools-fsutils« existiert kein Installationskandidat.
OPTION: install support for (F2FS) Flash-Friendly File System? [y/n] y
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
libf2fs-format4 libf2fs5
Die folgenden NEUEN Pakete werden installiert:
f2fs-tools libf2fs-format4 libf2fs5
0 aktualisiert, 3 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
Es müssen 185 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 568 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 libf2fs5 amd64 1.11.0-1.1ubuntu1 [14,1 kB]
Holen:2 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 libf2fs-format4 amd64 1.11.0-1.1ubuntu1 [16,6 kB]
Holen:3 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 f2fs-tools amd64 1.11.0-1.1ubuntu1 [154 kB]
Es wurden 185 kB in 0 s geholt (608 kB/s).
Vormals nicht ausgewähltes Paket libf2fs5:amd64 wird gewählt.
(Lese Datenbank ... 189666 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../libf2fs5_1.11.0-1.1ubuntu1_amd64.deb ...
Entpacken von libf2fs5:amd64 (1.11.0-1.1ubuntu1) ...
Vormals nicht ausgewähltes Paket libf2fs-format4:amd64 wird gewählt.
Vorbereitung zum Entpacken von .../libf2fs-format4_1.11.0-1.1ubuntu1_amd64.deb ...
Entpacken von libf2fs-format4:amd64 (1.11.0-1.1ubuntu1) ...
Vormals nicht ausgewähltes Paket f2fs-tools wird gewählt.
Vorbereitung zum Entpacken von .../f2fs-tools_1.11.0-1.1ubuntu1_amd64.deb ...
Entpacken von f2fs-tools (1.11.0-1.1ubuntu1) ...
libf2fs5:amd64 (1.11.0-1.1ubuntu1) wird eingerichtet ...
libf2fs-format4:amd64 (1.11.0-1.1ubuntu1) wird eingerichtet ...
f2fs-tools (1.11.0-1.1ubuntu1) wird eingerichtet ...
Trigger für man-db (2.9.1-1) werden verarbeitet ...
Trigger für initramfs-tools (0.136ubuntu6) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-5.4.0-37-generic
Trigger für libc-bin (2.31-0ubuntu9) werden verarbeitet ...
found a multipart image, merge files:
../userdata_20200609_220537.backup
../userdata_20200609_220537.backup1
../userdata_20200609_220537.backup2
../userdata_20200609_220537.backup3
../userdata_20200609_220537.backup4
../userdata_20200609_220537.backup5
../userdata_20200609_220537.backup6
(please wait - up to 15 min - don't worry computer is still alive)
...merged
try to unpack as sparse ext4 image (skipping ... )
...failed
try to mount as ext4
...failed
try to mount as ext3
...failed
try to mount as ext2
...failed
try to mount as rfs
...failed
try to mount as f2fs
...failed
no files in folder "data"
caching file to disk again for second run
(please wait - up to 15 min)
try to mount as ext4
...failed
skip first 512 bytes and try to mount again as ext4
...failed
try to mount as ext3
...failed
skip first 512 bytes and try to mount again as ext3
...failed
try to mount as ext2
...failed
skip first 512 bytes and try to mount again as ext2
...failed
try to mount as rfs
...failed
skip first 512 bytes and try to mount again as rfs
...failed
try to mount as f2fs
...failed
skip first 512 bytes and try to mount again as f2fs
...failed
./bckp2win.sh: Zeile 796: cd: .//b2wtmp: Datei oder Verzeichnis nicht gefunden
WARNING: no files in folder "data"
exiting script
So it had to load some stuff of the internet (namely simg2img and F2FS and its dependencies), but it seemed to run through properly, apart from not retrieving any data.
simg2img or f2fs is not required, it's from the days i wasn't aware of backup format
try to unpack as tar ...failed
mean it doesn't extract with tar(gz) with or without 512 bytes header
WARNING: No ext4 magic number detected
mean it did not find hex 53 ef with or without 512 bytes header (f2fs/ext4 is checked both)
but it tries to mount anyway
this could mean
a) script is not working (@matrix4you claimed this, too)
b) header is not 512 bytes
c) backup is encrypted
a) and b) can be double checked with unencrypted backup. do a factory reset then right after create another backup without booting android. this should give you 12 GB backup which can be zipped into less a few MiB because it is empty ext4 image
edit: did you run the script via 'sudo ./bckp2win.sh' that would explain the bug in line 796? usage is 'sudo bash bckp2win.sh' maybe behavior is different
aIecxs said:
simg2img or f2fs is not required, it's from the days i wasn't aware of backup format
try to unpack as tar ...failed
mean it doesn't extract with tar(gz) with or without 512 bytes header
WARNING: No ext4 magic number detected
mean it did not find hex 53 ef with or without 512 bytes header (f2fs/ext4 is checked both)
but it tries to mount anyway
this could mean
a) script is not working (@matrix4you claimed this, too)
b) header is not 512 bytes
c) backup is encrypted
a) and b) can be double checked with unencrypted backup. do a factory reset then right after create another backup without booting android. this should give you 12 GB backup which can be zipped into less a few MiB because it is empty ext4 image
edit: did you run the script via 'sudo ./bckp2win.sh' that would explain the bug in line 796? usage is 'sudo bash bckp2win.sh' maybe behavior is different
Click to expand...
Click to collapse
I did go sudo bash.
I can try the reset-backup thing.
aIecxs said:
simg2img or f2fs is not required, it's from the days i wasn't aware of backup format
try to unpack as tar ...failed
mean it doesn't extract with tar(gz) with or without 512 bytes header
WARNING: No ext4 magic number detected
mean it did not find hex 53 ef with or without 512 bytes header (f2fs/ext4 is checked both)
but it tries to mount anyway
this could mean
a) script is not working (@matrix4you claimed this, too)
b) header is not 512 bytes
c) backup is encrypted
a) and b) can be double checked with unencrypted backup. do a factory reset then right after create another backup without booting android. this should give you 12 GB backup which can be zipped into less a few MiB because it is empty ext4 image
edit: did you run the script via 'sudo ./bckp2win.sh' that would explain the bug in line 796? usage is 'sudo bash bckp2win.sh' maybe behavior is different
Click to expand...
Click to collapse
So what I did now:
Reset the device, without rebooting make a backup:
I still creates 7 files 12 gigs in total.
The are, as expected, seemingly completely empty, apart from the first 512 Bytes, allthough even those are empty in files 4-7.
The first 8 bytes are always the same, both in the empty and the real backup, if the first 512 exist at all.
Here are the first 512 bytes from the first file of the empty backup:
Code:
AB EF CA 9C B0 C5 4A 0A 38 3D BE C5 5E 4F B5 ED DB 14 73 B2 5C 52 64 1B FA 57 83 A1 6A 63 BF 7A 81 4F AF 09 8D 90 07 18 D6 00 68 0B 94 80 62 62 70 4E 35 8E 28 35 2A 65 63 8D 60 6C E6 1B BF 84 22 DC 8D 22 FF BE FA D8 40 A5 37 01 14 DA 80 C0 92 4A 41 24 EA 80 F6 B3 4B 2C 45 A1 17 99 E0 2D DF F5 7E 9D 10 3B 39 DD FE 1E 48 D4 A8 24 81 B4 E1 91 55 BC 2B 80 7D 9E 1B 1C 82 C5 BD 98 59 66 FF 07 00 1E 4F 41 0B 87 4F 17 CC C4 12 2A 50 1E 70 2F 96 61 09 EF 37 B6 A3 7C 01 9C 09 49 D5 0E 98 91 EB 68 09 FE 51 6D D1 7C 4A 15 02 FF 12 5B B2 CA 31 FD 9F 07 8E 26 FA 56 72 F7 BD 55 85 BB F6 F7 59 8C 11 54 B4 E8 04 3E 10 41 B9 32 54 19 A8 BF 0C 5B 40 5D 37 72 68 BA 46 2A E5 C6 98 28 C1 79 DD F6 8E 8F AD 75 43 BA DA 1B 48 DD B9 F8 AB BC 02 6E E3 62 E5 C8 E2 20 60 43 D9 C5 47 E4 81 04 13 A9 04 8C 1E B3 0B 9D 59 B7 D4 CF A9 2F D9 96 93 BA 02 F9 A8 4E D5 FD 7A B2 74 E4 DB 9C 8B 4C 94 CF CD 61 C6 98 E7 88 B7 51 79 E9 0B FB B2 DE 63 66 A5 08 44 24 CE 76 E2 F2 7D 16 80 DA BF 3E F4 58 B3 8C 76 83 62 ED 40 CC 73 6C 28 B8 C7 78 65 8E 11 BB 8D B7 64 4B 66 B7 32 F8 88 14 BB 54 17 D0 52 3D 5A 47 B8 06 D8 00 94 7C 0B FF 7B 07 6E 4A B7 23 A9 6E 91 BB FE 6F 61 C8 0B C5 B3 E9 96 FB 9F 21 33 F8 BF 0A 9A C7 3E ED 31 B5 F5 66 BD 12 1D E9 1F D7 B2 DA 2E FC 3C 22 F4 F4 B6 10 10 BA 7E 9A 41 76 B0 43 91 DE 2E 31 64 59 DD 1E A5 5D 20 D9 5E 17 78 59 12 35 66 35 3A E6 7B 67 D5 64 D7 93 9C F4 01 47 6C 0F 92 4D 45 F9 B8 34 81 0A EA 47 1A 6C 4D 68 C1 6E A0 6C DE 7D 3E 33 06 82 D2 BF 05 82 5D 0E CF 5B E3 15 98 BB 51 98 79 A2 05 8F 7B BC 70 D1 76 35 67 A8 A0 EF
Is there any chance left?
no there is nothing you can do. what does the script say to empty backup? does it mount ext4 image?
So I had to take a few days off, but I ran the script on the empty backup.
It does mount it as a ext4 image. But I can't find the folder it mounted it to.