yashsingh1/xdaforums huggingface dataset:
[G1 Android Development] ftruck90:
ok so after 10 minutes or so of bootloops it booted. df shows data is now mounted and at 117504kb booted through to my welcome screen checked settings and available internal storage is registering the increase as well. not quite sure what happened, but hey it's working so i'm happy. epic thanks to firerat and lbcoder you guys never cease to amaze me.
[G1 Android Development] Firerat:
if /data failed to mount that would make sense, as the rootfs gets mounted ro, and /data mountpoint is on the rootfs

glad its working, I'm still a little puzzled why it didn't do so 'out of the box'
[G1 Android Development] ftruck90:
Ok rebooted to test, and it bootloops until you manually mount data via mount -a

Edit: just regular old mount /data is better as mount -a forces sd card mount which can be not so pretty
[G1 Android Development] Firerat:
ok, thats two roms I should flash now :)

Edit:

Ok, I think I know what the problem is

dev: size erasesize name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 05a00000 00020000 "system"
mtd4: 00500000 00020000 "cache"
mtd5: 072c0000 00020000 "Partition_005"

the last partition is getting a 'default' name

because............

of the 'wild card'

it dosn't need the k

and the name should be userdata

-k@0x8D40000(data)

should be

-@0x8D40000(userdata)

new flashes attached

should be no need to reboot the recovery, the map is the same, just has the proper name now
[G1 Android Development] Firerat:
added new bug fix patchers to

http://xdaforums.com/showthread.php?p=6927076#post6927076

I really should consolidate this soon
[G1 Android Development] ftruck90:
when patches were applied still wasn't booting required

adb mount /data

then

adb mkdir /data/dalvik-cache

then reboot then

adb /mount/data to get it to boot up

Edit: this only enabled it to get past G1 flash screen it then boot looped on post boot screen.
[G1 Android Development] Firerat:
I'm really beginning to confuse myself now

, I'm booting chromatic now, after the attached patches

appears to be working

Edit:

I'm loving the bootanimation :)
[G1 Android Development] Ace42:
Do we need to do fastboot -w?
[G1 Android Development] Firerat:
I only do it when I change the map

but that only because I had issues the first time I did it

I'll have to mess about and see if just wiping works
[G1 Android Development] Ace42:
It is working now.I had to nand, flash patcher,reboot, wipe, nandrestore, patcher,reboot

Thanks for taking the time to fix the patcher
[G1 Android Development] ftruck90:
so you got chromatic to boot fine with just flashing those patches i wonder what i'm doing wrong. should i be starting from non-patched recovery to begin with.

EDIT: restored recovery to original amon_ra 1.7.0 then went through process and it worked fine with chromatic. thank's for your time and patience firerat.
[G1 Android Development] Firerat:
yeah, was working fine

It shouldn't matter, they will repatch your existing recovery/boot

as a little tangent, I've just flashed Danger, so I'm going to see if I have the same issues as I did the cm5.0.8F's boot.img as I did with noneDanger

Which, I'm not

can't for the life of me think why...

right, I think it makes sense to create a new post for this now

but first I'll add some checks for the custom cache size, 1mb is too small,

I'll also expand on lbcoder's automation idea, mostly for devs to include in their roms update(r)-script

It will just read /proc/mtd, and patch the boot.img based on the recovery you are using

should be a simple case of executing the script at the end of the flash ;)

and it doesn't matter if you are using a customised recovery or not, it will just work

the only thing that is worrying me at the moment is the fact that CM5.0.8 Kernel works fine on 1.33.2005 but not 0.95.3000, why :confused:
[G1 Android Development] TheNewGuy:
Instructions....

1. Nand Backup

2.Flash Recovery Patcher v1

3.shut down phone boot into bootloader, enter fastboot and clear everything using PC with

fastboot erase system -w

4.power off phone,boot into recovery,flash Rom+extras

5.flash boot patcher v1

6.reboot,enjoy........

