Am Montag, 4. Oktober 2004 23:13 schrieb Luis.F.Correia:
> Hi Mike,
>
> > -Original Message-
> > From: Mike Noyes [mailto:[EMAIL PROTECTED]
> > Sent: Monday, October 04, 2004 7:49 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [leaf-devel] PcEngines WRAP1C LED & Button driver
> >
> > On Mon,
On Mon, 2004-10-04 at 17:03, Mike Noyes wrote:
> Let me think on this for a while. A sandbox in our FRS for things like
> this is possible. The problem is once something is in the FRS you can't
> remove it. The tracker system isn't viable as there is a 256k size limit
> on attachments. Subversion h
On Mon, 2004-10-04 at 12:14, Martin Hejl wrote:
> So, how does a simple sf user place things in FRS? Any pointers? (I have
> to admit, I haven't searched for that info, since up to now, I was under
> the impression that only project admins could do that).
Luis & Martin,
Let me think on this for
Hi Mike,
> -Original Message-
> From: Mike Noyes [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 04, 2004 7:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [leaf-devel] PcEngines WRAP1C LED & Button driver
>
> On Mon, 2004-10-04 at 09:55, Luis.F.Correia wrote:
> > For now, it can be reach
Hi Mike,
Luis,
Placing content on our shell server space is a deprecated process.
Please use CVS and/or the FRS. Thanks.
CVS is easy (which Luis has already done too) - and lets say that
placing tarballs is at least frowned upon among many of the CVS
developers (that kind of discussion is pretty
On Mon, 2004-10-04 at 09:55, Luis.F.Correia wrote:
> For now, it can be reached from my developer area, no webpage yet, here:
>
> http://www.leaf-project.org/devel/lfcorreia/wrap1c.tar.gz
Luis,
Placing content on our shell server space is a deprecated process.
Please use CVS and/or the FRS. Thank
Hi!
I've managed to create a driver for accessing the 3 LED's and
to read the button on a WRAP1C and compatible hardware.
This is a kernel driver based on Martin Hejl's GPIO driver for
Soekris. It was tested with a 2.4.26 kernel, the same as current
Bering uClibc 2.2 version uses. It may or may
Mhh, that would be too reasonable, wouldn't it? :-)
Actually, one dev system is in a machine room at work, the other is in the crawlspace
under my house (old loud machine, this way I don't have to hear it).
Thanks for the nudge, though!
Thorsten
At 05:49 PM 10/4/2004 +0200, Erich Titl wro
Thorsten
At 09:07 03.10.2004 -0700, you wrote:
>Cool. Raises a couple of questions:
>
>- what is the difference between an "onboard IDE-CF" system and a "PCI-IDE CF"
>system? In particular, how can I tell which I have?
>
>- why does one need to turn DMA off in a PCI-IDE CF system? Is that the cas
I've been working on building Bering-uClibc from scratch for a WRAP embedded board.
Here is my step-by-step cheat-sheet on how to do it. Caveat: I'm not an expert and
this may not be right and probably won't work for you anyway. I'm posting it in the
hope that it will guide others in the right d
Cool. Raises a couple of questions:
- what is the difference between an "onboard IDE-CF" system and a "PCI-IDE CF" system?
In particular, how can I tell which I have?
- why does one need to turn DMA off in a PCI-IDE CF system? Is that the case for all
such systems, or only specific ones?
- one
The Bering-uClibc team releases Bering-uClibc 2.2.1 today.
It's mainly a maintenance release for version 2.2.
New feature is the support of USB sticks as boot media.
The necessary modules are provided with initrd_usb.lrp in our cvs
repository:
http://cvs.sourceforge.net/viewcvs.py/leaf/bin/packa
12 matches
Mail list logo
