cygwin and embedded linux

2002-08-27 Thread Sangmoon Kim

Hi,
I built a toolchain for ppc under cygwin about a year ago.
I used the Billgatliff's 
script(http://crossgcc.billgatliff.com/build-crossgcc.sh)
It failed to build glibc. So I copied glibc from a linux machine.
I've been using the toolchain, without any problem, for our custom MPC755 
board, for about a year.
I recommand the Billgatliff's script, if you are going to make a tool chain for 
ppc under cygwin.

- Sangmoon Kim -

- Original Message -
From: "Dan Malek" <[EMAIL PROTECTED]>
To: "Kenneth Johansson" 
Cc: "Dr. Craig Hollabaugh" ; "Marius Groeger" ; "John Fisher" ; "Linuxppc embedded" 

Sent: Saturday, August 24, 2002 9:11 AM
Subject: Re: cygwin and embedded linux


>
> Kenneth Johansson wrote:
>
> > And I remember what you thought about people like me that tried to make
> > the cross compile environment going.
>
> The only opinion I have changed is that people that can actually make
> this work well (and I know of only a couple) have a special talent
> and I really like them to hang around :-)
>
> I guess when you work for a large company that will pay your salary regardless
> of missing schedules and can only provide half-assed tools you have to
> cobble together to make things work, you are both lucky and have my sympathy.
> I don't have the patience or development time to create or debug my
> development tools, they just have to work.  I'm not using anything that
> anyone else can't go out and purchase or download, and it continues to
> baffle me why people won't take the easy route to developing software.
>
>
> > But it finally did work out OK and nowadays all you really need to now
> > is what parameters to give the configure script.
>
> There is LOTS more to creating an easy to use and properly created set
> of development tools than knowing some parameters to configure scripts.
> Only a couple of people I know understand the magic, and it isn't documented.
> I'm just going to rely on them to make my job easier :-)
>
> Have fun!
>
>
> -- Dan
>
>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Dan Malek

Kenneth Johansson wrote:

> And I remember what you thought about people like me that tried to make
> the cross compile environment going.

The only opinion I have changed is that people that can actually make
this work well (and I know of only a couple) have a special talent
and I really like them to hang around :-)

I guess when you work for a large company that will pay your salary regardless
of missing schedules and can only provide half-assed tools you have to
cobble together to make things work, you are both lucky and have my sympathy.
I don't have the patience or development time to create or debug my
development tools, they just have to work.  I'm not using anything that
anyone else can't go out and purchase or download, and it continues to
baffle me why people won't take the easy route to developing software.


> But it finally did work out OK and nowadays all you really need to now
> is what parameters to give the configure script.

There is LOTS more to creating an easy to use and properly created set
of development tools than knowing some parameters to configure scripts.
Only a couple of people I know understand the magic, and it isn't documented.
I'm just going to rely on them to make my job easier :-)

Have fun!


-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Marius Groeger

On Thu, 22 Aug 2002, I wrote:

> 2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
>fraction can be a major PITA, because it is not obvious. To compile a
>kernel you need a lot of tools with a lot of explicit and implicit twists
>to them. It is just a gut feeling that I wouldn't want to rely on this,
>if I don't have to. The native way just seems the better way to do it to
>me.

Since the term "native" seems to have triggered many other (very
interesting) posts, just for completeness: in fact I chose bad wording
for what I wanted to say in this post. In this case, with "native" I
merely meant a real Linux box (vs. a Windows box), not necessarily a
native ppc-linux machine.

Native ppc-linux is definitely one way to go, although I'd tend to
hold with one of the other posts to this thread. It pointed out the
necessity/robustness/repoducability/beauty of clearly distincting
between the host and the target.

Regards,
Marius

-
Marius Groeger   SYSGO Real-Time Solutions GmbH mgroeger at sysgo.de
Software Engineering Embedded and Real-Time Softwarewww.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Kenneth Johansson

