• Announcements

    • PaulOBrien

      Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such software Nintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance) CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission) ROMs must give full credit to the original author ISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • PaulOBrien

      Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.
sej7278

Compiling CM9 (and maybe CM10) for Blade

798 posts in this topic

So I'm looking at a page from another forum it seems that the process for compiling JB is very similar to ICS, but functioned proprietary vendor files, which we used to compile ICS?.

http://forum.xda-dev...d.php?t=1762641

yes it will be exactly the same, just a different repo branch to point at. i hope we won't need new adreno200 drivers, obviously we still don't have openmax.

1

Share this post


Link to post
Share on other sites

So I'm looking at a page from another forum it seems that the process for compiling JB is very similar to ICS, but functioned proprietary vendor files, which we used to compile ICS?.

http://forum.xda-dev...d.php?t=1762641

Yes, the principles are the same no matter what Android source you're using (AOSP, CM7/9, AOKP, Code Aurora, etc). Download the source, put device and vendor trees in place, and (try to) compile.

AOSP source works "out-of-the-box" for only few devices (nexus devices and moto xoom). Be prepared to sort all kinds of build errors (it doesn't compile for ARMv6 for one) and still at best you'll end up with a ROM that (hopefully) boots but almost nothing works.

CM10 is already well under way. JB code is in a new branch and quite a bit CM9 code has been merged on top that. Most of the native code side seems to done (e.g. dalvik has ARMv6 support). Just give it a few days and it will all be much easier. ;)

2

Share this post


Link to post
Share on other sites

https://github.com/k...tary_vendor_zte directory now has disappeared, you know if there is any other to replace it?. You may be removed to work on JB?

that's a bit worrying, jacob's one was never updated for ics either. back to the old extract-files.sh method i guess, but that's not much good as nobody actually has a blade running an official ics/jb. i guess we could upload a mirror of what we have locally if needed.

i just repo init'ed jellybean, 15Gb without any device trees again.

1

Share this post


Link to post
Share on other sites

Hmm... I wonder why it was removed. I pushed it to my github (with commit history).

https://github.com/K...tary_vendor_zte

nice one. i tweeted koush about it (and i hate twitter lol!) not sure why jacob never added an ics branch to his repo.

i hope JB isn't going towards only using extract-files.sh as we don't have ICS/JB devices to rip them from.

0

Share this post


Link to post
Share on other sites

Thank you for taking the time to upload KonstaT, hopefully soon have CM10, for our Blades

0

Share this post


Link to post
Share on other sites

I mostly game on a desktop PC. Which is why I use VM's for compiling rather the dual boot. I can be gaming whilst it's compiling. :D

There's not much point in having both a gaming PC and console because of the large crossover between the games. And as they cost more on consoles, if you've gone to the larger expense of building a gaming PC vs a cheap console you may as well have the cheaper PC games that are available to you. And then where there are platform exclusive games I tend towards those that are exclusive to PC like strategy games.

However, being in my 30's, I often reminisce of simpler times where it was all about the gameplay and less about the graphics, hours of cut scenes and complicated controls. PC gaming is beginning to be catered for now in that market with the rise of Indie gaming.

But prior to that I had a DS where the lack of power kind of limited it and so it was all about classic Nintendo gameplay. And this is what the phone basically replaced. You always have your phone with you to play a quick game for 10 minutes. But you sort of have to have planned ahead to have the DS with you! And as these phone games are so cheap, I've built up a huge collection of them - spending in total more than the Blade cost lol.

bit of topic but do you actually compile while paying high end pc games? i have access to an i7-2600k rig with an over clocked GTX 570 and own an i5 laptop with a gtx 560m. and when playing games like crysis 2, max payne 3, skyrim (heavily modded), and battlefield 3...etc both setups work pretty hard so i reckon it would substantially affect framerate if i tried to compile at the same time. plus the lappy would probs catch fire! the heat a high end laptops generate is ridiculous.

