yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Mini] stepph:
I got it yesterday... with a russian gingerbread FW (who knows where it was downloaded :D ), but without radio FW, and shutting down every minute...

... The guy of the service was not so able... and he doesn't work with 'official' FW... I have to take the phone back to him - for warranty at least.

I'm tempted to do it by myself - but if EFS is gone ?

Meanwhile, i'm working with androidx86 - a porting for PC - on a virtual machine... it seems great for testing some mods on /system - but kernel, executables, and libraries are recompiled...

And i'm tryng revskill - in order to understand AMSS - the free version seem good... but is limited...

If i get some new results, i'll post it...

(interested in matlab scripts for codig/decoding RLE logos ?)
[Samsung Galaxy Mini] Akath19:
Download the official Euro FW via checkfusdownloader and flash it through ODIN, those FWs come directly from Samsung servers so you shouldn't have a problem.

I checked out that port but I didn't quite like it (too slow for my taste).

What's revskill (forgive my ignorance)

Meanwhile I'm looking into porting voodoo kernel (from SGS) into our minis, mainly to get better audio support through voodoo sound.

(Ewww, I hate matlab!!)
[Samsung Galaxy Mini] stepph:
just tried...ODIN reported success, but now the phone does'nt boot anymore... :(
[Samsung Galaxy Mini] roofrider:
just popped in to say u guys are doing great!!

Thankx :)
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Hi everybody, I'm really new to this forum and this is my first reply too, but let me try:

I found that official firmwares are usually partial... That is: you can Odin-flash them only over same base firmware or you need two steps: a full firmware followed by its partial same_base update.

Let me know.

PS. Great topic ... Magic!
[Samsung Galaxy Mini] yagya:
If you are on a boot loop ...

Go to REcovery and wipe data and cache....

Else, flash the firmware again --also try with different firmwares, sometime one works the the other doesn't ---

:)

ANd what you guyz are doing is great... Keep the good work up and that's how you will learn.... It would have been better if someone knowledgeable would come and guide you. Anyway, good luck!!! :)
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Dumped Images - my experience...

Starting from [post 8]

I own a branded GT-S5570 (Italy Wind -> code WIN ) and I just upgraded from Stock Froyo 2.2.1 to Stock Gingerbread 2.3.4.

In the meanwhile I also kept a copy of the archive used to, with these images inside:

amss

arm11boot

boot.img

csc.rfs

mibib

oemsbl

qcsbl

recovery.img

system.rfs

After the dump of several bml devices and an stl one I obtained these files:

bml4-amss

bml7-arm11boot

bml8-boot.img

- - -

bml1-mibib

bml3-oemsbl

bml2-qcsbl

bml9-recovery.img

stl12-system.rfs

All but the former csc.rfs (related to stl5? ...I don't know but I just stayed far from it...)

A quick compare show me that the size is different: dumps are always bigger then stock-upgrades, but, after trimming to the same size, a "bit2bit comparison" told me that they are

Exactly the Same! :cool:​

That is: from my rooted phone I should be able to backup the whole firmware except "csc.rfs" in a flashable manner directly dumping these devices...

P.S. Actually system.rfs is not really the same, but I heavily worked on it immediately after stock upgrade, so I bet - anyway - they should match each other.
[Samsung Galaxy Mini] stepph:
Thank for suggestions !!

I dunno what a boot loop is - the phone going on and off 4ever ? is not my case. I cant access to recovery ... and i tried two official FW...

As Doc_cheilvenerdi.org suppose, the 'check fus' downloaded fw was partial - only amss boot recovery and csc - When i donloaded the last version from samfirmware, i got a complete FW, with all the components, and it works...

...more precisely, i get the phone working, with the same defect than before - shutting down, no radio, no gsm, mot even store data and time... I bring it back to service, since i DO have warranty, and they broke it, with an unofficial fw :-)

I know that EFS partition is corrupted ...since odin (official but internal samsung tool) have a efs slot, i think that someone inside samsung knows how to flash that.

Now, this bring up some questions:

-- why a incomplete FW does not work ?

-- what are the dependencies between the parts ?

-- how can i modify some parts being sure that it works ?

-- can i transform my dump into a flashable fw ?

-- are all the chek-fus-dowloaded fw incomplete ?

-- what 'base' complete fw should one use as base for check-fus?

I'll look for chek-fus forum/author and ask him (seem to me that he make an automatic download and decrypt of samsumg official fw releaseing server).

Still, i plan to compare the different download FW, in order to get the differencies (simple for boot recovery system and csc, that i know how to explode... but the others ? someone skilled to open the door is needed)

