I too searched through the source for /dev/pmem and found this section
in system/core/init/devices.c
{ "/dev/pmem", 0660, AID_SYSTEM, AID_GRAPHICS, 0 },
{ "/dev/pmem_gpu", 0660, AID_SYSTEM, AID_GRAPHICS, 1 },
{ "/dev/pmem_adsp", 0660, AID_SYSTEM, AID_AUDIO, 1 },
{ "/dev/pmem_camera", 0660, AID_SYSTEM, AID_CAMERA, 1 },
Looks like 3 are enabled and 1 is disabled. I am going to disable the
other 3, re-compile and see if that will get us past the surface
flinger problem.
On Nov 12, 2:54 pm, NickDG <[EMAIL PROTECTED]> wrote:
> Boot log is great! Thanks for the work.
>
> Surface flinger was the first service to die before they all went
> down.
>
> This section has some errors that maybe caused it to die?
>
> SurfaceFlinger
> SurfaceFlinger is starting
> MemoryHeapBase
> error opening /dev/pmem: No such file or directory
> SurfaceFlinger
> SurfaceFlinger's main thread ready to run. Initializing graphics H/
> W...
> SurfaceFlinger
> Couldn't open /sys/android_power/wait_for_fb_sleep or /sys/
> android_power/wait_for_fb_wake
> GLLogger
> couldn't load <libhgl.so> library (Cannot find library)
> SurfaceFlinger
> EGL informations:
> SurfaceFlinger
> # of configs : 4
> SurfaceFlinger
> vendor : Android
> SurfaceFlinger
> version : 1.2 Android META-EGL
> SurfaceFlinger
> extensions: EGL_ANDROID_query_string_config EGL_ANDROID_swap_rectangle
> SurfaceFlinger
> ext/config: EGL_ANDROID_swap_rectangle
> SurfaceFlinger
> Client API: OpenGL ES
> EGLDisplaySurface
> using (fd=21)
> id = PXA
> xres = 320 px
> yres = 320 px
> xres_virtual = 320 px
> yres_virtual = 640 px
> bpp = 16
> r = 11:5
> g = 5:6
> b = 0:5
> EGLDisplaySurface
> width = 51 mm (159.372543 dpi)
> height = 38 mm (213.894730 dpi)
> refresh rate = 57.78 Hz
> SurfaceFlinger
> OpenGL informations:
> SurfaceFlinger
> vendor : Android
> SurfaceFlinger
> renderer : Android PixelFlinger 1.0
> SurfaceFlinger
> version : OpenGL ES-CM 1.0
> SurfaceFlinger
> 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_texture_compression
> GL_ARB_texture_non_power_of_two GL_ANDROID_direct_texture
> GL_ANDROID_user_clip_plane GL_ANDROID_vertex_buffer_object
> GL_ANDROID_generate_mipmap
>
> We are seeing pmem pop up again. Trying to access memory that doesn't
> exist on the system maybe? Can we rem it out in the source?
>
> - Nick
>
> On Nov 12, 10:29 am, Strags <[EMAIL PROTECTED]> wrote:
>
> > I'm using the debian/lenny rootfs fromhttp://hackndev.com/node/212.
>
> > I've built android, and copied the root filesystem into /android_root
> > on /.
>
> > I boot debian, ssh in (over USB), and then:
>
> > chroot android_root ./init
>
> > This brings up the same messages that you're getting, and then the
> > flashing robot. At this point, I can (using another shell), go into /
> > android_root/dev/log, and look at a bunch of interesting log messages.
>
> > strings main
>
> > Unfortunately, the boot process seems to be continually dying and
> > restarting:
>
> >http://codepuppies.com/~ben/treo/bootlog.txt
>
> > On Nov 12, 1:37 am, NickDG <[EMAIL PROTECTED]> wrote:
>
> > > Update: Now I am getting this error.
>
> > > A N D R O I D init: Unable to open persistent property directory /data/
> > > property errno: 2
> > > init: cannot find `/system/bin/playmp3` disabling `bootsound`
> > > sh: can't access tty; job control turned off
> > > # warning `rild` uses 32-bit capabilities (legacy support in use)
>
> > > On Nov 11, 10:33 pm, NickDG <[EMAIL PROTECTED]> wrote:
>
> > > > Hey Alex,
>
> > > > Thanks for the kernel. I tried and successfully got it to boot.
>
> > > > It worked with 1944. I used the following settings
>
> > > > root=/dev/mmcblk0p2 mem=64m rootdelay=1 init=/init
>
> > > > I get a kernel panic when it tried to execute init. Permissions look
> > > > right. hmmm...
>
> > > > I've been keeping my eye on the Centro topic at Hackndev. Sorry I
> > > > haven't posted in there yet!
>
> > > > - Nick
>
> > > > On Nov 11, 4:05 pm, Alex Osborne <[EMAIL PROTECTED]> wrote:
>
> > > > > NickDG wrote:
> > > > > > Trying to get the Centro to the boot screen too. It needs to
> > > > > > catchup
> > > > > > to our progress with the 650. :)
>
> > > > > Nick, have you tried my kernel build with Centro support compiled in?
> > > > > Here's an android patched kernel that should work on the 650, 680,
> > > > > Centro and may work to some extent on the LifeDrive, TX, T|T5, T|C and
> > > > > Zire 72 machines as well. I've only tested it on the 650 and 680
> > > > > though.
>
> > > > >http://releases.hackndev.com/kernels/zImage-multidevice-android-2.6.2...
>
> > > > > Config it was built with:
>
> > > > >http://releases.hackndev.com/kernels/zImage-multidevice-android-2.6.2...
>
> > > > > Source:
>
> > > > > git clone git://git.hackndev.com/kernel-2.6
> > > > > cd kernel-2.6
> > > > > git checkout origin/android
>
> > > > > You won't need to change the machine id to "1230", leave it as "1944"
> > > > > with this one as it actually knows about the Centro, not just the 680.
> > > > > See the Centro forum thread for more information about the status of
> > > > > the
> > > > > port:
>
> > > > >http://hackndev.com/node/221
>
> > > > > If you get "0 Unknown Device", upgrade Cocoboot to 0.5.3.
>
> > > > > Cheers,
>
> > > > > Alex
--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
