Flashing GT-S5570 from brick to stock firmware

Post describes unbrick procedure for GT-S5570 phone. Former user tried to flash Samsung Galaxy Mini with ROM manager but he didn’t read warnings about unsupported devices. His flash attempt has resulted with hard bricked phone. I managed to unbrick the phone and install stock Gingerbread for my region (Croatia) but must say that it was not so easy.

if you don’t own RiffBox (or similar JTAG hardware), please don’t do any of steps from this post!

First step is disassembling the phone and soldering wires on motherboard (tiny JTAG pads are placed in the middle of motherboard). RiffBox detected “dead body” and flashed boot loader. After resurrection was completed, phone is switched to download mode and connected via USB to Odin. I have selected ARM11boot_GT-S5570.tar to BOOT field and start flashing. It was ended in a second and phone rebooted to Froyo 2.2.1. My goal is Android 2.3.6 so I downloaded latest stock ROM for Croatia (CRGKT1) and continue this procedure:


This ROM comes as one package so firmware upgrading is very simple – check “one package” checkbox, select OPS file and select tar.md5 file from the local disk (don’t forget to unzip downloaded firmware). Flashing this CRGKT1 firmware on top of the Froyo 2.2. went without problem but problem appears after reboot. Home screen without background image and application icons displayed some “java wizard” error in popup. Click on power button gave me option to turn off the phone. I thought that wiping cache in recovery mode will solve the problem. Unfortunately, pressing HOME + POWER buttons did not switch the phone to recovery mode. Instead, phone was stuck with displayed Samsung logo. Current situation was not so happy after trying to upgrade from Froyo 2.2.1 to Gingenread 2.3.6. I take a deep breath and try to flash CRGKT1 once again. This time I got “ONW UPDATE FAIL” error:

Name  : cache
Start : 1888
Num   : 116
ID    : 24
Attr  : 0x00001101
samsung_bml_format FAIL: 90220000

As I wrote in my previous post Flashing GT-S5570 from brick to CyanogenMod, in case of “ONW UPDATE FAIL” error it’s needed to flash ARM11boot_GT-S5570.tar to continue flashing Gingerbread ROM. Once again, please be very careful with flashing boot loader because it can hard brick your phone. Here is list of my hard brick cases with ARM11boot_GT-S5570.tar during this recovery session:

  1. I have prepared custom firmware package with files from CRGKT1 + data.rfs from JVKT1 but files in tar.md5 were placed inside directory. Odin stopped flashing at the beginning with displayed error. Right after I flashed ARM11boot_GT-S5570.tar and the phone was hard bricked.
  2. Samsung Galaxy Mini was not able to boot to the stock recovery so I flashed CWM, reboot to the ClockworkMod and wipe cache, data, Dalvik cache and formated “/system” partition. Next I flashed ARM11boot_GT-S5570.tar and phone was hard bricked.
  3. I prepared custom package with CSC from CRGKT1 package and flash only CSC. After that phone booted only to stock recovery. I tried to flash APBOOT from S5570XWKT2 firmware but I got “ONW UPDATE FAIL” error. I flashed ARM11boot_GT-S5570.tar and phone was hard bricked.

OK let’s back to the main thread where “ONW UPDATE FAIL” error was displayed on the phone screen. Phone was switched to download mode and flashed ARM11boot_GT-S5570.tar file. Next, I switched phone to download mode again and flashed CRGKT1 firmware without any error. After reboot, phone was in bootloop – samsung logo, animation, samsung logo … After digging on XDA, I found post where was explained difference between one package firmware and multi package firmware for S5570. The key was in data.rfs file.

RFS - Robust File System, a journaled enhancement of the File Allocation Table disk

One package firmware didn’t contain data.rfs so I tried to create custom package with all files from CRGKT1 + data.rfs from CODE_S5570JVKT1_CL703231_REV02_user_low_true.tar.md5. Here is list of commands how CRGKT1 firmware was repacked (files from CODE tar.md5 file were already unpacked in /tmp directory):

