Develop Bugs

Your own logo.img in param.lfs

Hello,
I wanna share some information about param.lfs. As some people I tried to study this file. I tried to port j4fs driver to linux, but with no success yet.
But I have something. For those ROM-makers who want to insert their own logo right in the file for flashing it as a part of a ROM you can do the following:
1. Prepare your jpeg file, process it through jpeg optimizer (like xat.com JPEG optimizer). Size must not exceed 3FD1(HEX), or 16337Bytes. 480x800, 72dpi
2. Load this file (jpeg) in a HEX editor (WinHex) and copy it as a block
3. Load param.lfs
4. Overwrite two blocks in param.lfs by your image (just paste block in overwrite mode). First one - from offset B4000, second one - from 7F000. To double check - overwritten blocks should start with FF D8
That's all. Tar param.lfs as it used to do: tar -H ustar -с param.lfs > param.tar
and flash it via odin as PDA, or add to firmware then. You will obtain your own logo.jpg and logo_kor.jpg in /mnt/.lfs
So, you don't need to use special scripts to change splash-screen (mount .lfs and copy your logo.img into it). It will work with any kernel. Even on stock firmware you may have your own bootlogo.
Caution: Be careful. If you make something wrong, phone won't boot, because param.lfs is used by bootloader. At least /mnt/.lfs will be empty.
You may have black screen. Anyway you will be able to enter in 3-button mode to flash stock param.lfs back.
Of course that won't change bootlogo with yellow triangle because it "resides" in sbl.bin and very dangerous to be changed.
P.S. I was going to write a patch script, but decided not to do that.
Cheers

As a newbye, I found that very interesting to read
Thank you
1.
My original logo is 18.100 bytes and wonder if 3BB0(HEX) limit is accurate :/ :\ - while $B4000-$7F000=217.088 bytes
2.
On my param.lfs image, I searched for "FFD8 FFE0" and found other position for the JFIF files
Complete signature seems to be
"FFD8 FFE0"
"0010 4A46 4946 0001" for "..JFIF.."
3.
Linux support for j4fs would be great
4.
I wanted to know how to deal such a special "behaviour" into param.lfs partition: we can create files but not overwritten files...
Code:
[alpha] adb shell
$ su
# mount -o remount,rw -t j4fs /dev/block/stl6 /mnt/.lfs
# mount | grep ".lfs"
/dev/block/mmcblk0p4 on /mnt/.lfs type j4fs (rw,relatime)
#
# cd /mnt/.lfs
# rm -f logo.jpg
rm: can't remove 'logo.jpg': Operation not permitted
# echo "1. Impossible to delete logo.jpg"
1. Impossible to delete logo.jpg
#
# cp /mnt/sdcard/logo.jpg /mnt/.lfs/logo0.jpg
# ls -l /mnt/.lfs/logo0.jpg
-rwxrwxrwx 1 root root 19524 Jan 1 1970 /mnt/.lfs/logo0.jpg
# echo "2. copy onto /mnt/.lfs/ is possible"
2. copy onto /mnt/.lfs/ is possible
#
# cp -f logo0.jpg logo.jpg
cp: can't create 'logo.jpg': File exists
# echo "3. copy onto logo.jpg is impossible"
3. copy onto logo.jpg is impossible
#
# chattr -i logo.jpg
chattr: reading flags on logo.jpg: Not a typewriter
# rm -f logo.jpg
rm: can't remove 'logo.jpg': Operation not permitted
# exit
$ exit
[alpha] echo "Really strange for a file system ?"
Really strange for a file system ?
Is there a simple way to delete logo.jpg ?

Ivan_Belarus said:
Caution: Be careful. If you make something wrong, phone won't boot, because param.lfs is used by bootloader. At least /mnt/.lfs will be empty. You may have black screen. Anyway you will be able to enter in 3-button mode to flash stock param.lfs back.
Click to expand...
Click to collapse
First of all, thanks for sharing the info.
I tried it, no dice. Seems B4000 in the param.lfs I'm using (KI8) isn't the beginning of a JPEG. Tried other addresses that start with FF D8, with and w/o Exif, to no avail. All I have is an empty .lfs folder (as you said) and a boot message saying "logo.jpg" draw failed, but it boots eventually.
What am I missing?
TIA
param.lfs I'm using: http://www.mediafire.com/file/jw0x36z04fvp4eg/param.lfs
EDIT:
Wow! It took me a couple of hours, but I've finally found it in that param.lfs (XWKI8)!!!
In XWKI8 logo.jpg starts @ 7D800. Don't go beyond the length of the file you have already (in XWKI8, +/-15K), otherwise you'll get the "draw failed" boot error and an empty /mnt/.lfs - in this case, just reflash the stock param.lfs and you'll be ok.
Works great! I can sleep now!
Once more, thx a bunch Ivan_Belarus for sharing the info!
cheers!!!

