Cannot find /dev/pmem

[borhe]

I am porting the Android for the ARM platform,
I am running it via NFS., so i have extracted the /data and /system
directories using the instructions on
http://elinux.org./Android_on_OMAP and loading the android executables
via NFS

I also downloaded the latest kernel and merged it with my platform's
kernel.
The system starts, the services are running but i get the following
error for /dev/pmem:

D/dalvikvm( 69): Trying to load lib /system/lib/
libandroid_servers.so 0x0
D/dalvikvm( 69): Added shared lib /system/lib/libandroid_servers.so
0x0
I/sysproc ( 69): Entered system_init()
I/sysproc ( 69): ServiceManager: 0xbf788
I/SurfaceFlinger( 69): SurfaceFlinger is starting
E/MemoryHeapBase( 69): error opening /dev/pmem: No such file or
directory
I/SurfaceFlinger( 69): SurfaceFlinger's main thread ready to run.
Initializing graphics H/W...
E/SurfaceFlinger( 69): Couldn't open /sys/android_power/
wait_for_fb_sleep or /sys/android_power/wait_for_fb_wake
E/SurfaceFlinger( 69): Can't open /dev/tty0
E/GLLogger( 69): couldn't load <libhgl.so> library (Cannot find
library)

I did not find the pmem.c under the latest android kernel, do i really
need this module?

I also compiled the android source but did not find the libhgl.so


Please help.

[Brian Swetland]

pmem is only needed for certain devices requiring large physically
contiguous memory on the msm7k (gpu, dsp, etc). It's not currently
used by any other SoCs and its absence is not a fatal error.

libhgl.so is the (proprietary) library for openglES on the msm7k
GPU. It also is not required for correct operation.

[borhe <boris...@gmail.com>]

[bcavagnolo]

On Dec 1, 12:18 pm, Brian Swetland <swetl...@google.com> wrote:
> pmem is only needed for certain devices requiring large physically
> contiguous memory on the msm7k (gpu, dsp, etc).  It's not currently
> used by any other SoCs and its absence is not a fatal error.
>
> libhgl.so is the (proprietary) library for openglES on the msm7k
> GPU.  It also is not required for correct operation.

I'm having this same problem trying to get the Media ApiDemo to work.
It seems that the opencore surface driver (external/opencore/android/
android_surface_output.cpp) wants to use /dev/pmem_adsp which does not
exist. I dug around in the kernel tree and it does not seem to be
implemented. Is there some other source of memory for that the
MemoryHeapBase to use? Am I missing something?

Thanks,
Brian

> [borhe <boris.st...@gmail.com>]

>
> > I am porting the Android for the ARM platform,
> > I am running it via NFS., so i have extracted the /data and /system
> > directories using the instructions on

> >http://elinux.org./Android_on_OMAPand loading the android executables

[Dave Sparks]

If you aren't using tunneling mode from the codec frame buffer to the
video output, you should set mEmulation to true in the
AndroidSurfaceOutput constructor. This will force the system to use
ashmem heap instead. The hardware abstraction is somewhat weak in this
area. We plan to do a better job of abstracting it in a future
release.

On Dec 5, 5:38 pm, bcavagnolo <bcavagn...@gmail.com> wrote:
> On Dec 1, 12:18 pm, Brian Swetland <swetl...@google.com> wrote:
>
> > pmem is only needed for certain devices requiring large physically
> > contiguous memory on the msm7k (gpu, dsp, etc). It's not currently
> > used by any other SoCs and its absence is not a fatal error.
>
> > libhgl.so is the (proprietary) library for openglES on the msm7k
> > GPU. It also is not required for correct operation.
>
> I'm having this same problem trying to get the Media ApiDemo to work.
> It seems that the opencore surface driver (external/opencore/android/
> android_surface_output.cpp) wants to use /dev/pmem_adsp which does not
> exist. I dug around in the kernel tree and it does not seem to be
> implemented. Is there some other source of memory for that the
> MemoryHeapBase to use? Am I missing something?
>
> Thanks,
> Brian
>
> > [borhe <boris.st...@gmail.com>]
>
> > > I am porting the Android for the ARM platform,
> > > I am running it via NFS., so i have extracted the /data and /system
> > > directories using the instructions on

> > >http://elinux.org./Android_on_OMAPandloading the android executables

[Ben Leslie]

Hi Brian,

I was wondering if this is something that can be changed to make the
logs more easy for people to parse. i.e: Can we set things up to not
try and load libhgl when it is not required, and same for pmem? This
would make things easier for people porting to understand the output.
(Not suggesting it is very important, but would there be any problem
if I made a patch to do this?)

Thanks,

Benno

[Mathias Agopian]

On Sun, Dec 7, 2008 at 7:20 PM, Ben Leslie <be...@benno.id.au> wrote:
>
> Hi Brian,
>
> I was wondering if this is something that can be changed to make the
> logs more easy for people to parse. i.e: Can we set things up to not
> try and load libhgl when it is not required, and same for pmem? This
> would make things easier for people porting to understand the output.
> (Not suggesting it is very important, but would there be any problem
> if I made a patch to do this?)

Trying to open pmem and load libhgl is how the system knows,
respectively, if surfaces need to be allocated in pmem and if h/w gl
acceleration is available. Of course, we could have the system not do
these things when it knows that that particular board doesn't have
these features (ie: do the check at compile time).
This mechanism is very crude, right know and it will be refined down the road.

In the meantime, we could definitely make the log messages sound less dramatic.

mathias