From my side, if some valuable result will arrive, i'll post ...

thanks again...

as above, as in the 3d title, someone skilled - to open the door - is needed !!
[Samsung Galaxy Mini] stepph:
You Really Do A Great work !!!

As i expected - was the same result i get - the code is padded to fit the partition size - and you can also check this with the bml0/c dump that should be the merge of all the partitions.

(i wonder if these sizes are fixed -in HW, or in FW- since on other devices they can be changed)

as for CSC - no, it is not related to STL5. In the same way of system.rfs, CSC.rfs it is a RFS (Robust FAT File System) - a filesystem of samsung devices.

I tried - as suggest elsewhere in the forum - to open them with MagicISO or mount via loop in linux, and since it is fat compatible, it is readable ( i don't even try to write...who knows?).

In CSC.rfs, you'll find a simple command file - a text file - and an update.zip.

When - after the flash - the phone reboot, the update.zip is automatically execute (this was the role of command i suppose). This update.zip - you can normally open it and check) give the carrier customization of the device.

In your case - you shoul have the WIND CSC, installing the italian T9, the correct APN for your data connection, and probably some inital logos and apps/widget.

Since CSC has not a partition, i think that it is not flashed , but added to system partition and then deleted (mmm...:confused:).

Another idea is the FOTA (Firmware Over The Air - i.e. the updates distributed directly by the carriers) partition, that could be use for such updates.

For STL5, since inside it many founds lock codes, and/or lost their IMEI, i think that it contains some codes for the radio to work proprerly... many told of a EFS filesystem that can be copied, mounted, with files that can be examined. it can be since it is a rfs file ... but i don't have any success doing this.

------------------------------------------------------------------------

Since you have a Stock Italian GB, would you share it with us ???

If you look in italian forums, stock IT roms are needed !!

...e sarebbe utile anche a me...

< ... i also need it ...>

Grazie !!
[Samsung Galaxy Mini] stepph:
About the BML/STL/RFS reading ....

As the attached scheme descibes - a snapshot of a doc from the repositery thread -

-- RFS (Robust FAT File System) is FAT compatible file system mounted by the linux kernel in /system, /data, /cache, (and /efs form some other devices). 'Robust' refer to recovery from unexpected shut down...

-- STL is the layer - with fast read/write support - on which RFS

is memorized. It perform 'wear levelling' and FTL (Flash Translation Layer - mapping between logical addresses and physical addresses), so R/W ops on the same logical address are not directed to the same physical/virtual address.

-- BML is the layer that trasforms an athomic memory ops - from above - in a operation on nand memory... (i see some other low level drives...).

So...

If I have a RFS image - as in downloaded FW - i have access to the files monted during the boot process.

If i dump a STL device, I access to the memory where RFS is stored - i'll have the same bits, but padded to fill the size of this part of the memory.

If I dump a BML device, i get a map of the physical(virtual) memory. I'll not see that some sector are ignored when BAD (this info is below BML). But i'll see if a R/W operation moves some adresses from here to there.

So...If i use the BML image to get the RFS filesystem...

If in this partition a r/w operation occured, i'll found that some blocks are not in the correct order. I'll found inconsistencies when reading this as RFS.

That's why i cannot read the data and cache - frequently R/W - BML dump.

That's why i cannot found in BML dumped system the r/w operation i made.

That's why a BML dump in not feasible to backup/restore STL partitions (a warning should be made to those backupping BML5).

Since a first R/W operation occurs with CSC after a flash, also a non-rooted stock BML12 (system) dump could be different from original RFS.

That's why samsung distribute systems.rfs and not STL12 or BML12.

------------------------------------------------------------

i don't know if i was clear enough... do you agree ? or all that writings are a lot of nonsense ?
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Actually - Google Thanks to Luffarjoh (CheckFUSDownloader) - we are talking at androidworld.it (thread 29764) about Stock GB Italian Wind, Tim and, maybe, H3g [SOLVED and shared nearby]... still waiting for GB NoBrand but We're just trying to complete Stock Froyo (androidworld.it thread 30279) following this great Idea of yours! (Italian threads, but I may translate to English if needed)

Loud and clear! Full Agree: leaving stock system.rfs "as is", working on csc.rfs!

GT-S5570 on Train...

P.S. Sorry but no out-links yet, due to spam prevention.
[Samsung Galaxy Mini] Akath19:
I also noticed that some of the CheckFus FWs are only partial, some don't include the baseband which is the basis for everything.