geekmarc said:
1.My original logo is 18.100 bytes and wonder if 3BB0(HEX) limit is accurate :/ :\ - while $B4000-$7F000=217.088 bytes
2.On my param.lfs image, I searched for "FFD8 FFE0" and found other position for the JFIF files
Complete signature seems to be
"FFD8 FFE0"
"0010 4A46 4946 0001" for "..JFIF.."
4.I wanted to know how to deal such a special "behaviour" into param.lfs partition: we can create files but not overwritten files...
Is there a simple way to delete logo.jpg ?
Click to expand...
Click to collapse
1. Wrong operation. I have given the offsets only: for logo.jpg and logo_kor.jpg. I you want full addressing they are: B4000-B7FCF. It comes to 3FCF+2=3FD1. The second one is: 7F000-839B2. It comes to 49B2+2=49B4. (I've written 3BB0 - sorry I looked at my own block size. Fixed)
2. Yep, the jpeg header is bigger than word FF D8. You can google for jpeg header. But main two bytes are FF D8. The end is marked by FF D9. There are many jpeg files inside. I provided offsets for two ones.
4. You may look at Init.V scripts of Siyah kernel for example (/sbin/siyah/imports.sh)- there you may find all the commands for replace logo.jpg
I attached my original param.lfs (unchanged). I used it without problems on KI8
Heh, I didnt compare different param.lfs but now I see that there are different builds of param.lfs (thnx to rizdroid). So, I guess we're able to locate quickly the required offsets via block sizes and names. We need to find two blocks of size 3FD1 (starts with FF D8, ends with FF D9) and 49B4. They will be logo.jpg and logo_kor.jpg images. Before these blocks (about -7E1) you can find text 'logo.jpg' and 'logo_kor.jpg' accordingly. Don't try to locate them only by name!

someone help me out here... im trying to do this for the galaxy nexus but whenever i open my param.lfs file in a hex editor all i get is 0's theres nothing in it

Ivan_Belarus said:
1. Wrong operation. I have given the offsets only: for logo.jpg and logo_kor.jpg. I you want full addressing they are: B4000-B7FCF. It comes to 3FCF+2=3FD1. The second one is: 7F000-839B2. It comes to 49B2+2=49B4. (I've written 3BB0 - sorry I looked at my own block size. Fixed)
2. Yep, the jpeg header is bigger than word FF D8. You can google for jpeg header. But main two bytes are FF D8. The end is marked by FF D9. There are many jpeg files inside. I provided offsets for two ones.
4. You may look at Init.V scripts of Siyah kernel for example (/sbin/siyah/imports.sh)- there you may find all the commands for replace logo.jpg
I attached my original param.lfs (unchanged). I used it without problems on KI8
Heh, I didnt compare different param.lfs but now I see that there are different builds of param.lfs (thnx to rizdroid). So, I guess we're able to locate quickly the required offsets via block sizes and names. We need to find two blocks of size 3FD1 (starts with FF D8, ends with FF D9) and 49B4. They will be logo.jpg and logo_kor.jpg images. Before these blocks (about -7E1) you can find text 'logo.jpg' and 'logo_kor.jpg' accordingly. Don't try to locate them only by name!
Click to expand...
Click to collapse
WOOOOOOOOOOOOOOOOOOO !!!!! YEAH !!!!!! :good::good::good::victory::victory::victory:
@Ivan_Belarus, Thank you very much for the guide and help !!!!!
I was stack with that process of HEXing the param.lfs you provided because the image i made is SMALLER then 16337Bytes.
So I solved the "'logo.jpg' draw failed" problem I got ( becuase I changed only part of logo.jpg ) by filling "20" ( hex value ) all the cells between after my image FF D9 ( not included) and the original logo.jpg END ( FF D9 included ) as you wrote in your post: 1st jpg end is at B7FCF and the second is at 839B2.
I used the param.rar you provided.
To be clearer, for an example, let say I got this original param.lfs HEX segment:
Code:
[COLOR="red"]FFD8[/COLOR]FFE100184578EE55184D5331DA8831930800450007[COLOR="red"]FFD9[/COLOR]
But the image i want to implant is SMALLER , so it starts with "FFD8" and ends EARLIER with "FFD9" like:
Code:
[COLOR="red"]FFD8[/COLOR]FFE1008374597335734753745[COLOR="red"]FFD9[/COLOR]
So, I need to change param.lfs HEX segment so that it will include "20" after my image "FFD9":
Code:
[COLOR="red"]FFD8[/COLOR]FFE1008374597335734753745[COLOR="red"]FFD9[/COLOR][U][COLOR="Blue"]202020202020202020[/COLOR][/U]
About the need to TAR the param.lfs, because i'm on windows I used 7zip, so no need for linux of any sort.

rizdroid said:
First of all, thanks for sharing the info.
I tried it, no dice. Seems B4000 in the param.lfs I'm using (KI8) isn't the beginning of a JPEG. Tried other addresses that start with FF D8, with and w/o Exif, to no avail. All I have is an empty .lfs folder (as you said) and a boot message saying "logo.jpg" draw failed, but it boots eventually.
What am I missing?
TIA
param.lfs I'm using: http://www.mediafire.com/file/jw0x36z04fvp4eg/param.lfs
EDIT:
Wow! It took me a couple of hours, but I've finally found it in that param.lfs (XWKI8)!!!
In XWKI8 logo.jpg starts @ 7D800. Don't go beyond the length of the file you have already (in XWKI8, +/-15K), otherwise you'll get the "draw failed" boot error and an empty /mnt/.lfs - in this case, just reflash the stock param.lfs and you'll be ok.
Works great! I can sleep now!
Once more, thx a bunch Ivan_Belarus for sharing the info!
cheers!!!
Click to expand...
Click to collapse
Sorry to resurrect a REALLY old thread, but how did you manage to flash PARAM partition. It is in my .pit file from heimdall, but when I flash the partition, I simply see the old bootscreen.

hackintosh5 said:
Sorry to resurrect a REALLY old thread, but (...) .
Click to expand...
Click to collapse
It is OK to ask questions even if the thread is sooo old
But unfortunately I can't help you.

Iluvatar2000 said:
It is OK to ask questions even if the thread is sooo old
But unfortunately I can't help you.
Click to expand...
Click to collapse
Its fine! Thanks for your time!

[Q] Can't boot with custom Ramdisk (resolved)

I dumped my boot device which i believe is /dev/mtd/mtd2 according to /proc/mtd
#cat /dev/mtd/mtd2 > boot.img
I took that image and ran the split_bootimg perl script on it to separate the kernel and ramdisk images.
#split_bootimg boot.img
Then I just tried to recombine them with mkbootimg without making any modifications.
#mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img
* I also tried an image with identical boot options as I found the stock kernel has
I then copied and erased/flashed the new image
#cat /dev/zero > /dev/mtd/mtd2
#flash_image boot boot-new.img
The phone just sits at the HTC screen forever when I try and boot it.
If I reboot into recovery and flash the original "boot.img" backup using the same method it boots OK.
What is it I'm missing? thanks!

I tried dumping the new base.img I made
Original from ROM for comparison:
Page size: 2048 (0x00000800)
Kernel size: 2271684 (0x0022a9c4)
Ramdisk size: 167343 (0x00028daf)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Repacked:
Page size: 2048 (0x00000800)
Kernel size: 2271684 (0x0022a9c4)
Ramdisk size: 167343 (0x00028daf)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
I also downloaded the kernel source for the incredible and tried to find the base address and used 0x10000000 on the mkbootimg command no to avail.
I did notice new image is smaller than the old by ~1MB! Even though when I unpack it still shows them as the same size.
3145728 boot.img
2443264 newboot.img
Any help here is very appreciated.

I found the solution. I was using the wrong base address on mkbootimg command
I found the proper base address by downloading the kernel source for the droid incredible.
(DROID Incredible by HTC (Verizon) – GB MR - 2.6.35 kernel source code)
Then I looked up the processor used in the incredible hardware in the file referenced below and got the proper offset. It's boot up now
arch\arm\mach-msm\include\mach\memory.h

| bml0!c | reset flash counter in bml15 . analyze bml0!c in oneNAND

we gingerbread guys need to get serious on this fricken flash counter, else we can't truely clone our SGYs.
reedit: by this time Doky has found it in bml15 and resets it in his galaxy tool app. ty !!
Kies knows about it and it has implications for asec stuff too.
manufacturing tried to keep the info on the flash counter's whereabouts a tightly guarded secret like some Bill Clinton sex affair, but now it is busted all out in the open ! <-- link
we gotta be able to reset that data to a fricken pristine state!
then we got a 100% CLONE !!
quote :
The flash counter and triangle state had to be stored somewhere. Everybody knew that ... You can dump and compare the entire /dev/block/mmcblk0 and you won't find a difference (you'll find a few unallocated and unused gaps, though).
on SGY mmcblk0 is the sd card, /dev/block/bml0!c = total internal NAND storage - which is what we are looking for. see: http://forum.xda-developers.com/showthread.php?t=1998471
however, the flash disk actually has two hidden boot partitions,
/dev/block/mmcblk0boot0 and
/dev/block/mmcblk0boot1
The MMC driver in the kernels used for Gingerbread did not present these partitions in the past, the MMC driver in the ICS kernel does.
Dump and compare the partitions and you'll have found them in no time.
Structure /dev/block/mmcblk0boot0 @ 0x00020000:
0x00020000 header magic: 32bit - 0x12340011
0x00020004 flash count: 16bit
0x00020006 future: 16bit - 0x0000
0x00020008 type: 16bit - 0x0000 unknown, 0x0001 custom (triangle), 0x0002 Samsung Official
0x0002000A name: max 16 chars
0x0002001A end: 16bit - 0x0000
The boot partitions are presented as readonly by default, but allowing modification is a simple matter of executing the following before writing the data:
### does not fullly apply to SGY ! other phones only !! ###
echo 0 > /sys/block/mmcblk0boot0/force_ro
A number of bytes trailing this structure also change between flashes and appear to be checksum related.
click Tags below for more related info !

neither I'm able to confirm nor negate, but I'm afraid the SGY have other storage areas.
and keep in mind, on SGSII this hidden device has appears only on the leaked beta ICS kernel. Moreover I don't see any good reason, why is it accessible under Android. Kies does not care about the bin counter. I was able to restore factory state with bin counter>0 and Kies recognized my devce as valid upgradeable. On the other hand, the bin counter is handled on the sbl runlevel, where kernel and android not yet loaded.
For further reference please see my research on the SGY partition system, decoded from the pit file:
Code:
[B]minor bml stl image[/B]
1 /bml1 /stl1 BcmBoot.img
2 /bml2 /stl2 sbl.bin
3 /bml3 /stl3 bl.bin
4 /bml4 /stl4 totoro.pit
5 /bml5 /stl5 BcmCP.img
6 /bml22 /stl6 param.lfs
7 /bml6 /stl7 boot.img
8 /bml7 /stl8 (boot backup)
9 /bml21 /stl9 system.img
10 /bml23 /stl10 csc.rfs
11 /bml24 /stl11 userdata.img
12 /bml8 /stl12 (efs)
13 /bml9 /stl13 sysparm_dep.img
14 /bml10 /stl14 HEDGE_NVRAM8_RF_LE.bin
15 /bml11 /stl15 (cal)
On much deeper details please see my spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0Arilp8uJromLdHdrdGpiZ2FSN3daRzRQMkIxR0pCZXc
Minor #12 and #15 is suspicious, might have some data, which not used by the OS, and not affected by ROM update packs.

This is good research, doky. I bookmarked your spreadsheet for future reference.

efs
Doky73 said:
12 /bml8 /stl12 (efs)
15 /bml11 /stl15 (cal)
Minor #12 and #15 is suspicious, might have some data, which not used by the OS, and not affected by ROM update packs.
Click to expand...
Click to collapse
efs is directly related to the SIM card file system, I take it.
"the /efs folder is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location."

<post deleted>

cal : calibration data
Doky73's SGY layout table: now, spot the flash counter
minor Start-offset --- End-offset ------ Size (hex) units ------- SIZE (bytes) -- BML --------- STL -- Internal name Image name ------ Description
01 0x00000000 0x00040000 0x00040000 001 000262144 /bml1 _/stl1 _bcm_boot BcmBoot.img Primitive boot loader
02 0x00040000 0x00240000 0x00200000 008 002097152 /bml2 _/stl2 _Loke sbl.bin Secondary boot loader
03 0x00240000 0x00440000 0x00200000 008 002097152 /bml3 _/stl3 _loke_bk bl.bin backup sbl
04 0x00440000 0x00480000 0x00040000 001 000262144 /bml4 _/stl4 _systemdata totoro.pit partition table
05 0x00480000 0x01100000 0x00c80000 050 013107200 /bml5 _/stl5 _Modem BcmCP.img modem/phone
06 0x01100000 0x01600000 0x00500000 020 005242880 /bml22 /stl6 _param_lfs param.lfs
07 0x01600000 0x01b00000 0x00500000 020 005242880 /bml6 _/stl7 _boot boot.img kernel & initramfs
08 0x01b00000 0x02000000 0x00500000 020 005242880 /bml7 _/stl8 _boot_backup - backup kernel & initramfs
09 0x02000000 0x10600000 0x0e600000 920 241172480 /bml21 /stl9 _System system.img ROM
10 0x10600000 0x12e00000 0x02800000 160 041943040 /bml23 /stl10 Cache csc.rfs CSC
11 0x12e00000 0x1f340000 0x0c540000 789 206831616 /bml24 /stl11 Userdata userdata.img data
12 0x1f340000 0x1f380000 0x00040000 001 000262144 /bml8 _/stl12 Efs - efs unique phone data
13 0x1f380000 0x1f3c0000 0x00040000 001 000262144 /bml9 _/stl13 sysparm_dep sysparm_dep.img
14 0x1f3c0000 0x1f400000 0x00040000 001 000262144 /bml10 /stl14 umts_cal HEDGE_NVRAM8_RF_LE.bin
15 0x1f400000 0x1f500000 0x00100000 004 001048576 /bml11 /stl15 cal - calibration data
note: not all /bml & /stl devices are visible, some of them not linked under the OS
------------------------------------------------------------
I guess, cloning all of minor 12 would be a mistake.
14 & 15 are sets of calibration data, probably for RF part (gsm radio)

mai77 said:
Darky's SGY layout table: now, spot the flash counter
Click to expand...
Click to collapse
Well, Darky is working on a custom rom for SGY???
Yep, we're saved!

Factory mode
also there is a difference between ODIN mode (via DOWN+HOME+POWER) and FACTORY MODE via USB jig 301KOhm.
makes a diff for displayed "official" vs. "custom" ROM

Any new ideas on this guys? I was wondering if this cant be hacked via the .pit file?
I wish I could find this damn partition and forcefully reset this

Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100

Princeomi said:
Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100
Click to expand...
Click to collapse
Are you sure?where did uou get that info??
Sent from my GT-S5360 using xda premium

Princeomi said:
Apparently the max count is 255 so if you flash it the 256th time you should be on zero. Take this info with a pinch of salt.
Sent from my GT-I9100
Click to expand...
Click to collapse
Very interesting bro
Hmmmm.... That actually does make sense to me, because due to screen size limitations, I can't see the numbers carrying on into infinity. As it is when it gets to the teens, it starts screwing up the text on screen, so an ultimate limit would make sense.
I guess besides the fact that it voids your warranty if anybody had to see it from Samsung, I guess it does nothing but just annoy you cause you cant reset it
Not sure if I will try your method Princeomi but I will keep that in mind
---------- Post added at 08:23 PM ---------- Previous post was at 08:09 PM ----------
What I don't understand though is why does the USB jig not reset it on our phones but it does on the SGS2? I just watched a vid on you tube and Odin mode looks exactly the same as it does on our phones.

I read it in the news section of XDA, never tried it though as I am on zero
Sent from my GT-S5360

NanoSurfer said:
[/COLOR]What I don't understand though is why does the USB jig not reset it on our phones but it does on the SGS2? I just watched a vid on you tube and Odin mode looks exactly the same as it does on our phones.
Click to expand...
Click to collapse
actually it does not resets neither on SGSII. Only on some old/initial ROMs. The SBL has been modified by Samsung, to prevent users resetting the counter simply by USB JIG. To reset my SGSII's counter, I have to downgrade the SBL. (or upgrade to ICS , there's an other method, based on a new feature of the 3.x kernel)
Sent from my SGSII using Tapatalk 2 & Swype

