Re: Hello

Re: toolchain.eclass and cross-compiling gcc

On Thu, Aug 30, 2007 at 06:03:58PM -0400, Mike Frysinger wrote:
> is_crosscompile is used to detect whether we're building a
> cross-compiler, not whether we're cross-compiling the compiler

Suggest name change to is_crosscompiler

> > The point is though, that even for straight cross-compiles it's
> > usually more dependent on CHOST being set to a different
> > architecture than CTARGET.
> 
> in the normal case, CTARGET is never set ... however, for all
> toolchain based packages, the three tuples (CBUILD CHOST CTARGET)
> are made sure to be set to the correct value

What about those --enable-serial-* though? Is there a better
solution for the author's problem?

//Peter

Re: Using gcc 3.3.6 Guide?

On Thu, Aug 30, 2007 at 10:48:56AM +0000, wireless wrote:
> Say I'm new to embedded linux.

I would recommend you to set up a few LFS systems and/or regular
Gentoo systems for starters.

> Now, I have  simple qustion. What x96 processors does it run on?
> NONE of these pages mention i386 or any other specific processor up
> to the 64 bit variants. Does it run on everything? If so, one
> sentence explicitly listing what it runs on, would be keen.

Do you want to keep updating that sentence when new hardware is
released? Submit web page bugs.

> All I see is "Gentoo uclibc/x86/hardened profile)" in the first doc
> GNAP should boot successfully on 486 systems with as low as 32 Mb
> RAM." on the second page.

So now you know it's at least 486 and up.

> I have no idea if I can indeed install (or should try to install)
> GNAP on a newer x86 such as one of the 64 bit variants. GNAP
> appeals to me very much, because building firewalls on 486 and 586
> class machines is something I do quite often.

If you don't want to control every single file, GNAP may be for you.

> >> So from what has been said, 'embedded gentoo' only has these
> >> choices for builds: i586, i686, and higher?
> > 
> > who said that ?
> 
> Exactly, we agree! The impression I have is I have no clue where
> GNAP ends and embedded Gentoo (should) start. Or are they the same
> thing?

I'd say there is a bit of overlap.

> So GNAP is a special case of 'Embedded Gentoo' just for x86?
> Embedded Gentoo, will run on a 386 and a 486?

Wow - come on?

GNAP is an appliance platform. AFAIK only x86 so far.

Embedded Gentoo is more like a meta-distribution, for embedded
systems, regardless of architecture.

> > the uClibc stages on our mirrors target i386.  if you want/need
> > something else, you'll have to build it.
> 
> Can you be explicit as to these locations?
> mirrors.tera-byte.com/experimental/x86/embedded/stages/
> 
> gives me these choices for a i586:
> stage3-x86-uclibc-hardened-2005.0.tar.bz2
> stage3-x86-uclibc-2006.1.tar.bz2
> stage3-x86-uclibc-2005.0.tar.bz2

So you found three uClibc stages, and since they only state x86 they
will work on any x86 architecture.

> HOwever, I usually use this one, with a traditional gentoo firewall
> install:
> stage3-i586-2006.1.tar.bz2
> but I am curious when, why or why not use this one:
> stage3-i586-2006.1-no-nptl.tar.bz2

Depends on whether you want NPTL or pthread threading in glibc.

> I guess I cannot use the last two because all embedded gentoo uses
> uclibc ?

Embedded Gentoo currently supports gnu, klibc and uclibc according to
crossdev -t help. klibc probably doesn't work though, and uclibc
isn't ported to all architectures supported by crossdev.

> I'm guessing that is exactly what makes 'embedded gentoo' is the
> use of uclibc?  A few explicit statements somewhere in the web
> pages, would go a long way to illuminating these details.

GNAP is very special purpose, as stated by the name too.

Embedded Gentoo is very generic, a meta-distribution, just like
regular Gentoo.

//Peter

Re: toolchain.eclass and cross-compiling gcc

On Saturday 01 September 2007, Peter Stuge wrote:
> On Thu, Aug 30, 2007 at 06:03:58PM -0400, Mike Frysinger wrote:
> > is_crosscompile is used to detect whether we're building a
> > cross-compiler, not whether we're cross-compiling the compiler
>
> Suggest name change to is_crosscompiler

makes sense

> > > The point is though, that even for straight cross-compiles it's
> > > usually more dependent on CHOST being set to a different
> > > architecture than CTARGET.
> >
> > in the normal case, CTARGET is never set ... however, for all
> > toolchain based packages, the three tuples (CBUILD CHOST CTARGET)
> > are made sure to be set to the correct value
>
> What about those --enable-serial-* though? Is there a better
> solution for the author's problem?