@Stepph, I'm not completely sure but I think your problems are due to radio errors (baseband again), so I'd check with someone else who has your carrier phone and check which baseband are they using, although if you flashed an unbranded euro ROM (baseband KPK) you should be able to get everything up and running.

@Doc, I also did some very basic exploration of the partitions (barely documented here) and found most of what you said, I thought that RFS was ReiserFS, which is a FAT compatible journaled FS, guess I was wrong.

I don't think CSC is flashable due to the fact that it depends on both a data and a system partition (CSC is just carrier customization).

I remember that I mounted my STL5 once in order to get the unlock codes, I'll try to do it again today and update you with what I find
[Samsung Galaxy Mini] stepph:
If you work on RFS you shoul have no problem, since thei are at upper level.

Only pay attention when getting *.rfs from BML dump.

CSC has more ploblem, since the update.zip has to be signed...

In every case, the only way i know to write a RFS is on the device itself...(i found some source code, but i'm not so skilled to make a tool).

If you have modified your /system folder, you can dd stl12 end then check if the dumped one - once extracted - reflects the changes...
[Samsung Galaxy Mini] stepph:
Surely i have problem with baseband, on device info, that field is blank !!!

but since i use a samfirmware complete FW, i think of a correct FW, with corrupted EFS, thus not enabling the baseband module.

On the other hand, my point is that the service center MUST solve my problem...

I started from there ;)

tried, but didnt, work... so i'm exploring this samsug proprietary fs...

if interested, there is a 3d with all the 'public' documentation...

CSC shoul be very similar to update.zip (official, not CWM) , with no flash or odin involved...

Waitng for your test ...
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
MeanWhile: boot.img issue

I just tried to unpack, edit and repack boot.img for my S5570 Brand Wind...

Unpack - OK (used either split_bootimg and mytools - related threads on this forum - even handy mode... dd if=...)...

Edit - Ok (changed Italian "next" logo to European "mini" one, few tweaks inside init.rc, ...)