Doky73 said:
actually it does not resets neither on SGSII. Only on some old/initial ROMs. The SBL has been modified by Samsung, to prevent users resetting the counter simply by USB JIG. To reset my SGSII's counter, I have to downgrade the SBL. (or upgrade to ICS , there's an other method, based on a new feature of the 3.x kernel)
Sent from my SGSII using Tapatalk 2 & Swype
Click to expand...
Click to collapse
Interesting Sir Doky
I kinda figured that Samsung would wise up to that trick sooner or later. BTW what you think of the max count trick?

doky's SGY partn table from above attached
remember,
dd if=/dev/block/bml0!c
gives you the complete NAND storage 501 MB file on SGY:
so this shell cmds gave me a 501 MB file which is probably the NAND dump :
adb shell
su
stop
dd if=/dev/block/bml0!c of=/sdcard/bml0c.outfile
## wait 2 minutes to finish
start
## wait 30 sec
I believe, the last 1 MB of the file is junk data or duplicate

bml0!c dump
the dump says:
OneNAND boot rev. 0.2
+cboot_uart_speed_handshake(0x%x)
Set Baudrate to 115k.
Set Baudrate to 230k.
¼:”Set Baudrate to 460k.
Set Baudrate to 921k.
Set Baudrate to 3m.
Invalid Baudrate, try again.
cboot_uart.c
assert at line %d in %s -cboot_uart_speed_handshake

