01-17-2013 12:07 AM
1,060 ... 7891011 ...
tools
  1. bigsupersquid's Avatar
    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.
    10-24-2011 05:23 PM
  2. JerryScript's Avatar
    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 likes this.
    10-24-2011 05:41 PM
  3. bigsupersquid's Avatar
    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.
    10-24-2011 06:02 PM
  4. BobZhome's Avatar
    @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.
    10-24-2011 06:08 PM
  5. redhat#AC's Avatar
    looks like its working now thanks

    edit: or not :/ i give up
    10-25-2011 03:24 PM
  6. mrg666's Avatar
    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/andro...VideoView.java

    This solves the problem. FYI.
    10-28-2011 11:34 AM
  7. asadullah's Avatar
    I didn't see the md5sum for the lg optimus v source code from lg open source main.
    Here's what I got:
    Code:
    fc5ae80f9d10af28aed954ee35e9e866
    10-29-2011 09:22 AM
  8. BobZhome's Avatar
    that md5 is correct for LGVM670(Thunder)_Android_Froyo_Opensource_02.zip
    asadullah likes this.
    10-29-2011 12:00 PM
  9. asadullah's Avatar
    Hopefully I find an answer but does anyone know how to fix this:
    Code:
    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
    10-29-2011 07:44 PM
  10. mrg666's Avatar
    I would check if vendor/cyanogen/products/AndroidProducts.mk looks like the following, specifically, if the first line in place.

    Code:
    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
    10-29-2011 08:05 PM
  11. asadullah's Avatar
    I would check if vendor/cyanogen/products/AndroidProducts.mk looks like the following, specifically, if the first line in place.

    Code:
    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
    10-29-2011 08:18 PM
  12. mrg666's Avatar
    I don't have anything cyanogen since it's the straight google source code
    Okay, I thought you were asking about IHO.
    10-29-2011 09:00 PM
  13. bigsupersquid's Avatar
    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.
    asadullah likes this.
    10-29-2011 09:01 PM
  14. JerryScript's Avatar
    Hopefully I find an answer but does anyone know how to fix this:
    Code:
    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.
    10-29-2011 09:03 PM
  15. asadullah's Avatar
    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/localfile.../make_121.html

    And here is the android configure a new product page

    Okay, I thought you were asking about IHO.
    Thanks though
    10-29-2011 10:51 PM
  16. bigsupersquid's Avatar
    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.
    10-30-2011 12:54 AM
  17. bigsupersquid's Avatar
    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:
    Code:
    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.
    10-31-2011 08:21 AM
  18. asadullah's Avatar
    So how did the build go?
    10-31-2011 12:13 PM
  19. bigsupersquid's Avatar
    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...
    10-31-2011 01:22 PM
  20. bigsupersquid's Avatar
    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
    Code:
    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.
    JerryScript likes this.
    11-02-2011 11:59 PM
  21. mrg666's Avatar
    The latest surfaceflinger merge causes image corruption in some apps such as Google Goggles and Barcode Scanner. FYI.
    JerryScript and BobZhome like this.
    11-06-2011 12:38 AM
  22. jdcnosse's Avatar
    So I decided that I wanted to try my hand at the next step up in making a custom ROM, and that is going from modifying already built zip files to compiling the source code straight on my computer.

    I followed the steps in post 3 of this thread, but I didn't get a zip file in out/target/product/thunderc I only got an assortment of files that look like they are my ROM...but not zipped.

    I've attached a screenshot to illustrate.
    11-08-2011 09:00 PM
  23. pbailey212's Avatar
    Did you have any errors after make bacon?
    11-08-2011 09:17 PM
  24. jdcnosse's Avatar
    Did you have any errors after make bacon?
    Not that I know of, but I should really pay better attention to the screen haha. Do the errors all get listed after make bacon is completely finished, or do they Just pop up as make bacon is running? Just trying to get a handle on if I have to watch the screen the whole time lol

    I should also include this doesn't have any modifications yet. I was simply compiling after finishing syncing the repo to see if it all worked.

    EDIT: Just ran it again and up I got 3 errors. Or one. I'm not sure.

    Here's the end of my make bacon.

    Code:
    target Strip: libstagefrighthw (out/target/product/thunderc/obj/lib/libstagefrighthw.so)
    target Strip: libcamera_client (out/target/product/thunderc/obj/lib/libcamera_client.so)
    target Strip: bootanimation (out/target/product/thunderc/obj/EXECUTABLES/bootanimation_intermediates/bootanimation)
    target SharedLib: libcamera (out/target/product/thunderc/obj/SHARED_LIBRARIES/libcamera_intermediates/LINKED/libcamera.so)
    target Strip: screenshot (out/target/product/thunderc/obj/EXECUTABLES/screenshot_intermediates/screenshot)
    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.
    3 errors
    target Strip: libsurfaceflinger (out/target/product/thunderc/obj/lib/libsurfaceflinger.so)
    make: *** [out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes-full-debug.jar] Error 41
    make: *** Waiting for unfinished jobs....
    11-08-2011 09:30 PM
  25. BobZhome's Avatar
    We can't see your errors, there are up further. Copy and paste the whole log on pastebin.com and post the link here.
    11-08-2011 10:24 PM
1,060 ... 7891011 ...
LINK TO POST COPIED TO CLIPBOARD