and yer i agree with the mobile gaming. love the cheap price and easily accessible games. can't wait for my nexus 7 so i can use that as my android gaming "rig" and get into this tegrazone stuff and leave my phone for hacking and general phone use.

Edited by hugobosslives
0

Share this post


Link to post
Share on other sites

My VM is restricted to 1 CPU core and is on the hard drive whereas my most commonly played games are on an SSD so there's little shared hardware.

I suspect what mostly allows me to game whilst compiling though is my taste in games! You'll generally catch me playing strategy games and platformers which are all a lot less demanding than the games you've named. :D

0

Share this post


Link to post
Share on other sites

My VM is restricted to 1 CPU core and is on the hard drive whereas my most commonly played games are on an SSD so there's little shared hardware.

I suspect what mostly allows me to game whilst compiling though is my taste in games! You'll generally catch me playing strategy games and platformers which are all a lot less demanding than the games you've named. :D

ah that makes more sense. i was thinking that maybe you didn't play your games on 1080p/high settings but i didn't want to sound like on of those shites that always claim they can run better graphics than everyone else.

well your pc is better than mine in that you have a ssd. i'm stuck with a 7200rpm desktop hard drive made to fit in my lappy. seriously considering buying a small ssd now the prices have crashed and mounting it in my optical bay. and then putting that drive into an external DIY caddy as i only use it for installing games from amazon/play.

cheers for the idea on compiling in windows when i'm spending a day gaming or have little time. usually reboot to ubuntu and set to compile during dinner and hope there wasn't an error that stopped the progress when i get back. although I doubt my dual core i5 would run games on one core? presumably you have a quad core?

0

Share this post


Link to post
Share on other sites

I actually have a 4 year old Core2Duo backed up by a more modern but not exactly state of the art ATI 6850. And I had to up from 4gb to 6gb (ddr2 so too expensive to buy lots of ram!) so I could compile and game. Because the consoles are so dated and games have to run on them I've never needed to upgrade it (other than the GPU to support DX 10 at a decent speed - it was previously an 8800GT).

It made such a nice change to not have to upgrade my PC every year after the previous 15 years of doing so, that I've grown quite attached to this old thing and set myself a goal of keeping it until the next gen consoles force me to upgrade!

I just have a few SSD's because I kinda unofficially support them over at Crucial. It was my forum addiction before this one. :D

0

Share this post


Link to post
Share on other sites

i've been trying to build jellybean but can't seem to get past problems with bionic. any ideas?

device tree and vendor tree


target thumb C: libc_common <= bionic/libc/bionic/sched_cpualloc.c

bionic/libc/bionic/realpath.c: In function 'realpath':

bionic/libc/bionic/realpath.c:112:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

bionic/libc/bionic/realpath.c:204:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]

bionic/libc/bionic/sched_getaffinity.c: In function 'sched_getaffinity':

bionic/libc/bionic/sched_getaffinity.c:33:5: warning: implicit declaration of function '__sched_getaffinity' [-Wimplicit-function-declaration]

bionic/libc/bionic/sched_getaffinity.c:36:13: warning: implicit declaration of function 'memset' [-Wimplicit-function-declaration]

bionic/libc/bionic/sched_getaffinity.c:36:13: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default]

target thumb C: libc_common <= bionic/libc/bionic/sched_cpucount.c

target thumb C: libc_common <= bionic/libc/bionic/semaphore.c

target thumb C: libc_common <= bionic/libc/bionic/sha1.c

target thumb C: libc_common <= bionic/libc/bionic/ssp.c

target thumb C: libc_common <= bionic/libc/bionic/stubs.c

target thumb C: libc_common <= bionic/libc/bionic/system_properties.c

target thumb C: libc_common <= bionic/libc/bionic/tdelete.c

target thumb C: libc_common <= bionic/libc/bionic/tdestroy.c

bionic/libc/bionic/stubs.c: In function 'android_id_to_passwd':

bionic/libc/bionic/stubs.c:197:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

bionic/libc/bionic/stubs.c: In function 'android_name_to_passwd':