###################################
Secondary Bootloader v3.1 version. Copyright (C) 2011 System S/W Group. Samsung Electronics Co., Ltd.
Board: %s %s / %s %s TOTORO REV 03 Jan 14 2012 07:01:28
%s: debug level 0x%x %s: debug level low! PUMR: %d FOTA_BOOT FOTA_UAUP PUMR: 0x40 (AP only boot mode) loadmodem loadCPDATA loadkernel
boot SBL> %s: parse command error! (%s)
Autoboot (%d seconds) in progress, press any key to stop
Autoboot aborted..
booting code=0x%x stl init failed.. %s: j4fs_open.. success failed %s: bye~ bye! %s: booting stop.
%s: booting stop and power off..
S5360 console=ttyS0,115200n8 mem=362M kmemleak=off root=/dev/ram0 rw
androidboot.console=ttyS0 /mnt/rsv SNBL main
#############
prob. kernel command line for UART FOTA boot or whatever
#############
loke_exit
loke_init
command_loop
boot_kernel
SERIAL_SPEED LOAD_RAMDISK BOOT_DELAY LCD_LEVEL SWITCH_SEL PHONE_DEBUG_ON LCD_DIM_LEVEL LCD_DIM_TIME MELODY_MODE REBOOT_MODE NATION_SEL LANGUAGE_SEL SET_DEFAULT_PARAM PARAM_INT_13 PARAM_INT_14 VERSION CMDLINE DELTA_LOCATION PARAM_STR_3 PARAM_STR_4
mtdparts=bcm_umi-nand: %[email protected]%dK(%s)ro, %[email protected]%dK(%s)rw, fota_reboot FOTA
Boot cause : %s FOTA_BOOT FOTA_UAUP LOKE3 : FOTA_UPDATE_FOTA_BOOT
BOOT_FOTA=1 BOOT_FOTA=0
ATAG_CORE: %x
ATAG_INITRD2: %x