Am I right?
[G1 Android Development] Firerat:
yeap

I'm hoping to play about and see if we really need the fastboot wipe

but it did go all screwy on me the first time I tried without it, could have just been bad luck
[G1 Android Development] TheNewGuy:
Thank you, It would be nice if there was a way to do it from the recovery so you don't have to reboot so many times... or at least it would be nice to be able to do it without a computer....(I am at work..Patience is a virtue.:rolleyes:.)
[G1 Android Development] rsxtypes72:
Hey Firerat,

Just wanted to say I have a G1 with danger spl and have radio 2.22.23.02. I am running CM 5.0.8. Since you stated you had not tried to install without fastboot wipe I decided to give it a try.

Here are my results.

tmpfs 47.7m /dev

tmpfs 4.0m /sqlite_stmt_journals

/dev/block/mtdblock3 90/system

/dev/block/mtdblock5 114/data

/dev/block/mtdblock4 800.8/cache

/dev/block/mtdblock2 800.8/sd-ext

/dev/block/mtdblock2 800.8/cache

/dev/block/vold/179:1 6.5G/sdcard

I booted into recover RA1.7.0.

flashed fr mtd parthack recovery v1

did NOT wipe using fastboot

turned off phone

rebooted into recovery

flashed cm 5.0.8+apps

flashed fr mtd parthack boot

rebooted phone

I did not wipe at any time.

did I get it right? hope my input helps.

screen shot attached.
[G1 Android Development] TheNewGuy:
Does anyone know if the boot patch needs to be applied each time you flash a kernel patch, such as the Jit-flash-addon?

also if I want to try a new rom I don't need to flash the recovery again right? just the new rom and boot patcher?

by the way, it did work for me, thanks again firerat!

edit: I have tried flashing other zips such as jit add on and gapps with no adverse affects so now the directions would be

flash recovery patch,reboot

flash boot patch......this is getting pretty easy:D
[G1 Android Development] Firerat:
ok, kewl, so you don't have any strange files floating around on system?

just doing the 'auto patcher'

but I think I'll pop out and catch the end of quiz night, lol

here is the main script

#!/sbin/sh
# 2010-06-24 Firerat
# patch boot.img with custom partition table
# Credits lbcoder
# http://xdaforums.com/showthread.php?t=704560
# 2010-07-01 Firerat
# Patch boot.img with same partition table as the running recovery
# This script should be executed via update(r)-script after kernel boot.img has been
# unpackaged to /tmp/boot.img
# it will unpack the boot.img, repack with the same partition layout as the running recovery, and then flash it
#
boot=boot
mtdpart=/proc/mtd
#################################################################
# WARNING DO NOT CHANGE THE INITIAL PORTION OF THE COMMAND LINE #
# that is Unless your very different to a dream/magic ;) #
#################################################################
CLInit="mtdparts=msm_nand:256k@0x24C0000(misc),5120k@0x26C0000(recovery),2560k@0x2BC0000(boot)"
#################################################################
# get the size of system and cache ( hex )
SystemSizeHex=`awk '/system/ { print "0x"$2 }' $mtdpart`
CacheSizeHex=`awk '/cache/ { print "0x"$2 }' $mtdpart`

SystemBytes=`printf '%d' $SystemSizeHex`
SystemKBytes=`expr $SystemBytes \/ 1024`
SystemStartBytes=48496640
# everything upto system should remain the same
SystemStartHex=`printf '%X' $SystemStartBytes`

CacheSizeHex=`awk '/cache/ { print "0x"$2 }' Sample`
CacheBytes=`printf '%d' $CacheSizeHex`
CacheKBytes=`expr $CacheBytes \/ 1024`
CacheStartBytes=`expr $SystemStartBytes + $SystemBytes`
CacheStartHex=`printf '%X' $CacheStartBytes`

