From: John Fisher <hidden> Date: 2002-08-21 07:58:54
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/
From: Magnus Damm <hidden> Date: 2002-08-21 14:54:12
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
From: Marius Groeger <hidden> Date: 2002-08-21 15:54:42
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@sysgo.de
Software Engineering Embedded and Real-Time Software www.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/
From: John Fisher <hidden> Date: 2002-08-22 01:15:20
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/
From: Pete McCormick <hidden> Date: 2002-08-22 03:20:58
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/
From: Marius Groeger <hidden> Date: 2002-08-22 07:36:19
On Thu, 22 Aug 2002, John Fisher wrote:
quoted
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@sysgo.de
Software Engineering Embedded and Real-Time Software www.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/
From: Magnus Damm <hidden> Date: 2002-08-22 11:00:21
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:
quoted
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?
From: Dan Taylor <hidden> Date: 2002-08-23 05:03:58
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:
quoted
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?
From: Jerry Van Baren <hidden> Date: 2002-08-23 13:10:53
At 01:00 PM 8/22/2002 +0200, Magnus Damm wrote:
quoted
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
From: Marius Groeger <hidden> Date: 2002-08-23 13:13:47
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@sysgo.de
Software Engineering Embedded and Real-Time Software www.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/