# create empty directory
> mkdir dbunic11

# enter to newly created directory
> cd dbunic11

# unpack all files in dbunic11 directory from CRGKT1 firmware
> tar xf /tmp/S5570XWKT7_S5570XWKT3_S5570CRGKT1_HOME.tar.md5

# add data.rfs file unpacked from JVKT1 firmware
> cp /tmp/data.rfs .

# create new package dbunic11.tar firmware in /tmp directory
> tar cf /tmp/dbunic11.tar *

# go to /tmp directory
> cd /tmp

# create md5 sign and append to the file end
> md5sum -t dbunic11.tar >> dbunic11.tar

# rename tar file to tar.md5
> mv dbunic11.tar dbunic11.tar.md5

# show all files inside tar.md5 package
> tar tpvf dbunic11.tar.md5
-rw-rw-rw- root/root  18808832 2011-11-17 13:10 amss
-rw-rw-rw- root/root    466192 2011-12-06 10:43 arm11boot
-rw-rw-rw- root/root   6455296 2011-12-06 10:43 boot.img
-rw-rw-rw- root/root  19427328 2011-12-13 11:23 csc.rfs
-rwxr-xr-x root/root   5033984 2012-12-26 19:24 data.rfs
-rw-rw-rw- root/root    786432 2011-12-06 11:11 mibib
-rw-rw-rw- root/root    566352 2011-12-06 11:11 oemsbl
-rw-rw-rw- root/root    368640 2011-12-06 11:11 qcsbl
-rw-rw-rw- root/root   6864896 2011-12-06 10:43 recovery.img
-rw-rw-rw- root/root 205430784 2011-12-06 10:42 system.rfs

With above described procedure, dbunic11.tar.md5 package was ready for flashing. However, before flashing Gingerbread ROM on top of already installed Gingerbread ROM, ARM11boot_GT-S5570.tar file should be flashed first to prevent “ONW UPDATE FAIL” error. So, after flashing dbunic11.tar.md5 as one package, phone normally booted (with boot sound). Added data.rfs file in the package has solved bootloop problem but phone was still not possible to boot in recovery mode (therefore localization files from CSC were not applied also).

From previous case (post), I knew that flashing CWM will allow boot into CWM recovery. Main idea is to have full stock ROM, so combination of stock ROM and CWM is not exactly the brightest but it will be tolerated for now. With switching to CWM recovery mode I thought that wiping caches will trigger or finish localization (support for Croatian language and keyboard layout).

CWM installation is easy. tass-recovery-cwm.tar is selected as one package and phone was booted into recovery. Now I could wipe cache, wipe data / factory reset and wipe Dalvik cache. Guess what? This has returned loop back error again. Custom dbunic11.tar.md5 can be installed but wiping data will result with bootloop. Anyway, CODE package from JVKT1 firmware contains data.rfs and flashing only CODE part could solve emergent bootloop. Here is list of files in CODE_S5570JVKT1_CL703231_REV02_user_low_true.tar.md5 file:

-rw-r--r-- 1 dbunic dbunic   6455296 Stu  2  2011 boot.img
-rwxr-xr-x 1 dbunic dbunic   5033984 Stu  2  2011 data.rfs
-rw-r--r-- 1 dbunic dbunic   6864896 Stu  2  2011 recovery.img
-rwxr-xr-x 1 dbunic dbunic 202907648 Stu  2  2011 system.rfs

Flashing anything but bootloader is safe so I selected TASS_v1.0.ops in OPS and CODE in PDA and start flashing with Odin. Because of system.rfs (the biggest part) this will last for about 2-4 minutes. After flashing finished, phone was boot normal and it was possible to enter to stock recovery mode. It seems that flashing only PDA part tweaks phone flags and somehow enables entering to recovery mode. I’m not 100% sure about this so any comment or explanation is more than welcome.

