Database Users

WARNING: Remember: to stay lag-free, leave lots of free internal space!

(90% of the time the main cause of Android device lag is slow internal Flash memory!)
Lately, my Note had gotten laggy- apps were taking forever to open, Chrome was slow opening pages and things were just slow overall. Was it one of my kernel mods? Was it the DeOdexed ROM? I'd gone back to a stock kernel and switched back to a stock ROM, but it was still laggy. I'd turned on "Show CPU Usage" and sure enough, my Note was spending a LOT of time in "IOWait" (the blue bar) and the system was spending a lot of time running the process "mmcqd/0" (the kernel thread that runs the Flash memory). None of my troubleshooing worked and I couldn't figure it out 'till I did a "df" and discovered I'd made a newbie mistake- I'd had only 750MB remaining on /data (which also includes where the internal sdcard is located). Bingo!
For those who don't know, I'll give you the "TL;DR" lesson on Flash memories- the fuller they get, the slower they get.
A more-detailed explanation: the controller on a Flash device takes longer to find free space to write file data on as it gets fuller- the "erase size" is usually far bigger than the average size of a kernel write, so the Flash device's internal controller can't find enough empty flash blocks it has to do some time-consuming "Read-Erase-Write" operations, and when that happens (which can take many milliseconds and adds up quickly) no other I/O can happen on the flash device, so your Android device lags as your CPU helplessly sits there waiting for all the I/O to complete. Although we're using the "discard" option on our /data partition (which lets the Flash-memory controller know when Linux has removed a file, helping it keep more available empty blocks for later write operations), there's only so much that can be done when the percentage of free space falls below a certain point.
(OK, the following steps aren't for absolute newbies, and you have to be rooted- so the Standard XDA Disclaimer of "If you fsck this up, don't blame me!" applies here!)
So, I'd first determined where all the space was going (I used "cd /data ; du -kx | sort -rn | head"). In my case, it was a couple of cached Vudu movies, YouTube caching of my "Watch Later", a couple of movies that I hadn't moved to the SD-Card and the Samsung "Note Screensaver" and "Note Manual" apps. I also used TiBu to Integrate updates of my apps back to the ROM. All told, I'd freed up about 4GB.
Next, I ran "fstrim -v /data" to help the Flash memory controller reclaim the space internally. After a reboot (only necessary 'cause of the TiBu "Integrate to ROM"), Voila! Back to speed!
I've attached a zipped-up copy of my "fstrim" binary, and for those using my kernels (which I'll be updating soon as I've got some other goodies too) they'll now have automatic "fstrim" on bootup (BTW, the free version (at least) of "LagFree" app doesn't work on our Notes for some reason).
(TL;DR: keep your internal storage as free as possible, else everything slows down.)

Do I need root to do this?
I spent some time doing some file shuffling between my internal and external memory cards and freed about 3gb of stuff from the internal sd. Tablet is more responsive but I'd still like to be able to clear my cacbes.
Sent from my GT-N8013 using XDA Premium HD app

Temetka said:
Do I need root to do this?
Click to expand...
Click to collapse
Looks like your question was already answered.
kcrudup said:
(OK, the following steps aren't for absolute newbies, and you have to be rooted- so the Standard XDA Disclaimer of "If you fsck this up, don't blame me!" applies here!)
Click to expand...
Click to collapse

Yes it was.
In my defense I was very tired. Just chalk it to me being that guy who asked the obvious.
Sent from my GT-N8013 using XDA Premium HD app

Temetka said:
Just chalk it to me being that guy who asked the obvious
Click to expand...
Click to collapse
Ah, don't sweat it, we've all done it- "Let he of ye without sin ..." and all
But in the next few days (and against my better judgement ) I'll be putting out a series of boot.img files for the most popular ROMs out there (i.e., "the ones I've used"): the latest Samsung Official, Darkman's latest and AR HD's latest.
They'll have my latest OC and upgraded kernels, and my YouTube and "fstrim" mods and I'll update them fairly often.

Is there a non-ODIN method to install boot.img? If not can you make flashable zips?

This very reason is why i bought the 32 gb version.. Some with my nexus 7 and my phone 16 gb .... Its well worth the little bit of extra money .. But its awesome to have people here willing to help. I know on the nexus if you get it half full you will have very bad slow down and issues. This has been discussed over and over in the GOOGLE TECH FORUMS and some here on the xda nexus forum..
I think like with a windows pc . if you move around install and uninstall alot of software applications . You should once in a while wipe and re install the os .So for android devices Cloud storage is awesome.I use a ftp app that will sync to my ftp site once a week of the night time..
I can wipe my device restore from the ftp quick easy and no loss of data...

erica_renee said:
This very reason is why I bought the 32 GB version
Click to expand...
Click to collapse
Yeah, I looked everywhere for a GT-N8000 with 32GB, and apparently they don't make one.
I think like with a windows PC, if you move around, install and uninstall a lot of software applications you should once in a while wipe and re-install the os
Click to expand...
Click to collapse
Well, that's really apples-and-oranges here, though. All that matters to US is relative storage availability (and the "discard" mount flag to give the Flash device hints, which is turned on even in Stock kernels) so there's room for the device to re-arrange things. Based on the design of Android, wipes are really only necessary when an app (or an owner ...) misbehaves.
Remember, too, that most of our devices' OS is in read-only-memory and never changes, also invalidating the need to install.
Windows, on the other hand, is just a mess

kcrudup said:
Yeah, I looked everywhere for a GT-N8000 with 32GB, and apparently they don't make one.
Well, that's really apples-and-oranges here, though. All that matters to US is relative storage availability (and the "discard" mount flag to give the Flash device hints, which is turned on even in Stock kernels) so there's room for the device to re-arrange things. Based on the design of Android, wipes are really only necessary when an app (or an owner ...) misbehaves.
Remember, too, that most of our devices' OS is in read-only-memory and never changes, also invalidating the need to install.
Windows, on the other hand, is just a mess
Click to expand...
Click to collapse
That is true... OOPS and you might be right on the GT-N8000. I have n8013 wifi only tab. Could not find the 3g one within any reasonable price range i was willing to pay..
ohh Sometimes im a mess as well... but thats obvious huh?

Just sold my Galaxy Tab 10.1 and bought a note. My question is, how much space should the system and all the preinstalled apps/bloat take up? I bought a white 16GB and upon turning it on it shows I only have 11.66GB of total space and 11.09GB of free space. Applications are taking up 228MB, Audio is at 20KB, Misc is at 194MB. Does the system really take up almost 4.5GB? Seems like a whole lot.
Shouldn't the system show 16GB of total space? My SGS3 does. Why does the note show only 11.66GB os total space?

The Apostle said:
Does the system really take up almost 4.5GB?
Click to expand...
Click to collapse
Yes, it does.
Seems like a whole lot.
Click to expand...
Click to collapse
No, it isn't.
Shouldn't the system show 16GB of total space?
Click to expand...
Click to collapse
No, it shouldn't.

Regarding to memory space,
Titanium Backup shows me a 2.48 mb free out of 1.44 gb sys rom memory !!!
So, where is the 4.5 gb the rest of 16 gb ???
Sent from my GT-N8000 using xda premium

hatem 5000 said:
So, where is the 4.5 gb the rest of 16 gb
Click to expand...
Click to collapse
There are a LOT of partitions besides system/data/cache/boot/recovery you've got to consider, too:
Code:
$ adb shell cat /proc/partitions | fgrep mmcblk0
179 0 15388672 mmcblk0
179 1 4096 mmcblk0p1
179 2 4096 mmcblk0p2
179 3 20480 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 32768 mmcblk0p7
179 8 819200 mmcblk0p8
179 9 1433600 mmcblk0p9
179 10 512000 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 12521472 mmcblk0p12
179 32 2048 mmcblk0boot1
179 16 2048 mmcblk0boot0
$
... and here's a human-readable dump of the PIT file for the N8000:
Code:
--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 80
Attributes: 2 (STL Read-Only)
Update Attributes: 1 (FOTA)
Partition Block Size: 0
Partition Block Count: 1734
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOTLOADER
Flash Filename: sboot.bin
FOTA Filename:
--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 81
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 1734
Partition Block Count: 312
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: TZSW
Flash Filename: tz.img
FOTA Filename:
--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 70
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 34
Partition Block Count: 16
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PIT
Flash Filename: note10.pit
FOTA Filename:
--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 71
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 50
Partition Block Count: 2048
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MD5HDR
Flash Filename: md5.img
FOTA Filename:
--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 8192
Partition Block Count: 8192
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOTA0
Flash Filename: -
FOTA Filename:
--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 16384
Partition Block Count: 8192
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOTA1
Flash Filename: -
FOTA Filename:
--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 5 (Read/Write)
Update Attributes: 5 (FOTA)
Partition Block Size: 24576
Partition Block Count: 40960
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename: efs.img
FOTA Filename:
--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 65536
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash Filename: param.bin
FOTA Filename:
--- Entry #8 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 5
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 81920
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 6
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 98304
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash Filename: recovery.img
FOTA Filename:
--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 7
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 114688
Partition Block Count: 65536
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RADIO
Flash Filename: modem.bin
FOTA Filename:
--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 8
Attributes: 5 (Read/Write)
Update Attributes: 5 (FOTA)
Partition Block Size: 180224
Partition Block Count: 1638400
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash Filename: cache.img
FOTA Filename:
--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 9
Attributes: 5 (Read/Write)
Update Attributes: 5 (FOTA)
Partition Block Size: 1818624
Partition Block Count: 2867200
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SYSTEM
Flash Filename: system.img
FOTA Filename:
--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 10
Attributes: 5 (Read/Write)
Update Attributes: 5 (FOTA)
Partition Block Size: 4685824
Partition Block Count: 1024000
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: HIDDEN
Flash Filename: hidden.img
FOTA Filename:
--- Entry #14 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 11
Attributes: 5 (Read/Write)
Update Attributes: 1 (FOTA)
Partition Block Size: 5709824
Partition Block Count: 16384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: OTA
Flash Filename: -
FOTA Filename:
--- Entry #15 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 12
Attributes: 5 (Read/Write)
Update Attributes: 5 (FOTA)
Partition Block Size: 5726208
Partition Block Count: 0
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: USERDATA
Flash Filename: userdata.img
FOTA Filename: remained

kcrudup said:
Yes, it does.
No, it isn't.
No, it shouldn't.
Click to expand...
Click to collapse
Thsnk you but can anyone provide insight on why the 16GB note would show 11.66GB of total space and the GSIII would show 16GB of total space?
Sent From a far away Galaxy, in Missouri.

The Apostle said:
Thsnk you but can anyone provide insight on why the 16GB note would show 11.66GB of total space and the GSIII would show 16GB of total space?
Sent From a far away Galaxy, in Missouri.
Click to expand...
Click to collapse
My s3 shows 11.95 gb disk space available by the way! So its the same.
Sent from my SAMSUNG-SGH-I747 using Tapatalk

The Apostle said:
Thsnk you but can anyone provide insight on why the 16GB note would show 11.66GB of total space and the GSIII would show 16GB of total space?
Sent From a far away Galaxy, in Missouri.
Click to expand...
Click to collapse
Every storage device has less than the advertised amount of space available. For example 1tb drives only have 965mb available.
Sent from the mighty Note II

dr.m0x said:
Every storage device has less than the advertised amount of space available. For example 1tb drives only have 965mb available
Click to expand...
Click to collapse
Actually, that particular difference is only due to difference in the definition of sizes; computer people like to think in terms of powers of 2, so a "Terabyte" to computer people is 2^30, or 1073741824 bytes. However, disk-drive manufacturers started using powers-of-10 "Terabytes" (1000000000) so they could legally claim a "Terabyte" (or "Megabyte", as the case may be) but short-change us by not meeting the computer-referenced version of same, so that same "1TiB" drive is really only 954 of the Megabytes that really count.
In the case of our Flash drives, the reason it's smaller than the 16GB (and it's a real "computer 16GB", 16777216 bytes) is because of what I'd stated above, partitioning of the drive into partitions we can't consider available for data storage.

kcrudup said:
Actually, that particular difference is only due to difference in the definition of sizes; computer people like to think in terms of powers of 2, so a "Terabyte" to computer people is 2^30, or 1073741824 bytes. However, disk-drive manufacturers started using powers-of-10 "Terabytes" (1000000000) so they could legally claim a "Terabyte" (or "Megabyte", as the case may be) but short-change us by not meeting the computer-referenced version of same, so that same "1TiB" drive is really only 954 of the Megabytes that really count.
In the case of our Flash drives, the reason it's smaller than the 16GB (and it's a real "computer 16GB", 16777216 bytes) is because of what I'd stated above, partitioning of the drive into partitions we can't consider available for data storage.
Click to expand...
Click to collapse
Well I'm still awake, but barely.
Sent from the mighty Note II

[FIRMWARE] AT&T Galaxy Note 3 N900A UNEXE STOCK + Analysis PIT + EFS BACKUP

Hi guys!
As you know, flashing of the older firmware is not possible because of the boot secure into bootloader.
But there is a way to downgrade the firmware without flashing bootloader that can't be to downgrade. But unfortunately it will increase the value KNOX WARRANTY BIT 0x1.
So I extracted parts of the firmware for your convenience and an opportunity to downgrade or flashing individual parts of stock firmware..
AP = Android Platform
BL = Bootloader
CP = Modem (radio)
CSC = Region & mobile operator
pit = Partition table
Download:
N900AUCUBMI1
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
***​
N900AUCUBMI9
N900AUCUBMJ5 - without system
Special tnx designgears for OneClick.exe
How to flash:

----------------------------------------------------------
PIT Magic - Analysis for: HLTE_USA_ATT_32G.pit
----------------------------------------------------------
Code:
<<< Pit File Start >>>
----------------------------------------------------------
<<< Unknown PIT File Properties >>>
----------------------------------------------------------
Entry Count: 29
Unknown 1: 1598902083
Unknown 2: 844251476
Unknown 3: 21325
Unknown 4: 14413
Unknown 5: 14137
Unknown 6: 52
Unknown 7: 0
Unknown 8: 0
----------------------------------------------------------
<<< PIT File Entries >>>
----------------------------------------------------------
----------------------------------------------------------
Entry Memory Address: 0x1C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 1
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 8*192
Block Count: 30*720
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: APNHLOS
Flash FileName: NON-HLOS.bin
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xA0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 2
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 38*912
Block Count: 117*632
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEM
Flash FileName: modem.bin
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x124
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 3
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 156*544
Block Count: 1*024
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL1
Flash FileName: sbl1.mbn
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x1A8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 4
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 157*568
Block Count: 64
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DBI
Flash FileName: sdi.mbn
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x22C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 5
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 157*632
Block Count: 64
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DDR
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x2B0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 6
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 157*696
Block Count: 4*096
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: ABOOT
Flash FileName: aboot.mbn
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x334
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 7
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 161*792
Block Count: 1*024
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RPM
Flash FileName: rpm.mbn
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x3B8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 8
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 162*816
Block Count: 1*024
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: TZ
Flash FileName: tz.mbn
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x43C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 9
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 163*840
Block Count: 20*480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PAD
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x4C0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 10
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 184*320
Block Count: 20*480
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash FileName: param.bin
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x544
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 11
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 204*800
Block Count: 28*672
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash FileName: efs.img.ext4
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x5C8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 12
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 233*472
Block Count: 6*144
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEMST1
Flash FileName: nvrebuild1.bin
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x64C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 13
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 239*616
Block Count: 6*144
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MODEMST2
Flash FileName: nvrebuild2.bin
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x6D0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 14
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 245*760
Block Count: 22*528
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash FileName: boot.img
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x754
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 15
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 268*288
Block Count: 26*624
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash FileName: recovery.img
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x7D8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 16
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 294*912
Block Count: 26*624
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FOTA
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x85C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 17
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 321*536
Block Count: 14*318
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BACKUP
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x8E0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 18
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 335*854
Block Count: 6*144
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FSG
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x964
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 19
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 341*998
Block Count: 2
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: FSC
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0x9E8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 20
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 342*000
Block Count: 16
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SSD
Flash FileName:
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xA6C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 21
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 342*016
Block Count: 16*384
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PERSIST
Flash FileName: persist.img.ext4
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xAF0
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 22
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 358*400
Block Count: 18*432
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PERSDATA
Flash FileName: persdata.img.ext4
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xB74
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 23
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 376*832
Block Count: 5*122*048
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SYSTEM
Flash FileName: system.img.ext4
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xBF8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 24
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 5*498*880
Block Count: 1*024*000
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash FileName: cache.img.ext4
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xC7C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 25
Attribute: 5 (READ / WRITE)
Update Attribute: 5 (FOTA)
Block Size: 6*522*880
Block Count:
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: USERDATA
Flash FileName: userdata.img.ext4
FOTA FileName: remained
----------------------------------------------------------
Entry Memory Address: 0xD00
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 70
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size:
Block Count: 34
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PGPT
Flash FileName: pgpt.img
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xD84
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 71
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 34
Block Count: 16
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PIT
Flash FileName: MSM8974.pit
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xE08
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 72
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 50
Block Count: 32
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MD5
Flash FileName: md5.img
FOTA FileName:
----------------------------------------------------------
Entry Memory Address: 0xE8C
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 73
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 61*071*327
Block Count: 33
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SGPT
Flash FileName: sgpt.img
FOTA FileName:
----------------------------------------------------------
<<< Pit File End >>>
----------------------------------------------------------

A.S._id said:
Added N900AUCUBMI9
Click to expand...
Click to collapse
I can used this in odin ????

SAMSUNG AT&T Galaxy Note 3 N900A EFS BACKUP/RESTORE
Instructions:
! Need for backup Root access and debugging USB
1. Extract from the zip and run .bat file
2. Is okay to your PC and follow the menu
Automatically create a text file of all the parameters of the device at the time of the copy
Automatic backup of efs:
* Odin flash file -. tar.md5,
* dd copy - raw.img
* tar.gz archive (need busybox)
Automatic naming of files and backup archive version of the firmware
Restore to choose from archives and backup images
Automatic start of Odin and the transition to the flashing mode when selecting Odin Restore

A.S._id said:
Of course
Click to expand...
Click to collapse
Bootloader is not been unlocked yet?

fern1221 said:
Bootloader is not been unlocked yet?
Click to expand...
Click to collapse
it's impossible - downgrade bootloader, only flash without it..

So does this mean we can now get a recovery and thus flash away. Maybe I'm not understanding what's happening here. Please go easy on me fellas.
Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app

androidmechanic said:
So does this mean we can now get a recovery and thus flash away. Maybe I'm not understanding what's happening here. Please go easy on me fellas.
Sent from my SAMSUNG-SM-N900A using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Now you can all...
You can extract any part to package into tar and flash it... but not bootloader
You can extract recovery.img, change stock recovery on cwm
You can extract system.img via dsixda kitchen and build custom zip...
You can analysis pit file and will know partition table for backup efs...
And more different things...
May be this thread better to move into development part
there she probably would have been more useful

A.S._id said:
Now you can all...
You can extract any part to package into tar and flash it... but not bootloader
You can extract recovery.img, change stock recovery on cwm
You can extract system.img via dsixda kitchen and build custom zip...
You can analysis pit file and will know partition table for backup efs...
And more different things...
May be this thread better to move into development part
there she probably would have been more useful
Click to expand...
Click to collapse
A.S., it sounds to me as you started an era of possible custom ROMs development for our N900A. Am I right?
The question I have since the first day with my phone is if it would be possible to flash the stock ROM of the N9005 (international version of the Note3) in this N900A variant. I do not use the phone in the AT&T network and would love to get rid of all AT&T stuff.
Even having the booloader locket, would this method let us able to do that?
Thanks!

cabtouch said:
A.S., it sounds to me as you started an era of possible custom ROMs development for our N900A. Am I right?
The question I have since the first day with my phone is if it would be possible to flash the stock ROM of the N9005 (international version of the Note3) in this N900A variant. I do not use the phone in the AT&T network and would love to get rid of all AT&T stuff.
Even having the booloader locket, would this method let us able to do that?
Thanks!
Click to expand...
Click to collapse
No, I'm hasn't n900a, but has n900 (exinos octa) and don't wanna to experiment with n900a...
To me was interesting to see firmware n900a, but don't find it.
So I extracted this from oneclickbin.exe and uploaded for users...

Would totally like to see what Designgears thinks of all this!

Can someone please extract the following files for me please
System/lib:
libaudio-ril.so
libreference-ril.so
libril.so
libril-qcril-hook-oem.so
librilutils.so
libsec-ril.so
libsecril-client.so
Need these files to make a flashable ril for tmob note 3 device for use in att.
More info http://forum.xda-developers.com/showthread.php?p=46995808#post46995808
Thanks

Pikezer1337 said:
Would totally like to see what Designgears thinks of all this!
Click to expand...
Click to collapse
But what hi can to say?
I'm extract this OneClick.exe without any scripts or bats on my UBUNTU 13.04 via Okteta hex editor...
p.s. I asked his, how to extract firmware from .exe before relise his .bat, but he don't answer me, so I myself had to think how to do it...

aalupatti said:
Can someone please extract the following files for me please
System/lib:
libaudio-ril.so
libreference-ril.so
libril.so
libril-qcril-hook-oem.so
librilutils.so
libsec-ril.so
libsecril-client.so
Need these files to make a flashable ril for tmob note 3 device for use in att.
More info http://forum.xda-developers.com/showthread.php?p=46995808#post46995808
Thanks
Click to expand...
Click to collapse
HERE

A.S._id said:
But what hi can to say?
I'm extract this OneClick.exe without any scripts or bats on my UBUNTU 13.04 via Okteta hex editor...
p.s. I asked his, how to extract firmware from .exe before relise his .bat, but he don't answer me, so I myself had to think how to do it...
Click to expand...
Click to collapse
No sorry I phrased that wrong. I didnt mean that you stole his work I meant I wanted to see if maybe he could get something with the bootloader going from this. You have done great work and hopefully some roms can come from this.

A.S._id said:
HERE
Click to expand...
Click to collapse
Thank yo so much for the files.

A.S._id said:
HERE
Click to expand...
Click to collapse
Is it safe to flash the modem files onto a tmobile device or am i goingn to end up with a brick ?

so can I use this to completely return to factory without triggering anything?

can anyone confirm the backup in post 3 works ok?
Thanks.

Hardcore!
Hehe, I use a hex editor on windows to do the same. However, there is a tool I use to do it now, its called exodin.
I have also downgraded with the older firmware exe and never tripped knox. As did many others with the original root method.

[LIBRARY]libpit-X Online PIT analysis Tool and Library

I would like to first start by sharing a bit of history behind this library. @Benjamin Dobell started the Heimdall project where he packet-sniffed the Odin(desktop client)/Loke(on-device server) protocol in order to create Heimdall, an open source flashing tool which I've personally used in my own projects Heimdall one-click and One-Click UnBrick as well as my current project, CASUAL. Heimdall was released with a very rough, but working, analysis of the PIT files and has been slowly increasing over time.
@Ralekdev , @Rebellos and myself began looking at the PIT files much later than Benjamin. Ralekdev and Rebellos were to reverse-engineer the bootloaders of several Samsung devices and was able to come up exploits while I somewhat brought the work together and assisted where I could. Ralekdev even identified proper sizes of data blocks and has created a few tools to assist.
Introduction
I'm happy to announce that we have 100% identification of all parts of the PIT files as they stand today. We are no longer working on identifying variables thanks to Ralekdev, Rebellos and Benjamin's work. We can read, and write and integrate PIT files into our Java Applications. As a demonstration of this library, i encourage you to
Analyze Your Pit File Online
If you don't have a PIT file, you can use this one. This will provide you with human-readable analysis of a PIT file.
This can also be accomplished locally on your computer with this file: http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar
Code:
[email protected]:~$libpit-X.jar GalaxyCamera.pit
PIT Name: Mx
Entry Count: 17
File Type: COM_TAR2
--- Entry #0 ---
ID: 80 Partition Name: BOOTLOADER
Filename: sboot.bin param: md5
Block Size: 1734 (887.8 kB)
Block range: 0 - 1733 (hex 0x0 - 0x6c5)
PartType: 2 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Bootloader partition resides on the AP EMMC.
--- Entry #1 ---
ID: 81 Partition Name: TZSW
Filename: tz.img param: md5
Block Size: 312 (159.7 kB)
Block range: 1734 - 2045 (hex 0x6c6 - 0x7fd)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #2 ---
ID: 70 Partition Name: PIT
Filename: camera.pit
Block Size: 16 (8.2 kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #3 ---
ID: 71 Partition Name: MD5HDR
Filename: md5.img param: in.md5
Block Size: 2048 (1.0 MB)
Block range: 50 - 2097 (hex 0x32 - 0x831)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #4 ---
ID: 1 Partition Name: BOTA0
Filename: -
Block Size: 8192 (4.2 MB)
Block range: 8192 - 16383 (hex 0x2000 - 0x3fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #5 ---
ID: 2 Partition Name: BOTA1
Filename: -
Block Size: 8192 (4.2 MB)
Block range: 16384 - 24575 (hex 0x4000 - 0x5fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #6 ---
ID: 3 Partition Name: EFS
Filename: efs.img param: md5
Block Size: 40960 (21.0 MB)
Block range: 24576 - 65535 (hex 0x6000 - 0xffff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #7 ---
ID: 4 Partition Name: PARAM
Filename: param.bin param: md5
Block Size: 16384 (8.4 MB)
Block range: 65536 - 81919 (hex 0x10000 - 0x13fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #8 ---
ID: 5 Partition Name: BOOT
Filename: boot.img param: md5
Block Size: 16384 (8.4 MB)
Block range: 81920 - 98303 (hex 0x14000 - 0x17fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #9 ---
ID: 6 Partition Name: RECOVERY
Filename: recovery.img param: md5
Block Size: 16384 (8.4 MB)
Block range: 98304 - 114687 (hex 0x18000 - 0x1bfff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #10 ---
ID: 7 Partition Name: RADIO
Filename: modem.bin param: md5
Block Size: 65536 (33.6 MB)
Block range: 114688 - 180223 (hex 0x1c000 - 0x2bfff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #11 ---
ID: 8 Partition Name: CACHE
Filename: cache.img param: md5
Block Size: 2097152 (1.1 GB)
Block range: 180224 - 2277375 (hex 0x2c000 - 0x22bfff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #12 ---
ID: 9 Partition Name: SYSTEM
Filename: system.img param: md5
Block Size: 3145728 (1.6 GB)
Block range: 2277376 - 5423103 (hex 0x22c000 - 0x52bfff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #13 ---
ID: 10 Partition Name: HIDDEN
Filename: hidden.img param: md5
Block Size: 737280 (377.5 MB)
Block range: 5423104 - 6160383 (hex 0x52c000 - 0x5dffff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #14 ---
ID: 11 Partition Name: OTA
Filename: -
Block Size: 16384 (8.4 MB)
Block range: 6160384 - 6176767 (hex 0x5e0000 - 0x5e3fff)
PartType: 5 FilesystemType: 1 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA:
This Basic format Data partition resides on the AP EMMC.
--- Entry #15 ---
ID: 12 Partition Name: TDATA param: TA
Filename: - param: erdata.img param: md5
Block Size: 409600 (209.7 MB)
Block range: 6176768 - 6586367 (hex 0x5e4000 - 0x647fff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA: param: Dmained
This EXT4 format Data partition resides on the AP EMMC.
--- Entry #16 ---
ID: 13 Partition Name: USERDATA
Filename: userdata.img
Block Size: 0 (0 B)
Block range: 6586368 - 6586367 (hex 0x648000 - 0x647fff)
PartType: 5 FilesystemType: 5 BinType: 0 DevType: 2
Offset:0 Size: 0 FOTA: remained
This EXT4 format Data partition resides on the AP EMMC. The partition will expand to fill the remainder of the EMMC.
Development Library/Downloads/Documentation
The libpit-X library is an extremely heavy overhaul of the libpit--Java- library by Benjamin Dobell. It features 100% accurate read/write/modification ability. It is also very well documented. I've submitted an issue for Benjamin to pull my changes. Until then you can find the library here.
Online documentation can be found here: http://javadoc.casual-dev.com/namespacecom_1_1casual__dev_1_1libpit_x.html
When you load a Library into your development environment, you need three parts. The Package, the Javadoc and the Source. The latest version of these three parts can be found here:
Package: http://jenkins.casual-dev.com/view/All/job/Build libpitX/ws/trunk/X/libpitX/dist/libpit-X.jar
Javadoc: http://jenkins.casual-dev.com/view/...runk/X/libpitX/dist/javadoc/*zip*/javadoc.zip
Source: http://jenkins.casual-dev.com/view/All/job/Build libpitX/ws/trunk/X/libpitX/src/*zip*/src.zip
Library Archives can be found here: http://goo.im/devs/AdamOutler/libpitX
Here's a picture of the library in action: http://dl.xda-developers.com/attach...3/7/8/Screenshot_from_2013-11-23_21_16_36.png
Automated Testing
Testing is conducted on EVERY SINGLE REVISION and compiled code is not published to the archvies if testing fails.
Latest test results: http://jenkins.casual-dev.com/job/CASUALbuild Test/lastBuild/console
Test code for this $X project: https://code.google.com/p/android-c...trunk/CASUALcore/test/CASUAL/archiving/libpit
And of course you can always test version yourself with our Analyze Your Pit File Online utility.
About
This is a $X project. The $ represents CASUAL for two reasons; CASUAL commands start with $, and the way CASUAL is commonly pronounced is cash-ual. In $X projects, the $ is silent. $X projects are not CASUAL core projects but rather offshoots. Rather than create an entire new repository for $X projects, we will host them in the http://android-casual.googlecode.com repository. For example, the working source code for this project is located in the CASUAL-Core and during build, the $X project is automatically created in the X.casual_dev.libpitX pacakge.
If you wish to contribute to this project, or any other CASUAL project, check out the "Developers" section of this page: http://casual-dev.com/about/. There's a lot to do and we are wiling to help you learn.

Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?

Adam, most PIT files I analyze have one or two strange partitions at the end..is this the fault of the analysis software or is just something else completely? Also, have you ever been able to extract the pit from a device that you was the same as ( md5 match) one you would get in a odin tar? The pit files I extract never end up being the exact same as the pit files that come in the odin tar for a particular device regardless of the method used; Heimdall and/or using dd if/of= w/ correct skip/count don't yield the right results. The PIT analysis tool you helped make lists everything correctly for the VZW GS4 but doesnt list the strange partition at the end thats found with other analysis tools like the one below, so I assume the last thing isn't a partition then?
TL;DR - What is the partition at the end with strange characters?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

Surge1223 said:
TL;DR - What is the partition at the end with strange characters?
Click to expand...
Click to collapse
That would appear to be a signature.

Please tell me this is going to lead 16gig Samsung Sg4 users to get more than 9 gigs free space when using a non touch wiz ROM . Great project and congrats

igoa said:
Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?
Click to expand...
Click to collapse
This isn't a utility, it's a library. You would include it in your Android Application or Java Desktop App.
Here's how you would use it for your project
Code:
Class BlockResizer{
public void remove100BlocksFromCACHE(){
//Open the PIT file
PitData pd=new PitData("mypit.pit");
//get the CACHE partition
PitEntry CACHE=pd.findEntry(String partitionName);
//Remove 100 blocks from CACHE
int blocksToRemove=100;
CACHE.block_count=CACHE.block_count-blocksToRemove;
//Loop through the rest of the partitions and bump them up 100 blocks.
for (int i=CACHE.part_id+1; i<pd.entryCount; i++){
pd.getEntry(i).BLOCK_START=pd.getEntry(i).BLOCK_START-blocksToRemove;
}
//write out the new PIT to "newPit.pit"
pd.pack(new DataOutputStream(new FileOutputStream("newPit.pit");
}
This would work just fine assuming that the rest of the partitions after the CACHE are in proper order.

igoa said:
Please tell how to redistribute space from cache and hidden partions to increase user space with your utility?
Click to expand...
Click to collapse
Hey, i just added the ability to do this easily after reviewing the code for a bit. The commit is still processing and the new library and documentation should be up shortly... Here goes a partition resize
Code:
public void resize(){
PitData instance = new PitData("MyPitFile.pit");
String partName="CACHE"; //partition name to change
int changeToSize=-2000; //size to change partition (-2000 blocks= 1 megabyte smaller)
try {
instance.resizePartition(partName, changeToSize); //actually resizes the partiton and all others are moved.
} catch (ClassNotFoundException ex) {
Logger.getLogger(PitDataTest.class.getName()).log(Level.SEVERE, null, ex); //this occurs if the partition specified is not found
}
instance.pack(new DataOutputStream(new FileOutputStream("newPit.pit"); //write out the new PIT to "newPit.pit"
}
This code has accompanying test code. So, if you'd like to resize a PIT, all you need to do is add the libpitX library into an existing project then run the code above.

AdamOutler said:
That would appear to be a signature.
Click to expand...
Click to collapse
This is very interesting. Is there anything we can do with it? Or is this read only/unknown flash protocol?

ryanbg said:
This is very interesting. Is there anything we can do with it? Or is this read only/unknown flash protocol?
Click to expand...
Click to collapse
You can append it to the end of the file.

AdamOutler said:
You can append it to the end of the file.
Click to expand...
Click to collapse
So it's not possible to write my own certificate to this 'partition' yet?

ryanbg said:
So it's not possible to write my own certificate to this 'partition' yet?
Click to expand...
Click to collapse
Yeah but it's worthless without Samsung's private key.

AdamOutler said:
Yeah but it's worthless without Samsung's private key.
Click to expand...
Click to collapse
Have you seen this post? here
and more specifically this:
ERROR: Image Invalid, X509_Certificate is NULL!
ERROR: Boot Invalid, RSA_KEY is NULL!
ERROR: Image Invalid! Decryption failed!
ERROR: Image Invalid! Please use another image!
Does this make a difference?

That's just strings and it says what error you'll get if you put in a null signature.

@AdamOutler for the VZW Galaxy S4 I analyzed the PIT file produced by Heimdall and it reports the last four partitions as "remained" so I decided to manually extract my PIT file using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
which is specific to MSM8690 S4's and the PIT analysis now shows the "remained" partitions actual values and you can see the PIT I extracted is factory signed, because I compare the md5 to the PIT from a factory Odin tar here so is this problem unique to just the S4 or is it a Heimdall problem? I assumed Heimdall just extracted the padded PIT file but even so it should still show the information for the last 4 partitions.
Before
Code:
--- Entry #29 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #30 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #31 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #32 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
After
Code:
--- Entry #29 ---
ID: 70 Partition Name: PGPT
Filename: pgpt.img
Block Size: 34 (17.4kB)
Block range: 0 - 33 (hex 0x0 - 0x21)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PGPT partition, identified as partition number 70, is 17.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as pgpt.img.
--- Entry #30 ---
ID: 71 Partition Name: PIT
Filename: MSM8960.pit
Block Size: 16 (8.2kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PIT partition, identified as partition number 71, is 8.2kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as MSM8960.pit.
--- Entry #31 ---
ID: 72 Partition Name: MD5
Filename: md5.img
Block Size: 32 (16.4kB)
Block range: 50 - 81 (hex 0x32 - 0x51)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The MD5 partition, identified as partition number 72, is 16.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as md5.img.
--- Entry #32 ---
ID: 73 Partition Name: SGPT
Filename: sgpt.img
Block Size: 33 (16.9kB)
Block range: 30777311 - 30777343 (hex 0x1d59fdf - 0x1d59fff)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The SGPT partition, identified as partition number 73, is 16.9kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as sgpt.img.

bump

Surge1223 said:
@AdamOutler for the VZW Galaxy S4 I analyzed the PIT file produced by Heimdall and it reports the last four partitions as "remained" so I decided to manually extract my PIT file using
Code:
su
dd if=/dev/block/mmcblk0 of=/sdcard/sch1545.pit bs=8 count=580 skip=2176
which is specific to MSM8690 S4's and the PIT analysis now shows the "remained" partitions actual values and you can see the PIT I extracted is factory signed, because I compare the md5 to the PIT from a factory Odin tar here so is this problem unique to just the S4 or is it a Heimdall problem? I assumed Heimdall just extracted the padded PIT file but even so it should still show the information for the last 4 partitions.
Before
Code:
--- Entry #29 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #30 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #31 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
--- Entry #32 ---
ID: -1 Partition Name: remained
Filename: remained
Block Size: -1 (-512 B)
Block range: -1 - -3 (hex 0xffffffff - 0xfffffffd)
PartType: -1 FilesystemType: -1 BinType: -1 DevType: -1
Offset:-1 Size: -1 FOTA: remained
This unknown format unknown partition resides on the CP unknwon. The partition will expand to fill the remainder of the unknwon.
After
Code:
--- Entry #29 ---
ID: 70 Partition Name: PGPT
Filename: pgpt.img
Block Size: 34 (17.4kB)
Block range: 0 - 33 (hex 0x0 - 0x21)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PGPT partition, identified as partition number 70, is 17.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as pgpt.img.
--- Entry #30 ---
ID: 71 Partition Name: PIT
Filename: MSM8960.pit
Block Size: 16 (8.2kB)
Block range: 34 - 49 (hex 0x22 - 0x31)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The PIT partition, identified as partition number 71, is 8.2kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as MSM8960.pit.
--- Entry #31 ---
ID: 72 Partition Name: MD5
Filename: md5.img
Block Size: 32 (16.4kB)
Block range: 50 - 81 (hex 0x32 - 0x51)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The MD5 partition, identified as partition number 72, is 16.4kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as md5.img.
--- Entry #32 ---
ID: 73 Partition Name: SGPT
Filename: sgpt.img
Block Size: 33 (16.9kB)
Block range: 30777311 - 30777343 (hex 0x1d59fdf - 0x1d59fff)
FilesystemType: 1 PartType: 5 DevType: 2 BinType: 0
Offset:0 Size: 0 FOTA:
The SGPT partition, identified as partition number 73, is 16.9kB in size and carries a Basic format. This partition resides on the Data section of the AP EMMC. It identifies itself to Odin as sgpt.img.
Click to expand...
Click to collapse
@Benjamin Dobell may know something about this.

Can anyone share the file http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar? The link fails.

t2060079 said:
Can anyone share the file http://goo.im/devs/AdamOutler/libpitX/libpit-X-R917.jar? The link fails.
Click to expand...
Click to collapse
I'm looking for the same stuff. I think that the dev has relocated to here:
http://3of5.com/builds.casual-dev.com/files/libpit-X/
HTH, J

Problem in changing the partition layout of the internal MMC SD card

I have a Nexus S 9023 fresh of bootloader unlocking becasue I want to solve a limitation due to the storage available for the installable apps (i.e. the /data partion). I know there are apps like App2SD or Link2SD but I want to follow another cleaner solution.
So I unlocked the bootloader and ran the cyanogenrecovery.20140922.crespo.img recovery to try repartitioning the SD card. On the host system connected to the Nexus S with an USB cable:
Code:
adb reboot bootloader
fastboot boot cyanogenrecovery.20140922.crespo.img
As you probably know the internal SD card (i.e. MMC flash) has three partitions with the following layout:
Code:
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
p
Model: MMC SEM16G (sd/mmc)
Disk /dev/block/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB ext4 system
2 538MB 1612MB 1074MB ext4 userdata
3 1612MB 15.9GB 14.3GB fat32 media
After a few commands using the parted utility
Code:
~ # parted /dev/block/mmcblk0
GNU Parted 1.8.8.1.179-aef3
Using /dev/block/mmcblk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)
(parted) rm 2
rm 2
(parted) rm 3
rm 3
(parted) mkpart primary ext4 538MB 3098MB
mkpart primary ext4 538MB 3098MB
(parted) name 2 userdata
name 2 userdata
(parted) mkpart primary fat32 3098MB 100%
mkpart primary fat32 3098MB 100%
(parted) name 3 media
name 3 media
(parted) p
p
Model: MMC SEM16G (sd/mmc)
Disk /dev/block/mmcblk0: 15.9GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 1049kB 538MB 537MB ext4 system
2 538MB 3098MB 2560MB ext4 userdata
3 3098MB 15.9GB 12.8GB fat32 media msftres
I successfully managed to change the layout of the disk:
Code:
~ # cd /dev/block/platform/s3c-sdhci.0/
/dev/block/platform/s3c-sdhci.0/by-name # ln -s /dev/block/mmcblk0p1 system
/dev/block/platform/s3c-sdhci.0/by-name # ln -s /dev/block/mmcblk0p2 userdata
/dev/block/platform/s3c-sdhci.0/by-name # ln -s /dev/block/mmcblk0p3 media
/dev/block/platform/s3c-sdhci.0/by-name # df -h
Filesystem Size Used Available Use% Mounted on
tmpfs 193.1M 136.0K 193.0M 0% /dev
tmpfs 193.1M 12.0K 193.1M 0% /tmp
tmpfs 193.1M 0 193.1M 0% /storage
tmpfs 193.1M 0 193.1M 0% /mnt/secure
tmpfs 193.1M 0 193.1M 0% /mnt/fuse
/dev/block/mtdblock4 469.5M 2.3M 467.2M 0% /cache
/dev/block/vold/179:3
11.9G 1.0G 10.9G 8% /storage/sdcard0
/dev/block/platform/s3c-sdhci.0/by-name/userdata
2.3G 132.0M 2.1G 6% /data
Up to here everthing looks fine.... So where it he problem? As soon as I reboot the partition layout is lost :crying: (this already happens in the recovery boot without booting the system regularly).
What am I doing wrong? Is the bootloader a supervisor of the partition layout correcting any difference comparing to a predefined value? If I try to boot the system I am asked about a password to decrypt the data partition, I guess Android doesn't find any useful file in the data partition so it thinks the partition is crypted

shouldnt you flash the custom recovery for that type of partitioning?
Sent from my Nexus S using XDA Premium 4 mobile app

g33k0 b3lk0w said:
shouldnt you flash the custom recovery for that type of partitioning?
Click to expand...
Click to collapse
First of all the procedure with Clockworkmod recovery doesn't work. Nevertheless that procedure is not what I want to obtain. because the partitioning done with CWM would divide the original FAT32 partition in two parts, the first will be dedicated to Link2SD or similar apps (so it will be an ext4) and the second to the FAT32 partition. In this way the partition layout would be:
Code:
/dev/block/mmcblk0 -> system partiotion
/dev/block/mmcblk1 -> userdata partition
/dev/block/mmcblk2 -> additional userdata partition for Link2SD or similar apps
/dev/block/mmcblk3 -> FAT32 partition
I don't see the reason in using 2 userdata partions + LinkSD when it's clearly easier to just enlarge the /dev/block/mmcblk1 partition. Moreover this solution preserves the size of the system partition but eventually I want to increase also that (for instance CM11 + gapps need more space).
I even tried chaning only the original FAT32 partition mimicking the 4 partition layout described above but as soon as I reboot I loose the changes. I suspect the problem is due to the bootloader which checks the partion layout during boot and restores the PIT

@efferre
Have you seen this? I have managed to manipulate succesfully around the nexus s storage. I am going to upload the latest cm11 m12 rom in the next couple of days.

KreAch3R said:
Have you seen this? I have managed to manipulate succesfully around the nexus s storage. I am going to upload the latest cm11 m12 rom in the next couple of days.
Click to expand...
Click to collapse
Yes, I have seen your post but I haven't tried yet that solution up to now. I prefer keeping the things simple
As the partition layout on the eMMC is using the new GPT standard (besides the MBR), I have also tried with gdisk (after having crosscompiled for ARM), a tool which is GPT-aware. Same result
Last step, I want to play with the PIT data. I have found heimdall which is capable to dump PIT data and later write back a modified version as done here using PITMagic.
Here is the PIT dump I get after putting the phone in download mode:
Code:
heimdall print-pit --file i9023.pit.orig
Heimdall v1.4.1
Copyright (c) 2010-2014 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/
This software is provided free of charge. Copying and redistribution is
encouraged.
If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/
Entry Count: 16
Unknown 1: 0
Unknown 2: 0
Unknown 3: 0
Unknown 4: 0
Unknown 5: 0
Unknown 6: 0
Unknown 7: 0
Unknown 8: 0
--- Entry #0 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 0
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 1
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: IPBL
Flash Filename: bootloader.img
FOTA Filename:
--- Entry #1 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 1
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 7
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL
Flash Filename:
FOTA Filename:
--- Entry #2 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 2
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 7
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SBL2
Flash Filename:
FOTA Filename:
--- Entry #3 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 3
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 4
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PARAM
Flash Filename:
FOTA Filename:
--- Entry #4 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 4
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 5
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MISC
Flash Filename:
FOTA Filename:
--- Entry #5 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 5
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 32
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash Filename: boot.img
FOTA Filename:
--- Entry #6 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 6
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 32
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash Filename: recovery.img
FOTA Filename:
--- Entry #7 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 7
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 1878
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: CACHE
Flash Filename: cache.img
FOTA Filename:
--- Entry #8 ---
Binary Type: 1 (CP)
Device Type: 0 (OneNAND)
Identifier: 8
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 54
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RADIO
Flash Filename: radio.img
FOTA Filename:
--- Entry #9 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 9
Attributes: 1 (Read/Write)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 27
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: EFS
Flash Filename:
FOTA Filename:
--- Entry #10 ---
Binary Type: 0 (AP)
Device Type: 0 (OneNAND)
Identifier: 10
Attributes: 0 (Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 256
Partition Block Count: 1
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: DGS
Flash Filename: dgs.img
FOTA Filename:
--- Entry #11 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 0
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 512
Partition Block Count: 2048
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: PGPT
Flash Filename: emmc.img
FOTA Filename:
--- Entry #12 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 1
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 512
Partition Block Count: 1048576
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SYSTEM
Flash Filename: system.img
FOTA Filename:
--- Entry #13 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 2
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 512
Partition Block Count: 2097152
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: USERDATA
Flash Filename: userdata.img
FOTA Filename:
--- Entry #14 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 3
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 512
Partition Block Count: 33554432
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: MEDIA
Flash Filename: media.img
FOTA Filename:
--- Entry #15 ---
Binary Type: 0 (AP)
Device Type: 2 (MMC)
Identifier: 4
Attributes: 2 (STL Read-Only)
Update Attributes: 0
Partition Block Size/Offset: 512
Partition Block Count: 33
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: SGPT
Flash Filename:
FOTA Filename:
but I have a few doubts:
can I write back the modified PIT (on the eMMC part) without having to flash back the OneNand parts (i.e. the repartitioning is touching only the modified parts of the PIT, in my case only the eMMC)?
after looking at the PIT sections, in particular at #14, I see a discrepancy because it says that the size of the MEDIA partition is more than 17GB which is of course not possible because the whole eMMC is only 16GB (I have opened a ticket for @benjamin)

This is exactly what I wanted to do on my phone, but I don't have too much spare time at the moment to experiment with it.
It's a bad news that it doesn't seem to work (my original idea was to follow this approach: http://forum.xda-developers.com/xperia-s/s-development/tutorial-increase-data-partition-t2821058 ). That tutorial says that "you have to re-flash your rom", did you re-flash it after re-partitioning the drive?

@efferre
Unfortunately, this is too low level for me. I have never messed around with partitions besides the normal PC formatting stuff. I just wanted to let you know that you can re-partition your Nexus S however you want using lvm. I have a very functional Nexus S with a combined 16GB storage (just like the newer smartphones) without any loss of performance (at least with my usage).
Good luck with your endeavors!

ekerazha said:
That tutorial says that "you have to re-flash your rom", did you re-flash it after re-partitioning the drive?
Click to expand...
Click to collapse
I don't think the flashing of the ROM changes the PIT and that procedure you pointed is for a Sony Xperia S device (i.e. not Samsung so I don't know if it has even a PIT), I think the reflashing is mandatory only when you change the /system partition.
Out of curiosity I have retested again the procedure changing the partition table with gdisk in recovery mode and, during the same session, uploading cm-10.2.1-crespo.zip with adb sideload. After the reboot the old partition table is recovered to the original values. The data in the media partition have not been touched, only the partition layout is changed by the bootloader.
Looking at the R880 source, the SBL is playing with the partition table so I'm pretty convinced that I need to upgrade the PIT, probably it's only necessary to change the PIT itself and the bootloader will change the partition layout for me
The next step would be to use heimdall to change the PIT but, as written above, I have a doubt of the data it reports dumping the current PIT so I want to wait for Benjamin's comment about the correctness of the dumped PIT data (do you know if it's possible to get the PIT with Odin for a comparison?) and some details the procedure heimdall follows.
For completeness, from the PIT acquired with heimdall, here is the calculated layout of the eMMC memory:
Code:
entry start stop size
11 0 1048575 1048576 (1 MiB)
12 1048576 537919487 536870912 (512 MiB)
13 537919488 1611661311 1073741824 (1 GiB)
14 1611661312 18791530495 17179869184 (16 GiB) ?????
15 18791530496 18791547391 16896 (16.5 kiB)
while this is the layout returned by gdisk:
Code:
~ # sgdisk -p /dev/block/mmcblk0
Disk /dev/block/mmcblk0: 31105024 sectors, 14.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 31104990
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 1050623 512.0 MiB 0700 system
2 1050624 3147775 1024.0 MiB 0700 userdata
3 3147776 31104990 13.3 GiB 0700 media
As you can see there is a discrepancy in the media partition size (14th entry of the PIT).

I thought the same approach used for the Xperia S would also work on the Nexus S. Unfortunately, I don't have any experience with this "PIT" and I never really used Odin as I always flashed everything through fastboot (the Nexus way).

ekerazha said:
I thought the same approach used for the Xperia S would also work on the Nexus S. Unfortunately, I don't have any experience with this "PIT" and I never really used Odin as I always flashed everything through fastboot (the Nexus way).
Click to expand...
Click to collapse
Yes, me too, up to now I have always used fastboot to flash images. I'm afraid of screwing up the device following other procedure so I want to be 100% before trying anything with heimdall.
PIT is the acronym of Partition Information Table, it's something typical of Samsung devices and it is somewhere hidden in the flash (more information in this thread). For instance for the Galaxy Nexus I have found some code here which references to its structure and location but nothing specific for the Nexus S.
Let me know if you can manage to change the partition layout without using LVM

[TOOL][NOT TESTED] BOOT partition repartitioner

I am not responsible for bricked devices, dead SD cards, thermonuclear war, or you getting fired because the alarm app failed. Please do some research if you have any concerns about features included in this ROM before flashing it! YOU are choosing to make these modifications, and if you point the finger at me for messing up your device, I will laugh at you.
FLASHING THIS WILL DELETE /BOOT AND /RECOVERY PARTITION!!
VERY IMPORTANT: YOU WON'T BE ABLE TO FLASH TWRP OR ANY OTHER RECOVERY, AS /RECOVERY WILL BE SHRINKED TO 23 MiB AND TWRP SIZE IS AT LEAST 28 MiB.
this is a repartitioner for /boot partition (to 47 MiB instead of 32 MiB), to make it to work i had to shrink /recovery partition (as it's the nearest partition; /boot is /dev/block/mmcblk0p10 and /recovery is /dev/block/mmcblk0p11), it works in this way:
/tmp/sgdisk $DK --delete 10 -> deletes /boot
/tmp/sgdisk $DK --delete 11 -> deletes /recovery
/tmp/sgdisk $DK --new=10:124928:221184 -> creates /boot again, with Block Size: 124.928 and with Block Count: 96.256
/tmp/sgdisk $DK --new=11:221184:268288 -> creates /recovery again with Block Size: 268.288 and with Block Count: 47.104
to get some infos from stock j6 PIT file i used Pit Magic (https://forum.xda-developers.com/t/...-samsung-pit-creator-editor-analyzer.1916936/)
Stock BOOT Partition:
Code:
----------------------------------------------------------
Entry Memory Address: 0x754
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 10
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 124.928
Block Count: 65.536
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: BOOT
Flash FileName: boot.img
FOTA FileName:
Stock RECOVERY Partition:
Code:
----------------------------------------------------------
Entry Memory Address: 0x7D8
----------------------------------------------------------
Binary Type: 0 (UNKNOWN)
Device Type: 2 (MMC)
Identifier: 11
Attribute: 5 (READ / WRITE)
Update Attribute: 1 (FOTA)
Block Size: 190.464
Block Count: 77.824
File Offset (Obsolete): 0
File Size (Obsolete): 0
Partition Name: RECOVERY
Flash FileName: recovery.img
FOTA FileName:
To get these numbers i just did some mathematical proportions:
using a unix blocks to megabytes converter (http://www.unitconversion.org/data-storage/blocks-to-megabytes-conversion.html) i found that 65.536 blocks correspond to 32 MiB.
so i did:
Code:
65.536 : 32 = x : 47
where 65.536 is the block count, 32 are the corrisponding MiB, x is the block count to find to get 47 MiB and 47 are the MiB i wanted to have.
so i just did: (65.536 * 47) / 32 = 96.265 -> corresponding to 47 MiB.
CREDITS: @ProtoDeVNan0 for his EPR