Jump to content

Cyanogen Mod 7 For Blade


Guest olionair

Recommended Posts

Here's what you need to change for 2G vmsplit:

https://www.codeaurora.org/gitweb/quic/la/?...ae3a7ef4b2cb9bb

At least on 2.2 that is what you need to do. If you want to make a quick hack, just replace the original prelink-linux-arm.map with the 2G version and change the two defines in prelinkmap.c.

thanks, looks a bit complex. might try using the cm7 tree to get an aurora build going, are you working on a new build yourself?

Link to comment
Share on other sites

thanks, looks a bit complex. might try using the cm7 tree to get an aurora build going, are you working on a new build yourself?

Isn't there a flag in CM that you can use to set the vmsplit?

Link to comment
Share on other sites

Guest kallt_kaffe
thanks, looks a bit complex. might try using the cm7 tree to get an aurora build going, are you working on a new build yourself?

Well, I've been kind of busy with other stuff. Had 2.2.1 booting but no RIL of course. Currently compiling AOSP 2.2 release 1.1 (FRF91) modified for 2G VMSPLIT to do some comparison against ZTE's 2.2 build. ZTE are using FRF91 and there are plenty of changes in the framework.jar between FRF91 and the later Froyo releases making it unnecessary difficult to try to track their RIL modifications. However compiling Android takes a day or two on my virtual linux machine (running on a really slow host) so progress is painfully slow. But my main goal is to get a booting AOSP 2.2 and then try to get the RIL working. I do not bother with wifi, bluetooth etc for now.

Btw, the modifications isn't as complex as it might look but I guess on 2.3 it may need more work.

Compare prelink-linux-arm.map from Codeaurora (using a 2.2 branch that has the -2G version of the .map file) with the prelink-linux-arm.map that is in the build you are compiling. If they are identical then they you can just replace the prelink-linux-arm.map with the -2G version and then change the two lines in prelinkmap.c:

#define PRELINK_MIN 0x90000000

#define PRELINK_MAX 0xBFFFFFFF

To:

#define PRELINK_MIN 0x50000000

#define PRELINK_MAX 0x6FFFFFFF

On the other hand if the the original prelink-linux-arm.map is not identical between 2.2 and 2.3 then it gets a bit more compilcated.

Edited by kallt_kaffe
Link to comment
Share on other sites

Currently compiling AOSP 2.2 release 1.1 (FRF91) modified for 2G VMSPLIT to do some comparison against ZTE's 2.2 build. ZTE are using FRF91 and there are plenty of changes in the framework.jar between FRF91 and the later Froyo releases making it unnecessary difficult to try to track their RIL modifications. However compiling Android takes a day or two on my virtual linux machine (running on a really slow host) so progress is painfully slow. But my main goal is to get a booting AOSP 2.2 and then try to get the RIL working. I do not bother with wifi, bluetooth etc for now.

I had a quick look at comparing the .smali/.java from the 2 frameworks and although it appears there is a lot of change I think much of it can be ignored, even in RIL there are extras that we probably dont need for stock android (mostly stuff to do with roaming and some zte debug/logging code). I used the approach of dex2java to generate .smali and then ran winmerge over that, then used jd-gui and winmerge to make more sense of the changes in java (albeit not quite right java), a lot of differences are caused by constants not being identified correctly which means that when they are used it shows the literal rather than constant so a simple change of 1 constant value will results in a difference everytime it was used since the new literal will appear rather than the old unchanges constant name.

I'm guessing that there will be some smallish change to get ril initialised correctly and that a lot of the extra baggage can be ignored, I noticed a change to the default network mode constant, maybe something like that is what screws it up.

I started to look at comparing the 2.1 frameworks too since we are using the 2.1 ril and they probably had less chance to add unnecessary baggage at that point.

Link to comment
Share on other sites

I had a quick look at comparing the .smali/.java from the 2 frameworks

Sounds very intersting! Could you provide a zip with all the diffs? I had a look at the two diffs you provided some time ago, that really looked like only a few things are crucial really.

I created a wiki page documenting and listing the things done/said so far:

- you can login to the wiki with your forum credentials. Please add and change things as needed. While for discussion the forum is great, for documentation and easy navigation it is really not suited IMHO. I'll try to keep the wiki page up to date.

BTW concerning setting up a build environment, perhaps it would be good to create a simple VM image with the tools needed at some point (but ATM it's probably too early for that).

Edited by Grain
Link to comment
Share on other sites

Guest fonix232
Well, I've been kind of busy with other stuff. Had 2.2.1 booting but no RIL of course. Currently compiling AOSP 2.2 release 1.1 (FRF91) modified for 2G VMSPLIT to do some comparison against ZTE's 2.2 build. ZTE are using FRF91 and there are plenty of changes in the framework.jar between FRF91 and the later Froyo releases making it unnecessary difficult to try to track their RIL modifications. However compiling Android takes a day or two on my virtual linux machine (running on a really slow host) so progress is painfully slow. But my main goal is to get a booting AOSP 2.2 and then try to get the RIL working. I do not bother with wifi, bluetooth etc for now.

Btw, the modifications isn't as complex as it might look but I guess on 2.3 it may need more work.

Compare prelink-linux-arm.map from Codeaurora (using a 2.2 branch that has the -2G version of the .map file) with the prelink-linux-arm.map that is in the build you are compiling. If they are identical then they you can just replace the prelink-linux-arm.map with the -2G version and then change the two lines in prelinkmap.c:

#define PRELINK_MIN 0x90000000

#define PRELINK_MAX 0xBFFFFFFF

To:

#define PRELINK_MIN 0x50000000

#define PRELINK_MAX 0x6FFFFFFF

On the other hand if the the original prelink-linux-arm.map is not identical between 2.2 and 2.3 then it gets a bit more compilcated.

By the way, what is the difference between VMSPLIT2G and VMSPLIT3G? I mean, what does the second one the first doesn't? I guess it has nothing to do with the 3G connections, at least it won't limit the speed and access (speedtests say that), but then, what?

Link to comment
Share on other sites

Fonix, please cut back a bit when quoting.

VMSPLIT_xG is a kernel option that configures virtual address space layout. 2G means 2GB userspace, 2GB kernel space. See arch/arm/Kconfig for help (arch/x86/Kconfig has better help text but I don't know if that also applies to ARM). This has nothing to do with mobile standards. ;)

Edited by Grain
Link to comment
Share on other sites

Guest fonix232
Fonix, please cut back a bit when quoting.

VMSPLIT_xG is a kernel option that configures virtual address space layout. 2G means 2GB userspace, 2GB kernel space. See arch/arm/Kconfig for help (arch/x86/Kconfig has better help text but I don't know if that also applies to ARM). This has nothing to do with mobile standards. ;)

Thank you for the explanation ;)

But then, could we build a VMSPLIT_1G kernel too? That would require even less memory (and as the Android kernel is very small, it would be even better).

Link to comment
Share on other sites

What you would need is to setup your debug environment DDMS etc, then hook up your phone add a breakpoint somewhere like the option to connect to a selected mobile network and follow what happens, see where it fails, then do the same on the zte framework.

There's also some static strace for Android available. Attaching that to Phone.apk and/or rild will probably also be interesting.

could we build a VMSPLIT_1G kernel too?

Please read the VMSPLIT docs I indicated, or the wiki page. Changing VMSPLIT from the ZTE default also breaks loading the binary-only kernel modules.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.