On Fri, 2002-08-23 at 07:18, Dan Malek wrote:
>
> Dr. Craig Hollabaugh wrote:
>
> > I'm curious ...
> >
> > How many out there actually are compiling PPC code natively on a PowerPC 
> > Linux box for their embedded devices?
>
> Me.

And I remember what you thought about people like me that tried to make
the cross compile environment going. Lucky you that I managed to delete
my old mbox otherwise I could repost some interesting mail :)

But it finally did work out OK and nowadays all you really need to now
is what parameters to give the configure script.


--
Kenneth Johansson
Ericsson AB   Tel: +46 8 404 71 83
Borgafjordsgatan 9Fax: +46 8 404 72 72
164 80 Stockholm  kenneth.johansson at etx.ericsson.se


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Magnus Damm

> How many out there actually are compiling PPC code natively
> on a PowerPC Linux box for their embedded devices?

Not me. I cross compile all my distributions from x86 hosts.
I like the idea of separating the target system from the
host system. To keep track of used libraries and to be able
to recreate the same distribution in the future with another
host.

I've always wanted a sleek laptop from apple,
but I would like more than one mouse button...

/ magnus

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Jerry Van Baren

At 01:00 PM 8/22/2002 +0200, Magnus Damm wrote:

> > Are there others in this situation and how have they chosen to solve it?

[snip]

>Another way to solve it would be to switch to Linux and use VNC to
>connect
>to your Windows boxes. I'm not sure how well this works out, though.

Very well.  It comes with a Windows client that works well.  The linux
server works very well with minimal slowdown compared to a native X session
(I use Exceed for X on Windows).  If I didn't already own Exceed, I would
use VNC exclusively.  (The Windows server also works quite well, but not as
well as VNC on linux because Windows isn't really set up to do remote
windows so it has to work a lot harder and is slower as a result.)

The default window manager (TWM?) is very basic so you may want to spend
some time getting it set up better or getting a more elaborate WM running.

What is really cool about VNC is that you can start a job, reboot your
Windows box 5 times to install some trivial piece of hardware :-),
re-attach to your VNC session that was busy running your job all the while,
just in time to see your job complete.

gvb


>/ magnus

[snip]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Jerry Van Baren

At 05:39 PM 8/22/2002 -0600, Dr. Craig Hollabaugh wrote:

>At 09:36 AM 8/22/2002 +0200, Marius Groeger wrote:
> >2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
> >   fraction can be a major PITA, because it is not obvious. To compile a
> >   kernel you need a lot of tools with a lot of explicit and implicit twists
> >   to them. It is just a gut feeling that I wouldn't want to rely on this,
> >   if I don't have to. The native way just seems the better way to do it to
> >   me.
>
>Just because your running on Linux doesn't mean anything because your
>duplicating
>the environment for cross-compiling anyway. So what does it matter if
>cygwin runs
>the cross tools or if Linux runs them?
>
>
>
>I'm curious ...
>
>How many out there actually are compiling PPC code natively on a PowerPC
>Linux box for their embedded devices?
>
>If so, do you run the same development versions on your desktop?
>
>How do you handle the FPU issues?
>
>Craig

We've done native on an iMac and cross on X86 linux.

Additional problems with Cygwin, from my point of view, is that you will
always be trailing the mainstream development because the Cygwin tools are
based on the native linux toolsets rebuilt (perhaps with customizations) to
allow them to run under DOS.  In addition, there are only a fraction as
many engineers using Cygwin vs. linux so your pool of "informed developers"
to ask questions of is much smaller.  Perhaps both of those objections go
away if you pay for Cygwin support :-).

My limited experience with Cygwin is that it is like cutting with a dull
knife: it can get the job done, but you have to work harder and the results
are a little more ragged than they should be.

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux ... a little OT

2002-08-23 Thread Rod Boyce

