Here, i've quickly compiled three MTD utils ( git://git.infradead.org/mtd-utils.git ):
nanddump, nandwrite, flash_erase
So far tested nanddump - works , i was wandering what's inside
--
mtd3: 00040000 00020000 "LogFilter"
mtd4: 00300000 00020000 "oem_log"
--
Nothing interesting, actually.
--
nandwrite should enable you to write boot, recovery, system and firstboot right from android system (i don't think that it's good idea, but anyway).
--
Readme:
MTD-Utils 1.5
Please use with extreme caution!
--
Streak 5, dump example for recovery:
./nanddump /dev/mtd/mtd1 -f /sdcard/mtd1
--
Our layout:
cat /proc/mtd
dev: size erasesize name
mtd0: 00500000 00020000 "boot"
mtd1: 00600000 00020000 "recovery"
mtd2: 00600000 00020000 "recovery_bak"
mtd3: 00040000 00020000 "LogFilter"
mtd4: 00300000 00020000 "oem_log"
mtd5: 00100000 00020000 "splash"
mtd6: 10400000 00020000 "system"
mtd7: 08c00000 00020000 "userdata"
--
Have fun,
Sergei (_n0p_)
(tools attached)
--
I was able to switch recovery on the fly, having /sdcard/CWM.img (CWM port by TheManii) and /sdcard/SM.img (Old and trusty StreakMod):
/system/xbin/flash_erase /dev/mtd/mtd1 0 0
/system/xbin/nandwrite /dev/mtd/mtd1 /sdcard/CWM.img
Reboot, checked if works - it does
Back to StreakMod:
/system/xbin/flash_erase /dev/mtd/mtd1 0 0
/system/xbin/nandwrite /dev/mtd/mtd1 /sdcard/SM.img
Changelog:
Added flash_erase
can you please guide how to flash this
should i flash this in streakmod recovery and will it wipe my current streakmod with cwm recovery ?
This zip pack should not be flashed.
This tools can operate on (at least) Streak NAND flash partitions, i.e. read, erase, write.
It contains three android binaries - you should extract them and place, preferably, into /system/xbin
Change permissions on al this files to 755 - like:
chmod 755 nanddump
Now, you should be able to flash boot(kernel) and recovery right from working Android system.
I've given an example in first post.
hunderteins, if you reading this - would you give mtd5 from your device?
I have it empty and wander what image format it should have.
Where is AMSS, DSP and stuff?
What do we have on NAND (my comments are in italic):
I/PrintK ( 1): <5>Creating 8 MTD partitions on "msm_nand":
54MB hole
I/PrintK ( 1): <5>0x000003600000-0x000003b00000 : "boot"
I/PrintK ( 1): <5>0x000003b00000-0x000004100000 : "recovery"
I/PrintK ( 1): <5>0x000004100000-0x000004700000 : "recovery_bak"
I/PrintK ( 1): <5>0x000004700000-0x000004740000 : "LogFilter"
I/PrintK ( 1): <5>0x000004740000-0x000004a40000 : "oem_log"
1MB hole
I/PrintK ( 1): <5>0x000004b40000-0x000004c40000 : "splash"
35MB hole
I/PrintK ( 1): <5>0x000007000000-0x000017400000 : "system"
I/PrintK ( 1): <5>0x000017400000-0x000030000000 : "userdata" (should be 0x000020000000)
W/PrintK ( 1): <4>mtd: partition "userdata" extends beyond the end of device "msm_nand" -- size truncated to 0x8c00000
According to this article:
http://forum.xda-developers.com/showthread.php?t=542688
this areas can be regained and hmmm, altered?
AMSS, DSP, service tag, provider lock and some other interesting stuff could be there!
_n0p_ said:
hunderteins, if you reading this - would you give mtd5 from your device?
I have it empty and wander what image format it should have.
Click to expand...
Click to collapse
nice one. Thanks. But my mtd5 is 1048576 times 0xff.
What is the difference between
$ cat /dev/mtd/mtd5 > /sdcard/mtd5
and
$ nanddump /dev/mtd/mtd5 -f /sdcard/mtd5
?
hunderteins said:
nice one. Thanks. But my mtd5 is 1048576 times 0xff.
What is the difference between
$ cat /dev/mtd/mtd5 > /sdcard/mtd5
and
$ nanddump /dev/mtd/mtd5 -f /sdcard/mtd5
?
Click to expand...
Click to collapse
Well, it seems that nothing, but this makes me feel dumber than usual
I didn't try cat :laugh:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
try reading the raw nand at the beginning of it, thats where its stored on emmc devices, and there is unmapped space in the beginning
54mb should be approx enough shouldnt it? (not at pc to verify file sizes of the firmwares)
you could compare to the spro's map i guess, its an emmc device, but not a qisda one.
if i had the mapping for the "streak2 5" that would be the best to compare to, but i dont
is there any way to verify the mem locations are correct? i have the exact emmc layout for the s7/s10 because nvflash provides it if asked.
but there is no standardized tool for qualcomm chips, ill assume they're correct
also: at least on filesystems you should use dd and not cat for the fact that cat drops the final byte or something to that degree.
i dont recall if it applies to yaffs2 but it should for ext, it shouldnt matter for raw mtd partitions
hmmm iam still confused need to wait more to know this all
TheManii said:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
try reading the raw nand at the beginning of it, thats where its stored on emmc devices, and there is unmapped space in the beginning
54mb should be approx enough shouldnt it? (not at pc to verify file sizes of the firmwares)
Click to expand...
Click to collapse
You see, tools operate on logical partition level (i think flash_image is a userspace tool that uses mtd partitions, same as mtd-utils).
And kernel doesn't provide a raw device for NAND (i'd love to be wrong though).
I'll try tomorrow to supply kernel an MTD table via mtdparts parameter and check ow it goes.
TheManii said:
flash_image should be the built in way of writing to mtd and raw emmc partitions, though we rarely ever discuss flash_image
also: at least on filesystems you should use dd and not cat for the fact that cat drops the final byte or something to that degree.
i dont recall if it applies to yaffs2 but it should for ext, it shouldnt matter for raw mtd partitions
Click to expand...
Click to collapse
mtd devices are character devices, dd works only on block devices.
I thought apply_patch is the first choice for writing into mtd from the commandline.
there should be a kernel option near mtd in menuconfig where you can setup the mtd-layout manually on the kernel commandline. Thats where I would tinker, when I wouldn't trust atag.
Yes, " Command line partition table parsing" enabled in kernel.
Also, MTD seems to have enabled char read/write access, that makes MTD-Utils a bit obsolete
OK, i'll report if i'll find something interesting.
$ dumpatags /proc/atags
read 412 bytes from /proc/atags in buffer of size 10000
0000 - 0002:54410001 ATAG CORE flags=00000004 pagesize=54420005 rootdev=21000000
0008 - 0004:54420005 ATAG INITRD2 start=21000000 size=0002b4d3
0024 - 0004:54410002 ATAG MEM size=0e800000 start=20000000
0040 - 0004:54410002 ATAG MEM size=0fe00000 start=30000000
0056 - 0058:4d534d70unknown tag
0288 - 0022:54410009 ATAG CMDLINE androidboot.hardware=streak console=ttyMSM2,115200n8 androidboot.baseband=msm
0376 - 0004:afd137cbunknown tag
0392 - 0003:54410007 ATAG REVISION revision=00000016
AMSS MTD partition:
Offset: 0x6C0000, Size: 0x1360000
DSP MTD partition:
Offset: 0x1A80000, Size: 0x1060000
--
Service Tag resides in area starting on 0x360000
--
AppsBoot:
Offset: 0x1A20000, Size: 0x60000
dbl:
Offset: 0x200, Size: 0x1E000
DT:
Offset: 0x620000, Size: 0xA0000
--
Unsure of fsbl and osbl - seems like it's data intermixed with bad blocks on my device.
--
Block from 0x4c40000 contains somewhat altered amss and dsp (maybe something else).
StreakMod recovery.
Kind of side-effect from my test:
StreakMod with replaced kernel (Phoenix, +rotated matrix).
http://n0p.8bit.fm/streak/smd.img
Works in portrait mode (interesting, looks like out matrix was rotated in kernel for 270 in kernel)., no it's different static surface flinger.
Could you make a dump of dt? (and which version of DT you have)
DT obviously isnt straight flashed during a stock update, wonder how it's transformed on install.
I believe it's 407.
http://n0p.8bit.fm/streak/DT.zip (zipped just for integrity)
Which kernel was it that you modded for this? (I mean the exact revision), did you upload it?
I'm keen on dumping everything and attempting to do a write up on it.
I've done a device fixing guide for the S7:
[Guide][Technical]Restoring your device specific data (including Service Tag)
Context: someone uploaded an nvflash dump that also included their device specific data (imei, service tag, etc)
and dozens of people ended up with cloned devices because they blindly flashed it without understanding nvflash.
I would like to do a feasability study to see if it would be possible to restore jtagged S5's (ie ones with blanked IMEI, service tags)
I'd need multiple dumps to compare the unique data, very least we'd be able to learn a thing or three.
I'm guessing that JTAG was always able to access these sections of the nand, and that they were writing bad data to it during restore
(as the jtaggers didnt have a good copy from a working s5?)
Your DT dump is definitely different from the raw DT.img, 366 and 407's DT only differ in their dates, they're more or less byte identical.
It's likely due to DT being "installed" and not mere "extracted" (ie DT_update on stock update)
It's simply a kernel parameters, altering mtd partitions - and you can take them from smd.img I published earlier. There's three unkX partitions mapped to holes in nand layout.
Or I can build a cm7 kernel with this options.
--
Seems like contents or mtd partitions are crc checksummed. Anyway, having full amss and dsp dump should enable us to write'em right on rom flashing and that's good.
For the actual firmware files, it's not important as I'm mainly interested in analyzing the device unique data.
I dont believe the unique data has any checksums, as devices can still boot with blank IMEIs and service tags,
unless it also just so happens that they took that one instance into account.
The S7's data definitely isnt checksummed, but it's a rather different platform.
Related
So, there hasn't been any solution to unlock bootloaders of 3rd party certificates, other than multiunlock, seetool2 and semc.
I'm pretty new to this thing... but I'll give it a chance, as nobody did anything in several months.
the_laser posted his solution
His script roots the device, exploits qualcom bug to disable MPU, loads mapper.ko, then excecutes his bootloader patch, then flashes his custom loader.sin
what we lack is the bootloader patch
the_laser left this comment:
the_laser said:
ps.
all that other 3rd-pary unlock tool authors need to do -
- sniff my patched s1boot
- replace S1_SL_Root_xxxx with own
- proudly release new version with words "world first user friendly REAL TRUE TOTALLY SAFE ULTIMATE bootloader unlock blablablablabla"
Click to expand...
Click to collapse
So, insterting mapper.ko maps the next devices
Code:
< /dev/mtd/mtd5ro
< /dev/mtd/mtd5
< /dev/mtd/mtd4ro
< /dev/mtd/mtd4
< /dev/block/mtdblock5
< /dev/block/mtdblock4
Code:
adb shell cat /proc/mtd
dev: size erasesize name
mtd0: 0ce00000 00020000 "system"
mtd1: 03200000 00020000 "cache"
mtd2: 00040000 00020000 "appslog"
mtd3: 0d3c0000 00020000 "userdata"
mtd4: 80000000 00020000 "msm_nand"
mtd5: 00040000 00020000 "userdate"
I wasn't able to read "msm_nand".
I don't know what "userdate" contains, but inside is this "S1_SL_Root_xxxx" that repeats two times. Is this partition the S1boot?
respect to the "my7227bootwrite_*SL" of the laser...
Does anybody has its sources?
Androxyde flashtool plugin comes with a third my7227bootwrite_omniusSL. This one restores the bootloader lock of omnius unlocked phones... Who made this one and how did (s)he made it?
Finaly, i tried disassembling "my7227bootwrite_*SL". I wasn't able to find the patch or the nand image inside. the debug/error messeges, state that it sets some mtd partition in raw mode.
So, I'll start comparing the images after and before the_laser patches...
Questions:
Does anybody have a compiled mtd_utils for this device?
How do I enable raw mode nandread for a partition/block?
What is inside mtd5 and mtd4?
Am I near of a mini brick?
skirhir said:
What is inside mtd5 and mtd4?
Am I near of a mini brick?
Click to expand...
Click to collapse
a: Yes...
I was unable to access to de oob area...
And I was unable to find the image inside the patcher binary, so:
Unlocked with my7227bootwrite_setool2
made a "nandump -o" with busibox(I was unable to access de oob area).
edited the dump and replaced S1_SL_Root_xxxx with omnius one...
made a (flash_erase 0 0) with mtd_utils
made a nandwrite (no flags) with mtd_utils (failed to write with the busybox one).
checked that the image was correctly patched. No difference with the original dump.
Reboot...
No boot, no flashmode, no nothing...
If anyone can point the mistake in the flashing process...
Now I'm trying to resurrect my shiny brick (any Ideas to make a test point matrix connector, or the name of that connector?)
Conclussion: do not try this at home.
unlock bootloader
I know this is not the answer that this thread was meant to find, but omnius has updated its omnius for SE, and now supports bl unlock for the mini, they still will ask for a license to do this, but the good news is that right now its free for a promo that lasts till the 9th i think, anyways i unlocked my bootloader free a few minutes ago without purchasing a license and wanted to share with anyone in the same problem of sim unlocked with omnius that couldnt unlock their bl
The HTC Droid Incredible 4G LTE is officially supported by ROM Manager. ClockworkMod recovery can be downloaded from within the ROM Manager application, or from clockworkmod.com/rommanager. In addition to the official builds, I also publish CWMR Touch by gweedo767 and PhilZ Touch by Phil3759, both highly recommended.
Official ClockworkMod Builds
Download ClockworkMod 6.0.3.3 Official
MD5: cf0eac6d3c111e92ce5e4581d1059865
This is the stock ClockworkMod recovery. Navigation is done through volume-up/down and power to select.
Download ClockworkMod Touch 6.0.3.3 Official
MD5: 6f5110757380ac685f9d0191062dec8c
This is the touch driven ClockworkMod recovery. Navigation is done through a touch interface.
Advanced/Modified ClockworkMod Builds
PhilZ Touch 5 - based on CWM 6
Information about PhilZ Touch recovery, along with numerous screenshots, can be found in the master thread. This is a very feature complete recovery with many extras. Please report issues related to the device in this thread and general issues related to PhilZ Touch in the master thread. Note: if you prefer to flash recoveries through fastboot, simply extract recovery.img from the zip file.
Download CWMR Touch 6.0.3.7
MD5: 82a6ead49ce1f2831f3cbc1c22b318d9
This is a gesture enabled build of ClockworkMod recovery. Navigation is done through swiping up/down/left/right. Volume and power navigation still work as well. This is not to be confused with the official ClockworkMod Touch, which has a different interface.
Automated Installers
Automated installation will only work if you have the su binary (root access) on your ROM. If you have just performed unlock or S-OFF, you must use the manual installation method for the first recovery installation.
Official ClockworkMod builds: ROM Manager
CWMR Touch builds: CWMR Touch Installer
Manual Installation:
Requirements: you must have fastboot set up: Windows Guide, Mac Guide, Ubuntu Guide
1) Reboot your phone to the bootloader:
Method 1: Disable fast boot under Settings > Power > Fast boot. Shut down the phone. Hold Volume-Down and Power simultaneously until the phone vibrates. Continue holding volume down, but release the power button. When you reach the bootloader, choose the FASTBOOT menu option using the volume keys to move up/down and the power key to select.
Method 2: If you have adb installed, then with your phone fully booted up, type: adb reboot-bootloader
2) Flash the recovery image using fastboot. Open a terminal and navigate to the directory with the downloaded image. Type:
Code:
fastboot flash recovery recovery-clockwork-6.0.2.9-fireball.img
where the filename should be replaced with that of the version you downloaded. When the image has finished flashing (usually less than 10 seconds), issue the command
Code:
fastboot reboot-bootloader
3) Use the volume keys to navigate to BOOTLOADER and then select it with the power key. After the phone finishes scanning for PJ____.zip images, choose RECOVERY from the menu. This will start ClockworkMod recovery.
Additional Information:
The boot image comes from RUU 2.17.605.2
Credits:
utkanos for putting in the original effort to build CWM on the Inc 4G and building assistance
gweedo767 (@unstableapps on twitter) for the gesture enabled modifications to CWM
Phil3759 for PhilZ Touch
KemoNine for building assistance
Shaaan for his CWM building guide
Koush for writing ClockworkMod and officially supporting this device
CyanogenMod for way too many reasons
Release History:
Official 6.0.3.1 - Allow cancellation of adb sideload
Official 6.0.2.9 - USB mount support and some text corrections
Official 6.0.2.8 - Builds now officially supported
Beta 1.2 - Enable charging support
Alpha 1.1 - Enable both internal and external sdcards
Alpha 1.0 - Initial Release
Known issues / Workarounds / To Do
In the stock version, there is no support for the capacitive back/home/recent buttons on the phone.
The charging status LED does not turn on when the phone is charging, though charging does work.
If the phone is powered off while plugged into USB, it will temporarily reboot into recovery then shut down 20-30sec later.
Source
The device tree is at github.com/cyanogenmod/android_device_htc_fireball.
Build Guide
This guide is a historical account of how ClockworkMod was built for the fireball before a CyanogenMod device configuration existed for it. Obviously, all this work has been done for you now, and you can easily build ClockworkMod from the github source. If you're curious to know how configuration was done though, this post is for you! On the other hand, don't expect this to be your comprehensive guide to building recoveries. It's more an example to guide you. A brain and willingness to utilize said brain are still requirements. Furthermore, this guide ONLY focuses on the htc fireball. Don't expect direct translation to other devices. Finally, this thread is not a discussion zone for building recovery; please visit #koush on freenode if you need assistance.
Another more general resource that you should familiarize yourself with is XDA University: Porting ClockworkMod Recovery to a New Device. Some distinctions: the following uses cm-10.1 and mka instead of make -j4.
Prepare the build environment
ClockworkMod is distributed as part of the CyanogenMod source. Follow a guide for a device similar to fireball to set up a build environment. This HTC Evo 4G LTE guide should work well. Go all the way through Get pre-built apps, but stop before Prepare the device-specific code since we will be writing the device configuration from scratch.
Sun Java JDK 6 is necessary to build using Android sources. This Paranoid Android guide has a nice section on how to replace an existing Java installation on your computer. Do this.
Amend these directories as you see fit and set the variables:
Code:
export INC4G=~/inc4g
export CMHOME=~/android/system
$INC4G is our working directory and $CMHOME is the CyanogenMod source. If you close the terminal at any point, remember to re-set these (if you actually use them).
If you plan to upload your work to github at some point, give git some basic information:
Code:
git config --global user.name "Your Name"
git config --global user.email [email protected]
You should replace the name and e-mail with real(ish) values.
Some additional tools we will need throughout are abootimg and unpackbootimg. You can install abootimg through the package manager:
Code:
sudo apt-get install abootimg
unpackbootimg needs to be compiled from the CyanogenMod source. Go to $CMHOME and type
Code:
. build/envsetup.sh
mka otatools
Then copy unpackbootimg to a directory in your path, for example:
Code:
cp $CMHOME/out/host/linux-x86/bin/unpackbootimg ~/bin/
I put together a script that cleans up the output of unpackbootimg. Copy the below text into a file called unpack_image.sh, copy it to a directory in your path (~/bin/) and make it executable with chmod +x unpack_image.sh:
Code:
#!/bin/bash
strip() {
cp [email protected] out.img
unpackbootimg -i out.img > image_info.txt
BIT=`grep "Android magic found at:" image_info.txt | cut -d ':' -f 2 | cut -c 2-`
if [ $BIT -gt 0 ]; then
dd bs=$BIT skip=1 if=out.img of=unsigned.img
fi
}
extract() {
mkdir ramdisk
cd ramdisk
gunzip -c ../out.img-ramdisk.gz | cpio -i
cd ..
}
cleanup() {
rm out.img out.img-base out.img-cmdline out.img-pagesize
mv out.img-zImage zImage
mv out.img-ramdisk.gz ramdisk.gz
}
if [ -f [email protected] ]; then
strip [email protected]
extract
cleanup
else
echo "No image specified"
fi
Start the device configuration
CyanogenMod has a few built-in tools to help setup a bare-bones device configuration based on a stock ROM's recovery image. Download recovery_signed.img from RUU 2.17.605.2 to $INC4G. Then, navigate to $CMHOME and type:
Code:
build/tools/device/mkvendor.sh htc fireball $INC4G/recovery_signed.img
The following files have been created at $CMHOME/device/htc/fireball:
Code:
AndroidBoard.mk
AndroidProducts.mk
BoardConfig.mk
cm.mk
device_fireball.mk
kernel
recovery.fstab
system.prop
File descriptions
AndroidBoard.mk - (no changes needed) is setup to pull in pre-built and proprietary files. Since there are so few proprietary files needed by recovery, we will just drop them in a sub-directory of the device tree instead of utilizing the vendor directory called by this file.
AndroidProducts.mk - (no changes needed) calls the config file specific to your device
BoardConfig.mk - kernel specifications, device specifications, and internal memory layout are defined here
cm.mk - (no changes needed) includes device name, and pulls in some CyanogenMod resources used by ClockworkMod
device_fireball.mk - this file pieces together all of the parts into a recovery
kernel - (binary file - do not modify) this is the linux kernel extracted from recovery_signed.img
recovery.fstab - defines the file system layout on the internal memory
system.prop - parameters used by the kernel at boot time to play nicely with the device
BoardConfig.mk - Link to final BoardConfig.mk
We can benefit from the work that has already been done on similar Qualcomm MSM8960 based HTC devices to configure settings in BoardConfig.mk. These devices share a common device configuration: CyanogenMod/android_device_htc_msm8960-common. Analyze BoardConfigCommon.mk and amend the following chipset capabilities:
Code:
TARGET_ARCH := arm
TARGET_NO_BOOTLOADER := true
TARGET_BOARD_PLATFORM := [B]msm8960[/B]
[B]TARGET_BOARD_PLATFORM_GPU := qcom-adreno200[/B]
TARGET_CPU_ABI := armeabi-v7a
TARGET_CPU_ABI2 := armeabi
TARGET_ARCH_VARIANT := armv7-a-neon
[B]TARGET_ARCH_VARIANT_CPU := cortex-a9[/B]
ARCH_ARM_HAVE_TLS_REGISTER := true
[B]TARGET_CPU_SMP := true[/B]
[B]TARGET_USE_KRAIT_BIONIC_OPTIMIZATION := true[/B]
Next, we can fill in the partition values under # fix this up by examining /proc/mtd on a running device. Connect your phone to the computer and type:
Code:
adb shell "cat /proc/emmc"
The output will look like:
Code:
dev: size erasesize name
mmcblk0p23: 000ffa00 00000200 "misc"
mmcblk0p22: 00fffe00 00000200 "recovery"
mmcblk0p21: 01000000 00000200 "boot"
mmcblk0p33: 47fffc00 00000200 "system"
mmcblk0p30: 00140200 00000200 "local"
mmcblk0p34: 13fffe00 00000200 "cache"
mmcblk0p35: 49fffe00 00000200 "userdata"
mmcblk0p26: 01400000 00000200 "devlog"
mmcblk0p28: 00040000 00000200 "pdata"
mmcblk0p36: 109c00000 00000200 "fat"
mmcblk0p31: 00010000 00000200 "extra"
mmcblk0p17: 02d00000 00000200 "radio"
mmcblk0p18: 00a00000 00000200 "adsp"
mmcblk0p16: 00100000 00000200 "dsps"
mmcblk0p19: 00500000 00000200 "wcnss"
mmcblk0p20: 007ffa00 00000200 "radio_config"
mmcblk0p24: 00400000 00000200 "modem_st1"
mmcblk0p25: 00400000 00000200 "modem_st2"
Convert the hex sizes to decimal for needed partitions:
Code:
boot: (hex) 01000000 --> (decimal) 16777216
recovery: (hex) 00fffe00 --> (decimal) 16776704
system: (hex) 47fffc00 --> (decimal) 1207958528
userdata: (hex) 49fffe00 --> (decimal) 1241513472
Then, fill in the values:
Code:
[B]TARGET_USERIMAGES_USE_EXT4 := true[/B]
BOARD_BOOTIMAGE_PARTITION_SIZE := [B]16777216[/B]
BOARD_RECOVERYIMAGE_PARTITION_SIZE := [B]16776704[/B]
BOARD_SYSTEMIMAGE_PARTITION_SIZE := [B]1207958528[/B]
BOARD_USERDATAIMAGE_PARTITION_SIZE := [B]1241513472[/B]
BOARD_FLASH_BLOCK_SIZE := 131072
TARGET_USERIMAGES_USE_EXT4 was added because the data partition is formatted as ext4. Discovery of partition types is discussed when we get to the recovery.fstab section.
We only have a recent apps button, not a select button, so the following is correct:
Code:
BOARD_HAS_NO_SELECT_BUTTON := true
These options allow the device to be mounted to a computer as a USB disk drive while in recovery:
Code:
[B]BOARD_VOLD_MAX_PARTITIONS := 36[/B]
[B]TARGET_USE_CUSTOM_LUN_FILE_PATH := /sys/devices/platform/msm_hsusb/gadget/lun%d/file[/B]
The LUN file path is general to msm-based ICS and Jellybean devices. The max partitions value comes from analyzing the output of
Code:
adb shell "ls /dev/block/mmcblk*"
The board name and kernel location are obviously correct:
Code:
TARGET_PREBUILT_KERNEL := device/htc/fireball/kernel
TARGET_BOOTLOADER_BOARD_NAME := fireball
We can verify the kernel options using unpackbootimg and abootimg. Navigate to $INC4G and execute the following command:
Code:
unpack_image.sh recovery.img
The script will unpack the recovery image, resulting in the following files:
image_info.txt - kernel information used in BoardConfig.mk
ramdisk.gz - compressed archive of the ramdisk
unsigned.img - the same recovery image with the 256bit signature stripped so it can be read by simpler programs like abootimg
zImage - the kernel
ramdisk/ - the unpacked ramdisk
The contents of image_info.txt can be compared to the following items in BoardConfig.mk:
Code:
BOARD_KERNEL_CMDLINE := console=ttyHSL0,115200,n8 [B]androidboot.hardware=qcom[/B]
BOARD_KERNEL_BASE := 0x80400000
BOARD_KERNEL_PAGESIZE := 2048
[B]BOARD_MKBOOTIMG_ARGS := --ramdisk_offset 0x01400000[/B]
A couple differences (in bold) are obvious. androidboot.hardware=qcom lets us identify the hardware through ${ro.hardware} in init scripts. The ramdisk_offset line is calculated from the difference (as in subtraction) between the hex addresses for the ramdisk and kernel. To find the ramdisk address, run
Code:
abootimg -i unsigned.img
and take note of the load address for ramdisk (ignore the kernel address which is different than KERNEL_BASE above). Then, subtract the two:
Code:
<ramdisk address> - <kernel base> = <ramdisk offset>
0x81800000 - 0x80400000 = 0x01400000
Often times, other devices define a custom init script using TARGET_RECOVERY_INITRC. By not specifying one, we will inherit the default init script which we can supplement rather than replace.
device_fireball.mk - Link to final device_fireball.mk
It's advisable to include charging support while in recovery. This amounts to copying a few charging specific binaries and calling them as services at startup. device_fireball.mk is the best place to put file copy commands. Find the lines for the kernel copy and piggy-back PRODUCT_COPY_FILES:
Code:
PRODUCT_COPY_FILES += \
$(LOCAL_KERNEL):kernel [B]\
$(LOCAL_PATH)/recovery/init.recovery.qcom.rc:root/init.recovery.qcom.rc \
$(LOCAL_PATH)/recovery/choice_fn:recovery/root/sbin/choice_fn \
$(LOCAL_PATH)/recovery/power_test:recovery/root/sbin/power_test \
$(LOCAL_PATH)/recovery/offmode_charging:recovery/root/sbin/offmode_charging \
$(LOCAL_PATH)/recovery/detect_key:recovery/root/sbin/detect_key[/B]
Of course, we need to supply these files. Notice I have specified a new recovery sub-directory which should be created under $CMHOME/device/htc/fireball. The needed binary files are in the ramdisk directory from our earlier unpacking of the recovery image. Navigate to $INC4G/ramdisk/sbin and copy choice_fn, power_test, offmode_charging, and detect_key to $CMHOME/device/htc/fireball/recovery.
init.recovery.qcom.rc is inherited by the default init script (notice the first line). Open $INC4G/ramdisk/init.rc and copy the service definitions related to the above charging binaries to a text file. Save it as $CMHOME/device/htc/fireball/recovery/init.recovery.qcom.rc:
Code:
service choice_fn /sbin/choice_fn
oneshot
service power_test /sbin/power_test
disabled
oneshot
service offmode_charging /sbin/offmode_charging
oneshot
service detect_key /sbin/detect_key
disabled
oneshot
Notice that disabled has been removed from the offmode_charging service. This ensures the service actually gets called at startup without relying on other processes to enable it.
system.prop - Link to final system.prop
We can directly copy/paste the contents of system.prop. You should still have the extracted files from recovery.img (see just above). Open $INC4G/ramdisk/default.prop and copy everything between
Code:
#
# system.prop for surf
#
[COLOR="Red"](Copy all of this)[/COLOR]
#
# ADDITIONAL_BUILD_PROPERTIES
#
This is your system.prop.
recovery.fstab - Link to final recovery.fstab
recovery.fstab is constructed by examining two sources. First, fix-up the device paths (column 3) by examining the output of
Code:
adb shell "cat /proc/emmc"
Then, fix-up the file-system types by examining the stock recovery.fstab in $INC4G/ramdisk/system/etc/recovery.fstab. Go ahead and add the missing /devlog line as well. The storage paths from stock recovery are not consistent with those used by ClockworkMod; rename
Code:
/sdcard --> /external_sd
/internal_sdcard --> /sdcard
Finally, we should leave 16kb of unformatted space at the end of the /data partition to allow for encryption in supported ROMs. This amounts to appending the following code to the end of the data partition line:
Code:
length=-16384
In the end you should have
Code:
# mount point fstype device [device2]
/boot emmc /dev/block/mmcblk0p21
/cache ext4 /dev/block/mmcblk0p34
/data ext4 /dev/block/mmcblk0p35 length=-16384
/misc emmc /dev/block/mmcblk0p23
/recovery emmc /dev/block/mmcblk0p22
/external_sd vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
/system ext4 /dev/block/mmcblk0p33
/devlog ext4 /dev/block/mmcblk0p26
/sdcard vfat /dev/block/mmcblk0p36
Compare your work
This is enough to compile a functional recovery. Compare your device tree with this recovery-only tree and tell me I did everything wrong!
It's time to build! Navigate to $CMHOME and type:
Code:
. build/envsetup.sh
croot
lunch cm_fireball-eng
. build/tools/device/makerecoveries.sh cm_fireball-eng
Ignore the warnings about using a pre-built kernel. This is standard practice for recoveries. After compilation, reboot your phone to the bootloader and flash the recovery.img:
Code:
adb reboot-bootloader
fastboot flash recovery $CMHOME/out/target/product/fireball/recovery.img
fastboot reboot-bootloader
To clean-up:
Code:
mka clobber
After clobber, you will need to run lunch before compiling again.
Awesome job man!
Glad someone is working on this, I've been in touch with some guys that are really good with the CWM recoveries and getting the soft buttons to work seems to be a huge issue, would love to have that. Koush has it working in his touch CWM versions, perhaps he could be of assistance.
Thanks
Sent from my ADR6410LVW using Tapatalk 2
Bump for beta build! Love classic cmw
This is greatly appreciated. While TWRP is working just fine for me, I like Classic CWM - probably because I used it on my OG Dinc. I'm good with the volume/power keys to navigate.
Would you please add an MD5 to the OP for the downloaded file? I'd like to make sure it came down completely before flashing it.
Does a "back" button not exist for our phone?
Thanks for building this, I am most familiar with CWM.
Sent with my Dinc4G
DavDoc said:
Does a "back" button not exist for our phone?
Click to expand...
Click to collapse
The capacitive back/home/recent buttons do not currently work, this is a known issue. I uploaded a gesture enabled build today that gets around this problem.
Testing the gesture enabled version (cwmr-touch-6.0.2.7-fireball-beta1.2) now. So far so good.
Flashed the recovery without any issues
I started with the "classic" vol-up/vol-down/power - all working fine as per the classic method
I then tried the gesture method - very nice :good:
(Re)booted into recovery from menu without any problem
Made Nandroid backup without any problems
Appears to work well with ROM Manager Premium - it recognized the backup I just made
ROM Manager auto-scheduled Nandroid backup feature worked flawlessly! (auto scheduled reboot into recovery, auto backup, auto reboot to system)
Restored my first backup from within recovery (not ROM Manager) without any problem
I will play more with it later, but so far it is working great.:good:
Outstanding work, mdmower!
Thanks for this! I will be nice to have auto-scheduled Nandroids again
junkmail9 said:
Testing the gesture enabled version now. So far so good.
Flashed the recovery without any issues
I started with the "classic" vol-up/vol-down/power - all working fine as per the classic method
I then tried the gesture method - very nice :good:
(Re)booted into recovery from menu without any problem
Made Nandroid backup without any problems
Appears to work well with ROM Manager Premium - it recognized the backup I just made
ROM Manager auto-scheduled Nandroid backup feature worked flawlessly! (auto scheduled reboot into recovery, auto backup, auto reboot to system)
Restored my first backup from within recovery (not ROM Manager) without any problem
I will play more with it later, but so far it is working great.:good:
Outstanding work, mdmower!
Thanks for this! I will be nice to have auto-scheduled Nandroids again
Click to expand...
Click to collapse
I appreciate the extensive testing. I'll tone down the warning in the OP.
mdmower said:
I appreciate the extensive testing. I'll tone down the in the OP.
Click to expand...
Click to collapse
My pleasure
mdmower said:
There are two versions available, differentiated by their filenames
cwmr-touch: (Recommended) This is a gesture enabled build of ClockworkMod recovery. Navigation is done through swiping up/down/left/right. Volume and power navigation still work as well. This is not to be confused with ClockworkMod Touch by Koush which is closed source.
Click to expand...
Click to collapse
Maybe call yours cwmr-swipe. The swipe navigation is really nice.
junkmail9 said:
Maybe call yours cwmr-swipe. The swipe navigation is really nice.
Click to expand...
Click to collapse
That was the name I was originally going to use, but the source modifications to clockworkmod were not done by me, so I want to respect the developer's choice of name. He's been using it for a while, check out the marketplace app: CWMR Touch Installer. I don't want to put the cart before the horse, but I'm hoping to get this recovery included in the installer.
mdmower said:
That was the name I was originally going to use, but the source modifications to clockworkmod were not done by me, so I want to respect the developer's choice of name. He's been using it for a while, check out the marketplace app: CWMR Touch Installer. I don't want to put the cart before the horse, but I'm hoping to get this recovery included in the installer.
Click to expand...
Click to collapse
Its included in the installer now. Had to update the app for support so it might take an hour or so for the update to hit all the Play servers.
mdmower said:
That was the name I was originally going to use, but the source modifications to clockworkmod were not done by me, so I want to respect the developer's choice of name. He's been using it for a while, check out the marketplace app: CWMR Touch Installer. I don't want to put the cart before the horse, but I'm hoping to get this recovery included in the installer.
Click to expand...
Click to collapse
Fair enough. Regardless of what its called, it works very well
Looks like you got your wish, too:
gweedo767 said:
Its included in the installer now. Had to update the app for support so it might take an hour or so for the update to hit all the Play servers.
Click to expand...
Click to collapse
Congrats
mdmower said:
I appreciate the extensive testing. I'll tone down the warning in the OP.
Click to expand...
Click to collapse
I missed this earlier, but the backup time appears to be wrong. If possible, can this be fixed? Not a big deal though, but slightly annoying.
One nice thing about the TWRP recovery is that it uses the external SD card for backups. However, the CWM uses the internal SD for backups. Is it possible to automatically swap the internal/external SD cards and use the external for backups by default?
junkmail9 said:
I missed this earlier, but the backup time appears to be wrong. If possible, can this be fixed? Not a big deal though, but slightly annoying.
Click to expand...
Click to collapse
The time stamps do seem to be janky. In my tests:
issue backup from rom manager: filename with local timestamp but rom manager 'manage backups' reports UTC time
issue backup from cwm (started from bootloader): filename with UTC and rom manager reports UTC
This seems a little inconsistent since the rom manager initiated backup uses local time.
I'm passing word along to the CWM folks to see if this is a bug on their end (don't expect a miracle though, I don't exactly have much "reputation").
junkmail9 said:
One nice thing about the TWRP recovery is that it uses the external SD card for backups. However, the CWM uses the internal SD for backups. Is it possible to automatically swap the internal/external SD cards and use the external for backups by default?
Click to expand...
Click to collapse
ROM Manager: Settings > Use External Storage
Recovery: Backup and Restore > backup to external sdcard
These don't seem any more difficult than backing up to internal. Am I missing something?
mdmower said:
The time stamps do seem to be janky. In my tests:
issue backup from rom manager: filename with local timestamp but rom manager 'manage backups' reports UTC time
issue backup from cwm (started from bootloader): filename with UTC and rom manager reports UTC
This seems a little inconsistent since the rom manager initiated backup uses local time.
I'm passing word along to the CWM folks to see if this is a bug on their end (don't expect a miracle though, I don't exactly have much "reputation").
ROM Manager: Settings > Use External Storage
Recovery: Backup and Restore > backup to external sdcard
These don't seem any more difficult than backing up to internal. Am I missing something?
Click to expand...
Click to collapse
I'm not terribly concerned about the timestamp, as it should be consistent within itself and the latest will be obvious even if several are done during the same day.
I missed the backup to external option. The "original" CWM recovery I was remembering from my OG Dinc automatically used the external SD because it was the only option (i.e. no internal SD card). It would be nice to use the external SD Card by default if possible and back up to internal if desired.
Still very happy with this recovery so far!
Finally got around to trying this and the gestures very cool bro working well, much appreciated!
Sent from my ADR6410LVW using xda app-developers app
Any chance of this making its way to goo.im? It'll make flashing this a breeze
Linch89 said:
Any chance of this making its way to goo.im? It'll make flashing this a breeze
Click to expand...
Click to collapse
I don't really have experience with goo manager, so you can test and be my guinea pig:
GooManager: devs/mdmower/htc-fireball/recovery
They're uploaded in img format, not sure if the manager requires zip flashable recoveries. Perhaps you can let me know?
IMG installation isn't supported in CWM. Will try flashable zips later.
Hi there, long time reader, first time contributor.
[Edit: Sorry I just read this should go in Q&A and I do apologise. Can a moderator please move if appropriate?]
I'm hoping some of you on this forum can help me with a Rockchip 3066 TV Box I am working with. The situation is thus:
I have a number of these boxes, 12 in my possession currently with more on the way
I have successfully rooted the boxes through ADB, none of the one click or other methods worked, but rooting through ADB did.
I have tried using rkdump but unfortunately it cannot find the update.img which I assume to mean it doesn't have one.
What I would like to do is setup a box exactly how I want and then image this off and copy the image to the others
As I mentioned, even though it's a Rockhip based chipset, there's no way I can identify to extract any kind of update.img from it. I have seen through other postings that some of the 3066 based boards no longer use the same cramfs file header/structure the previous 2xxx chipset used so this is probably why.
The big thing is, I just want to mirror the setup to other hardware of exactly the same pedigree.
Here is the MTD/partition map:
Code:
1|[email protected]:/dev # cat /proc/mtd
dev: size erasesize name
mtd0: 00400000 00004000 "misc"
mtd1: 00800000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 01000000 00004000 "recovery"
mtd4: 18000000 00004000 "backup"
mtd5: 08000000 00004000 "cache"
mtd6: 40000000 00004000 "userdata"
mtd7: 00400000 00004000 "kpanic"
mtd8: 20000000 00004000 "system"
mtd9: 6ac00000 00004000 "user"
My thoughts are I could just dd off the partition to the sd card, and dd this back onto the other devices. I could write a shell script easy enough that could do all this, but obviously trial and error could be an expensive process if I start bricking boxes.
So a couple of questions:
Would the DD thing work?
If so which MTD partition(s) should I dd off
any ideas on what the precise format of the copy to and from commands should be assuming this is the way to go about it?
Is this the wrong way to go about it? Are there better suggestions / ways of achieving this i.e. mirroring devices?
There's a number of applications that ship on the box by default too I need to remove as root, and I'd like to automate everything, hence the idea of imaging as opposed to stepping through all the tasks manually.
Use rkdump to dump kernel, boot and recovery (use /dev/block/mtdblock# as an argument), dd'ing system partition should work, but i wouldn't suggest it because it can be modified during creating dump, and this may corrupts image , so its better to copy all files from system using adb and then create ext4 image using make_ext4fs.
After you done use RKAndroidTool to flash dumped images to your device
lolet said:
Use rkdump to dump kernel, boot and recovery (use /dev/block/mtdblock# as an argument), dd'ing system partition should work, but i wouldn't suggest it because it can be modified during creating dump, and this may corrupts image , so its better to copy all files from system using adb and then create ext4 image using make_ext4fs.
After you done use RKAndroidTool to flash dumped images to your device
Click to expand...
Click to collapse
Thanks very much for your reply, unfortunately rkdump cannot find the boot and recovery.img in any of the mtdblocks, only kernel.img. I had read this is because of the FS Rk3066 uses for some images.
Hence the DD route.... but as you said, there is a possibility of corruption.
DoctorDbx said:
Thanks very much for your reply, unfortunately rkdump cannot find the boot and recovery.img in any of the mtdblocks, only kernel.img. I had read this is because of the FS Rk3066 uses for some images.
Hence the DD route.... but as you said, there is a possibility of corruption.
Click to expand...
Click to collapse
You can dd boot & recovery image safely, then strip 0xFF in hex editor from end if you need lower size of images. Try my tool I attached.Type:
"dump.bat info", to get partition structure you will need later to flash the images, then
"dump.bat recovery o",
"dump.bat kernel",
"dump.bat boot o",
"dump.bat system"
Good luck.
Hi,
I'm sorry if these details get too long, but I want to explain the stage and the problem currently I have.
I'm having a Broadcom 21552g device (Alcatel OT-983), which is hard bricked. The OTU of the device say that it already has the greatest version as I had made upgrade once before. I don't want to go to service or repair center because of my credentials.
As for the record, currently the phone is hard-bricked, because I've erased the modem partition only (which is the first partition starts 0x0 and have length 1000000) with fastboot. There is no fastboot any more. The phone shows only black screen and nothing happens on it. The phone was recognized as Alcatel One Touch Device COM5 after OTU install, but I found these 2 good articles:
http://forum.xda-developers.com/showthread.php?t=2322414 and http://forum.gsmhosting.com/vbb/f606/celkon-a19-factory-tool-flash-file-my-birthday-gift-1600605/
I took the Broadcom drivers, so currently the phone is visible in device manager as Broadcom USB to Serial (COM5). I have Broadcom Multiple Flash Tool (FLASHLOADER) version 2.0.7.0, and I've read everything that I managed to find online (Flashtool.chm, BRCM_FlashLoader_ReadMe_V1.5.pdf, FlashLoader.log/s …) I got some understanding of this tool. I have full CWM recovery (made from Rom manager), and additional another live phone, just in case I need some file/partition that I didn't have in backup.
I will post some information that I've got for my phone:
mtd partitions are:
dev: size erasesize name
mtd0: 01000000 00020000 "modem"
mtd1: 00100000 00020000 "sysparm_ind"
mtd2: 00a00000 00020000 "comms"
mtd3: 000c0000 00020000 "dsp_pram"
mtd4: 00300000 00020000 "dsp_dram"
mtd5: 00100000 00020000 "bootloader"
mtd6: 00080000 00020000 "systemdata"
mtd7: 00040000 00020000 "deviceinfo"
mtd8: 00040000 00020000 "ckdatablock"
mtd9: 00100000 00020000 "bootloader2"
mtd10: 00080000 00020000 "FOTAFLAG"
mtd11: 00500000 00020000 "boot"
mtd12: 00500000 00020000 "recovery"
mtd13: 00040000 00020000 "misc"
mtd14: 00080000 00020000 "boot2icon"
mtd15: 07600000 00020000 "system"
mtd16: 03c00000 00020000 "cache"
mtd17: 00100000 00020000 "kpanic"
mtd18: 08300000 00020000 "custpack"
mtd19: 0a000000 00020000 "userdata"
I have this scatter file, generated to get the start addresses:
modem 0x0
{
}
comms 0x1000000
{
}
…
…
As there is no Firmware for my phone, I need to take some structure from some other phone and alter is for mine. I'm using the A51_R10_MMX_DS_NSL_0422 as structure rom (found here: http://micromaxa51development.blogspot.com/), but I also found another firmware, which only compared with A51 one for getting the diff. between them and get the picture what should change to work for mine.
Here I would like to say that I took A51 firmware, replaced all the files in AP directory and the file sysparm_ind.img in the COMMs … folder. Then recreated the bin file that is flashed into the phone by setting, and flashed. The results are absolutely same as my following more specific settings.
I did the following with clean firmware from A51:
1. Put only modem.img (taken with dd if=/dev/mtd/mtd0 of=/sdcard/modem.img) inside AP directory. There is no other file there
2. I copy sysparm_ind.img (taken with dd if=/dev/mtd/mtd1 of=/sdcard/sysparm_ind.img).
3. Alter the xml file: pctools\android_flash_acar_gingerbread.xml to look like this:
<?xml version='1.0' encoding='iso-8859-1' ?>
<usbDownloader>
<!-- creating partition table command -->
<command name="create">
<partInfo>
<name>modem</name>
<length>0x1000000</length>
<attribute>w</attribute>
<address>0x0</address>
</partInfo>
</command>
<command name="flash">
<partInfo>
<name>modem</name>
<file>.\\AP\\modem.img</file>
</partInfo>
</command>
</usbDownloader>
The idea is to flash only the modem.img file inside start address 0x0 and length 0x1000000, also the attribute flag should be w for write (found from one of the manuals what options are available). I'm even giving Read-only flag on that file as original archive have this flag also.
4. Alter the files: pctools\cp_image_all.txt and pctools\cp_image_ind.txt to look like this:
#image file name and path Address (in hex format)
#========================================================== ==========================
#nand preboot image
.\AP\modem.img 0x0000
These files are used when the flash image is generated.
5. After generating the image file, and setting the port setting I'm done. I plug the phone into the USB and with these settings, it is recognized, and Dloading 0% is shown, but after this I got error messages. Will show 3 different settings with 3 different errors (same errors if I use all the .img files in AP folder)
I case: Config file visible in Screenshot1.png, give Ready, then Dloading 0% and then Screenshot1error.png. I'm also attaching log in FlashLoader Screenshot1.log
II case: Config file visible in Screenshot2.png, give Ready, then Dloading 0% and then Screenshot2error.png. I'm also attaching log in FlashLoader Screenshot2.log
II case: Config file visible in Screenshot3.png, give Ready, then Dloading 0% stars increasing up to Dloading 118% (Screenshot3error1.png)and then Screenshot3error2.png, and nothing happens. I can only unplug the phone then Screenshot3error3.png happens. I'm also attaching log in FlashLoader Screenshot3.log
(All these files are in the attached zip file)
I found how should look like FlashLoader.log: http://pastebin.com/MnsRkRMi
According to BRCM_FlashLoader_ReadMe_V1.5.pdf manual, ERROR messages:
#define ERROR_LOAD_PRELOADER_FAILED 0x1000
#define ERROR_LOAD_SCRAMLOADER_FAILED ERROR_LOAD_PRELOADER_FAILED + 0x100
#define ERROR_LOAD_DOWNLOADER_FAILED ERROR_LOAD_PRELOADER_FAILED + 0x200
I go to conclusion that I have problem with PRELOADER.
Thanks to superusr there are similar problems in russian forum:
quick google for "broadcom" "port1" "f0001" and it comes up with a couple of pages in Russian. I didn't found anything that can help.
Thanks to gokur20, We've been in contact (sorry that coudn't reply in time because of urgent problem).
My further investigations lead to nothing useful. I found Alcatel OT-991 which seem to have the first partition called preloader, and in this model is possible to get accurate preloader.img. There is no such partition in my phone, and I can't find what exactly have to setup/download/touch in order to skip these errors and to flash my missing modem partition.
I hope if someone of you have this knowledge to share it with me! Any ideas are also welcome. Thank you!
Thanks also for reading this. Hope it wasn't boring.
Kind and Best Regards
did you repair your phone? I have same problem with voafone smart II a.k.a. alcatel v860 deleted bootloader. I dont have the file sysparm_ind.img for my phone. It would be nice if you can send me your sysparm_ind.imgfile because they have the same structure. thnx
Hi
these are my random online notes. Being sometimes dis-organised, I need to focus on some things which in hindsight may be trivia but better to put them out there so others can add knowledge if they are free to do so.
Please note this is not a post to specifically answer questions but general research and observations of what I think I know. And I may be wrong
I may also ramble on about some of my intentions
#######################
Stock tablet ROM but rooted.
Kernel size reported on unpack follows/// md5 second bit
3673028 kernel // 947125799e8124bddcb9737a347e98ec kernel
TWRP kernel details are
3676160 kernel // e421c8e09888728b6a43aa7a63288074 kernel
########################
I think I will use the boot image kernel
#######################
In stock normal boot, AFAIK usb-otg works as expected.
in TWRP, so far I can't get it to work.
In comparing the init commands and some files and modules in stock I am leaning this way
stock has 2 modules that begin with the string rk as per image
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
research suggests the first one, ipp is useful for screen stuff and may resolve some upside down issues so I may inject that into any TWRP mod
The second module apparently is required for usb-otg. however this is the current config lines
on early-init
insmod /rk29xxnand_ko.ko.3.0.8+
insmod /rk29xxnand_ko.ko.2.6.32.27
write /sys/bus/platform/drivers/usb20_otg/force_usb_mode 2
write /sys/devices/virtual/display/HDMI/scale 80
Click to expand...
Click to collapse
Checking other init lines I see a trend that before we write any configs we turn off a service and re-enable, restart it at the end of the config as per these type entries
write /sys/class/android_usb/android0/enable 0
blah blah
write /sys/class/android_usb/android0/enable 1
now I consider otg as a USB style function and most usb entries have above formula but I may be wrong.
Testing it may prove something but unfortunately I believe I should make only small changes so I can trouble shoot my own brain .....giggles.....
thanks for reading.
Feel free to add any notes for mediapad
You do realize you can run Abdul's recovery for RK2918 tablets? I use that and it seems much better than the one made here for the Mediapad 7 lite specifically. I'm not sure about USB OTG working (haven't tested) and IIRC I also changed the partition sizes as well to eliminate the useless cust partition and I love it!
To change sizes you gotta edit some addresses in misc before flashing and you must make sure to edit fstab accordingly.
Oh and to get the recovery running - the device has an unified image with kernel and recovery like most standard Android devices (RK2918 usually has it separate).
Simply take the recovery image for the RK2918 (TWRP by abdul), take its ramdisk, put the stock zimage and make the final recovery.img with mkbootimage for rockchip. (This is coming all from my memory atm)
It was a while ago since I modded this tablet, so I am a bit rusty with it, but I got it again just yesterday so I will start hacking the thing again.
If in any case you want me to, I can dd the tablet and send images away (except big files due to upload speed).
@xan1242 this is great news... Hope you guys can make cm rom for this tablet
There already are ports for RK2918 done numerous times (namely by CrewRKtablets, props to them!) and I almost did make it to run on the Mediapad 7 Lite, but it got stuck at the part where after it caches the programs it just holds at "Starting applications". This has all been done, of course, with the stock kernel image.
I couldn't compile from the sources for some reason, it didn't want to boot. Also yes, Huawei released the kernel sources specifically for Mediapad 7 Lite. It doesn't matter if it's the w or u variant as they're compatible. I can confirm that since I am running a modified stock ROM of the S7-931u on my S7-931w. I'm not sure which kernel it is, but, nevertheless, it can be configured which variant you've got during compilation anyway.
As far as CM11 goes, I tried porting CWM recovery off of the main branch as well, but the display didn't work with the stock kernel.
OOH goody I should keep quiet but I have just rememebered while I had stock recovery I had downloaded firmware from here
http://consumer.huawei.com/en/support/downloads/
unfortunately when I unzip it, its not like a traditional official zip containing mulitiple images like boot and system but only one big file called update.app.
Anyhows that might explain why my kernel differs from our TWRP.
######################################
xan1242 in post 4 you mention you almost had a new ROM running.
forgive me for mentioning it, but you did flash both the boot image and the kernel area?
I know you may have changed your fstab but for a stock rom, kernel is sitting at mtd1
also known as /dev/mtd/mtd1 as per mtd outputs hidden here
OR try /dev/block/mtd/by-name/kernel
dev: size erasesize name
mtd0: 00400000 00004000 "misc"
mtd1: 00800000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 01000000 00004000 "recovery"
mtd4: 00400000 00004000 "backup"
mtd5: 00c00000 00004000 "oeminfo"
mtd6: 00800000 00004000 "vrcb"
mtd7: 01000000 00004000 "reserved"
mtd8: 20000000 00004000 "cust"
mtd9: 1cc00000 00004000 "system"
mtd10: 10000000 00004000 "cache"
mtd11: 01000000 00004000 "userdata"
mtd12: 00400000 00004000 "kpanic"
mtd13: 9a800000 00004000 "user"
Click to expand...
Click to collapse
aus9 said:
xan1242 in post 4 you mention you almost had a new ROM running.
forgive me for mentioning it, but you did flash both the boot image and the kernel area?
I know you may have changed your fstab but for a stock rom, kernel is sitting at mtd1
also known as /dev/mtd/mtd1 as per mtd outputs hidden here
OR try /dev/block/mtd/by-name/kernel
Click to expand...
Click to collapse
The listing you got there is the default partition table indeed which can be changed as per one single text file which has got a specific name I can't remember (located in the folder with the images for the Rockchip flash tool), but you'd usually flash it in the "misc" partition, hence it being the partition 0.
Here is the thing with the kernel - as I said, with this device the images are unified just like on normal Android devices (only on Mediapads as far as Rockchips go) which means - the kernel is inside "boot" and "recovery" partitions respectively.
The "kernel" partition you see there seems to be nothing more than either a fallback or a leftover for the flash tool so it could still work. I believe it still may be necessary for the device to start up, but it may just be a dummy to which you can put anything. (zImage only goes here)
So when you boot normally it boots the "boot" partition, so if you need to change the kernel, change it like you would for any other device. IIRC the regular mkbootimg works fine!
When you go to recovery (hold vol up + vol down), it'll boot the "recovery" partition and its own kernel and everything so the recovery is treated entirely as its own part.
So yeah, I changed the boot partition by separating the zImage from the stock boot dump, modifying the ramdisk as necessary and then remaking the boot image with mkbootimg with some special addresses (I think, don't take my word for the address part, I don't remember exactly as of yet, will have to do things again since I deleted most of the stuff)
let me take the opportunity to mention I have edit top post to encourage anyone to add more notes on mediapad.
your information is very valuable, but I do have some issues so have not tested what you have said on the kernel or remodding my own partition table.
I would agree tho, that its not very efficient to rely on a kernel from boot image and some other flash storage.
As a side note, I have been attempted to flash various re-modded TWRPS, and at this stage with no luck, so the kernel is a bit of fixation for me at the moment.
That and keeping aussie beach babes from smothering me.....giggles
I have still not converted my boot image to insecure mode, and yes I know how to
instead I am using an apk to give me insecure mode called .......adbd insecure by Chainfire
in order to overwrite, I use a simple read-write script I made executable sitting on removeable sdcard = /sdcard2 with contents
#!/system/bin/sh
mount -o remount,rw /system
mount | busybox grep system
Click to expand...
Click to collapse
make it executable with a rooted device by commands
Code:
su
busybox chmod +x /sdcard2/rw.sh
result of actioning script is showing in image
Notice that we are looking for rw against /system and anything else is bad.
the balance of the output of mount for system has been cut from image as its irrelevant to discussion
hope that helps someone
mtd1 the kernel......
just took an image of it using formula
dd if=/dev/mtd/mtd1 of=/sdcard2/kernel.img
2) tried to unpack it using Linux executable imgrepackerrk.......gives me error unknown format detected
3) so tried Linux command strings against it with the following result for any interested?
Code:
strings kernel.img
RKOEM10
RKOEM10
[email protected]:~/Downloads$file kernel.img
kernel.img: data
[email protected]:~/Downloads$ ls -al
total 8280
drwxr-xr-x 2 gordon gordon 4096 Jan 31 13:29 .
drwxr-xr-x 21 gordon gordon 4096 Jan 31 13:12 ..
-rwxrwxr-x 1 gordon gordon 74456 Feb 17 2014 imgrepackerrk
-rw-rw-r-- 1 gordon gordon 131 Jan 31 13:29 imgrepackerrk.ini
-rw-r--r-- 1 gordon gordon 8388608 Jan 31 2015 kernel.img
It does nothing for me......but hey I am just the messenger
You should dd using the ones in "by-name" since it's kind of broken or just use TWRP.
Besides, it seems it's just the addresses there for the kernel, the rest is padding.
Code:
http://puu.sh/fhpXv/45b3326285.7z
Check this file out and tell me if it differs from yours. If it does in any case, then there are the addresses for the kernels in the other two partitions. If not, then it's something else I don't know about. I don't think I've ever touched this file even.
By the way, the ROM I'm using is this one:
Code:
http://4pda.ru/forum/index.php?showtopic=395683&st=840#entry23349533
It's based off of the stock one and it's basically just a cleaned up ROM. Only thing is you'd need to survive through is the Russian. To fix that you just need to get MoreLocale and change the languages.
There you can find some info about flashing 'n' other stuff.
I just looked into the images from the ROM as well - misc is just random padding again, kernel is the same thing I got and the partition table is defined in a single file called parameter. You can edit that file with any text editor.
There you will find the CMDLINE where the partition table is defined as well under mtdparts.
parameter
Code:
FIRMWARE_VER:0.2.3
MACHINE_MODEL:MediaPad 7 Lite
MACHINE_ID:007
MANUFACTURER:HUAWEI
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 2929
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
COMBINATION_KEY: 0,6,A,1,0
CMDLINE: quiet console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x800000 mtdparts=rk29xxnand:[email protected](misc),[email protected](kernel),[email protected](boot),[email protected](recovery),[email protected](backup),[email protected](oeminfo),[email protected](vrcb),[email protected](reserved),[email protected](cust),[email protected](system),[email protected](cache),[email protected](userdata),[email protected](kpanic),[email protected](user)
Format is
Code:
[email protected]
xan1242
You should dd using the ones in "by-name" since it's kind of broken or just use TWRP
Click to expand...
Click to collapse
I wish I knew this early as I had made a number of flashing with modified TWRPS, all not booting and always thought it was just me not being good enough to know what I am doing with a Rockchip.
So I plan to redo one of my better efforts just to see if it boots later.
2) I downloaded and inspected your file here
Code:
md5sum kernel.img
c497d0e079117e8a08c3e3894237811d kernel.img
[email protected]:~/Downloads$ ls -al
total 8208
drwxr-xr-x 2 gordon gordon 4096 Feb 1 06:53 .
drwxr-xr-x 21 gordon gordon 4096 Feb 1 06:45 ..
-rw-rw-r-- 1 gordon gordon 5529 Feb 1 06:53 kernel.7z
-rw-rw-r-- 1 gordon gordon 8388608 Jan 31 23:10 kernel.img
strings kernel.img gives me
RKOEM10
RKOEM10
That size looks to me to be padded already. As the size/ erase size from stock mtd output is
mtd1: 00800000 00004000 "kernel"
Click to expand...
Click to collapse
the 8 number I believe means 8 megs or 8 x 1024 x 1024 = 8388608 bytes and so we agree
the rest is padding.
Click to expand...
Click to collapse
but it does not help me know if we have same kernel or not sorry. Can you at least tell me what kernel version the Russian ROM is please?
I use Linux tool imgrepackerrk from here
http://forum.xda-developers.com/showthread.php?t=2257331
ignore my next bit.....its just a whine by me.....after I pull my fist out of the monitor
I have found 3 main methods.....ignoring adb....to flash recovery from within normal bootup
dd if=newimagename of=/dev/mtd/md3
dd if=newimagename of=/dev/block/mtd/by-name/recovery
dd if=newimagename of=/dev/block/mtdblock3
I have also apppended those lines with bs=512 count=32768, giving a total of 6 commands
all of them show output of records in matching records out
but I am not getting recovery on boot up for any of them, consistenly so sorry if that looks bad.
2) it may be that I have been long pressing to turn off on failure and other pressing buttons.......that my device is spanking me for treating it without respect
b) but then if what I just said is true, this device is unreliable. I mean no great disrespect here either as it only costs A$50 in australia
end of grumble
ok so had modest success on a TWRP mod and flash using mtd3 method
the working bits are in images hidden, the really bad bits I am too shy to show but mount is not getting access to my fstab entries such as for system which in showing as 0 MB to backup
Yes.....thats not good.
Also I added some more flags to show more options in the mount area of TWRP but inserting usb-otg after boot or on reboot.....does not allow me to CHECK the box and mount it.
In first image, removeable sdcard means the microsd card you push into slot and the bottom entry is for OTG, I might amend the flags later but only when I resolve the fstab to mount issue.
working fstab entry is
/sdcard2 vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0 flags=display="removeable sdcard";wipeingui;storage;removable;backup=0
OTG failure line is currently
/usb-otg vfat /dev/block/sda1 flags=display="USB Storage";storage;wipeingui;removable
and yes I must make that auto instead of vfat
system faulure line is attempt to use block style and yes I must try by name
/system ext4 /dev/block/mtdblock9 flags=display=system;wipeingui;backup=1
Drat I should I think remove wipingui for sdcards
#######################
heck I think I just found a gremlin?
in normal boot up the command
Code:
cat /proc/mtd
gives me the mtd list including this line
mtd9: 1cc00000 00004000 "system"
looks good but we know that our current TWRP has this entry for its fstab line
/system ext4 /dev/block/mtdblock10
WT?
well I know and am fairly sure pogs24ever has done a TWRP backup and restore so mtd10 must be for system and not mt9
only way to confirm is for me to try a new image with corrected fstab
well well well
lets go and have a peek at the current TWRP backup log created when doing a backup. I backed up only boot, data and system
Q If anyone thinks I should back up more, please say so.
############
now let me focus on mtd.....which I know scant about.....in normal boot up......recovery is mtd3
in twrp log its not the same!!
and others also have changed. so frustrated I am with this blinkin mtd system I thought I would share a link to my log and maybe some kind soul can tell me where to go.....LOL
https://www.dropbox.com/s/xa6uy8f4akauffo/twrp-current-recovery.txt?dl=0
if not thanks for reading.
Just to repeat ......this is the current TWRP not my mod as my mod contains more errors than current.
Hi Guys...
You can check my conversation with abdul on his page... here's the first page........ http://www.freaktab.com/showthread.php?10466-Unofficial-TWRP-2-7-0-0-for-Rockchip-s/page4
pog2rever
I can see your recovery log from that other site.......so in case it helps others let me take a snip from yours that our friend also saw at post 95, page 5
I:Actual command is: 'cd "/" && cat proc/mtd 2>&1'
dev: size erasesize name
mtd0: 00400000 00004000 "parameter"
mtd1: 00400000 00004000 "misc"
mtd2: 00800000 00004000 "kernel"
mtd3: 01000000 00004000 "boot"
mtd4: 01000000 00004000 "recovery"
mtd5: 00400000 00004000 "backup"
mtd6: 00c00000 00004000 "oeminfo"
mtd7: 00800000 00004000 "vrcb"
mtd8: 01000000 00004000 "reserved"
mtd9: 20000000 00004000 "cust"
mtd10: 1cc00000 00004000 "system"
mtd11: 10000000 00004000 "cache"
mtd12: 01000000 00004000 "userdata"
mtd13: 00400000 00004000 "kpanic"
mtd14: 18880000 00004000 "user"
Click to expand...
Click to collapse
now from our post 5.....with a normal boot up, I used cat /proc/mtd giving us
dev: size erasesize name
mtd0: 00400000 00004000 "misc"
mtd1: 00800000 00004000 "kernel"
mtd2: 01000000 00004000 "boot"
mtd3: 01000000 00004000 "recovery"
mtd4: 00400000 00004000 "backup"
mtd5: 00c00000 00004000 "oeminfo"
mtd6: 00800000 00004000 "vrcb"
mtd7: 01000000 00004000 "reserved"
mtd8: 20000000 00004000 "cust"
mtd9: 1cc00000 00004000 "system"
mtd10: 10000000 00004000 "cache"
mtd11: 01000000 00004000 "userdata"
mtd12: 00400000 00004000 "kpanic"
mtd13: 9a800000 00004000 "user"
Click to expand...
Click to collapse
I still have no idea why a twrp boot up uses different numbers from our normal boot up.
I am now forced to use a "by-name" etc/recovery.fstab, but have yet to resolve USB-OTG
################
adbul_pt discusses some of this issue at post 100,
at post 126 it is claimed TWRP does not support fuse........I can see on normal boot /dev/fuse so will have to check that out later.
thanks for reading
hi
Having read 60 odd pages at freaktab I have a new test, for USB-OTG
boot current TWRP, insert usb stick into hub and hub into OTG cable into device
check mount and try to check the box for usb storage.....fails
choose right hand side, it names a storage device and changes to a dialog box........usb storage shows as 0 Mb......result ......fails
Altho this is no better than my earlier report, until someone says they have succeeded with OTG storage..............I think I have done enough testing of this and my brain hurts (joke)
Sorry for not replying, been a bit busy. ;V
I'll upload the recovery dump now. I have some files on my computer too (ramdisk and other stuff) so if you want those too I'll send em too.
EDIT: Link
Code:
http://puu.sh/fsBNP/4789c249eb.zip
This is the recovery I use. It really wasn't too hard to make. I even think I took the one for RK3xxx. Only bad things are - no internal SD and it's upside down lol
i tried a CWM and found it upside down
repacked with this string in default.prop
ro.sf.hwrotation=180
still upside down.....have not had a chance to look at your recovery but assume its based on the generic rk2918?
cheers
aus9 said:
still upside down.....have not had a chance to look at your recovery but assume its based on the generic rk2918?
cheers
Click to expand...
Click to collapse
My pack is based on abdul's RK292x recovery since there wasn't any 2918 based with 1024x600 resolution.
On another note - I think the etna_viv driver can be ported to the Mediapad 7 Lite as the developer himself has a RK2918 based tablet. I think it's better than the regular Vivante driver. Apparently it handles things horribly and you can see it in games such as Table Top Racing or some games/3D apps not running at all such as Epic Citadel, which is quite disappointing. Besides games and apps, I think it can benefit the latest of CWM recoveries since the framebuffer didn't get updated at all when I ran it (and I'm not sure even if it ran since I need serial pins for that, I do own a RS232 interface though).
EDIT: I actually found the original image file I used. Instead of the link above (which has the extra unnecessary padding) use this one;
Code:
http://puu.sh/fta8X/824844a344.img