i really dont have an idea of what the problem is.  i build cross-compilers 
and cross-compile native compilers and cross-compile cross-compilers and have 
yet to hit any problems (which are not fixed in the current tree).
-mike

Re: Hello

Jean-Marc Beaune wrote:
> Hi,
> 
> I'd be interested in multimedia application, but on a board with more
> features (+wifi, +video & sound connectors, +usb, etc...).
> 
> /JM
> 
> On 8/31/07, * Carmelo Pintaudi* <carmelo.pintaudi@...
> <mailto:carmelo.pintaudi@...>> wrote:
> 
>     Alle sabato 4 agosto 2007, wireless ha scritto:
> 
>     >  A very interesting subproject that has been alluded to
>     >  by Vapier, is completing the port of ffmpeg to an
>     >  arm chip (with sufficient on board resources) to
>     >  run all sorts of video, including H.264 on an
>     >  Arm embedded (gentoo) linux board. If we all agree
>     >  on the main CPU, then we can use different variants
>     >  (different SBC or custom built boards) to complete
>     >  porting and testing ffmpeg on Arm?
>     >
>     >  The board I have ordered is this:
>     >  http://www.emacinc.com/sbc_microcontrollers/ipac_9302.htm#FEATURES
>     <http://www.emacinc.com/sbc_microcontrollers/ipac_9302.htm#FEATURES>:
>     >
>     >  I have a Macraigor Raven for the Arm and they support
>     >  Eclipse for firmware development.
>     >
>     >  Any interest in mpeg4(avc) on ARM here as  group project?
>     >  anyone?
>     >
>     >
>     >  James
> 
> 
>     Sorry for late reply....
>     Currently I am working on a MIPS device.
> 
>     Bye.

Hello,

I Well my suggestion came from a conversation (poostings) on the list
about how folks do not contribute back to Open Source. H.264 is a
prime example. Regardless of which processor you select, you have to
ensure that the processor is appropriate for the types of calculations
one finds, with DCT and such mathematics. Arm is the number one
selling embedded processor family in the world, because they (ARM ltd)
will license the processor to anyone (with financial resources). Many
DSP, SOC, FPGA and multi-processor boards use an arm processor.
It rivals x86 in actual deployments.

MIPS is a very interesting processor, as much of the IP (intellectual
property) is in the public domain, even though some companies sue
all sorts of folks that use MIPS derivatives....

Many processors that purport to support H.264 have specialized
hardware. AT www.opencores.com, here is one example:
http://www.opencores.com/projects.cgi/web/video_systems/overview

Another is the TI Davinci DSP family. Many of the FreeeScale I.mx
http://media.freescale.com/phoenix.zhtml?c=196520&p=irol-newsArticle&ID=1019152&highlight=

So before you rush head-long into porting/running h.264 on an embedded
processor, you must decide if you want a pure software solution
(such as 100% code on a powerful DSP) or you want to use a processor,
such as ARM with some additional computational resources, or yet
another valid architecture.  Arm is a universal embedded processor
and porting the code from ffmpeg to a DSP or specialized hardware
platform is far from a trivial task.

Merely porting code from one platform to another, without a through
investigation of  the correctness of the new target platform's
hardware, is a questionable expenditure of technical talent.
In my opinion, MIPS is a dying architecture, at the very best a
very obscure platform for development. They easy thing to do
is find a chip solution where a vendor has been successful in
support H.264 in a real time mode. Then you can develop on a similar
hardware platform, in a open source project. Last, you might want
to spend some time on ffmpeg and other related discussion groups to
ascertain if your MIPS hardware platform is indeed viable for h.264
type of development. It may be a valid platform.

caveat emptor.

James

Zydas zd1211 drivers on MIPS and kernel 2.4

Hi, 
I am trying for use the Zydas usb wifi key on a MIPS board with special 
dedicate kernel 2.4. I had the module compiled after some CFLAGS opportune 
change. But now module seem to be possessed of evil. 
The module creates the interface eth1 with some debug error in dmesg about 
some kind of "read failure" (unfortunately now I have not the exact debug 
message). Once eth1 was created I made "ifconfig eth1 up && iwconfig eth1 
mode essid". At this point module hangs up the handling of the device and 
this become unregistered device and disappears from "ifconfig -a".
Please, If someone had the same problem let me know. Also if someone has the 
module working on ker2.4/MIPS could be a useful information.
GoodBye.

Re: Zydas zd1211 drivers on MIPS and kernel 2.4

Hello,

you did not provide enough information for anyone to be able to help.
Please find the answer to all questions below, maybe then we can help
you with some specific advice.