DataKBytes=-
# data size is 'wildcard' -@ uses remaining space
DataStartBytes=`expr $CacheStartBytes + $CacheBytes`
DataStartHex=`printf '%X' ${DataStartBytes}`

#
KCMDline=${CLInit},${SystemKBytes}k@0x${SystemStartHex}\(system\),${CacheKBytes}k@0x${CacheStartHex}\(cache\),${DataKBytes}@0x${DataStartHex}\(userdata\)
/tmp/unpackbootimg /tmp/${boot}.img /tmp/
/tmp/mkbootimg --kernel /tmp/${boot}.img-zImage --ramdisk /tmp/${boot}.img-ramdisk.gz -o /tmp/${boot}.img --cmdline "$KCMDline"
# for now let the updater-script flash
# TODO patch update-script to extract to tmp, and flash from tmp ( NB the r is not a typo ; )
#	flash_image ${boot} /tmp/${boot}.img
exit

and just a chunk of the 'zip patcher'

just a sed

UpdaterScript ()
{
sed \
-e '/write_raw_image("\/tmp\/boot.img",\ "boot"),/ i package_extract_dir("MTDPartPatcher",\ "/tmp"),' \
-e '/write_raw_image("\/tmp\/boot.img",\ "boot"),/ i set_perm(0,\ 0,\ 0700,\ "\/tmp\/patchbootimg.sh")\;' \
-e '/write_raw_image("\/tmp\/boot.img",\ "boot"),/ i run_program("\/tmp\/patchbootimg.sh")\;' \
-e '/write_raw_image("\/tmp\/boot.img",\ "boot"),/ i ui_print("Patching\ boot\ image...")\;' \
-i ${ScriptPath}${ScriptType}-script
zip $ROMZIP META-INF $TOOLS -r

return
}

NB, I haven't tested any of this yet

after this its fully auto, like lbcoder said, having mtd as kmods and reloading, so the rom can tell recovery what layout ;)
[G1 Android Development] rsxtypes72:
firerat...

no strange files :)

excellent work!
[G1 Android Development] lbcoder:
And the other "part" of the equation is fixing the radio and hboot update routines within the recovery.

Now the PROBLEM we have with radio and hboot updates is that the data to be written to the radio or hboot needs to be stored in the cache partition -- and not the CUSTOM cache partition, but the SPL's cache partition... which means it HAS to be done with the default partition table.

And this, of course, means that any attempt to update the hboot or radio WILL destroy the userdata contents AS WELL AS any system data that lies after the beginning of the spl's cache partition -- which means that an hboot or radio update WILL break the installed ROM.

I can think of THREE ways to fix this;

1) just disable the hboot and radio update options. They're dangerous anyway. Downside here is that only a 1.33.2xxx SPL can fastboot those partitions -- 0.95.x000 and 1.33.0xxx are screwed.

2) full backup prior to hboot/radio update, and full restore after (in place of formatting cache partition). This is easy, but has a large amount of redundancy.

3) backup of cache partition (as defined by the spl's partition table) prior to hboot/radio update, restore it after. This is probably the best option.

***ALL of these three options can be (mostly) implemented within bootable/recovery/firmware.c -- 2 and 3 also require modification of bootable/recovery/recovery.c to add a new recovery parameter "--restore_cache" or "--restore_backup", and possibly modification of nandroid (or whatever) to be launched like this.

Now to implement no-wipe updates when switching between multiple layouts:

(this is the fun part...)

Need to know the partition table of the INSTALLED ROM.

There are possibly TWO partition tables defined within the device.... the SPL table, and the BOOT table (via kernel command line).

IF there is a table set by kernel command line in the boot partition, use that one. If not, use SPL table.

Check the userdata partition. IF it is currently mapped differently than we NEED it to map, it has to be moved. It can be moved under the following conditions:

1) the offset of the userdata partition is to be REDUCED,

2) the total data within the userdata partition will fit within the SIZE of the new partition... even if the partition is to be SHRUNK.