Linux-based NAND Flash software solution, offering higher performance and cost effectiveness for next-generation mobile phones. Samsung's Linux NAND Flash memory software allows the NAND Flash memory to store code as well as data. By eliminating the need for NOR Flash memory and supporting the Linux operating system with a demand-paging function, Samsung can lower overall costs and reduce space requirements in mobile handhelds.
Samsung's Linux file system, Robust File System (RFS), also offers greater data preservation capabilities in case of power disruption as well as wear-leveling for higher reliability. To address the problem of data loss from corrupted file allocation tables (FAT), Samsung's Linux-based NAND Flash memory solution also supports Transactional FAT for external memory cards. Compared to the conventional JFFS2 and YAFFS open file systems, Samsung's Linux file system enhances the NAND Flash write-speed up ten and four times , respectively.
This Flash memory solution is also available with Samsung's OneNAND (tm) Flash memory, which boasts a faster read speed compared to the conventional NAND Flash. With its advanced multi-tasking function, Linux will further accelerate the adoption of NAND Flash in next-generation mobile phones.
Importantly, as Samsung's new Linux NAND Flash memory software, RFS has completed verification in the Linux kernel 2.4.20-based Montavista Linux environment, Samsung's NAND Flash solution addresses the diverse needs of system developers for advanced performance, high reliability, shortened development time, and reduced costs.

