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/
Restructuring of ibm_ocp_enet driver
On Wed, Aug 21, 2002 at 10:20:28AM -0700, akuster wrote: David Gibson wrote: The patch below make some first steps to restructuring the ibm_ocp_enet driver to separate drivers for the EMAC and MAL components. This is necessary to sanely allocate the various IRQs. It will also be necessary to sanely incorporate the driver into the unified device model. snipped David, I don't see any probelms with this for 2.5. I would like to see these changes done for *devel and it should just easely drop in since I didn't see anything UDM specific. I would like to keep delta between 2.4 and 2.5 to a minimum if at all possible. :) Devel will benefit from this patch because if anyone added support for the HDLC , I would assume it would be done in 2_4_devel and not in 2.5 at this time. Sure. I'm just more comfortable with potential breakage in 2.5. Mind you I think I've discovered several bugs which I'll be fixing as I go. That probably wants to go into 2.4. You're right, nothing is UDM specific as yet. The idea is to first rearrange the driver so it has the right form, then do the actually plugging into the UDM. Oh, and here's the next iteration: diff -urN /home/dgibson/kernel/linuxppc-2.5/drivers/net/ibm_ocp/Makefile linux-bluefish/drivers/net/ibm_ocp/Makefile --- /home/dgibson/kernel/linuxppc-2.5/drivers/net/ibm_ocp/Makefile 2002-08-09 07:27:41.0 +1000 +++ linux-bluefish/drivers/net/ibm_ocp/Makefile 2002-08-21 12:55:05.0 +1000 @@ -13,7 +13,9 @@ obj-$(CONFIG_IBM_OCP_ENET) += ibm_ocp.o -ibm_ocp-objs := ibm_ocp_enet.o ibm_ocp_phy.o ibm_ocp_mal.o +# NB! Link order matters + +ibm_ocp-objs := ibm_ocp_mal.o ibm_ocp_enet.o ibm_ocp_phy.o # Only one of these can ever be set at a time, so this works. ifeq ($(CONFIG_NP405L)$(CONFIG_NP405H)$(CONFIG_440),y) diff -urN /home/dgibson/kernel/linuxppc-2.5/drivers/net/ibm_ocp/ibm_ocp_debug.c linux-bluefish/drivers/net/ibm_ocp/ibm_ocp_debug.c --- /home/dgibson/kernel/linuxppc-2.5/drivers/net/ibm_ocp/ibm_ocp_debug.c 2002-08-09 07:27:41.0 +1000 +++ linux-bluefish/drivers/net/ibm_ocp/ibm_ocp_debug.c 2002-08-21 13:21:08.0 +1000 @@ -109,47 +109,47 @@ printk(KERN_DEBUG MAL DEBUG ** \n); printk(KERN_DEBUG MCR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALCR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALCR)); printk(KERN_DEBUG ESR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALESR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALESR)); printk(KERN_DEBUG IER == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALIER)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALIER)); #ifdef CONFIG_40x printk(KERN_DEBUG DBR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALDBR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALDBR)); #endif /* CONFIG_40x */ printk(KERN_DEBUG TXCASR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXCASR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXCASR)); printk(KERN_DEBUG TXCARR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXCARR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXCARR)); printk(KERN_DEBUG TXEOBISR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXEOBISR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXEOBISR)); printk(KERN_DEBUG TXDEIR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXDEIR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXDEIR)); printk(KERN_DEBUG RXCASR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALRXCASR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALRXCASR)); printk(KERN_DEBUG RXCARR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALRXCARR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALRXCARR)); printk(KERN_DEBUG RXEOBISR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALRXEOBISR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALRXEOBISR)); printk(KERN_DEBUG RXDEIR == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALRXDEIR)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALRXDEIR)); printk(KERN_DEBUG TXCTP0R == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXCTP0R)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXCTP0R)); printk(KERN_DEBUG TXCTP1R == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXCTP1R)); + (unsigned int) get_mal_dcrn(fep-mal, DCRN_MALTXCTP1R)); printk(KERN_DEBUG TXCTP2R == 0x%x\n, - (unsigned int) get_mal_dcrn(fep, DCRN_MALTXCTP2R)); + (unsigned int)
Embedded Planet
An embedded and charset-unspecified text was scrubbed... Name: not available Url: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20020822/bcc901ee/attachment.txt
cygwin and embedded linux
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
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/
PCMCIA on an MPC860
All,
Has anybody had any luck getting PCMCIA to work on an MPC860?
I have a custom MPC860 board, with a single PCMCIA socket connected to Slot B.
This is what I have
so far done:
1.
Downloaded pcmcia-cs-3.2.0.tar.gz
2.
Added board specific definitions in modules/m8xx_pcmcia.c for
hardware_enable()
hardware_disable()
voltage_set()
socket_get()
3.
Cross compiled for the 8xx.
4.
In my kernel (linux-2.4.4-2001-11-24 from Denx) I added the following lines
include/asm-ppc/board.h:
/* define IO_BASE for pcmcia */
#define _IO_BASE 0x8000
#define _IO_BASE_SIZE (1024*64)
arch/ppc/mm/init.c:
void __init MMU_init(void) {
...
ioremap(_IO_BASE,_IO_BASE_SIZE);
...as suggested by Magnus Damm in
http://lists.linuxppc.org/linuxppc-embedded/25/msg00227.html
HOWEVER,
5. When I boot my board with a Flash card in the PCMCIA slot, and I run:
/etc/rc.d/rc.pcmcia start
I find that ide_cs.o causes an Oops when it calls ide_register().
cardctl status
and cardctl ident work though.
Can anybody suggest what I'm doing wrong?
Thanks in advance,
Alex
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
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/
Does Linux support kernel application?
Hi folks, I am new to Linux application development. Does it have such feature as a kernel application? I am trying to find ways to bypass kernel and user space separation in an embedded system design. Thanks, --Khai ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
ocp emac phy wierdness
David, The whole phy idea back when I did it was modeled after the fec.c driver with the thought that at some point we could merge all phy_info structs into a common file. The same idea was applied to the mii routines. I noticed that code/information is duplicated in a few ethernet drivers in ppc. Some of the what you see will be used when we add link support driver, some of the 4xx boards with zmii bridges have interrupt capability. The phy implementation is a project that is not completed. :) Armin David Gibson wrote: There seems to be a whole lot of stuff related to phy handling with no clear purpose to it. The table phy_cmd_config appears to be unused, as are the functions mii_queue_config, mii_display_config. Furthermore process_mii_queue() is dispatched through schedule_task(), from mii_queue_schedule(). But the only place that is called is in ppc405_enet_open(), which immediately calls schedule() to wait for the job to be completed. So what the hell is the point of the schedule_task() rigmarole? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Booting Linux Kernel on a EST8260
Hi,
I am trying to boot the Linux kernel on the EST8260 board.
Board has ppcboot-1.1.6 running.
The procedure I try to do is attached and is here as well.
Several questions.
1) what does message
Warning: real time clock seems stuck!
mean?
2) I was hoping that I have configured the bootargs corectly. But it seems that
something is wrong because of the messages
Looking up port of RPC 13/2 on 10.0.0.245
portmap: server 10.0.0.245 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 15/2 on 10.0.0.245
portmap: server 10.0.0.245 not responding, timed out
Root-NFS: Unable to get mountd port number from server, using default
mount: server 10.0.0.245 not responding, timed out
I configured my nfs (/etc/exports file) like
/usr/src/ELDK/ppc_82xx10.0.0.0/255.255.255.0(rw,no_root_squash,
no_all_squash)
nfs and portmap are running and DHCP is also running (I think)
/rootrpcinfo -p
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
1000111 udp883 rquotad
1000112 udp883 rquotad
151 udp 1039 mountd
151 tcp 1153 mountd
152 udp 1039 mountd
152 tcp 1153 mountd
153 udp 1039 mountd
153 tcp 1153 mountd
132 udp 2049 nfs
/rootps -A |grep nfs
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
10892 pts/2 00:00:00 nfsd
/rootps -A |grep dhcp
10566 ? 00:00:00 dhcpd
DHCP configuration file is as follows
subnet 10.0.0.0 netmask 255.255.255.0 {
option routers 10.0.0.1;
option subnet-mask 255.255.255.0;
option domain-name internal.jaspur.com;
host trgt { hardware ethernet 00:A0:1E:A8:7B:CB;
fixed-address 10.0.0.161;
option root-path /usr/src/ELDK/ppc_82xx;
option host-name trgt;
next-server 10.0.0.245;
filename /tftpboot/pImage;
}
}
However what worries me is that there are no messages on my host machine when I
do the 'tcpdump'
Image I am trying to boot on the board is the image I compiled with the
following procedure:
'make mrproper'
'make est8260_config'
'make oldconfig'
'make dep'
'make pImage'
and I donwloaded this image as described bellow, as to say I did not change
anything in the configuration. This means that the NFS is configured in my
kernel and also BOOTP protocol for 'IP level autocofiguration'
Thanks in advance,
Cheers
Dejan
==
PPCBoot 1.1.6 (Jul 24 2002 - 14:56:02)
MPC8260 Reset Status: External Soft, External Hard
MPC8260 Clock Configuration
- Bus-to-Core Mult 3x, VCO Div 2, 60x Bus Freq 33-100, Core Freq 100-300
- dfbrg 0, corecnf 0x08, busdf 3, cpmdf 1, plldf 0, pllmf 1
- vco_out 26400, scc_clk 6600, brg_clk 6600
- cpu_clk 19800, cpm_clk 13200, bus_clk 6600
CPU: MPC8260 (Rev 01, Mask A.1 1K22A-XC) at 198 MHz
Board: EST SBC8260
I2C: ready
DRAM: 16 MB
FLASH: 4 MB
In:serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
= tftpboot 20 pImage
ARP broadcast 1
TFTP from server 10.0.0.245; our IP address is 10.0.0.161
Filename 'pImage'.
Load address: 0x20
Loading: #
#
done
Bytes transferred = 457136 (6f9b0 hex)
= setenv bootargs root=/dev/nfs rw nfsroot=10.0.0.245:/usr/src/ELDK/ppc_82xx
ip=10.0.0.161:10.0.0.245:::trgt::off
= bootm 20
## Booting image at 0020 ...
Image Name: Linux-2.4.4
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:457072 Bytes = 446 kB = 0 MB
Load Address:
Entry Point:
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Total memory = 16MB; using 0kB for hash table (at )
Linux version 2.4.4 (root at jebac.internal.jaspur.com) (gcc version 2.95.3
20010111 (prerelease/franzo/20010111)) #1 Wed Au
g 14 17:17:49 CDT 2002
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw nfsroot=10.0.0.245:/usr/src/ELDK/ppc_82xx
ip=10.0.0.161:10.0.0.245:::trgt::off
Warning: real time clock seems stuck!
Calibrating delay loop... 131.89 BogoMIPS
Memory: 14796k available (868k kernel code, 364k data, 48k init, 0k highmem)
Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 1024 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
CPM UART driver version 0.02
ttyS0 on SMC1 at 0x, BRG7
ttyS1
MPC857T FEC/MII failure
Hello, I am experiencing a problem with the MPC857T FEC's MII interface. I want to read MII registers for our PHY (ID 24 on our board). Per the MPC857T manual: * I write 0x36 to MII_SPEED (IMMR + 0xe84). An oscilloscope probe on the PHY's MDC pin reveals a 1.235 MHz rate, within spec. * I write 0x6c06 to MII_DATA (IMMR + 0xe80). This is: - ST=01 - OP=10 - ID=11000 - REG=1 - TA=10 The data read back in the second 16 bits of MII_DATA are always 0x. This is in fact regardless of the PHY ID (I've tried all 32) or register (I've tried all 32). There are two concomitant symptoms: * If I put oscilloscope probes on the PHY's MDC and MDIO pins, then look at the MDIO pin's values at the rising edges of MDC, I see that the FEC has actually written the following: - ST=01 - OP=10 - ID=11000 - REG=1 - TA=11 which is *not* what I asked it to do. * If I read back the MII_DATA register, *even though* I wrote 0x6c06, I read back the value 0x6c07. Note that the second 6 is now a 7. In short, I formulate a compliant request (TA=10), then the FEC mangles it (TA=11) and drives that out. It is no wonder the PHY doesn't respond. This problem is observable in our debug monitor using simple peek and poke. Thus, this is more of a PPC question than a Linux question. Has anyone seen anything similar? Thanks. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
MPC857T FEC/MII failure
P.S. Please cc me regarding the previous question. Thanks. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
fast ethernet LXT972A support
I noticed that only LXT970 and 971 are supported in the lastest kernel distribution from DENX. But the comments in fec.c say includes support for following PHYs: QS6612, LXT970, LXT971/2. Does it mean that LXT972 can use 971's driver? If not, basically what kind of modification is needed? Thanks. - Shawn. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
fast ethernet LXT972A support
for following PHYs: QS6612, LXT970, LXT971/2. Does it mean that LXT972 can use 971's driver? If not, basically what kind of modification is needed? Thanks. After looking into LXT971/972 datasheets, I believe LXT972 can use 971's driver. Thanks. - Shawn. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
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
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
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/
fast ethernet LXT972A support
distribution from DENX. But the comments in fec.c say includes support for following PHYs: QS6612, LXT970, LXT971/2. Does it mean that LXT972 Well, the first several lines of comments says that. ;) Ummm you must be looking in the wrong place; our kernel version supports AMD79C874, LXT970, LXT971, QS6612, DP83843, and DP83846A on MPC8xx processors, and AMD79C873, LXT970, LXT971, QS6612 on MPC8260 Well, the version I got is linux-2.4.4-08-09. And I'm sure there are no DP83843 and DP83846A support. So you must have made progress in supporting new PHYs. :) The file I'm looking at is arch/ppc/8xx_io/fec.c. - Shawn. ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
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/
8260 Memory Management
Since the 8260 is based on a PPC 603e core, is there any reason why the memory management should differ from the other Mac implementations? The real difference is the CPM and the embedded peripheral support. Would it be reasonable to make the 8260 memory management consistent with the rest of the 6xx processors? ** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
cygwin and embedded linux
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/
