With the issue of TWRP 3.0.2-1 causing bootloops from people going back to MM from N because that version had a bug in the EFS restore functionality, I mistakenly formatted the /persist partition of my Nexus 6P attempting to find a fix last weekend.
I noticed no ill effects at first, and then I realized that some sensor readings (for example the tilt reading on GPS Status & Toolbox app) were inconsistent. After looking at the /persist partition on different Nexus 6P, I was able to identify most of the partition contents with a bit of searching, and what is affected.
Code:
/persist/audio/speaker_calibdata.bin - text file, holds values for calibrating speaker (e.g. L:6.778258 R:6.556932 ), not sure of the scale of values
/persist/data/st_offset and /persist/data/st_xtalk - laser autofocus calibration data (according to Nexus 6P Android [URL="https://android.googlesource.com/device/huawei/angler/+/android-6.0.1_r62/init.angler.rc"]source code[/URL])
/persist/data/sfs - some sort of DRM files
/persist/data/tz - related to a qualcomm trustzone increment only counter
/persist/usf - related to digital pen calibration (except for /persist/usf/mixer)
/persist/usf/mixer - related to sound device specific mixer settings
/persist/.bt_nv.bin - contains what looks to be a MAC address if opened in a hex editor, however it is not the address of the BT MAC of the phone
/persist/sensorcal.json - contains data for Nexus 6P sensors (in this case acceleration, barometer, gyro, and proximity)
A lot of these files don't seem like they are even used, except for /persist/sensorcal.json
Using the post here, I was able to figure out the right syntax to regenerate this file:
(Note, the following requires SELinux to be set as permissive, as well as root access)
Code:
sensortool.angler -c all:1013
where 1013 in the above command is the true barometer reading in mb (mmHg) from the known calibrated Nexus 6P. Also to note, if the calibration data stored on the device significantly deviates from the current regenerated values, the calibration of some sensors might fail. In this case, deleting the /persist/sensorcal.json file if it exists, rebooting, and re-issuing the command should fix that issue, and the sensors should all calibrate successfully. Sample output:
Code:
[email protected]:/vendor/bin # sensortool.angler -c all:1013
resetting target.
sensorhub said: 'Hello, world!'
sensorhub said: 'Found Bosch BMP280 Pressure/Temperature Sensor'
sensorhub said: 'Found AMS TMD27723 Proximity/ALS Sensor'
sensorhub said: 'Found Bosch BMI160 Accel/Gyro Sensor'
sensorhub said: 'init: 0 0 0, 0 0 0, 0.00, 0'
sensorhub said: 'batch 18 flags:0, sampling_rate_Hz:1.00, max_report_latency_us:0'
sensorhub said: 'activate 18 enable:1'
onMagAccuracyUpdate 0
onMagBiasUpdate 0.00, 0.00, 0.00
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'calibrate 4'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'calibrate 1'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'calibrate 2'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'calibrate 6'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'sensor 4 calibration SUCCESS: -1.96'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'Found Bosch BMM150 Mag Sensor'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'sensor 1 calibration SUCCESS: 16 / -1 / -11'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'sensor 2 calibration SUCCESS: 7 / -2 / -1'
18: 283042619 us, 0.00 0.00 0.00
sensorhub said: 'sensor 6 calibration SUCCESS: 14'
18: 283042619 us, 0.00 0.00 0.00
writing json: {
"accel": [
16,
-1,
-11
],
"barometer": -1.960000,
"gyro": [
7,
-2,
-1
],
"proximity": 14
}
Figured I'd update this in case anyone else comes across this issue. Lastly, since there are no personally identifiable contents in this partition, I have perfomed a backup that is flashable from TWRP on a Nexus 6P. After copying persist.img to /tmp on the phone's filesystem, the following command will restore it:
Code:
dd if=/tmp/persist.img of=/dev/block/platform/soc.0/f9824900.sdhci/by-name/persist
Backup of Nexus 6P /persist partition (ext4 image) is here.
<reserved>
Ended up solving the issue on my own, turns out the magnetic sensor was not affected by the missing sensor calibration file, which can be re-generated as stated on the OP.
Related
Hi All,
I have been trying to find the best way to configure my swap for my android phone, currently the G1. I had started out with the regular swap partition but find my phone performance degraded over time thus I decided to test the usual read/write for my Class 6 Micro SDHC card.
Configure the SD card via fdisk and setup 3 partitions (like everyone else).
Command (m for help): p
Disk /dev/sdm: 8166 MB, 8166309888 bytes
224 heads, 56 sectors/track, 1271 cylinders
Units = cylinders of 12544 * 512 = 6422528 bytes
Disk identifier: 0x3114df25
Device Boot Start End Blocks Id System
/dev/sdm1 1 800 5017572 c W95 FAT32 (LBA)
/dev/sdm2 801 1100 1881600 83 Linux
/dev/sdm3 1101 1271 1072512 82 Linux swap / Solaris
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
WARNING: If you have created or modified any DOS 6.x
partitions, please see the fdisk manual page for additional
information.
Syncing disks.
Afterward, format the drive as vfat, ext3, swap
localhost ~ # mkfs.vfat /dev/sdm1
mkfs.vfat 3.0.1 (23 Nov 2008)
localhost ~ # mkfs.ext3 /dev/sdm2
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
117600 inodes, 470400 blocks
23520 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=482344960
15 block groups
32768 blocks per group, 32768 fragments per group
7840 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
localhost ~ # mkswap /dev/sdm3
Setting up swapspace version 1, size = 1072508 KiB
no label, UUID=2046ef6b-ac5a-47a2-9484-ea2a356cc7fa
now the read performance via "hdparm -t /dev/sdxxx"
sdm1 (fat) = Timing buffered disk reads: 26 MB in 3.12 seconds = 8.34 MB/sec
sdm2 (ext3) = Timing buffered disk reads: 26 MB in 3.11 seconds = 8.35 MB/sec
sdm3 (swap) = Timing buffered disk reads: 26 MB in 3.08 seconds = 8.45 MB/sec
as you can see, reading is more or less the same across the board.
now the fun part of write. for fat and ext3, I decided to write to a file, for the swap partition, I decided to write directly to the partition.
FAT:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm1/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.9464 s, 6.4 MB/s
EXT3:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=sdm2/test.write
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 4.94644 s, 6.4 MB/s
SWAP:
localhost ~ # dd count=30 bs=1M if=/dev/urandom of=/dev/sdm3
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 8.79714 s, 3.6 MB/s
As you can see, write to a FAT or EXT3 partition seems to be faster than writing to a swap partition. Of course, this is assuming I have done my test correctly . If writing to FAT or EXT3 is faster and reads are the same, would it mean that you get better SWAP performance via a swap file on an EXT3 partition?
thanx for the interesting read
Your write test is flawed.
Flaw 1: You use /dev/urandom as a data source. Data generation from /dev/urandom is heavily affected by CPU usage AND by available entropy -- though it doesn't block, its speed does vary drastically.
Flaw 2: You only run the test ONCE. This means that issues from flaw 1 are totally visible rather than being averaged out over a large number of tests. You should do the test 100's of times and take the average over them.
Flaw 3: Implementation of the ext3 filesystem tend to hide the effects of disk latency. There are caches and journals that you haven't accounted for. In order to get the ACTUAL time that it takes to write to the ext3 filesystem, you need to follow the write test by a synchronization, which will *actually* write the data to the disk (i.e., it will BLOCK until the write is actually completed). Unfortunately though, this test will also synchronize OTHER write operations that are buffered, which will further skew your results. What you REALLY need to do is perform the tests on a completely empty partition. Should be starting sync, begin time, test write, finishing sync, finishing time. Elapsed time = finishing time - begin time.
In other words, I'm sorry, but your conclusions are not correct. What I *very strongly* suspect, is that if you do your tests correctly, you will find that the performance of swap-on-ext3 will actually be *lower* than swap-on-partition due to the extra overhead of the ext3 filesystem.
Note: the linux vfat filesystem implementation also buffers writes.
A little bit of fun trivia:
Back in the days when we actually used floppy disks, you could actually copy an entire disk worth of data over to a vfat floppy disk without it even BEGINNING to write to the disk. Usually, it would begin writing several seconds after the copy "completed". If you wanted to speed it along, a sync or umount would force the buffer immediately to write to disk.
ahhh...thanks for the info. I guess with buffer, it makes timing or calculating the write speed a bit difficult. I will have to think more about this.
This really makes me wonder how do SD card manufactures test their write speed and assign the card class.
I believe they do a test similar to yours without any buffering and write different amounts of data to simple file systems.
Then, according to http://en.wikipedia.org/wiki/Secure_Digital the class number is equal to the amount of minimum write megabytes per second that can be written to the disk when in a clean and unfragmented state. So a class 6 card would at it's slowest writing speed on a perfectly setup disk be able to write data at 6 megabytes per second or faster. Read speed isn't taken into account for the rating, but is generally faster than write speed.
I redid my test with raw write via if=/dev/zero and the write speed is now on-par with what was classified on the SD class. (7.4MBps write on my class 6). Playing around w/ the setting more, seems like the over-time degradation seems to be caused by my swappiness configuration.
Hi all,
So I've made a few backup images of my nook and want to be able to access the files on there without problems. I'm not the most knowledgeable Linux guy but have a Kubuntu VirtualBox image lying around for when I decide to compile Rockbox and such. I've also got Cygwin installed, but never expect it to do anything correctly, really. I haven't really come across any Windows tools that'll do the trick for me, so I want to know what I'm doing wrong with my parameters for the 'mount' command in Linux. What I really want right now is to get into the the system partition (#5).
Now I don't really know how to use mount beyond a little bit of googling, so I likely missed something here, but anyway, this is what I did:
I ran
Code:
fdisk -l nook_1.0.0_backup.img
and got this:
Disk nook_1.0.0_backup.img: 1958 MB, 1958739968 bytes
128 heads, 32 sectors/track, 934 cylinders, total 3825664 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
nook_1.0.0_backup.img1 * 32 155647 77808 c W95 FAT32 (LBA)
nook_1.0.0_backup.img2 155648 188415 16384 c W95 FAT32 (LBA)
nook_1.0.0_backup.img3 188416 577535 194560 83 Linux
nook_1.0.0_backup.img4 577536 3792895 1607680 5 Extended
nook_1.0.0_backup.img5 577568 1167359 294896 83 Linux
nook_1.0.0_backup.img6 1167392 1658879 245744 c W95 FAT32 (LBA)
nook_1.0.0_backup.img7 1658912 2150399 245744 83 Linux
nook_1.0.0_backup.img8 2150432 3792895 821232 83 Linux
I multiplied 577568 by 512 to get an offset of 295698432, and knew that the system partition uses ext2 by running 'mount' in the nook's shell, so then I ran:
Code:
mount -o loop,offset=295698432 -t ext2 nook_1.0.0_backup.img /media/n2e
and keep getting this error message:
wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases, useful info is found in syslog - try
dmesg | tail or so
trying dmesg | tail yielded this gibberish:
[ 6690.080964] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081015] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081081] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081131] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081181] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081231] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081286] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081337] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081387] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
[ 6690.081437] VbglR0HGCMInternalCall: vbglR0HGCMInternalPreprocessCall failed. rc=-2
I also tried using dd to extract that partition (which I also did correctly if you go by file size, which is identical to the file size listed when I extract it via 7-zip in Windows) and then tried to mount that, but got the same message. I'm thinking this is all a simple syntactical error...any ideas? roustabout? ros87?
Wait, so this piece of software does the trick in Windows:
http://www.diskinternals.com/linux-reader/
But I'd still like to know how to mount correctly.
Double posting will make you quite popular with the moderators,.. not!
I answered you here.
very simple bash script:
Code:
#!/bin/bash
if test $# -lt 2; then
echo "usage: $0 [image] [mount point] <partition number>"
exit
fi
if test -z $3
then
number=1
else
number=$3
fi
mount -o loop,ro,offset=$(parted $1 unit B print | grep "^ $number" | sed "s/\s$number\s*\([0-9]*\)B\s*.*/\1/") $1 $2
In case this info is of use to someone...
Trying to understand what goes where,
Here is the partition table of a U8800:
#######################################
Disk /dev/sdb: 3959 MB, 3959422976 bytes
1 heads, 62 sectors/track, 124729 cylinders, total 7733248 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 491520 245760 b W95 FAT32
/dev/sdb2 * 491521 492520 500 4d QNX4.x
/dev/sdb3 492521 498520 3000 46 Unknown
/dev/sdb4 498521 7733247 3617363+ 5 Extended
/dev/sdb5 524288 548863 12288 59 Unknown
/dev/sdb6 655360 921599 133120 4c Unknown
/dev/sdb7 1048576 1049575 500 5a Unknown
/dev/sdb8 1179648 1185791 3072 58 Unknown
/dev/sdb9 1310720 1324719 7000 50 OnTrack DM
/dev/sdb10 1441792 1447935 3072 4a Unknown
/dev/sdb11 1572864 1579007 3072 4b Unknown
/dev/sdb12 1703936 2154495 225280 83 Linux
/dev/sdb13 2228224 3457023 614400 83 Linux
/dev/sdb14 3538944 7733247 2097152 69 Unknown
#############################################
sdb1: This is the FAT32 partition that gets mounted when we boot into pink screen;
It holds, among other files, EMMCBOOT.MBN, which, if not present and as far as I've experimented, will get the phone straight into a blue screen and initiate a flash procedure if a 'dload' folder with a ROM is found in the sdcard. The contens of this partition are changed when a ROM is flashed.
sdb2: Is flagged as bootable, and holds an (so far) unknown filesystem (if any; could hold a raw binary image, for instance);
sdb3: Holds an unknown filesystem, if any. This partition is changed whenever you flash a ROM. dumping this partition back, from any 2.3BETA, to a 2.3 (B522) running phone, will get the USB pink screen mode working again, allowing acces to sdb1.
sdb5: holds an unknown filesystem if any; dumping this one back gets us the original "IDEOS" logo and, probably, whatever is needed to make previous CWM backups work again.
sdb6: ext3 filesystem with a directory called "recovery".
sdb7: Unknown filessytem, if any.
sdb8: Unknown filesystem, if any.
sdb9: Unknown filesystem, if any.
sdb10: Unknown filesystem, if any.
sdb11: Unknown filesystem, if any.
sdb12: ext3 filesystem; gets mounted at "/system".
sdb13: ext3 filesystem; gets mounted at "/data".
sdb14: vfat filesystem; represents the internal sdcard.
I'm trying to find out what needs to be restored in order to perform a clean, reliable downgrade. sdb5 is a must, but not the only one. I've flashed 2.2 and dumped it back right after. The result is an almost downgraded U8800. I say almost because charging the battery while the phone is off shows a different image (the one that comes with 2.3) and I can't power up the phone unless I take the cable out; this means there are still remnants of 2.3 somewhere...
UPDATE: Not being able to power up the phone was to due to the CWM recovery; restoring original recovery.img solved that one.
Well, I was glad to have found the thread that described my case perfectly (OTA brick, no recovery, no download, unable to reset). Thus, I installed Ubuntu, and followed all the steps. When I came to the final step of 'rebooting the phone', my VZW G2 VS980 (I think) was unresponsive to anything. I thought that perhaps it got fully discharged, so I hooked it up to a charger. And - nothing, not even after a few hours of charging. I realize that I used the files that may not be EXACTLY for the version I have, but someone on this thread suggested that these may still work. So - not sure if this was THE death blow...
If before Win8 recognized it as a Qualcomm device (with the attendant smorgasbord of phantom drives), now the error is for a generic 'unrecognized usb device'.
So - it is a complete brick, which does not respond to any hadrware inputs - i.e., matter what buttons are pressed and for how long, there is no response from the device.
Thoughts??
This is a copy from the terminal window, as it stands curently:
/dev/sda /dev/sda2 /dev/sdb1 /dev/sdb5
/dev/sda1 /dev/sdb /dev/sdb2 /dev/sdb6
Disk /dev/sdb: 976773168 sectors, 465.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 918B6C9F-D1B0-49D5-8CA2-F14781192942
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 976773134
Partitions will be aligned on 8-sector boundaries
Total free space is 4594 sectors (2.2 MiB)
Number Start (sector) End (sector) Size Code Name
1 63 780764729 372.3 GiB 0700 Microsoft basic data
5 780765184 959999999 85.5 GiB 8300 Linux filesystem
6 960002048 976771071 8.0 GiB 8200 Linux swap
Here is the long version.
My phone a U8800 Pro was running the official B928 version downloaded from Huawei
I wanted to install the latest version Cyanogen 11. That needed me to install the latest version of TWRP which led me to the mistake that I needed to update the bootloader as well.
And then I did another mistake where I installed what is obviously the wrong bootloader from here (http://forum.xda-developers.com/showthread.php?t=1800045) using
Code:
dd if=/tmp/bootloader.bin of=/dev/block/mmcblk0p3
The phone since then just boot cycles continously and cannot even login to recovery mode.
I attempted to re-install B928 from the SD card but always fails at about 1/4 of the way through with a
Code:
dload_sd_ram_data_proc->(retry >= DLOAD_RETRY) failed!
msg.
Now interestingly if I remove the battery and just use the USB I get an empty pink screen and I can see at least the partitions of the internal drive
Code:
Disk /dev/sdg: 3.7 GiB, 3959422976 bytes, 7733248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdg1 1 524287 262143+ c W95 FAT32 (LBA)
/dev/sdg2 * 524288 525287 500 4d QNX4.x
/dev/sdg3 525288 531287 3000 46 Unknown
/dev/sdg4 531288 7733247 3600980 5 Extended
/dev/sdg5 655360 679935 12288 59 Unknown
/dev/sdg6 786432 1052671 133120 4c Unknown
/dev/sdg7 1179648 1183743 2048 5a Unknown
/dev/sdg8 1310720 1316863 3072 58 Unknown
/dev/sdg9 1441792 1455791 7000 50 OnTrack DM
/dev/sdg10 1572864 1579007 3072 4a Unknown
/dev/sdg11 1703936 1710079 3072 4b Unknown
/dev/sdg12 1835008 2621439 393216 83 Linux
/dev/sdg13 2621440 4456447 917504 83 Linux
/dev/sdg14 4456448 7733247 1638400 69 Unknown
and can mount some of them.
Now where can I find an appropriate bootloader and which partition should I attempt to copy it on .
And secondly if that works out, how do I install TWRP 2.8.0.0 . Using TWRP manager fails which led to this whole mess really.
On /dev/sdg1 I can see a dir called image and it contains
Code:
amss.mbn boot.img cust.img EMMCBOOT.MBN recovery.img
but don't want to touch anything before I know more since I can do more dmg.
Thanks for all the help in advance
Edit: I managed to copy the bootloader from a friend and copy it back on my phone so that problem was solved. It needed to go to the /dev/sdg3 partition if anyone is wandering. Now pink screen seems locked and can't access the internal storage through USB so back to square 1.
Glad you got the problem solved out. When you unlock your bootloader (like I said in here), boot your phone to pink screen and plug it to your computer. You're using linux? If so, there probably is going to be four difference device's to be shown, the one which you're interested is the device containing "image" folder, in there replace the recovery.img with appropriate one.