LAYOUT MAPPING COMPLETE! THANKS EVERYONE!
based on XXJF5 stock 2.1#1
256 KB -- bml1, contain boot.bin (262144 bytes), Primary Boot Loader (low-level hardware initialization)
256 KB -- bml2, contains PIT file first 512 bytes
10240 KB -- bml3 /dev/block/stl3 /efs
1280 KB -- bml4 contain Sbl.bin (1310720 bytes) Secondary Boot Loader (loads the Linux kernel and passes the necessary arguments)
1280KB -- bml5 contains Secondary Boot Loader (for recovery, ect)
5120KB -- bml6 param.lfs /mnt/.lfs j4fs
7680KB -- bml7 contain zImage and initramfs
7680KB -- bml8 empty
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition) /dev/block/stl9
137216KB -- bml10 dbdata.rfs ( /dbdata RFS Partition) /dev/block/stl10
35840KB -- bml11 cache.rfs ( /cache RFS Partition) /dev/block/stl11
12800KB -- bml12 modem.bin
Hello husq510
Thanks for this infos, i'll follow this thread closely because i'm looking for the place where ServiceMode settings are stored.
anyone tried writing to the bml directly?
husq510 said:
bash-3.2# ls -al /dev/block/bml*
1280 KB -- bml4 kernel (zImage)
293376KB -- bml9 factoryfs.rfs ( /system RFS Partition)
Click to expand...
Click to collapse
interesting. so ive dd the bml4 and bml9 of optus australia stock 19000DTJF3. now anyone want to point me in the direction of creating an odin package out of it.
i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?
jodue said:
i whoner .... how can bml4 be the zImage? bml4=1.2MB, zImage=5.8MB ?? also if it should just contain the kernel without initram, it's still about 2.6MB? any idea?
Click to expand...
Click to collapse
you are right, cant be. then kernel must be in some other bml place, seems bml7.
gandalf:~/Desktop/android/bml ackie$ grep "booting the kernel" *
Binary file bml7.dump matches
gandalf:~/Desktop/android/bml ackie$ hexdump -n 128 bml7.dump | grep "e1a0 0000 e1a0"
0000000 0000 e1a0 0000 e1a0 0000 e1a0 0000 e1a0
0000020 0002 ea00 [2818 016f] [0000 0000] [a510 005b] <- zimage magic number 0x016F2818, start at 0x0, end at 0x005b10a5
0000030 7001 e1a0 8002 e1a0 2000 e10f 0003 e312
0000040 0001 1a00 0017 e3a0 3456 ef12 2000 e10f
0000050 20c0 e382 f002 e121 0000 0000 0000 0000
0000060 00d0 e28f 307e e890 0001 e050 000a 0a00
0000070 5000 e085 6000 e086 c000 e08c 2000 e082
0000080
Offset into zImage Value Description
0x24 0x016F2818 Magic number used to identify this is an ARM Linux zImage
0x28 start address The address the zImage starts at
0x2C end address The address the zImage ends at
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.
husq510 said:
so if you start at 0x0 of bml7 and read untill offset inside 0x2c for XXJF5 is 0x005b10a5 you have your zImage.
Click to expand...
Click to collapse
so is it safe to assume after 0x005b10a5 is the ram disk?
Hello Folks.
I found some interesting bits in bml12.
"Service Mode" datas strings are in it, like show these example :
Code:
strings ./bml12 | grep Diamond
[SND] TurnON UtaAudioModifyHf(prev_Diamond_mode:0x%x)
`[SND]DiamondVoice_GetMode : path = 0x%x, Diamond_mode = 0x%x
`[SND]DiamondVoice_GetMode : Diamond_mode = 0x%x
[SND]DiamondVoiceTXcfgMSG
`[SND] DiamondVoice_RxInit : DiamondVoice_Mode_v = 0x%x
Diamond Solution
[9] Diamond Solution
[SND]DiamondVoice_Config : DiamondVoice_Mode_v = 0x%x, Diamond_mode= 0x%x
strings ./bml12 | grep DEBUG
MN_GPS_DEBUG_INFO_CNF
GPS_DEBUG_INFO_CNF
[1] DEBUG SCREEN
[2] DEBUG INFO
DEBUG INFO
DEBUG MSG 115200
DEBUG MSG SETTING FAIL
DEBUG MSG 921600
DEBUG MSG ON
DEBUG MSG OFF
AUDIO_LIB_DSP_DEBUG_GRP1
AUDIO_LIB_DSP_DEBUG_GRP2
AUDIO_LIB_DSP_DEBUG_GRP3
AUDIO_LIB_DSP_DEBUG_GRP4
AUDIO_LIB_DSP_DEBUG_GRP5
AUD_LIB_DSP_DEBUG
IPC_MISC_PHONE_DEBUG
IPC_MISC_DEBUG_LEVEL
IPC_SVC_DEBUG_DUMP
IPC_SVC_DEBUG_STRING
And I found my IMEI number in bml3
edit :
+ some MAC hardware address too (but not the Wifi one)
+ the HW Version : MP 0.800
I guess that bml3 is device-specific.
But I don't know if it's the source of specific values or just contains copy of hardware-related data.
In the first case, modifying bml3 would allow to change IMEI or other sensitive values ^^
nonato said:
so is it safe to assume after 0x005b10a5 is the ram disk?
Click to expand...
Click to collapse
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)
raspdeep said:
nope, to extract the ram disk, u hv to find the magic number of gz and extract the gzip image out... i was able to get the directory listing of the ramdisk but not the content..
the other problem is after u get the ramdisk and do any modifications, u hv to reverse the process.. not an easy job but if anyone found a solution, please share.
anyone try writing to the bml directly? dd doesnt seem to work
anyway, its possible to extract the image and use odin to flash after tar but if can write to bml directly, clockworkmod can effectively backup/restore the kernel.. (just a thought)
Click to expand...
Click to collapse
No, you cant write directly to bml.
Data write to a sector involves following sequence of low-level flash operations:
1. Block copy for back-up
2. Block erase
3. Copy back for non-modified pages
4. Writing the sector data to the modified page
These sequences of operations are not atomic, so a write request to this block device driver is prone to data corruption. For this reason, read-only file systems such as CRAMFS are adequate to run on top of this block device driver.
use this small script to extract your current zImage:
offset=`dd if=/dev/block/bml7 bs=1 skip=44 count=4 2>/dev/null| hexdump -e '1/4 "%d"' -e '"\n"'`
echo $offset
dd if=/dev/block/bml7 bs=1 count=$offset of=/sdcard/zImage_backup
husq510 said:
use this small script to extract your current zImage:
Click to expand...
Click to collapse
nice, thanks for sharing that!
i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init
how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors
how did you dump and make the zip file you have attached?
thanks,
husq510 said:
i just extracted initramfs from bml7, file attached, unzip and cpio -i
some file differs from leshak:
modules/dpram.ko
modules/multipdp.ko
modules/dhd.ko
modules/stgloc
initramfs/init.rc
.info/rootfs.info
default.prop
init.smdkc110.sh
sbin/recovery
sbin/init
Click to expand...
Click to collapse
raspdeep said:
how do u extract this?
gunzip -c initrd-cpio.zip | cpio -i does not work.. gave errors
Click to expand...
Click to collapse
[email protected] you have to use unzip instead gzip, cuz forum dislike .gz format, so I had to use standard zip.
mkdir initramfs
mv initrd-cpio.zip initramfs
cd initramfs
unzip initrd-cpio.zio
cat initrd.cpio | cpio -i --no-absolute-filenames
Hey, did somebody already tried to dump one or some bml partitions and restore them later ?
I guess this could be the ultimate backup tool.
I took a look into this and found that
bml2 : PIT file is here
bml5 : Sbl.bin is here
I opened it with a Hexeditor and compared with things from the firmware.
My device is running on JP3, froyo, at the moment.
thanks i will update first post. layout mapping is complete now!
I'm trying to make insecure boot.img for U9200 for my firmware version (V100R001C185B104). Unpacking original boot.img and ramdisk goes OK. After making changes to defult.prop I do the following:
mkbootfs ./ramdisk | gzip > ramdisk-new.gz
mkbootimg --kernel boot.img-kernel --ramdisk ramdisk-new.gz --base 0x80000000 --cmdline "console=ttyGS2,115200n8 mem=1G vmalloc=768M omap_wdt.timer_margin=30 mmcparts=mmcblk015(splash)" --board omap4 -o tools/flash/boot.img
New boot.img is successfuly created but doesn't boot (fastboot boot boot.img). What am I doing wrong?
I've got parameters using bootimg.exe and I think they are OK. There's nothing about them on the net
EDIT:
I made it using other mkbootimg.exe. This one accept more input parameters. This time I use bootimg.exe for upacking bootimg and unpacking and packing ramdisk. I did:
>bootimg.exe --unpack-bootimg
>bootimg.exe --unpack-ramdisk
Do changes at default.prop.
>bootimg.exe --repack-ramdisk
>mkdir flash\
>mkbootimg --kernel kernel --ramdisk ramdisk.cpio.gz --cmdline "console=ttyGS2,115200n8 mem=1G vmalloc=768M omap_wdt.timer_margin=30 mmcparts=mmcblk015(splash)" --board omap4 --base 0x80000000 --pagesize 2048 -o flash\boot.img
Reboot to bootloader:
>adb reboot bootloader
Test if you have good drivers installed:
>fastboot devices
If OK, test your new boot.img without flashing it:
>fastboot boot boot.img
If device boots and you want to have this image permanant flash it with:
>fastboot flash boot.img.
I've attached the tools that worked for me. I'm coplete noob in Android cooking, this is my first steps. There are lot about editing boot.img on the internet but nothing about my device so I decided to start a new topic if someone is also interested in.
also cracking my U9500. Have you done with your problems?
i use bootimg.exe to unpack & repack the img file, using same parameters and nothing modified to the extracted files,
but,
the new & old boot.img(should be same) are not same using binary compare.
according to a file that describes how boot.img is structured, i found that some key parameters are different in these two img file.
I don't know why ....
so if you have succeeded, PLZ tell me ..
contact me qq 6777711 if you're Chinese. or mail me: 6777711 AT qq.com
Nice one. I'll take a look at this aswell.
I want to load a custom ROM on my Desire Z. (finally!)
And I eventually got adb to work.
Now following the guide: Rooting the Vision (G2/DZ) and DHD; I got as far as this step:
4 S-OFF, root and its friends Super-CID, SIM-unlock, engineering hboot, clockwork recovery and root
In the following section we are trying to gain write access to the emmc by power cycling it.
We recommend to install the engineering hboot as part of the gfree procedure.
In the root shell (indicated by the #) that you got in the Temporary root section execute the following commands:
Code:
# cd /data/local/tmp
# ./gfree -f -b hboot-eng.img -y recovery.img
# ./root_psn
# sync
Wait a few seconds for the changes to "take".
Click to expand...
Click to collapse
Before receiving this error:
Code:
# ./gfree -f -b hboot-eng.img -y recovery.img
./gfree -f -b hboot-eng.img -y recovery.img
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
--hboot set. hboot image hboot-eng.img will be installed in partition 18
--recovery set. recovery image recovery.img will be installed in partition 21
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.32.21-g132894e
New .modinfo section size: 204
Attempting to power cycle eMMC... OK.
Write protect was successfully disabled.
Searching for mmc_blk_issue_rq symbol...
- Address: c02adc44, type: t, name: mmc_blk_issue_rq, module: N/A
Kernel map base: 0xc02ad000
Kernel memory mapped to 0x40002000
Searching for brq filter...
- Address: 0xc02adc44 + 0x34c
- 0x2a000012 -> 0xea000012
Backing up current partition 18 and installing specified hboot image...
md5sum #1 = 62c0aac0a85f3a0a0cbe364b64c552e6
md5sum #2 = 2ce1bdd5e4c1119ccfcecb938710d742
Backing up partition /dev/block/mmcblk0p18 to /sdcard/part18backup-1363017105.bin ...
Writing image hboot-eng.img to partition /dev/block/mmcblk0p18 ...
md5sum #3 = 62c0aac0a85f3a0a0cbe364b64c552e6
md5sum #3 == md5sum #1 - the hboot image was not installed!
Probably the power cycle of the eMMC failed. Check the messages above.
You might join the IRC channel #G2Root on Freenode for further help!
What should be my next course of action?
Thanks for all suggestions,
Alec Taylor
Double check you have the right hboot downloaded and that the md5sum matches, then run the command again. If you still have issues copy and paste your input/output from cmd here
Sent from my Nexus 7 using xda premium
I have included the input/output from my CMD in the initial post.
Sorry I thought you were just copying and pasting from the guide you were folowing. I guess I was reffuring to the entire root procedure but its no big deal
Its telling you exactly what is happening, phone didn't take the flash of the new engineeging bootloader, probably the emmc didn't cycle, try running command again, if its the same outcome double check your radio version as that can cause this or can you post all info from your hboot screen here
Sent from my SGH-T839 using Tapatalk 2
Also I couldn't get it to work with Gingerbreak or DooMLoRD's Easy Rooting Toolkit either.
*bump*
Right down all info on boot loader, you seem to know what to do but you're missing something, possibly need to change radio as gfree will not work with newer ones
Sent from my Nexus 7 using xda premium
FYI: Was able to root it finally by upgrading my stock to gingerbread from froyo; then back down to non-stock froyo followed by upgrade to modded Jelly Bean.
Hi all folks,
I have some question about the stock android system in this specific box and the format of the dumped partition.
Try to explain, I'm using rkflashtool to interact with the memory of the RK3188
This is the output of the command
rkflashtool r 0 1 | head -n 11
-------------------------------------------------------------------------------------------------
CMDLINE:console=ttyFIQ0 androidboot.console=ttyFIQ0
init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:
[email protected](misc),
[email protected](kernel),
[email protected](boot),
[email protected](recovery),
[email protected](backup),
[email protected](cache),
[email protected](userdata),
[email protected](kpanic),
[email protected](system),
[email protected](user)
-------------------------------------------------------------------------------------------------
I guess the boot partition is something linke that:
+-------+ <--- 0x00019fe0
| boot |
+-------+ <----0x00012000
With this command i'm able to dump the entrie boot partition on my linux box in a file named b00t.img :
rkflashtool r 0x12000 0x8000 > b00t.img
Now, i have find out that with the tool rkunpack (or simply with dd) i'm able to unpack this b00t.img. The output are two file:
b00t.img-raw
b00t.img-symbol
The first file is no more than a gzip compressed data file, I'm able to extract the data in a directory with this command:
gunzip < ../b00t.img-raw | sudo cpio -i --make-directories
Now in this dir I have all the files of the / partition. I can modify for example the /init.rc.
I want to repack the entrie b00t.img in order to flash it again on the device.
NB:
In this thread this guys work at something like my problem...
http://www.freaktab.com/showthread....-Tricks-by-Finless&p=4055&viewfull=1#post4055
The difference is that they work on a different partition layout, and the rkunpack of dumped boot.img return they only boot.img-raw.
Obviously I've already tried to repack the modified directory in this two ways:
mkcramfs myboot myboot-temp.img
kcrc myboot-temp.img customboot.img
or
find . ! -name "."| sort | cpio -oa -H newc | gzip -n > ../newboot.gz
kcrc newboot.gz customboot.img
Neither of these leads to obtain a file large enough to fit the boot partition on the deivice, that I want fill with:
rkflashtool w 0x12000 0x8000 < modifiedb00t.img
Has anyone ever worked with rk3188? Any idea?
Thanks in advance.
Anyone?
EDIT I FIGURED IT OUT, after some head scratching and studying of magisk 15.3 zip.
Below is how I was able to edit the init.rc:
Required:
Magisk-v15.3.zip
- Magisk-v15.3/arm64/magiskboot
- Magisk-v15.3/chromeos/futility
- Magisk-v15.3/chromeos/kernel.keyblock
- Magisk-v15.3/chromeos/kernel_data_key.vbprivk
*I have to sudo adb, not sure how to have the permissions by default.*
Code:
adb push futility /sdcard/
adb push magiskboot /sdcard/
cp /sdcard/futility /system/bin/
chmod u+x /system/bin/futility
cp magiskboot /system/bin/
chmod u+x /system/bin/magiskboot
mkdir -p /sdcard/initrc
adb push kernel_data_key.vbprivk /sdcard/initrc/
adb push kernel.keyblock /sdcard/initrc/
Old guides on the interwebs tell you that lnx is the partition to unpack / repack flash however if you peek at Magisk-v15.3/common/util_functions.sh
Code:
find_boot_image() {
...
for BLOCK in boot_a kern-a android_boot kernel boot lnx bootimg; do
BOOTIMAGE=`find /dev/block -iname $BLOCK | head -n 1` 2>/dev/null
Because there's a kern-a that's the one you need to use. The above command gets me:
/dev/block/platform/700b0600.sdhci/by-name/KERN-A
The above command also is used to display: "Found boot image: /dev/block/mmcblk0p1" (cat /proc/partitions) during Magisk installation.
Now that I've figured out the boot partition, I'll use magiskboot to unpack it.
Code:
cd /sdcard/initrc
magiskboot --unpack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
The unpacking will create dtb, kernel, and ramdisk.cpio. I'll extract the ramdisk.cpio so I can add / edit files.
**NOTE** if you get a permission denied .backup / .subackup just run sudo
Code:
mkdir ramdisk
cd ramdisk
sudo cpio -i -d -m < ../ramdisk.cpio
I'm not sure how to fix this but I was getting:
cpio: bugreports: Operation not permitted
cpio: charger: Operation not permitted
cpio: d: Operation not permitted
cpio: etc: Operation not permitted
cpio: sbin/ueventd: Operation not permitted
cpio: sbin/watchdogd: Operation not permitted
cpio: sdcard: Operation not permitted
I was forced to copy ramdisk.cpio to my computer and extract it, update, and repack it there.
Once you're ready to repack and move the ramdisk back to the pixel c.
Code:
sudo find . | sudo cpio -R 0:0 -H newc -o > ../newramdisk.cpio
mv /sdcard/initrc/ramdisk.cpio /sdcard/initrc/ramdisk.cpio.orig
adb push newramdisk.cpio /sdcard/initrc/ramdisk.cpio
cd /sdcard/initrc && magiskboot --repack /dev/block/platform/700b0600.sdhci/by-name/KERN-A
MagiskBoot v15.3(1531) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/block/platform/700b0600.sdhci/by-name/KERN-A]
KERNEL [5481552] @ 0x10008000
RAMDISK [1876886] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
DTB [5481552]
KERNEL_FMT [dtb]
RAMDISK_FMT [gzip]
Repack to boot image: [new-boot.img]
KERNEL [5481552] @ 0x10008000
RAMDISK [1879383] @ 0x11000000
SECOND [0] @ 0x10f00000
EXTRA [0] @ 0x10000100
PAGESIZE [2048]
OS_VERSION [8.1.0]
PATCH_LEVEL [2018-03]
NAME []
CMDLINE [buildvariant=userdebug]
This will create "new-boot.img" file. Next we'll need to sign the image. If someone can explain why it's required that would be great.
Code:
cd /sdcard/initrc
echo > empty
futility vbutil_kernel --pack new-boot.img.signed --keyblock ./kernel.keyblock --signprivate ./kernel_data_key.vbprivk --version 1 --vmlinuz new-boot.img --config empty --arch arm --bootloader empty --flags 0x1
Finally flash the signed boot image and reboot
Code:
cat /sdcard/initrc/new-boot.img.signed | eval cat - | cat - /dev/zero 2>/dev/null | dd of=/dev/block/platform/700b0600.sdhci/by-name/KERN-A bs=4096
dd: /dev/block/platform/700b0600.sdhci/by-name/KERN-A: No space left on device
8193+0 records in
8192+0 records out
33554432 bytes transferred in 0.129 secs (260111875 bytes/sec)
---ORIGINAL POST---
Trying to edit init.rc (or anything really in the ramdisk) by unpacking / repacking and flashing but I get stuck in a TWRP 3.2.1-0 bootloop. I've been using the latest unofficial lineage March 8, 2018 from followmsi
I'm not sure if there's an easier way or I'm doing it wrong all the guides out there are from 2012-2014.
With github com/xiaolu/mkbootimg_tools was using the LNX partition but then noticed the SuperSu.zip when installing from TWRP was using KERN-A the mmcblk0p1.
Code:
Unpack & decompress ../boot.img to boot
kernel : kernel
ramdisk : ramdisk
page size : 2048
kernel size : 5463088
ramdisk size : 1594653
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : buildvariant=userdebug
ramdisk is gzip format.
Unpack completed.
When flashing either of them I get stuck in the bootloop. I've tried fastboot flash boot new_boot.img, dd and cat > when updating the repacked boot image. I also tried fastboot flash:raw boot <kernel> [ <ramdisk> [ <second> ] ] create bootimage and flash it.
When booting the image without flashing via sudo fastboot boot new_boot.img I get stuck on the lineageOS logo before it reboots to recovery TWRP then I have to reboot again to get back into the rom.
I've also tried many other unpacking / packing script tools with no success just bootloops or complaints about invalid boot.img
I don't understand how supersu and magisk zip can have zips run from twrp that are able to edit the ramdisk? Are they running a compiled c program like this? github com/TeamWin/Team-Win-Recovery-Project/blob/8373cfe28cf1b5ad758faa1d502e21787c3665e4/injecttwrp/injecttwrp.c
Probably not relevant (disclaimer couldn't hex edit my way out of a paper bag) but noticed sometimes when repacking with different tools and peeking at the new boot image with ghex that the first line in the original boot was always CHROMEOS but the repacked would say ANDROID! and be just 5-7mb when the boot image backup would be 36mb in size.
Code:
APP -> /dev/block/mmcblk0p4
CAC -> /dev/block/mmcblk0p6
KERN-A -> /dev/block/mmcblk0p1
KERN-B -> /dev/block/mmcblk0p2
LNX -> /dev/block/mmcblk0p9
MD1 -> /dev/block/mmcblk0p8
MSC -> /dev/block/mmcblk0p10
PST -> /dev/block/mmcblk0p11
UDA -> /dev/block/mmcblk0p7
VNR -> /dev/block/mmcblk0p5
recovery -> /dev/block/mmcblk0p3
cat /proc/partitions
Code:
7 0 98304 loop0
254 0 520912 zram0
179 0 61071360 mmcblk0
179 1 32768 mmcblk0p1
179 2 32768 mmcblk0p2
179 3 32768 mmcblk0p3
179 4 3670016 mmcblk0p4
179 5 311296 mmcblk0p5
179 6 409600 mmcblk0p6
179 7 56470528 mmcblk0p7
179 8 65536 mmcblk0p8
179 9 32768 mmcblk0p9
179 10 4096 mmcblk0p10
179 11 512 mmcblk0p11
179 96 4096 mmcblk0rpmb
179 64 4096 mmcblk0boot1
179 32 4096 mmcblk0boot0
253 0 56470528 dm-0