On Sun, Sep 02, 2007 at 12:11:14PM +0200, Carmelo Pintaudi wrote:
> I am trying for use the Zydas usb wifi key on a MIPS board

Which chipset is used in the wifi adapter? The best way to make sure
is to look up the FCCID in the online FCC database, and read the chip
model number written on the hardware components. USB wifi vendors
have on several occasions replaced the hardware without changing the
USB product id so that is unfortunately not completely reliable. :(

> with special dedicate kernel 2.4.

Why do you need a special kernel?

Which driver are you using for the wifi adapter?

//Peter

Re: Zydas zd1211 drivers on MIPS and kernel 2.4

Alle domenica 2 settembre 2007, Peter Stuge ha scritto:
>  Hello,
>
>  you did not provide enough information for anyone to be able to help.
>  Please find the answer to all questions below, maybe then we can help
>  you with some specific advice.
>
>  On Sun, Sep 02, 2007 at 12:11:14PM +0200, Carmelo Pintaudi wrote:
>  > I am trying for use the Zydas usb wifi key on a MIPS board
>
>  Which chipset is used in the wifi adapter? The best way to make sure
>  is to look up the FCCID in the online FCC database, and read the chip
>  model number written on the hardware components. USB wifi vendors
>  have on several occasions replaced the hardware without changing the
>  USB product id so that is unfortunately not completely reliable. :(
>
The chipset is for sure the ZD1211b from ZyDas
>  > with special dedicate kernel 2.4.
>
>  Why do you need a special kernel?
>
I don't  "need" a special kernel instead I have this kernel from the vendor of 
the board because the board hosts special hw (like the usb controller) and so 
features and drivers were added to the kernel by the vendor.
Maybe the usb controller (and/or his driver) is the problem?
>  Which driver are you using for the wifi adapter?
The driver is from Zydas. The zd1211.o module. This driver is the original 
driver from the manufacturer. Now from kernel 2.6.18 we have a more reliable 
driver (community driven) named zd1211rw. Based on zd1211 but available only 
for kernel 2.6.
>
>  //Peter
Thank You for any help. GoodBye!
Carmelo (a.k.a Cardone)

PGP KEY @ http://pgp.mit.edu

Re: Zydas zd1211 drivers on MIPS and kernel 2.4

On Sun, Sep 02, 2007 at 09:16:37PM +0200, Carmelo Pintaudi wrote:
> >  Which chipset is used in the wifi adapter?
> 
> The chipset is for sure the ZD1211b from ZyDas
> 
> >  > with special dedicate kernel 2.4.
> >
> >  Why do you need a special kernel?
> 
> I don't "need" a special kernel instead I have this kernel from the
> vendor of the board because the board hosts special hw (like the
> usb controller) and so features and drivers were added to the
> kernel by the vendor.

I see. Do you require these features or could you also use a vanilla
2.6 kernel on the board? I believe you could benefit a lot from 2.6.
Maybe you can use another bus for wifi?

> Maybe the usb controller (and/or his driver) is the problem?

That is certainly a possibility.

> >  Which driver are you using for the wifi adapter?
> 
> The driver is from Zydas. The zd1211.o module. This driver is the
> original driver from the manufacturer. Now from kernel 2.6.18 we
> have a more reliable driver (community driven) named zd1211rw.
> Based on zd1211 but available only for kernel 2.6.

Tough problem. :(

One vendor is supplying a proprietary driver for the USB host
controller, another vendor is supplying a proprietary driver for
the USB device.

USB can be tricky enough when everyone is working together, and you
have two different vendors working on independent drivers that need
to cooperate properly.

We can not help.

I would urge the board vendor to get their act together and have
their board-specific code rolled into the vanilla kernel, so that
their customers (you!) actually have half a chance of making use of
the board with a kernel version from this millenium.

//Peter

Eclipse and Embedded Development

Hello,

Here is another RTOS vendor that is actively supporting their
tool/RTOS via Eclipse (enjoy):
http://www.embedded.com/products/softwaretools/201800936?_requestid=170465

I wonder what the appeal is for Eclipse? I'm not really sure, but
vendors seem to be coming out of the woodwork to support many
forms of embedded development, via Eclipse. Eclipse Europa, is
receiving lots of hype concerning embedded development, again, I'm not
really sure why this convergence is occurring in the vendor space
of embedded development.

Like many on this list, I tend to use
a wide variety of CLI methodologies. However, when I work with
MS pc_weenies they are use to a robust IDE and they are willing to
migrate to embedded linux, but they insist on an IDE.

Naturally, I'm torn between these issues......

James