34 replies to this topic

[tcpaulh]

kallt_kaffe, on Jan 24 2011, 14:33, said:

Btw, I haven't come that far yet but I suppose I will need to solve the 180 degree rotation issue when/if I get that far. How did you get around that problem? Did you modify PhoneWindowManager.java?

I think it was surfaceflinger

[hecatae]

rjm2k, on Jan 24 2011, 16:16, said:

..

https://github.com/j...rancisco-kernel

https://github.com/j...5329c740474eff5

[hecatae]

fonix232, on Jan 23 2011, 11:39, said:

From the SDK you can't create a ROM. It is for SOFTWARE (application) development!
You need to download and compile the Android Source code yourself (for that you need Ubuntu x64, read the Android Source page for details).
But, you need a lot of work to build everything right. First of all, setting up the device tree isn't the easiest thing to do.

6.) Compiling Android 2.3.1
To build a final release on a 32bit machine, we must modify some files and use the target option "user" (default is "eng", which is only a debug build for the emulator).
Attention
following code must be run in root of your repo:

source build/envsetup.sh
find . -name '*.mk' | xargs sed -i 's/-m64//g'
export TARGET_BUILD_VARIANT=user
lunch
make

http://forum.xda-dev...mp;postcount=10

Quote

it is also needed to comment a line in /build/core/main.mk for stop error

$(warning ************************************************** **********)
$(warning You are attempting to build on a 32-bit system.)
$(warning Only 64-bit build environments are supported beyond froyo/2.2.)
$(warning ************************************************** **********)
#$(error stop) <--just add #

Edited by hecatae, 24 January 2011 - 07:03 PM.

[fonix232]

hecatae, on Jan 24 2011, 21:55, said:

6.) Compiling Android 2.3.1
To build a final release on a 32bit machine, we must modify some files and use the target option "user" (default is "eng", which is only a debug build for the emulator).
Attention
following code must be run in root of your repo:

source build/envsetup.sh
find . -name '*.mk' | xargs sed -i 's/-m64//g'
export TARGET_BUILD_VARIANT=user
lunch
make

http://forum.xda-dev...mp;postcount=10