Our company at the beginning of last year just added Linux to our
development platforms.  There are a lot of free tools to make using two OS's
Linux and Windows very easy.
Firstly there is the question of weather to have a single big and expensive
box for Linux development that all developers log into and used for there
development or does each developer have his own box that he uses.  It does
not have to be as expensive but still needs to be about the same
specifications as his current windows box.
Next is how do you get around the problem of an extra screen, keyboard, and
mouse on the developers desktop.  We started out using a non-freeware
xserver for windows.  This worked well for our evaluation but we quickly
discovered the limitations.  I have been using VNC on Linux and windows for
a while now and it works very well.
One big and expensive server about $9000USD separate machines about $700USD
if you have more that 12 developers then maybe a big server but then you
have need a bigger even more expensive server for 12 developers.

If I was to set up a development environment again it would give each
developer another PC the same specifications as his current windows PC
running Linux (my preference is RedHat 7.3) using Xvnc on boot up and the
windows VNC client can log in to it for the developer can use.  This second
PC does not even have to reside in the developers work area but it is
easier.  The developer needs to have full control of this PC including the
root password.  But this adds to the maintenance of the machines and you
very quickly discover that patches come out often.  Some developers do not
like your chosen Linux distribution.  My experience is that these developers
know how to look after their machine and you don't need to maintain these
PCs.  The way I would set up the workstations would be that the cross
compiler would be mounted form a sopped up workstation somewhere the tftp
server would also sit on one server and each workstation would mount this in
the same place on each workstation.  User accounts would be set up network
wide using NIS or LDAP but the home directory for each developer would
reside on each workstation.  Each developer would have his own network root
partition for his own development and this needs to be kept as close as
possible to what will be stored in flash (this is difficult but possible).
Whoever gets the job of keeping the Linux server and / or workstations up to
date will like using a Linux distribution as it is very easy to apply
patches.  It is not uncommon for me to have 4 or 5 RedHat update agents
running at the same time from different PCs on my one desktop.

This is how I did it but maybe there are better ways I am yet to work out.

Hope this helps a little bit
Regards,
Rod Boyce

 -Original Message-
From:   John Fisher [mailto:[EMAIL PROTECTED]
Sent:   Wednesday, August 21, 2002 6:15 PM
To: linuxppc-embedded at lists.linuxppc.org
Subject:    RE: cygwin and embedded linux


> Actually, my personal opinion on that matter is that I'm not very fond
> of using Windows for a Linux kernel development platform. Doing --

So what are the issues: How is cygwin significantly different from Linux
that you would not want to use it?
Are there useful tools that run under Linux but not under cygwin?

The reason I ask is that my organization currently does its software
development under windows using proprietary tools. We have to maintain our
existing products using these tools. We are however contemplating new
development using linux. If we have to dual boot our PCs or have an extra PC
running Linux for each developer, that is going to bring its own set of
nuisances and problems.

Are there others in this situation and how have they chosen to solve it?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Dan Malek

Dr. Craig Hollabaugh wrote:

> I'm curious ...
>
> How many out there actually are compiling PPC code natively on a PowerPC 
> Linux box for their embedded devices?

Me.

> If so, do you run the same development versions on your desktop?

Almost :-)

> How do you handle the FPU issues?

For 4xx/8xx I'll use a cross compiler, all other PowerPCs have FPUs.
For embedded Altivecs I have to use the host compiler.

I do all of my development for all embedded processors on a PowerMac running 
YDL.


-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-23 Thread Dr. Craig Hollabaugh

At 01:18 AM 8/23/2002 -0400, Dan Malek wrote:
>I do all of my development for all embedded processors on a PowerMac running 
>YDL.
>
>
>   -- Dan


why you lucky dog!

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Dan Taylor

Set up a separate Linux server (or servers), then use an X-Windows
server package, running on each M$-Windows machine, to be able to
run xterms, etc. locally/  You will be able to access all of the
Linux tools in their native environment.

