OESF Portables Forum

Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Android => Topic started by: Mrflying on February 18, 2008, 10:38:28 pm

Title: Porting M5rc14 To Real Hardware
Post by: Mrflying on February 18, 2008, 10:38:28 pm
Hi everyone:
Does anyone can help me? Thanks in advance.
I'm now working on porting m5rc14 to our platform.
I meet 2 problems:

1) when system starts, console seem almost hangs. and process
system_server
occupies 99% of CPU time.

This is my logcat:
W/AudioFlinger(  557): Using stubbed audio hardware. No sound will be
produced.
I/AudioFlinger(  557): AudioFlinger's main thread ready to run.
I/ServiceManager(  539): ServiceManager: addService(AudioFlinger,
0x133f8)
I/sysproc (  557): System server: starting Android runtime.
I/sysproc (  557): System server: starting Android services.
I/SystemServer(  557): Entered the Android system server!
I/sysproc (  557): System server: entering thread pool.
D/TouchDex(  557): TouchDex parent waiting for pid=580 (timeout=36.4s)
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
D/AudioFlinger(  557): Audio hardware entering standby
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
I/ServiceManager(  539): ServiceManager: unable to find service
activity
I/runtime (  539): Still waiting for activity manager...
I/ServiceManager(  539): ServiceManager: waiting for service activity
E/TouchDex(  557): timed out waiting for 580; kill(0) returns 0

It seems services don't respond to SeviceManager, it doesn't happen on
previous version

2). There's nothing appear on the screen. (screen is turned to black,
it doesn't happen on previous version, too)