Repack Ok (OK? strange behaviour? I'll explain later on)

Create Odin PDA Package with md5 sign - OK

Flash - OK

Boot - Failure :(

Reflash Original boot.img - OK

Boot - OK

Repeat from beginning - Always Failure :( :(

I repeated these operation several times playing around with ramdisk and cmdline parameters (blind way? maybe... inside phone /proc/config.gz I found copy of the default cmdline)

Always Boot Failure: Phone freezes showing first samsung logo... need to remove battery to switchoff and reflash... repeat

This is the strange behavior found:

When "Unpacking" several times, archives never differ (normal behavior)

When "repacking" ramdisk several times (without changing anything), archives always differ (strange behavior).

The command I used, from inside ramdisk folder, is this one:

$ find . | cpio -o -H newc | gzip > ../NEW-WIN-ramdisk.cpio.gz
$

My system Is a Linux Box amd64 no-multilib with a 32bit chroot environment...

Files always differ (64Bit environment... 32bit... doesn't matter)... even the "mkbootfs" command found on this forum showed same trouble...

Investigating! :confused:
[Samsung Galaxy Mini] stepph:
You can focus your investigation on:

- gzip compression ?

- alignment to page boundaries

- there is a (one or more) sort of checksum (SHA?) in android header (and some others data - i found arm11boot size in it !! ) ..

- there is an android sdk tool (mkbootimage ?) with sources to try (not badly cloned ones).

- many reports direct links between kernel and ramdisk, so they cannot be developed in a separate way (but how ??)

- try working ( adb shell ) on the phone and not on PC for compress/decompress (so to use same binaries)

About the logo (TASS.RLE the original, TASS-HUI.RLE the italian one...)... what is the first logo you see? if it is the image in ramdisk , and it appears... the fail is after the ramdisk boot (more info on samsung boot sequence needed ?!? )

How the italian FW load the modified TASS_HUI.RLE instead of TASS.RLE? in kernel ? maybe the kernel try to load an image you removed ?
[Samsung Galaxy Mini] stepph:
Examining the 'command' file in CSC, seem clear that CSC id dumped on /cache (stl14). Since it contains the 'recovery' folder, at boot I'll find

/cache/recovery/command

/cache/recovery/sec-csc.zip

Somwhere should be a way to exec 'command' file...

I don't know how it is launched, but could it be used for automatic installation of updates (without recovery) ??

Other notes:

- after the execution of update, these files are removed ?

- the csc.zip cointains the valid update.bin for updates...
[Samsung Galaxy Mini] stepph:
By comparing some dwld FW, I found (thk to Doc efforts, too) that:

- Froyo updates have only AMSS, system.rfs, csc.rfs, boot.img, recovery.img

- Froyo to Gingerbread updates have complete FWs - so the new version has different arm11boot, oemsbl, qcsbl (different boot-up methods?)

- MIBIB is almost unchanged - for the parts i know... but at offset 85010h i found - repeated 4 times with some extras zeros - the size of arm11boot partition (that is not aligned to page boundaries, i.e not multiple of 4096 = 1000h)

NOTE: dump of froyo arm11boot, oemsbl, qcsbl, mibib for some check fus FW incomplete release are needed to reconstruct exact FW distribution !!!
[Samsung Galaxy Mini] Akath19:
Are you sure about this, 'cause I believe that depends on the carriers (the FWs pulled by CheckFus are hosted by Samsung, but made by each carrier)

These updates need to have at least a different boot (due to underlying OS changes), besides different OS almost always (if not always) means different baseband, hence the need for a new arm11boot

I still don't get what MIBIB is or does

Can you create any of those files after the system has booted (through ADB), I believe these are prepackaged and cannot be recreated (that's why neither ODIN nor HEIMDALL can make backups)
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
After upgrade to Wind GB I saved copy of the Kies FW archive and I confirm that these dumps of mine, created as stated above, are all equal to prepackaged files plus garbage patterns to reach partitions size...

I prepared user defined packages too, flashed correctly via Odin...

GT-S5570 on Train
[Samsung Galaxy Mini] stepph:
not sure 100% - i didn't check it all, but so it is with all last available rom for europe i download (more than five - less than ten).

As Doc confirmed by testing (much risk for his own device - hit thanks to him ;) ) , the backup method here explained works. this is fine, since we (not CWM user) lack a stock backup method, and dowloadble FW are not the original ones.

Odin - tool for Samsung service centers - is not required to backup. Don't know heimdall, nor its story, never tried it.

[CWM do backups - in a way I do not know - see initial assumption.]
[Samsung Galaxy Mini] Akath19:
Why would you need the exact original FW, the system is supposed to (theoretically) work with unbranded ROMs the same way it works with branded ones

My phone was Colombian branded and it became unbranded after updating to GB, as long as your baseband is compatible with your carrier network everything should work just fine, unless there's physical damage.

Heimdall is a open source tool odin clone, but so far I think it only works on the Galaxy S variants, haven't tried it with a mini because I'm scared of breaking my only phone.

CWM is a Nandroid based recovery tool, so Nandroid does all the backup and restore functions, can't tell you exactly how Nandroid works (the code is not that easy to read, and it's here).

All I know is that Nandroid will backup/restore everything BUT the baseband, since that one needs to be flashed by Odin
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Back to Boot.img Investigation [SOLVED]!

Starting from beginning:

LINUX SIDE

I unpacked boot.img into header/kernel/ramdisk and repack it without changes, just to obtain the same archive...

Once somebody said somewhere : "When you know the answer (0x13600000) it's easy to state the question..." and this Time I really have to agree! Once found the trick, everywhere on the web you can read about it... eh eh...

Kernel and ramdisk are easily unpacked...say with the following name convention:

boot.img-kernel
boot.img-ramdisk.cpio.gz

While the last repack command I used was:

mkbootimg --kernel boot.img-kernel --ramdisk boot.img-ramdisk.cpio.gz --base 0x13600000 --pagesize 4096 -o NEW-boot.img

...and Files fully matched each other!!

You are pretty right:

I was simply (base hex mistake :() repacking with pagesize=2048 while it should be 4096...

and I found the base address for my kernel inside the compilation parameters stored in its /proc/config.gz:

CONFIG_PHYS_OFFSET=0x13600000

After that, I repeated the steps posted above, obtaining a new boot.img with different logos (both samsung and European/Italian ones) and tweaked init.rc.

Finally, even if there are several threads about it, here are the commands I used to prepare the Odin package:

My PDA Code is S5570XIKQC:

$ tar -H ustar -c boot.img > CODE_S5570XIKQC_boot.tar
$ md5sum -t CODE_S5570XIKQC_boot.tar >> CODE_S5570XIKQC_boot.tar
$ mv CODE_S5570XIKQC_boot.tar CODE_S5570XIKQC_boot.tar.md5
$

WINXP SIDE

Started Odin with usual .ops file and this archive in the PDA field...

...Start button, five seconds and "voilà":

Galaxy Mini (it was Galaxy Next) and system ready and waiting! :cool:​

Right! It detects "mini" device in download mode but cannot handshake any connection through usb interface. Actually, looking inside source code (BridgeManager.cpp), I think it could be an issue related to libusb protocol...anyway I'm just talking as an ant one parsec far from home...
[Samsung Galaxy Mini] Akath19:
Hey Doc, you could try asking Benjamin Dobell here @XDA about the libusb problem, although I don't think it'll change much since Heimdall isn't that much different than Odin.

I've got a question for both of you, I've been having the weirdest battery reporting errors since I bought my phone (percentages jumping, sometimes even as high as 25%), I was wondering if you knew which module does the battery reporting??

And before you ask I've calibrated my battery before a lot of times and I still have the same problem, I had it in stock Froyo, stock GB, Andro-ID, Tj's CM7 and squadzone's CM7
[Samsung Galaxy Mini] stepph:
I need a methods for backup my stock rom - warranty related issues...

Thank for the infos !! i'll look for those surces...

sorry, can't help with that...
[Samsung Galaxy Mini] stepph:
Great !! Wonderful Work!!

... and thanks for sharing ....

Just wondering about the memory mapping on our devices, on which you open a door...
[Samsung Galaxy Mini] Doc_cheilvenerdi.org:
Linux Behind Android - Both Win!

ext4 FileSystem and busybox!

I cloned the Android Open Source Project, I downloaded from Samsung Open Source Community the kernel+platform source for our GT-S5570, I downloaded the sourcery arm toolchain for Linux and I partially compiled the kernel 2.6.35.7...

From inside the kernel directory I prepared the S5570 environment (Linux Side):

$ make tass_rev02_defconfig
$

Then I selected the ext4 module via make menuconfig command, .config piece follows:

CONFIG_EXT4_FS=m
CONFIG_EXT4_FS_XATTR=y
CONFIG_JBD2=m

After that I changed the local uname for the compiled code to match the one used in my phone (Settings -> About Phone -> Kernel Version = 2.6.35.7-perf-CL561937- mandatory to let the Phone use external builded modules)

CONFIG_LOCALVERSION="-perf-CL561937"

After the compilation of the modules (no kernel core needed yet)

$ make modules
$

I was able to push the files

fs/ext4/ext4.ko

fs/jbd2/jbd2.ko

to the phone and to load them into the kernel "on the fly" (adb side):

# busybox insmod /sdcard/Temp/modules/jbd2.ko
# busybox insmod /sdcard/Temp/modules/ext4.ko
#

Finally (:cool:) I could mount and use a loop device "ext4 formatted"

# busybox mount -o loop -t ext4 /sdcard/Temp/data.ext4 /sdcard/Loop
#

All these lines of code can now surely be fixed in init.rc (figured out in previous post how to) and I can mount ext4 filesystem immediately at boot-up stage!

What next? Just Working on moving data filesystem (/dev/stl13) from Robust FileSystem to Fourth Extended one... on Stock ROM!
[Samsung Galaxy Mini] stepph:
Exellent !!

Probably you're ready to release a new customized ROM !!

may be useful to move dalvil-cache in /cache (to wipe it from recovery menu) ?

About ext4 & RFS ... take note of the wear leveling issue, on a R/W partition like /data you shoul preserve it - save the lifespan of your device. Check where it is implemented - should be in BML level, but to be sure...

Or it can be moved to SD (fat or ext4) ... timig issues ?

About RFS, i found some sources - tried to compile - for R/W access from PC - but not so skilled... and too busy with work now...

If you want to give at look, let me know (you can find it online, there are from a Samsung TV).

I want to implement down to BML level, in order to mount the dump we made, in case it differs from origianl RFS. At bottom of RFS (stl devices) shoul be XFR(BML device) and NAND Low level drivers... but no real NAND HW, so a kind of emulation / loopmount should occurs...

... i'll get back to play with my SGM in a week...
[Samsung Galaxy Mini] darkfable:
sapete per caso come rimediare ad una perdita di imei in seguito al stl5 unlock? grazie mille!

Do you know how to restore imei after stl5 unlock? thanks
[Samsung Galaxy Mini] stepph:
l'ho portato in assistenza dice che mi daranno un nuovo terminale ... :-)

<service center, they'll promise me a new one...>
[Samsung Galaxy Mini] aleks20:
i have the same version of firmware on my telephone. Can you compile tun.ko
[Samsung Galaxy Mini] aleks20:
I compile tun.ko for Samsung Galaxy mini 2.3.4 CL561937

for me working ok.

Regards