hellmonger asked me to repost this as a new thread. I'm not entirely sure he wasn't pulling my chain.. but whatever... here it is.
There's development going on for kernel's that can't be flashed anyway. So every time you boot your phone you need your PC handy for fastboot... fun experiment, but no thanks.
Support for ext2/3/4, and any of the other modular changes the kernel mods do can probably be made (and possibly even made useful) without changing the actual kernel image (flashed or otherwise).
I now see it's not like nobody here thought of this (and I didn't mean to presume otherwise), example here:
http://forum.xda-developers.com/showthread.php?t=929871
The point that I did add was:
From my samsung experience, one click lag fix mounted /data without modifying the kernel by replacing the splash screen binary, which came up before data was mounted needed (other things used this trick too). It's not near as elegant but it may be possible to place kernel modules in /system/extramodules or whatever load them at some time like that, and then get support from then on.
The file on samsung was called playlogos or playlogos1 depending on the device. It did more than just play a logo I think.. and actually it had to be moved, replaced with a script.. and the script then should run the moved copy in the end. I don't see this file on the Motorola, but maybe there is something similar. If being clever, you make the script copy another script in from the sd card, chmod it and run it. Then if you make changes to the real script that cause boot loops, you can just modify it on the sd card, or pull it.
This would then be something that doesn't require a PC to do. Obviously anything requiring changing the actual kernel zImage won't work.
It's not beautiful, but neither is fastboot. For korean sgs it was possible to compile kernel modules for ext4 that would run on the stock kernel. (you should read through that thread I linked though.. some good point made there about that).
If you want to use another filesystem for your primary (as opposed to linked) /data there are some important details that I'm no longer remembering perfectly. The typical boot loop check for /data happened after this splash screen so that was ok, but it was I think still necessary to have the kernel not fail to mount /data before that (Probably the partition will get reformatted if it can't be mounted). If so, one possibility may be to repartition to make a tiny fake data partition and then remount the real one, just and idea. The reason things worked for OCLF was that OCLF left /data partition unmodified, but mounted an ext2 image file sitting on /data, arguably not an appealing thing to do, but it had its uses on Samsung devices depending who you asked.
Mioze7ae since pointed out in passing though that partition tables are burned into the kernel, so this repartition trick may still be a no-go. Anyway I don't know exactly what goals people have for using various filesystems on XT720 devices, and filesystems are not the only modular changes being made to some of these kernels that maybe don't need to be in-kernel, in a flashing sense.
I probably don't intend to be a primary developer on anything this involved... no time, just ideas, testing, etc at most.
about mtd partitions
Actually they are passed as parameters to the kernel...
Code:
/$ cat /proc/cmdline
console=ttyS2,115200n8 console=ttyMTD10 rw [email protected] init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:[email protected](pds),[email protected](cid),[email protected](logo),384k(misc),3584k(boot)ro,[email protected](recovery),8960k(cdrom),[email protected](system),[email protected](cache),177280k(userdata),1536k(cust),[email protected](kpanic)
and then they are visible
Code:
/$ cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"
for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )
about modules, i use following not included in the stock:
jbd, ext*, overclock, tun, (and some cpu governors)
Also when i was on eclair, i used jit, dalvik-cache was on /cache partition, was able to move all the apps on sdcard (slow), was able to "link" selected (usually big and not often used ones) files to the sdcard.
All kernel modules loaded without kernel.
But some kernel features like swap or thumbee are not kernel-module... they in kernel itself...
So..
peshovec said:
Actually they are passed as parameters to the kernel...
Code:
/$ cat /proc/cmdline
console=ttyS2,115200n8 console=ttyMTD10 rw [email protected] init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:[email protected](pds),[email protected](cid),[email protected](logo),384k(misc),3584k(boot)ro,[email protected](recovery),8960k(cdrom),[email protected](system),[email protected](cache),177280k(userdata),1536k(cust),[email protected](kpanic)
and then they are visible
Code:
/$ cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"
for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )
Click to expand...
Click to collapse
I don't think we have any way to change boot parameters because they are signed. In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed. I decided that Motorola's kernels also ignore boot parameters entirely. Other than fastboot, the first point we can hijack anything is when the boot process first executes something from /system which limits our ability to repartition...
Sent from my XT720 using XDA Premium App
agree...
with my limited experience with embedded devices i suppose folowing:
the bootloader loads the so called initrd.img and kernel.img.
Then in very early boot process the mtd partition are created (if needed.
After that the control is passed to the kernel...
In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed
Click to expand...
Click to collapse
may be that was not bad i mean if you give different layout of the mtd flash, then your filesystem data will be very likely mismatched (e.g. not useful readable).
But let me clarify: You have tried to modify the mtd parameters? and nothing happens?
If these things are like samsung, if the filesystem is not readable,they get reformatted early on bootup (at least /data and probably /cache). So early repartitioning /cache and /data wouldn't cause big problems if you managed out how to do it. But doing it with fastboot doesn't interest me much anyway. Of course that reformatting is also big part of the problem. If you manage to repartition later in the bootup (which should be possible right?) things will get reformatted on next bootup before you can get control again.
One bad idea is to hijack recovery mode (which maybe doesn't do that?) and use it as a normal boot mode. Pressing some key combo is better than needing a PC, however, if you ever forgot to press the combo, you get reformatted.. ouch. There does seem to be no nice way out if you're interested in changing the /data or /cache partitioning or fs. For everything else, work on user-friendly late module loading schemes seems much more useful than fastboot. Ok not everything.. fjfaclon makes a good point clearly, but fastboot is not solution as far as I care (of course if others find it useful, I have not complaint).
I get that Mioze7ae probably wants to reallocate memory for /cache and /data, but is there a compelling reason to reformat /data on this device to ext or something? On samsung, rfs (their proprietary fs) was a bit slow (I'm not as critical of it as many, I think it was just set up very safe.. in the end ext4 is not that much faster if setup just as safe... but that's a flame war for another forum) .
Oh one more point... Even if boot paramters aren't doing the partitioning is it entirely clear that it's in the kernel image? Maybe it's hidden somewhere else. With samsung's flash tool there was a pit file separate from the kernel image and not usually required for flashes. That was responsible for defining the partitioning, but it was never clear to me that anyone ever really understood how.
Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.
Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.
sh sounds like a really good hijack, might be early enough to mess with /data and /cache. mount might also work. Clearly if filesystems are checked/reformatted before /system is mounted, then there's no hope.
I thought recovery called stuff from /system, but that's probably my ignorance. Anyway, probably no need to beat this bad idea (the recovery idea) any more dead regardless.
Mioze7Ae said:
Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.
Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.
Click to expand...
Click to collapse
Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?
Vistaus said:
Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?
Click to expand...
Click to collapse
I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?
Mioze7Ae said:
I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?
Click to expand...
Click to collapse
WanHu Deodex already no?
see this
http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html
Related
There are small differences between the OTA-2.1 and the Leak-V3. Tiny might be a better adjective.
This involves two files which are present (post install) in the OTA-2.1 which are not present in the Leak-V3 PB00IMG.ZIP file, and two files which are in the Leak-V3 PB00IMG.ZIP ROM file not present in OTA-2.1.
After a short background, I give my results. (For those with a high tolerance for boredom a complete description of the methodology I used follows that.)
Background
Back in mid-May, thenestor compared a significant fraction of the files in the OTA-2.1 http: download to the files unpacked from the Leak-V3 PB00IMG.ZIP.
Two days ago I extended that check to include all files, including those which undergo binary patching on the phone during the OTA-2.1 install. (This patching is performed by the HTC recovery boot as part of the OTA-2.1 install).
Summary of Results
The essential result is the strengthening of the conclusion that OTA-2.1 and Leak-V3 are identical. By file count, there are 4 differences among 813 files - a 99.5% match. There are no instances where there are two versions of the same file between the two installs.
The "system" partition of OTA-2.1 is essentially identical to Leak-V3, with the exception of 2 files which are present in OTA-2.1, and missing in Leak-V3.
The boot and recovery partitions are 100% identical.
The Leak-V3 install wipes clean the pre-existing /data mount point, and installs only two files into /data; these two files are not found post-install in the OTA-2.1.
Detailed Results
system partition ( /system mount point )
100% of files in the Leak-V3 /system partition identically match files in the post-install OTA-2.1 /system.
There are 2 files present in the /system folder of the OTA-2.1 which are not present in the Leak-V3 release:
/system/app/UpgradeSetup.apk
/system/xbin/modem_link
Based on name alone (rather than trying to decipher classs.dex within UpgradeSetup.apk by de-odexing) it seems reasonable that the OTA-2.1 upgrade only needs "partial" setup because it is an overlay rather than a wipe. Perhaps that is why this "app" is not present in Leak-V3.
The latter file - /system/xbin/modem_link ? I don't know what it does; it has some rather curious string data in it.
data partition ( /data mount point )
The OTA-2.1 process contains no files which are loaded into the /data partition, and only deletes unneeded cache and application parameter settings within the pre-existing /data partition; this is done under control of the update-script.
The leak-V3 ROM, which is a "wipe" or "factory reset" type of operation, drops only two files into the /data partition:
/data/app/PingTool.apk
/data/local/dmdata/00004
Neither of these files are found in a (clean MR2 to) OTA-2.1 phone's /data partition following completion of the OTA-2.1 upgrade. I do not know what role these files play - the classes.dex files and some of the .xml files in the .apk suggest an IP-layer network diagnostic capability (ping, traceroute), as well as IP route manipulation.
boot, recovery partitions
As mentioned previously - bit-by-bit identical between Leak-V3 and OTA-2.1
Conclusion
Are OTA-2.1 and Leak-V3 identical? Technically, NO. But as far as all the system executables, libraries, and pre-installed applications are concerned, YES. There are four small differences - which appear to be in areas where phone owners typically do not venture.
Methodology (Read at peril of boredom)
1) Write scriptware (*nix) to compare two complete filesystem trees, looking for match/mismatch in MD5 hashes, as well as reporting missing files. For completeness, the script works bijectively - it first examines all files found in TreeA relative to TreeB, and then reverses this (all files in TreeB relative to TreeA). This catches all missing files (which are in A, but not B; or alternatively are in B but not A). This script does not (presently) examine file modes, ownership, or timestamps, nor does it look at symlinks or directories; so differences of that nature are unexamined here.
2) Unpack partitions from the Leak-V3 PB00IMG.ZIP file using appropriate tools into separate directory (subtrees).
3) Perform a 1.5 full factory rollback on the phone, including bootloader and radio, followed by an OTA-2.1 update. Install 1.49 S-OFF bootloader (only, via battery pull trick), and then soft-load Amon_RA v1.6.2 via a fastboot "boot" operation ("fastboot boot recovery-RA-eris-v1.6.2.img")
4) Via adb (to the Amon_RA recovery soft-boot), perform:
- mkyaffs2image on system and data partitions (output goes to SD card)
- dump_image on recovery and boot partitions (again, output goes to SD card)
5) Pull all images to the PC and
- unpack the system and data images via "unyaffs"
- **unpack the boot and recovery images with split_bootimg.pl and then
- **unpack the ramdisk (gunzip -c bootimg-ramdisk.gz | cpio -i)
** For Leak-V3 vs. OTA-2.1, this step is superfluous, as both ship the contents of these partitions as monolithic ".img" files, which have the same MD5 has in both. (I did this step to set up comparisons against Leak-V2 and Leak-V1, which I am not reporting on here)
6) Run the analysis script to compare trees
bftb0
WOW
very informative
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
nindoja said:
bftb0, thanks once again for such awesome information. I'd be interested in seeing the script you wrote, although I'd understand if you didn't share it.
Click to expand...
Click to collapse
Sent you a link to a pastebin in PM. It's cruftware, not lebenswerk. Don't take it too seriously.
Very intersting. I'm really trying to get into all this coding and dev. stuff. Thanks for the post. Always nice to learn new things.
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
hallstevenson said:
I'm sorry, but I don't understand ANY of that. Are they really the same or are they different ? I have the v3 leak installed and I really want to install the "official" firmware. Should I ?
Click to expand...
Click to collapse
You need to install the "Official Leak-V8". It's identical to Leak-V3, but there is a picture of a bunch of carrots on the package it comes in. Waaaay better than V3.
Wow great post thanks!
-------------------------------------
Sent via the XDA Tapatalk App
Seriously though, excellent information. Myself and a number of others have been repeating endlessly that the last leak and the OTA were really the same but some just refused to believe it. Even after 'thenestor' did the MD5 comparison and "proved" it, it didn't seem to matter to some ("what's MD5 ?"). Now there's a 2nd backup to help prove it. Hopefully it works !
Thanks for the info. Basically the operation and functionality of the two versions are the same, just a couple of files in one that aren't in the other, but the end user won't notice a bit of difference.
-------------------------------------
Sent from my HTC Droid Eris using Swype
I'll simply say my phone's current state and hopefully someone will have some suggestions that'll actually work. And before anyone says it, YES I'v Googled every error message I've received from the phone.
The phone: T-Mobile HTC Dream/G1
SDCard: 8GB Class 4. (Partitioned 732MB ext3/ 7.2 FAT32)
Recovery Installed: Clockwork 2.0.0.3(?)
ROM: CM 5.0.8.DS
Problem:
1/ ROM is busted. Can't get into settings, force closes. Can't setup data connection(3G) due to FC on settings menu. Can make/receive calls/texts.
2/ Clockwork is busted. Can't boot into it any more. Was able to before I installed 5.0.8.
3/ Fastboot commands are ignored when in Fastboot mode. ADB commands work fine when booted up.
Here is the current logcat: http://cyanogenmod.pastebin.com/mFD6QGHX
So seriously, I am begging for some help here.
Fastboot in yourself a fresh/working recovery image, boot recovery, and mess around with wipes and flashing until you get something working.
Oh that is exactly what I would love to do. The problem is that the methods listed for doing so don't seem to work for my phone atm.
i.e "fastboot devices" command returns nothing. All I get is a blank command prompt. While I did read in a number of places that this particular command may not work for all devices (I did have it working once before...sigh) none of the other commands work either. "fastboot reboot" and such.
So you have a great theoretical method.....now, where's the steps to accomplish such a task?
BTW, the Micro SD card is freshly formatted as I was trying to do a complete fresh install but got screwed somewhere....
As lbcoder said, all you need to do here is get your recovery back up and running; from there you can reflash and fix anything. If fastboot is giving you issues, you can also do it through an adb shell. Copy your recovery.img to the root of the sdcard and do this:
Code:
adb shell
stop
flash_image recovery /sdcard/recovery.img
reboot recovery
The stop command kills the dalvik vm, so the phone will appear to crash and the screen may even go black.. dont try to use it, just type the rest of the commands. This is necessary to avoid memory errors when using the flash_image script on cm5.0.8.
The problem keeps appearing.
Code:
# flash_image recovery /sdcard/cm-recovery-1.4.img
mtd: read all-zero block at 0x00000000; skipping
error reading /sdcard/cm-recovery-1.4.img
It seems to be some sort of formatting issue but I have yet to understand which tool will fix this.
So, doing a bit of reading here gives me a little more understanding.
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 05a00000 00020000 "system"
mtd4: 01e00000 00020000 "cache"
mtd5: 059c0000 00020000 "userdata"
Still no further ahead per se, but at least it seems that there is an issue with mtd1 based on the error message I am seeing.
goldenarmZ said:
As lbcoder said, all you need to do here is get your recovery back up and running; from there you can reflash and fix anything. If fastboot is giving you issues, you can also do it through an adb shell. Copy your recovery.img to the root of the sdcard and do this:
Code:
adb shell
stop
flash_image recovery /sdcard/recovery.img
reboot recovery
The stop command kills the dalvik vm, so the phone will appear to crash and the screen may even go black.. dont try to use it, just type the rest of the commands. This is necessary to avoid memory errors when using the flash_image script on cm5.0.8.
Click to expand...
Click to collapse
JadedTech said:
The problem keeps appearing.
Code:
# flash_image recovery /sdcard/cm-recovery-1.4.img
mtd: read all-zero block at 0x00000000; skipping
error reading /sdcard/cm-recovery-1.4.img
It seems to be some sort of formatting issue but I have yet to understand which tool will fix this.
So, doing a bit of reading here gives me a little more understanding.
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 05a00000 00020000 "system"
mtd4: 01e00000 00020000 "cache"
mtd5: 059c0000 00020000 "userdata"
Still no further ahead per se, but at least it seems that there is an issue with mtd1 based on the error message I am seeing.
Click to expand...
Click to collapse
It looks more like the file you're trying to flash is corrupt.. the error is on reading the first block of the image file before trying to write it to mtd1. Have you checked the md5 on the image you're trying to flash? Try a different image.. amon-ra 1.7 is reliable.
Edit: how did you copy the recovery.img to the sdcard? Did you adb push it? Your card isn't mounted on the PC is it..?
goldenarmZ said:
It looks more like the file you're trying to flash is corrupt.. the error is on reading the first block of the image file before trying to write it to mtd1. Have you checked the md5 on the image you're trying to flash? Try a different image.. amon-ra 1.7 is reliable.
Click to expand...
Click to collapse
Tried the amon-ra on, here are the results:
Code:
[email protected]:~/Downloads$ adb push recovery-RA-dream-v1.7.0.img /sdcard
828 KB/s (4704256 bytes in 5.545s)
[email protected]:~/Downloads$ adb shell
# stop
# flash_image recovery /sdcard/recovery-RA-dream-v1.7.0.img
mtd: read all-zero block at 0x00000000; skipping
# md5sum /sdcard/recovery-RA-dream-v1.7.0.img
4b9f198aa8ada3ca1ed5537e9c25e427 /sdcard/recovery-RA-dream-v1.7.0.img
#
The md5sum matches the one listed on this page: http://forum.xda-developers.com/showpost.php?p=4647751&postcount=1
Not a corrupt issue. The error message does not point to the file being corrupt but the MTD in use.
"First off, an MTD is a "Memory Technology Device"" (source: http://www.linux-mtd.infradead.org/faq/general.html)
To me, this means that the MTD setup for recovery is the problem. But for the hell of it, I followed your suggestions to see if it made any difference. It did not....sigh.
Edit: how did you copy the recovery.img to the sdcard? Did you adb push it? Your card isn't mounted on the PC is it..?
Click to expand...
Click to collapse
I copied using Ubuntu's Nautilus. This time I used adb. No, it was not mounted either time.
So, the question is now, and really hasn't changed, how can we address an MTD error?
Further reading here and I saw this:
"I keep getting errors whenever I try to write or erase to my MTD device
Some NOR chips power on with all of the eraseblocks in a locked state. The MTD layer doesn't unlock these devices by default. If you are accessing these devices from user-space, you can use the flash_unlock tool to unlock the MTD device(s). If you are using the MTD device as a write-able root file-system you will either need to have the boot loader unlock the eraseblocks before booting the kernel, or add code to the MTD map driver for your board to unlock them."
I would suspect that loading up the recovery/ROM at some point would take care of this?
Still, any idea why fastboot is having zero affect on the device?
It seems persistence pays off....how far is yet to be determined.
I was able to get it to flash a recovery from fastboot!
Code:
sudo ./fastboot flash recovery /home/dragondon/Downloads/recovery-RA-dream-v1.7.0.img
sending 'recovery' (4594 KB)... OKAY
writing 'recovery'... OKAY
Not only did I need to use SUDO for it, I also needed ./ before fastboot command. How odd. This little tip came from a Samsung posting on this subject.
So the Amon RA 1.7 recovery flashed, I wiped, twice, each of the major parts (factory reset, dalvik, sd-xt...) and, God help me, I decided to try CM 5.0.8.DS again. CM installed with no issues....Gapps installed. Ok, now for the reboot.....
Well, took a bi fo the G1 logo to disappear.....so far so good.
It's nice to see the boo animation fly along at a good speed, something is going right.
oh BOOO! Can't get into settings without a FC...so I can't add in my APN to connect to 3G data....
Well....time to try Bugless Beast.....very tired of CM not working....I'll be back with an update shortly....
So I installed 5.0.8.DS and it was nice and broken. FCs on trying to open Settings....the handy little on/off widget for radio features was blank.....ugh.
So I tried to install latest BB 0.04....failed during install about some sort of missing file. Well, that was pleasant...... :/
So I tried to install BB 0.03....missing a DIFFERENT file....this just keeps getting better. Ok, check Peter's site...oh wait....he doesn't list a site, only RapidShare so I can't chck any MD5 sums because he doesn't list any. Sigh.
Ok dammit, let me try CM5.0.7.DS. Hey this works. I have a functioning G1 again.
Almost..... (yeah....you know this was coming eh?).
Apps2SD was greyed out. Despite my manual partitioning of the SD Card.
Ok, fine....let's use Amon's recovery to do the partitioning for me. Maybe they'll talk nice then? Nope. Still greyed out.
Ok, Let's go back to the source....Cyanogen's Wiki page. I followed the GParted instructions to the letter. Still greyed out Apps2SD.
For some reason, standard instructions are no working on this phone.
Here's the lastest logcat for those who might be able to understand such things. I'm still trying to learn.... http://cyanogenmod.pastebin.com/9X9FZrNN
There are some lines that I am curious about and wonder should I be concerned about?
486 W/ResourceType( 132): Resources don't contain package for resource number 0x7f050000
Alllllmost there with this thing.....
Ok so I decided to put this up together because it took me two days of forum searching to gather the different bits and to understand what was happening.
Update: see the complete wiki here : http://forum.xda-developers.com/wiki/index.php?title=Nexus_One/Recovery_Images
This applies to some latest N1 stock models as such:
MODEL: Nexus One (SLCD version)
HBOOT: 0.35.0017
RADIO: 32.41.00.32U_5.08.00.04
BUILD: FRF91
WHAT YOU WILL GET :
- Root without unlocking your bootloader
- Successfully Install Recovery
- Successfully Install CM6
WARNING: This method worked for me, It should work for you in the same conditions. If you intend to install a moded rom over your stock N1 , you are supposed to know what you 're doing. I can't be held responsable if you brick (not likely) your phone, break-up with your lover or witness a nuclear explosion.
----- Since I'm a new subscriber, ALL links in the guide don't work , just paste them in your browser -------
A- Root your phoneGet latest Universal Androot from (blog.23corner.com/tag/universalandroot/) install the app and follow the instructions.
This has the benefit of rooting your device without unlocking your bootloader and thus NOT voiding your warranty.
B- Install Recovery.Since you got an S-LCD device you can't use the default Clockwork Recovery (for example if you install Rom Manager). If you do you'll end up with a black screen when rebooting into recovery and will not be able to go on to proceed to flashing the Rom.
You need to get Amon_RA Recovery v1.8.0.1 (I think v1.8.0.0 also works)
you can get it here : (alternate-coding.com/recovery-RA-nexus-v1.8.0.1-aw.img)
Since you didn't unlock the bootloader I believe you can't use the fastboot commands to flash the recovery, so it's a bit tricky but you have to install it with another method :
First you need to have Adb installed in your computer.
follow this guide: (forum.xda-developers.com/showthread.php?t=690362)
First save the file flash_image (get it here benocharm.lensworks.org/flash_image) to the root of you SD card
1) also put the recovery-RA-nexus-v1.8.0.1-aw.img to the root of your SD:
- next unmount the SD put keep your phone connected to the USB
2) Open a terminal prompt (if you do Windows type "CMD") and navigate to your adb "Tools" folder, type "adb shell" and hit Enter (don't write the quotes "" from now on)
3) On the terminal write "su" and hit enter
- Caution: At this point your phone should ask you permission to use the SuperUser app (if it does not you have to allow it specifically)
- Now on your terminal window the "$" symbol should change to a "#"
4) Still on the terminal, write "mount -o rw,remount /dev/block/mtdblock4 /system" and hit Enter
5) on the terminal, write "cat /sdcard/flash_image > /system/bin/flash_image" and hit Enter
6) on the terminal, write "chmod 775 /system/bin/flash_image" and hit Enter
7) on the terminal, write "flash_image recovery /sdcard/recovery-RA-nexus-v1.8.0.1-aw.img" and hit Enter
8) on the terminal, write "rm /system/etc/install-recovery.sh" and hit Enter
9) on the terminal, write "rm /system/recovery-from-boot.p" and hit Enter
10) Next: type exit + Enter till you get out of Terminal
You'll find that maybe steps 8 and 9 give you an error because the files don't exist, so don't worry anyways.
Now you should be set,
next, reboot the phone holding the Power button on + volume down and go into
recovery to see if anything went OK.
C- install CM6
Get yourself the latest Cyanogen ROM.
Since your phone has got HBOOT 0.35.0017, if you try to flash CM6 from recovery, it will give you an error and fail.
This is because the update script of CM6 checks for HBOOT 0.33.0012 and fails.
Some people have got a way around this by reverting phone to HBOOT 0.33, (just do a search in this forum if you need this) but personally I prefer a less "destructive" and simplier method.
What you need to do is to get winrar, or another zip/compress tool and unzip the rom.
Navigate to folder "META-INF\com\google\android\updater-script" and open "updater-script" with your favorite text editor.
What you need to do is to comment 3 lines of it:
Almost in the beginning of the script look for this part :
Code:
assert(getprop("ro.product.device") == "passion" || getprop("ro.build.product") == "passion" || getprop("ro.product.board") == "passion");
assert(getprop("ro.bootloader") == "0.33.2012" ||
getprop("ro.bootloader") == "0.33.0012");
ui_print(" ");
ui_print(" ");
ui_print(" ");
You need to change it so that it goes like this.
Code:
# assert(getprop("ro.product.device") == "passion" || getprop("ro.build.product") == "passion" || getprop("ro.product.board") == "passion");
# assert(getprop("ro.bootloader") == "0.33.2012" ||
# getprop("ro.bootloader") == "0.33.0012");
ui_print(" ");
ui_print(" ");
ui_print(" ");
That's it !
Now repack the rom (CAUTION: if you did unzip it don't zip the resulting folder, just zip ALL the files IN IT, otherwise it will give you an error later)
Next copy the Rom to the root of you phone SD card.
Now reboot into Recovery and flash your Rom.
Welcome to CM6 !!
I hope this will help someone.
Please keep in mind I'm by no means a specialist, and that there are maybe other (better) ways to achieve this (I didn't find them). Also my knowledge of Android is very limited so I won't probably be able to help you if you run into problems following this how-to. I repeat, I did it and worked ok for me.
I will be happy that some of you maybe correct or contribute to what I have exposed if you fell like it.
Cheers
Thank you for posting this.
Where did you get an SLCD nexus one from though?
They ship them now in Vodafone Spain
Has been fixed in the nightly builds.
github.com/CyanogenMod/android_device_htc_passion/commit/6d19e88c86f01b68a206fa27a49bf58567ff255e
I am not allowed to post links, normally just lurk here and post on the CyanogenMod forums.
I'm surprised that ROM Manager still hasn't been updated to include recovery images that support SLCD Nexus Ones.
kibje said:
Has been fixed in the nightly builds.
github.com/CyanogenMod/android_device_htc_passion/commit/6d19e88c86f01b68a206fa27a49bf58567ff255e
I am not allowed to post links, normally just lurk here and post on the CyanogenMod forums.
Click to expand...
Click to collapse
Thanks ! good to know
cmstlist said:
I'm surprised that ROM Manager still hasn't been updated to include recovery images that support SLCD Nexus Ones.
Click to expand...
Click to collapse
Yes indeed I am surprised too, but I think koush will be working on this sooner or later, tweeted asking for plans about this but no news so far.
I'd imagine it wouldn't be too big a change, seeing as versions now exist which support the SLCD Desire.
Sent from my Nexus One using XDA App
Hi!
I'm stuck with a boot partition with bad blocks which prevents me from flashing other custom ROMs than CM6. I read somewhere that the new hboot 0.35.0017 changed the partition sizes so that might help me.
Could you do a
#cat /proc/mtd so I can see if the sizes differ from mine?
ollegut said:
Hi!
I'm stuck with a boot partition with bad blocks which prevents me from flashing other custom ROMs than CM6. I read somewhere that the new hboot 0.35.0017 changed the partition sizes so that might help me.
Could you do a
#cat /proc/mtd so I can see if the sizes differ from mine?
Click to expand...
Click to collapse
Ok so that's what I get:
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 000e0000 00020000 "misc"
mtd1: 00400000 00020000 "recovery"
mtd2: 00380000 00020000 "boot"
mtd3: 09100000 00020000 "system"
mtd4: 05f00000 00020000 "cache"
mtd5: 0c440000 00020000 "userdata"
good luck !
cestbibi said:
Ok so that's what I get:
Code:
# cat /proc/mtd
dev: size erasesize name
mtd0: 000e0000 00020000 "misc"
mtd1: 00400000 00020000 "recovery"
mtd2: 00380000 00020000 "boot"
mtd3: 09100000 00020000 "system"
mtd4: 05f00000 00020000 "cache"
mtd5: 0c440000 00020000 "userdata"
good luck !
Click to expand...
Click to collapse
Great! It looks like they grew the boot partition
Guess I should try updating to a ROM with the new hboot that's rootable...
Thanks for the help!
A very concise but complete Wiki has been updated on this matter courtesy of Jack_R1
h**p://forum.xda-developers.com/wiki/index.php?title=Nexus_One/Recovery_Images
**damm I still can't embed links**
didnt work for me, korean slcd
xx_ED_xx said:
didnt work for me, korean slcd
Click to expand...
Click to collapse
What exactly didn't work ?
This is an old thread because by now every major ROM and Recovery work with SLCD N1.
Have you had a look at the wiki ? (see update and link on first page)
The Wiki has been great, though I find myself stuck at the download flash_image (benocharm.lensworks.org/flash_image) step.
I've done some Googling and found it here - cyanogen-files.carneeki.net/flash_image.zip.
I'll update the Wiki link if I can as well.
Hey Folks!
I´m with CM7 now for several weeks and i´m quite happy with it! Just for my personal interest I wanted to give WP7 a try, so I´m very interested in the possibility to make a full backup of my Android System with Clockwork Recovery (where it is possible to get a full working ROM file including all data and apps, isn´t it?)
But here´s the problem now: as soon as I want to use CW (point 9: AD Recovery), it says das there´s an "invalid boot image header" and I can´t use any of CWM´s functions. It seems like this is based on the fact that I´ve installed Rom Manager and updated my CW with it, ignoring (or more "not knowing") that this can only by used when having clk installed and NOT Magldr...
The question for now is: what possibilities do I have now to make a full backup of my system, including all data, all programs, dictionaries and settings I made? Are Titanium Backup/BackupEverthing the only two ways to get out of this chaos? Has anybody some experience with those apps? Will everything work again after a fresh ROM install?
Tried to use the magldr SD Version...it didn´t work...
I´m still hoping for help, friends
brooon said:
Hey Folks!
I´m with CM7 now for several weeks and i´m quite happy with it! Just for my personal interest I wanted to give WP7 a try, so I´m very interested in the possibility to make a full backup of my Android System with Clockwork Recovery (where it is possible to get a full working ROM file including all data and apps, isn´t it?)
But here´s the problem now: as soon as I want to use CW (point 9: AD Recovery), it says das there´s an "invalid boot image header" and I can´t use any of CWM´s functions. It seems like this is based on the fact that I´ve installed Rom Manager and updated my CW with it, ignoring (or more "not knowing") that this can only by used when having clk installed and NOT Magldr...
The question for now is: what possibilities do I have now to make a full backup of my system, including all data, all programs, dictionaries and settings I made? Are Titanium Backup/BackupEverthing the only two ways to get out of this chaos? Has anybody some experience with those apps? Will everything work again after a fresh ROM install?
Click to expand...
Click to collapse
Hi,
Rom Manager only works with cLK.
If you use it with MAGLDR ,it will screw up your CWM.
Unless you made a NAND backup before you started all of this ,you are, indeed, in deep doo-doo...
If you now go and try to re-install clk or magldr,it will wipe your rom,data etc.
Your only hope to save your data now,is something like Titanium Backup,or similar.
Once you re-install clk or magldr,flash CWM partition for your new ROM and flash ROM,everything will work again,but obviously without your data and settings.Titanium Backup will back up and restore apps and data to a degree,but not as well as a NAND backup.
Try and re-install a similar rom to the one you have now.Then restore Titanium backup,then make a NAND backup,to protect you against any future folly...
Thank you for your help!
I´ve tried to get into the SD magldr CWM version again...and finally, I won!
- Services
- Bootsettings
- AD SD Dir
- (choose folder with SD magldr CWM inside)
- --> Boot SD AD
Click to expand...
Click to collapse
I was able to make a backup of my Android...it´s flashing-time now
Tell me please, where did you get SD magldr CWM version?
This should be it: Klick
Explain please
brooon said:
Thank you for your help!
I´ve tried to get into the SD magldr CWM version again...and finally, I won!
I was able to make a backup of my Android...it´s flashing-time now
Click to expand...
Click to collapse
Could you please explain how you(won) managed to fix "invalid boot image header" I would also like to take a backup, but facing the same problem. Thanks a lot.
And I am newbe in this "game".
PS! I have installed this ROM : TyphooN CyanogenMod 7 Nightly v3.3.2
This saved me a tremendous headache TY!
Can't dd do something?
I have the recovery partition image file that came with the DAF flash tool:
# ls -l /mnt/sdcard/r*
----rwxr-x 1 system sdcard_r 4005888 Mar 26 00:38 /mnt/sdcard/recovery-raw.img
The recovery partition is mtd1:
# cat proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "misc"
mtd1: 003e0000 00020000 "recovery"
mtd2: 00500000 00020000 "boot"
mtd3: 09600000 00020000 "system"
mtd4: 00500000 00020000 "cache"
mtd5: 30000000 00020000 "userdata"
Can't the partition be fixed somehow with dd?
I tried:
# dd if=/mnt/sdcard/recovery-raw.img of=/dev/mtd/mtd1 bs=4096
978+0 records in
978+0 records out
4005888 bytes transferred in 0.982 secs (4079315 bytes/sec)
But no luck.
golagha11 said:
Could you please explain how you(won) managed to fix "invalid boot image header" I would also like to take a backup, but facing the same problem. Thanks a lot.
And I am newbe in this "game".
PS! I have installed this ROM : TyphooN CyanogenMod 7 Nightly v3.3.2
Click to expand...
Click to collapse
It worked for me:
unzipped the file to a directory - say ADRecovery
Then from MAGLDR
- Services
- Bootsettings
- AD SD Dir
- (choose folder with SD magldr CWM inside -ADRecovery)
Go back to main menu and select Boot AD SD
It came to the AD Recovery menu of MAGLDR.
john0902 said:
I have the recovery partition image file that came with the DAF flash tool:
# ls -l /mnt/sdcard/r*
----rwxr-x 1 system sdcard_r 4005888 Mar 26 00:38 /mnt/sdcard/recovery-raw.img
Click to expand...
Click to collapse
This command got me back to the originally flashed working NAND recovery partition:
flash_image recovery /sdcard/recovery-raw.img
This thread has more info on the issue, as well as downloads, etc.
The problem seems to that earlier recovery partitions were under 4MB and newer ones are around 5MB. My original partition config included this line:
recovery rrecov|ro|nospr filesize recovery-raw.img
Iow, it made the recovery partition the 'filesize' of the older recovery image size. Newer recoveries don't fit. If you want a newer recovery partition, you need to partition your NAND with a bigger recovery partition, or run the newer recoveries off SD.
follow this thread
http://forum.xda-developers.com/showthread.php?t=1090783
akshan said:
It worked for me:
unzipped the file to a directory - say ADRecovery
Then from MAGLDR
- Services
- Bootsettings
- AD SD Dir
- (choose folder with SD magldr CWM inside -ADRecovery)
Go back to main menu and select Boot AD SD
It came to the AD Recovery menu of MAGLDR.
Click to expand...
Click to collapse
Thx, simple and detailed explanation
link is not working
akshan said:
It worked for me:
unzipped the file to a directory - say ADRecovery
Then from MAGLDR
- Services
- Bootsettings
- AD SD Dir
- (choose folder with SD magldr CWM inside -ADRecovery)
Go back to main menu and select Boot AD SD
It came to the AD Recovery menu of MAGLDR.
Click to expand...
Click to collapse
Could you please share your link to sd magldr cwm once more - the link above doesn't work anymore...
thx
just managed to find a working link for sd magldr: link
This error happened to me before, and it was fixed by restoring the CWM backup and then flashing the kernel via CWM before rebooting.
akshan said:
It worked for me:
unzipped the file to a directory - say ADRecovery
Then from MAGLDR
- Services
- Bootsettings
- AD SD Dir
- (choose folder with SD magldr CWM inside -ADRecovery)
Go back to main menu and select Boot AD SD
It came to the AD Recovery menu of MAGLDR.
Click to expand...
Click to collapse
Hi! The "file" link doesnt work.. could anyone help plz?
brooon said:
This should be it: Klick
Click to expand...
Click to collapse
Link not working. Please help
Same problem here! I really dont want to loose my files. Please can someone post the right file or help me with a workaround.
Hi. I am creating this guide because i did not find any particular functional guide with details.
You must be running a 64 or 32 bit version of Ubuntu. Please note that i wont be going in the details on how to setup a build environment and sync sources as there are many guides for that.
Step 1 :
Install the required packages
Step 2 :
Setup the build environment and sync the sources for the required CWM. CWM source comes bundled with the CyanogenMod source.
Code:
CWM 5 - Gingerbread
CWM 6 - Jellybean
Step 3 :
Now we come to the actuall compiling part. Make sure you have synced the latest source using the "repo sync" command.
Change directory to your source.
Issue this command :
Code:
make -j4 otatools
Step 3.5 :
Do this step if your device is not officially supported by CM10.
Using terminal emulator on your device, issue the command
Code:
dump_image boot /sdcard/boot.img
This will dump the boot image to your sdcard. Transfer it to your home directory.
To build Android from source for a new device, you need to set up a board config and its makefiles. This is generally a long and tedious process. Luckily, if you are only building recovery, it is a lot easier. From the root of your Android source directory (assuming you've run envsetup.sh), run the following (substituting names appropriately):
Code:
build/tools/device/mkvendor.sh device_manufacturer_name device_name /your/path/to/the/boot.img
For example if you are having the Samsung Galaxy Ace device, the command will go as follows :
Code:
build/tools/device/mkvendor.sh Samsung cooper ~/boot.img
Please note that Cooper is the device name. Only use "~/boot.img" if you have the boot image in your home directory. Or else please specify the correct path.
You will receive the confirmation "Done!" if everything worked. The mkvendor.sh script will also have created the following directory in your Android source tree:
manufacturer_name/device_name
Step 3.5 ends here.
Step 4 :
Now that you have the device config ready, proceed.
Type the following code in your terminal in the source directory.
Code:
. build/envsetup.sh
This will setup the build environment for you to work.
Now launch the command
Code:
lunch full_device_name-eng
This will set the build system up to build for your new device. Open up the directory in a file explorer or IDE. You should have the following files: AndroidBoard.mk, AndroidProducts.mk, BoardConfig.mk, device_.mk, kernel, system.prop, recovery.fstab, and vendorsetup.sh.
The two files you are interested in are recovery.fstab and kernel. The kernel in that directory is the stock one that was extracted from the boot.img that was provided earlier. For the most part, recovery.fstab will work on most devices that have mtd, emmc, or otherwise named partitions. But if not, recovery.fstab will need to be tweaked to support mounts and their mount points. For example, if your /sdcard mount is /dev/block/mmcblk1p1, you would need the following lines in your BoardConfig.mk
/sdcard vfat /dev/block/mmcblk1p1
Once the recovery.fstab has been properly setup, you can proceed to the next step.
Step 5 :
Now we build the actual recovery.
Code:
make -j4 recoveryimage
This command builds the recovery image
You can use the command
Code:
make -j4 recoveryzip
to make a fakeflash recovery i.e. a temporary recovery to test out on the actual device.
Your recovery can then be found at "your_source_directory/OUT/target/product/device/recovery.img" and the temporary fakeflash zip in the utilities folder at the same location.
If everything works out well, you will have a working recovery.
Once you have working builds, notify "koush", on Github and he can build official releases and add ROM Manager support!
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Some tips :
If you want to compile CWM 6, sync the jellybean branch using the command :
Code:
repo init -u git://github.com/CyanogenMod/android.git -b jellybean
repo sync
If you want to compile CWM 6 on a 32 bit system, you need to sync THIS source too. Instructions are given in the readme.
Run "make clobber" between builds if you change the BoardConfig.mk, or the change will not get picked up.
Credits :
Koush for this guide.
Nice.
Will come in handy
Excellent guide!
Thanks!
I will try on my Motorola PRO+, wish me luck
any ideeas how i can make the recovery font smaller? i read somewhere that i have to edit ui.c file, but what syntax? thanks
thank you for this
i will try to compile this
i tried before using koush online builder but the cwm has bugs.
Okay, I'm problly stupid, but.
repo init -u git://github.com/CyanogenMod/android.git -b jellybean
seems to work fine, but
repo sync does this:
Code:
fatal: '../CyanogenMod/android_abi_cpp.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
error: Cannot fetch CyanogenMod/android_abi_cpp
What did I screw up, or not have prepared correctly?
I have built AOSP and currently build kernels on this box, so I know git and all that is setup correctly.
D
.
edited
Got it. Needed an updated repo script.
D
.
what's this ?
shaaan said:
Hey guys, i present to you a new updated version of CyanogenMod Recovery a.k.a CWM 6.0.1.3. The current version that we use is 5.0.2.6
Edit : As you guys know, i bricked my ace while trying to get CWM working. The bootloader is lost. So there is no way i can get it working back. This is the end of developing for me for now atleast. I will have to replace the motherboard or get a new device. Any dev wanting to take over the project, please feel free. Contact me for help and i will try my best. But if you use my sources, please give credits to me and TeamCooper.
My sources are here.
Edit : You can refer my guide on compiling a recovery here.
Click to expand...
Click to collapse
now afraid to do it on my own
So you copy pasted a guide (and linked it in the end), and then you say you can't find any other guide.
Orelly?
Can jou tell a bit more about run "envsetup.sh"thats what i mis in this guide and the original guide. and most other guides.
The file "dump_image" needs to be placed on the phone. Can be put on the sd of the phone and than place on a place you like.(Folder bin/xbin ore some other) Use terminal on the phone. (any from google store play) cd to the dir the dump_image is than run the command.
How do i find the device name for my phone/tablet. I know the name of the tablet i bought.. But still. samsung ace hase device name cooper? Where did you find it?
Thx by the way. This guide is a bit more clear than the original.
the device name is in build.prop
[email protected] said:
Can jou tell a bit more about run "envsetup.sh"thats what i mis in this guide and the original guide. and most other guides.
The file "dump_image" needs to be placed on the phone. Can be put on the sd of the phone and than place on a place you like.(Folder bin/xbin ore some other) Use terminal on the phone. (any from google store play) cd to the dir the dump_image is than run the command.
How do i find the device name for my phone/tablet. I know the name of the tablet i bought.. But still. samsung ace hase device name cooper? Where did you find it?
Thx by the way. This guide is a bit more clear than the original.
Click to expand...
Click to collapse
dump_image would be on the phone, it was for MTD devices now a days ytou want to use DD on mmcblk devices
i solved the font problem, you need to edit the Anndroid.mk from bootable/recovery, but now i got messed up Graphics in the recovery and i cannot boot back into the OS. ideeas? thanks
PS: i think that the graphics.c may be the problem. but for booting, i really have no clue.
This will give you a non touch version of CWM
Any idea if the touch modifications are also available opensource to modify code?
Not yet. But finding it. Once I get it working, will add it to the op.
Thx for the answar on my question.:good:
I have a nother question:silly: For example, my recovery.fstab hase: /sdcard mount is /dev/block/mmcblk1p1
What lines do i ad in my BoardConfig.mk:
? what is here? /sdcard vfat /dev/block/mmcblk1p1
just adding /sdcard vfat /dev/block/mmcblk1p0 does not seem to work..
my recovery.fstab:
# mount point fstype device [device2]
/boot mtd boot
/cache yaffs2 cache
/data yaffs2 userdata
/misc mtd misc
/recovery mtd recovery
/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0
/system yaffs2 system
/sd-ext ext4 /dev/block/mmcblk0p2
My vold.fstab hase:
# External NAND Storage
dev_mount sdcard /mnt/sdcard auto /devices/virtual/block/ndda
# External SD card
dev_mount ext_sd /mnt/ext_sd auto /devices/platform/tcc-sdhc
# External USB storage
dev_mount usb_sda /mnt/usb_sda1 all /devices/platform/dwc_otg /devices/platform/tcc-ohci /devices/platform/tcc-ehci
dev_mount usb_sdb /mnt/usb_sdb1 all /devices/platform/dwc_otg /devices/platform/tcc-ohci /devices/platform/tcc-ehci
Some other info i found..:
/dev/block/platform/tcc-sdhc0.0/mmcblk0
if i use mount in terminal i get this:
/dev/block/vold/179:0 /mnt/ext_sd vfat ...
/dev/block/vold/240:0 /mnt/sdcard vfat ...
cat /proc/mtd
geeft:
dev: size: erasersize: name:
mtd0 00a00000 00100000 ¨boot¨
mtd1 00500000 00100000 ¨kpanic¨
mtd2 12c00000 00100000 ¨system¨
mtd3 00400000 00100000 ¨plash¨
mtd4 09600000 00100000 ¨cache¨
mtd5 40000000 00100000 ¨userdata¨
mtd6 00a00000 00100000 ¨recovery¨
mtd7 00100000 00100000 ¨misc¨
mtd8 00100000 00100000 ¨tcc¨
partitions /proc/partitions:
major: minor: #blocks name:
7 0 16664 loop0
31 0 10240 mtdblock0
31 1 5120 mtdblock1
etc/ sow on
179 0 15339520 mmcblk0
240 0 2392064 ndda
240 1 2392064 ndda1
240 0 16663 dm-0
My boot.img files on github. + some adding ...(/device/YG/m805_892x) https://github.com/Frank77GLD/Telechip_tcc892x
(just testing a github for fun...)
Hope you could give me some advice?
can someone please make an english working cwm for samsung galaxy young cdma ich-509 please?
Porting to a new "unknown" device
Hi folks. I`m trying to start to develop some stuff to an chinese tablet and, of course, my first need is the cmw ...
Then. I only can have it using the fakeflash method(locked bootloader). My problem that it`s kinda new stuff to me.
I have some files built by utkanos to start the job. But now I dont know where to go to ...
Theere appears do be no documentation in what files in what folders I have to edit/add to get it fully functional.
When i flash the zip and the cwm load there`s no partition table. It loads a lot of errors on the screen saying no /dev/block* ...
I little help will be much appreciated here. Even just a start point .. anything that can help!