bionic/libc/bionic/stubs.c:210:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

bionic/libc/bionic/stubs.c: In function 'android_id_to_group':

bionic/libc/bionic/stubs.c:223:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

bionic/libc/bionic/stubs.c: In function 'android_name_to_group':

bionic/libc/bionic/stubs.c:236:37: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]

target thumb C: libc_common <= bionic/libc/bionic/time64.c

In file included from bionic/libc/private/bionic_atomic_inline.h:53:0,

				 from bionic/libc/bionic/semaphore.c:33:

bionic/libc/private/bionic_atomic_arm.h:54:4: warning: #warning Rebuilding this source file in ARM mode is highly recommended for performance!! [-Wcpp]

target thumb C: libc_common <= bionic/libc/bionic/tfind.c

target thumb C: libc_common <= bionic/libc/bionic/thread_atexit.c

bionic/libc/private/bionic_atomic_arm.h: In function '__sem_dec':

bionic/libc/private/bionic_atomic_arm.h:144:9: error: unknown register name 'r3cc' in 'asm'

bionic/libc/private/bionic_atomic_arm.h: In function '__sem_trydec':

bionic/libc/private/bionic_atomic_arm.h:144:9: error: unknown register name 'r3cc' in 'asm'

bionic/libc/private/bionic_atomic_arm.h: In function 'sem_post':

bionic/libc/private/bionic_atomic_arm.h:144:9: error: unknown register name 'r3cc' in 'asm'

make: *** [out/target/product/blade/obj/STATIC_LIBRARIES/libc_common_intermediates/bionic/semaphore.o] Error 1

make: *** Waiting for unfinished jobs....

target thumb C: libc_common <= bionic/libc/bionic/tsearch.c

0

Share this post


Link to post
Share on other sites

i've been trying to build jellybean but can't seem to get past problems with bionic. any ideas?

Compile using TARGET_ARCH_VARIANT := armv5te-vfp instead of armv6-vfp or patch the asm code to support arm6. That'll get you forward but there's more to come. :P

I'm now successfully compiling and booting CM10. Friday the 13th has always been my lucky day. ;) Device tree has been in my github for a while.

3

Share this post


Link to post
Share on other sites

When compiling with v6 you only need one hack along with my patch on Gerrit. I'll edit this post in a few minutes with it.

0

Share this post


Link to post
Share on other sites

When compiling with v6 you only need one hack along with my patch on Gerrit. I'll edit this post in a few minutes with it.

i saw this patch of yours on gerrit (full of whitespace errors argh!) :D what's the other one?

none of our blade, blade2 or skate device trees look much different (mostly cm9 plus the ALOG fixes etc.) so not sure what's my problem.

Edited by sej7278
0

Share this post


Link to post
Share on other sites

That patch and add #undef __ARM_HAVE_LDREX_STREX above line 138 of bionic/libc/private/bionic_atomic_arm.h

0

Share this post


Link to post
Share on other sites

That patch and add #undef __ARM_HAVE_LDREX_STREX above line 138 of bionic/libc/private/bionic_atomic_arm.h

ah that seems to be doing it, where do you find this info?