Later, when you may have only a few people doing legacy M$-Windows
support, you can reverse the process.  Your developers will live
on Linux boxes and access a (NT Terminal Server/2000 Enterprise
Server/Whatever the #%$! they call the XP version) to run the M$-Windows
tools in THEIR native environment, while living in your primary
development environment.

I've done both of these, at various locations, currently the latter,
living on Solaris/SPARC and Linux/X86 developing for embedded Linux/PPC.

I have, in addition, used cygwin, on M$-Windows 2000 Pro, and found that
the worst performance issue is that shared drives are PAINFUL, but that
cross-development (for non-Linux MIPS, in that case) is really doable,
although I ended up resorting to the M$-Windows-native version of emacs.

Regards,

Dan

John Fisher wrote:

>>Actually, my personal opinion on that matter is that I'm not very fond
>>of using Windows for a Linux kernel development platform. Doing --
>>
>
> So what are the issues: How is cygwin significantly different from Linux
> that you would not want to use it?
> Are there useful tools that run under Linux but not under cygwin?
>
> The reason I ask is that my organization currently does its software
> development under windows using proprietary tools. We have to maintain our
> existing products using these tools. We are however contemplating new
> development using linux. If we have to dual boot our PCs or have an extra PC
> running Linux for each developer, that is going to bring its own set of
> nuisances and problems.
>
> Are there others in this situation and how have they chosen to solve it?
>
>
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Dr. Craig Hollabaugh

To summarize:
 Speed
 Windows version compatibility
 NFS issues

all good reasons to not develop using cygwin. Anything else?

Personally, I do all my embedded development on a Debian machine. I'm just want 
a specific answer to the inevitable customer question, "Why can't I just use 
cygwin for development?"

Thanks,
Craig


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Dr. Craig Hollabaugh

At 09:36 AM 8/22/2002 +0200, Marius Groeger wrote:
>2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
>   fraction can be a major PITA, because it is not obvious. To compile a
>   kernel you need a lot of tools with a lot of explicit and implicit twists
>   to them. It is just a gut feeling that I wouldn't want to rely on this,
>   if I don't have to. The native way just seems the better way to do it to
>   me.

Just because your running on Linux doesn't mean anything because your 
duplicating
the environment for cross-compiling anyway. So what does it matter if cygwin 
runs
the cross tools or if Linux runs them?



I'm curious ...

How many out there actually are compiling PPC code natively on a PowerPC Linux 
box for their embedded devices?

If so, do you run the same development versions on your desktop?

How do you handle the FPU issues?

Craig


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Kerl, John

Oops, should have written:

When starting to do Linux/PPC cross-development about
a year ago (my current workplace is an NT shop) I
experimented with cygwin, for some of the same reasons
as the original poster describes.  & I found that cygwin
was roughly 20x slower than Linux running on the same class
of PC (!).  I could pop the Red Hat CD in the drive and install
the actual OS, & have it up & running in half an hour
-- less time than it took to complete a single,
moderately complex compile job on cygwin.  I soon found that
   ^
cygwin wasn't saving me any time at all.


-Original Message-
From: Kerl, John
Sent: Thursday, August 22, 2002 4:49 PM
To: 'Dr. Craig Hollabaugh'; Marius Groeger; John Fisher
Cc: linuxppc-embedded at lists.linuxppc.org
Subject: RE: cygwin and embedded linux


When starting to do Linux/PPC cross-development about
a year ago (my current workplace is an NT shop) I
experimented with cygwin, for some of the same reasons
as the original poster describes.  & I found that cygwin
was roughly 20x slower than Linux running on the same class
of PC (!).  I could pop the Red Hat CD in the drive and install
the actual OS, & have it up & running in half an hour
-- less time than it took to complete a single,
moderately complex job.  I soon found that cygwin wasn't
saving me any time at all.


-Original Message-
From: Dr. Craig Hollabaugh [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 22, 2002 4:39 PM
To: Marius Groeger; John Fisher
Cc: linuxppc-embedded at lists.linuxppc.org
Subject: RE: cygwin and embedded linux



At 09:36 AM 8/22/2002 +0200, Marius Groeger wrote:
>2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
>   fraction can be a major PITA, because it is not obvious. To compile a
>   kernel you need a lot of tools with a lot of explicit and implicit
twists
>   to them. It is just a gut feeling that I wouldn't want to rely on this,
>   if I don't have to. The native way just seems the better way to do it to
>   me.

Just because your running on Linux doesn't mean anything because your
duplicating
the environment for cross-compiling anyway. So what does it matter if cygwin
runs
the cross tools or if Linux runs them?



I'm curious ...

How many out there actually are compiling PPC code natively on a PowerPC
Linux box for their embedded devices?

If so, do you run the same development versions on your desktop?

How do you handle the FPU issues?

Craig


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Kerl, John

When starting to do Linux/PPC cross-development about
a year ago (my current workplace is an NT shop) I
experimented with cygwin, for some of the same reasons
as the original poster describes.  & I found that cygwin
was roughly 20x slower than Linux running on the same class
of PC (!).  I could pop the Red Hat CD in the drive and install
the actual OS, & have it up & running in half an hour
-- less time than it took to complete a single,
moderately complex job.  I soon found that cygwin wasn't
saving me any time at all.


-Original Message-
From: Dr. Craig Hollabaugh [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 22, 2002 4:39 PM
To: Marius Groeger; John Fisher
Cc: linuxppc-embedded at lists.linuxppc.org
Subject: RE: cygwin and embedded linux



At 09:36 AM 8/22/2002 +0200, Marius Groeger wrote:
>2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
>   fraction can be a major PITA, because it is not obvious. To compile a
>   kernel you need a lot of tools with a lot of explicit and implicit
twists
>   to them. It is just a gut feeling that I wouldn't want to rely on this,
>   if I don't have to. The native way just seems the better way to do it to
>   me.

Just because your running on Linux doesn't mean anything because your
duplicating
the environment for cross-compiling anyway. So what does it matter if cygwin
runs
the cross tools or if Linux runs them?



I'm curious ...

How many out there actually are compiling PPC code natively on a PowerPC
Linux box for their embedded devices?

If so, do you run the same development versions on your desktop?

How do you handle the FPU issues?

Craig


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Hihn Jason

Why not just set up ONE Linux computer and have people login to it?
Use SAMBA to map drives off the Linux box if you want to use your
proprietary IDEs
-or- use Cygwin Xfree86 (or a proprietary product, i.e. eXceed) to run an X
server and run KDevelop (or whatever off the Linux box with display to your
local windows PC)

With Linux and Unix-based tools and technologies, the possible developmental
infrastructure configurations are endless!

-Jason Hihn
I reserve the right to be wrong.



-Original Message-
From: John Fisher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 21, 2002 9:15 PM
To: linuxppc-embedded at lists.linuxppc.org
Subject: RE: cygwin and embedded linux



> Actually, my personal opinion on that matter is that I'm not very fond
> of using Windows for a Linux kernel development platform. Doing --

So what are the issues: How is cygwin significantly different from Linux
that you would not want to use it?
Are there useful tools that run under Linux but not under cygwin?

The reason I ask is that my organization currently does its software
development under windows using proprietary tools. We have to maintain our
existing products using these tools. We are however contemplating new
development using linux. If we have to dual boot our PCs or have an extra PC
running Linux for each developer, that is going to bring its own set of
nuisances and problems.

Are there others in this situation and how have they chosen to solve it?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Magnus Damm

> Are there others in this situation and how have they chosen to solve it?

Vmware could be one way to solve it. Good if you want to develop and
test
device drivers.

Or use separate Linux boxes and use a X server to connect to them.
There are commercial X servers for Windows like X-Win32 and it should
also be possible to use Xfree86 on Windows for free. Both work great.

That way you can stay on Windows for a while, use the X-Server to access
the Linux box (and other boxes that supports X), and then maybe later
switch to a Linux-only solution.

Another way to solve it would be to switch to Linux and use VNC to
connect
to your Windows boxes. I'm not sure how well this works out, though.

/ magnus

> John Fisher wrote:
>
> > Actually, my personal opinion on that matter is that I'm not very fond
> > of using Windows for a Linux kernel development platform. Doing --
>
> So what are the issues: How is cygwin significantly different from Linux
> that you would not want to use it?
> Are there useful tools that run under Linux but not under cygwin?
>
> The reason I ask is that my organization currently does its software
> development under windows using proprietary tools. We have to maintain our
> existing products using these tools. We are however contemplating new
> development using linux. If we have to dual boot our PCs or have an extra PC
> running Linux for each developer, that is going to bring its own set of
> nuisances and problems.
>
> Are there others in this situation and how have they chosen to solve it?
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread John Fisher

> Actually, my personal opinion on that matter is that I'm not very fond
> of using Windows for a Linux kernel development platform. Doing --

So what are the issues: How is cygwin significantly different from Linux
that you would not want to use it?
Are there useful tools that run under Linux but not under cygwin?

The reason I ask is that my organization currently does its software
development under windows using proprietary tools. We have to maintain our
existing products using these tools. We are however contemplating new
development using linux. If we have to dual boot our PCs or have an extra PC
running Linux for each developer, that is going to bring its own set of
nuisances and problems.

Are there others in this situation and how have they chosen to solve it?


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Marius Groeger

On Thu, 22 Aug 2002, John Fisher wrote:

> > Actually, my personal opinion on that matter is that I'm not very fond
> > of using Windows for a Linux kernel development platform. Doing --
>
> So what are the issues: How is cygwin significantly different from Linux
> that you would not want to use it?

My advise against compiling a kernel and generating boot images (ie.
integrating the parts of an embedded Linux project) is on two grounds:

1. You will only succeed in doing so by emulating a lot of aspects of a
   regular Linux build machine. That's why you need something like Cygwin.
   On that way you are loosing some of Windows's advantages (YMMV), most
   notably and of the GUI features. What you end up with is more or less
   like any Linux terminal, so you might as well do the job on a real
   Windows box that you log on to from your Windows machine, if you must.

2. The "emulation" will never be 100%. Maybe 99%. Maybe 99.99%. That last
   fraction can be a major PITA, because it is not obvious. To compile a
   kernel you need a lot of tools with a lot of explicit and implicit twists
   to them. It is just a gut feeling that I wouldn't want to rely on this,
   if I don't have to. The native way just seems the better way to do it to
   me.

> Are there useful tools that run under Linux but not under cygwin?

Probably you can get pretty many tools for Cygwin too. But it may not be as
easy.

But please don't get me wrong: my point isn't religious: there are
situations where you simply have to use what you're given (at least if
you want to keep your job :-), and Cygwin definitely is a valid
alternative. I'd just not go through this trouble if I don't really
have to.

> The reason I ask is that my organization currently does its software
> development under windows using proprietary tools. We have to maintain our
> existing products using these tools. We are however contemplating new
> development using linux. If we have to dual boot our PCs or have an extra PC
> running Linux for each developer, that is going to bring its own set of
> nuisances and problems.

Well, if you're really jumping ship with the new projects, you should go the
full way and install Linux workstations. You'll have to in the long run. You
could try VMware for the maintainance business. We're using VMware here
quite successfully.

Regards
Marius

-
Marius Groeger   SYSGO Real-Time Solutions GmbH mgroeger at sysgo.de
Software Engineering Embedded and Real-Time Softwarewww.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-22 Thread Wolfgang Denk

John,

in message <000501c24979$6348a190$37d34c93 at neca.nec.com.au> you wrote:
>
> So what are the issues: How is cygwin significantly different from Linux
> that you would not want to use it?

First, you may run into compatibility issues.  It  is  a  non-trivial
task  to  create  a  set  of  tools  that  will  run on more than one
combination of versions of Cygwin and Windoze: a product  that  works
for Cygwin under Windows 2000 may fail if attempted to run on Windows
NT,  let alone Windows 98. Different versions of Cygwin may even have
different layout of the C header files.

Second, many packages need for their build process a couple  of  UNIX
tools  which  are  not  available  on Cygwin. For example: localedef,
mktemp, rpcgen and others.

Finally, you will probably run into  problems  with  NFS  support  on
Windows  hosts.  I'm not sure that you can really create a filesystem
on a Windows box which preserves all the information required  for  a
LInux  root  filesystem,  so that you can actually export if over NFS
for your targets (think about issues like symbolic  and  hard  links,
owners,  groups,  sticky bit [for /tmp], setuid / setgid bits, device
files, ...).

> Are there useful tools that run under Linux but not under cygwin?

Yes.

> The reason I ask is that my organization currently does its software
> development under windows using proprietary tools. We have to maintain our
> existing products using these tools. We are however contemplating new
> development using linux. If we have to dual boot our PCs or have an extra PC
> running Linux for each developer, that is going to bring its own set of
> nuisances and problems.

There are several solutions.

First, and recommended, you can install one  of  a  couple  of  Linux
servers.  It  is  trivial  to  make these resources available to your
developers on Windoze hosts. You don't have to install a new Linux PC
for every developer. Remember that UNIX has a long tradition in using
dumb clients (like VT100 terminals or X11  clients);  a  windows  box
fits nicely into this ;-)

If you still think this is not an option, you don;t have to dual-boot
to use both environments on the same machine. For example, Lineo uses
(used?) vmware to provide a (hidden) Linux box running under  Windows
to  provide  a Linux development environment on Windows systems - you
can do the same.

> Are there others in this situation and how have they chosen to solve it?

Of course there is also the more radical approach: install  Linux  on
all your Windoze boxen, and save a lot of money on M$ licenses ;-)

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The price one pays for pursuing any profession,  or  calling,  is  an
intimate knowledge of its ugly side.  - James Baldwin

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-21 Thread Pete McCormick