And phone still didn’t have Croatian keyboard layout. All localizations are placed in csc.rfs. Here is listed csc.rfs content and command

# csc.rfs content

# command

… content of sec_csc.zip

> unzip -l sec_csc.zip

Archive:  sec_csc.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  12-13-2011 19:23   META-INF/
       71  12-13-2011 19:23   META-INF/MANIFEST.MF
     1714  12-13-2011 19:23   META-INF/CERT.RSA
        0  12-13-2011 19:23   META-INF/com/
        0  12-13-2011 19:23   META-INF/com/google/
        0  12-13-2011 19:23   META-INF/com/google/android/
     1797  12-13-2011 19:23   META-INF/com/google/android/updater-script
   150256  12-13-2011 19:23   META-INF/com/google/android/update-binary
    42021  12-13-2011 19:23   META-INF/CERT.SF
        0  12-13-2011 19:23   system/
        0  12-13-2011 19:23   system/lib/
   708020  12-13-2011 19:23   system/lib/libSwypeCore.so
      357  12-13-2011 19:23   system/SW_Configuration.xml
       12  12-13-2011 19:23   system/CSCVersion.txt
        0  12-13-2011 19:23   system/T9DB/
   198420  12-13-2011 19:23   system/T9DB/Samsung_400_SRlsUN_xt9.ldb
     1582  12-13-2011 19:23   system/T9DB/phonepad_sl.kdb
     1570  12-13-2011 19:23   system/T9DB/phonepad_da.kdb
     1514  12-13-2011 19:23   system/T9DB/phonepad_en.kdb
    11892  12-13-2011 19:23   system/T9DB/qwerty_hr.kdb
      322  12-13-2011 19:23   system/T9DB/phonepad_ko.kdb
      613  12-13-2011 19:23   system/T9DB/qwerty_sr.kdb
   155914  12-13-2011 19:23   system/T9DB/Samsung_400_DAlsUN.ldb
   220870  12-13-2011 19:23   system/T9DB/Samsung_400_SLlsUN_xt9.ldb
     1538  12-13-2011 19:23   system/T9DB/phonepad_fi.kdb
      597  12-13-2011 19:23   system/T9DB/qwerty_ro.kdb
     1602  12-13-2011 19:23   system/T9DB/phonepad_fr.kdb
    11840  12-13-2011 19:23   system/T9DB/qwerty_fr.kdb
   132541  12-13-2011 19:23   system/T9DB/Samsung_400_NLlsUN_xt9.ldb
    98056  12-13-2011 19:23   system/T9DB/Samsung_400_ENubUN_xt9.ldb
    11796  12-13-2011 19:23   system/T9DB/qwerty_en.kdb
   377450  12-13-2011 19:23   system/T9DB/Samsung_400_BGlsUN_xt9.ldb
   144958  12-13-2011 19:23   system/T9DB/Samsung_400_SVusUN_xt9.ldb
      365  12-13-2011 19:23   system/T9DB/phonepad_no.kdb
   159734  12-13-2011 19:23   system/T9DB/Samsung_400_NOlsUN.ldb
    11884  12-13-2011 19:23   system/T9DB/qwerty_nl.kdb
      359  12-13-2011 19:23   system/T9DB/phonepad_bg.kdb
      395  12-13-2011 19:23   system/T9DB/phonepad_sr.kdb
      648  12-13-2011 19:23   system/T9DB/qwerty_da.kdb
   163899  12-13-2011 19:23   system/T9DB/Samsung_400_ROlsUN_xt9.ldb
   132027  12-13-2011 19:23   system/T9DB/Samsung_400_DEusUN_xt9.ldb
     1538  12-13-2011 19:23   system/T9DB/phonepad_sv.kdb
     1610  12-13-2011 19:23   system/T9DB/phonepad_hr.kdb
      632  12-13-2011 19:23   system/T9DB/qwerty_sv.kdb
      599  12-13-2011 19:23   system/T9DB/qwerty_sl.kdb
      648  12-13-2011 19:23   system/T9DB/qwerty_no.kdb
   346934  12-13-2011 19:23   system/T9DB/Samsung_400_FIlsUN_xt9.ldb
   204801  12-13-2011 19:23   system/T9DB/Samsung_400_HRlsUN_xt9.ldb
      632  12-13-2011 19:23   system/T9DB/qwerty_fi.kdb
     1546  12-13-2011 19:23   system/T9DB/phonepad_de.kdb
      391  12-13-2011 19:23   system/T9DB/phonepad_nl.kdb
      750  12-13-2011 19:23   system/T9DB/qwerty_ko.kdb
     1578  12-13-2011 19:23   system/T9DB/phonepad_ro.kdb
      667  12-13-2011 19:23   system/T9DB/qwerty_bg.kdb
    11828  12-13-2011 19:23   system/T9DB/qwerty_de.kdb
   117129  12-13-2011 19:23   system/T9DB/Samsung_400_FRlsUN_xt9s.ldb
        0  12-13-2011 19:23   system/app/
  5011505  12-13-2011 19:23   system/app/T-Wisepilot.apk
 11233444  12-13-2011 19:23   system/app/Swype.apk
        0  12-13-2011 19:23   system/csc/
     5126  12-13-2011 19:23   system/csc/customer.xml
     5120  12-13-2011 19:23   system/csc/contents.db
      300  12-13-2011 19:23   system/csc/others.xml
        4  12-13-2011 19:23   system/csc/sales_code.dat
     1524  12-13-2011 19:23   system/CSCFiles.txt