stuck at audioinwrapper.cpp now :(


external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp: In function 'int AudioSetVolume(int, int)':

external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp:155:61: error: invalid conversion from 'int' to 'audio_stream_type_t' [-fpermissive]

frameworks/av/include/media/AudioSystem.h:58:21: error:   initializing argument 1 of 'static android::status_t android::AudioSystem::setStreamVolume(audio_stream_type_t, float, audio_io_handle_t)' [-fpermissive]

external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp: In function 'int AudioGetVolume(int)':

external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp:165:50: error: invalid conversion from 'int' to 'audio_stream_type_t' [-fpermissive]

frameworks/av/include/media/AudioSystem.h:60:21: error:   initializing argument 1 of 'static android::status_t android::AudioSystem::getStreamVolume(audio_stream_type_t, float*, audio_io_handle_t)' [-fpermissive]

make: *** [out/target/product/blade/obj/SHARED_LIBRARIES/libSR_AudioIn_intermediates/audioinwrapper.o] Error 1

your dalvik patch with the whitespace fixed (no-op's with trailing spaces): dalvik.patch.zip

Edited by sej7278
0

Share this post


Link to post
Share on other sites

ah that seems to be doing it, where do you find this info?

stuck at audioinwrapper.cpp now :(


external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp: In function 'int AudioSetVolume(int, int)':
external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp:155:61: error: invalid conversion from 'int' to 'audio_stream_type_t' [-fpermissive]
frameworks/av/include/media/AudioSystem.h:58:21: error: initializing argument 1 of 'static android::status_t android::AudioSystem::setStreamVolume(audio_stream_type_t, float, audio_io_handle_t)' [-fpermissive]
external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp: In function 'int AudioGetVolume(int)':
external/srec/audio/AudioIn/UNIX/src/audioinwrapper.cpp:165:50: error: invalid conversion from 'int' to 'audio_stream_type_t' [-fpermissive]
frameworks/av/include/media/AudioSystem.h:60:21: error: initializing argument 1 of 'static android::status_t android::AudioSystem::getStreamVolume(audio_stream_type_t, float*, audio_io_handle_t)' [-fpermissive]
make: *** [out/target/product/blade/obj/SHARED_LIBRARIES/libSR_AudioIn_intermediates/audioinwrapper.o] Error 1
[/CODE]

your dalvik patch with the whitespace fixed (no-op's with trailing spaces): dalvik.patch.zip

I make it up lol :P.

libSRaudio needs to be disabled until our audio drivers support it.

As for the whitespace - I didn't produce the asm output. It was generated by python script which is the cause of the whitespaces.

0

Share this post


Link to post
Share on other sites

That patch and add #undef __ARM_HAVE_LDREX_STREX above line 138 of bionic/libc/private/bionic_atomic_arm.h

I ended up removing the insulting half of the ifdeffage, but this might be more elegant. ;)

I make it up lol :P.

libSRaudio needs to be disabled until our audio drivers support it.

Well, the compiler tells you exactly where the problem is so you don't have to make it all up from the top of your head.

There's bunch of stuff that needs to be disabled for now. libSRaudio, libaac/libFraunhoferAAC -> AACenc bits in libstagefright etc. Have you found any solutions to these?. Doesn't seem to affect too much though since audio is one the very few things I have working at the moment. :P

0

Share this post


Link to post
Share on other sites

There's bunch of stuff that needs to be disabled for now. libSRaudio, libaac/libFraunhoferAAC -> AACenc bits in libstagefright etc. Have you found any solutions to these?. Doesn't seem to affect too much though since audio is one the very few things I have working at the moment. :P

lol, yeah there's a massive amount that doesn't seem to be anywhere near working - add iptables to that list. i'm giving up for now as most of the bugs (well unported code i guess) are outside our device/vendor trees.

are cyanogenmod actually starting from scratch with cm10 rather than basing it on cm9, as it seems like there would be a fair bit of work involved in porting all the cm9 fixes into the jellybean aosp code, possibly more than porting the aosp code into cm9 to make cm10.

0

Share this post


Link to post
Share on other sites

I feel so privileged to be a Blade user knowing that we have developers like you guys, Thanks.

0

Share this post


Link to post
Share on other sites

Hi!

How do I disable libSRaudio?

And I'm getting bunch of errors regarding export_includes and always with librpc_intermediates

make: *** No rule to make target `out/target/product/tass/obj/SHARED_LIBRARIES/librpc_intermediates/export_includes', needed by `out/target/product/tass/obj/STATIC_LIBRARIES/libloc_api-rpc_intermediates/import_includes'.  Stop.[/CODE]

Any ideas?

0

Share this post


Link to post
Share on other sites

I feel so privileged to be a Blade user knowing that we have developers like you guys, Thanks.

+1

Lovely work going on here!

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2016. MoDaCo uses IntelliTxt technology.