> So what are the issues: How is cygwin significantly different from Linux
> that you would not want to use it?
> Are there useful tools that run under Linux but not under cygwin?
> The reason I ask is that my organization currently does its software
> development under windows using proprietary tools. We have to maintain our
> existing products using these tools. We are however contemplating new
> development using linux. If we have to dual boot our PCs or have an extra PC
> running Linux for each developer, that is going to bring its own set of
> nuisances and problems.

I am in a very similar situation as you.  I had a few problems doing things in
cygwin, things not building correctly, no genksyms for the kernel modules,
mount doesn't have all the options that the linux version does (for example
loopback file systems, useful for creating a ramdisk image.), etc.  So I feel
it is less desirable than a linux environment.

The solution that I am trying to implement in my current company is to do the
cross compiling on actual linux servers, using telnet or ssh from the windows
machines.  Running samba on the linux servers will let the windows people use
their current favorite programmer's editors.  If you install cygwin on the
windows machines, you can use their xwindows client Cygwin/XFree86 to run gui
applications remotely, if desired (e.g. DDD or Insight debuggers).


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-21 Thread John Fisher

Is anyone seriously trying to do embedded Linux development for power PC
using Cygwin as the host?

I'm trying to get linux running on proprietary MPC850/860/8260 boards. I'll
start with either the 850 or the 860 board as I'm more familiar with these
processors than with the 8260.