---------                     -------
 19694940                     65 files

All this indicates that flashing only CSC and rebooting to stock recovery should finally install/place localization files to system partition. So I prepared package only with csc.rfs file (the procedure is similar to dbunic11.tar.md5) from CRGKT1 firmware and flash dbunic_csc.tar.md5 as one package. After reboot, phone entered to stock recovery and I could see how sec_csc.zip file was automatically unzipped (installed) and phone reboots again. This was very close to success, but phone boots only to recovery. Somewhere I read that flashing bootloader shoud fix this problem so I selected APBOOT file from JVKT1 firmware, start flashing and got “ONW UPDATE FAIL” error. As I saw this error many times, I switch phone to download mode, flash ARM11boot_GT-S5570.tar file and phone was hard bricked – doh!.

Luckily I have RiffBox, and S5570 was resurrected again. This time flashing APBOOT from JVKT1 package was successful. With this step, all problems where fixed. Phone boots normally (no bootloop), it is possible to boot to stock recovery, it is possible to wipe data / factory reset, Croatian keyboard layout is present. Here are main steps how to recovery (ubrick) S5570 to stock ROM for next time:

  1. resurrection with RiffBox
  2. flash CRGKT1 (last Croatian) firmware as one package – phone will have bootloop but this will install S5570XWKT3 baseband
  3. flash CODE_S5570JVKT1_CL703231_REV02_user_low_true.tar.md5 as PDA – this should fix bootloop and enable entering to stock recovery
  4. flash custom CSC file dbunic_csc.tar.md5 from CRGKT1 firmware – after that, phone will boot only to stock recovery
  5. resurrect with RiffBox again
  6. flash APBOOT_S5570JVKT1_CL703231_REV02_user_low_true.tar.md5 from JVKT1 firmware

Maybe I missed something or steps are not performed in right order but I still have no answer to the following questions:

  • Why after flashing all files from JVKT1 firmware is not possible to enter to stock recovery?
  • Why after flashing custom CSC file phone boots only to stock recovery?

Well, this post is quite long but I wanted to note all the facts that happened during recovery process. Hope some info will be useful and help to prevent bricking more Samsung Galaxy Mini devices.