m3rc37 system runs well on our platform with new released kernel.
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 19, 2008, 03:32:56 am
Did you create a new kernel with latest Google patches (http://android.googlecode.com/files/linux-2.6.23-android-m5-rc14.tar.gz) applied?
If not, then don't bother to try, it won't work on the kernel used in the previous release, since they made some major changes.
Title: Porting M5rc14 To Real Hardware
Post by: jpmatrix on February 19, 2008, 10:50:02 am
Quote from: cortez
Did you create a new kernel with latest Google patches (http://android.googlecode.com/files/linux-2.6.23-android-m5-rc14.tar.gz) applied?
If not, then don't bother to try, it won't work on the kernel used in the previous release, since they made some major changes.

is there the same for kernel 2.6.24 ? i cannot find it...
would someone (2orO ?  compile it for us please ?
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on February 19, 2008, 09:47:52 pm
Quote from: Mrflying
2). There's nothing appear on the screen. (screen is turned to black,
it doesn't happen on previous version, too)

Same for Angstrom Zaurus. Just blank screen, nothing displayed.

I don't think this would work though, give a try to copy /dev/fb0 to /dev/graphics/fb0 and chmod 666. The emulator is working like that.

Android Zaurus: Confusing issue of Android m5_rc14
http://androidzaurus.seesaa.net/article/84934031.html (http://androidzaurus.seesaa.net/article/84934031.html)
Title: Porting M5rc14 To Real Hardware
Post by: Mrflying on February 21, 2008, 04:15:09 am
Quote from: Android Zaurus
Quote from: Mrflying
2). There's nothing appear on the screen. (screen is turned to black,
it doesn't happen on previous version, too)

Same for Angstrom Zaurus. Just blank screen, nothing displayed.

I don't think this would work though, give a try to copy /dev/fb0 to /dev/graphics/fb0 and chmod 666. The emulator is working like that.

Android Zaurus: Confusing issue of Android m5_rc14
http://androidzaurus.seesaa.net/article/84934031.html (http://androidzaurus.seesaa.net/article/84934031.html)


I've tried copy a binary to /dev/graphics/fb0, and it can work. My framebuffer driver works well
But Android still not print something on the screem. It semms google make some  modification on
SufaceFlinger serives.
As I trace the system bootup, it uses mmap to map /dev/graphics/fb0 to memory.

BTW, the boot very slow problem is solved, it's because my flash driver I/O thread's priority is too low.
Now system can boot successfully, but still have nothing on screen
Title: Porting M5rc14 To Real Hardware
Post by: speculatrix on February 21, 2008, 05:57:08 pm
Quote from: Mrflying
I've tried copy a binary to /dev/graphics/fb0, and it can work. My framebuffer driver works well
But Android still not print something on the screem. It semms google make some  modification on
SufaceFlinger serives.
As I trace the system bootup, it uses mmap to map /dev/graphics/fb0 to memory.

how did you copy it?

you need to do "cp -prd /dev/XXX /dev/graphics/" to copy the device, or, better yet, use "mknod" instead!
Title: Porting M5rc14 To Real Hardware
Post by: Mrflying on February 21, 2008, 10:04:20 pm
Quote from: speculatrix
Quote from: Mrflying
I've tried copy a binary to /dev/graphics/fb0, and it can work. My framebuffer driver works well
But Android still not print something on the screem. It semms google make some  modification on
SufaceFlinger serives.
As I trace the system bootup, it uses mmap to map /dev/graphics/fb0 to memory.

how did you copy it?

you need to do "cp -prd /dev/XXX /dev/graphics/" to copy the device, or, better yet, use "mknod" instead!

I use android's original init, and it creates device node automatically; /dev/graphics/fb0 (29, 0) is alreadly there
when system boot-up.
I mean I copy a binary image into the fb device, and there's something shown on screen
And I also use mmap() to map the fb device, write something, and it works.
My framebuffer driver seems works fine.
Title: Porting M5rc14 To Real Hardware
Post by: Mrflying on February 21, 2008, 10:12:46 pm
Quote from: cortez
Did you create a new kernel with latest Google patches (http://android.googlecode.com/files/linux-2.6.23-android-m5-rc14.tar.gz) applied?
If not, then don't bother to try, it won't work on the kernel used in the previous release, since they made some major changes.

Ya. I've updated to newest kernel. Google do minor modify on new kernel. The major change is the binder driver.
Title: Porting M5rc14 To Real Hardware
Post by: jpmatrix on February 22, 2008, 02:35:11 pm
Quote from: Mrflying
Quote from: cortez
Did you create a new kernel with latest Google patches (http://android.googlecode.com/files/linux-2.6.23-android-m5-rc14.tar.gz) applied?
If not, then don't bother to try, it won't work on the kernel used in the previous release, since they made some major changes.

Ya. I've updated to newest kernel. Google do minor modify on new kernel. The major change is the binder driver.

so is it working now?
Title: Porting M5rc14 To Real Hardware
Post by: speculatrix on February 25, 2008, 05:51:31 pm
very much please to have even a partial version working!!!
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 26, 2008, 02:51:58 am
Quote from: speculatrix
very much please to have even a partial version working!!!
You mean you don't even care that the screen is black all the time?  
I've created an installable image from the new SDK. From what I see in the traces Android starts normally. It's just that there's nothing displayed...
Title: Porting M5rc14 To Real Hardware
Post by: speculatrix on February 26, 2008, 07:37:36 am
Quote from: cortez
Quote from: speculatrix
very much please to have even a partial version working!!!
You mean you don't even care that the screen is black all the time?  
I've created an installable image from the new SDK. From what I see in the traces Android starts normally. It's just that there's nothing displayed...

if you tap around on the screen, can you tell if something's happening by looking at debug output and any processes/threads running?
Title: Porting M5rc14 To Real Hardware
Post by: zaurick on February 26, 2008, 11:48:32 am
Quote from: cortez
Quote from: speculatrix
very much please to have even a partial version working!!!
You mean you don't even care that the screen is black all the time?  
I've created an installable image from the new SDK. From what I see in the traces Android starts normally. It's just that there's nothing displayed...

Hi,

Have you got some IOCTL errors about /dev/fb or /dev/graphics in the debug output.
The last time i've got a black screen problem when porting an appli, it was because of the use of a double framebuffer.
The framebuffer was mmaped in ram with the size of two screens and it started with the second screen !!!
and then tried to switch the base address of the visible window with "FBIOPAN" IOCTL (don't work with our driver).
Maybe It's not our actual problem, but i have no other idea.

All of you make a great work about porting android !!!
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 26, 2008, 12:36:23 pm
Quote from: zaurick
Quote from: cortez
Quote from: speculatrix
very much please to have even a partial version working!!!
You mean you don't even care that the screen is black all the time?  
I've created an installable image from the new SDK. From what I see in the traces Android starts normally. It's just that there's nothing displayed...

Hi,

Have you got some IOCTL errors about /dev/fb or /dev/graphics in the debug output.
The last time i've got a black screen problem when porting an appli, it was because of the use of a double framebuffer.
The framebuffer was mmaped in ram with the size of two screens and it started with the second screen !!!
and then tried to switch the base address of the visible window with "FBIOPAN" IOCTL (don't work with our driver).
Maybe It's not our actual problem, but i have no other idea.

All of you make a great work about porting android !!!

I see no IOCTL errors of significance. All devices are created nicely when running the /init executable, including /dev/graphics/fb0. This is no double framebuffer as far as I can tell. All services start successfully (I don't see the errors as described in the first post).

The main difference between Qemu emulator and Zaurus seems to be the supported OpenGL options. From what I remember, the Zaurus doesn't support page flipping.
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on February 26, 2008, 08:32:55 pm
My guess for now. Let the Android use drivers/video/pxafb.c not platform driver in arch/arm/mach-pxa. I'm working on another project for now and my Zaurus is configured for m3 Android. Later I'd like to try to build the kernel with CONFIG_FB_PXA=m and see what happens.

By the way, I found this wiki is very informational.

Android on OMAP - Embeddedlinux
http://elinux.org/Android_on_OMAP (http://elinux.org/Android_on_OMAP)
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 27, 2008, 04:40:38 am
Quote from: Android Zaurus
My guess for now. Let the Android use drivers/video/pxafb.c not platform driver in arch/arm/mach-pxa. I'm working on another project for now and my Zaurus is configured for m3 Android. Later I'd like to try to build the kernel with CONFIG_FB_PXA=m and see what happens.

By the way, I found this wiki is very informational.

Android on OMAP - Embeddedlinux
http://elinux.org/Android_on_OMAP (http://elinux.org/Android_on_OMAP)

Setting CONFIG_FB_PXA=m changes the behavior indeed... it turns the screen to white instead of black  
To be precise, the screen is white all the time, not only when switching to graphics mode, but also at startup and in console.
So, this seems not to be the solution either.

Look at the interesting part (sorry, it's a bit long) in the trace output below. It says "page flipping not supported (yres_virtual=640, requested=1280". I think this is the problem we're facing.

Code: [Select]
02:53:16.651373 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"SurfaceFlinger\'s main thread ready to run. Initializing graphics H/W...\", 72}], 3) = 88
02:53:16.655210 open("/dev/tty0", O_RDWR|O_SYNC|O_LARGEFILE) = 20
02:53:16.657091 ioctl(20, VT_GETSTATE, 0x43145e92) = 0
02:53:16.658640 ioctl(20, VIDIOC_QUERYCAP or VT_OPENQRY, 0x43145e9c) = 0
02:53:16.660192 ioctl(20, VIDIOC_G_COMP or VT_ACTIVATE, 0x2) = 0
02:53:16.676678 ioctl(20, VIDIOC_S_COMP or VT_WAITACTIVE, 0x2) = 0
02:53:16.678243 close(20)               = 0
02:53:16.679822 open("/dev/tty0", O_RDWR|O_SYNC|O_LARGEFILE) = 20
02:53:16.706815 ioctl(20, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
02:53:16.713156 ioctl(20, SNDCTL_TMR_START or TCSETS, {B38400 opost -isig -icanon -echo ...}) = 0
02:53:16.717340 ioctl(20, VIDIOC_ENUM_FMT or VT_SETMODE, 0x43145e8a) = 0
02:53:16.720475 sigaction(SIGUSR2, {0xacd132d1, [], 0}, NULL, 0xc4268) = 0
02:53:16.726764 sigaction(SIGSYS, {0xacd13335, [], 0}, NULL, 0xc4268) = 0
02:53:16.730505 sigprocmask(SIG_UNBLOCK, [USR2 SYS], NULL) = 0
02:53:16.733692 ioctl(20, KDSETMODE, 0x1) = 0
02:53:16.737202 open("libagl.so", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
02:53:16.739228 open("/system/lib/libagl.so", O_RDONLY|O_LARGEFILE) = 21
02:53:16.741405 lseek(21, -8, SEEK_END) = 96024
02:53:16.742915 read(21, "\\300\254PRE ", 8) = 8
02:53:16.780406 mmap2(0xacc00000, 98304, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 21, 0) = 0xacc00000
02:53:16.782040 close(21)               = 0
02:53:16.835776 mprotect(0xacc00000, 94208, PROT_READ|PROT_EXEC) = 0
02:53:16.838281 writev(4, [{"\5", 1}, {"\", 1}, {" not found in libagl.so\", 53}], 3) = 55
02:53:16.841546 access("/dev/hw3d", R_OK) = -1 ENOENT (No such file or directory)
02:53:16.843565 writev(4, [{"\5", 1}, {"\", 1}, {"can\'t access 3D hardware (No such file or directory)\", 53}], 3) = 55
02:53:16.847058 brk(0x142000)           = 0x142000
02:53:16.848999 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"EGL informations:\", 18}], 3) = 34
02:53:16.851889 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"# of configs : 4\", 17}], 3) = 33
02:53:16.854875 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"vendor    : Google Inc.\", 24}], 3) = 40
02:53:16.857839 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"version   : 1.2 Android META-EGL\", 33}], 3) = 49
02:53:16.860992 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"extensions: EGL_ANDROID_swap_rectangle EGL_ANDROID_copy_front_to_back EGL_ANDROID_get_render_buffer_address EGL_ANDROID_query_string_config\", 140}], 3) = 156
02:53:16.865904 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"ext/config: EGL_ANDROID_swap_rectangle EGL_ANDROID_copy_front_to_back EGL_ANDROID_get_render_buffer_address\", 108}], 3) = 124
02:53:16.870221 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"Client API: OpenGL ES\", 22}], 3) = 38
02:53:16.873291 open("/dev/graphics/fb0", O_RDWR|O_LARGEFILE) = 21
02:53:16.875388 ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0
02:53:16.876931 ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0
02:53:16.878477 ioctl(21, FBIOPUT_VSCREENINFO, 0x43145cfc) = 0
02:53:16.925453 writev(4, [{"\5", 1}, {"EGLDisplaySurface\", 18}, {"page flipping not supported (yres_virtual=640, requested=1280)\", 63}], 3) = 82
02:53:16.929119 ioctl(21, FBIOGET_VSCREENINFO, 0x43145cfc) = 0
02:53:16.930807 writev(4, [{"\4", 1}, {"EGLDisplaySurface\", 18}, {"using (fd=21)\nid           = PXA\nxres         = 480 px\nyres         = 640 px\nxres_virtual = 480 px\nyres_virtual = 640 px\nbpp          = 16\nr            = 11:5\ng            =  5:6\nb            =  0:5\n\", 200}], 3) = 219
02:53:16.967995 writev(4, [{"\4", 1}, {"EGLDisplaySurface\", 18}, {"width        = 51 mm (239.058823 dpi)\nheight       = 38 mm (427.789459 dpi)\nrefresh rate = 124.61 Hz\n\", 102}], 3) = 121
02:53:16.972517 ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0
02:53:16.974061 mmap2(NULL, 614400, PROT_READ|PROT_WRITE, MAP_SHARED, 21, 0) = 0x43146000
02:53:17.028820 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x431dc000
02:53:17.030696 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43273000
02:53:17.032605 brk(0x143000)           = 0x143000
02:53:17.034701 brk(0x145000)           = 0x145000
02:53:17.036760 brk(0x146000)           = 0x146000
02:53:17.038532 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"OpenGL informations:\", 21}], 3) = 37
02:53:17.041493 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"vendor    : Google Inc.\", 24}], 3) = 40
02:53:17.046048 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"renderer  : Android PixelFlinger 1.0\", 37}], 3) = 53
02:53:17.049257 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"version   : OpenGL ES-CM 1.0\", 29}], 3) = 45
02:53:17.052344 writev(4, [{"\4", 1}, {"SurfaceFlinger\", 15}, {"extensions: GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_draw_texture GL_OES_matrix_get GL_OES_query_matrix GL_ARB_te"..., 277}], 3) = 293
02:53:17.058395 access("/dev/hw3d", R_OK) = -1 ENOENT (No such file or directory)
02:53:17.060899 getpid()                = 2289
02:53:17.062402 getuid32()              = 0
02:53:17.063969 getpid()                = 2289
02:53:17.065639 open("/tmp/android-shared_heap.2289.0x145ab0", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 22
02:53:17.068031 ftruncate(22, 19660800) = 0
02:53:17.069588 mmap2(NULL, 19660800, PROT_READ|PROT_WRITE, MAP_SHARED, 22, 0) = 0x4330a000
02:53:17.071229 unlink("/tmp/android-shared_heap.2289.0x145ab0") = 0
02:53:17.073566 getpid()                = 2289
02:53:17.075242 open("/tmp/android-shared_heap.2289.0x145df8", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 23
02:53:17.077626 ftruncate(23, 4096)     = 0
02:53:17.079201 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, 23, 0) = 0x445ca000
02:53:17.080843 unlink("/tmp/android-shared_heap.2289.0x145df8") = 0
02:53:17.083728 open("/tmp/android-SurfaceFlingerSynchro", O_WRONLY|O_NONBLOCK|O_LARGEFILE) = 24
02:53:17.086224 brk(0x147000)           = 0x147000
02:53:17.088069 mmap2(0x10000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x445cb000
02:53:17.089681 mprotect(0x445cb000, 4096, PROT_NONE) = 0
02:53:17.091435 clone(child_stack=0x446caf80, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLO
E_DETACHED) = 2300
02:53:17.094168 mmap2(0x10000000, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x446cb000
02:53:17.097904 mprotect(0x446cb000, 4096, PROT_NONE) = 0
02:53:17.101337 clone(child_stack=0x447caf80, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLO
E_DETACHED) = 2301
02:53:17.108176 futex(0x140d98, FUTEX_WAKE, 2147483647)                = 1
02:53:17.115013 futex(0x140d94, FUTEX_WAKE, 1)              = 0
02:53:17.122600 read(15, "\", 4096) = 1
02:53:17.333882 futex(0x140c04, FUTEX_WAKE, 1) = 0
02:53:17.344042 futex(0x445ca004, FUTEX_WAKE, 2147483647) = 0
02:53:17.352317 writev(4, [{"\6", 1}, {"SurfaceFlinger\", 15}, {"GL error 0x0500\", 16}], 3) = 32
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on February 27, 2008, 05:39:33 am
Cortez,

Thanks for trying to make a module.

Quote from: cortez
It says "page flipping not supported (yres_virtual=640, requested=1280". I think this is the problem we're facing.

Gee. We need a double buffer capable driver. Means a bit of work to modify current pxafb driver code.
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 27, 2008, 07:10:59 am
Would it be possible to make the second page (the second mmap2 call) point to the same address as the first?
That would mean patching (or rebuilding if source is available) libagl.
Anyone know a good ARM disassembler that could be used to find the right spot?

Code: [Select]
02:53:16.967995 writev(4, [{"\4", 1}, {"EGLDisplaySurface\", 18}, {"width        = 51 mm (239.058823 dpi)\nheight       = 38 mm (427.789459 dpi)\nrefresh rate = 124.61 Hz\n\", 102}], 3) = 121
02:53:16.972517 ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0
02:53:16.974061 mmap2(NULL, 614400, PROT_READ|PROT_WRITE, MAP_SHARED, 21, 0) = 0x43146000
02:53:17.028820 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x431dc000
02:53:17.030696 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43273000
Title: Porting M5rc14 To Real Hardware
Post by: zaurick on February 27, 2008, 08:29:33 am
Quote from: cortez
Would it be possible to make the second page (the second mmap2 call) point to the same address as the first?
That would mean patching (or rebuilding if source is available) libagl.
Anyone know a good ARM disassembler that could be used to find the right spot?

Code: [Select]
02:53:16.967995 writev(4, [{"\4", 1}, {"EGLDisplaySurface\", 18}, {"width        = 51 mm (239.058823 dpi)\nheight       = 38 mm (427.789459 dpi)\nrefresh rate = 124.61 Hz\n\", 102}], 3) = 121
02:53:16.972517 ioctl(21, FBIOGET_FSCREENINFO, 0x43145d9c) = 0
02:53:16.974061 mmap2(NULL, 614400, PROT_READ|PROT_WRITE, MAP_SHARED, 21, 0) = 0x43146000
02:53:17.028820 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x431dc000
02:53:17.030696 mmap2(NULL, 618496, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x43273000

Can we try starting android in QVGA mode ?
In that mode 320*240 it will be possible to have a double buffer for screen.
I think that the requested value yres*2 is calculated from the actual résolution from FSCREENINFO like it work in tomtom navigation software.
Title: Porting M5rc14 To Real Hardware
Post by: speculatrix on February 27, 2008, 09:00:14 am
ask the angstrom kernel guy, (richard purdie?), he added a feature we needed when getting tomtom to run on it, so hopefully that would avoid any bodges that would come back to haunt us.
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 27, 2008, 10:43:39 am
I guess I need to adjust the default pxafb framebuffer code to see if this can be tweaked easily.
We'll see if this works  
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on February 27, 2008, 08:01:25 pm
Is there anyone who is familliar with OpenEZX?
http://www.openezx.org/ (http://www.openezx.org/)

Their wiki mentions double buffer support.http://wiki.openezx.org/CodeAnalysis (http://wiki.openezx.org/CodeAnalysis)

I looked around their svn, but I couldn't find paticullar patch or source code.
Title: Porting M5rc14 To Real Hardware
Post by: cortez on February 28, 2008, 04:09:44 pm
I did it, it works! The problem was the unsupported page flipping in the frame buffer.
More info later, it needs some more tweaking before I can upload a new image.
Check out my blog (http://www.omegamoon.com) for more info.
Title: Porting M5rc14 To Real Hardware
Post by: matthis on February 29, 2008, 09:12:09 am
>>More info later, it needs some more tweaking before I can upload a new image.
WOW~~! Looking forward to it!
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on March 02, 2008, 02:56:04 am
Today I implemented my version of double buffer and pan in pxafb. It works. m5_rc14 booted up on my Zaurus finally. My patch is very primitive. Any suggestions make it better are very welcome.

o Android Zaurus: m5_rc14 works on my Zaurus C3000 (http://androidzaurus.seesaa.net/article/87973048.html)

Cortez,
Is your keyboard working correctly? Something funny with mine. I can't navigate on the menu by cursor keys. It's like a jumping around.
Title: Porting M5rc14 To Real Hardware
Post by: zaurick on March 02, 2008, 05:36:20 am
Quote from: Android Zaurus
Today I implemented my version of double buffer and pan in pxafb. It works. m5_rc14 booted up on my Zaurus finally. My patch is very primitive. Any suggestions make it better are very welcome.

o Android Zaurus: m5_rc14 works on my Zaurus C3000 (http://androidzaurus.seesaa.net/article/87973048.html)

 It works for me too.
Just a litle thing in your patch, your panning function only toggle FB base adresse.
The result can be inverted.
Normaly the base adresse is calculated with the var.yoffset value from var_screeninfo.
I'm going to work on that !

Thanks !
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on March 02, 2008, 07:24:52 am
Quote from: zaurick
Normaly the base adresse is calculated with the var.yoffset value from var_screeninfo.
I'm going to work on that !

Big thanks from me. I'm not familliar with fb driver. Please make the patch better. I noticed that some long cycle flickerings while I tried a couple of times booting Android up. I guess I need exclusiveness to change DMA address.
Title: Porting M5rc14 To Real Hardware
Post by: matthis on March 02, 2008, 08:58:51 am
is touchscreen any better in this version?
Title: Porting M5rc14 To Real Hardware
Post by: cortez on March 02, 2008, 09:34:40 am
Quote from: Android Zaurus
Today I implemented my version of double buffer and pan in pxafb. It works. m5_rc14 booted up on my Zaurus finally. My patch is very primitive. Any suggestions make it better are very welcome.

o Android Zaurus: m5_rc14 works on my Zaurus C3000 (http://androidzaurus.seesaa.net/article/87973048.html)

Cortez,
Is your keyboard working correctly? Something funny with mine. I can't navigate on the menu by cursor keys. It's like a jumping around.

The cursor keys are working, no problems there.
Title: Porting M5rc14 To Real Hardware
Post by: zaurick on March 02, 2008, 03:46:15 pm
Quote from: Android Zaurus
Quote from: zaurick
Normaly the base adresse is calculated with the var.yoffset value from var_screeninfo.
I'm going to work on that !

Big thanks from me. I'm not familliar with fb driver. Please make the patch better. I noticed that some long cycle flickerings while I tried a couple of times booting Android up. I guess I need exclusiveness to change DMA address.

Can you try to replace your fb_pan _display portion of code with this one :
Code: [Select]
+static int pxafb_pan_display(struct fb_var_screeninfo *var, struct fb_info *info)
+{
+       struct pxafb_info *fbi = (struct pxafb_info *)info;
+               fbi->dmadesc_fbhigh_cpu->fsadr = fbi->screen_dma + (var->xres * var->yoffset * var->bits_per_pixel/8);
+       return 0;
+}

It work for me.
Title: Porting M5rc14 To Real Hardware
Post by: cortez on March 02, 2008, 03:51:45 pm
Quote from: matthis
is touchscreen any better in this version?

Seems to be the same, sometimes working, sometimes not.
Title: Porting M5rc14 To Real Hardware
Post by: speculatrix on March 02, 2008, 04:11:34 pm
I'm looking forward to being able to download this. I am happy to provide a mirror for the files if you need it.
Title: Porting M5rc14 To Real Hardware
Post by: Android Zaurus on March 03, 2008, 06:08:59 am
zaurick

Thanks for your tips. I guess I need to check the differences between fbi->fb.var and var.

Today I tried schedule_work() instead of changing DMA address at once. It seems OK. Flickering is gone.

o Android Zaurus: Improvement of double buffer (http://androidzaurus.seesaa.net/article/88123891.html)
Title: Porting M5rc14 To Real Hardware
Post by: zaurick on March 03, 2008, 09:02:36 am
Happy to hear that the project go ahead.

Could someone post his "android.patch" used over linux-rp-2.6.23 ?

I have some problems with mine.