I have the Macraigor blackbird BDM interface for the MPC850/860. I have both
an Agilent ethernet based probe and the Wind River Vision Probe II for the
8260.

All boards will be running with plenty of flash and RAM: 16MB and 32MB
respectively for both the 850 and 860 boards. They will be running with no
disk drive, no monitor and a serial port on SCC3.

I may have real time requirements, but this is yet to be determined.

This is a learning exercise at this stage.


John Fisher
NEC Australia Pty Ltd


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-21 Thread Marius Groeger

On Wed, 21 Aug 2002, John Fisher wrote:

> Is anyone seriously trying to do embedded Linux development for power PC
> using Cygwin as the host?

We will do it for Elinos 3.0. There aren't any release dates fixed,
unfortunately.

Actually, my personal opinion on that matter is that I'm not very fond
of using Windows for a Linux kernel development platform. Doing --
ideally pure ANSI-C/C++ -- application development is a different
story. Thus, I feel it is much more sane to split it right there, if
you must:  develop application code whereever you like, but compile
your kernel and integrate your project on Linux.

Just my $.02,
Marius

-
Marius Groeger   SYSGO Real-Time Solutions GmbH mgroeger at sysgo.de
Software Engineering Embedded and Real-Time Softwarewww.sysgo.de
Voice: +49-6136-9948-0   Am Pfaffenstein 14 www.osek.de
FAX:   +49-6136-9948-10  55270 Klein-Winternheim, Germany   www.elinos.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-21 Thread Magnus Damm