At the end, I will try to summarize this post in a few notes:

  • flashing CRGKT1 (one package firmware) will result with bootloop (because CRGKT1 package doesn’t contain data.rfs)
  • CRGKT1 firmware can be repackaged with data.rfs and after flashing such package, phone will not have bootloop problem
  • phone flashed with CRGKT1 + data.rfs package will have bootloop after wiping data
  • flashing CRGKT1 firmware and only PDA from JVKT1 will resolve bootloop and enable entering to the stock recovery
  • flashing only CSC will cause booting phone to recovery mode (phone will not be able to normal boot)
  • flashing APBOOT from JVKT1 after previous step (to fix booting only to recovery) will result with “ONW UPDATE FAIL” error
  • flashing ARM11boot_GT-S5570.tar file to fix “ONW UPDATE FAIL” error after phone boots only to recovery will result with hard brick
  • finally, after resurrection with RiffBox (again) and flashing APBOOT from JVKT1 bundle, S5570 recovery process was happily finished :)

8 thoughts on “Flashing GT-S5570 from brick to stock firmware

  1. hi man i did what said in step 1 but after flashing ARM11boot_GT-S5570.tar my phone has ablack screen now and won’t go to download mode so please help

  2. @na – Well, if phone screen is black and it doesn’t react on any key combination then I have a bad news – your phone diagnosis is hardbrick. Hope you have a RiffBox or similar JTAG hardware (as is described in this post) to recover boot loader. In this phone state, it’s impossible to fix the phone without disassembling and soldering connector to JTAG pads (phone is not permanently damaged, just bootloader is messed up). If you don’t have any JTAG box, the best option is the nearest service to fix it for you.

    In this post I wrote several ways of how my S5570 was bricked. Fortunately, boot loader was fixed with RiffBox (JTAG connector was all the time connected to the motherboard just for any case).

  3. Hi. I brick my device and performed the first step by flashing arm11boot then my device is bootloop – samsung logo as you wrote. I’m using one package firmware that does not contain data.rfs. My doubt is how did you created data.rfs? I don’t know how to create a custom firmware package. Is there anywhere that I can download it then put it in my rom? Or how to create it? Could you clarify that black hole of my knowledge? Thank you and congratulation for your post.

  4. @SamBR – First a big caution! In my case I was able to play with GT-S5570 phone because I have backup option – JTAG box to fix boot loader in case of “hard brick”. As you can read, this phone was hardbricked several times because of my wrong steps. If that happened, then you can’t go any further without phone disassembling and soldering JTAG connector to the phone’s motherboard.

    So, one file package doesn’t contain data.rfs file and this can cause bootloop. Please read post very carefully and you will find how is possible to repackage (actually I tried to use data.rfs from other package). If you don’t have Linux skills regarding basic commands like “tar” tool, better stop. Generally speaking, this post/procedure is intended for experienced users otherwise it can lead to hard bricked device.

  5. Thx for your guide here..but its too late for me to read this,i’m bricked my phone totally..hard bricked i think,doesnt have JTAG hardware with me,and i’m not experianced skill in this,so i’m gonna to send my phone to nearest phone shop to get repair to samsung…thx

  6. I am sorry to hear that. Hope your phone will be repaired and it will serve you good as before.

  7. hi,as you said,,, i also get samsung_bml_format FAIL: 90220000
    then the problem began ..after that i used arm…tar but in the finishing period it went on lighting black screen and never went to download mode.. but odin detects it in apx mode . and while charging it does lighting with black screen .what to do

  8. @faisal – It seems that your phone still shows some signs of life – means it’s not still hard bricked. If you have JTAG box then you can try with flashing ARM11boot_GT-S5570.tar otherwise you can end with totally dead phone. In my post you can read experience with recovering that might be helpful for your case.

    Guys, this post is published only as information and to show my way how phone is recovered. As I don’t own this phone any more, I can’t respond with some quality reply – only with general advises. So, with this in mind, comments for this post will be closed. Cheers!

Comments are closed.