Here is the partition info for spica.
this is usefull information, before you update your image, check to see if the file size of your image is not exceed the size of the partition
For examples if you want to change the boot logo. In spica, the boot logo (logo.png) is located in partition 3. So if you have a new boot logo, make sure that file size of the image (logo.png) must below the size of partition 3 which is 384KB (0x00060000).
#cat /proc/rfs/bmlinfo
XSR VERSION: 1.5.2-p4
minor position size blocks id
1: 0x00000000-0x00020000 0x00020000 1 0
2: 0x00020000-0x00160000 0x00140000 10 1
3: 0x00160000-0x001c0000 0x00060000 3 2
4: 0x001c0000-0x006c0000 0x00500000 40 3
5: 0x006c0000-0x0c240000 0x0bb80000 1500 4
6: 0x0c240000-0x164c0000 0x0a280000 1300 5
7: 0x164c0000-0x1b540000 0x05080000 644 6
8: 0x1b540000-0x1dd40000 0x02800000 320 7
9: 0x1dd40000-0x1ed40000 0x01000000 128 8
10: 0x1ed40000-0x1f540000 0x00800000 64 9
(0) bad mapping information
No BadBlock RsvBlock
0: 802 4014
Click to expand...
Click to collapse
bolons said:
For examples if you want to change the boot logo. In spica, the boot logo (logo.png) is located in partition 3. So if you have a new boot logo, make sure that file size of the image (logo.png) must below the size of partition 3 which is 384KB (0x00060000).
Click to expand...
Click to collapse
You are wrong! Together with the boot logo in the same partition contains the variables for the boot, if you overwrite them, then you turn spica in brick!
before giving such information to use the google search!
LeshaK said:
You are wrong! Together with the boot logo in the same partition contains the variables for the boot, if you overwrite them, then you turn spica in brick!
before giving such information to use the google search!
Click to expand...
Click to collapse
You are correct Leshak.
Not all bytes in partition 3 is reserved for logo.png.
after i dump the partition into file and looking into binary, there is a data after PNG data
#dd if=/dev/bml3 of=/bml3_dump bs=1
$adb pull /bml3_dum
Click to expand...
Click to collapse
bolons said:
You are correct Leshak.
Not all bytes in partition 3 is reserved for logo.png.
after i dump the partition into file and looking into binary, there is a data after PNG data
Click to expand...
Click to collapse
Can Anyone help me to get APPS2SD for my rooted spica 2.1?
I have rooted my spica from here - http://www.addictivetips.com/mobile/root-samsung-galaxy-spica-i5700-with-leshaks-kernel/
Can any1 upload an original bml3?
I've dumped mine, but I have a 172 kb boot logo so I can't verify if there was any data under that...
Anyway I examined mine and there's only FF-s till 0x00030000 (192k) so I guess that's may be the logo size limit.
Thanks!
u-foka said:
Can any1 upload an original bml3?
I've dumped mine, but I have a 172 kb boot logo so I can't verify if there was any data under that...
Anyway I examined mine and there's only FF-s till 0x00030000 (192k) so I guess that's may be the logo size limit.
Thanks!
Click to expand...
Click to collapse
You're right. The max size for logo.png is 192kB.
Does anyone have this tablet? I can't find this tablet on the website.
I want to know if this tablet can be upgraded to v3.0 or higher when ics comes on CyanogenMod?
Technical Specifications
Weight: 426 gr
Dimensions: 202 x 140 x 11 mm
CPU Samsung Cortex A8 1.0 GHZ
OS: Android 2.2
WiFi 802.11 b/g/n
Bluetooth
Capacitive Multi Touch Screen
7" TFT-LCD Display
SDRAM 512 MB
4 GB Internal Memory
Micro SD/SDHC slot (Up to 32 GB)
G-Sensor
Mini-HDMI port out
Mini-USB port
Microphone
Adobe Flash Compatible
Camera: 2 MP
2 Stereo Speakers
I've the exact same question about the Cyanogen Mod.
Also, I would like to know if it's possible to perform a COMPLETE back up (root or nand backup) without this mod. (without nandroid backup)
The device is also released as the BQ DaVinci. That company released a firmware update to Gingerbread a couple of days ago.
However, I'm a bit reluctant to install it, because it'll change the splash screen and who knows what else.
The update procedure seems to be different from other devices: you have to put a folder called SDFUSE on the root of the SD-card and reboot. The folder contains these files:
SDFUSE
--> ramdisk-uboot.img
--> sdfuse.txt
--> system.img
--> u-boot.bin
--> zImage
Does anyone have any idea on how to reverse-assemble these files (i.e. extract or replace boot splash screen,...)
Mahalaleel said:
I've the exact same question about the Cyanogen Mod.
Also, I would like to know if it's possible to perform a COMPLETE back up (root or nand backup) without this mod. (without nandroid backup)
The device is also released as the BQ DaVinci. That company released a firmware update to Gingerbread a couple of days ago.
However, I'm a bit reluctant to install it, because it'll change the splash screen and who knows what else.
The update procedure seems to be different from other devices: you have to put a folder called SDFUSE on the root of the SD-card and reboot. The folder contains these files:
SDFUSE
--> ramdisk-uboot.img
--> sdfuse.txt
--> system.img
--> u-boot.bin
--> zImage
Does anyone have any idea on how to reverse-assemble these files (i.e. extract or replace boot splash screen,...)
Click to expand...
Click to collapse
There is not much help here..
I think we can forget an answer to our question
From experience I can say 2.3.4 DaVinci upgrade works fine on BeBook Live, even Angry Birds Space is now playable!
Indeed so, I discovered that as well.
But... still no possibility to upgrade to a custom ROM apparently?
AGSO Somx 7 GS20 has same format for their ROMs. In my understanding:
zImage - linux kernel compressed
u-boot-config - ???
ramdisk-uboot.img - ram disk image for loading
system.img - image of /system disk
To convert other ROMs into this format you have to get kernel and ramdisk images from boot.img, then make system partition image (create virtual disk with same size, make filesystem on it, move all /system files to the disk).
After some researching:
zImage - linux kernel gzip-compressed (just kernel, with empty initramfs inside) with built-in unpacker code at start
u-boot-config.bin - u-boot loader and/or its config (perhaps, stage 2 loader as S5PC110 has two-stage loader)
ramdisk-uboot.img - initramfs image (initramfs archive by cpio, then gz [output name "ramdisk"], then mkimage from u-boot distribution)
system.img - image of /system disk (ext4, not compressed)
BQ put ICS (Android 4.0) online for the BQ DaVinci, works fine also (booting takes a bit). Definitely a good idea if you still are using the device, Skype and so on works smooth!
Hi guys.
Several months ago, I have bought a rk2918 based tablet and succesfully rooted it as you can see in this thread. I haven´t managed to take the time and have more fun with this tablet until today, when I decided to tweak it a bit. So, I´m facing a bit of a problem and don´t know how to solve it. I wan´t to create a custom partition layout, in other words - I want to increase data and system partitions on this tablet. So if anybody understands mtd partitioning I would be grateful for any help. So here´s the current partition layout:
Code:
0[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache), 112,4 MB
[email protected](userdata), 504 MB
[email protected](kpanic),
[email protected](system) 247 MB,
[email protected](user) 2.58 GB
So, I want to decrease "user" partition for 1024 MB, increase "userdata" partition for 950 MB and increase "system" partition for 74 MB. If someone understands how to do it, I would really appreciate it!
Anybody? I´m just refreshing this thread so people can notice it..
Root protab25
Sirrocco, could you make a root rights on this rom: Firmware Update TAB-PROTAB25 model 2.2_2.3 NOT for other versions.zip 179 MB
Please go to the link itself, I was a novice user can not post URL downloads.pointofview-online.com
The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)
Ficik said:
The format is [email protected]
so if you want to increase size of userdata by 950MB you need to add 950×2048 which is in hexa 1DB000 to size of [email protected](userdata) which is
[email protected](userdata)
add same value to position of all following partitions (kpanic, system, user).
last partition is specified only by starting position and uses rest of memory so you don't need to worry about it's size
[email protected](user)
Click to expand...
Click to collapse
Omg, thank you man! Cheers! :highfive:
See Post #2 for current known stock partition parameters for various devices. Your contributions for missing devices are welcome and appreciated. Cheers!
Introduction
This guide / reference aims to be a complete article on customizing, resizing and/or re-ordering the internal partition layout on most (any?) Android MTD-based device. I have seen many questions around the various forums on how to get more internal data so I thought I'd share my developments. Hopefully this will become a valuable resource for kernel builders/hackers.
The guide is especially valuable (and, in the case of my kernel builds, originally designed for) the Xperia 2011 line, but from what I know it could be applied to nearly any Android device where kernel source/flashing is possible.
I would like to gather stock partition information for various devices and place them into Post #2. If you can at least give me your Partition Info from ATAG (see "Gathering information" section), I can create a reference for all kernel developers. Thank you!
Requirements
Android SDK
Ability to build a kernel (this guide does not teach that)
Ability to flash a kernel (unlocked bootloader, etc)
Bootloader which exposes Partition info via ATAG on startup (see "Gathering information" section)
Device which uses MTD Partition Map (Don't know how to check this, I think most Android devices do anyway)
Warning
As far as I know, following this guide and using precise calculation that you double and triple check before flashing will not result in a hard brick - however I can not guarantee it. Some devices may have "obscure" partition maps or some "protected" sectors for one reason or another, and modifying these *may* result in either a hard-brick (unlikely) or a permanent inability to restore your device to 100% stock (very likely) for warranty and/or DRM purposes. You have been warned. I/we/anyone may not be held accountable for any of these events should they occur, for you are doing this at your own risk and with your own responsibility.
Gathering information
The first thing you'll want to do for the sake of accuracy is to flash to a 100% stock firmware. In the case of Xperia 2011 devices, flash the latest stock FTF for your device.
With the stock firmware now installed, the second thing you will need to do is to flash a custom kernel that is rooted and has busybox installed. In most cases, a CM7/9/10 kernel will do nicely.
Power-off your device. Execute the following command from shell/console, and then press enter:
Code:
adb wait-for-device && adb shell dmesg
After pressing enter, the console will wait at the prompt as intended. Now, power on your device and immediately plug in the USB cable. I assume the ADB drivers are already installed.
Shortly (5-15 seconds) you should see a mass output from the kernel followed by a return to your shell prompt. If you don't, either your kernel or bootloader does not support it. Try a different kernel. If you still don't, then sorry but I think we can't do it for your device.
Scroll right to the top of the dmesg output, you should see something similar to this:
Code:
<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.32.9-KRsH ([email protected], Linaro 4.7) (gcc version Linaro 4.6.2 20111004) #8 PREEMPT Thu Oct 25 15:57:27 EST 2012
<4>[ 0.000000] CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7d
<4>[ 0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache
<4>[ 0.000000] Machine: zeus
<6>[ 0.000000] Partition (from atag) system -- Offset:2e4 Size:9c4
<6>[ 0.000000] Partition (from atag) userdata -- Offset:ca8 Size:be0
<6>[ 0.000000] Partition (from atag) cache -- Offset:1cb4 Size:32c
<6>[ 0.000000] Partition (from atag) appslog -- Offset:1888 Size:42c
<4>[ 0.000000] Memory policy: ECC disabled, Data cache writeback
...see those "Partition (from atag)" lines? That's what we need! Copy this information down and move on to the next section.
Additional verification and hidden partitions (optional)
As far as I know, this is only possible with Xperia 2011 devices. If you know of a method for other devices, please let me know.
We can additionally verify the ATAG information and map extra "hidden" partitions such as boot (kernel) by examining the SIN files inside an FTF. I will assume that you know how to use Flashtool already as I won't go into much detail here.
First, we need to enable the development features of Flashtool. In the program folder, open "config.properties" and edit/add the line like so:
Code:
devfeatures=yes
Next, extract your stock FTF bundle with any ol' ZIP extractor, load Flashtool, and select "Tools" > "SIN Editor", and open a particular SIN file that you want to verify/unhide. In this example, we will open system.sin. The "Partition Info" field is what we want. Behold:
Code:
STOCK SIN:
system: 0400000001000080E4020000C4090000
-- --|------||------|
| | | |
type? (elf/yaffs) _/ | | \____ byte-reversed size
| |
unknown ____/ \____________ byte-reversed offset
The second last 8-bytes are the offset and the last 8-bytes are the size. By "byte-reversed" I mean that you read each byte from end to beginning, but not swap the bytes themselves. Thus the size above, reading "C4090000" is actually "000009C4". And as you can see, this matches 100% to our ATAG of 9c4 for system size. Correct sir! Additionally, the offset of "E4020000" > reversed to "000002E4" also matches.
So now, we can open "kernel.sin" and do the same, because we also want to partition "boot" (why not?). In this device (Xperia Play/Xperia Neo L), kernel.sin gives us 03000000220000808002000064000000 which means that the size is 64 and the offset is 280.
Calculations
From the partition info via ATAG, we can now build "stock" mtdparts information to apply to our kernel. Using the example(s) above, we can now build this information:
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Note the syntax of size@offset. Next, we must convert the hex values to decimal, then multiply by 128 (I do not know if 128 is the same multiplier for all devices, please double check and let me know). This will give us the exact sizes and offsets in kilobytes.
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Alright, so that is a 100% stock partition map for this device - except we also have the boot (kernel) mapped now too. Here is a (crappy) visual representation of it:
Code:
reserved | boot | /system | /data | appslog | /cache |
first 80MB | 12.5MB | 312.5MB | 380MB | 133.5MB | 101.5MB |
Note: Not to scale :)
You may have noticed that the order we (and ATAG) lists the partitions in does not match the actual order of the partitions. It is quite important to retain the order of the partitions as specified in ATAG, because that's the order they will be mapped in. I.e. system will remain mtdblock0 and cache will remain mtdblock2. Any extra partitions should always go after these defaults.
Formatting for kernel
To specify the mtdparts parameter for the kernel to use is trivial. Doing this will over-ride the ATAG map (from bootloader) and everything in the system - including Recovery - will see your map from the kernel. Search your default config file in your kernel for the value "CONFIG_CMDLINE" and you should find a value like this :
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc"
Using the information we have above about our partition map, we add a new parameter here with "mtdparts=msm_nand:". The syntax is as follows:
Code:
mtdparts=msm_nand:[size]@[offset](name){,[size]@[offset](name)}{...}
Remember that we converted our size and offsets to kilobytes (for better readibility) so we need to specify size unit of k. The new parameter, from our above examples, becomes this:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
Don't forget to retain the order! And so, our full line looks like this:
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)"
NOTE: Depending on your kernel, you may also need to enable the following line in your config:
Code:
CONFIG_MTD_CMDLINE_PARTS=y
And we're all done. If you build your kernel now, you will be able to mount (or at least dd from) the appslog and boot partitions.
Resizing partitions
This is somewhat trivial, the most difficult part is probably over - but this step can be tedious, albeit not very complicated. Anybody with an above average IQ would have already figured this out - we simply change the size of one partition and adjust the offsets of it's following partitions to accommodate for the change. Here is one good example that I use for the MIUI ROM for the Xperia Play and Neo L, compared to the stock examples shown above:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
...and a visual representation of this new map:
Code:
reserved | boot | /system | /data |/cache|
first 80MB | 12.5MB | 280MB | 639MB | 8MB |
Note: Not to scale :)
Hopefully that's enough to make sense. Remember to verify your modified partitions. This can easily be done by adding the size+offset of a partition, giving the offset of the next partition. E.g. in this mod, userdata ends at 1036288 (654848+381440) which matches the offset for the next partition - cache.
Troubleshooting/Recovering from modified partitions
In some cases, your new kernel may not boot. A common issue is that the kernel logo will show, and the device will shortly reboot (kernel bootloop). This can be solved by formatting your partitions with fastboot after flashing the new kernel, usually system and userdata are all that is needed:
Code:
fastboot format system
fastboot format userdata
If you wish to return to a stock partition layout, sometimes flashing a non-modified kernel is not enough. You may get stuck on kernel logo even after formatting system and userdata. In this case, flashing a stock Firmware and setting your phone back to scratch should result in a 100% original device. But if your phone is still bricked, sorry but it's not my fault. You probably did something wrong.
#####
OK, that's the guide done for now. Any questions or suggestions on the guide, please let me know! Also, refer to post #2 for some stock partition map reference.
Finding Stock Partition Info For Your Device
Three methods:
Most reliable - See the section "Gathering info" above to get it from ATAG
Only shows size without offset - do "cat /proc/mtd" from adb shell. Can be used to test if you're on stock partitions or not, or to verify partition is big enough for update ZIP's (with sed/grep).
Xperia 2011 Only - Examine SIN header as outlined above. This method is difficult to determine mtd block order but I'm 99% sure the order is same for all Xperia 2011 devices (system=mtd0, userdata=mtd1, cache=mtd2).
Stock Partition Parameters for Various Devices
Xperia 2011 Range:
Code:
[B]anzu (Arc) (LT15) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - [email protected] ([email protected])
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](appslog),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1),[email protected](boot)
[B]ayame (Arc S) (LT18) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
\ this is odd, there is 2048k unallocated between boot and system (SEMC made a mistake?)
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - none
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1)
[B]haida (Neo V) (MT11) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]hallon (Neo) (MT15) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]iyokan (Pro) (MK16) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]mango (Mini Pro) (SK17) (MDPI):[/B]
??
[B]satsuma (Active) (ST17) (MDPI):[/B]
??
[B]smultron (Mini) (ST15) (MDPI):[/B]
??
[B]urushi (Ray) (ST18) (HDPI):[/B]
??
[B]phoenix (Neo L) (MT25) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]zeus/zeusc (Play) (R800) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
R800a (and probably i/at, but not x) has unallocated vendor partition. Needs one-time flash of Vendor-enabled FTF (e.g. phoenix or anzu) to allocate it otherwise the vendor map will present I/O errors.
Reserved again (just in case)
Thanks for the info. You have used the same for MIUI for Neo L and Play and we have good internel memory..
Thanks for sharing
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...
E:V:A said:
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...
Click to expand...
Click to collapse
Heh nice! Yours looks a bit more hardcore than mine, I've never used any of those tools
I started this guide so I can port kernels to various devices for Xperia 2011 range, and also to help other devs appeal the users who crave for more internal partition space. But so far, none of these people seem to have the patience to lend a hand with gathering data
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
[NUT] said:
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
Click to expand...
Click to collapse
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
CosmicDan said:
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
Click to expand...
Click to collapse
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
[NUT] said:
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
Click to expand...
Click to collapse
1GB = 1024MB, not 1000MB
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
CosmicDan said:
1GB = 1024MB, not 1000MB
Click to expand...
Click to collapse
well... thats open for debate in some way, GB != GiB. For me 1GB should be 1024Mb though ...
CosmicDan said:
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
Click to expand...
Click to collapse
most likely yes... sounds fair atleast...
CosmicDan said:
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Click to expand...
Click to collapse
i've been playing around with wedgess' kernel:
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata 1258 @ CA8 601088 @ 414720 587Mb
cache 40 @ 1F00 8192 @ 1015808 8Mb
EOD: 1024000 1000Mb
Thats what i am using now, thanks to your guide
{
"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"
}
CosmicDan said:
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
Click to expand...
Click to collapse
Will report back with the defaults from the stock rom later... going to bed now... 7:36am here now... haven't been sleeping yet :silly:
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
CosmicDan said:
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
Click to expand...
Click to collapse
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
LT15i: anzu
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
cache 330 @ 1CB4 104448 @ 940544 102Mb
EOD: 1044480 1020Mb
LT18i: ayame
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
MK16i/a: iyokan
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
your welcome
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk
CosmicDan said:
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app
[NUT] said:
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app
Click to expand...
Click to collapse
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk
CosmicDan said:
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
From what i know from using dd: it does a byte4byte copy, in any sector size you like but in any case it will read what the disk says there is, as long as there is a disk... so the o/i errors should only occur on those parts that are either damaged or non existent...
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
As the NAND flash chip has no logic that makes it a disk like entity other then direct access through MTD software logic (hence yaffs2 as filesystem of choice) i strongly doubt it will use the last 2/4Mb in the end as wear leveling buffer...
[NUT] said:
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
Click to expand...
Click to collapse
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors
[NUT] said:
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors
Click to expand...
Click to collapse
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though
CosmicDan said:
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though
Click to expand...
Click to collapse
I would agree with you, except if I skip the first 92 Mb of the NAND with dd it still doesn't read... maybe the 'read-protection' foils that plan as well... I don't know ...