SGY heimdall
with UBI running on oneNAND and UBIfs we SGY users can have our own "mobile ODIN" and Heimdall.
UBI is open source and part of the Linux kernel.

[DEV][HOWTO] Extracting stock firmware files from .tot files

Hello everyone!
First off:
DISCLAIMER: I AM NOT RESPONSIBLE FOR ANYTHING YOU DO TO YOUR PHONE WHILE USING ANY OF THE INFORMATION LOCATED BELOW. IF YOU DO NOT UNDERSTAND WHAT IS BEING DONE, PLEASE DO NOT TRY ANYTHING DONE HERE!
This is still in a VERY basic phase. I am not sure how helpful it will be, but currently, I have been able to extract some of the smaller partitions from the AT&T firmware file.
Starting off, when LGNPST is used to image a phone, it creates a log file in C:\LG Electronics\LGNPST\Models\LOG\ For example, mine was called LS970Log_COM5.log. We are really only interested in one part of this file, located close to the bottom when the phone is actually being imaged. It should look something like this:
0Download mode locking
0Download : PrimaryGPT 0x 0 Size: 0x 512Kb, File Offset: 0x 100000
0 3.182994E-313mmc Init
0Partition Count : 35======================================================
0======================================================
0Download : modem 0x 800000 Size: 0x 54272Kb, File Offset: 0x 180000
0Download : sbl1 0x4800000 Size: 0x 512Kb, File Offset: 0x3680000
0Download : sbl2 0x4880000 Size: 0x 512Kb, File Offset: 0x3700000
0Download : sbl3 0x4900000 Size: 0x 1024Kb, File Offset: 0x3780000
0Download : aboot 0x4b00000 Size: 0x 512Kb, File Offset: 0x3880000
0Download : rpm 0x4b80000 Size: 0x 512Kb, File Offset: 0x3900000
0Download : boot 0x5000000 Size: 0x 7168Kb, File Offset: 0x3980000
0Download : tz 0x6800000 Size: 0x 512Kb, File Offset: 0x4080000
0(null)kip misc Partition
0Download : system 0xb000000 Size: 0x 131072Kb, File Offset: 0x4900000
0Download : system 0x13000000 Size: 0x 512Kb, File Offset: 0xc900000
0Download : system 0x1325e000 Size: 0x 129024Kb, File Offset: 0xc980000
0Download : system 0x1b1fd000 Size: 0x 129536Kb, File Offset: 0x14780000
0Download : system 0x2325e000 Size: 0x 129024Kb, File Offset: 0x1c600000
0Download : system 0x2b1fd000 Size: 0x 129536Kb, File Offset: 0x24400000
0Download : system 0x3325e000 Size: 0x 129024Kb, File Offset: 0x2c280000
0Download : system 0x3b1fd000 Size: 0x 129536Kb, File Offset: 0x34080000
0Download : system 0x4325e000 Size: 0x 129024Kb, File Offset: 0x3bf00000
0Download : system 0x4b1fd000 Size: 0x 76800Kb, File Offset: 0x43d00000
0Download : system 0x53000000 Size: 0x 512Kb, File Offset: 0x48800000
0Download : system 0x5b000000 Size: 0x 512Kb, File Offset: 0x48880000
0Download : system 0x63000000 Size: 0x 512Kb, File Offset: 0x48900000
0Download : persist 0x7a800000 Size: 0x 4608Kb, File Offset: 0x48980000
0Download : recovery 0x8b000000 Size: 0x 8192Kb, File Offset: 0x48e00000
0Download : BackupGPT 0xab380000 Size: 0x 512Kb, File Offset: 0x49600000
0
*********************************************************************************************
Click to expand...
Click to collapse
What do we see that is important here? Image sizes and offsets for data in the file! For example, lets take the boot partition.
0Download : boot 0x5000000 Size: 0x 7168Kb, File Offset: 0x3980000
Click to expand...
Click to collapse
We have a offset of 0x3980000 and a size of 7168Kb. That converts to an equivalent of an offset of 60293120 bytes and a size of 7340032 bytes (I really hope I got that right. As I'm sitting here writing this, I'm thinking of how many different ways I could have messed up that calculation...)
Here, I am using dd on linux in order to separate the partitions from the binary file, but it can be done using equivalent tools on windows.
$ dd bs=1 skip=60293120 count=7340032 if=LGE970AT-00-V10o-ATT-US-SEP-29-2012+0.tot of=boot.img
Click to expand...
Click to collapse
Basically, what I am doing here is copying 7340032 bytes, starting at byte 60293120, from the .tot file to boot.img.
Now, lets check out the backups made with FreeGee when you unlock, to see if it matches with what was actually written to the phone. In order to see if they are equal, we need to trim the backup, because the backup that is taken is actually of the entire partition, not just the actual data.
$ dd bs=1 count=7340032 if=boot-att-backup.img of=boot-att-backup-trimmed.img
Click to expand...
Click to collapse
This is doing basically the same, starting at the first byte, copying 7340032 bytes to boot-att-backup-trimmed.img. This is just making sure you only get the same amount of data that was written.
Now, If of course we want to see if the data is actually the same, so we will also use the diff command, also found on linux, and I'm sure is also available on windows.
$ diff -s boot.img boot-att-backup-trimmed.img
Click to expand...
Click to collapse
If both files are identical, which means everything was done correctly, this should result in the output "Files boot.img and boot-att-backup-trimmed.img are identical", which it does! (The -s flag makes diff report identical files.)
So, now that we know that we can successfully extract the boot partition, I also tried this with the aboot partition, and it worked as well! I have not had success extracting the system partition yet, as it is split up into several partitions. I was hoping that someone with more knowledge could piece together a system image. Enjoy

