[HW][OT] E:V:A's Discussion Thread - Off-topic
This is my own completely Off Topic Discussion thread.
A place where I will bring HW related discussions, that do not fit into
specific threads or discussions.
Please, do not post here with general questions or other junk that I have not initiated myself.
Also do not ask where to find files/programs mentioned in this thread, because if I have not linked to them, I don't know!
They will be removed. (Thanks for understanding.)
See you.
<< Better reserve for more dragons >>
Didn't see that anyone mentioned it and I'm not sure if the S4 modems are as well, but the initial container that the modems are in on the HTC used S3 chips is a fat16 format. I saw that with a simple hex editor showed it and I was able to see the modem file structure as well. I'll snag a few S4 modems later today and take a look. Couldn't unpack and repackaged though, which is probably the EFS formatting with it.
Off topic goes in off topic
Sorry it took so long
I had intended to do this at least a week ago, but had not the chance. Both the S3 HTC Radios and the S4 HTC Radios are fat 16 imgs.
As you see in the Rezound screenshot, in the first few lines of the HEX table in the bottom left mentions no volume label and a fat 16 label on the type. in addition when I use IMG viewers it shows the same with both the MDM9K image and the main IMG. This should theoretically enable us to possibly use amss imgs or other parts of the radios with other devices or even cross the modem over to other Samsung devices with the same modem chips.
In addition as per the Ville screenshot, this is the One S modem for one of the European basebands. Again the HEX shows Fat 16 as the file type, but the file structure and amount of files are much more plentiful. If this can become of any use, great. If not, oh well... but it is good food for thought either way.
On other notes, I did try to copy files from the LTE baseband (MDM9k) from the Vivid and move them to the MDM9k IMG for the rezound, but the IMG bloated. I haven't had enough time to try and mount the images in my Ubuntu environment, but doing it in Winblows caused the IMG to bloat up too much and caused radio issues and IMEI unknown blanks.
Happy perusing and happy hunting!
Very nice, but I doubt you'll be able to mix modem files (between different devices) unless you're absolutely sure that the device modem and AP HW is the same. Apparently from another recent conversation, it seem that HTC and Qualcomm are both moving to unified source code for their devices. So it can still be true that many of those files are the same across devices.
Could you write a few lines on how you go about this extraction and do it for the HTC One X (LTE)?
Also don't forget that US HTC One X (or S, or whatever) is not the same hardware and the European one!
On second thought, I think this is what you got..right?
Pretty much. Seems like another situation where I should have spoke up when I first saw it with Qualcomm S3 modems in May. On moving files though, I was planning to stay in family. S3 w/ S3 ect.
^^ BTW. Could you tell if there are any structural differences (content wise) between files of same prefix, but sequential postfix? What is strange is that they are all very different sizes, which indicate they probably have very different content...
If it was just one solid piece of firmware, it would just have been chopped up into equal sized pieces...
I'll look closer on that. I do remember that most of the sequential pieces were the same size minus either the first or the last, holding with your theory.
Maybe not the right place, but have you looked at the pit files?
COM_TAR2MSM8960
MODEM non-tlos.bin
sbl1.mbm
sbl2.mbm
sbl3.mbm
aboot.mbm
rpm.mbm
BOOT boot.img
TZ
PAD
PARAM
EFS efs.img (ext4)
MODEMST1 nvrebuild1.bin
MODEMST2 nvrebuild2.bin
system.img (ext4)
userdata.img (ext4)
persist.img (ext4)
cache.img (ext4)
recovery.img (ext4)
FOTA
BACKUP
FSG
SSD
GROW
PGPT pgpt.img
PIT MSM8960.pit
MD5 md5.img
SGPT sgpt.img
I know it is not really new, but I hadn't seen the img names.
The ones I took screenshots of were for 3rd and 4th Gen Snapdragon processors, radio.imgs for HTC devices. The Samsung pit files may give good cross references though. I'll re-unbox my Amaze this evening and check the mounts to see any information on the single file broken into pieces theory.
"eMMC Partition tools usage for msm7x30/msm8x60"
(A repost from Anyclub...)
In the eMMC boot, there are some changes in eMMC partitioning.
Code:
[SIZE=2]partition.xml - Everything begins with this file, which describes the number of
partitions desired, and how many sectors each one should be.
PartitioningTool.py - translates partition.xml into binary partitions
msp.exe - writes binary partitions to SD/eMMC cards using card reader
mjsdload.cmm - writes binary partitions to SD/eMMC cards using Trace32
msp.py - writes binary partitions to a single image file
QPST - writes binary partitions to SD/eMMC cards on Target
[/SIZE]
Helper /Debug Tools:
Code:
[SIZE=2]parseBinaryPartitionFile.pl - Decodes MBR partition tables. Run:
"Perl parseBinaryPartitionFile.pl partition.bin"
to generate the partition information
parseGPT.pl - Decodes GPT partition tables
[/SIZE]
partition.xml
These are the property entries that can be added in new partiton.xml to specify the configuration.
Code:
[SIZE=2]<parser_instructions>
WRITE_PROTECT_BOUNDARY_IN_KB = 0
GROW_LAST_PARTITION_TO_FILL_DISK = false
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY = false
</parser_instructions>[/SIZE]
WRITE_PROTECT_BOUNDARY_IN_KB: Typical boundaries are 64MB, i.e. 65536 KB. This
means that a 256MB eMMC card has 4 write protect boundaries. Any or all of
them can be marked as read-only. Different vendors allow for different sized
boundaries.
GROW_LAST_PARTITION_TO_FILL_DISK: In partition.xml the size of each partition
is specified. If this field is TRUE, then the last partition size is ignored
and set to 0. Then during patching this size is updated such that the last
partition extends to use all remaining space.
ALIGN_ALL_LOGICAL_PARTITIONS_TO_WP_BOUNDARY: To allow total flexibility, it
could be that a partition that is currently writeable might need to be marked
as read-only. This can only happen *if* that partition begins on a write
protect boundary (i.e. 64MB). Thus if this field is TRUE, then all logical
partitions are positioned such that they begin on a write protect boundary.
PartitioningTool.py
Is a new tool used to generate the the partition.xml
When run, it will output following 5 files:
1. emmc_lock_regions.xml
This hold the sector ranges that need to be marked as read-only by the
operating system (this is from readonly="true" in partition.xml) i.e. modem
code and boot images are typically on read-only partitions Typical
Write-Protect boundary is 64MB = 131072 sectors = 0x20000 sectors. The file
below is protecting the very first 64MB region of the card,
Boundary #0
Starting at sector 0
Ending at sector 131071 (for a total of 131072 sectors)
Code:
[SIZE=2]<?xml version="1.0" ?>
<protect>
<!-- NOTE: This is an ** Autogenerated file ** -->
<!-- NOTE: Sector size is 512bytes, WRITE_PROTECT_BOUNDARY_IN_KB=0, WRITE_PROTECT_BOUNDARY_IN_SECTORS=0 -->
<!-- NOTE: "num_sectors" in HEX "start_sector" in HEX, i.e. 10 really equals 16 !! -->
<program boundary_num="0" num_boundaries_covered="1"
num_sectors="20000" num_sectors_dec="131072" physical_partition_number="0"
start_sector="0" start_sector_dec="0"/>
<information WRITE_PROTECT_BOUNDARY_IN_KB="0"/>
</protect>
[/SIZE]
2. partition0.bin
This holds the partition tables, i.e. MBR followed by all EBRs. This is the
partition table in binary format. It is copied over to the storage device in a
1 to 1 manner. I.e. how it looks in partition0.bin is exactly how the
partition table will look on the storage device. partition0.bin is a "generic"
file meant to fit on *any* size SD/eMMC card, as a result, there are 0's that
need to be patched,such as EXT partition and last partition size.
3. patch0.xml
Contain the patching instructions to tailor each partition table
"partition0.bin" to a specific SD/eMMC card. I.e. the partition0.bin
partition tables can be applied to any size storage device As a result,
there are empty values (zeros) in the partition tables that must be filled
in with a specific cards sector size
There are two ways to apply this patch:
a) (patch before) When you patch the "zeros" in the partition tables held in the file partition0.bin, and then write it to the card
b) (patch after) When you write partition0.bin to the card (which still has "zeros" in it), and then patch the cards partition tables directly
4. rawprogram0.xml
precise sector details of all partitions and what files (if any) need to
be placed there. In addition to writing partition tables onto a device,
often times it is desired to write one or more files into the partition
area as well, The File has partition name (i.e. label), where it begins
(start_sector) and how big it is (num_partition_sectors). It also
describes what file(s) to write to this partition, as well as any
offsets.
Example:
Code:
[SIZE=2]<program file_sector_offset="0" filename="partition0.bin" label="MBR"
num_partition_sectors="1" physical_partition_number="0"
size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin " label="EXT"
num_partition_sectors="2" physical_partition_number="0"
size_in_KB="1.0" start_sector="779"/>
[/SIZE]
The 1st line describes taking the 1st sector from partition0.bin, and writing it to sector 0 of the card.
The 2nd line describes taking the 2nd and 3rd sector from partition0.bin and writing it to sector 779 of the card.
I.e. file_sector_offset = 2 and num_partition_sectors=2
5. loadpt.cmm
This is used by the mjsdload.cmm to flash the image.
msp.exe
This is used to apply the patches
This program will program a memory card (SD/eMMC) attached to the PC as USB mass storage device
Use -d to detect the path of the memory card if you are unsure what to do first
Commands list:
Code:
[SIZE=2]-h (Print this help message) Ex. msp -h
-d (Detect which storage device ID is active) Ex. msp -d
-p (Print partition information) Ex. msp -p /dev/sdb
-pp (Print partition information - DETAILED) Ex. msp -pp /dev/sdb
-x (Write files as outlined in rawprogram.xml) Ex. msp -x rawprogram.xml /dev/sdb
-xx (Write files as outlined in rawprogram.xml - DETAILED) Ex. msp -xx rawprogram.xml /dev/sdb
-s (Write SINGLE IMAGE "singleimage.bin" as outlined in rawprogram.xml) Ex. msp -s rawprogram.xml 8192
-v (Verify file written correctly as outlined in rawprogram.xml) Ex. msp -v rawprogram.xml boot.img /dev/sdb
-f (Program single file as outlined in rawprogram.xml) Ex. msp -f rawprogram.xml boot.img /dev/sdb
[/SIZE]
To program the SD/eMMC with msp.exe in mass storage mode:
Code:
[SIZE=2]STEPS Complete example (patch after)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
STEPS Complete example (patch before)
-------------------------------------------------------------
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Patch your files msp xx patch0.xml 15758336 (patch the 8GB card offline,this will change the partition0.bin)
Program your device msp x rawprogram0.xml /dev/sdb
[/SIZE]
The msp.py program can also used to patch the files.
For example:
python msp.py patch0.xml 15758336
This will patch the 8GB card offline, and change the partition0.bin.
Qualcomm DBL format (source Anyclub)
DBL is combined by three images.
dbl.bin - the raw DBL image
dbl.hd - the dbl header image
dbl_preamble.mbn - the preamble image with following format:
Code:
[SIZE=2]+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
[/SIZE]
PBL is using the dbl_preamble to detect the NAND page size. The NAND controller
can detect 512 byte and 2 Kbyte page size automatically, but for NAND page size
more than 2K, PBL needs preamble to determine the page size, so for 512/2K
NAND,eMMC,eSD,oneNAND , the preamble is optional.
For the dbl_preamable, the first two words are same as dbl header, they are
codeword and magic,
ref image_header.c
Code:
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
the third one is auto page size detection magic number.
The usage of the auto detection magic number is as below description To
understand this more clearly, for example ,if the dbl_preamble is 8KB. When we
detect the NAND page size > 2KB, we will set the default page size as 2K, then
try to read the preamble image from NAND flash, in case the page size is 4KB,
when read, can get 2 magic number in 8K size because page size will increase
with 4K byte steps, so page size is detected and that is 8K/2 = 4. For the 8K
page NAND, 1 magic number is read from the 8K size preamble image, so the page
size will be 8K/1 = 8K.
Dbl_preamble layout:
Code:
[SIZE=2]+-------------------------------------------------+
| codeword|magic|autodetection_ magic|............|
2K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
4K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
6K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
8K------------------------------------------------|
| codeword|magic|autodetection_ magic|............|
+-------------------------------------------------+
[/SIZE]
E:V:A said:
parse partition.xml python PartitioningTool.py partition.xml
Detect your device msp -d
Program your device msp -x rawprogram0.xml /dev/sdb
Patch your device msp -xx patch0.xml /dev/sdb
Click to expand...
Click to collapse
Hello, where i can find these files, i have qpst but there are no such files.
So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)
dviguha said:
Hello, where i can find these files, i have qpst but there are no such files.
Click to expand...
Click to collapse
I think it could be part of the Qualcomm Development Acceleration Resource Toolkit (QDART), as it supersedes QPST. But I'm not sure...
joederp said:
So does this explain why the pit references: pgpt.img, md5.img, sgpt.img but they aren't on any partition, (they should be after GROW blk0p23)
Click to expand...
Click to collapse
Where do you find these references?
I don't know, so if you find out let us know.
http://forum.xda-developers.com/showthread.php?t=1848267
If you dump the pit file you can see the references if you open in hex editor. Since it defines partition locations it appears they are either after last partition.. I haven't looked into technical pit stuff.
Sent from my SGH-T999 using xda app-developers app
Photo Place Holder Post
All images that I have not yet posted goes here...
Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?
vache said:
Where can i find parseBinaryPartitionFile.pl or parseGPT.pl ?
Click to expand...
Click to collapse
You tell me!
Related
[GUIDE] SD card partitioning for rooted phones
Behold... a long awaited partitioning guide WARNING! This GUIDE is to actually learn something not just to copy/paste commands! Requirements rooted phone busybox installed parted (optional) backup your SD card (optional) calculator Click to expand... Click to collapse Background Before we begin partitioning, we need to elaborate some key points: block storage units are divided into logical blocks known as sectors sector has a size of 512 bytes NAND flash chips are divided into blocks known as erase blocks our SD cards consist of those NAND flash chips and controller erase block on our SD cards has a size of 128 kB, that's 256 sectors CHS (cylinder, head, sector) alignment has an insignificant importance here 1st sector is sector 0 (not 1) and is used as MBR (master boot record) 1st partition begins at cylinder boundary to maintain MS-DOS compatibility raw access to block storage units is done via special block device files under /dev/block directory our SD card is represented by block device file /dev/block/mmcblk0 Click to expand... Click to collapse Instructions Here I will provide you with two methods of partitioning. For 1st method you will be using fdisk utility which is part of busybox and for 2nd a standalone utility called parted will be used. Both methods can be used in normal mode via adb shell or some terminal app. I will explain both methods using adb shell as it is more convenient and handy than typing commands via touch keyboard on your phone. 1st thing to do before you begin is to unmount your SD card via "Settings->SD & phone storage" and then you issue "adb shell" command ony your PC. 2nd thing you will do is erasing of your SD card (actually you will erase just first few erase blocks of your SD card) using dd utility: Code: dd if=/dev/zero of=/dev/block/mmcblk0 bs=131072 count=16 ...that will overwrite 1st 2 MB of your SD card with null characters. Next you may begin with partitioning. fdisk As I already stated, fdisk is a (interactive) utility that is part of busybox so I will assume it is available under /system/xbin directory. Now you can run fdisk with device file of your SD card as parameter/argument: Code: fdisk /dev/block/mmcblk0 ...this will bring you some notes on your screen you should not worry about and a command prompt: Code: Command (m for help): ...which you can leave at any time by pressing CTRL+C. Next you will change unit display type to sectors: Code: Command (m for help): [B]u[/B] Changing display/entry units to sectors ...and print your SD's current info (this is info of my SD card actually, yours may vary): Code: Command (m for help): [B]p[/B] Disk /dev/block/mmcblk0: 8018 MB, 8018460672 bytes 4 heads, 16 sectors/track, 244704 cylinders, total 15661056 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System ...and you write down the number of sectors. In my case it is 15661056 sectors of 512 bytes which is exactly 7647 MB if we divide them by 2048. For example you would take 7000 MB for fat32 1st partition and 647 MB for ext 2nd partition. and it is handy that way coz megabytes are divisible by our SD card's erase block size which is 128 kB as stated before. Calculation would give you start sector for 2nd partition and this would be 14336000 (7000*2048). Now you need to create 2 primary partitions: Code: Command (m for help): [B]n[/B] Command action e extended p primary partition (1-4) [B]p[/B] Partition number (1-4): [B]1[/B] ...now there's a catch. You will be offeread a start of 1st partition at 1st to 2nd cylinder boundary which is sector 16 in my case and you push it to SD card's erase block boundary (256): Code: First sector (16-15661055, default 16): [B]256[/B] Last sector or +size or +sizeM or +sizeK (256-15661055, default 15661055): [B]14335999[/B] ...and continue to the next partition which should also be primary: Code: Command (m for help): [B]n[/B] Command action e extended p primary partition (1-4) [B]p[/B] Partition number (1-4): [B]2[/B] First sector (16-15661055, default 16): [B]14336000[/B] Last sector or +size or +sizeM or +sizeK (14336000-15661055, default 15661055): [B]15661055[/B] ...now print what you have just done: Code: Command (m for help): [B]p[/B] Disk /dev/block/mmcblk0: 8018 MB, 8018460672 bytes 4 heads, 16 sectors/track, 244704 cylinders, total 15661056 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 256 14335999 7167872 83 Linux /dev/block/mmcblk0p2 14336000 15661055 662528 83 Linux ...it looks OK but you need to change 1st partition's hex id which needs to be fat32 (c): Code: Command (m for help): [B]t[/B] Partition number (1-4): [B]1[/B] Hex code (type L to list codes): [B]c[/B] Changed system type of partition 1 to c (Win95 FAT32 (LBA)) ...now you're am set, print again your configuration and write changes to SD card: Code: Command (m for help): [B]p[/B] Disk /dev/block/mmcblk0: 8018 MB, 8018460672 bytes 4 heads, 16 sectors/track, 244704 cylinders, total 15661056 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 256 14335999 7167872 c Win95 FAT32 (LBA) /dev/block/mmcblk0p2 14336000 15661055 662528 83 Linux Command (m for help): [B]w[/B] The partition table has been altered! There's a possibility you would need to shutdown and power on again your phone at this point. Do not reboot via adb or some 3rd party app! Click to expand... Click to collapse parted Parted is one of interactive partitioning utilities that can also use external formatting utilities. It can be found in some recovery images but can be copied to your internal phone storage and run from there in normal mode too. To run it you have to use your SD card's device file as a parameter/argument: Code: parted /dev/block/mmcblk0 ...and you will be presented with an interactive shell: Code: 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) I probably shouldn't mention that there's an interactive help available and that it is invoked by issuing "help" into shell's command prompt. Next thing to do is making a MS-DOS disklabel: Code: (parted) [B]mklabel msdos[/B] ...and switch to display sector as a unit: Code: (parted) [B]unit s[/B] Now you can print some useful info: Code: (parted) [B]print all[/B] Model: SD USD (sd/mmc) Disk /dev/block/mmcblk0: 15661056s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags Mind and write down the size in sectors (15661056 in my case).If you divide number of sectors by 2048, you get how big in MB is actually your SD card (7647 in my case).You should mind that erase block of your SD card is 128 kB and all of your partitions should start at the beginnings of those erase blocks. It is safe to say that 1st partition should begin at sector 256 and 2nd at any MB boundary. Let say you want 512 MB big ext partition and the rest for fat32 one. Mind tho that 1st partition is to be fat32! So we say 7135 MB for fat32 1st partition and 512 MB for ext 2nd partition. Now you calculate the start sector of 2nd partition... number of MB for 1st partition multiplied by 2048 should give you the number (14612480). And you are set for partitioning: Code: (parted) [B]mkpart primary fat32 256 14612479[/B] (parted) [B]mkpart primary ext2 14612480 15661055[/B] ...and print result: Code: (parted) [B]print all[/B] Model: SD USD (sd/mmc) Disk /dev/block/mmcblk0: 15661056s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 256s 14612479s 14612224s primary fat32 lba 2 14612480s 15661055s 1048576s primary ext2 ...and quit: Code: (parted) [B]quit[/B] Click to expand... Click to collapse At this point you have partitioned your SD card but not yet formatted it. Format fat32 partition with mkfs.vfat and ext partition with mkfs.ext2: Code: mkfs.vfat /dev/block/mmcblk0p1 ...and: Code: mkfs.ext2 -m0 -b4096 /dev/block/mmcblk0p2 If there is a mke2fs utility on your phone system (standalone - not part of busybox), you may use it to format second partition as ext3: Code: mke2fs -j -m0 -b4096 /dev/block/mmcblk0p2 ...or even as ext4 (if your mke2fs supports that): Code: mke2fs -j -m0 -b4096 -Oextents,uninit_bg,dir_index /dev/block/mmcblk0p2 Click to expand... Click to collapse
Blayo, thanks for the post. You always manage to take things to an entirely different level of understanding Is this guide for the successful implementation of the latest data2ext scripts in roms ? in comparison to methods like the Rom Manager and partition through recovery ?
No, it is general guide to better understand partitioning etc.
BlaY0 said: No, it is general guide to better understand partitioning etc. Click to expand... Click to collapse I totally agree! After going through parted I think it's the best way to partition your SD, you have complete control! I can't wait will my new SD card arrives, and give this a shot! The Kingston 16GB class 10 sucks even when set-up to the best parameters and the reason for that is simple: Although class 10, it is like 4 times slower than my 8GD sandisk mobile ultra Class 4 when random writing and 3 times slower when reading... So Thanks BlaY0 for this cool guide/lesson
I have problem with fdisk . when i press p i got this info and there a no sector: PHP: Command (m for help): p p Disk /dev/block/mmcblk0: 16.0 GB, 16001269760 4 heads, 16 sectors/track, 488320 cylinders Units = cylinders of 64 * 512 = 32768 bytes
Did you change units display to sectors?
Thanks, with the "u" option comes later in your manual A last newbie question: i have now 2 part. and formated the FAT, but i dont know, how to get the "mke2fs" on the phone to format the Linux part.? Sorry Blay0 but Linux is another Word for me...
tasar said: Thanks, with the "u" option comes later in your manual Click to expand... Click to collapse Thanx, I have changed that. A last newbie question: i have now 2 part. and formated the FAT, but i dont know, how to get the "mke2fs" on the phone to format the Linux part.? Sorry Blay0 but Linux is another Word for me... Click to expand... Click to collapse If you have busybox on your phone you also have mke2fs or mkfs.ext2 as these two are part of it. If you have CM based ROM there should already be standalone e2fsprogs in /system/bin directory and if you have a stock based one, you can find mke2fs_recvy + e2fsck_recvy in /system/bin directory. In B ROM you have all e2fsprogs available in /system/xbin directory.
Many thanks!!! Now i install your 0.5
Code: # mkfs.vfat /dev/block/mmcblk0p1 mkfs.vfat /dev/block/mmcblk0p1 mkfs.vfat: not found help?
Try "busybox mkfs.vfat"...
BlaY0 said: Try "busybox mkfs.vfat"... Click to expand... Click to collapse Code: # busybox mkfs.vfat /dev/block/mmcblk0p1 busybox mkfs.vfat /dev/block/mmcblk0p1 mkfs.vfat: applet not found its ok, before you replied i tried doing it in recovery and i believe it worked, but i think i missed a digit in my partitioning and it was only 98mb for my fat drive instead of about 988 or something (1gb) so ill try it again and let you know EDIT: ok yeah i had the digits wrong so now its formatted/partitioned correctly. now im gonna apply the data2ext thing and see what happens. i didnt actually do anything about my darktremor a2sd so ive probably got bits and pieces of all my apps missing but if **** starts to screw up ill just put a fresh copy of cm on since ive ruined all my apps basically already EDIT: alright its working, thanks heaps!
DT has some commands to disable itself. As for mkfs.vfat... it is part of busybox but not necesarily. There are several versions lying around the internets. Type just "busybox" and you'll see all the utils available in it.
BlaY0 said: DT has some commands to disable itself. As for mkfs.vfat... it is part of busybox but not necesarily. There are several versions lying around the internets. Type just "busybox" and you'll see all the utils available in it. Click to expand... Click to collapse Code: # busybox busybox BusyBox v1.16.2androidfull (2010-08-01 14:57:25 EDT) multi-call binary. Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as. Currently defined functions: [, [[, arp, ash, awk, basename, bbconfig, brctl, bunzip2, bzcat, bzip2, cal, cat, catv, chgrp, chmod, chown, chroot, cksum, clear, cmp, cp, cpio, cut, date, dc, dd, depmod, devmem, df, diff, dirname, dmesg, dnsd, dos2unix, du, echo, ed, egrep, env, expr, false, fdisk, fgrep, find, fold, free, freeramdisk, fuser, getopt, grep, gunzip, gzip, head, hexdump, id, ifconfig, insmod, install, ip, kill, killall, killall5, length, less, ln, losetup, ls, lsmod, lspci, lsusb, lzop, lzopcat, md5sum, mkdir, mke2fs, mkfifo, mkfs.ext2, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, mv, nc, netstat, nice, nohup, nslookup, ntpd, od, patch, pgrep, pidof, ping, pkill, printenv, printf, ps, pwd, rdev, readlink, realpath, renice, reset, rm, rmdir, rmmod, route, run-parts, sed, seq, setsid, sh, sha1sum, sha256sum, sha512sum, sleep, sort, split, stat, strings, stty, swapoff, swapon, sync, sysctl, tac, tail, tar, tee, telnet, test, tftp, time, top, touch, tr, traceroute, true, tty, tune2fs, umount, uname, uniq, unix2dos, unlzop, unzip, uptime, usleep, uudecode, uuencode, vi, watch, wc, wget, which, whoami, xargs, yes, zcat yeah so that mkfs.vfat isnt there and neither is parted and then when i go to android recovery Code: # busybox busybox BusyBox v1.15.3 (2010-02-06 17:13:19 CET) multi-call binary Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. See source distribution for full notice. Usage: busybox [function] [arguments]... or: function [arguments]... BusyBox is a multi-call binary that combines many common Unix utilities into a single executable. Most people will create a link to busybox for each function they wish to use and BusyBox will act like whatever it was invoked as! Currently defined functions: [, [[, arping, ash, awk, basename, bbconfig, bunzip2, bzcat, bzip2, cat, catv, chattr, chgrp, chmod, chown, chroot, chrt, chvt, cksum, clear, cmp, cp, crond, crontab, cut, date, dc, dd, deallocvt, depmod, devmem, df, dhcprelay, diff, dirname, dmesg, dnsd, dnsdomainname, dos2unix, du, dumpkmap, dumpleases, echo, egrep, env, ether-wake, expr, false, fbset, fbsplash, fdisk, fgrep, find, fold, free, freeramdisk, fsck, fuser, getopt, grep, gunzip, gzip, head, hexdump, hostname, hwclock, ifconfig, ifdown, ifup, insmod, install, ip, ipaddr, ipcalc, iplink, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, last, length, less, ln, loadfont, loadkmap, losetup, ls, lsattr, lsmod, makedevs, md5sum, mdev, mkdir, mkdosfs, mkfifo, mkfs.vfat, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od, openvt, patch, pidof, ping, pipe_progress, pivot_root, printenv, printf, ps, pscan, pwd, rdate, rdev, readlink, readprofile, realpath, renice, reset, resize, rm, rmdir, rmmod, route, run-parts, sed, seq, setconsole, setkeycodes, setlogcons, setsid, sh, sha1sum, showkey, sleep, sort, split, stat, strings, stty, sum, swapoff, swapon, switch_root, sync, sysctl, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, tunctl, udhcpd, udpsvd, umount, uname, uncompress, uniq, unix2dos, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, watch, wc, wget, which, who, whoami, xargs, yes, zcat and boom, a lot more stuff is there (except parted.. but it works anyways, and mkfs.ext2 is missing, and doesnt work). it should be okay to do everything in recovery anyways right? and i can just use mke2fs -m0 -b4096 /dev/block/mmcblk0p2 to format the ext2 partition? EDIT: just tried the parted method and i dont think it works, i get this Code: (parted) mkpart primary fat32 256 2813951 mkpart primary fat32 256 2813951 mkpart primary fat32 256 2813951 (parted) mkpart primary ext2 2813952 3862527 mkpart primary ext2 2813952 3862527 mkpart primary ext2 2813952 3862527 (parted) print all print all print all Model: SD SU02G (sd/mmc) Disk /dev/block/mmcblk0: 3862528s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 256s 2813951s 2813696s primary lba 2 2813952s 3862527s 1048576s primary anyways i used the first method and its fine, although the partitioning isnt spot on accurate, i just put on data2ext for cm6 and my available space is 504mb instead of 512mb and i checked all my calculations and everything, ah well close enough. thanks again!
It looks OK. Sent from my HTC Legend
Need some help. There's a possibility you would need to shutdown and power on again your phone at this point. Click to expand... Click to collapse Possibility? I got this: Code: Command (m for help): p p Disk /dev/block/mmcblk0: 7973 MB, 7973371904 bytes 4 heads, 16 sectors/track, 243328 cylinders, total 15572992 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 256 13475839 6737792 c Win95 FAT32 (LBA) /dev/block/mmcblk0p2 13475840 15572991 1048576 83 Linux Then i got Code: Command (m for help): mkfs.vfat /dev/block/mmcblk0p1 mkfs.vfat /dev/block/mmcblk0p1 Command Action a toggle a bootable flag b edit bsd disklabel c toggle the dos compatibility flag d delete a partition l list known partition types n add a new partition o create a new empty DOS partition table p print the partition table q quit without saving changes s create a new empty Sun disklabel t change a partition's system id u change display/entry units v verify the partition table w write table to disk and exit x extra functionality (experts only) The same with the mkfs.ext2 -m0 -b4096 /dev/block/mmcblk0p2 And now the phone says than my flash is empty or uses wrong format, dont want to mount it and want to format it. I press cancel. if i make p again it shows: Code: Command (m for help): p p Disk /dev/block/mmcblk0: 7973 MB, 7973371904 bytes 4 heads, 16 sectors/track, 243328 cylinders Units = cylinders of 64 * 512 = 32768 bytes Device Boot Start End Blocks Id System What is my mistake? UPD: Seems like it worked with the parted Spoiler Code: C:\androidsdk\platform-tools>adb shell adb server is out of date. killing... * daemon started successfully * # dd if=/dev/zero of=/dev/block/mmcblk0 bs=131072 count=16 dd if=/dev/zero of=/dev/block/mmcblk0 bs=131072 count=16 16+0 records in 16+0 records out 2097152 bytes transferred in 0.568 secs (3692169 bytes/sec) # parted /dev/block/mmcblk0 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) mklabel msdos mklabel msdos mklabel msdos (parted) unit s unit s unit s (parted) print all print all print all Model: SD SA08G (sd/mmc) Disk /dev/block/mmcblk0: 15572992s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags (parted) mkpart primary fat32 256 13475839 mkpart primary fat32 256 13475839 mkpart primary fat32 256 13475839 (parted) mkpart primary ext2 13475840 15572992 mkpart primary ext2 13475840 15572992 mkpart primary ext2 13475840 15572992 Error: The location 15572992 is outside of the device /dev/block/mmcblk0. (parted) mkpart primary ext2 13475840 15572991 mkpart primary ext2 13475840 15572991 mkpart primary ext2 13475840 15572991 (parted) print all print all print all Model: SD SA08G (sd/mmc) Disk /dev/block/mmcblk0: 15572992s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 256s 13475839s 13475584s primary lba 2 13475840s 15572991s 2097152s primary (parted) quit quit quit Information: You may need to update /etc/fstab. # mkfs.vfat /dev/block/mmcblk0p1 mkfs.vfat /dev/block/mmcblk0p1 # mkfs.ext2 -m0 -b4096 /dev/block/mmcblk0p2 mkfs.ext2 -m0 -b4096 /dev/block/mmcblk0p2 Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 65536 inodes, 262144 blocks 0 blocks (0%) reserved for the super user First data block=0 Maximum filesystem blocks=4194304 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376
playahate said: Need some help. Code: Command (m for help): p p Disk /dev/block/mmcblk0: 7973 MB, 7973371904 bytes 4 heads, 16 sectors/track, 243328 cylinders Units = cylinders of 64 * 512 = 32768 bytes Device Boot Start End Blocks Id System What is my mistake? Click to expand... Click to collapse I got this too... seems I forgot to enter the "w" command to write the partitions.
Absolutely. You neet to write the partition table exiting fdisk. And you can't execute mkfs.vfat and mke2fs inside fdisk shell! It's the same as you would try to microwave your sandwich in the fridge... it won't work that way...
agrrrrr. didnt see the next line with the w. anyway i made it by parted. very good guide, very good rom =) lil question: can i make ext3 or ext4 at any time? (after using data2ext).will it work correctly or wipe all data? or just when i make partitionong?
Yes. Just search the interwebs on how to convert ext2 -> ext3 -> ext4...
[Q] Completely Hosed - Recovery Impossible?
Yeah, yeah. Sounds like a million other posts. I am a unix/linux sort of guy, so I'm quite familiar with navigating and working in *nix based operating systems. Here is the synopsis: Without an SD card, the device will not boot. I can hear the USB cycle and I'm stuck at a black screen. Sounds normal so far. After booting up CWM, I can adb in. My first step was to check devices. /dev/block # cd /dev/block cd /dev/block /dev/block # ls ls loop0 loop5 mmcblk0p2 ram10 ram15 ram6 loop1 loop6 mmcblk1 ram11 ram2 ram7 loop2 loop7 platform ram12 ram3 ram8 loop3 mmcblk0 ram0 ram13 ram4 ram9 loop4 mmcblk0p1 ram1 ram14 ram5 As you can see, there are a few missing block devices. I proceeded to mount each of these. Only mmcblk0p1 had anything on it: the boot partition, as I expected. Mmcblk1 was the device name for the SDCard, which deviates from what I would have expected. Blk0p2 contained nothing and was not mountable. Next, I tried to do a 'mknod' to create the devices. This was successful to a degree, but did not actually create working devices. I attempted to mkfs.ext2 on them, that failed. For grins, I tried it on p1 and p2. The only one that worked was p1. At this point, I decided to try and flash the boot.img I retrieved from here: "mrm3.net/nook-color-recover-any-bricked-device/" and see what I could do to get the device up and running - any self booting would be an improvement, I thought. This too failed. The 'dd' was successful and the partition now contained boot info, but when i tried to boot up, I still received a black screen: /dev/block # dd if=/sdcard/boot.img of=/dev/block/mmcblk0p1 dd if=/sdcard/boot.img of=/dev/block/mmcblk0p1 144522+0 records in 144522+0 records out 73995264 bytes (70.6MB) copied, 44.914978 seconds, 1.6MB/s /dev/block # When I try to flash ANY rom, I get failures - obviously because there's no place for them to flash to. 'dmesg' doesn't contain any useful information. The device seems hosed. The last rom I was running was Cyanogen nightly #69, which wouldn't allow me to mount SDCard or do anything useful. When I tried to install nightly #80, I found that the device was no longer usable. Hopefully this was thorough enough, I refrained from typing out the obvious stuff, but please feel free to suggest things. I'm stumped. I still think it can be saved, but I don't have a ton of hope. Thanks a lot for giving this a read. I really hope someone can help out. -- j.k
Ill add you to the list with everyone else here of people who are more advanced than I. But one of the fist things I learned about the Nook is that its pretty much impossible to brick. I'm sure someone from the list will be by to help soon.
I really hope so. Logically, if the device nodes can be recreated, I could flash a new mod in. Perhaps I'm going about that the wrong way.
sangandongo said: Next, I tried to do a 'mknod' to create the devices. This was successful to a degree, but did not actually create working devices. I attempted to mkfs.ext2 on them, that failed. For grins, I tried it on p1 and p2. The only one that worked was p1. Click to expand... Click to collapse Have you verified that the partition table is actually intact/correct? No point trying to create device nodes if the underlying devices aren't there. What does "fdisk -l /dev/block/mmcblk0" give you, and how does it compare to the standard layout? Maybe check notes with the OP of this thread -- appears that both of you have essentially the same problem.
jll544 said: Have you verified that the partition table is actually intact/correct? No point trying to create device nodes if the underlying devices aren't there. What does "fdisk -l /dev/block/mmcblk0" give you, and how does it compare to the standard layout? Maybe check notes with the OP of this thread -- appears that both of you have essentially the same problem. Click to expand... Click to collapse Sorry, I should have included that earlier. The partition table is b0rked. I also had attempted applying the zips from the [ZIP][RECOVERY] EMMC Recovery Repair thread to no avail. ~ # fdisk -l /dev/block/mmcblk0 fdisk -l /dev/block/mmcblk0 Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes 4 heads, 16 sectors/track, 242432 cylinders Units = cylinders of 64 * 512 = 32768 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 1 15260 488312 b Win95 FAT32 /dev/block/mmcblk0p2 15261 242432 7269504 83 Linux
Not to sounds like a smartass (or maybe a dumbass) but have you tried to restore back to stock?
Yes. In my initial post, I stated that no restoring via zip works. Currently I am attempting to rebuild the partition table as mine is hosed. I get the following output though, which is troubling by comparison to what I should be seeing: ~ # busybox fdisk /dev/block/mmcblk0 busybox fdisk /dev/block/mmcblk0 The number of cylinders for this disk is set to 242432. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p p Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes 4 heads, 16 sectors/track, 242432 cylinders Units = cylinders of 64 * 512 = 32768 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 1 15260 488312 b Win95 FAT32 /dev/block/mmcblk0p2 15261 242432 7269504 83 Linux Command (m for help): d d Partition number (1-4):
Right, virtually all .zip restore files are filesystem-level recovery and assume that the partition table is unchanged. Try forcing the geometry using "fdisk -H 255 -S 63 /dev/block/mmcblk0"
Before I write this, does the following look like what you'd expect? I mean, it makes sense considering... Code: ~ # fdisk -H 255 -S 63 /dev/block/mmcblk0 fdisk -H 255 -S 63 /dev/block/mmcblk0 Code: Command (m for help): p p Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes 255 heads, 63 sectors/track, 965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 1 61 488312 b Win95 FAT32 Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 1) logical=(0, 0, 17) Partition 1 has different physical/logical endings: phys=(1023, 3, 16) logical=(60, 202, 14) Partition 1 does not end on cylinder boundary /dev/block/mmcblk0p2 61 966 7269504 83 Linux Partition 2 has different physical/logical beginnings (non-Linux?): phys=(1023, 3, 16) logical=(60, 202, 15) Partition 2 has different physical/logical endings: phys=(1023, 3, 16) logical=(965, 205, 8) Partition 2 does not end on cylinder boundary
jll544 said: Right, virtually all .zip restore files are filesystem-level recovery and assume that the partition table is unchanged. Try forcing the geometry using "fdisk -H 255 -S 63 /dev/block/mmcblk0" Click to expand... Click to collapse What he said. Texas Instrumentss OMAP devices such as the nook require that media, whether sd, mmc, etc, be formatted with particular geometry. One that's set up, you can create the partitions normally and forget it ever happened. Remember that the first partition should be FAT, and this is where the kernel (uImage) and ramdisk (uRamdisk) as well as bootloader (u-boot.bin) and pre-bootloader (mlo) go. See here for more info.
I believe the version of busybox available to me on this 3.0.2.8 CWR SD image is too old to accomplish what the instructions on this post state: http://forum.xda-developers.com/showpost.php?p=13971291&postcount=110 I've been unable to find a bundle of the binaries yet, but I'm still looking. That being said, I changed the geometry of the partition table and wrote the changes, then tried to dd again - fail.
sangandongo said: Before I write this, does the following look like what you'd expect? I mean, it makes sense considering... Code: Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 1 61 488312 b Win95 FAT32 Partition 1 has different physical/logical beginnings (non-Linux?): phys=(0, 1, 1) logical=(0, 0, 17) Partition 1 has different physical/logical endings: phys=(1023, 3, 16) logical=(60, 202, 14) Partition 1 does not end on cylinder boundary <snip> Click to expand... Click to collapse You mean you wrote the partition table as shown above? That won't work. You need to run fdisk with the corrected geometry, delete the existing partitions, and create new ones. Those warnings say that your partition LBA's are still aligned to the incorrect geometry.
What happens when remove all if the partitioning on the emmc, format it, and repartition it? For some reason ive found linux has a tendency to corrupt storage bits of memory chips altogether and the only way to restore was to completely start over clean. Also, anyone tested for bad blocks? One of my laptops decided to take a **** and the only way I'm able to install an os on it is by installing ubuntu on half the hard drive. Maybe if it is bad blocks we could repartition around them? Sent from my PC36100 using Tapatalk
RileyGrant said: What happens when remove all if the partitioning on the emmc, format it, and repartition it? For some reason ive found linux has a tendency to corrupt storage bits of memory chips altogether and the only way to restore was to completely start over clean. Also, anyone tested for bad blocks? One of my laptops decided to take a **** and the only way I'm able to install an os on it is by installing ubuntu on half the hard drive. Maybe if it is bad blocks we could repartition around them? Click to expand... Click to collapse Save the FUD for somewhere else....
RileyGrant said: For some reason ive found linux has a tendency to corrupt storage bits of memory chips altogether and the only way to restore was to completely start over clean. Click to expand... Click to collapse LOL, just about any operating system will write an unsuitable partition table if the end user commands it to do so. No, the OP has omitted details about what he did to get into his situation, but there is no chance it just happened on its own (i.e., his partition layout is technically valid but unbootable by OMAP). If we're going to hazard wild guesses, I'd say he was trying to install Backtrack or some other non-Android Linux distribution.
Hahah I only used linux as an example because ubuntu its all I have run for a coupe years now. but you sir are completely oblivious too the fact that evo users, thunderbolt users and now nook users have reported the same issue and symptoms, always on gingerbread. A self corruption of internal memory. Sent from my PC36100 using Tapatalk
jll544 said: LOL, just about any operating system will write an unsuitable partition table if the end user commands it to do so. No, the OP has omitted details about what he did to get into his situation, but there is no chance it just happened on its own (i.e., his partition layout is technically valid but unbootable by OMAP). If we're going to hazard wild guesses, I'd say he was trying to install Backtrack or some other non-Android Linux distribution. Click to expand... Click to collapse In this case, I believe it was caused either by "fixing permissions" while using Rom Manager, or by doing it in CWM. This was in an attempt to get out of CM7 nightly #69, which all but rendered my system inoperable. I agree with you though: there's likely no reason why linux would cause corruption on a disk. If anything, an app might be to blame, but it would have to explicitly do so. That aside, I am very close to getting my Nook fixed. I rebuilt the partition table this morning after loading busybox 1.18 onto my SD card. ran 'fdisk' with the proper geometry, deleted the existing partitions, built each out to standard specs, then changed the filesystem id for each. After that I did a mkfs.vfat and mke2fs on the appropriate partitions and wrote the configuration. I rebooted, did a dd of a 1.0.1 boot image to mmcblk0p1 and of a system image to mmcblk0p5 and tried to boot, but I'm still getting a black screen. Here is my current partition table after I resized it and marked the partitions with their respective types: Code: /busybox fdisk -l /dev/block/mmcblk0 Disk /dev/block/mmcblk0: 7944 MB, 7944011776 bytes 255 heads, 63 sectors/track, 965 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/block/mmcblk0p1 1 9 72261 c Win95 FAT32 (LBA) /dev/block/mmcblk0p2 10 18 72292+ c Win95 FAT32 (LBA) /dev/block/mmcblk0p3 19 56 305235 83 Linux /dev/block/mmcblk0p4 57 965 7301542+ 5 Extended /dev/block/mmcblk0p5 57 114 465853+ 83 Linux /dev/block/mmcblk0p6 115 789 5421906 83 Linux /dev/block/mmcblk0p7 790 834 361431 83 Linux /dev/block/mmcblk0p8 835 965 1052226 c Win95 FAT32 (LBA) I made the Fat32 Partitions using mk.vfat and the linux partitions with mke2fs -j -L <label>. Something still just isn't right.
Blah. I get so OCD about this sort of ****. I need to just go outside and play, this is driving me nuts.
sangandongo said: Blah. I get so OCD about this sort of ****. I need to just go outside and play, this is driving me nuts. Click to expand... Click to collapse It's not booting because you're missing your /rom partition. There is no data in /mmcblk0p2, which init calls for all your device info. Hopefully you have a backup of that as well. Without it, you won't be able to run any roms with your nook color. And unfortunately that is a partition that is not good to share with anyone else besides each individual nook owner because is contains all the unique Device identifiers for your Nook. If two people would have the same Device info and you're both logged into your B&N stock, it will error out on the B&N server side and de-register your device and the other person as well. If you need further guidance, PM me and I'll see what I can do to help to resolve your /rom partition issue. -Racks
I DD'd every partition off my friend's Nook. Every one. Just to see if I could get this puppy running. Still black.
[SHARE] Partition Map (S5830i)
From being used to a Linux PC with everything on a couple of partitions, trying to suss out how Android works has baffled me a bit what with having so many things hidden away in so many different places. I couldn't find a partition map for our phone so I made one by looking at /proc/partitions, using the mount command, analysing s5830i ODIN pit files and searching the internet. I realise that this isn't new information in that I'm pretty sure this stuff is known by some people but I still thought that this was worth putting out there. I've listed the information in the following format: #blocks <device file name> <partition name> (<flash file name> <Odin part>) <information> Mount points are given where relevant. Partition name and flash file name are from the Odin pit file. To get the 'Odin part' I looked inside my “Full Firmware Backup To Odin Format”, which is a CWM script by Rafael.Baugis. I've tried to be as accurate as possible and make it clear where I'm not 100% sure but please help me improve it if you can as I done this as a learning exercise in the first place! Figures from /proc/partitions (also see the mount command): #blocks name 31166976 mmcblk0 – sdcard (entire device) 29179904 mmcblk0p1 – sdcard partition 1 * 1945600 mmcblk0p2 - sdcard partition 2 * 513024 bml0/c – All bml partitions (figures add up to 513024) 256 bml1 – bcm_boot (BcmBoot.img – BOOT) – Bootloader 2048 bml2 – loke (sbl.bin - PDA) - Secondary bootloader 2048 bml3 – loke_bk (no flash file) - Presumably SBL backup 256 bml4 – systemdata (totoro.pit) – A copy of the Odin pit file by the looks of it 12800 bml5 – modem (BcmCP.img – PHONE) - baseband/modem 5120 bml6 – see stl6 ** 5120 bml7 – boot (boot.img - PDA) - The kernel and ramdisk 5120 bml8 – boot_backup (no flash file) – Presumably boot.img backup 235520 bml9 – see stl9 ** 40960 bml10 – see stl10 ** 201984 bml11 – see stl11 ** 256 bml12 – efs (?) (no flash file) – Not sure why this is called 'efs' as efs is well documented as being on bml15 and the number of blocks isn't even the same 256 bml13 – sysparm (sysparm_dep.img – BOOT) – part of the bootloader? 256 bml14 – umts_cal - (HEDGE_NVRAM8_RF_LE.bin – BOOT) – part of the bootloader? 1024 bml15 – cal (no flash file) - Not sure about the name but this is the EFS partition containing IMEI + network/region lock info 1280 stl6 – param_lfs (param.lfs – PDA) - mount point: /mnt/.lfs – SBL data including settings and images such as Samsung S5830i boot logo. 227840 stl9 – system (system.img - PDA) - mount point: /system – Operating System / ROM 36864 stl10 - cache (csc.rfs - CSC) - mount point: /cache – App/system cache storage but apparently CSC (region specific) data is also flashed here which seems odd but true! 194816 stl11 - userdata (userdata.img) - mount point: /data - (dm-0 to dm-18) - Each app that is stored via SD card has its own virtual partition. I have 19 applications stored via traditional apps2sd, hence dm-0 to dm-18. Mount Point: /mnt/asec/<app's Java package name> - (loop0 to loop18) – Loop devices. Each numbered loop is directly related to its dm counterpart, filesystem size is practically identical. I don't really understand loop devices that well so I can't say more than that! * SD card partitions have other block device files, from which they are mounted via, at: /dev/block/vold/179:1 - sdcard 1st partition – mount points: /mnt/sdcard and /mnt/secure/asec /dev/block/vold/179:2 - sdcard 2nd partition – mount point: /data/sdext2 ** This is from XDA user Darkshado in the following post: “From what I've gathered bml is essentially a lower level interface to the same blocks accessed by stl, but the results differ somewhat in resulting file size” http://forum.xda-developers.com/showpost.php?p=16963172&postcount=1 In actual fact bml and stl counterparts don't differ very much at all in size. From what I've read elsewhere the reason for the availability of stl interfaces on only some partitions may be related to the need for regular read-write access. *** stl* and bml* interfaces can be accessed through device files such as /dev/stl*, dev/bml*, /dev/block/stl* and dev/block/bml*. Of course just because they can be doesn't mean it's necessarily a good idea!
Unpacking contents in fastboot.img - possible?
I've downloaded a few different firmwares for VOG-L29 and used HuaweiUpdateExtractor to unpack images from the udpate.app files. I wanted to see if I can look at the content of fastboot.img, but it seems like this is packed and/or encrypted, so just wondering if anyone has taken a look into this before and have some suggestions? Since the file has quite high entropy I'm positive it's either packed in some way or worst case encrypted. Code: --/dload_VOG-L29.153/extracted$ file FASTBOOT.img FASTBOOT.img: data ../dload_VOG-L29.153/extracted$ binwalk FASTBOOT.img -E DECIMAL HEXADECIMAL ENTROPY -------------------------------------------------------------------------------- 2048 0x800 Falling entropy edge (0.084814) 4096 0x1000 Rising entropy edge (0.988633)
militiaOfDeath said: I've downloaded a few different firmwares for VOG-L29 and used HuaweiUpdateExtractor to unpack images from the udpate.app files. I wanted to see if I can look at the content of fastboot.img, but it seems like this is packed and/or encrypted, so just wondering if anyone has taken a look into this before and have some suggestions? Since the file has quite high entropy I'm positive it's either packed in some way or worst case encrypted. Code: --/dload_VOG-L29.153/extracted$ file FASTBOOT.img FASTBOOT.img: data ../dload_VOG-L29.153/extracted$ binwalk FASTBOOT.img -E DECIMAL HEXADECIMAL ENTROPY -------------------------------------------------------------------------------- 2048 0x800 Falling entropy edge (0.084814) 4096 0x1000 Rising entropy edge (0.988633) Click to expand... Click to collapse Did you try to mount it in Linux?
tibcsi0407 said: Did you try to mount it in Linux? Click to expand... Click to collapse No, but as far as I can see there is no signature data in the file that suggests that it can be mounted. As mentioned it seems to be mostly random data, so either it's some sort of archive or scrambled/encrypted/etc. I've uploaded the file to mega: https://mega.nz/#!4VwRhCSA!mJ55LuxzdIOQMOXTFVEuLZ5E9LVGgYy4aZl7gjohNe0
Extracing super.img (super2.img issue) and mounting vendor.img
Hi there, I am facing an issue, I am trying to extract binary from vendor.img (UPDATE.app/super2.img/simg2img/vendor.img), however it seems that when I mount vendor.img (erofs) it is not full (lib64 is missing). splituapp extract duplicate of super.img (named super.img and super2.img) it seems that super2.img is extracted sucessfully using lpunpack to vendor.img and some of vendor.img is in super.img which cannot be extracted using lpunpack (no magic). It is recurring to me with the newest firmwares for multiple devices. Let's take super.img from as a testcase (NOH-N29 11.0.0.167(C185E9R5P1)_Firmware_EMUI11.0.0_05017BYV) I am able to use lpunpack on super_2.img but `vendor.img` is all nulls and super.img cannot be extracted: Lpunpack on Update.app/super.img/simg2img/: lpunpack E 05-20 15:02:15 46076 46076 reader.cpp:81] [liblp]Logical partition metadata has invalid geometry magic signature. lpunpack E 05-20 15:02:15 46076 46076 reader.cpp:81] [liblp]Logical partition metadata has invalid geometry magic signature. Image does not appear to be in super-partition format. I had an idea that maybe due to the big size of super.img it is splitted to two different parts (super and super2) and I need to concat both of them somehow. any assistance will be apperiacted
I am working on the same issue, and the following is pure guessing. My conclusion is: super_2 is to be laid over super.img. This is due to my observation that no blocks overlap. That is to say, if you flash super.img and then super_2.img, the content is a combined, working super.img. I am right going to verify this and will post a subsequent update.
Solved! My guess was correct. First, read https://2net.co.uk/tutorial/android-sparse-image-format and download simg_dump.py at https://github.com/aosp-mirror/platform_system_core/blob/master/libsparse/simg_dump.py. Step 1. Dump the two simgs, and take note of any continuous ranges. Step 2. Convert both images to raw. Step 3. For each continuous range, do a block copy to create a merged file. Example: Step 1. ``` $ ./simg_dump.py -v super.img super.img: Total of 1316864 4096-byte output blocks in 192 input chunks. input_bytes output_blocks chunk offset number offset number 1 40 4 0 1 Fill with 0x00000000 2 56 139264 1 34 Raw data 3 139332 0 35 477 Don't care 4 139344 268435456 512 65536 Raw data ... (unimportant, but continuous) 190 3996191328 4 1142250 21 Fill with 0x00000000 191 3996191344 4096 1142271 1 Raw data 192 3996195452 0 1142272 174592 Don't care 3996195452 1316864 End $ ./simg_dump.py -v super_2.img super_2.img: Total of 1316864 4096-byte output blocks in 12 input chunks. input_bytes output_blocks chunk offset number offset number 1 40 0 0 1154560 Don't care 2 52 268435456 1154560 65536 Raw data 3 268435520 131432448 1220096 32088 Raw data 4 399867980 4 1252184 22792 Fill with 0x00000000 5 399867996 7827456 1274976 1911 Raw data 6 407695464 4 1276887 40 Fill with 0x00000000 7 407695480 4096 1276927 1 Raw data 8 407699588 135278592 1276928 33027 Raw data 9 542978192 4 1309955 6258 Fill with 0x00000000 10 542978208 2564096 1316213 626 Raw data 11 545542316 4 1316839 24 Fill with 0x00000000 12 545542332 4096 1316863 1 Raw data 545546428 1316864 End ``` Notice that in super.img, the continuous range ends at 191, block number 1142271 inclusive. The next item then says Don't care. In super_2, the first real item is chunk 2, corresponding to block number 1154560 onward. 1154560 is greater than 1142271. super_2 has the real end. Your super.img layout may not be the same as mine because super does not guarantee the order of partitions. Step 2. Convert both. Step 3. `dd if=super_2.raw.img of=super.raw.img bs=4K skip=1154560 seek=1154560` Do this for each continuous range, utilizing bs, skip, seek, and count parameters.