Building your own ROM

[bigsupersquid]

Yes, you can modify the appropriate files to build vanilla aosp, pm'd you.
...snip...

could you share? Pretty-please?
I've successfully built vanilla AOSP and CAF Gingerbread, but only generic builds. I can get them to boot by including a working boot.img, but with no hardware support.
I tried patching in the extra stuff from IHO to AOSP and CAF a while back, but obviously didn't get it right because I couldn't get it to copy any of the proprietary stuff in at all when building.

Building should be a little easier for me now that I'm back to focussing on the stock VM radio; I finally finished off my old OV where it doesn't even have emergency mode anymore... in fact, it won't even light up the buttons or screen when plugged in, and doesn't respond to any buttons at all. At least on its way out the PC would still see it as a port and modem even though it couldn't read from or write to the phone, but after it stopped lighting up the PC lost all interest in talking to it. Couldn't find a JTAG connector or anything like that inside it, but at least it looks like I can swap the nicer old screen assembly to my newer phone (the old screen has better color response and doesn't look so green, plus has better software compatibility.) Ah, parts is parts, I guess. Sorry for the off-topic finale, just wanted to vent.

 

[JerryScript]

Do a diff of the thunderc make files, add the proprietary files from lg, and use the cyanogenmod apns.conf file, and I would recommend patching in Blarfs mms and camera packages. Those are the main steps, but it would probably be easiest to spend an hour following the TechTv video with the files you need in front of you.

It's a project I've been wanting to do for a while, just never seem to find the time.

 

[bigsupersquid]

ok, I'll give up search-engine hunting for now and watch the videos.
I really need a better handle on how those proprietary files are dealt with by the build system, and can't seem to find any good, consistent info from google. so, time to check out the media.
thanks for the pointers.

 

[BobZhome]

@redhat, look like your set up is missing parts of frameworks/base and external/webkit
Did you have any issues with repo sync?
Try deleting those folders and re-syncing.

 

[redhat#AC]

looks like its working now thanks

edit: or not :/ i give up

 

[mrg666]

The latest builds after OMAP updates are giving an error with VideoView.java. You can just revert that file to the previous version in the following link.
https://github.com/CyanogenMod/andr...b42ab/core/java/android/widget/VideoView.java

This solves the problem. FYI.

 

[asadullah]

I didn't see the md5sum for the lg optimus v source code from lg open source main.
Here's what I got:

fc5ae80f9d10af28aed954ee35e9e866

 

[BobZhome]

that md5 is correct for LGVM670(Thunder)_Android_Froypensource_02.zip

 

[asadullah]

Hopefully I find an answer but does anyone know how to fix this:

Which would you like? [generic-eng] 4
build/core/product_config.mk:203: *** No matches for product "thunderc_VM670".  Stop.

** Don't have a product spec for: 'thunderc_VM670'
** Do you have the right repo manifest?

** Invalid variant: 'user-debug'
** Must be one of user userdebug eng

Let me throw in what I've done since most people with this error have just repo synced and fixed it. I'm going for a stock gingerbread build as practice for ics so I downloaded the google gingerbread source and added a new lunch combo then added lge to devices as well as vendor. tried to build but no go

 

[mrg666]

I would check if vendor/cyanogen/products/AndroidProducts.mk looks like the following, specifically, if the first line in place.

PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/cyanogen_thunderc.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_cricket.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_metropcs.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_sprint.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_usc.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_verizon.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_virgin.mk

 

[asadullah]

I would check if vendor/cyanogen/products/AndroidProducts.mk looks like the following, specifically, if the first line in place.

PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/cyanogen_thunderc.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_cricket.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_metropcs.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_sprint.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_usc.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_verizon.mk \
    $(LOCAL_DIR)/cyanogen_thunderc_virgin.mk

I don't have anything cyanogen since it's the straight google source code

 

[mrg666]

I don't have anything cyanogen since it's the straight google source code

Okay, I thought you were asking about IHO.

 

[bigsupersquid]

the easiest way around it until you pick through the bones of the folder, is to include the vendor/cyanogen folder from the iho repository, and leave the lunch combos untouched... you can mod them once you distill down the vendor/cyanogen to something more vanilla.
there are makefiles in vendor/cyanogen/products that you'll either need or need to merge into vendor/lge/thunderc or device/lge/thunderc.
there are also issues with the device/lge/thunderc/files/overlay files, many are cyanogen-'tainted' and either need removed or pruned.

 

[JerryScript]

Hopefully I find an answer but does anyone know how to fix this:

Which would you like? [generic-eng] 4
build/core/product_config.mk:203: *** No matches for product "thunderc_VM670".  Stop.

** Don't have a product spec for: 'thunderc_VM670'
** Do you have the right repo manifest?

** Invalid variant: 'user-debug'
** Must be one of user userdebug eng

Let me throw in what I've done since most people with this error have just repo synced and fixed it. I'm going for a stock gingerbread build as practice for ics so I downloaded the google gingerbread source and added a new lunch combo then added lge to devices as well as vendor. tried to build but no go

Using the IHO repo, work your way backwards through the steps from that product file, see which file calls it, then determine how you want to arrange your repo.

 

[asadullah]

the easiest way around it until you pick through the bones of the folder, is to include the vendor/cyanogen folder from the iho repository, and leave the lunch combos untouched... you can mod them once you distill down the vendor/cyanogen to something more vanilla.
there are makefiles in vendor/cyanogen/products that you'll either need or need to merge into vendor/lge/thunderc or device/lge/thunderc.
there are also issues with the device/lge/thunderc/files/overlay files, many are cyanogen-'tainted' and either need removed or pruned.

I put the cyanogen folder into vendor and that fixed one problem but created another. I'm pretty determined right now. May have to go jerryscripts way but it doesn't sound fun.

Here is a site on make files http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_121.html

And here is the android configure a new product page

Okay, I thought you were asking about IHO.

Thanks though

 

[bigsupersquid]

the cyanogen build system uses armv6-vfp as subarch. (TARGET_ARCH_VARIANT in device/lge/thunderc/BoardConfig.mk)
the CAF build system doesn't offer that one, but does have armv6k-vfp.
I don't remember the aosp repo offering either of those two, and it was the second annoying error I had to track down.
For an aosp build I had to import the cyanogen build/core/arch/arm/armv6-vfp.mk and android_dalvik to handle the vfp functions.
you could also drop the vfp support (TARGET_ARCH_VARIANT := armv6) , but why slow it down with soft-float math in the interpreter?
For CAF I just had to change armv6-vfp to armv6k-vfp in the BoardConfig.mk
But, CAF is super picky about the 64 bit build system, and while I was able to patch it some time ago for 32 bit, my recent attempt to do the same disgusted me so much I just chucked in the aosp external/clearsilver project into the repo instead of the CAF version.
I'm getting tired of the tweaks in the CAF system and will probably just save it for patching aosp.
so, I might see if I can get a fresh aosp repo overnight to play with, but it takes FOREVER to make the initial sync with my bandwidth.

edit:
only about 20 hours to sync aosp :-[ eek, and it's still smaller than CAF.
sure enough, aosp repo lacks the armv6-vfp variants. it'll require either adding in the armv6-vfp.mk from cyanogen or armv6k-vfp from CAF, plus the matching dalvik from those respective repos, or changing to TARGET_ARCH_VARIANT := armv5te-vfp instead for pure aosp. the armv5te route would be simplest but slowest running on device since it's be built for a wimpier chipset than the armv6. doubt that it make a ton of real-world difference, still has the -vfp option for the coproccessor.

 

[bigsupersquid]

now that my aosp repo is synced, and I try to build it, I got a 'new' (to me) error, griping about copybit:
"user tag detected on new module - user tags are only supported on legacy modules. Stop."
I google it, found what appears to be a solution, here
in a nutshell:

What I did is to replace the “LOCAL_MODULE_TAGS := user” in every Android.mk with “LOCAL_MODULE_TAGS := optional”. It just seems to work at present. I’m not sure if there will be any problem in the future. So please remind me if you find problem here.

in the source root directory, execute:

find ./ -exec grep -l "LOCAL_MODULE_TAGS := user" {} \; -exec sed -i.bak s/"LOCAL_MODULE_TAGS := user"/"LOCAL_MODULE_TAGS := optional"/g {} \;

lots of errors regarding .git directories, but that doesn't matter.
that little change let my build start.

 

[asadullah]

So how did the build go?

 

[bigsupersquid]

another armv6k-vfp based error...
also had to import system/core/debuggerd/vfp.S from CAF to aosp to get the armv6k-vfp to work.
it built, wouldn't boot. adb worked but no logcat or shell functions.
looked in /system from recovery, it seemed to be mostly there except for the /system/bin/sh
pushed /system/bin/sh to get shell in adb when booting.
could use shell then, but it couldn't find any other functions (no ls, toolbox, ps, etc.)
same with cm7 boot.img.

Keeping on trying...

 

[bigsupersquid]

so, it looks like the aosp 2.3.7 code is being compiled for armv7 in spite of the device makefile settings for armv6.
the binaries it produces won't execute on the phone, at all. I can move, say, toolbox, into /system/xbin on a working rom, rename it something harmless like 'duh', chmod 4755 it, and trying to run it only says
duh: no such tool

I tried with several binaries, a couple different builds.
no wonder it wouldn't boot and said /system/bin/sh not found!

Generic builds appear to now produce armv7 code by default. Yuk. last time I used aosp for a generic build the repo was still at 2.3.3 for gingerbread... it built usable binaries in a generic build back then.

Next I'll try armv5te-vfp in the BoardConfig.mk since it's supported by the build system without patching.
maybe that'll help it build something that'll run.

edit: it still seems to be building unrunnable binaries, with just changing the couple lines in BoardConfig.mk
bah.
So, I've been looking through the CAF device makefiles for the msm7627_surf, which shares the same base CPU/GPU chipset as the OV, and they use armv5te-vfp even though the build system includes armv6k-vfp.
the applicable chunk of BoardConfig.mk from the msm7627_surf

TARGET_GLOBAL_CFLAGS += -mfpu=vfp -mfloat-abi=softfp
TARGET_GLOBAL_CPPFLAGS += -mfpu=vfp -mfloat-abi=softfp
TARGET_CPU_ABI := armeabi
TARGET_ARCH_VARIANT := armv5te-vfp
TARGET_BOARD_PLATFORM := msm7k

so it looks like armv5te-vfp may indeed be the way to go, but there's some rearranging of which makefiles get what settings and how the included proprietary files like the included *.kl files are copied. there's a lot of patchwork neccesary to align the IHO thunderc makefiles with the msm7627_surf ones, I'm plugging away on it, and will definitely post up what it takes me to get runnable binaries out of aosp (and hopefully, eventually, how to get a whole functional build should I get that far.)
Any input from the more experienced is welcome.

last edit before a new post:
armv5te-vfp is producing working binaries... the armv6k-vfp might have, too, but I left out pushing the shared libs (duh) so that might be why it wasn't running the test files. It wouldn't run the armv5te-vfp toolbox without pushing the shared libs built at the same time, said no such tool until the new libs were pushed to /system/lib. wouldn't work with the cyanogen libs that were already in the phone.
I'll have to check on the armv6k-vfp again after I finish playing with armv5te-vfp.