Curtis1973
Android Expert
I'm working on my first CWM build from source.Wish me luck.
you can do this. and even if its a little glitchy,its still a step forward
-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root ClockWorkMod
- Thread starter salvy512
- Start date
-
- Tags
- lg optimus elite
you can do this. and even if its a little glitchy,its still a step forward
Good luck. I'm still trying to clone the cm repository. I started this repo sync command last night and its still running 8 hours later.I'm working on my first CWM build from source.
landonh12
Android Enthusiast
I'm working on my first CWM build from source.
Give us updates regularly, man. How long you think itll take? You got this.
bubalashkka
Member
goodluck ktb83 !!
DsyMnapTic
Android Expert
May the Force be with you!
Dark One
Android Expert
http://androidforums.com/elite-all-things-root/595144-rom-status-some-assistance-needed.html
I had Harmonia on my Optimus V and it was quite exquisite.
[ROM] Harmonia 2.09 18July12 (IHO Gingerbread)
Leslie Ann
Android Expert
Harmonia is always pretty much stock, no bloat... "What Virgin should have released". That doesn't mean it is always based on stock, many roms have issues with mods, or lack Gapps, etc... I focus on being a complete rom (everything you need, nothing you don't).
I'm planning3 versions, all of which should get you guys up and going. Since I won't be doing a lot of development on this phone, doing it this way gives you guys an easy way to carry it forward.
Harmonia - Tweaked stock, de-branded, stripped of bloat...
Stock deodexed - You can take it and do what you want including tweak and re-upload it as your own.
Aeneas - Stock with some of Harmonia's tweaks that you can build and re-upload as your own.
Looks like we're finally making some decent progress, can't wait to see this all come
together
Leslie can't wait to get my hands on one of those roms and start tweaking around, always used yours as my base for the OV.
Also I've seen it before but your signature just about always makes me laugh, not a android developer but there have been many nights with a computer behind me lighting up the room with a reformatting screen for equivalent reasons.
together
Leslie can't wait to get my hands on one of those roms and start tweaking around, always used yours as my base for the OV.
Also I've seen it before but your signature just about always makes me laugh, not a android developer but there have been many nights with a computer behind me lighting up the room with a reformatting screen for equivalent reasons.
Leslie Ann
Android Expert
Well now you will be able to mess around and share them.
As for the sig, if you mess around with Android, yeah, you will be there at some point. lol
What are you using for the BoardConfig.mk? That file has some values that looks like they are the size of our partitions and things like that. Since we don't have a usable /proc/mtd, I wrote a little app to pull the information from the phone. It asks the kernel for the information, and it also reads the raw flash and determines that information itself and then compares the two to make sure they match. It created this output:
Code:
[COLOR=#1f1c1b][FONT=Monospace] (sectors) (bytes)[/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] device start size start size mount name[/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p1 1 1000 200 200000 2.00 MiB ? dbl.mbn [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p2 1001 1000 200200 200000 2.00 MiB ? osbl.mbn [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p3 2001 3800 400200 700000 7.00 MiB ? fota [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p4 5801 2 b00200 400 1.00 KiB ? EBR [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p5 8000 8000 1000000 1000000 16.00 MiB /persist persist [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p6 10000 74000 2000000 e800000 232.00 MiB /cache cache [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p7 84000 2000 10800000 400000 4.00 MiB ? Unknown [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p8 88000 c000 11000000 1800000 24.00 MiB ? Misc. [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p9 94000 4000 12800000 800000 8.00 MiB ? Boot [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p10 98000 2000 13000000 400000 4.00 MiB ? modem fs1 [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p11 9c000 2000 13800000 400000 4.00 MiB ? modem fs2 [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p12 a0000 b4000 14000000 16800000 360.00 MiB /system system [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p13 154000 1c4000 2a800000 38800000 904.00 MiB /data userdata [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p14 318000 4000 63000000 800000 8.00 MiB ? Recovery [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p15 31c000 3dc000 63800000 7b800000 1.93 GiB ? SD Card [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p16 6f8000 e000 df000000 1c00000 28.00 MiB ? amss.mbn [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p17 708000 2000 e1000000 400000 4.00 MiB ? appsbl [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p18 70c000 4000 e1800000 800000 8.00 MiB ? adsp [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p19 710000 e000 e2000000 1c00000 28.00 MiB ? amssbak [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p20 720000 4000 e4000000 800000 8.00 MiB ? adspbak [/FONT][/COLOR]
[COLOR=#1f1c1b][FONT=Monospace] mmcblk0p21 724000 8000 e4800000 1000000 16.00 MiB /mpt mpt
[/FONT][/COLOR]
Code:
[COLOR=#1f1c1b][FONT=Monospace]USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/LGE/m3s_virgin_us/BoardConfigVendor.mk
TARGET_NO_BOOTLOADER := true
TARGET_BOARD_PLATFORM := unknown
TARGET_CPU_ABI := armeabi-v7a
TARGET_BOOTLOADER_BOARD_NAME := m3s_virgin_us
BOARD_KERNEL_CMDLINE := androidboot.hardware=qcom
BOARD_KERNEL_BASE := 0x00200000
BOARD_KERNEL_PAGESIZE := 4096
# fix this up by examining /proc/mtd on a running device
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00800000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00800000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x16800000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x38800000
BOARD_FLASH_BLOCK_SIZE := 0x40000
TARGET_PREBUILT_KERNEL := device/LGE/m3s_virgin_us/kernel
BOARD_HAS_NO_SELECT_BUTTON := true
# Use this flag if the board has a ext4 partition larger than 2gb
#BOARD_HAS_LARGE_FILESYSTEM := true
[/FONT][/COLOR]Here is my BoardConfig.mk. I have no idea if I did things correctly.
Code:
USE_CAMERA_STUB := true
# inherit from the proprietary version
-include vendor/lge/vm696/BoardConfigVendor.mk
TARGET_NO_BOOTLOADER := true
TARGET_BOARD_PLATFORM := unknown
TARGET_CPU_ABI := armeabi
TARGET_BOOTLOADER_BOARD_NAME := vm696
BOARD_KERNEL_CMDLINE := androidboot.hardware=qcom
BOARD_KERNEL_BASE := 0x00200000
BOARD_KERNEL_PAGESIZE := 4096
# fix this up by examining /proc/mtd on a running device
BOARD_BOOTIMAGE_PARTITION_SIZE := 0x00380000
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 0x00480000
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 0x08c60000
BOARD_USERDATAIMAGE_PARTITION_SIZE := 0x105c0000
BOARD_FLASH_BLOCK_SIZE := 131072
TARGET_PREBUILT_KERNEL := device/lge/vm696/kernel
TARGET_RECOVERY_INITRC := device/lge/vm696/recovery/recovery.rc
#BOARD_HAS_NO_SELECT_BUTTON := true
# Use this flag if the board has a ext4 partition larger than 2gb
#BOARD_HAS_LARGE_FILESYSTEM := trueI finally got mine to build by commenting out some lines in /build/core/definitions.mk. I can't say I know what I'm doing, but found that advice on one of the many tutorials/guides that are around. I have to say that there really isn't a good and complete guide for building CWM.
I tried my recovery.img and it just bootloops. I'd be happy to try your IMG.
Did you un/re-pack the recovery before installing it? I'm not sure if it will be required, but I'm pretty sure it won't hurt anything. What I mean is to let the build process create whatever it wants to create, and then using the abootimg program to stick the CWM ramdisk into our stock recovery.
As far as the BoardConfig.mk goes, I believe the BOARD_XXXX_PARTITION_SIZE need to be matched to our layout. If they are too small, the recovery may not wipe the full data when it tries to clear data/cache. If the numbers are too big, it may write past the end of one partition and into another one.
As far as the BoardConfig.mk goes, I believe the BOARD_XXXX_PARTITION_SIZE need to be matched to our layout. If they are too small, the recovery may not wipe the full data when it tries to clear data/cache. If the numbers are too big, it may write past the end of one partition and into another one.
Good call on the partition sizes. I didn't think to question those values, but they were clearly incorrect. I assumed they were somehow taken from the recovery.img when running mkvender.sh. That takes care of the "too large" problem without having to modify definitions.mk. Cool.
I haven't used abootimg before, I've only used split_bootimg.pl. But I'll give that a shot.
UPDATE: I combined the CWM ramdisk with the stock recovery kernel using mkbootimg and still get loops.
Code:
desktop:~/android/cyanogenmod$ out/host/linux-x86/bin/mkbootimg --kernel out/target/product/vm696/stockrecoverykernel --ramdisk out/target/product/vm696/ramdisk-recovery.img --cmdline "androidboot.hardware=qcom" --base 0x00200000 --pagesize 4096 --output out/target/product/vm696/hybridrecovery.imgWe also may need to change BOARD_KERNEL_BASE to 0x208000. That is what our stock recovery has for hdr->kernel_addr. I didn't see a place to set the ramdisk address, second address, or tags address yet. But in our stock recovery, we have these.
hdr->kernel_addr 208000
hdr->ramdisk_addr 1300000
hdr->second_size 0
hdr->second_addr 1100000
hdr->tags_addr 200100
hdr->page_size 1000
(all values in hex)
If I had to venture a guess, I would say that this is why the repacked recoveries were not booting that were tried months ago. And that would also be why the abootimg program works to replace the kernel and ramdisk. It doesn't modify the addresses.
hdr->kernel_addr 208000
hdr->ramdisk_addr 1300000
hdr->second_size 0
hdr->second_addr 1100000
hdr->tags_addr 200100
hdr->page_size 1000
(all values in hex)
If I had to venture a guess, I would say that this is why the repacked recoveries were not booting that were tried months ago. And that would also be why the abootimg program works to replace the kernel and ramdisk. It doesn't modify the addresses.
Very interesting.
I used CONFIG_PHYS_OFFSET=0x00200000 from /proc/config.gz. I thought that was correct.
Hopefully 0x00208000 helps.
Update: Aw, nuts. I think that kills it.. frozen on the LG logo.
Battery-pull got me out of that pickle... no real harm done.
I suppose I'll try that one more time with the stock kernel+cwm ramdisk.
At least it didn't boot loop.. just froze. haha
UPDATE: Frozen again. Oh well. It'd be nice if we could get a log of the recovery trying to boot. I only know how to do that with dmesg from adb shell, and I don't think it works when booting recovery.
UPDATE: I also tried repacking one of the builder.clockworkmod.com CWM builds I did with the stock kernel and 0x00200000 base, and then another simply with the 0x00208000 base, no luck.
The 0x00208000 base builds definitely alway freeze at the LG logo.
The only builds i got to do anything at all were the ones where I stuck a different ramdisk/kernel in the stock one with abootimg. I've still not had anything at all appear on the phone's LCD screen. All the cool distorted cwm logos have been snagged using the diag interface. You can try to find a device similar to ours that uses a graphics.c file and figure out how to tell the build system to use it.
I did have one experiment where I used that online CWM builder. Then I unpacked it's ramdisk, mixed and matched some stuff from our stock recovery, and packed up the ramdisk and stuck it in the stock recovery. It booted up and I was able to connect with adb. So in that one, a lot of stuff was happening correctly, just the main program not knowing how to draw on the screen.
I did have one experiment where I used that online CWM builder. Then I unpacked it's ramdisk, mixed and matched some stuff from our stock recovery, and packed up the ramdisk and stuck it in the stock recovery. It booted up and I was able to connect with adb. So in that one, a lot of stuff was happening correctly, just the main program not knowing how to draw on the screen.
Curtis1973
Android Expert
optimus m+ may have the same graphics.c
So it looks like we need to toss in a few lines in the boardconfig.mk to tell it to use the graphics.c file. https://github.com/Shabbypenguin/android_device_lge_ms695/blob/master/BoardConfig.mk
I'm still too chicken to try it out.
I'm still too chicken to try it out.