The data within the userdata partition can be moved by simply shifting all the data by the difference between the two offsets. The resulting SIZE of the partition (when mapped) will automatically adjust. Alternatively, one can simply nandroid backup the userdata partition, reload the partition table, and restore.

Now the big thing that needs to be done is that IF the userdata partition CANNOT be moved (i.e. it has more data in it than will fit within the new userdata partition), the user must be given the opportunity to WIPE or ABORT (or simply abort with an error).

Obviously, some of this will have to be implemented/executed within the update-script.
[G1 Android Development] ezterry:
Actually I wonder if we map the partition if we can flash hboot directly from recovery.

The image is raw to my knowledge, I believe the spl flashes it the same way as the other partitions.

And the extra bonus of it acting like fastboot (ie no need to set a special boot mode) thus less likely to brick peoples phones because they refuse to verify the radio they have installed.

Been meaning to test this but life has been busy away from my computers.

(As for the radio.. it needs to be flashed by the radio bootloader via the spl without a good bit of hacking anyway)
[G1 Android Development] lbcoder:
That's a very good point, and something I've also considered on occasion. It is likely that HTC flashes the SPL in this manner simply to make it possible for them to hide the partition -- i.e. to protect it from idiots doing stupid things with no way to save themselves if it screws up. Other partitions can be written dangerously since you can always fall back on an NBH to bring it back to life. There are a couple of things to consider in implementing this approach:

1) How to keep the danger seekers from writing *just anything* into the SPL partition..? I.e. are there any verifiable checksums on an SPL to make sure that the image is good?

2) How to protect the process against failed READS..? (note: answer is to load the image in memory and flash from memory rather than going straight from disk).

3) Is the SPL partition even writable? (might be write protected).

4) Does the flashing process depend on any function of the SPL that can/will fail during a write?

Another point: I might actually lean towards simply disabling any option to write the SPL.

From my perspective, there isn't actually any good reason to write the SPL once we are no longer dependent on the SPL's partition table. Whether it be fastboot, super-fastboot, or simply writing an NBH in case of catastrophic failure, there is always a way out, even if both recovery and boot are hopelessly broken.

