234 replies to this topic

[rjm2k]

There now seems to be yet another repo for this https://github.com/H...evice_zte_blade , looks more uptodate that r3peks but haven't tried it yet.  I wish the devs would get together and grant others rights to their git rather than everyone creating a seperate copy.

[hecatae]

rjm2k, on Jan 31 2011, 12:40, said:

There now seems to be yet another repo for this https://github.com/H...evice_zte_blade , looks more uptodate that r3peks but haven't tried it yet.  I wish the devs would get together and grant others rights to their git rather than everyone creating a seperate copy.

based on z71, aka ZTE x876.

builds does not boot

[Cirno]

Same here, couldn't get it to boot; checking various things....

[Aquilo]

Cirno, on Feb 1 2011, 08:17, said:

Same here, couldn't get it to boot; checking various things....

Looks like the partition sizes & kernel base address are wrong.

[kallt_kaffe]

rjm2k, on Jan 30 2011, 12:23, said:

It's slow and nothing much works, not even wifi and it only has 162meg because of the vmsplit thing but it's a start.  I'm wondering if it's worth merging this device tree into code aurora rather than cm7 for the extra memory.

Here's what you need to change for 2G vmsplit:
https://www.codeauro...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.

Edited by kallt_kaffe, 01 February 2011 - 08:27 AM.

[rjm2k]

kallt_kaffe, on Feb 1 2011, 08:27, said:

Here's what you need to change for 2G vmsplit:
https://www.codeauro...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?

[Aquilo]

rjm2k, on Feb 1 2011, 09:01, said:

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?

[kallt_kaffe]

rjm2k, on Feb 1 2011, 10:01, said:

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, 01 February 2011 - 01:10 PM.

[rjm2k]

kallt_kaffe, on Feb 1 2011, 13:04, said:

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.

[Grain]

rjm2k, on Feb 1 2011, 17:54, said:

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:

• ZTE Blade Community ROM Wiki Page

- 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, 02 February 2011 - 12:05 PM.

[fonix232]

kallt_kaffe, on Feb 1 2011, 16:04, said:

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?

[Grain]

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, 02 February 2011 - 04:12 PM.

[fonix232]

Grain, on Feb 2 2011, 19:03, said:

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).

[Grain]

rjm2k, on Jan 13 2011, 10:48, said:

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.

fonix232 said:

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.

[Grain]

Seems Tom G had some success with RIL: new cyanogenmod-for-blade thread