Database Users

Where to begin....too many issues and no solutions yet....

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.....

Non-kernel kernel hacking

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

Frankdrey's Brick Adventure

Twas the night.......nah that's not gonna work...
Anyways, I had just compiled froyo from android source and wanted to flash it
But apparantly I needed a specific spl when I did "fastboot flashall -w" (one of them being 0.95.0000 or whatever, too lazy to remember..but it was one that didn't support fastboot....which is dumb lol since fastboot is saying to use it)...
So I decided to install engineering spl
I had danger spl and the 2.something radio it needs
I decided to flash it from recovery
BRICK!
So really g1s are impossible to brick...if you flash radio and spls from fastboot not recovery
(Most of this knowledge is from a thread about g1s and spls and bricking that I'm too lazy to link to)
What happens is that recovery FORCES the g1 to boot to recovery on next boot...even if you press buttons
And with a mismatched radio/spl recovery will not start
So you have a brick...
Moral: use fastboot not recovery
Anyways so my solution...
I had a really messed up rogers dream that had a cracked screen and bad ribbon cables...
Pretty much everything was broken except for the motherboard...
Well I decided to try and put this rogers motherboard into my tmobile g1
It worked!
Even booted up into the rom I used to have (biffmod) on the rogers dream before it got screwed up beyond usability
I am posting from my g1 with a rogers motherboard in it as I speak...post....
Moral 2: you can mix motherboards between dreams
One problem is that this ROM still has the keymap for the rogers dream and my home and call button don't work
Hopefully flashing a new rom it will detect the tmobile keyboard
Well this was fun...but I don't know if I'm gonna try to flash my aosp froyo or not again...
Comment please on how you manage to flash a compiled aosp froyo...maybe ill try flashing engineering spl again through fastboot this time
Edit: oh and I like this motherboards vibrate more
Its quieter...
The old one rattled like crazy
So this actually a very win situation
I got Frayo back on and everythings beautiful

In a rom's zip there is this file:
META-INF\com\google\android\updater-script
Try to open it and read the first lines, there are the asserts generally (the part that tells to the device that particular SPL/Radio/Files are needed to proceed the install)
Here's an example of an assert:
assert(getprop("ro.product.device") == "trout" || getprop("ro.build.product") == "trout" || getprop("ro.product.board") == "trout" ||
getprop("ro.product.device") == "sapphire" || getprop("ro.build.product") == "sapphire" || getprop("ro.product.board") == "sapphire");
assert(getprop("ro.bootloader") == "1.33.0013" ||
getprop("ro.bootloader") == "1.33.2013" ||
getprop("ro.bootloader") == "1.33.3013" ||
getprop("ro.bootloader") == "1.33.0013d");
This assert checks many things, with logical operators (|| that's or; == that's equal; "" that's a string; () that's an argument; etc). If you've ever programmed, you'll understand very fast how to change the assert to make it less agressive of checking this things and anothers and not let you install.
The previous assert cheched that the device, or product, ot board where "trout" or "sapphire". Also it needs an specific bootloader ("1.33.0013", or "1.33.2013", or"1.33.3013", or "1.33.0013d").
It's an good idea tho check the updater-script that's in your zip installation file, view what installs it, add/remove asserts and unwanted things, and then, proceed to install it safely from recovery and the SPL/Radio combo that you prefer. Also, it's an good idea to flash an alternative kernel (ezterry one's are very good).
Remember that the only thing that's really recommended to install from fastboot is the SPL and the Radio. Other things are installable from wherever you want (fastboot, OS, recovery) without an potential hard brick risk.
So, if you want to install an ROM (AOSP FroYo as you described), it's not needed to install it from fastboot, and it will not represent an brick risk if it really is only a ROM installer what you have.
---------- Post added at 06:16 PM ---------- Previous post was at 06:12 PM ----------
Oh, and if you can paste here the updater-script it would be usefull, more than one buddy will say you how to change it to let you install everithing by a correct and safe way.

Yes yes I know all of that
I'm using fastboot because the compiled output is not an update.zip
Its all the image files and I am supposed to do "fastboot flashall"
Its alright though...I got cm6 source working
That will work
Sent from my HTC Dream using Tapatalk

It should be also fun to convert your images to a zip format.
When you flash those full images, you don't know if it will flash more things than needed. Zip files give you more control, and the updater-script also.
The "fastboot flashall" command is kinda risky with images that touchs radio/spl/partitions layouts/etc. It's really recommended to do a wipe of everithing from fastboot when you're installing this images, and also, of course, know what those images will install and be carefull to have the right pre-requisites to don't harm the device.
Good to know you got it working after all !

Alright maybe putting images into zips will be an adventure for later
As of now, the AOSP froyo source and built images are in the deep dark room of a PC's deleted files
Thanks for the tip about flashall!

frankdrey said:
Alright maybe putting images into zips will be an adventure for later
As of now, the AOSP froyo source and built images are in the deep dark room of a PC's deleted files
Thanks for the tip about flashall!
Click to expand...
Click to collapse
No need for flashall
instead of using
Code:
make
use
Code:
make otapackage
You will find a zip ready for flashing
if you are building cm6 then use
Code:
squisher
to optimise the zip
have a look in the opticharger script to make improvements like replacing pngcrush with something better

Scrip said:
No need for flashall
instead of using
Code:
make
use
Code:
make otapackage
You will find a zip ready for flashing
if you are building cm6 then use
Code:
squisher
to optimise the zip
have a look in the opticharger script to make improvements like replacing pngcrush with something better
Click to expand...
Click to collapse
Thanks
And here I was about to go and start extracting the images and writing an updater-script
And I went back to AOSP
CM6 has too many missing files that I don't want to go through the trouble of finding

frankdrey said:
...And here I was about to go and start extracting the images and writing an updater-script...
Click to expand...
Click to collapse
OTA packaging is easier and more simple, I agree... but something is true... fighting with those extractions and updater-script is kinda funnier
Happy source-compiling

Alright I have the zip and all
It checks for the spls though
Should I just remove that from the script?
And try with DangerSPL?
DangerSPL is a port of the mytouch spl right?
Maybe I shoulda built for mytouch?
Also, it looks like it patches recovery after install.
Is that safe? Should I remove the entire folder and entry in the update script?

You must do a little change.
First, open the updater-script, then find the bootloader assert
It will be like this:
assert(getprop("ro.bootloader") == "1.33.0013" ||
getprop("ro.bootloader") == "1.33.2013" ||
getprop("ro.bootloader") == "1.33.3013" ||
getprop("ro.bootloader") == "1.33.0013d");
Just be shure to add the SPL version that you've installed on your phone already. For example, if I've a 1.33.2222 bootloader, then the change will be this:
assert(getprop("ro.bootloader") == "1.33.0013" ||
getprop("ro.bootloader") == "1.33.2013" ||
getprop("ro.bootloader") == "1.33.3013" ||
getprop("ro.bootloader") == "1.33.2222" ||
getprop("ro.bootloader") == "1.33.0013d");
It doesn't matter if you put the new bootloader assert on the beginning or at last or in the middle, it'll be the same. Also, you can delete some asserts if you want to. Be carefull to keep right the sintax.
And the recovery thing, it's better to delete that part, zip will give less troubles whithout that part. And better to delete it from the script and the zip!
I recommend you to use the 1.33.0013d SPL, it'll give you extra RAM and is fully compatible with AOSP FroYo. Just be shure that after flashing the ROM, you flash the right kernel to let the OS boot up.
And remember, if you use Amon_RA recovery, you'll need to re-sign the zip that you modify, if you don't do it, the verification part of the flashing will fail.

Ok thanks I thought all of that too, just wanted to make sure

Oh, and I forgot it...
DON'T edit the script with notepad on windows, it leaves an "Error 6" in recovery when flashing.
In windows you can use notepad++ (google it, it's free), or if you're using other text editor just be shure that the "Enter" (new line in text) key is on right encoding, it's kinda of Unicode if I've good memory yet

mishamosher said:
Oh, and I forgot it...
DON'T edit the script with notepad on windows, it leaves an "Error 6" in recovery when flashing.
In windows you can use notepad++ (google it, it's free), or if you're using other text editor just be shure that the "Enter" (new line in text) key is on right encoding, it's kinda of Unicode if I've good memory yet
Click to expand...
Click to collapse
Yes I have edited them before

unable to install OTA2 WE

I'm not able to install the new OTA2. A factory reset didn't fix it. I read the CWM DEV thread and updated my "old" CWM to the newest version for my Tablet (ventana64_recovery.img) (WE)
Trying to install the new OTA2 update it stops and Trying to install the OTA via the CWM i got although an Error (like before):
Installing update...
assert failed: getprop("ro.product.device") == "Indigo" || getprop("ro.build.product") == "Indigo"
E:Error in /sdcard/ThinkPatTablet_A310_02_0039_0086_WE.zip
(Status 7)
Installation aborted.
I read in an other Forum that perhaps the CWM and Voodoo RootKeeper in combination could cause some Problem, but I have no idea to solve it.
Is there a way to uninstall the CWM, install the OTA and reinstall the CWM ?
Did someone managed to install the OTA2 with CWM installed
Thanks
Antiheld

i had the same problem. solved it by restoring the original Recovery.
- you have to have superuser rights
- you should have a backup of the stock recovery in /system named recovery-from-boot.p
- put the file from the zip to /system/etc and do the following via adb:
Code:
$ su
# dd if=/system/recovery-from-boot.p of=/dev/block/mmcblk0p1
- do a reboot and try to install the OTA2 update.
for me it worked like a charm. hope for you too.

That didn't work for me. Now I can't get into Recovery-Mode. Can someone post the stock recovery?

which tablet version do you have? i can only give you the 16 gb Wifi only version. didn't you check to have /system/recovery-from-boot.p file? maybe it is called different at your tablet?
edit: attached stock recovery for 16gb wifi only model.

Yeah I tried it. I copied your command. I have the 64GB 3G model. The file /system/recovery-from-boot.p is only 343918 bytes big. Is this alright?
I tried Quick Reboot App and the Volume-Toggle, which always worked for me. Couldn't get into recovery.
Could it be the install-recovery is the wrong one? (I really should make backups before doing stuff like install CWR )
EDIT: I checked the new OTA-zip. There is a new recovery-image and a new install-recovery.sh in there. I think I'll try these? Or do you think it's a bad idea?

the file in /system should be all right. When you fully copied my commands then you should know that the $ and the # are already in your window.
but if you have some new files take them and do the following (now you really can copy the commands )!
-put your 2 files to the destinated place and hit the following code into your command tool :
Code:
adb shell
su
dd if=/system/recovery-from-boot.p of=/dev/block/mmcblk0p1

Hi,
I have the same problem as Noneus. After done your step, now I cannot get in to recovery mode anymore. I tried both, copy your file even copy from now OTA.zip to the destination. Anyway to solve it?
---------- Post added at 02:12 PM ---------- Previous post was at 02:03 PM ----------
OK now I'd managed to get back to CWR following this thread again http: //santafemods.com/Forum/ThinkpadForums/CWR_Port/C-TPT%20CWR%20port%20setup .pdf. But still stuck, cannot update new OTA2.5.

[GUIDE] Compile CWM Recovery

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!