SnowLeopardJB said:
Hello everyone!
First off:
DISCLAIMER: I AM NOT RESPONSIBLE FOR ANYTHING YOU DO TO YOUR PHONE WHILE USING ANY OF THE INFORMATION LOCATED BELOW. IF YOU DO NOT UNDERSTAND WHAT IS BEING DONE, PLEASE DO NOT TRY ANYTHING DONE HERE!
This is still in a VERY basic phase. I am not sure how helpful it will be, but currently, I have been able to extract some of the smaller partitions from the AT&T firmware file.
Starting off, when LGNPST is used to image a phone, it creates a log file in C:\LG Electronics\LGNPST\Models\LOG\ For example, mine was called LS970Log_COM5.log. We are really only interested in one part of this file, located close to the bottom when the phone is actually being imaged. It should look something like this:
What do we see that is important here? Image sizes and offsets for data in the file! For example, lets take the boot partition.
We have a offset of 0x3980000 and a size of 7168Kb. That converts to an equivalent of an offset of 60293120 bytes and a size of 7340032 bytes (I really hope I got that right. As I'm sitting here writing this, I'm thinking of how many different ways I could have messed up that calculation...)
Here, I am using dd on linux in order to separate the partitions from the binary file, but it can be done using equivalent tools on windows.
Basically, what I am doing here is copying 7340032 bytes, starting at byte 60293120, from the .tot file to boot.img.
Now, lets check out the backups made with FreeGee when you unlock, to see if it matches with what was actually written to the phone. In order to see if they are equal, we need to trim the backup, because the backup that is taken is actually of the entire partition, not just the actual data.
This is doing basically the same, starting at the first byte, copying 7340032 bytes to boot-att-backup-trimmed.img. This is just making sure you only get the same amount of data that was written.
Now, If of course we want to see if the data is actually the same, so we will also use the diff command, also found on linux, and I'm sure is also available on windows.
If both files are identical, which means everything was done correctly, this should result in the output "Files boot.img and boot-att-backup-trimmed.img are identical", which it does! (The -s flag makes diff report identical files.)
So, now that we know that we can successfully extract the boot partition, I also tried this with the aboot partition, and it worked as well! I have not had success extracting the system partition yet, as it is split up into several partitions. I was hoping that someone with more knowledge could piece together a system image. Enjoy
Click to expand...
Click to collapse
would it be possible to guide me through this from the very beginning? i want to start cooking for this device, but i need a legit flashable Rom. Please and Thank you.

