#2206: Can't mount GadgetFS on OM.
-+--
Reporter: frankmpunkt | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component:
I wrote:
> - teach Qi to read zImage.
I just gave it a try. Seems to work well enough. Patches on
openmoko-kernel.
- Werner
___
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
Hi all,
I still suffer from enlightenment drawing
cpu time (20% ) for no obvious reason on
OM2008.12.
I removed dropshadow module as suggested.
That did't help.
The phantom is barely reproducable. Sometimes
it shows on subsequent boots sometimes not.
To get rid of it, I do the following:
> kil
Andy Green wrote:
> You misunderstand, we need a mach-gta02.c upstream at some point, one
> that has basically no peripherals in it as a starting point for GTA02
> support going upstream, so we can plug all the drivers we are never
> going to get ready all at once in later.
Oh, we need that for su
Petr Vanek wrote:
> so each distro would have to supply zImage... or can one locate the
> build directory where our [fr owners :)] kernels come from, so one
> could get t zImage from there?
Hmm yes, that would be one option. Other possibilities include:
- add uImage support to kexec-tools
- teac
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| Nelson Castillo wrote:
|> I thought that we needed to have a small mach-gta02.c that works in
mainline.
|
| I don't think this is a condition for getting the design reviewed by
| upstream. People will mainly
Nelson Castillo wrote:
> I thought that we needed to have a small mach-gta02.c that works in mainline.
I don't think this is a condition for getting the design reviewed by
upstream. People will mainly be interested in seeing the code. The
other documentation you've prepared will of course help to
On Thu, Jan 8, 2009 at 6:13 PM, Stefan Schmidt wrote:
> Hello.
>
> On Thu, 2009-01-08 at 17:32, Nelson Castillo wrote:
>>
>> I fail to see your point :-(
>
> From my view the main point Holger is making is that you did the work in a
> nice
> generic way but kept it all in the openmoko-only git tr
Hello.
On Thu, 2009-01-08 at 17:32, Nelson Castillo wrote:
>
> I fail to see your point :-(
>From my view the main point Holger is making is that you did the work in a nice
generic way but kept it all in the openmoko-only git tree. Speculating if
upstream likes this or not could get clarified by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| On Thursday 08 January 2009 23:32:34 Nelson Castillo wrote:
|
|> I feel you're trying to tell us there is a single path to solving the
|> problem and that we
|> are failing to follow it...
|
| Sorry that I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| On Thursday 08 January 2009 20:38:42 you wrote:
|
|> | have and maintain code that is doing that.
|>
|> The implementation already exists.
|
| Cool what prevents the kernel team from presenting the patches
u
On Thursday 08 January 2009 23:32:34 Nelson Castillo wrote:
> I feel you're trying to tell us there is a single path to solving the
> problem and that we
> are failing to follow it...
Sorry that I'm forced to state the obvious. There is one crucial part with
sending stuff upstream. It involves w
On Thu, Jan 8, 2009 at 3:59 PM, Holger Freyther wrote:
> On Thursday 08 January 2009 20:38:42 you wrote:
>
>> | have and maintain code that is doing that.
>>
>> The implementation already exists.
>
> Cool what prevents the kernel team from presenting the patches upstream[1] and
> asking for commen
Am 08.01.2009 um 21:56 schrieb Christopher Friedt:
> Hi again Niklaus,
>
> I made 2 small typos on my reply before
>
> 1) my target was not gnueabi, it was arm-softfloat-linux-gnu (only
> more recent versions of glibc / gcc / binutils support gnueabi)
Ok, that may be different in detail and the
On Thursday 08 January 2009 20:38:42 you wrote:
> | have and maintain code that is doing that.
>
> The implementation already exists.
Cool what prevents the kernel team from presenting the patches upstream[1] and
asking for comments? I'm puzzled on the part that you have done 4x to 5x times
the
Am 08.01.2009 um 20:26 schrieb Christopher Friedt:
> a) The FR supports NTPL, but I wouldn't actually suggest trying to use
> anything else, be it linuxthreads or some 3rd party threading lib.
Ok, so the easiest approach could be to simply leave out NPTL from the
toolchain instead of fighting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| On Thursday 08 January 2009 16:58:32 Andy Green wrote:
|> Somebody in the thread at some point said:
|> |1.) Get the code upstream into the linux kernel
|>
|> We feel showing it can remove the need for t
On Thursday 08 January 2009 17:20:48 Nelson Castillo wrote:
> We are making parts of tslib optional for us, not all of it obsolete
> for everyone ...
If you do filtering and calibration in kernel? What does tslib do? Why to keep
it around? nostalgia?
> > Our Company goal is to use upstream s
On Thursday 08 January 2009 16:58:32 Andy Green wrote:
> Somebody in the thread at some point said:
> | 1.) Get the code upstream into the linux kernel
>
> We feel showing it can remove the need for tslib gives us a story that
> gives a better chance upstream.
I think one can imagine that this
please excuse my questions (perhaps too stupid for you):
On Sat, 27 Dec 2008 03:27:17 -0200
Werner Almesberger (WA) wrote:
>More specifically, that you don't actually change the boot loader
>but make a small Linux system that does nothing but bring up the
>menu and then execute the respective c
Hi,
I am in the process of building a native crosstoolchain for the
Freerunner to do some Objective-C development that runs natively on a
Mac OS X (Darwin).
Currently I am sitting at the issue that glibc-2.3.6 with NPTL has no
support for ARM processors and I thought that every kernel since
On Thu, Jan 8, 2009 at 10:33 AM, Holger Freyther wrote:
> On Friday 26 December 2008 06:24:21 Nelson Castillo wrote:
>> Hello.
>>
>> With the latest kernel we can use the Touchscreen with no further
>> user-space filtering. I'd like to test this.
>>
>> How can I make Xglamo read the TS information
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
| 1.) Get the code upstream into the linux kernel
We feel showing it can remove the need for tslib gives us a story that
gives a better chance upstream.
| Our Company goal is to use upstream stuff, by
On Friday 26 December 2008 06:24:21 Nelson Castillo wrote:
> Hello.
>
> With the latest kernel we can use the Touchscreen with no further
> user-space filtering. I'd like to test this.
>
> How can I make Xglamo read the TS information from /dev/input/eventX?
To restart this:
Check /etc/ts.conf. I
Dear friends,
I am trying to make a scripted ftp session for Openmoko using obexftp -
pretty much like described for S60 in:
http://code.google.com/p/bluepys60/wiki/InstallationNotes
inspired by
http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#OBEX
Also described for S60 is how to make o
On Thursday 08 January 2009, Dieter Spaar wrote:
> Hello Al,
>
> > Is this something that a volunteer who's signed the NDA would be able to
> > look into? If we're lucky here might be something in the small bit of GSM
> > source OM do have access to.
>
> The actual task of modifying the audio strea
26 matches
Mail list logo