The radio, on the other hand, still requires some means of replacing -- preferably without bricking the phone (which we can't guarantee through recovery), so maybe the best option is to simply disable the recovery's ability to update firmware -- just let it be fastboot-only and depend on a 1.33.2xxx SPL.

Or... maybe we want to build in some safeguards to the recovery (since we're talking about modifying the recovery). During the update-firmware setup process, verify that what is going IN isn't known-incompatible with what is already in place -- abort if it is incompatible.
[G1 Android Development] Firerat:
quick post, then sleep

this will patch a flashable zip to use the same partitions as the running recovery

its linux only ( sorry )

AutoMTD_partitionPatcher.tar.gz

Edit: ^^ I've updated that, had a few bugs in it ( I tarred the wrong thing up , wip and not the final.. doh )

untar it,

either cd in or set in PATH

then

./PatchUpdateScript.sh <full path ><rom.zip>

eg

./PatchUpdateScript.sh ~/Downloads/update-cm-5.0.8-DS-signed.zip

( or just PatchUpdateScript.sh <full path ><rom.zip>

if you got the dir into PATH

it will copy the zip to a folder of same name as zip

untar tools

uzip update(r)-script

patch update(r)-script

zip update(r)-script + tools

sign zip

maybe someone can convert to windoze batch script
[G1 Android Development] TheNewGuy:
Now that this is really catching on,(it's in the all in 1 patch now) I was wondering if we could get a little clarification on acceptable settings for the txt document that will set the size of partitions.

You know this is coming, all the newbes will be asking...so whats the best settings???? so instead I think some one should get an idea of what will break it and post that, then just tell everyone to experiment.
[G1 Android Development] Firerat:
the only thing that is a real issue is cache, recovery complains if its 1mb, 2mb is fine

has to be a whole number, I'm only using expr in the script, so 2 is the smallest you can have

the partition can be as small as 128k, but.. yaffs2 needs 1.1mb

this is what I have for defcon CM6 FroYo TEST4

85mb system, and 2mb cache, leaving 122.8mb for data :)

Filesystem Size Used Available Use% Mounted on
tmpfs 47.7M 0 47.7M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
tmpfs 47.7M 0 47.7M 0% /mnt/asec
/dev/block/mtdblock3 85.0M 83.6M 1.4M 98% /system
/dev/block/mtdblock5 122.8M 29.0M 93.7M 24% /data
/dev/block/mtdblock4 457.4M 8.1M 424.9M 2% /cache
/dev/block/mmcblk0p2 457.4M 8.1M 424.9M 2% /sd-ext
/dev/block/mmcblk0p2 457.4M 8.1M 424.9M 2% /cache
[G1 Android Development] mdneilson:
I'm definitely going to have to try this out once I have access to my liveboot. Thanks firerat!
[G1 Android Development] TheNewGuy:
Ok.....I tried just re-running the mtdboot script with some new settings on the sd/txt.....and there are some adverse affects.... g1 screen

Also more importantly it does not appear that you can bart restore from it . so that sucks.(im sure you could... but i cant)

Oh well i just had to repeat the install with fresh factory wipe to get it to work.

edit: for some one who knows more than me Bart seemed to fail when it tried to restore the data dump. it said failed and only 4 of 5 mdm sums passed so restore aborted.
[G1 Android Development] Firerat:
I'm not sure I understand what you are reporting as a problem..

you can't just resize the partitions and expect it to work

4 of 5 means just one 1 md5sum didn't match, since the custom mtd partitions have nothing to do with your sdcard, its not related, probably just bad luck
[G1 Android Development] Sik-1:
Hey firerat how do I put this in without using virtual box??? my comp is temporaryly down, I'm running the same cm6 as u are
[G1 Android Development] Firerat:
, you just need to patch recovery, then run the boot patcher, you don't really need to patch the whole ROM, that's just for convenience

So, put both FR-MTD-PartHack-boot-v1_S.zip and FR-MTD-PartHack-recovery-v1_S.zip on your sdcard

( they are small , so you can d/l with phone, then just move from /sdcard/downloads/ to /sdcard )

make a text file on sdcard

e.g. , in terminal

su
echo "85 2" > /sdcard/mtdpartmap.txt

nb, default is 90 5 ( system 90mb , cache 5mb )

reboot to recovery

nand backup

wipe data + cache

flash FR-MTD-PartHack-recovery-v1_S.zip

reboot to recovery

nand restore, or flash CM6 + gapps

flash FR-MTD-PartHack-boot-v1_S.zip

CM6 doesn't run scripts on boot, so cache will be tiny

in order for the market to work properly

su
sh /etc/init.d/06BindCache

cache will be bound with /data/cache

but, I did repack a bootimg, with run-parts and stuff ( like in cm5 )

http://xdaforums.com/showthread.php?p=7051449#post7051449

That flashable zip will Autodetect your partitions and patch boot.img for you :)

it will mount /sd-ext, and the cache will bind to that, (

NB, it won't turn a2sd on..,
[G1 Android Development] Sik-1:
Sweeet uts rumning even smoother now thanks alot, why dont u just build a rom a re-write the whole damn thing??? Now that would b a sweet rom
[G1 Android Development] Firerat:
lol, you give me too much credit

Remember, this is lbcoder's idea, I just scripted it to make it easy to do.
[myTouch 3G, Magic Android Development] soiwa:
thanks at all:D
[myTouch 3G, Magic Android Development] omnikai:
Awesome, I'd love to start poking around with this.

Is there a way to flash an update with a camera fix on top of this?

Thanks for posting!
[myTouch 3G, Magic Android Development] dferreira:
I never figured out how to add NCommander's hacked camera drivers that work with Eclair. If anyone knows how to do it, please share so that we can add it to the script. Maybe we can turn this script into something that will allow anyone build their own AOSP ROM :)
[myTouch 3G, Magic Android Development] ododoo:
cant find package sun-java5-jdk...
[myTouch 3G, Magic Android Development] dferreira:
Try it with whatever version comes with your Ubuntu. It's been a while since I had setup the system to compile and I have updated to Ubuntu 10.04 and it's compiling fine.

Just ignore that line :)
[myTouch 3G, Magic Android Development] DopyG:
So actually everythings work except camera?

How is this in terms of speed? : D
[myTouch 3G, Magic Android Development] ododoo:
Tnx! Works like a charm! How can you add apps and such?
[myTouch 3G, Magic Android Development] ododoo:
Did not get any question about anything.. Made a .zip file, but not sure if i dare to flash it...
[myTouch 3G, Magic Android Development] Switch33:
According to that output it did not create the img files you would need to flash. Looks like your missing some binaries required in the script.
[myTouch 3G, Magic Android Development] dferreira:
The .zip you have there is later used to extract the proprietary drivers. The output is saying that you don't have "repo", which is the tool Google uses to control the source files. My guess is you skipped this:

cd ~
mkdir bin
curl http://android.git.kernel.org/repo >~/bin/repo
chmod a+x ~/bin/repo
PATH="$HOME/bin:$PATH"
[myTouch 3G, Magic Android Development] dferreira:
The speed is not an issue. All the rest works, orientation, LED's etc. Only the camera doesn't because there is no open-source drivers for it on the repositories.
[myTouch 3G, Magic Android Development] ododoo:
this is the first line that works for me... Had to remove alot.

Does not work

This is what i get..

Still get the same error when i try to compile.
[myTouch 3G, Magic Android Development] Szusz:
Awesome work mate!

Two questions though.

1. Which Radio version is required?

2. Can I install the gapps from Cyanogenmod for instance?

Cheers,

Szusz
[myTouch 3G, Magic Android Development] dferreira:
Any radio will work. And yes, you can add gapps add-on from Cyanogen if you wish.
[myTouch 3G, Magic Android Development] dferreira:
Don't forget this:

PATH="$HOME/bin:$PATH"

So that Repo can be run by the script. I'll change the script to do this automatically for us.

Edit: Just updated the script, he checks for Repo, downloads it and sets it up for you now.
[myTouch 3G, Magic Android Development] xaueious:
Thanks a lot for this!
[myTouch 3G, Magic Android Development] ododoo:
Seems to be working now! :)

Edit: Too soon.....

So close...
[myTouch 3G, Magic Android Development] Szusz:
OK, compiled it (one note though, Ubuntu 10.4 uses OpenJava JDK instead of SunJava, so it has to be removed before compiling)

Got a lot of warnings and an error

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
make: *** [out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes-full-debug.jar] Błąd 41
make: *** Oczekiwanie na niezakończone zadania....
elapsed seconds: 306
wrote generated Main_*.java files to out/host/linux-x86/obj/EXECUTABLES/vm-tests_intermediates/main_files
Your files ready for flashing are here:
boot.img ramdisk.img userdata.img

As you can see above there's no system.img file.

I belive that dferreira is using a 64bit OS and that's why the packages are like this

lib32readline5-dev lib32z-dev

so my apt line looks the one below (I'm on a 32bit OS; added a repo from Dapper Drake)

sudo apt-get install git-core gnupg sun-java5-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev valgrind libreadline5-dev gcc-multilib g++-multilib libc6-dev libncurses5-dev x11proto-core-dev libx11-dev libreadline5-dev libz-dev

I'm on a 2 core proc, so change the android.sh script to have

make -j2

Trying to compile for the second time. Didn't work.

Updated SunJava JDK to 1.5.18 and it did work. Created all img files properly. Flashed three mentioned in the first post to the phone and now waiting for about 5 minutes for the phone to boot up. Hopefully it will work.