You are most likely better off just pulling a system image off your device. So, if you are rooted, you can pull your system with something like this:
# busybox tar cf /sdcard/system.tar /system/*
Click to expand...
Click to collapse
That should give you all of the system files all together in a tar archive on your internal sdcard.

I messaged you, but is there any way to use this on the Sprint version to create a flashable .zip?

sorry about the resurrection,
but has there been any progress made on this? More of a curiosity, then anything.
Thanks

RK3188 on MINIX-NEOX7mini

Hi all folks,
I have some question about the stock android system in this specific box and the format of the dumped partition.
Try to explain, I'm using rkflashtool to interact with the memory of the RK3188
This is the output of the command
rkflashtool r 0 1 | head -n 11
-------------------------------------------------------------------------------------------------
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0
init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](kpanic),
[email protected](system),
[email protected](user)
-------------------------------------------------------------------------------------------------
I guess the boot partition is something linke that:
+-------+ <--- 0x00019fe0
| boot |
+-------+ <----0x00012000
With this command i'm able to dump the entrie boot partition on my linux box in a file named b00t.img :
rkflashtool r 0x12000 0x8000 > b00t.img
Now, i have find out that with the tool rkunpack (or simply with dd) i'm able to unpack this b00t.img. The output are two file:
b00t.img-raw
b00t.img-symbol
The first file is no more than a gzip compressed data file, I'm able to extract the data in a directory with this command:
gunzip < ../b00t.img-raw | sudo cpio -i --make-directories
Now in this dir I have all the files of the / partition. I can modify for example the /init.rc.
I want to repack the entrie b00t.img in order to flash it again on the device.
NB:
In this thread this guys work at something like my problem...
http://www.freaktab.com/showthread....-Tricks-by-Finless&p=4055&viewfull=1#post4055
The difference is that they work on a different partition layout, and the rkunpack of dumped boot.img return they only boot.img-raw.
Obviously I've already tried to repack the modified directory in this two ways:
mkcramfs myboot myboot-temp.img
kcrc myboot-temp.img customboot.img
or
find . ! -name "."| sort | cpio -oa -H newc | gzip -n > ../newboot.gz
kcrc newboot.gz customboot.img
Neither of these leads to obtain a file large enough to fit the boot partition on the deivice, that I want fill with:
rkflashtool w 0x12000 0x8000 < modifiedb00t.img
Has anyone ever worked with rk3188? Any idea?
Thanks in advance.

Anyone?