> Is anyone seriously trying to do embedded Linux development for power PC
> using Cygwin as the host?

I've designed a build-system for a customer, and I tried (just to see
how
much that worked ok) to build under Cygwin. Everything worked out ok
until
the system cross compiled glibc-2.1.3. Building glibc generated a error
message that meant something like you-have-bad-memory-on-your-system.
I tried to find the source of the problem with rebuilding and running
memtest86. But no success. But this was maybe a year ago.

The same system works great on Linux boxes.

That's my only experience.

But I have a box from Lynuxworks somewhere here (someone gave it to me)
and that box says that the build system is hosted on windows...

/ Magnus

John Fisher wrote:
>
> Is anyone seriously trying to do embedded Linux development for power PC
> using Cygwin as the host?
>
> I'm trying to get linux running on proprietary MPC850/860/8260 boards. I'll
> start with either the 850 or the 860 board as I'm more familiar with these
> processors than with the 8260.
>
> I have the Macraigor blackbird BDM interface for the MPC850/860. I have both
> an Agilent ethernet based probe and the Wind River Vision Probe II for the
> 8260.
>
> All boards will be running with plenty of flash and RAM: 16MB and 32MB
> respectively for both the 850 and 860 boards. They will be running with no
> disk drive, no monitor and a serial port on SCC3.
>
> I may have real time requirements, but this is yet to be determined.
>
> This is a learning exercise at this stage.
>
> John Fisher
> NEC Australia Pty Ltd
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/





