I know that this may be stupid, but after the kernel successfully
built and loaded, nothing happens on Zylonite, even not uncompressing
the zImage, what may I have done wrong?
On 4月3日, 下午2時56分, cxh chen.xi...@zte.com.cn wrote:
when you build Linux kernel for running on PXA310 EVM,
you should
Thanks Ben. We have a 920T based hardware and have commenced the porting.
Just wanted to ensure that we don't encounter any obvious surprises!
On Mon, Apr 6, 2009 at 11:29 AM, Ben Leslie be...@benno.id.au wrote:
There are existing ports to various ARM9 platforms.
The simulated 'goldfish'
hi icekolo,
when you got blank screen,
you can press alt + F1 to see more detail message
try dmesg or logcat
On 4月3日, 下午5時08分, icekolo icek...@gmail.com wrote:
Hi all,
I'm a new hand.
My development environments
-OS:Ubuntu 8.04LTS(2.6.24)
-CPU:Intel(R) Pentium(R)4 CPU 3.20GHz
Thanks for the links.
I got my Penmount 6000 USB to work.
I forgot to add Power Management support:
* Suspend to RAM and standby
* Wake lock
* Wake lock stats
* Userspace wake locks
* Early suspend
I had to write my own device driver, because it got added as USB HID.
I added BTN_TOUCH
I use the Alsa Lib from the git repository. It's still from before the
big merge.
I still can't get it to work. Does it really need an asound.conf ?
When are the alsa-utils commited to the repository? I can't build it
decently for x86. Anyone has a decent Android makefile for this?
On 1 apr,
Hi,
Even i am also facing the same error with the new android source after
making repo sync.
The alsa-lib and alsa_sound are also new ones checked out from git.
the dev/snd are created. /proc/asound exists.
i also copied the sample asound.conf to /system/etc/.
Even given the permissions.
Hi,
There is a complete build targeted for the Openmoko Freerunner
available at http://git.koolu.org. It contains a prebuild ARM4T
toolchain as well, and creates images suitable for flashing to the
phone.
We have two branches at the moment: koolu-1.0 which is based on the
original source
*http://cars-mansoor.blogspot.com* http://cars-mansoor.blogspot.com
http://cars-mansoor.blogspot.com//
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
I'm working on getting all the required changes (for armv4t) into the
master branch, it's actually not that much. I'm currently waiting for
a simple Skia change to be approved/merged !
/Fredrik
On Mon, Apr 6, 2009 at 7:54 AM, Saffron Labs saffronl...@gmail.com wrote:
Hi,
I've read in one
Hi 'Jackson Fan',
I agree with your analysis. The framework code to handle A2DP / SCO
transitions could be improved. In the current design A2DP and HFP are
loosely coupled independent services. In retrospect you actually need
a fair degree of coupling between them in order to make the SCO/A2DP
Chen,
It seems that no one from google really care about this. And this leaves
the x86 build totally broken. We should really check in the fix for
this. Should we?
Yi
On Tue, 2009-03-31 at 17:51 +0800, Chen Yang wrote:
Would some one from google give some comments on the removal the build
of
*http://cars-mansoor.blogspot.com/*
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~--~~~~--~~--~--~---
On Apr 5, 9:21 pm, Manish Sharma manishsharm...@gmail.com wrote:
I have enabled HAVE_SHORT_ENUMS and now the logs are changed but still
getting VM aborting.
[...]
E/dalvikvm( 1554): Bad asm sizeof sizeofGlobal_debuggerActive (1), should be
4
E/dalvikvm( 1554): Bad asm sizeof
*http://cahttp://cars-mansoor.blogspot.com/rs-mansoor.blogspot.com*/
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~--~~~~--~~--~--~---
*http://cars-mansoor.blogspot.com/* http://cars-mansoor.blogspot.com/
http://cars-mansoor.blogspot.com/
--~--~-~--~~~---~--~~
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
What is the general opinion about the code in external (for example
skia, libjpg), can it depend on bionic-specifics like cpu-features.h
or should we try to keep the external stuff independent ?
The specific question this time is if I'd better off using #if
!defined(__ARM_ARCH_4T__) or #if
Hi Fredrik,
IMO, external/* should not depend on bionic.
Fredrik Markström wrote:
What is the general opinion about the code in external (for example
skia, libjpg), can it depend on bionic-specifics like cpu-features.h
or should we try to keep the external stuff independent ?
The specific
I really don't see any reason to not use bionic in external. This would not
be the common case, because by definition external tends to be things that
exist outside of android so probably want to run elsewhere. But whether or
not they want to depend on bionic should really be up to the owner of
The whole idea is to minimize the changes to the code in external/* such
that it has the possibility to be merged back to its source. Which is better
a) use #ifdef __ARM_ARCH_4T__ (which is standard to many people and
already in Androids compilation line).
or
b) #ifdef ANDROID, #include
Hi fadden,
Now my setup is working without any error. The changes which I have done
are.
1. Modified linux-arm.mk file as mentioned in my previous mail.
2. enabled HAVE_SHORT_ENUMS as mentioned by you.
If I miss anything it give VM aborting. I am still not understanding the
logic of enabling
20 matches
Mail list logo