I haven't been into this build-stuff too much, so I wasn't looking for a solution (and I'm using x64 Ubuntu any ways ) that's why I wrote my last info from Cyanogen. That time there were no patch

[hecatae]

fonix232, on Jan 24 2011, 19:11, said:

I haven't been into this build-stuff too much, so I wasn't looking for a solution (and I'm using x64 Ubuntu any ways ) that's why I wrote my last info from Cyanogen. That time there were no patch

just hoping all the people who only have 32 bit cpus realise they can get on board with development.

has anyone released a gingerbread build based on codeaurora yet, want to see if it boots

[Tom G]

kallt_kaffe, on Jan 25 2011, 01:33, said:

Seems like a good idea to switch to Code Aurora then. I'm using the JJ boot.img so I should have the /sbin/usbconfig in place but I didn't add the USB device id line in build.prop so I suppose it might not work without it.

However with since I'm not using a kernel compiled with 3G vmsplit it's propably the main cause for it not to boot. Oh, well...

Btw, I haven't come that far yet but I suppose I will need to solve the 180 degree rotation issue when/if I get that far. How did you get around that problem? Did you modify PhoneWindowManager.java?

The devid in build.prop doesn't matter. If the boot image is good but you have the wrong VMSPLIT you should see the device with 'adb devices' but shell and logcat will fail with a linking problem (shell might work).

The rotation problem is fixed.

diff --git a/libs/surfaceflinger/SurfaceFlinger.cpp b/libs/surfaceflinger/SurfaceFlinger.cpp
index b9ab1c0..9b0dafe 100644
--- a/libs/surfaceflinger/SurfaceFlinger.cpp
+++ b/libs/surfaceflinger/SurfaceFlinger.cpp
@@ -1883,16 +1883,16 @@ void GraphicPlane::setDisplayHardware(DisplayHardware *hw)
 
	 // initialize the display orientation transform.
	 // it's a constant that should come from the display driver.
-	int displayOrientation = ISurfaceComposer::eOrientationDefault;
+	int displayOrientation = ISurfaceComposer::eOrientation180;
	 char property[PROPERTY_VALUE_MAX];
	 if (property_get("ro.sf.hwrotation", property, NULL) > 0) {
		 //displayOrientation
		 switch (atoi(property)) {
		 case 90:
-			displayOrientation = ISurfaceComposer::eOrientation90;
+			displayOrientation = ISurfaceComposer::eOrientation270;
			 break;
		 case 270:
-			displayOrientation = ISurfaceComposer::eOrientation270;
+			displayOrientation = ISurfaceComposer::eOrientation90;
			 break;
		 }
	 }

This isn't the greatest way to doing it. It should be switchable from the device config, but it is basically what is needed. It needs some #ifdef's to choose normal or inverted. If your code is only used for devices with inverted screens then this is fine.

Edited by Tom G, 24 January 2011 - 09:29 PM.

[kallt_kaffe]

Tom G, on Jan 24 2011, 22:25, said:

The devid in build.prop doesn't matter. If the boot image is good but you have the wrong VMSPLIT you should see the device with 'adb devices' but shell and logcat will fail with a linking problem (shell might work).

The rotation problem is fixed.

diff --git a/libs/surfaceflinger/SurfaceFlinger.cpp b/libs/surfaceflinger/SurfaceFlinger.cpp
index b9ab1c0..9b0dafe 100644
--- a/libs/surfaceflinger/SurfaceFlinger.cpp
+++ b/libs/surfaceflinger/SurfaceFlinger.cpp
@@ -1883,16 +1883,16 @@ void GraphicPlane::setDisplayHardware(DisplayHardware *hw)
 
	 // initialize the display orientation transform.
	 // it's a constant that should come from the display driver.
-	int displayOrientation = ISurfaceComposer::eOrientationDefault;
+	int displayOrientation = ISurfaceComposer::eOrientation180;
	 char property[PROPERTY_VALUE_MAX];
	 if (property_get("ro.sf.hwrotation", property, NULL) > 0) {
		 //displayOrientation
		 switch (atoi(property)) {
		 case 90:
-			displayOrientation = ISurfaceComposer::eOrientation90;
+			displayOrientation = ISurfaceComposer::eOrientation270;
			 break;
		 case 270:
-			displayOrientation = ISurfaceComposer::eOrientation270;
+			displayOrientation = ISurfaceComposer::eOrientation90;
			 break;
		 }
	 }

This isn't the greatest way to doing it. It should be switchable from the device config, but it is basically what is needed. It needs some #ifdef's to choose normal or inverted. If your code is only used for devices with inverted screens then this is fine.

Many thanks for your help, do you have a BoardConfig.mk with all all the wifi stuff and other things setup? How far have you got with compling Android for the blade? My first goal is to get something to boot so that I also could start having a look at getting the RIL working. I haven't looked much at it so far but I'm pretty sure an important part of the integration is hidden within Phone.apk and the extra .jar files in /system/framework. Have anyone tried just signing Phone.apk from the Chinese or Japanese build with AOSP certs, grab the .jar files and libcm.so + libril-qc-1.so and put it into an AOSP/CAF compiled 2.2?

Deleted my AOSP repo before I had a "DOH!"-moment where I relealized I could have easily ported 2G prelink changes over to it so it took a while to sync the Code Aurora repo but it's currently compiling. Will take a while though since my machine is rather slow.

However I think I now know, why I didn't even get my adb working on the first attempt. I'm using my jellyfish boot.img and doesn't start any services until userinit.sh has set the filesystem.ready property and setprop uses toolbox and toolbox propably fails due to the 3G prelink setup so adb never got started.

[Tom G]

kallt_kaffe, on Jan 25 2011, 19:14, said:

Many thanks for your help, do you have a BoardConfig.mk with all all the wifi stuff and other things setup? How far have you got with compling Android for the blade? My first goal is to get something to boot so that I also could start having a look at getting the RIL working. I haven't looked much at it so far but I'm pretty sure an important part of the integration is hidden within Phone.apk and the extra .jar files in /system/framework. Have anyone tried just signing Phone.apk from the Chinese or Japanese build with AOSP certs, grab the .jar files and libcm.so + libril-qc-1.so and put it into an AOSP/CAF compiled 2.2?

Deleted my AOSP repo before I had a "DOH!"-moment where I relealized I could have easily ported 2G prelink changes over to it so it took a while to sync the Code Aurora repo but it's currently compiling. Will take a while though since my machine is rather slow.

However I think I now know, why I didn't even get my adb working on the first attempt. I'm using my jellyfish boot.img and doesn't start any services until userinit.sh has set the filesystem.ready property and setprop uses toolbox and toolbox propably fails due to the 3G prelink setup so adb never got started.

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

[rjm2k]

Tom G, on Jan 25 2011, 11:15, said:

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

can you provide some instructions on which tag you used and generally getting a basic build up and running?  each dev seems to have to spend time re-inventing the wheel in order to get the ball rolling rather than being able to concentrate on the real issues such as ril.
thanks

[fonix232]

Tom G, on Jan 25 2011, 14:15, said:

I have most things working (and have had for months) although I haven't done a lot of testing. I have issues with egl. The camera doesn't work. RIL doesn't work. I haven't really looked at the egl and camera problems as without RIL the rest doesn't really matter. I will look at put my device config on github.

For camera and EGL, you need the specific camera and egl so libraries (proprietary files like on HTC) copied into your build, and also some modifications to the build system too (to build the AOSP source for the specified hardware).

By the way my site is up again, so you can freely discuss there (highly moderated, anyone who is working on it and contacts me in PM here can be a moderator to assure everything will be clean).
http://fonix232.co.c...-ril-reversing/

[hecatae]

http://www.flickr.co...man/5273408519/

found this picture, anyone know the source?

[IronDoc]

hecatae, on Jan 25 2011, 18:05, said:

http://www.flickr.co...man/5273408519/

found this picture, anyone know the source?

Yeah Tom G (I think) had a vaguely working gingerbread. Very slow and no ril among other things.

[hecatae]

IronDoc, on Jan 25 2011, 20:07, said:

Yeah Tom G (I think) had a vaguely working gingerbread. Very slow and no ril among other things.

got to same point, looks pretty though.

[hecatae]

just occurred to me that Stackbladroid is built on AOSP 2.2.1

http://android.modac...-san-francisco/

I wont be able to build a new kernel til later, can someone have a go and post a new boot.img based on the new source from

https://github.com/Z...TE-BLADE-2.6.32

[fonix232]

hecatae, on Jan 28 2011, 21:33, said:

just occurred to me that Stackbladroid is built on AOSP 2.2.1

http://android.modac...-san-francisco/

I wont be able to build a new kernel til later, can someone have a go and post a new boot.img based on the new source from

https://github.com/Z...TE-BLADE-2.6.32

It is just a partial build, not a whole 2.2.1 AOSP compile.