colorant wrote:
1. If the /dev/binder device node is missing or having wrong minor
number, the android display comes up properly.
2. If the /dev/binder device node is created properly by making use of
the information from the "/proc/misc", then the "/system/bin/runtime"
spits out the following messages and then hangs for ever.
binder_open: 276:276
binder_mmap: 276 40000000-40400000 (4096 K) vma 71 pagep 5f
binder_open: 278:278
binder_mmap: 278 42648000-42a48000 (4096 K) vma 71 pagep 5f
In fact the whole system hangs :-(
Currently my platform on which this whole activity is being carried
out has only 64MB RAM and I presume the mmap calls may be failing due
to some memory crunch.
It would be great if you could share your thoughts on the above given
observations.
Warm Regards,
Anil
Hi Anil
I guess there still is some thing we don't handle well in the vmalloc
related functions.
My output messages after the first two binder_mmap is a binder_flush
as following:
binder_open: 500:500
binder_mmap: 500 40008000-40408000 (4096 K) vma 71 pagep 5f
binder_open: 510:510
binder_mmap: 510 42650000-42a50000 (4096 K) vma 71 pagep 5f
binder_flush: 510 woke 3 threads
binder_open: 537:537
binder_mmap: 537 42650000-42a50000 (4096 K) vma 71 pagep 5f
And three more mmap later, the main screen is shown.
However I also got a mmap fail :
binder_open: 552:552
binder_mmap: 552 42650000-42a50000 (4096 K) vma 71 pagep 5f
binder_open: 554:554
binder_mmap: 554 42650000-42a50000 (4096 K) vma 71 pagep 5f
binder_open: 498:507
binder_mmap: 498 40108000-40508000 (4096 K) vma 71 pagep 5f
allocation failed: out of vmalloc space - use vmalloc=<size> to increase
size.
binder_mmap: 498 40108000-40508000 get_vm_area failed -12
And I remember that I had to modify some vmalloc related functions to
make the binder driver working happy with my 2.6.21 kernel. I think
there might be something I miss to modify which is changed from 2.6.21
kernel to 2.6.23 kernel but can be compiled without problem.
Yes, I think you are right here. Using 2.6.23 on OSK without touching
any vmalloc related stuff I don't see anything like this. So most
probably something with the changes you mention.
Dirk
Btw: After hacking this page flipping issue, m5-rc14 basically starts
on OSK. Start takes some time, and it isn't really usable. So more or
less a "proof of concept" for 32MB systems ;). But it starts.
http://elinux.org/Android_on_OMAP
However, since I just want to verify the possiblility of porting the
android to my platform and don't want to really make it perfect for now,
So I don't want to study further at this point, I will just wait until
the whole system's src is available so that the problem hunting job is
more easy to do.
And , Just my guess, It might be helpful to read the emulator's src code
? Since the goldfish is base on it, and I can see that some hardware
releated code, when I trace it down, it finally direct to a register
reading or writing without any clue of what is going on.
Rayomnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