cygwin and embedded linux

2002-08-21 Thread Steven Blakeslee

viosoft has done it

-Original Message-
From: Magnus Damm [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 21, 2002 10:54 AM
To: John.Fisher at nec.com.au
Cc: linuxppc-embedded at lists.linuxppc.org
Subject: Re: cygwin and embedded linux



> Is anyone seriously trying to do embedded Linux development for power PC
> using Cygwin as the host?

I've designed a build-system for a customer, and I tried (just to see
how
much that worked ok) to build under Cygwin. Everything worked out ok
until
the system cross compiled glibc-2.1.3. Building glibc generated a error
message that meant something like you-have-bad-memory-on-your-system.
I tried to find the source of the problem with rebuilding and running
memtest86. But no success. But this was maybe a year ago.

The same system works great on Linux boxes.

That's my only experience.

But I have a box from Lynuxworks somewhere here (someone gave it to me)
and that box says that the build system is hosted on windows...

/ Magnus

John Fisher wrote:
>
> Is anyone seriously trying to do embedded Linux development for power PC
> using Cygwin as the host?
>
> I'm trying to get linux running on proprietary MPC850/860/8260 boards.
I'll
> start with either the 850 or the 860 board as I'm more familiar with these
> processors than with the 8260.
>
> I have the Macraigor blackbird BDM interface for the MPC850/860. I have
both
> an Agilent ethernet based probe and the Wind River Vision Probe II for the
> 8260.
>
> All boards will be running with plenty of flash and RAM: 16MB and 32MB
> respectively for both the 850 and 860 boards. They will be running with no
> disk drive, no monitor and a serial port on SCC3.
>
> I may have real time requirements, but this is yet to be determined.
>
> This is a learning exercise at this stage.
>
> John Fisher
> NEC Australia Pty Ltd
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/