From owner-vxwexplo-process Tue Dec 1 09:29:03 1998 From: Hamid Shoaee Date: Tue Dec 1 09:29:06 PST 1998 Subject: Booting VxWorks from Flash memory or eproms Does anyone know if it's possible to boot VxWorks from flash memory or EPROM rather than through the network. In particular, it would be very useful if at boot time it could check for the presence of boot image in flash/prom and failing that then it would try the network option. I would appreciate any information on this option. Hamid Shoaee Stanford Linear Accelerator Center Stanford, CA From owner-vxwexplo-process Tue Dec 1 11:29:32 1998 From: "Keith Buchanan" Date: Tue Dec 1 11:29:35 PST 1998 Subject: RE: Booting VxWorks from Flash memory or eproms > Does anyone know if it's possible to boot VxWorks from flash memory or > EPROM rather than through the network. In particular, it would be very > useful if at boot time it could check for the presence of boot image in > flash/prom and failing that then it would try the network option. I would > appreciate any information on this option. VxWorks will boot from EPROM or flash if your target and BSP author chose to support and test the options. The programmer's guide includes instructions on how compile standalone versions (compressed, uncompressed, text in ROM, etc) of vxWorks that includes your application. SPARTA often modifies the boot sequence, adding the capability to boot from a file system in memory.(could be flash, EPROM, NVRAM, etc) The boot sequence then convienently resembles the network boot cycle.(provided WRS continues to support startup scripts!!) It is fairly easy to alter the boot sequence to try multiple boot options. The current boot options already return control to the boot configuration interface when they fail. You just have to insert code to try again in a chosen order. adios ---------------------------------- /\\ Thomas Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 519 Interstate 30 / \\\\\ \\ Suite 140 \ \\\\\ // Rockwall, TX 75087 \ ////// \////// Voice: 972 672 9657 \//// FAX: 972 722 1216 \// WWW: www.sparta.com From owner-vxwexplo-process Tue Dec 1 11:54:52 1998 From: Fred Roeber Date: Tue Dec 1 11:54:56 PST 1998 Subject: Re: Booting VxWorks from Flash memory or eproms Hamid Shoaee asks about vxworks: > Does anyone know if it's possible to boot VxWorks from flash memory or > EPROM rather than through the network. In particular, it would be very > useful if at boot time it could check for the presence of boot image in > flash/prom and failing that then it would try the network option. I would > appreciate any information on this option. This is definitely possible. We have systems that boot standalone right from FLASH. The normal VxWorks bootrom starts up a minimalistic version of VxWorks from EPROM. We took parts of the bootrom code (from config/all/bootConfig.c) and parts of the normal downloaded VxWorks image (from config/all/usrConfig.c) and melded them together to get a full function standalone image. I suggest studying the code components that are built into the bootrom image for your board and downloaded image to see how the two images work. Then you can just cut-and-paste from the two images to get the image you want. Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | | TraceMaker product manager -> www.tracemaker.bbn.com | From owner-vxwexplo-process Tue Dec 1 12:10:21 1998 From: Charlie Grames Date: Tue Dec 1 12:10:25 PST 1998 Subject: sysBusToLocalAdrs() VxWorks 5.3.1 MVME2700 1.1/4 I have a question about the behavior of sysBusToLocalAdrs(). But first, I'd like to share my own observations. The mv2604 BSP man page for sysLocalToBusAdrs() says: "This routine returns a VMEbus address as it would be seen on the bus. The local address that is passed into this routine is the address of the local resource as seen by the CPU." Indeed, this routine works as described. The mv2604 BSP man page for sysBusToLocalAdrs() says: "This routine returns a local address that is used to access the VMEbus. The bus address that is passed into this routine is the VMEbus address as it would be seen on the bus." This description seems a little vague, and I could interpret it in two ways: 1) The local address returned is always assumed to be off-board. If you tried to use the address to access an on-board resource, it would fail. For example, if the calling board were mapped to the VMEbus, the CPU address of local memory were zero, the VMEbus address of the board were 0x08000000, and the CPU address of VMEbus location 0x08000000 were 0x10000000, the value returned by sysBusToLocalAdrs() when called with a bus address of 0x08000000 would be 0x10000000. 2) The local address returned is appropriate for either on-board or off-board accesses. For example, if the calling board were mapped to the VMEbus, the CPU address of local memory were zero, the VMEbus address of the board were 0x08000000, and the CPU address of VMEbus location 0x08000000 were 0x10000000, the value returned by sysBusToLocalAdrs() when called with a bus address of 0x08000000 would be 0. I know for a fact that the mv2604/mv2700 implementation of sysBusToLocalAdrs() matches interpretation 1). My question (finally) is: Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same way? I'd appreciate a response from as wide a variety of BSP users as possible. Thanks in advance. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com From owner-vxwexplo-process Tue Dec 1 12:42:11 1998 From: Charlie Grames Date: Tue Dec 1 12:42:14 PST 1998 Subject: Booting VxWorks from Flash memory or eproms -Reply Hamid, It is possible to boot VxWorks from flash or ROM, though booting from ROM or the network is not an either/or proposition (unless you design your own application to boot from ROM which, in turn, boots VxWorks from ROM or in the "traditional" manner). The procedure for building a standalone VxWorks is documented in the Tornado User's Guide in the "Creating Bootable Applications" section. The actual process of getting into your flash is hardware-specific. HTH Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/01/98 11:29am >>> Submitted-by owner-vxwexplo-process Tue Dec 1 09:29:03 1998 Submitted-by: Hamid Shoaee Does anyone know if it's possible to boot VxWorks from flash memory or EPROM rather than through the network. In particular, it would be very useful if at boot time it could check for the presence of boot image in flash/prom and failing that then it would try the network option. I would appreciate any information on this option. Hamid Shoaee Stanford Linear Accelerator Center Stanford, CA From owner-vxwexplo-process Tue Dec 1 15:39:53 1998 From: pbrett@hathaway-systems.com Date: Tue Dec 1 15:39:57 PST 1998 Subject: Re: Booting VxWorks from Flash memory or eproms -----Original Message----- From: the vxWorks Users Group Exploder To: vxworks_users@csg.lbl.gov Date: Tuesday, December 01, 1998 3:07 PM Subject: Booting VxWorks from Flash memory or eproms >Submitted-by owner-vxwexplo-process Tue Dec 1 09:29:03 1998 >Submitted-by: Hamid Shoaee > > >Does anyone know if it's possible to boot VxWorks from flash memory or >EPROM rather than through the network. In particular, it would be very >useful if at boot time it could check for the presence of boot image in >flash/prom and failing that then it would try the network option. I would >appreciate any information on this option. > > Yes. Pretty much anything is possible. I have worked on two projects which have taken radically different approaches to this. 1) The highly custommised version. The hardware has 16 MB of DRAM and 1 MB flash. Some standalone code (written in a combination of assember and C) resides in the bootblock of the flash device. The memory is arranged so that the bootblock is pointed to by the reset vector. On reset, the initial code which runs sets up global descriptor tables etc (x86 architecture) and copies another program from the bootblock to DRAM. The thread of execution then jumps to this point in DRAM. The remainder of the flash is divided into code blocks and configuration blocks. CRCs of these blocks are now checked. If any do not match, then the system prints a message to the LCD and waits for code / configuration to be sent using XModem to a serial port. Once the transfer is complete, the system reboots. If the CRCs check out OK, the vxWorks image (with application statically linked to it) is copied from flash to DRAM. finally the custom code jumps to the entry point of the vxWorks image. The main reason for the complexity of this solution was that no vxWorks image would fit into the bootblock of the selected flash device. 2) If you do not want to damage brain cells The other project uses a SanDisk flash disk. This device looks pretty much like a standard IDE disk. First boot a PC with the SanDisk installed to DOS. Format the SanDisk, and run vxsys on it. Next make bootrom_uncmp and vxWorks. From bootrom_uncmp create bootrom.sys by "vxcopy bootrom_uncmp bootrom.sys" copy bootrom.sys followed by vxWorks and vxWorks.sym onto the SanDisk. Install the SanDisk in the target and boot the system with a bootline something like: ata=0,0(0, 0){HOST:}/ata0/vxWorks e={target_ip_address} h = {host_ip_address} u = {user_name} pw = {password} tn = {target name} o = {ethernet device} It is unlikely that either of these solutions will entirely meet your needs, but I hope they will give you an idea of what is possible and the work involved. My employer will not allow me to release source, but if I can be of any further help otherwise, let me know. Regards, Pete From owner-vxwexplo-process Tue Dec 1 15:51:21 1998 From: "John R. Moore III" Date: Tue Dec 1 15:51:24 PST 1998 Subject: Re: sysBusToLocalAdrs() A constant source of confusion: Because sysBusToLocalAdrs and sysLocalToBusAdrs are not inverses of each other, and usually only have enough information to do the address translation in one direction, interpretation 2 does not work in the general case. I haven't seen a BSP whose sysBusToLocalAdrs would know that you were selecting the calling boards local address if presented with its VME slave address. Of course you could extend the function yourself to do this. The MV162 (68k), MV167(68k), Heurikon V4D(68k), Themis SPARC, Force SPARC, and the VME based x86 processors that I have worked with all adhere to interpretation 1. The set of registers (on the VME interface chip) that allow master access to the bus, will reflect how sysBusToLocalAdrs functions, and the set of registers that control slave access to the board, reflect how sysLocalToBusAdrs functions. the vxWorks Users Group Exploder wrote: ... > I have a question about the behavior of sysBusToLocalAdrs(). But > first, I'd > like to share my own observations. ... > The mv2604 BSP man page for sysBusToLocalAdrs() says: "This routine > returns > a local address that is used to access the VMEbus. The bus address > that is > passed into this routine is the VMEbus address as it would be seen on > the > bus." This description seems a little vague, and I could interpret it > in > two ways: ... > 2) The local address returned is appropriate for either on-board or > off-board accesses. For example, if the calling board were mapped to > the > VMEbus, the CPU address of local memory were zero, the VMEbus address > of the > board were 0x08000000, and the CPU address of VMEbus location > 0x08000000 > were 0x10000000, the value returned by sysBusToLocalAdrs() when called > with > a bus address of 0x08000000 would be 0. > > I know for a fact that the mv2604/mv2700 implementation of > sysBusToLocalAdrs() matches interpretation 1). My question (finally) > is: > Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same > way? > I'd appreciate a response from as wide a variety of BSP users as > possible. -- ------------------------------------------------------------ |John R. Moore | Voice -> 703 448 1683 x229 | |Principal Engineer | FAX -> 703 893 5494 | |EMAIL: | On the WEB! | |jrm@mclean.sparta.com | http://www.mclean.sparta.com | |___________________________|______________________________| | | | | /\\ SPARTA, Inc. | | | ///\\ 7926 Jones Branch Drive | | | /////\\ Suite 900 | | | ///// \\ McLean, VA 22102 | | | / \\\\\ \\ 703-448-0120 | | | \ \\\\\ // | | | \ ////// | | | \////// SPARTA | | | \//// Pride In Performance | | | \// -------------------- | | ------------------------------------------------------------ From owner-vxwexplo-process Tue Dec 1 16:25:51 1998 From: "James B. Hawthorne" Date: Tue Dec 1 16:25:54 PST 1998 Subject: Connecting a PC to VxWorks NFS Server VxWorkers- I am trying to connect a PC running Hummingbird's NFS Client software to an MVME162-533 running Tornado with the NFS Server option turned on. We have been able to mount the exported directories from a UNIX machine running Solaris and have verified proper configuration of the VxWorks NFS server. When trying to connect with Hummingbird from the PC, it seems to expect the server to be running pcnfsd or hclnfsd. This makes sense on a UNIX server but I am not aware of any such daemon that runs on the VxWorks system. Does anyone have experience with this type of configuration and were you successful in making the connection? Stuck in HELLstf at White Sands Missle Range... Jim ************************************************************ Jim Hawthorne Voice: (505) 767-1228 Applied Technology Associates Fax: (505) 768-1379 1900 Randolph Road SE email: jbhawth@aptec.com Albuquerque, NM 87106 Web: http://www.aptec.com/ ************************************************************ From owner-vxwexplo-process Tue Dec 1 16:32:29 1998 From: Tom Antles Date: Tue Dec 1 16:32:32 PST 1998 Subject: dosFsLib patch increases mem usage 8X or more tornado vxworks Has anyone else run into memory usage problems with the latest dosFsLib Patch? ( I believe it was approx 8/98 and goes by any of the following SPRs: 21475, 9465, 4061, 8721, 9057 ...) This dosFsLib patch is requesting more than 1.5Mbytes of memory while running in the bootrom and causing memPartAlloc failures. A comparison before and after the patch shows: - pre dosFsLib patch: The call to dosFsDevInit from usrIdeConfig resulted in alloc of ~200Kbytes - post dosFsLib patch: The call to dosFsDevInit from usrIdeConfig resulted in memPartAlloc failure after allocating 1.5Mbytes. This means that it requested almost 8 times more memory and still didn't get enough. This is a problem since this is happening in a bootcode executing at RAM_HIGH_ADRS, where we typically only allocate 1Meg total space for both code and system memory partition (we tried 2Meg for the experiment above and still didn't get enough - the code was approx 500Kbytes, the free list 1.5Mbytes). Fundamentally it seems that something must be wrong to need 1.5MBytes to represent the ~300 files on our hard drive. Also, the 8X growth factor doesn't seem right either. Even though I haven't checked yet, it most likely means that our applications will need/use this much more memory too, which is not desirable either. Tom Antles antles@spk.hp.com Phone: (509) 921-3590 Fax: (509) 921-3991 From owner-vxwexplo-process Wed Dec 2 10:30:57 1998 From: Anthony Le Date: Wed Dec 2 10:31:00 PST 1998 Subject: VxWorks and PC104 Hi Users: Does anyone currently use the generic VxWorks 486 kernel with PC104 board? I am also looking for Analog IO and Digital IO modules for PC104 which VxWorks currently supports. If you have this PC104 configuration, I like to hear from you. Anthony Le LAM Research Corp. anthony.le@lamrc.com From owner-vxwexplo-process Wed Dec 2 15:03:44 1998 From: Hesham_Elbakoury@BayNetworks.COM (Hesham Elbakoury) Date: Wed Dec 2 15:03:47 PST 1998 Subject: VxWorks vx other Real-time OS From your experience with vxWorks and windRiver systems what are the most important reasons why one would choose VxWorks instead of another real-time OS like Nucleus ? Regards Hesham From owner-vxwexplo-process Thu Dec 3 01:41:16 1998 From: "Alex Reznik" Date: Thu Dec 3 01:41:21 PST 1998 Subject: Re: Booting VxWorks from Flash memory or eproms Hi, the answer is: "shurely, YES". There is the special kind of vxWorks' image which is called "vxWorks ROM-resident". This image can be built by usual make procedure from a standard BSP. The details are described in the "Configuration" section of "vxWorks Programmers Guide". The only preparation that is not described there and seems absolutely necessary is to adjust jumpers on your target in purpose to start from the address which is assigned to the EPROM with vxWorks. There is the second possibility - to use any of FlashFile systems which are implemented for vxWorks: to put (to copy) the vxWorks image onto the Flash device, and to change slightly the file "bootConfig.c" of your BSP. The goal of this change is to define a Flash device as one of possible "boot devices". Then you should build the modified vxWorks bootROM. If your vxWorks bootROM will understand a Flash device as one of "boot" devices you are free to use the same vxWorks image for downloading both from network and from the Flash (just copy it on the Flash device). Regards, Alex Reznik. alexr@telegate.co.il > >Does anyone know if it's possible to boot VxWorks from flash memory or >EPROM rather than through the network. In particular, it would be very >useful if at boot time it could check for the presence of boot image in >flash/prom and failing that then it would try the network option. I would >appreciate any information on this option. > >Hamid Shoaee >Stanford Linear Accelerator Center >Stanford, CA > From owner-vxwexplo-process Thu Dec 3 01:51:26 1998 From: "Alex Reznik" Date: Thu Dec 3 01:51:29 PST 1998 Subject: Re: sysBusToLocalAdrs() Hello, for mv2304 BSP (MVME23XX boards) it is right too. Enjoy, Alex Reznik Telegate Ltd alexr@telegate.co.il -Subject: sysBusToLocalAdrs() >Submitted-by owner-vxwexplo-process Tue Dec 1 12:10:21 1998 >Submitted-by: Charlie Grames > >VxWorks 5.3.1 >MVME2700 1.1/4 > >I have a question about the behavior of sysBusToLocalAdrs(). But first, I'd >like to share my own observations. > >The mv2604 BSP man page for sysLocalToBusAdrs() says: "This routine returns >a VMEbus address as it would be seen on the bus. The local address that is >passed into this routine is the address of the local resource as seen by the >CPU." Indeed, this routine works as described. > >The mv2604 BSP man page for sysBusToLocalAdrs() says: "This routine returns >a local address that is used to access the VMEbus. The bus address that is >passed into this routine is the VMEbus address as it would be seen on the >bus." This description seems a little vague, and I could interpret it in >two ways: > >1) The local address returned is always assumed to be off-board. If you >tried to use the address to access an on-board resource, it would fail. For >example, if the calling board were mapped to the VMEbus, the CPU address of >local memory were zero, the VMEbus address of the board were 0x08000000, and >the CPU address of VMEbus location 0x08000000 were 0x10000000, the value >returned by sysBusToLocalAdrs() when called with a bus address of 0x08000000 >would be 0x10000000. > >2) The local address returned is appropriate for either on-board or >off-board accesses. For example, if the calling board were mapped to the >VMEbus, the CPU address of local memory were zero, the VMEbus address of the >board were 0x08000000, and the CPU address of VMEbus location 0x08000000 >were 0x10000000, the value returned by sysBusToLocalAdrs() when called with >a bus address of 0x08000000 would be 0. > >I know for a fact that the mv2604/mv2700 implementation of >sysBusToLocalAdrs() matches interpretation 1). My question (finally) is: >Do other BSPs intepret the behavior of sysBusToLocalAdrs() the same way? >I'd appreciate a response from as wide a variety of BSP users as possible. > >Thanks in advance. > >Charlie Grames >The Boeing Company >(314) 233-1956 >Charles.R.Grames@boeing.com > From owner-vxwexplo-process Thu Dec 3 11:28:44 1998 From: Anthony Le Date: Thu Dec 3 11:28:47 PST 1998 Subject: [Fwd: VxWorks and PC104 (fwd)] This is a multi-part message in MIME format. --------------A0DBFF75ACF9B61628DB4C22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------A0DBFF75ACF9B61628DB4C22 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from lamrc.lamrc.com by softeng.lamrc.com (4.1/SMI-4.1) id AA18225; Thu, 3 Dec 98 04:27:47 PST Received: from serverm.lamrc.com by lamrc.lamrc.com via ESMTP (951211.SGI.8.6.12.PATCH1042/951211.SGI) for id EAA16346; Thu, 3 Dec 1998 04:27:31 -0800 Received: from out.esrf.fr (firewall.esrf.fr [193.49.43.1]) by serverm.lamrc.com (8.9.0/8.9.0) with SMTP id EAA17831 for ; Thu, 3 Dec 1998 04:26:41 -0800 (PST) Received: (from uucp@localhost) by out.esrf.fr (8.6.10/8.6.10) id NAA08370 for ; Thu, 3 Dec 1998 13:21:41 +0100 Received: from esrf.esrf.fr(160.103.2.9) by firewall via smap (V1.3) id tmp008241; Thu Dec 3 13:20:50 1998 Received: from freak.esrf.fr (freak.esrf.fr [160.103.5.78]) by esrf.esrf.fr (8.6.10/8.6.9) with SMTP id NAA09799; Thu, 3 Dec 1998 13:23:35 +0100 Received: from localhost by freak.esrf.fr with SMTP (1.37.109.4/16.2) id AA01175; Thu, 3 Dec 98 13:25:21 +0100 Sender: petri@esrf.fr Message-Id: <3666832F.D98EB2CD@esrf.fr> Date: Thu, 03 Dec 1998 13:25:20 +0100 From: Petri Makijarvi Organization: E.S.R.F. X-Mailer: Mozilla 4.04 [en] (X11; I; HP-UX A.09.01 9000/715) Mime-Version: 1.0 To: anthony.le@lamrc.com Subject: Re: VxWorks and PC104 (fwd) References: <199812031203.NAA24215@libra.esrf.fr> Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit X-Mozilla-Status2: 00000000 Hi, one of my Tornado/vxWorks/68k using colleagues forwarded this mail to me, don't know its origin but I will try to answer nevertheless... > Forwarded message: > Subject: VxWorks and PC104 > > Hi Users: > > Does anyone currently use the generic VxWorks 486 kernel with PC104 board? > > I am also looking for Analog IO and Digital IO modules for PC104 which VxWorks > currently supports. > > If you have this PC104 configuration, I like to hear from you. > > Anthony Le > LAM Research Corp. > anthony.le@lamrc.com I have used in an odd project a vxWorks 486 kernel on a PC/104 CPU board. I don't know what you mean with "generic" but I presume that you mean the original one in the Tornado 1.0.1 BSP delivery. I couldn't get my PC/104 running with that, but that is probably because I didn't use any IDE, spinning hard disk but the local MS-DOS FAT12 Flash hard disk. Additionally I had an onboard Ethernet controller so to me it was a natural thing to regenerate the kernel with my settings. It worked fine in my project. I have written some integration details for my PC/104 superMOPSpro CPU board in: http://www.esrf.fr/computing/cs/sysadmin/rtk/pc104project/howto/vxworks.htm The configuration settings you could find by browsing a little the project's download area in http://www.esrf.fr/computing/cs/sysadmin/rtk/pc104project/howto/download/ We didn't use any particular PC/104 I/O cards with vxWorks in the project, but just on-board resources, such as serial lines. Everything went well with the project and I was happy with Tornado/vxWorks. But today we have big Flash-IDE disks and we put Linux on them - its free... You'll find more details in the above site, as well. Hope that this helped you a bit, Petri -- Petri Makijarvi - European Synchrotron Radiation Facility mailto:petri@esrf.fr - http://www.esrf.fr/computing/cs/sysadmin/rtk/ tel: +33-(0)4.76.88.22.50 fax: +33-(0)4.76.88.20.20 E.S.R.F. B.P 220 F-38043 Grenoble Cedex France --------------A0DBFF75ACF9B61628DB4C22-- From owner-vxwexplo-process Tue Dec 8 02:17:41 1998 From: Mark Armstrong Date: Tue Dec 8 02:17:44 PST 1998 Subject: VxWorks NFS and the automounter on Solaris 2.6 Hello everyone, I'm sure some of you remember VxWorks 5.2 and that it can be setup to allow NFS mountable disks. This works great with Solaris 2.4, you can even mount and auto-mount VxWorks RAM disks without a problem. Then Sun in there wisdom moved onto NFS version 3 for Solaris 2.5 and 2.6. You can still mount but auto-mounting no longer works. The Solaris machine complains: > automountd[]: No network locking on VW-TARGET > Contact admin to install server change. Does anyone know a quick fix for this? Hope someone can help. Mark Armstrong Kaon Ltd. From owner-vxwexplo-process Tue Dec 8 05:35:56 1998 From: heller@nm.picker.com (Mark Heller) Date: Tue Dec 8 05:35:59 PST 1998 Subject: blaster/blastee programs for vxWorks Hello All, I'm trying to find the blaster/blastee for Vxworks to enable me to test networking performance. Any pointers would be appriciated. Thanks in advance. ------- -Mark ------- Mark Heller Picker International Inc. Nuclear Medicine Division heller@nm.picker.com VxWorks Tornado VxWorks Tornado From owner-vxwexplo-process Tue Dec 8 06:52:27 1998 From: Jerald Pendleton Date: Tue Dec 8 06:52:30 PST 1998 Subject: Re: blaster/blastee programs for vxWorks At 05:36 AM 12/8/98 -0800, the vxWorks Users Group Exploder wrote: >Submitted-by owner-vxwexplo-process Tue Dec 8 05:35:56 1998 >Submitted-by: heller@nm.picker.com (Mark Heller) > > > >Hello All, > > I'm trying to find the blaster/blastee for > Vxworks to enable me to test networking > performance. > > Any pointers would be appriciated. > > Thanks in advance. > >------- > >VxWorks Tornado VxWorks Tornado > All the demo code (blaster and blastee are part of the demo code) can be found on Windsurf. HTH, Jerald Pendleton ------------ Manager - WRS Sustaining Engineering email: jerald@wrs.com "Exacerbate Obfuscation" From owner-vxwexplo-process Tue Dec 8 08:37:57 1998 From: Ian.Kerr@bae.co.uk Date: Tue Dec 8 08:38:00 PST 1998 Subject: Tornado/VxWorks Hello, Does anyone know if any version of VxWorks has been certified to the following FAA (and CAA in the UK) required standard? RTCA (Requirements and Technical Concepts for Aviation) DO-178B "Software Considerations in Airborne Systems and Equipment Certification" Some systems integrators have been unable to use it as they may have had problems with certification. Some seem to be planning to use it on their aircraft. Anyone? N.B. Can some one post this to comp.risks and relay the results back as we do not have the technology here? Thanks in advance. Ian Kerr. From owner-vxwexplo-process Tue Dec 8 10:57:09 1998 From: Alistair Adams Date: Tue Dec 8 10:57:13 PST 1998 Subject: Unresolved symbols in a loaded module VxWorks 5.3 PowerPC Does anyone know if there is a way to determine if there are any unresolved symbols in a loaded module. The documantation for loadModuleAt() states that NULL will be returned if there are unresolved symbols. I believe this may have been true for VxWorks 5.2 but it certainly does not appear to be true for the version we are using. Alistair Adams Octant Technologies Inc. From owner-vxwexplo-process Tue Dec 8 11:01:03 1998 From: Kevin Bradley Date: Tue Dec 8 11:01:06 PST 1998 Subject: GCC, Linux, VxWorks Page: New Home Announcing the new home of the "GCC for VxWorks under Linux" page, now hosted by Sparta: http://linux.sparta.com/VxWorks The new page maintainer is Bruce O. Benson (benson@sparta.com); redirect any queries to him. I hope you will find the page useful. As compiler technology is always advancing (witness the successes of egcs, http://egcs.cygnus.com) faster than "official" releases of compilers (gcc 2.7.2, included in the Tornado 1.0.1 release, is dated Nov. 29, 1995 on Sunsite -- http://metalab.unc.edu/pub/gnu/), enterprising software designers will want to use the advanced features in new compilers. Building your own GNU cross-compiler is feasible under most UNIX systems (and under NT as well); this page just addresses an observed lack for VxWorks. All queries to the old address will be pointed to the new host. -- Kevin From owner-vxwexplo-process Tue Dec 8 12:54:30 1998 From: "Blake, Don" Date: Tue Dec 8 12:54:34 PST 1998 Subject: RE: Tornado/VxWorks (DO-178B Certification) We had a couple of conversations with Wind River about DO-178B certification. We discussed the possibility of WRS supplying a "kit" that would facilitate certification of a system that used VxWorks. So far, we have had no feedback from WRS. I believe that they didn't feel there was a large enough market to justify the required investment. Depending on the DO-178B level desired, this could be quite an investment. Don Donald R. Blake Sr. Programmer Lockheed Martin Federal Systems 1802 State Route 17C Owego, NY 13827-3994 -----Original Message----- From: vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov] Sent: Tuesday, December 08, 1998 11:38 AM To: vxworks_users@csg.lbl.gov Subject: Tornado/VxWorks Submitted-by owner-vxwexplo-process Tue Dec 8 08:37:57 1998 Submitted-by: Ian.Kerr@bae.co.uk Hello, Does anyone know if any version of VxWorks has been certified to the following FAA (and CAA in the UK) required standard? RTCA (Requirements and Technical Concepts for Aviation) DO-178B "Software Considerations in Airborne Systems and Equipment Certification" Some systems integrators have been unable to use it as they may have had problems with certification. Some seem to be planning to use it on their aircraft. Anyone? N.B. Can some one post this to comp.risks and relay the results back as we do not have the technology here? Thanks in advance. Ian Kerr. From owner-vxwexplo-process Tue Dec 8 14:01:20 1998 From: "Pete Brett" Date: Tue Dec 8 14:01:24 PST 1998 Subject: Re: Unresolved symbols in a loaded module > >Does anyone know if there is a way to determine if there are any >unresolved symbols in a loaded module. > How are you loading the module? When I execute ld < {module_name} from the host or target resident shell, any unresolved symbol names are printed out. When I use the debugger to load the module, a message box appears in Tornado showing me the names of any unresolved symbols. I am using Tornado 1.0.1 for an x86 target. If you are using loadModuleAt() from your code, it should be fairly easy to generate an object file with a symbol which is not present in the target and use the debugger to check the returned value. You could also try printErrno from the shell, perror or logMsg(" Date: Tue Dec 8 14:07:50 PST 1998 Subject: Throw/Catch We have a developer here that has decided that using the Throw/Catch exception handling of C++ would be a good thing. Mental judgements aside, we have attempted this with the bundled G++ that comes with Tornado, and have run into a sticky wicket - to wit: Using the -fhandle_exceptions introduces a number of undefined symbols, that appear to deal with setting up and dealing with the jumps needed to do exception processing. Is there some trick I am not aware of, or am I SOL? Target system is 68K (MVME 167) -- Michael Baumann Optivus Technology Inc.|Loma Linda University Medical Center San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu From owner-vxwexplo-process Tue Dec 8 15:03:01 1998 From: Andreas Wolf Date: Tue Dec 8 15:03:05 PST 1998 Subject: RE: Throw/Catch Hi, > Submitted-by: "Michael Baumann" > > We have a developer here that has decided that using the Throw/Catch > exception handling of C++ would be a good thing. > Mental judgements aside, we have attempted this with the bundled > G++ that comes with Tornado, and have run into a sticky wicket - > to wit: Using the -fhandle_exceptions introduces a number of undefined > symbols, that appear to deal with setting up and dealing with > the jumps needed to do exception processing. > Is there some trick I am not aware of, or am I SOL? > Target system is 68K (MVME 167) > The GNU C++ compiler coming with Tornado (Ver 2.7.2) is *not* capable of generating reentrant exeception code! I would not use it!!! However, if you like adventures you can still try it... ;-) Then you need to switch on not only -fhandle_exceptions but also -frtti, which gives you the needed runtime type info to catch the correct classes in your code. Problem is, that you must compile *all* C++ code with that options, since it changes the basic class layout adding virtual methods/classes. As you might guess, this is impossible if you use 'iostream' classes, since you do not have the source code!! Conclusion: Give up on exceptions! I use this opportunity to urge WRS to come up with a better compiler! (Instead of just another (better?) Tornado version ;-) I saw some code in egcs-1.1b that might make all these headaches go away... Does anybody care at WRS? Are C++ programmer's that rare, still? Andreas =:-) From owner-vxwexplo-process Tue Dec 8 22:58:28 1998 From: Yves LEDUC Date: Tue Dec 8 22:58:32 PST 1998 Subject: ASM 68k on Tornado-VxWorks / NT4.0 I am a old programmer on 68k, but I am beginner on Tornado VxWorks. Do you have some informations and examples od ASM 68k programs, particulary for interrupt and use with Tornado-gdb. Thanks in advance Yves ----------------- Yves LEDUC Indsutrial computing teacher LPT de la SALLE NANTES FRANCE ----------------- yleduc@oceanet.fr --------------------- From owner-vxwexplo-process Wed Dec 9 00:46:28 1998 From: stevens Date: Wed Dec 9 00:46:32 PST 1998 Subject: Thanks: CORBA for VxWorks Hi VxWorkers ! Thank you for all the answers to the CORBA for VxWorks-questions. To our solution: We will use Visibrokers CORBA-ORB, because it is the only one which has an IIOP-engine for CPU32. ORBIX has no IIOP-Engine implemented yet. TAO is a very interesting and a very cheap solution, but there is no support and compiling TAO for Motorola's 68332 is not possible without a lot of changes to the sources. Visibroker's CORBA-ORB uses only 1.5 megs of RAM at runtime with the operation system build in. If somebody know a better solution. Please let me know. CU in the VxWorks-exploder, Torsten Stevens -- ************************************************************************** fraunhofer institute of microelectronic circuits and systems department sat name torsten stevens mailto:stevens@ims.fhg.de address finkenstrasse 61 phone +0049/203/3783-238 47057 duisburg fax +0049/203/3783-266 germany http://www.fhg.de/depts/ims-du-e.html ************************************************************************** From owner-vxwexplo-process Wed Dec 9 01:55:18 1998 From: Martin Schrape Date: Wed Dec 9 01:55:49 PST 1998 Subject: Re: Throw/Catch Hi Michael, I already write my code with C++ exception handling, waiting for Tornado II that will be available in spring. -Martin --------------------------------------------------------------- Dipl.-Phys. Martin Schrape schrape@atomika.com Senior Software Engineer Tel. +49 89 315 891 34 Atomika Instruments GmbH Fax +49 89 315 59 21 Bruckmannring 40 http://www.atomika.com 85764 Oberschleissheim/Munich, Germany --------------------------------------------------------------- At 14:07 12/8/98 -0800, you wrote: >Submitted-by owner-vxwexplo-process Tue Dec 8 14:07:47 1998 >Submitted-by: "Michael Baumann" > > >We have a developer here that has decided that using the Throw/Catch >exception handling of C++ would be a good thing. >Mental judgements aside, we have attempted this with the bundled >G++ that comes with Tornado, and have run into a sticky wicket - >to wit: Using the -fhandle_exceptions introduces a number of undefined >symbols, that appear to deal with setting up and dealing with >the jumps needed to do exception processing. >Is there some trick I am not aware of, or am I SOL? >Target system is 68K (MVME 167) > >-- >Michael Baumann Optivus Technology Inc.|Loma Linda University Medical >Center >San Bernardino, California. (909)799-8308 |Internet: baumann@llumc.edu From owner-vxwexplo-process Wed Dec 9 20:24:45 1998 From: Garry Kraemer Date: Wed Dec 9 20:24:49 PST 1998 Subject: MVME2604 Printer Driver vxWorks users, I'm looking for a printer driver for the MVME2604. Can anyone provide assistance in getting the printer port attached to vxWorks? Thanks in advance. Garry Kraemer, Raytheon Systems (602) 935-2214 From owner-vxwexplo-process Thu Dec 10 07:09:40 1998 From: Charlie Grames Date: Thu Dec 10 07:09:43 PST 1998 Subject: WTX Timeout VxWorks 5.3.1 MVME2700 1.1/4 Can anyone tell me _exactly_ what it means when you get a WTX timeout in WindSh? I know that a WTX timeout may occur if you are attempting to load a large load module with symbol synchronization enabled, but I corrected for that by using symSyncTimeoutSet() to increase the timeout to something sufficiently large. My recent WTX timeout errors don't appear to be correlated to anything in particular, so I really don't know where they are coming from. I can leave my WindSh up with nothing special running on the target and still get them. Any ideas? I'd appreciate any feedback. Thanks. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com From owner-vxwexplo-process Thu Dec 10 08:12:59 1998 From: Piero Giorgio Degiorgis Date: Thu Dec 10 08:13:02 PST 1998 Subject: kbhit() function Hello All, In my application, I need to test if a character on the keyboard has been typed (to exit from a loop that runs forever on a well defined line of code). The getchar() function is suspensive, it blocks the software every cycle so this way does not work. If I have to use the Microsoft C++ environment, I could use the primitive kbhit(). Does somebody know a similar way with vxWorks? Thanks in advance, - Piero Giorgio DEGIORGIS, - Universita' degli Studi di TORINO (ITALY) - sperimental physics department and INFN, - Via Pietro GIURIA 1, 10125, TORINO (ITALY) - 0039 11 6707332, E-mail: degiorgis@to.infn.it From owner-vxwexplo-process Thu Dec 10 13:39:33 1998 From: Charlie Grames Date: Thu Dec 10 13:39:37 PST 1998 Subject: kbhit() function -Reply Piero, If the keyboard on your system is treated as a terminal input, you can use ioctl() calls to allow immediate processing of all inputs and to determine when inputs have been provided. See the description of tyLib in the VxWorks Reference Manual for details. Following is a piece of code I wrote to wait up to a certain amount of time for the user to press a key on the console keyboard during booting: /* TSS Set the console for normal terminal operation, except allow immediate TSS processing of all inputs. This operation also causes all waiting TSS inputs to be flushed, reducing the chance that a stray input will be TSS interpreted as an intentional break request. */ ioctl(consoleFd,FIOSETOPTIONS,OPT_TERMINAL^OPT_LINE); /* TSS Calculate the tick at which to continue booting, and wait until the TSS timeout period has expired or a key is pressed. */ continueTick = tickGet() + (timeout * sysClkRateGet()); do ioctl(consoleFd,FIONREAD,(int)&bytesWaiting); while ((tickGet() < continueTick) && (bytesWaiting == 0)); /* TSS Return the console to normal terminal operation. This operation also TSS causes all waiting inputs to be flushed. */ ioctl(consoleFd,FIOSETOPTIONS,OPT_TERMINAL); /* TSS If a key was pressed... */ if (bytesWaiting) { . . . HTH Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/10/98 10:13am >>> Submitted-by owner-vxwexplo-process Thu Dec 10 08:12:59 1998 Submitted-by: Piero Giorgio Degiorgis Hello All, In my application, I need to test if a character on the keyboard has been typed (to exit from a loop that runs forever on a well defined line of code). The getchar() function is suspensive, it blocks the software every cycle so this way does not work. If I have to use the Microsoft C++ environment, I could use the primitive kbhit(). Does somebody know a similar way with vxWorks? Thanks in advance, - Piero Giorgio DEGIORGIS, - Universita' degli Studi di TORINO (ITALY) - sperimental physics department and INFN, - Via Pietro GIURIA 1, 10125, TORINO (ITALY) - 0039 11 6707332, E-mail: degiorgis@to.infn.it From owner-vxwexplo-process Fri Dec 11 01:35:41 1998 From: Harald Grundner Date: Fri Dec 11 01:35:45 PST 1998 Subject: Re: kbhit() function >Submitted-by owner-vxwexplo-process Thu Dec 10 08:12:59 1998 >Submitted-by: Piero Giorgio Degiorgis > > >Hello All, > >In my application, I need to test if a character on the keyboard has been >typed (to exit from a loop that runs forever on a well defined line of >code). The getchar() function is suspensive, it blocks the software >every cycle so this way does not work. >If I have to use the Microsoft C++ environment, I could use the primitive >kbhit(). Does somebody know a similar way with vxWorks? Hi Piero, here's some code that should do the trick. Harald #include /* printf() */ #include /* FIOSETOPTIONS */ #include /* assert() */ #include /* taskDelay() */ #include /* sysClkRateGet() */ static int keyhit(void); void test(void) { char key; int testCount = 0; int options; /* Save options */ options = ioctl (0, FIOGETOPTIONS, 0); /* Enter raw mode */ ioctl (0, FIOSETOPTIONS, OPT_TERMINAL & ~OPT_LINE & ~OPT_ECHO); printf("Press any key to stop\n"); while (!(key = keyhit())) { printf("Test %d\n", testCount++); taskDelay (sysClkRateGet()); } /* while !keyhit() */ /* Leave raw mode */ ioctl (0, FIOSETOPTIONS, options); printf("\nKey was %d = %.4X = %c\n", key, key, key); } /* test */ static int keyhit(void) { int nread; int rc; int oneChar; /* probe STDIN to see if operator entered any characters */ rc = ioctl(0, FIONREAD, (int) &nread); assert(rc != ERROR); if (nread) { /* got a char */ /* flush all the characters entered */ for (; nread; nread--) oneChar = getchar(); return oneChar; } return 0; } /* keyhit */ From owner-vxwexplo-process Fri Dec 11 08:27:40 1998 From: David Laight Date: Fri Dec 11 08:27:43 PST 1998 Subject: Re: kbhit() function > >Hello All, > > > >In my application, I need to test if a character on the keyboard has been > >typed (to exit from a loop that runs forever on a well defined line of > >code). The getchar() function is suspensive, it blocks the software > >every cycle so this way does not work. > >If I have to use the Microsoft C++ environment, I could use the primitive > >kbhit(). Does somebody know a similar way with vxWorks? > > > Hi Piero, > > here's some code that should do the trick. > > Harald > > /* probe STDIN to see if operator entered any characters */ > rc = ioctl(0, FIONREAD, (int) &nread); It ought to be possible to use poll() here instead of the FIONREAD ioctl. I also remember a reference to setting 'NONBLOCK' mode. Which is best probably depends on the structure of your app. David ---------------------------------------------------------------- David Laight email: dsl@tadpole.co.uk Tadpole Technology plc phone: +44 1223 278 256 Cambridge, UK fax: +44 1223 278 201 From owner-vxwexplo-process Fri Dec 11 10:22:37 1998 From: Lori Fraleigh Date: Fri Dec 11 10:22:41 PST 1998 Subject: Re: VxWorks Hung Telnet Session Tim - What BSP are you using? I've seen this problem with the ebsa285 BSP (ARM SA110) for VxWorks 5.3.1 and have filed TSR 11538. The ebsa285 BSP included the SENS stack by default so this bug may or may not also exist on other BSPs if you have SENS installed. I don't know. The problem is due to inefficient use of network buffers (M_BLKs and clusters). The printf blocks on a semaphore trying to get a network buffer to send the data out over the socket. There is a workaround while you wait for a fix. In target/h/netBufLib.h, change: #define NUM_NET_MBLKS 400 /* no. mBlks to initialize */ to #define NUM_NET_MBLKS 20000 /* no. mBlks to initialize */ or some other number large enough to make your problems go away. WRS just released a SENS 1.1 update. If the bug existed on other platforms, it may be fixed in the update. It does not cover the ARM platform though. I'm waiting to hear when a fix for ARM will be released. The problem has already been acknowledged and fixed in Tornado 2 / VxWorks 5.4. Regards, Lori -- Lori Fraleigh Real-Time Innovations http://www.rti.com lori@rti.com 408-720-8312 ext. 121 Fax: 408-734-5009 Tim Sohacki wrote: > > Can anyone provide any insight into the following problem? > Thanks for your help. > > Cheers, > Tim > > > I'm running into some trouble with the Target Shell's IO > > when I have multiple tasks printing to the STDOUT device. > > I have narrowed the scenario down to something very simple: > > > > 1. Telnet into a target: > > > > % telnet 47.192.0.165 > > Trying... > > Connected to 47.192.0.165. > > Escape character is '^]'. > > Local flow control off > > > > -> > > > > 2. Type the following command: > > > > -> sp i > > task spawned: id = 0x1b71238, name = t7 > > value = 28774968 = 0x1b71238 > > > > And that's all you need. The Telnet session (target shell) > > is now hung. No I/O is possible until the target is rebooted. > > It's possible, although I cannot confirm, that both STDIN and > > STDOUT are PENDED waiting to take some semaphore. > > > > > > -- > Tim Sohacki, Nortel Networks > email: sohacki@nortelnetworks.com From owner-vxwexplo-process Tue Dec 15 09:09:37 1998 From: ksamavedam@hns.com (Krishna Samavedam) Date: Tue Dec 15 09:09:40 PST 1998 Subject: VxWorks max FTp sessions HI, I d like to know how to configure the vxWorks FTP server with regard to max number of sessions it can support simultaniously. If there is no such support, how can I control the number of sessions with the default configuration. thanx in advance krishna From owner-vxwexplo-process Tue Dec 15 12:01:22 1998 From: "Victor Wu" Date: Tue Dec 15 12:01:27 PST 1998 Subject: Help://Motorola MC68360 SCC UART serial driver vxWorks Tornado Hi, all, We need to set the serial speed as 115200, but only 38400 is achieved. I checked MC68360 serial driver file m68360Sio.c, there is a line : if (arg >= 50 && arg <= 38400) { ... } After I modified to: if (arg >= 50 && arg <= 115200) The speed 57600 is achieved. But 115200 is still failed. Have someone done the similar things ? Do I need to modify the driver register setting in order to achieve 115200 speed ? Thanks. Victor Wu MTS Telogy Networks Inc. (301)515-6624 vwu@telogy.com From owner-vxwexplo-process Tue Dec 15 14:10:32 1998 From: Cecil Mathews Date: Tue Dec 15 14:10:36 PST 1998 Subject: Re:VxWorks Max Ftp Sessions There is a compile time definition in ftpdlib.h ftpdMaxClients = 4. You can change that   From owner-vxwexplo-process Wed Dec 16 04:00:22 1998 From: daemon@csg.lbl.gov Date: Wed Dec 16 04:00:26 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Dec 16 04:00:13 PST 1998 Subject: Re: PowerPc assembler & system tick accuracy Subject: Problem in booting VxWorks Subject: Tornado II Subject: Re: Strange behaviour with global variable : have you seen it before? Subject: Is this Veritas NG Subject: Re: VxWorks max FTp sessions Subject: netBufLib question Subject: Question on SENS drivers Subject: Sporadic interrupts from Industry Pack - vw5.2 - MVME162 Subject: Dec Ethernet Driver? Subject: Re: DMA on MVME2600 Subject: Re: Build Output Requires Prompting? (Update) Subject: PCI ATM NIC Subject: Re: Dec Ethernet Driver? ------------------------------------------------------- Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks Subject: Re: PowerPc assembler & system tick accuracy Date: 15 Dec 1998 13:23:47 GMT From: laire@basis.owl.de (Ralph Schmidt) Organization: Privates Internet Ost-Westfalen-Lippe Message-ID: <755nt3$ji7$1@pri.owl.de> References: <36760043.5D1F4E4E@ecitele.com> On 12/15/98, Yosi Yarchi wrote: >Hello all > >The following is source copied from vxWorks system timer interrupt >routine, which is based on the decrementer function of the PowerPc (in >this case: MPC860). I'm looking for some explanation about the syntax in >this code: (1) what is the %0 (implemented by the compiler as r9 >register). (2) what means the colon character (appears at the begining seperates the 1) output 2) input 3) trashed memory/register definition of a gcc inline asm function. >of the last 3 lines). (3) what means of the "r", "3", and "cc" commands >which have special inverted commas (" ")? as I could see, these lines >have no effect on the code generated by the compiler. (4) can someone >explain me the trick of compensation of the interrupt latency which is >implemented here in the loop(it required because the decrementer is not >auto reloaded)? > >Thank you >Yosi > > > > > >__asm__ (" > mfdec 3 >sysClkIntLoop: > add. 3, %0, 3 > ble sysClkIntLoop /* check if we missed tick(s) */ > > mtdec 3" > : /* no output operands */ Here you define the output register of an (inline) assembler function > : "r" (decCountVal) /* input operand, %0 = >decCountVal */ %0 is a integer "register" defined by the compiler which is loaded with the value decCountVal. You could also create more arguments and the compiler would use the right registers. > : "3", "cc"/* side-effects: r3 clobbered, 'condition code' is "3"== register 3 "cc" == condition code which are changed by the "add." >clobbered */ > ); > defines the registers which are trashed by this operation. All that is explained in the gcc docs. - -- Ralph Schmidt,laire@popmail.owl.de(private),NextMail welcome --------------------------- Newsgroups: comp.os.vxworks Subject: Problem in booting VxWorks Date: 15 Dec 1998 15:30:24 GMT From: chandraj@nortel.ca (Chandan Rajah) Organization: Bell Northern Research Message-ID: <755vag$7s2@bmdhh222.europe.nortel.com> Hi, I am working with the vxwork on the VME architechture on a SunSprac card. The problem I'm facing is that when i boot the card with VxWorks, i get the VxWorks banner and then i get the following message... Cannot regiister service: RPC: Timed out rdbTask: couldn't open RDB service Unable to open startup script - -> i undefined symbol 'i' But coincidently the other card seems to be working perfectly. It is not a NFS problem as the same card had been working for sometime in the past with the same configuration. The other problem is that when I try to do an ldf ("/bnr/rchtools/automation/ttf/vme/bootnet/bootrom_uncmp",0,0x100,1) It returns an error message 'Program to big for flash memory' but again the same thing is working for the other card. Crisis situation, kindly advise - --- Chandan !!! E-Mail: chandraj@wipsys.soft.net --------------------------- Newsgroups: comp.os.vxworks Subject: Tornado II Date: Tue, 15 Dec 1998 10:57:47 -0800 From: Edward LaPier Organization: Lockheed Martin Federal Systems, Owego, NY Message-ID: <3676B12B.8BE52903@lmco.com> VxWorks Greetings! I am trying to get some information on Tornado II. If anyone out there in VxWorks Land has been using the BETA version and has information about PROS/CONS it would be greatly appreciated. Thanks in advance! Ed - -- - ------------------------------------------------------------------- Edward LaPier - Lockheed Martin Federal Systems 1801 State Route 17C Mail Drop 0302 Owego, NY 13827-3994 Voice: (607) 751-4296 - ------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Strange behaviour with global variable : have you seen it before? Date: Tue, 15 Dec 1998 07:56:12 -0800 From: "Joseph R Hansen" Organization: NAWCWPNS Message-ID: <75615e$3f11@news.nawcwpns.navy.mil> References: <7543t6$p8p$1@nnrp1.dejanews.com> <754t9l$ejc$1@nnrp1.dejanews.com> Mittal, My "solution" is a bit different from John's. It has been my experience with VxWorks that a task will continue to run until it gives the shell a reason to check on other tasks' status (poor wording, but a task will run until it comes to a taskDelay, semTake, or some other basic function that interrupts its flow of control). Your task "TaskInit" never prints because it never runs. It never runs because the shell never interrupts "RxFunc" from running. I _believe_ that if you use printf instead of logMsg, it will work. I seem to remember that there is a taskDelay in the printf function, but not in logMsg (I could be wrong here; corrections from the group gladly accepted). I don't know if this will give you what you need, but as I said, this has been my experience. Good luck. Oh, and I do agree with John that you should make Count volatile (especially if accessed from two different object files). Joseph Hansen NAWCWPNS China Lake Code 471500D China Lake, CA 93555 hansen@cel.chinalake.navy.mil (760) 939-6999 john@kivala.com wrote in message <754t9l$ejc$1@nnrp1.dejanews.com>... >In article <7543t6$p8p$1@nnrp1.dejanews.com>, > newsmine@my-dejanews.com wrote: >> Hi VxGurus, >> >> While doing some simple timer-driven code on VxWorks, I saw the following >> strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1, >> gcc 2.7.2 and a PPC860 board. My compilation flags are >...edit >> int Count; >... > >My guess is that "int Count" wants to be "volatile int Count". >The compiler might be sticking it in a register and never >re-getting it from memory, unless you have a "sufficiently >complicated" line of code between uses of Count (case 3). > >This is not too hard to check: >objdumpppc --disassemble file.o > file.lst >(A reading knowledge of any given assembly language is far >easier than a writing knowledge thereof.) > >If this is what's happening, and maybe even if it's not, the >lesson is that if you have any variables shared by more than >one task (or isr), then they should be volatile, since you >don't (in general) know when task A is going to switch out >and task B is going to switch in. This is a different kind >of protection than that achieved by intLock, taskLock, or >a semaphore. > >John > >-------------------------------------------------- > John Finley Kivala Systems, Inc. > Project Manager (619) 689-0032 > john@kivala.com http://www.kivala.com >-------------------------------------------------- > VxTool - Build Tornado Apps with MS Visual Basic >-------------------------------------------------- > >-----------== Posted via Deja News, The Discussion Network ==---------- >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Is this Veritas NG Date: Sat, 12 Dec 1998 11:09:56 -0800 From: "Dave41" Organization: SBC Internet Services Message-ID: Is this a VXFS type ng. If so I'd like to pose questions. If not does anyone know of a ng that discusses VXFS? Dave --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks max FTp sessions Date: Tue, 15 Dec 1998 13:56:48 -0500 From: Douglas Fraser Organization: Lucent Technologies Message-ID: <3676B0F0.F88E04C1@lucent.com> References: <981215120856.ZM1775@dcn49.hns.com> Krishna Samavedam wrote: > > HI, > I d like to know how to configure the vxWorks FTP server > with regard to max number of sessions it can support simultaniously. > > If there is no such support, how can I control the number of > sessions with the default configuration. > Check the programmers reference manual for tftpdInit. The last arg is the max number of connections. - -- Doug Fraser dwfraser@lucent.com --------------------------- Newsgroups: comp.os.vxworks,cisco.eng.cr.su-dev-vxworks Subject: netBufLib question Date: Tue, 15 Dec 1998 11:31:16 -0800 From: "Sohail M. Parekh" Organization: Cisco Systems Message-ID: <3676B904.F715282D@cisco.com> Reply-To: sparekh@cisco.com Hello, I cannot seem to find a netBufLib routine that helps connect two (or more) mblks to form a chain. If someone could point me in the right direction. Regards, Sohail --------------------------- Newsgroups: comp.os.vxworks Subject: Question on SENS drivers Date: Tue, 15 Dec 1998 11:59:16 -0800 From: "Sohail M. Parekh" <@cisco.com> Organization: Cisco Systems Message-ID: <3676BF94.A1B06812@cisco.com> Reply-To: @cisco.com Hello, Any idea if SENS END drivers TYPICALLY support scatter-Gather chains. I am using m-blk chains which I would like the END driver to send as a single block. Regards, Sohail --------------------------- Newsgroups: comp.os.vxworks Subject: Sporadic interrupts from Industry Pack - vw5.2 - MVME162 Date: Tue, 15 Dec 1998 16:36:08 -0800 From: David Morris 222-7450 Organization: TRIUMF Message-ID: <36770077.E63CBB2E@triumf.ca> Hello I'm getting some peculiar behaviour with an interrupt from an ADC/DAC Industry Pack board, and am searching for any suggestions. Computer is MVME162 running vw5.2. Industry Pack is TEWS Datentechnik TIP850 ADC/DAC board. The IP generates an interrupt on end-of-conversion. Most of the time it works but every now and then I get a flurry of timeouts from the semaphore. The GCR for the IPIC on 162 is set up as: *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x18 + cPosition)) = 0x00; This means no memory access, no recovery time, no Error* signal. I tried changing recovery time to see if that was the problem but with no luck. The ICR for the IPIC on 162 is set up as: *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x10 + cPosition * 2)) = 0x15 - cPosition; *((unsigned char *) (MVME162_IPIC_ADDRESS + 0x11 + cPosition * 2)) = 0x15 - cPosition; This means Low level ints, ints enabled, int level depends on position on board. The interrupt service routine is connected to some arbitrary vector. (There doesn't seem to be much info about what numbers to select for vector numbers, but that's another story) A task runs to scan the eight ADC channels in a while loop. The format for each channel is set up, then the command register is written to start the collection. Then a semaphore is taken until the interrupt occurs. while () /* loop through all channels */ { sCmdStatus = iChannel | (iDifferential << 4) | (tip850Board->ADC[iChannel].iGain << 5) | (iGainSettle << 7) | (iInterrupt << 8); * (tip850Board->psADC_CSR) = sCmdStatus; * (tip850Board->psADC_CON) = 0xff; /* dummy write to trigger ADC */ sResult = semTake(sidTip850ADCComplete, 1); /* block until collection done */ sData = * (tip850Board->psADC_DAT); /* collect data */ } The interrupt routine just gives the semaphore back, allowing the collection to happen. void tip850IntADC() { semGive(sidTip850ADCComplete); } My error diagnostic printouts show the collection completed. I've tried making the timeout on the semTake longer, but no luck there; the conversion takes 10 usec, not 1/60th second. It happens on all channels although mostly on channel 0. I've tried double triggering, a long delay between setup and trigger, etc.etc.etc. Does anyone have any ideas? Thanks in advance! - -- David B Morris TRIUMF Systems Designer/Analyst Canada's National Meson Facility cadfael@triumf.ca 4004 Wesbrook Mall 604-222-7450 Vancouver, B.C. V6T 2A3 "Remember, no matter where you go, there you are." - Buckaroo Banzai --------------------------- Newsgroups: comp.os.vxworks Subject: Dec Ethernet Driver? Date: Tue, 15 Dec 1998 17:23:32 -0800 From: Frankie Sierra Message-ID: <36770B93.DCE5CB9A@teralogic-inc.com> I am looking for a Dec 21140, or 21143 Ethernet driver for use with VxWorks 5.1.3? Anyone done this? Any issues, caviats? Frankie Sierra sierra@teralogic-inc.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: DMA on MVME2600 Date: Wed, 16 Dec 1998 13:55:22 +0900 From: "Young-Han, Kim" Organization: Softec Engineering Co., Ltd. Message-ID: <757ei3$gll$1@news.kornet.nm.kr> References: Reply-To: "Young-Han, Kim" Dear Philippe, I don't have the experience for VME DMA transfer. Our company is the agent of DY4 Systems. Our customer wants to use the VME DMA transfer. So, somedays ago, I was look into the UNIVERSE manual. The DY4 CPU used the UNIVERSE. In my opinion, if know the UNIVERSE manual and the base address of UNIVERSE, anybody can make the DMA transfer program. You can solve this problem as follow 1. ask to the Motorola or the agent 2. solve by yourself. In this case, First of all, You must know the VMEbus Interface Chip and the base address of VMEbus Interface Chip. Maybe, it is not so easy to get the base address of VMEbus Interface Chip. So, ask to Motorola. Then you must get the manual of the VMEbus Interface Chip. If you can refer the manual, maybe, you can make the program for VME DMA transfer. Best Regards Young-Han, Kim / R&D Philippe Duhoux was wrote... >Bonjour, >does someone have experience in DMA transfers on >MVME2600? >In my particalar case, I shall transfer CPU data >from/to an external VME board in A32/D32 space. > >Thanks for any hint. > >Best regards, >Philippe > >================================================================ >Philippe Duhoux Tel: (+49) >89-3200-6523 >Software Engineer VLT Fax: (+49) >89-3200-6494 >CCD Cameras & Instrument Motors >Karl-Schwarzschild-Str.2 >European Southern Observatory D-85748 Munich >- Germany >E-Mail : pduhoux@eso.org WWW >http://www.eso.org >================================================================ > > > >*** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) *** ? ''' (o o) - -----------------------oOO--(_)--Oo----------------------- Young-Han, Kim / R&D E-mail : support@softec.co.kr Softec Engineering Co., Ltd. 4F, Shinil B/D, #196-1, Poi-Dong, Kangnam-Ku, Seoul, Korea Tel : ++ 82 2 575 7311 Fax : ++ 82 2 575 7314 Http://www.softec.co.kr - ----------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Build Output Requires Prompting? (Update) Date: Tue, 15 Dec 1998 03:44:18 GMT From: paulvroberts@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <754lui$8je$1@nnrp1.dejanews.com> Tim Sohacki wrote: > > Update ... on one machine, it appears to be an interaction with > Norton Anti-virus. On the other, it's something else, though > we don't know what yet. > > Cheers, > Tim > Thanks to you and Philip Gaglia for giving me the idea that it was the virus checker. I have verified this to be the case on the Win 95 machines that had problems. We are running McAfee VShield 3.2.0, and if you disable it, Tornado make windows then work fine. Oh the joy of developing under Windows... Paul Roberts. - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: PCI ATM NIC Date: Wed, 16 Dec 1998 11:22:21 +0200 From: "Udi Nir" Organization: NetVision Israel Message-ID: <757u7f$7eq$1@news.netvision.net.il> I am looking for a commercial PCI ATM NIC (e.g. OC3) that has drivers for VxWorks. The only requirements are to be able to set up a connection and send/receive AAL5 PDUs (no need for IP etc.) Thanks in advance, Udi --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dec Ethernet Driver? Date: Wed, 16 Dec 1998 05:40:00 -0500 From: Dan DeVault Organization: IBM.NET Message-ID: <36778DFF.D92F63F2@ibm.net> References: <36770B93.DCE5CB9A@teralogic-inc.com> Wind River has a driver that works with the SENS stack. At least for the Motorola MTX604 BSP. We are trouble shooting some problems with it now. Dan DeVault IBM Global Network devault@ibm.net Frankie Sierra wrote: > I am looking for a Dec 21140, or 21143 Ethernet driver for use with > VxWorks 5.1.3? Anyone done this? Any issues, caviats? > > Frankie Sierra > sierra@teralogic-inc.com --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Wed Dec 16 07:51:39 1998 From: tpbiele@sandia.gov Date: Wed Dec 16 07:51:42 PST 1998 Subject: Problems with the floor() function on MV2604 Fellow vxworks users, I believe I have discovered two double floating point numbers that the floor() function on an MV2604 board does work correctly on. The code snippet that I used and the output that I got are shown below. I would appreciate any feedback. ******************************** Begin Function ****************************************** #include "vxworks.h" #include "math.h" #include "stdio.h" void floorchk(void) { double temp; double temp1; long *pLong; temp = -1327828.87015908; pLong = (long *)&temp; /* change the LSW slightly */ pLong[1] = 0xdec2beca; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becb; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becc; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becd; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2bece; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); } ******************************** End Function ****************************************** ******************************** Begin Output ****************************************** pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECA floor(-1327828.870159) = -1327829.000000 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECB floor(-1327828.870159) = -1327829.000000 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECC floor(-1327828.870159) = -1327828.870159 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECD floor(-1327828.870159) = -1327828.870159 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECE floor(-1327828.870159) = -1327829.000000 ******************************** End Output ****************************************** -------------------------------------------------------- E-mail: tpbiele@sandia.gov Date: 12/16/1998 Time: 08:39:31 This message was sent by Z-Mail Pro - from NetManage NetManage - delivers Standards Based IntraNet Solutions -------------------------------------------------------- From owner-vxwexplo-process Wed Dec 16 10:56:55 1998 From: "Minbo Shim" Date: Wed Dec 16 10:56:59 PST 1998 Subject: VwWorks: A16 VME for PowerPC (MVME2700) Vxworks gurus: I have some difficulties to get access to a register in the A16-based I/O board. Here is the story. We have an A16-based VMEbus I/O board with short addressing map that tells us where to go to see the contents of some registers in it. Suppose the local address to one of the registers is 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that VME MASTER WINDOW for A16 SPACE is following: /* * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks * This maps: MPU RANGE: 0xfbff0000 - 0xfbffffff * to: PCI RANGE: 0xfbff0000 - 0xfbffffff * to: VME RANGE: 0xfbff0000 - 0xfbffffff */ # define VME_A16_MSTR_LOCAL 0xfbff0000 # define VME_A16_MSTR_SIZE 0x00010000 /* 64K */ # define VAL_LSI3_BS_VALUE (VME_A16_MSTR_LOCAL) I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value: { (void *) VME_A16_MSTR_LOCAL, (void *) VME_A16_MSTR_LOCAL, VME_A16_MSTR_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, However, every try to get access to "0xfbff6005" has been failed in the sense that the contents are NOT what we expect. Does anybody know what I am missing? Your help would be greatly appreciated. ------------------------- MINBO SHIM; mshim@rst.com Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 ROBOTIC SYSTEMS TECHNOLOGY 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Wed Dec 16 11:35:06 1998 From: Alan K Biocca Date: Wed Dec 16 11:35:09 PST 1998 Subject: filtered article viewing I have just setup a web-accessible viewing area for rejected articles. If you are concerned that a posting did not come through the exploder check there after 20 minutes or so and see if your article was filtered out. The filename contains an error message that should help you know which filter was triggered. http://csg.lbl.gov/vx_explo.html I fixed a bug yesterday that prevented the digests from the newsgroup from being emailed. They were reaching the archive but were being rejected by sendmail. This should be fixed now, we will be watching it the next few days. Alan K Biocca VxWorks Exploder Program Author From owner-vxwexplo-process Wed Dec 16 11:54:53 1998 From: "Minbo Shim" Date: Wed Dec 16 11:54:57 PST 1998 Subject: VxWorks: shared memory network for PowerPC (MVME2700) Vxworks gurus: I am trying to make a SM network with the proxy arp for the powerpc boards (mvme2700). As described in the Programmer's manual, I included the following in the "configAll.h": #define INCLUDE_PING #define INCLUDE_SM_NET #define INCLUDE_PROXY_SERVER #define INCLUDE_SM_SEQ_ADDR #define INCLUDE_PROXY_DEFAULT_ADDR And for the master: #define PROXY_ARP_MASTER #define SM_OFF_BOARD FALSE and for the slave: #define PROXY_ARP_SLAVE #define SM_OFF_BOARD TRUE By doing so, I want slaves to use the memory on the master starting at 0x01000000 (16MB) with the size of 1MB. Here is the configuation (config.h) #define SM_ANCHOR_OFFSET 0x4100 /* default for PowerPC */ #define SM_ANCHOR_ADRS ((sysProcNumGet() == 0) ? \ ((char*) (LOCAL_MEM_LOCAL_ADRS + SM_ANCHOR_OFFSET)) : \ ((char*) (VME_A32_MSTR_LOCAL + SM_ANCHOR_OFFSET))) #define SM_MEM_ADRS 0x01000000 #define SM_MEM_SIZE 0x00100000 #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) #define SM_OBJ_MEM_SIZE 0x00100000 After rebuilding vxWorks images, the master seems happy by attaching net work interface sm0 to the anchor point (0x4100). I verify that the heartbeat on the master is alive by looking at the 5th 4-byte word. In order to get the VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which returns 0x8004100. I used this address as the share memory anchor address for all slaves (sm=0x8004100). However slaves are complaining that the address is not corretly mapped somehow. Clients keep saying the following without granting the vxworks prompt: Backplane anchor at 0x8004100... Attaching network interface sm0... done. smIsAlive: readyValue = 0xffffffff, heartbeat = 0x0 Does anybody know what I did wrong in setting up the shared memory network with the proxy arp? Your help would be greatly appreciated. Regards, ----------------- MINBO SHIM; mshim@rst.com Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 ROBOTIC SYSTEMS TECHNOLOGY 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Wed Dec 16 12:21:38 1998 From: Charlie Grames Date: Wed Dec 16 12:21:42 PST 1998 Subject: VwWorks: A16 VME for PowerPC (MVME2700) -Reply Minbo, The addressing looks fine. How are you doing your accesses? The 6005 address suggests that you are addressing by byte. If so, your code should be doing something equivalent to: someCharVar = *(char *)0xfbff6005; (though hopefully more elegantly). In particular, the d() funciton is probably not useful, because it reads from memory 32 bits at a time. If your board does not respond to D32 bus cycles, you get bus errors and useless data. HTH Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/16/98 12:57pm >>> Submitted-by owner-vxwexplo-process Wed Dec 16 10:56:55 1998 Submitted-by: "Minbo Shim" Vxworks gurus: I have some difficulties to get access to a register in the A16-based I/O board. Here is the story. We have an A16-based VMEbus I/O board with short addressing map that tells us where to go to see the contents of some registers in it. Suppose the local address to one of the registers is 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that VME MASTER WINDOW for A16 SPACE is following: /* * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks * This maps: MPU RANGE: 0xfbff0000 - 0xfbffffff * to: PCI RANGE: 0xfbff0000 - 0xfbffffff * to: VME RANGE: 0xfbff0000 - 0xfbffffff */ # define VME_A16_MSTR_LOCAL 0xfbff0000 # define VME_A16_MSTR_SIZE 0x00010000 /* 64K */ # define VAL_LSI3_BS_VALUE (VME_A16_MSTR_LOCAL) I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value: { (void *) VME_A16_MSTR_LOCAL, (void *) VME_A16_MSTR_LOCAL, VME_A16_MSTR_SIZE, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, However, every try to get access to "0xfbff6005" has been failed in the sense that the contents are NOT what we expect. Does anybody know what I am missing? Your help would be greatly appreciated. ------------------------- MINBO SHIM; mshim@rst.com Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 ROBOTIC SYSTEMS TECHNOLOGY 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Wed Dec 16 12:24:44 1998 From: Tom Antles Date: Wed Dec 16 12:24:47 PST 1998 Subject: Re: Problems with the floor() function on MV2604 vxwexplo@lbl.gov (the vxWorks Users Group Exploder) wrote: I am not surprised. In the past (> 1 yr) we had problems with the fmod function returning the incorrect value on mv2603. We were sent several 'fixes' that each revealed successive problems deeper in their math libraries. We finally gave up and hacked a very non-elegant fix for ourselves. I am not sure if we even told them thier 'fixes' were still broken or if these deeper library problems were ever fixed on subsequent BSP patches/releases or not. Tom vxworks tornado > Submitted-by owner-vxwexplo-process Wed Dec 16 07:51:39 1998 > Submitted-by: tpbiele@sandia.gov > > Fellow vxworks users, > > I believe I have discovered two double floating point numbers that the floor() function on > an MV2604 board does work correctly on. The code snippet that I used and the output that I got are shown > below. I would appreciate any feedback. > > ******************************** Begin Function ****************************************** > > #include "vxworks.h" > #include "math.h" > #include "stdio.h" > > void floorchk(void) > { > double temp; > double temp1; > long *pLong; > > temp = -1327828.87015908; > pLong = (long *)&temp; > > /* change the LSW slightly */ > pLong[1] = 0xdec2beca; > > printf("\npLong[0] = 0x%X\n", pLong[0]); > printf("pLong[1] = 0x%X\n", pLong[1]); > temp1 = floor(temp); > printf("floor(%f) = %f\n\n", temp, temp1); > > > /* change the LSW slightly */ > pLong[1] = 0xdec2becb; > > printf("\npLong[0] = 0x%X\n", pLong[0]); > printf("pLong[1] = 0x%X\n", pLong[1]); > temp1 = floor(temp); > printf("floor(%f) = %f\n\n", temp, temp1); > > > /* change the LSW slightly */ > pLong[1] = 0xdec2becc; > > printf("\npLong[0] = 0x%X\n", pLong[0]); > printf("pLong[1] = 0x%X\n", pLong[1]); > temp1 = floor(temp); > printf("floor(%f) = %f\n\n", temp, temp1); > > > /* change the LSW slightly */ > pLong[1] = 0xdec2becd; > > printf("\npLong[0] = 0x%X\n", pLong[0]); > printf("pLong[1] = 0x%X\n", pLong[1]); > temp1 = floor(temp); > printf("floor(%f) = %f\n\n", temp, temp1); > > > > /* change the LSW slightly */ > pLong[1] = 0xdec2bece; > > printf("\npLong[0] = 0x%X\n", pLong[0]); > printf("pLong[1] = 0x%X\n", pLong[1]); > temp1 = floor(temp); > printf("floor(%f) = %f\n\n", temp, temp1); > } > > ******************************** End Function ****************************************** > > > > ******************************** Begin Output ****************************************** > > pLong[0] = 0xC13442D4 > pLong[1] = 0xDEC2BECA > floor(-1327828.870159) = -1327829.000000 > > > pLong[0] = 0xC13442D4 > pLong[1] = 0xDEC2BECB > floor(-1327828.870159) = -1327829.000000 > > > pLong[0] = 0xC13442D4 > pLong[1] = 0xDEC2BECC > floor(-1327828.870159) = -1327828.870159 > > > pLong[0] = 0xC13442D4 > pLong[1] = 0xDEC2BECD > floor(-1327828.870159) = -1327828.870159 > > > pLong[0] = 0xC13442D4 > pLong[1] = 0xDEC2BECE > floor(-1327828.870159) = -1327829.000000 > > ******************************** End Output ****************************************** > > -------------------------------------------------------- > E-mail: tpbiele@sandia.gov > Date: 12/16/1998 > Time: 08:39:31 > > This message was sent by Z-Mail Pro - from NetManage > NetManage - delivers Standards Based IntraNet Solutions > -------------------------------------------------------- Tom Antles antles@spk.hp.com Phone: (509) 921-3590 Fax: (509) 921-3991 From owner-vxwexplo-process Wed Dec 16 12:33:48 1998 From: Charlie Grames Date: Wed Dec 16 12:33:52 PST 1998 Subject: Problems with the floor() function on MV2604 -Reply I ran the test case on both a 2604 and a 2700 and had no problems with it. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/16/98 09:51am >>> Submitted-by owner-vxwexplo-process Wed Dec 16 07:51:39 1998 Submitted-by: tpbiele@sandia.gov Fellow vxworks users, I believe I have discovered two double floating point numbers that the floor() function on an MV2604 board does work correctly on. The code snippet that I used and the output that I got are shown below. I would appreciate any feedback. ******************************** Begin Function ****************************************** #include "vxworks.h" #include "math.h" #include "stdio.h" void floorchk(void) { double temp; double temp1; long *pLong; temp = -1327828.87015908; pLong = (long *)&temp; /* change the LSW slightly */ pLong[1] = 0xdec2beca; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becb; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becc; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2becd; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); /* change the LSW slightly */ pLong[1] = 0xdec2bece; printf("\npLong[0] = 0x%X\n", pLong[0]); printf("pLong[1] = 0x%X\n", pLong[1]); temp1 = floor(temp); printf("floor(%f) = %f\n\n", temp, temp1); } ******************************** End Function ****************************************** ******************************** Begin Output ****************************************** pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECA floor(-1327828.870159) = -1327829.000000 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECB floor(-1327828.870159) = -1327829.000000 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECC floor(-1327828.870159) = -1327828.870159 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECD floor(-1327828.870159) = -1327828.870159 pLong[0] = 0xC13442D4 pLong[1] = 0xDEC2BECE floor(-1327828.870159) = -1327829.000000 ******************************** End Output ****************************************** -------------------------------------------------------- E-mail: tpbiele@sandia.gov Date: 12/16/1998 Time: 08:39:31 This message was sent by Z-Mail Pro - from NetManage NetManage - delivers Standards Based IntraNet Solutions -------------------------------------------------------- From owner-vxwexplo-process Wed Dec 16 14:18:07 1998 From: "Carl C. Chesbrough" Date: Wed Dec 16 14:18:11 PST 1998 Subject: Re: VxWorks: shared memory network for PowerPC (MVME2700) VxWorks... From the slave CPU you should be able to display memory and see the readyValue of 0x12345678 or 0x87654321. It should be the same as displaying memory on the master at 0x4100. Typically I will boot the slave CPU from ethernet and then take the value returned by sysLocalToBusAdrs() of 0x8004100 and use that in the sysBusToLocalAdrs(0xd,0x8004100,&slaveAdrs). This needs to be run on the slave as the VME address of 0x8004100 may not be accessed using 0x8004100 on the slave. HTH, -Carl. > After rebuilding vxWorks images, the master seems happy by attaching net > work interface sm0 to the anchor point (0x4100). I verify that the heartbeat > on the master is alive by looking at the 5th 4-byte word. In order to get the > VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which > returns 0x8004100. I used this address as the share memory anchor address > for all slaves (sm=0x8004100). However slaves are complaining that the address > is not corretly mapped somehow. Clients keep saying the following without > granting the vxworks prompt: > > Backplane anchor at 0x8004100... Attaching network interface sm0... done. > smIsAlive: readyValue = 0xffffffff, heartbeat = 0x0 > > Does anybody know what I did wrong in setting up the shared memory network with > the proxy arp? > > Your help would be greatly appreciated. ******************************************************************** * * * Carl C. Chesbrough Telephone: (510) 252-0870 x 126 * * Themis Computer Facsimile: (510) 490-5529 * * 3185 Laurelview Court E-Mail : carl@themis.com * * Fremont, California 94538 * * * ******************************************************************** From owner-vxwexplo-process Wed Dec 16 14:30:54 1998 From: Charlie Grames Date: Wed Dec 16 14:30:58 PST 1998 Subject: VxWorks: shared memory network for PowerPC (MVME2700) -Reply Minbo, 8004100 is the VMEbus address. You need to use the processor address that correlates to that VMEbus address. You can determine that by using sysBusToLocalAdrs: sysBusToLocalAdrs(0x0d,0x8004100,&adrs) By default, adrs should be 10004100 for the 2700. Good luck! Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/16/98 01:54pm >>> Submitted-by owner-vxwexplo-process Wed Dec 16 11:54:53 1998 Submitted-by: "Minbo Shim" Vxworks gurus: I am trying to make a SM network with the proxy arp for the powerpc boards (mvme2700). As described in the Programmer's manual, I included the following in the "configAll.h": #define INCLUDE_PING #define INCLUDE_SM_NET #define INCLUDE_PROXY_SERVER #define INCLUDE_SM_SEQ_ADDR #define INCLUDE_PROXY_DEFAULT_ADDR And for the master: #define PROXY_ARP_MASTER #define SM_OFF_BOARD FALSE and for the slave: #define PROXY_ARP_SLAVE #define SM_OFF_BOARD TRUE By doing so, I want slaves to use the memory on the master starting at 0x01000000 (16MB) with the size of 1MB. Here is the configuation (config.h) #define SM_ANCHOR_OFFSET 0x4100 /* default for PowerPC */ #define SM_ANCHOR_ADRS ((sysProcNumGet() == 0) ? \ ((char*) (LOCAL_MEM_LOCAL_ADRS + SM_ANCHOR_OFFSET)) : \ ((char*) (VME_A32_MSTR_LOCAL + SM_ANCHOR_OFFSET))) #define SM_MEM_ADRS 0x01000000 #define SM_MEM_SIZE 0x00100000 #define SM_OBJ_MEM_ADRS (SM_MEM_ADRS+SM_MEM_SIZE) #define SM_OBJ_MEM_SIZE 0x00100000 After rebuilding vxWorks images, the master seems happy by attaching net work interface sm0 to the anchor point (0x4100). I verify that the heartbeat on the master is alive by looking at the 5th 4-byte word. In order to get the VMEbus (A32) address, I used "sysLocalToBusAdrs(0x0d,0x4100,&adrs)" which returns 0x8004100. I used this address as the share memory anchor address for all slaves (sm=0x8004100). However slaves are complaining that the address is not corretly mapped somehow. Clients keep saying the following without granting the vxworks prompt: Backplane anchor at 0x8004100... Attaching network interface sm0... done. smIsAlive: readyValue = 0xffffffff, heartbeat = 0x0 Does anybody know what I did wrong in setting up the shared memory network with the proxy arp? Your help would be greatly appreciated. Regards, ----------------- MINBO SHIM; mshim@rst.com Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 ROBOTIC SYSTEMS TECHNOLOGY 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Wed Dec 16 15:24:59 1998 From: "Wu, Don (HT-EX)" Date: Wed Dec 16 15:25:02 PST 1998 Subject: database products on VxWorks VxWorkers, Any one knows about commercial database products running on VxWorks? We'd like a database product that is popular, reliable and mature. Any recommendation is welcome Regards, Don Wu Ph.D System Technologies, Digital Network Systems General Instrument Corporation Tel: (215)323-1518 (office), Email: dwu@gi.com From owner-vxwexplo-process Wed Dec 16 16:11:48 1998 From: Alistair Adams Date: Wed Dec 16 16:11:52 PST 1998 Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) Assuming you have set up to use EXTENDED VME, I would say your address correct. Another possibility is the user/supervisor setting of the Address Modifier used for the A16 master window. The default setting for access to A16 VMEbus is to use a user mode address modifier. If your I/O board only responds to supervisor addresses then that might explain your problem. Look at the VAL_LSI3_CTL setting in mv2600.h. Alistair Adams Octant Technologies Inc. the vxWorks Users Group Exploder wrote: > Submitted-by owner-vxwexplo-process Wed Dec 16 10:56:55 1998 > Submitted-by: "Minbo Shim" > > Vxworks gurus: > > I have some difficulties to get access to a register in the A16-based > I/O board. > > Here is the story. We have an A16-based VMEbus I/O board with short > addressing map that tells us where to go to see the contents of some > registers in it. Suppose the local address to one of the registers is > 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that > VME MASTER WINDOW for A16 SPACE is following: > > /* > * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks > * This maps: MPU RANGE: 0xfbff0000 - 0xfbffffff > * to: PCI RANGE: 0xfbff0000 - 0xfbffffff > * to: VME RANGE: 0xfbff0000 - 0xfbffffff > */ > # define VME_A16_MSTR_LOCAL 0xfbff0000 > # define VME_A16_MSTR_SIZE 0x00010000 /* 64K */ > # define VAL_LSI3_BS_VALUE (VME_A16_MSTR_LOCAL) > > I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value: > > { > (void *) VME_A16_MSTR_LOCAL, > (void *) VME_A16_MSTR_LOCAL, > VME_A16_MSTR_SIZE, > VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, > VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT > }, > > However, every try to get access to "0xfbff6005" has been failed in the sense > that the contents are NOT what we expect. > > Does anybody know what I am missing? > > Your help would be greatly appreciated. > > ------------------------- > MINBO SHIM; mshim@rst.com > Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 > ROBOTIC SYSTEMS TECHNOLOGY > 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Wed Dec 16 16:13:11 1998 From: "Carl C. Chesbrough" Date: Wed Dec 16 16:13:14 PST 1998 Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply Minbo, You can use the m() function, giving it a parameter of 1 to do 8-bit access rather than 16-bit accesses. I thought that the default d() access was 16-bits. You can specify the size with the 3rd parameter to the d() function. -> m 0xfbff6005,1 or -> d 0xfbff6005, 1, 1 ^ ^ # of bytes ----| | access size ------| HTH, -Carl. ******************************************************************** * * * Carl C. Chesbrough Telephone: (510) 252-0870 x 126 * * Themis Computer Facsimile: (510) 490-5529 * * 3185 Laurelview Court E-Mail : carl@themis.com * * Fremont, California 94538 * * * ******************************************************************** > The addressing looks fine. How are you doing your accesses? The 6005 > address suggests that you are addressing by byte. If so, your code should > be doing something equivalent to: > > someCharVar = *(char *)0xfbff6005; > > (though hopefully more elegantly). In particular, the d() funciton is > probably not useful, because it reads from memory 32 bits at a time. If > your board does not respond to D32 bus cycles, you get bus errors and > useless data. > > HTH > > Charlie Grames > The Boeing Company > (314) 233-1956 > Charles.R.Grames@boeing.com > > >>> the vxWorks Users Group Exploder 12/16/98 12:57pm >>> > Submitted-by owner-vxwexplo-process Wed Dec 16 10:56:55 1998 > Submitted-by: "Minbo Shim" > > Vxworks gurus: > > I have some difficulties to get access to a register in the A16-based > I/O board. > > Here is the story. We have an A16-based VMEbus I/O board with short > addressing map that tells us where to go to see the contents of some > registers in it. Suppose the local address to one of the registers is > 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that > VME MASTER WINDOW for A16 SPACE is following: > > /* > * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks > * This maps: MPU RANGE: 0xfbff0000 - 0xfbffffff > * to: PCI RANGE: 0xfbff0000 - 0xfbffffff > * to: VME RANGE: 0xfbff0000 - 0xfbffffff > */ > # define VME_A16_MSTR_LOCAL 0xfbff0000 > # define VME_A16_MSTR_SIZE 0x00010000 /* 64K */ > # define VAL_LSI3_BS_VALUE (VME_A16_MSTR_LOCAL) > > I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value: > > { > (void *) VME_A16_MSTR_LOCAL, > (void *) VME_A16_MSTR_LOCAL, > VME_A16_MSTR_SIZE, > VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, > VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT > }, > > However, every try to get access to "0xfbff6005" has been failed in the > sense > that the contents are NOT what we expect. > > Does anybody know what I am missing? > > Your help would be greatly appreciated. > > > ------------------------- > MINBO SHIM; mshim@rst.com > Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 > ROBOTIC SYSTEMS TECHNOLOGY > 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Thu Dec 17 01:31:04 1998 From: "Michael Lawnick" Date: Thu Dec 17 01:31:07 PST 1998 Subject: Re: VxWorks: shared memory network for PowerPC (MVME2700) Check wether slave-bootrom and master-kernel have set the same #define EXTENDED_VME There has been a version shift from Rev3 (#undef) to Rev4(#define) > Vxworks gurus: > > I am trying to make a SM network with the proxy arp for the powerpc > boards (mvme2700). As described in the Programmer's manual, I included the > following in the "configAll.h": > MfG Lawnick, SOFTEC GmbH ============================================== SOFTEC GmbH Tel +49-731-96600-0 Promenade 17 Fax +49-731-96600-23 D-89073 Ulm Michael Lawnick Germany lawnick@softec.de ============================================== From owner-vxwexplo-process Thu Dec 17 04:00:25 1998 From: daemon@csg.lbl.gov Date: Thu Dec 17 04:00:30 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Dec 17 04:00:13 PST 1998 Subject: Re: Network misbeviour Subject: Re: Network misbeviour Subject: DEC 21140 driver on pc486: some fixes Subject: PPP Connect Problems Subject: DEC 21140 driver on pc486: some fixes Subject: DEC 21140 driver on pc486: some fixes Subject: Re: MPC860 chip select & cache problems Subject: Re: Looking for 860SAR ATM driver for VxWorks ?? Subject: large files and rawFs ? Subject: Strange behaviour with global variable : have you seen it before? Subject: Re: Tornado + Version Control integration Subject: PERL on VxWorks? Subject: Re: Build Output Requires Prompting? Subject: Re: Strange behaviour with global variable : have you seen it before? Subject: BOOTP / RARP server Subject: Re: DMA on MVME2600 Subject: Re: DMA on MVME2600 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Network misbeviour Date: Wed, 16 Dec 1998 17:36:57 +0000 From: Ian Love Organization: BT Labs - but speaking only for myself Message-ID: <3677EFB9.203@wireplay.bt.co.uk> References: <758neq$5ql$1@news.ncal.verio.com> Dave Craig wrote: > > Here are some symptoms that we have in our system that I'm looking for some > insight into. We run on x86 with SENS... > > * Two processors on a switched ethernet system communicate with each other > by broadcasting UDP messages. > > * If severely loaded, one processor (lets call it A) gets into a state where > it no longer seems to get messages broadcast from B in real time. They > appear to accumulate in a buffer somewhere before finally the whole lot > avalanches through. No messages appear to be lost. : : I am running MV2305 _without_ SENS, and am seeing same behaviour: raised SPR116776 with WRS some time back: no response as yet but they have given me source for the dc ethernet driver so I can instrument it. (not done yet) I had a set of test apps sending lots of small *TCP* packets to another card, which turned the packets round and returned them to a receiving app. The packets contain the sending end 'tick' time. Each sender sends a packet every 100ms. Sporadically, one of the receivers (which are measuring latency), report a latency of 300ms for one packet, 200 for next and 100 for next, implying that something is not dealing with THAT PARTICULAR CONNECTION'S DATA for a while. This is happening even when we run the ethernet interfaces at 100Mb, Full Duplex, back-to-back! options: 1) interface (in my case dc) driver problem - but it only affects SOME of the connections using the interface? 2) TCP/IP problem - but it affects your UDP as well, so: 3) IP problem - but I have non-SENS, and you have SENS (3) is favorite, but what if the driver is causing the IP layer to 'back off' by not responding or returning some kind of error....? WRS are being their usual responsive selves..... Suggest you add your weight to the SPR! regards Ian Love, The views expressed above are my own and not those of my employer --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Network misbeviour Date: Wed, 16 Dec 1998 09:56:42 -0800 From: "Dave Craig" Organization: Verio Northern California's Usenet News Service Message-ID: <758s8i$80p$1@news.ncal.verio.com> References: <758neq$5ql$1@news.ncal.verio.com> <3677EFB9.203@wireplay.bt.co.uk> Thanks Ian, it sounds like it might be the same problem. I'll go and read up on the SPR. In our case if the processor A (which has got into the "bad" state) stops receiving any new packets, then there are likely to be a number of packets that are sitting not being processed somewhere in the stack of that processor. These can be flushed through by some number of new packets arriving. This would seem to be the same as your case where a couple of packets got delayed and then flushed through (the 300ms and 200ms latency ones), Thanks again Dave. --------------------------- Newsgroups: comp.os.vxworks Subject: DEC 21140 driver on pc486: some fixes Date: Mon, 14 Dec 1998 18:06:01 GMT From: david.hagood@ifrsys.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <753k27$ahj$1@nnrp1.dejanews.com> References: <366E73A6.32FD2550@sktc.net> * |-------------------------------------| * | The transmit buffers | * | (DC_BUFSIZ * dcNumTds) | * |-------------------------------------| * | Setup Filter Frame | * | (FLTR_FRM_SIZE) | * |-------------------------------------| */ /* zero the shared memory */ bzero ( (char *) pShMem, (int) sz ); /* carve Rx memory structure */ pDrvCtrl->rxRing = (DC_RDE *) (((int)pShMem + 0x07) & ~0x07); /* wd align */ pDrvCtrl->dcNumRds = dcNumRds; /* receive ring size */ pDrvCtrl->rxIndex = 0; /* Set up the Rx descriptors */ rmd = pDrvCtrl->rxRing; /* receive ring */ buf = (char *)(rmd + pDrvCtrl->dcNumRds); for (ix = 0; ix < pDrvCtrl->dcNumRds; ix++, rmd++, buf += DC_BUFSIZ) { pTemp = DC_CACHE_VIRT_TO_PHYS (buf); /* convert to PCI phys addr */ pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp)); rmd->rDesc2 = PCISWAP((ULONG)pTemp); /* buffer address 1 */ rmd->rDesc3 = 0; /* no second buffer */ /* buffer size */ rmd->rDesc1 = PCISWAP(RDESC1_RBS1_VAL(DC_BUFSIZ) | RDESC1_RBS2_VAL(0)); if (ix == (pDrvCtrl->dcNumRds - 1)) /* if its is last one */ rmd->rDesc1 |= PCISWAP(RDESC1_RER); /* end of receive ring */ rmd->rDesc0 = PCISWAP(RDESC0_OWN); /* give ownership to lance */ } /* setup Rx loaner pool */ pDrvCtrl->nLoanRx = dcLPool; for (ix = 0; ix < dcLPool; ix++, buf += DC_BUFSIZ) { pDrvCtrl->lPool[ix] = buf; pDrvCtrl->refCnt[ix] = 0; pDrvCtrl->pRefCnt[ix] = & pDrvCtrl->refCnt[ix]; } /* carve Tx memory structure */ pDrvCtrl->txRing = (DC_TDE *) (((int)buf + 0x07) & ~0x07); /* qword align */ pDrvCtrl->dcNumTds = dcNumTds; /* transmit ring size */ pDrvCtrl->txIndex = 0; pDrvCtrl->txDiIndex = 0; /* Setup the Tx descriptors */ tmd = pDrvCtrl->txRing; /* transmit ring */ buf = (char *)(tmd + pDrvCtrl->dcNumTds); for (ix = 0; ix < pDrvCtrl->dcNumTds; ix++, tmd++, buf += DC_BUFSIZ) { pTemp = DC_CACHE_VIRT_TO_PHYS (buf); /* convert to PCI phys addr */ pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp)); tmd->tDesc2 = PCISWAP((ULONG)pTemp); /* buffer address 1 */ tmd->tDesc3 = 0; /* no second buffer */ tmd->tDesc1 = PCISWAP((TDESC1_TBS1_PUT(0) | TDESC1_TBS2_PUT(0) | TDESC1_IC | /* intrpt on xmit */ TDESC1_LS | /* last segment */ TDESC1_FS)); /* first segment */ if (ix == (pDrvCtrl->dcNumTds - 1)) /* if its is last one */ tmd->tDesc1 |= PCISWAP(TDESC1_TER); /* end of Xmit ring */ tmd->tDesc0 = 0 ; /* clear status */ } /* carve Setup Filter Frame buffer */ pDrvCtrl->pFltrFrm = (ULONG *)(((int)buf + 0x07) & ~0x07); /* word align */ buf += FLTR_FRM_SIZE; /* Flush the write pipe */ CACHE_PIPE_FLUSH (); /* Device Initialization */ dcChipReset (pDrvCtrl); /* reset the chip */ pTemp = DC_CACHE_VIRT_TO_PHYS (pDrvCtrl->rxRing); pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp)); dcCsrWrite (devAdrs, CSR3, ((ULONG)pTemp)); /* recv descriptor */ pTemp = DC_CACHE_VIRT_TO_PHYS (pDrvCtrl->txRing); pTemp = (void *)(MEM_TO_PCI_PHYS((ULONG)pTemp)); dcCsrWrite (devAdrs, CSR4, ((ULONG)pTemp)); /* xmit descriptor */ /* get the ethernet address */ /* RCP: If DEC21140 make an alternate call */ if (!DEC21140(pDrvCtrl->dcOpMode)) { if (dcEnetAddrGet (devAdrs, (char *) pDrvCtrl->idr.ac_enaddr, 6) != OK) logMsg ("dc: error reading ethernet rom\n", 0,0,0,0,0,0); } else /* Get the ethernet address for the DEC21140 */ { if (dc21140EnetAddrGet (devAdrs, (char *) pDrvCtrl->idr.ac_enaddr, 6) != OK) logMsg ("dc21140: error reading ethernet rom\n", 0,0,0,0,0,0); } /* RCP: Check to see if Full Duplex mode set */ if ((pDrvCtrl->dcOpMode & DC_FULLDUPLEX_FLAG) && (pDrvCtrl->dcOpMode != NONE)) dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_FD)); /* RCP: DEC21040 Specific Setup */ if (!DEC21140(pDrvCtrl->dcOpMode)) { dcAuiTpInit (devAdrs); /* configure AUI or 10BASE-T */ /* RCP: Added initialization of CSR6 to turn off Promiscuous and Multicast */ dcCsrWrite (devAdrs, CSR6, 0x0); } else { /* RCP: DEC21140 Setup - these modes must be set before start Xmitter */ /* Default to 10BT */ uTemp = dcCsrRead(devAdrs, CSR6); uTemp = uTemp | CSR6_TTM | CSR6_BIT25; /* Now verify the parameters passed to configure the interface further */ if ((pDrvCtrl->dcOpMode & DC_100_MB_FLAG) && (pDrvCtrl->dcOpMode != NONE)) { /* Hard Coded values from SROM offset to start 100MB testing. The actual code should be imbellished to handle the configuration for other possible interfaces other then 100BaseTx. This information will be stored in the DC21140 Info Leaf of the SROM. In the case of the DEC520-AA PMC, the starting offset for the DEC21140 Info Leaf is 0x41. This location contains some basic capabilities of the interface and the initial state of CSR12. Also there is a block count for the total number of interfaces supported by the interface card. For testing the default values for the SYM_SCR (100MBaseTx) port will be used. The information for this interface starts in offset 0x49. The configuration for Full Duplex starts in offset 0x4D. Potentially the driver could be altered to do some autosensing and configuration, but for now arguments will be passed to the driver to configure it. */ dcCsrWrite (devAdrs, CSR12, INIT_CSR12); dcCsrWrite (devAdrs, CSR12, SYM_MODE); if ((pDrvCtrl->dcOpMode & DC_HBE_FLAG) && (pDrvCtrl->dcOpMode != NONE)) uTemp = (uTemp & ~CSR6_TTM) | CSR6_PS; else uTemp = (uTemp & ~CSR6_TTM) | CSR6_PS | CSR6_HBD ; uTemp = uTemp | (((pDrvCtrl->dcOpMode & DC_SCRAMBLER_FLAG) && (pDrvCtrl->dcOpMode != NONE)) ? CSR6_SCR : 0) | (((pDrvCtrl->dcOpMode & DC_PCS_FLAG) && (pDrvCtrl->dcOpMode != NONE)) ? CSR6_PCS : 0); } else /* DDH hard wired to light up the Ziatech boards */ { dcCsrWrite (devAdrs, CSR12, 0x1FF); uTemp = CSR6_BIT25 | CSR6_TTM | CSR6_PS; dcCsrWrite(devAdrs,CSR12,0x1FF); mdio_write(devAdrs,8,4,0x1e1); mdio_write(devAdrs,8,0,0x3100); } dcCsrWrite (devAdrs, CSR6, uTemp); } /* RCP: End of DEC21140 Code Addition */ /* clear the status register */ dcCsrWrite (devAdrs, CSR5, 0xffffffff); /* set the operating mode to start Xmitter only */ /* RCP: Modify this call to accomodate DEC21140 , add the Setting of Bit 25*/ dcCsrWrite (devAdrs, CSR6, (dcCsrRead (devAdrs, CSR6) | CSR6_ST | CSR6_BIT25)); /* RCP: Added Loopback modes */ if ((pDrvCtrl->dcOpMode & DC_ILOOPB_FLAG) && (pDrvCtrl->dcOpMode != NONE)) /* RCP: Internal loopback selected */ dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_OM_ILB)); else if ((pDrvCtrl->dcOpMode & DC_ELOOPB_FLAG) && (pDrvCtrl->dcOpMode != NONE)) /* RCP: External loopback selected */ dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_OM_ELB)); /* Xmit a Filter Setup Frame */ dcFltrFrmXmit (pDrvCtrl, (char *) pDrvCtrl->idr.ac_enaddr, 1); /* set operating mode any additional operational mode set by user */ dcCsrWrite (devAdrs, CSR6, (dcCsrRead(devAdrs, CSR6) | CSR6_SR | /* start receiver */ (((pDrvCtrl->dcOpMode & DC_MULTICAST_FLAG) && (pDrvCtrl->dcOpMode != NONE)) ? CSR6_PM: 0) | (((pDrvCtrl->dcOpMode & DC_PROMISCUOUS_FLAG) && (pDrvCtrl->dcOpMode != NONE)) ? CSR6_PR: 0) )); /* set up the interrupts */ /* RCP: Modified to accomodate DEC21140 */ if (!DEC21140(pDrvCtrl->dcOpMode)) dcCsrWrite (devAdrs, CSR7, ( CSR7_NIM | /* normal interrupt mask */ CSR7_RIM | /* rcv interrupt mask */ CSR7_TIM | /* xmit interrupt mask */ CSR7_TUM | /* xmit buff unavailble mask */ CSR7_AIM | /* abnormal interrupt mask */ CSR7_SEM | /* system error mask */ CSR7_LFM | /* link fail mask */ CSR7_RUM /* rcv buff unavailable mask */ )); /* RCP: Removed CSR7_LFM for DEC21140 */ else dcCsrWrite (devAdrs, CSR7, ( CSR7_NIM | /* normal interrupt mask */ CSR7_RIM | /* rcv interrupt mask */ CSR7_TIM | /* xmit interrupt mask */ CSR7_TUM | /* xmit buff unavailble mask */ CSR7_AIM | /* abnormal interrupt mask */ CSR7_SEM | /* system error mask */ CSR7_RUM /* rcv buff unavailable mask */ )); sysLanIntEnable (ilevel); /* enable LANCE interrupts */ pDrvCtrl->idr.ac_if.if_flags |= (IFF_UP | IFF_RUNNING | IFF_NOTRAILERS); /* Set our flag */ pDrvCtrl->attached = TRUE; return (OK); } /******************************************************************************* * * dcReset - reset the interface * * Mark interface as inactive & reset the chip */ LOCAL void dcReset ( int unit ) { DRV_CTRL *pDrvCtrl = & drvCtrl [unit]; pDrvCtrl->idr.ac_if.if_flags = 0; dcChipReset (pDrvCtrl); /* reset LANCE */ } /******************************************************************************* * * dcInt - handle controller interrupt * * This routine is called at interrupt level in response to an interrupt from * the controller. */ LOCAL void dcInt ( DRV_CTRL * pDrvCtrl /* pointer to device control struct */ ) { DC_TDE * tmd; /* pointer to Xmit ring descriptor */ ULONG stat; /* status register */ ULONG devAdrs; /* device address */ devAdrs = pDrvCtrl->devAdrs; /* Read the device status register */ stat = dcCsrRead(devAdrs, CSR5); /* clear the interrupts */ dcCsrWrite(devAdrs, CSR5, stat); /* If false interrupt, return. */ if ( ! (stat & (CSR5_NIS | CSR5_AIS)) ) return; /* Check for system error */ if (stat & CSR5_SE) { ++pDrvCtrl->idr.ac_if.if_ierrors; /* restart chip on fatal error */ pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING); (void) netJobAdd ( (FUNCPTR)dcRestart, pDrvCtrl->idr.ac_if.if_unit, 0,0,0,0 ); return; } /* Have netTask handle any input packets */ if ((stat & CSR5_RI) && (!(stat & CSR5_RPS))) { (void) netJobAdd ( (FUNCPTR)dcHandleRecvInt, (int)pDrvCtrl, 0,0,0,0 ); /* disable the Rx intr, re-enable in dcHandleRecvInt() */ dcCsrWrite(devAdrs, CSR7, (stat & ~CSR7_RIM)); } /* * Did LANCE update any of the TMD's? * If not then don't bother continuing with transmitter stuff */ if (!(stat & CSR5_TI)) return; while (pDrvCtrl->txDiIndex != pDrvCtrl->txIndex) { /* disposal has not caught up */ tmd = pDrvCtrl->txRing + pDrvCtrl->txDiIndex; /* if the buffer is still owned by LANCE, don't touch it */ DC_CACHE_INVALIDATE (tmd, TMD_SIZ); if (tmd->tDesc0 & PCISWAP(TDESC0_OWN)) break; /* now bump the tmd disposal index pointer around the ring */ pDrvCtrl->txDiIndex = (pDrvCtrl->txDiIndex + 1) % pDrvCtrl->dcNumTds; /* * TDESC0.ES is an "OR" of LC, NC, UF, EC. * here for error conditions. */ if (tmd->tDesc0 & PCISWAP(TDESC0_ES)) { pDrvCtrl->idr.ac_if.if_oerrors++; /* output error */ pDrvCtrl->idr.ac_if.if_opackets--; /* If error was due to excess collisions, bump the collision * counter. */ if (tmd->tDesc0 & PCISWAP(TDESC0_EC)) pDrvCtrl->idr.ac_if.if_collisions += 16; /* bump the collision counter if late collision */ if (tmd->tDesc0 & PCISWAP(TDESC0_LC)) pDrvCtrl->idr.ac_if.if_collisions++; /* check for no carrier */ if (tmd->tDesc0 & PCISWAP(TDESC0_NC | TDESC0_LO | TDESC0_LF)) logMsg ("dc%d: no carrier\n", pDrvCtrl->idr.ac_if.if_unit, 0,0,0,0,0); /* Restart chip on fatal errors. * The following code handles the situation where the transmitter * shuts down due to an underflow error. This is a situation that * will occur if the DMA cannot keep up with the transmitter. * It will occur if the LANCE is being held off from DMA access * for too long or due to significant memory latency. DRAM * refresh or slow memory could influence this. Many * implementation use a dedicated LANCE buffer. This can be * static RAM to eliminate refresh conflicts; or dual-port RAM * so that the LANCE can have free run of this memory during its * DMA transfers. */ if (tmd->tDesc0 & PCISWAP(TDESC0_UF)) { pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING); (void) netJobAdd ( (FUNCPTR)dcRestart, pDrvCtrl->idr.ac_if.if_unit, 0,0,0,0 ); return; } } tmd->tDesc0 = 0; /* clear all error & stat stuff */ } /* Flush the write pipe */ CACHE_PIPE_FLUSH (); } /******************************************************************************* * * dcHandleRecvInt - task level interrupt service for input packets * * This routine is called at task level indirectly by the interrupt * service routine to do any message received processing. */ LOCAL void dcHandleRecvInt ( DRV_CTRL * pDrvCtrl /* pointer to device control struct */ ) { DC_RDE * rmd; /* pointer to Rx ring descriptor */ while ((rmd = dcGetFullRMD (pDrvCtrl)) != NULL) dcRecv (pDrvCtrl, rmd); /* re-enable the Rx interrupt */ dcCsrWrite (pDrvCtrl->devAdrs, CSR7, (dcCsrRead (pDrvCtrl->devAdrs, CSR7) | CSR7_RIM)); } /******************************************************************************* * * dcGetFullRMD - get next received message RMD * * Returns ptr to next Rx desc to process, or NULL if none ready. */ LOCAL DC_RDE * dcGetFullRMD ( DRV_CTRL * pDrvCtrl /* pointer to device control struct */ ) { DC_RDE * rmd; /* pointer to Rx ring descriptor */ /* Refuse to do anything if flags are down */ if ( (pDrvCtrl->idr.ac_if.if_flags & (IFF_UP | IFF_RUNNING) ) != (IFF_UP | IFF_RUNNING) ) return ((DC_RDE *) NULL); rmd = pDrvCtrl->rxRing + pDrvCtrl->rxIndex; /* form ptr to Rx desc */ DC_CACHE_INVALIDATE (rmd, RMD_SIZ); if ((rmd->rDesc0 & PCISWAP(RDESC0_OWN)) == 0) return (rmd); else return ((DC_RDE *) NULL); } /******************************************************************************* * * dcRecv - process the next incoming packet * */ LOCAL STATUS dcRecv ( DRV_CTRL * pDrvCtrl, /* pointer to device control struct */ DC_RDE * rmd /* pointer to Rx ring descriptor */ ) { ENET_HDR * pEnetHdr; /* pointer to ethernet header */ MBUF * pMbuf = NULL; /* pointer to mbuf */ u_long pPhys; UCHAR * pData; /* pointer to data */ int len; /* length */ USHORT ether_type; /* ether packet type */ /* Packet must be checked for errors. */ if (rmd->rDesc0 & PCISWAP(RDESC0_ES)) /* If error flag */ { /* error can occur on overflow, crc error, collision, * frame too long, runt frame or length error */ ++pDrvCtrl->idr.ac_if.if_ierrors; /* bump error stat */ goto cleanRXD; /* skip to clean up */ } ++pDrvCtrl->idr.ac_if.if_ipackets; /* bump statistic */ len = RDESC0_FL_GET(PCISWAP(rmd->rDesc0)); /* frame length */ len -= 4; /* Frame length includes CRC in it so subtract it */ /* Get pointer to packet */ pEnetHdr = DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(rmd->rDesc2))); DC_CACHE_INVALIDATE (pEnetHdr, len); /* make the packet data coherent */ /* call input hook if any */ if ((etherInputHookRtn == NULL) || ((*etherInputHookRtn) (& pDrvCtrl->idr.ac_if, (char *) pEnetHdr, len)) == 0) { /* Adjust length to size of data only */ len -= SIZEOF_ETHERHEADER; /* Get pointer to packet data */ pData = ((u_char *) pEnetHdr) + SIZEOF_ETHERHEADER; ether_type = ntohs ( pEnetHdr->type ); /* OK to loan out buffer ? -> build an mbuf cluster */ if ((pDrvCtrl->nLoanRx > 0) && (USE_CLUSTER (len)) && ((pMbuf = build_cluster (pData, len, & pDrvCtrl->idr, MC_LANCE, pDrvCtrl->pRefCnt [(pDrvCtrl->nLoanRx - 1)], dcLoanFree, (int) pDrvCtrl, (int) pEnetHdr, (int) pDrvCtrl->pRefCnt [(pDrvCtrl->nLoanRx - 1)])) != NULL)) { pPhys = (u_long) DC_CACHE_VIRT_TO_PHYS(MEM_TO_PCI_PHYS( (pDrvCtrl->lPool[--pDrvCtrl->nLoanRx]))); rmd->rDesc2 = PCISWAP(pPhys); } else { if ((pMbuf = bcopy_to_mbufs (pData, len, 0, & pDrvCtrl->idr.ac_if, pDrvCtrl->memWidth)) == NULL) { ++pDrvCtrl->idr.ac_if.if_ierrors; /* bump error stat */ goto cleanRXD; } } /* send on up... */ do_protocol_with_type (ether_type, pMbuf, & pDrvCtrl->idr, len); /* RCP: This is a redundant increment of incoming packets, removed from original driver */ /* ++pDrvCtrl->idr.ac_if.if_ipackets;*/ /* bump statistic */ } /* Done with descriptor, clean up and give it to the device. */ cleanRXD: /* clear status bits and give ownership to device */ rmd->rDesc0 = PCISWAP(RDESC0_OWN); /* Flush the write pipe */ CACHE_PIPE_FLUSH (); /* Advance our management index */ pDrvCtrl->rxIndex = (pDrvCtrl->rxIndex + 1) % pDrvCtrl->dcNumRds; return (OK); } /******************************************************************************* * * dcOutput - the driver output routine * */ LOCAL int dcOutput ( IDR * pIDR, /* pointer to interface data record */ MBUF * pMbuf, /* pointer to mbuf */ SOCK * pDest /* pointer to destination sock */ ) { char destEnetAddr [6]; /* space for enet addr */ USHORT packetType; /* type field for the packet */ DRV_CTRL * pDrvCtrl; /* pointer to device control struct */ DC_TDE * tmd; /* pointer to Tx ring descriptor */ char * buf; /* pointer to buffer */ int len; /* length */ /* Check ifnet flags. Return error if incorrect. */ if ( (pIDR->ac_if.if_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING) ) return (ENETDOWN); /* Attempt to convert socket addr into enet addr and packet type. * Note that if ARP resolution of the address is required, the ARP * module will call our routine again to transmit the ARP request * packet. This means we may actually call ourselves recursively! */ if (convertDestAddr (pIDR,pDest, destEnetAddr, &packetType, pMbuf) == FALSE) return (OK); /* I KNOW returning OK is stupid, but it is correct */ /* Get driver control pointer */ pDrvCtrl = & drvCtrl [pIDR->ac_if.if_unit]; /* Obtain exclusive access to transmitter. This is necessary because * certain events can cause netTask to run a job that attempts to transmit * a packet. We can only allow one task here at a time. */ semTake (pDrvCtrl->TxSem, WAIT_FOREVER); /* See if next TXD is available */ tmd = pDrvCtrl->txRing + pDrvCtrl->txIndex; DC_CACHE_INVALIDATE (tmd, TMD_SIZ); if ( ((tmd->tDesc0 & PCISWAP(TDESC0_OWN)) != 0) || ( ((pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds) == pDrvCtrl->txDiIndex ) ) { m_freem (pMbuf); /* Discard data */ goto outputDone; } /* Get pointer to transmit buffer */ buf = (char *)DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(tmd->tDesc2))); /* Copy packet from MBUFs to our transmit buffer. MBUFs are * transparently freed. */ bcopy_from_mbufs ((buf + SIZEOF_ETHERHEADER), pMbuf, len, pDrvCtrl->memWidth); /* Fill in the Ethernet header */ bcopy (destEnetAddr, buf, 6); bcopy ( (char *) pIDR->ac_enaddr, (buf + 6), 6); ((ENET_HDR *)buf)->type = htons(packetType); tmd->tDesc0 = 0; /* clear buffer error status */ tmd->tDesc1 &= PCISWAP(~TDESC1_TBS1_MSK); tmd->tDesc1 |= PCISWAP(TDESC1_TBS1_PUT(max (ETHERSMALL, (len + SIZEOF_ETHERHEADER)))); tmd->tDesc0 = PCISWAP(TDESC0_OWN); /* give ownership to device */ CACHE_PIPE_FLUSH (); /* Flush the write pipe */ /* Advance our management index */ pDrvCtrl->txIndex = (pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds; if (dcKickStartTx) dcCsrWrite(pDrvCtrl->devAdrs, CSR1, CSR1_TPD); /* xmit poll demand */ /* Bump the statistic counter. */ pIDR->ac_if.if_opackets++; outputDone: /* Release exclusive access. */ semGive (pDrvCtrl->TxSem); return (OK); } /******************************************************************************* * * dcIoctl - the driver I/O control routine * * Process an ioctl request. */ LOCAL int dcIoctl ( IDR * ifp, /* pointer interface data record */ int cmd, /* command */ caddr_t data /* data */ ) { int error = 0; DRV_CTRL * pDrvCtrl = (DRV_CTRL *)ifp; /* pointer to device */ switch (cmd) { case SIOCSIFADDR: ifp->ac_ipaddr = IA_SIN (data)->sin_addr; break; case SIOCSIFFLAGS: /* No further work to be done */ break; case IFF_PROMISC: /* set device in promiscuous mode */ dcCsrWrite (pDrvCtrl->devAdrs, CSR6, (dcCsrRead(pDrvCtrl->devAdrs, CSR6) | CSR6_PR)); break; default: error = EINVAL; } return (error); } /**************************************************************************** *** * * dcChipReset - hardware reset of chip (stop it) */ LOCAL int dcChipReset ( DRV_CTRL * pDrvCtrl /* pointer to device control structure */ ) { ULONG devAdrs = pDrvCtrl->devAdrs; /* device base address */ ULONG volatile ix; /* index */ dcCsrWrite(devAdrs, CSR6, CSR6_PS); /* stop rcvr & xmitter */ dcCsrWrite(devAdrs, CSR7, 0); /* mask interrupts */ dcCsrWrite(devAdrs, CSR0, CSR0_SWR); /* Wait Loop, Loop for at least 50 PCI cycles according to chip spec */ for (ix = 0; ix < 0x1000; ix++) dcCsrRead(devAdrs,CSR0); /* any additional bus mode | give xmit & rcv process equal priority */ dcCsrWrite (devAdrs, CSR0, dcCSR0Bmr | CSR0_BAR); for (ix = 0; ix < 0x1000; ix++) /* loop for some cycles */ ; return (OK); } /******************************************************************************* * * dcAuiTpInit - initialize either AUI or 10BASE-T connection * * This function configures 10BASE-T interface. If the link pass state is * not achieved within two seconds then the AUI interface is initialized. */ LOCAL void dcAuiTpInit ( ULONG devAdrs /* device base I/O address */ ) { /* reset the SIA registers */ dcCsrWrite (devAdrs, CSR13, 0); dcCsrWrite (devAdrs, CSR14, 0); dcCsrWrite (devAdrs, CSR15, 0); /* configure for the 10BASE-T */ dcCsrWrite (devAdrs, CSR13, CSR13_CAC_CSR); /* 10BT auto configuration */ taskDelay (sysClkRateGet() * 2); /* 2 second delay */ if (dcCsrRead (devAdrs, CSR12) & (CSR12_LKF | CSR12_NCR)) { /* 10BASE-T not connected initialize interface for AUI */ dcCsrWrite (devAdrs, CSR13, 0); /* reset SIA registers */ dcCsrWrite (devAdrs, CSR14, 0); dcCsrWrite (devAdrs, CSR15, 0); /* AUI auto configuration */ dcCsrWrite (devAdrs, CSR13, (CSR13_AUI_TP | CSR13_CAC_CSR)); } } /******************************************************************************* * * dcCsrWrite - select and write a CSR register * */ LOCAL void dcCsrWrite ( ULONG devAdrs, /* device address base */ int reg, /* register to select */ ULONG value /* value to write */ ) { #ifdef MEM_MAPPED volatile ULONG * csrReg; csrReg = (ULONG *)(devAdrs + (reg * DECPCI_REG_OFFSET)); /* write val to CSR */ *(csrReg) = PCISWAP(value); #else sysOutLong(devAdrs+(reg* DECPCI_REG_OFFSET),value); #endif } /******************************************************************************* * * dcCsrRead - select and read a CSR register * */ LOCAL ULONG dcCsrRead ( ULONG devAdrs, /* device address base */ int reg /* register to select */ ) { #ifdef MEM_MAPPED volatile ULONG * csrReg; /* csr register */ ULONG csrData; /* data in csr register */ csrReg = (ULONG *)(devAdrs + (reg * DECPCI_REG_OFFSET)); csrData = *csrReg; /* get contents of CSR */ return ( PCISWAP(csrData)); #else return sysInLong(devAdrs + (reg * DECPCI_REG_OFFSET)); #endif } /******************************************************************************* * * dcRestart - restart the device after a fatal error * * This routine takes care of all the messy details of a restart. The device * is reset and re-initialized. The driver state is re-synchronized. */ LOCAL void dcRestart ( int unit /* unit to restart */ ) { ULONG status; /* status register */ int ix; /* index variable */ DC_RDE * rmd; /* pointer to receive descriptor */ DC_TDE * tmd; /* pointer to Xmit descriptor */ DRV_CTRL * pDrvCtrl = & drvCtrl [unit]; rmd = pDrvCtrl->rxRing; /* receive ring */ tmd = pDrvCtrl->txRing; /* transmit ring */ pDrvCtrl->idr.ac_if.if_flags &= ~(IFF_UP | IFF_RUNNING ); fprintf (stderr, "Fatal Error. DEC Ethernet Chip Restarted\n"); status = dcCsrRead(pDrvCtrl->devAdrs, CSR6); dcCsrWrite (pDrvCtrl->devAdrs, CSR6, 0); /* reset mode register */ for (ix = 0; ix < pDrvCtrl->dcNumRds; ix++, rmd++) { /* buffer size */ rmd->rDesc1 = PCISWAP(RDESC1_RBS1_VAL(DC_BUFSIZ) | RDESC1_RBS2_VAL(0)); if (ix == (pDrvCtrl->dcNumRds - 1)) /* if its is last one */ rmd->rDesc1 |= PCISWAP(RDESC1_RER); /* end of receive ring */ rmd->rDesc0 = PCISWAP(RDESC0_OWN); /* give ownership to lance */ } for (ix = 0; ix < pDrvCtrl->dcNumTds; ix++, tmd++) { tmd->tDesc1 = PCISWAP((TDESC1_TBS1_PUT(0) | TDESC1_TBS2_PUT(0) | TDESC1_IC | /* intrpt on xmit */ TDESC1_LS | /* last segment */ TDESC1_FS)); /* first segment */ if (ix == (pDrvCtrl->dcNumTds - 1)) /* if its is last one */ tmd->tDesc1 |= PCISWAP(TDESC1_TER); /* end of Xmit ring */ tmd->tDesc0 = 0 ; /* clear status */ } /* clear the status register */ dcCsrWrite (pDrvCtrl->devAdrs, CSR5, 0xffffffff); dcCsrWrite (pDrvCtrl->devAdrs, CSR6, status); /* restore mode */ pDrvCtrl->idr.ac_if.if_flags |= (IFF_UP | IFF_RUNNING | IFF_NOTRAILERS); } /******************************************************************************* * * dcLoanFree - return the given buffer to loaner pool * * This routine returns to the pool of available loaner buffers. * It also returns to the pool of available loaner reference counters, * then zeroes the reference count. * * RETURNS: N/A */ LOCAL void dcLoanFree ( DRV_CTRL * pDrvCtrl, /* pointer to device control structure */ char * pRxBuf, /* pointer to receive buffer to free */ UINT8 * pRef /* pointer to reference count */ ) { /* return loaned buffer to pool */ pDrvCtrl->lPool[pDrvCtrl->nLoanRx] = pRxBuf; /* return loaned reference count to pool */ pDrvCtrl->pRefCnt[pDrvCtrl->nLoanRx++] = pRef; /* reset reference count - should have been done from above, but... */ *pRef = 0; } - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: PPP Connect Problems Date: Wed, 16 Dec 1998 11:21:48 -0700 From: Rick Busser Organization: Dimensional Communications Message-ID: <3677FA3C.E807A865@sitera.com> I'm trying to run VxWorks on a MIPS BSP using PPP as the boot device. When I attach COM2 on my NT machine to COM2 from the MIPS board I see garbage instead of WDB READY. I have the serial ports set up the same way, 9600, 8 data, 1 stop, no flow control. Does anyone have any ideas on what to change so I can get WDB READY on COM2? Has anyone else had this problem? I changed the VxWorks image to echo all characters typed on COM2 and then I see the WDB READY message. But then I can't run target server because the boot never finishes. - -- Rick Busser rickb@sitera.com Software Engineer (303) 651-1935 x256 SiTera Corporation (303) 651-1199 fax 1820 Lefthand Circle Longmont, CO 80501 --------------------------- Newsgroups: comp.os.vxworks Subject: DEC 21140 driver on pc486: some fixes Date: Mon, 14 Dec 1998 18:04:06 GMT From: david.hagood@ifrsys.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <753jum$adq$1@nnrp1.dejanews.com> References: <366E73A6.32FD2550@sktc.net> After much slogging, I've managed to get the DEC 21140 network driver for VxWorks (the if_dcfast.c driver) working under x486 VxWorks. I'll list my changes and attach my file here in case anybody cares. The changes: 1) I hardwired the initialization of the MII PHY chip. The may not work for everybody but it got me going. 2) I hardwired the parameters to the init call. I didn't write the code to parse the PCI information and find the board, so you'll have to find your board. Use the PCISHOW library routines. 3) The code to read the MAC address out of the 21140 EEPROM was broken for little-endian machines. 4) The code to place the ethernet packet type into the ethernet header was broken for little-endian machines. Other useful info: The DEC21140 is no longer a Digital Equipment Corp. chip: Intel now owns it. If you want info, go to www.intel.com, not www.digital.com. Here's the changed file: /* if_dcFast.c - DEC 21040 PCI Ethernet LAN network interface driver */ /* Copyright 1984-1995 Wind River Systems, Inc. */ #include "copyright_wrs.h" /* modification history - -------------------- 01e,06mar96,rcp added support for the DEC21140 100Mbit Controller 01d,05sep95,vin added filter Frame setup, added PROMISCOUS MODE to ioctl, changed all ln references to dc, added flag DC_MULTICAST_FLAG. 01c,05apr95,vin added AUI/10BASE-T dynamic configuration support. 01b,31mar95,caf changed name from "dcPci" to "dc". 01a,03mar95,vin written. */ /* FROM ROB PERSONS - Motorola Computer Group (March 06, 1996) The comments below describe the primary operation and configuration of the DEC 21X40 driver. Differences between the two DEC parts will be outlined in this section and how the original driver was modified to accomodate the differences. The DEC21140 is very similar to the original DEC21040 but it also has the ability to operate on networks at 100-Mb/s along with 10-Mb/s. The physical interface is no longer part of the chip so configuration of the CSR registers which control the AUI and TP interfaces is no longer applicable. This part now provides 100-Mb/s MII/SYM 10-Mb/s Serial intefaces which are then converted to the appropriate external interface with some additional hardware. Most of the driver will be uneffected by the new part. In the early stages of the driver initialization, the driver will use the Configuration ID Register (CFID) to determine which of the two parts is to be used. A global flag will indicate which device is in use and its state will be used along with the driver modifications to accomodate the DEC21140. The Status Register (CSR5) has three bits which have different behavior. Bit 12 (Link Fail Status) and Bit 10 (AUI/TP Status) are no longer used by the DEC21140. Bit 11 in the DEC21040 indicates a Full-Duplex Short Frame was Received which in the DEC21140 it indicates the General Purpose Timer(GPT) has expired. The GPT is a new feature with the DEC21140. Bit 11 is currently not used in the drive and there are no plans on adding support for the GPT so at this time it will be ignored. The Operating Mode Register (CSR6) is significantly different. Many of the bits reflect the difference in the MII/SYM interface for the 100-Mb/s interface. To make the driver as flexible as possible, logic will be added to the dcattach function to allow for the configuration of all these control bits at driver configuration. The following modes will be added: DEC21140 Flag - This flag indicates the driver will be operating with a DEC21140 chip and not the DEC21040. 100Mb/s Mode - This flag will be used to set a bits in the CSR6 for the DEC21140. The Transmit Threshold Mode and Heartbeat Disable bits will be effect. Scramble Mode - The scrambler function is active and the MII/SYM port transmits and received scrambled symbols. PCS Function - The PCS functions are active and MII/SYM port operates in symbol mode. All MII/SYM port cont andol signals are generated internally bits will be effect. Port Select - When selected the MII/SYM mode is active. All 100-Mb/s modes require this. Full Duplex Mode- When selected the Lance Chip Operates in Full Duplex Mode. It is important that the can operate in Full Duplex mode as well. Int Loopback - An additional mode was added for doing internal loopback. Ext Loopback - An additional mode was added for doing external loopback. HB Enable - An additional mode was added for testing, enableing heartb. If none of these mode bits are selected, the DEC21140 will default to the MII interface with transmit FIFO thresholds appropriate for 10-Mb/s. Additional code will be added to deal with the different Serial ROM interface. The DEC21140 now has a new interface to access a R/W ROM part to store ethernet addresses. The dcEnetAddrGet will be modified to add the proper logic to read the DEC21140 Serial ROM interface. No logic will be added to reprogram the value. It turns out the DEC PMC 520-AA only stores the last 2 bytes of the ethernet address in the ROM. The driver will make the assumption that the VENDOR ID portion extends to from 0-3 where bytes 0-2 are the manufacturers assigned values and byte 3 is assigned by DEC for the class of products. The remaining Host to Controller interface is identical and should not be effected by the new part. */ /* This module implements the DEC 21040-PCI Ethernet 32 bit network interface driver. The DEC 21040-PCI ethernet controller is inherently little endian because the chip is designed to operate on a PCI bus which is a little endian bus. The software interface to the driver is divided into three parts. The first part is the PCI configuration registers and their set up. This part is done at the BSP level in the various BSPs which use this driver. The second and third part are dealt in the driver. The second part of the interface comprises of the I/O control registers and their programming. The third part of the interface comprises of the descriptors and the buffers. This driver is designed to be moderately generic, operating unmodified across the range of architectures and targets supported by VxWorks. To achieve this, the driver must be given several target-specific parameters, and some external support routines must be provided. These parameters, and the mechanisms used to communicate them to the driver, are detailed below. If any of the assumptions stated below are not true for your particular hardware, this driver will probably not function correctly with it. This driver supports upto 4 lance units per CPU. The driver can be configured to support big-endian or little-endian architectures. It contains error recovery code to handle known device errata related to DMA activity. This driver configures the 10BASE-T interface by default and waits for two seconds to check the status of the link. If the link status is fail then it configures the AUI interface. Big endian processors can be connected to the PCI bus through some controllers which take care of hardware byte swapping. In such cases all the registers which the chip DMA s to have to be swapped and written to, so that when the hardware swaps the accesses, the chip would see them correctly. The chip still has to be programmed to operated in little endian mode as it is on the PCI bus. If the cpu board hardware automatically swaps all the accesses to and from the PCI bus, then input and output byte stream need not be swapped. BOARD LAYOUT This device is on-board. No jumpering diagram is necessary. EXTERNAL INTERFACE This driver provides the standard external interface with the following exceptions. All initialization is performed within the attach routine; there is no separate initialization routine. Therefore, in the global interface structure, the function pointer to the initialization routine is NULL. The only user-callable routine is dcattach(), which publishes the `dc' interface and initializes the driver and device. TARGET-SPECIFIC PARAMETERS .iP "bus mode" This parameter is a global variable that can be modified at run-time. The LAN control register #0 determines the bus mode of the device, allowing the support of big-endian and little-endian architectures. This parameter, defined as "ULONG dcCSR0Bmr", is the value that will be placed into LANCE control register #0. The default is mode is little Endian. For information about changing this parameter, see the manual .I "DEC Local Area Network Controller DEC21040 or DEC21140 for PCI." .iP "base address of device registers" This parameter is passed to the driver by dcattach(). .iP "interrupt vector" This parameter is passed to the driver by dcattach(). This driver configures the LANCE device to generate hardware interrupts for various events within the device; thus it contains an interrupt handler routine. The driver calls intConnect() to connect its interrupt handler to the interrupt vector generated as a result of the LANCE interrupt. .iP "interrupt level" This parameter is passed to the driver by dcattach(). Some targets use additional interrupt controller devices to help organize and service the various interrupt sources. This driver avoids all board-specific knowledge of such devices. During the driver's initialization, the external routine sysLanIntEnable() is called to perform any board-specific operations required to allow the servicing of a LANCE interrupt. For a description of sysLanIntEnable(), see "External Support Requirements" below. This parameter is passed to the external routine. .iP "shared memory address" This parameter is passed to the driver by dcattach(). The LANCE device is a DMA type of device and typically shares access to some region of memory with the CPU. This driver is designed for systems that directly share memory between the CPU and the LANCE. It assumes that this shared memory is directly available to it without any arbitration or timing concerns. This parameter can be used to specify an explicit memory region for use by the LANCE. This should be done on hardware that restricts the LANCE to a particular memory region. The constant NONE can be used to indicate that there are no memory limitations, in which case, the driver attempts to allocate the shared memory from the system space. .iP "shared memory size" This parameter is passed to the driver by dcattach(). This parameter can be used to explicitly limit the amount of shared memory (bytes) this driver will use. The constant NONE can be used to indicate no specific size limitation. This parameter is used only if a specific memory region is provided to the driver. .iP "shared memory width" This parameter is passed to the driver by dcattach(). Some target hardware that restricts the shared memory region to a specific location also restricts the access width to this region by the CPU. On these targets, performing an access of an invalid width will cause a bus error. This parameter can be used to specify the number of bytes of access width to be used by the driver during access to the shared memory. The constant NONE can be used to indicate no restrictions. Current internal support for this mechanism is not robust; implementation may not work on all targets requiring these restrictions. .iP "shared memory buffer size" This parameter is passed to the driver by dcattach(). The driver and LANCE device exchange network data in buffers. This parameter permits the size of these individual buffers to be limited. A value of zero indicates that the default buffer size should be used. The default buffer size is large enough to hold a maximum-size Ethernet packet. .iP "pci Memory base" This parameter is passed to the driver by dcattach(). This parameter gives the base address of the main memory on the PCI bus. .iP "dcOpMode" This parameter is passed to the driver by dcattach(). This parameter gives the mode of initialization of the device. The mode flags for both the DEC21040 and DEC21140 interfaces are listed below. DC_PROMISCUOUS_FLAG 0x01 DC_MULTICAST_FLAG 0x02 The mode flags specific to the DEC21140 interface are listed below. DC_100_MB_FLAG 0X04 DC_21140_FLAG 0x08 DC_SCRAMBLER_FLAG 0X10 DC_PCS_FLAG 0x20 DC_PS_FLAG 0x40 The Full Duplex Mode was added to the driver. DC_FULLDUPLEX_FLAG 0x80 Loopback mode flags DC_ILOOPB_FLAG 0x100 DC_ELOOPB_FLAG 0x200 DC_HBE_FLAG 0x400 .iP "Ethernet address" This is obtained by the driver by reading an ethernet ROM register interfaced with the device. .LP EXTERNAL SUPPORT REQUIREMENTS This driver requires one external support function: .iP "void sysLanIntEnable (int level)" "" 9 -1 This routine provides a target-specific enable of the interrupt for the LANCE device. Typically, this involves interrupt controller hardware, either internal or external to the CPU. This routine is called once, from the dcattach() routine. .LP SEE ALSO: ifLib, .I "DECchip 21040 or 21140 Ethernet LAN Controller for PCI." */ #include "vxWorks.h" #include "stdlib.h" #include "taskLib.h" #include "logLib.h" #include "intLib.h" #include "netLib.h" #include "stdio.h" #include "stdlib.h" #include "sysLib.h" #include "iv.h" #include "memLib.h" #include "cacheLib.h" #include "sys/ioctl.h" #include "etherLib.h" #ifndef DOC /* don't include when building documentation */ #include "net/mbuf.h" #endif /* DOC */ #include "net/protosw.h" #include "sys/socket.h" #include "errno.h" #include "net/if.h" #include "net/route.h" #include "netinet/in.h" #include "netinet/in_systm.h" #include "netinet/in_var.h" #include "netinet/ip.h" #include "netinet/if_ether.h" #include "net/if_subr.h" #include "semLib.h" #include "if_dcFast.h" /* device description header */ /* defines */ #define DC_BUFSIZ (ETHERMTU + SIZEOF_ETHERHEADER + 6) #define MAX_UNITS 4 /* maximum units supported */ #define DC_L_POOL 0x10 /* number of Rx loaner buffers in pool */ #define LOOP_PER_NS 4 #define DELAY(count) {\ volatile int cx = 0;\ for (cx = 0; cx < (count); cx++);\ } #define NSDELAY(nsec) {\ volatile int nx = 0;\ volatile int loop = (int)(nsec*LOOP_PER_NS);\ for (nx = 0; nx < loop; nx++);\ } /* RCP: Added DEC Part Check */ #define DEC21140(x) ((x & DC_21140_FLAG) && (x != NONE)) /* * If DC_KICKSTART_TX is TRUE the transmitter is kick-started to force a * read of the transmit descriptors, otherwise the internal polling (1.6msec) * will initiate a read of the descriptors. This should be FALSE is there * is any chance of memory latency or chip accesses detaining the LANCE DMA, * which results in a transmitter UFLO error. This can be changed with the * global dcKickStartTx below. */ #define DC_KICKSTART_TX TRUE /* Cache macros */ #define DC_CACHE_INVALIDATE(address, len) \ CACHE_DRV_INVALIDATE (&pDrvCtrl->cacheFuncs, (address), (len)) #define DC_CACHE_VIRT_TO_PHYS(address) \ CACHE_DRV_VIRT_TO_PHYS (&pDrvCtrl->cacheFuncs, (address)) #define DC_CACHE_PHYS_TO_VIRT(address) \ CACHE_DRV_PHYS_TO_VIRT (&pDrvCtrl->cacheFuncs, (address)) /* memory to PCI address translation macros */ #define PCI_TO_MEM_PHYS(pciAdrs) \ ((pciAdrs) - (pDrvCtrl->pciMemBase)) #define MEM_TO_PCI_PHYS(memAdrs) \ ((memAdrs) + (pDrvCtrl->pciMemBase)) /* Typedefs for external structures that are not typedef'd in their .h files */ typedef struct mbuf MBUF; typedef struct arpcom IDR; /* Interface Data Record wrapper */ typedef struct ifnet IFNET; /* real Interface Data Record */ typedef struct sockaddr SOCK; /* The definition of the driver control structure */ typedef struct drv_ctrl { IDR idr; /* Interface Data Record */ int dcNumRds; /* RMD ring size */ int rxIndex; /* index into RMD ring */ DC_RDE * rxRing; /* RMD ring */ int dcNumTds; /* TMD ring size */ int txIndex; /* index into TMD ring */ int txDiIndex; /* disposal index into TMD ring */ DC_TDE * txRing; /* TMD ring */ BOOL attached; /* indicates unit is attached */ SEM_ID TxSem; /* transmitter semaphore */ ULONG dcOpMode; /* mode of operation */ int ivec; /* interrupt vector */ int ilevel; /* interrupt level */ ULONG devAdrs; /* device structure address */ ULONG pciMemBase; /* memory base as seen from PCI*/ int memWidth; /* width of data port */ CACHE_FUNCS cacheFuncs; /* cache function pointers */ int nLoanRx; /* number of Rx buffers left to loan */ char *lPool[DC_L_POOL]; /* receive loaner pool ptrs */ UINT8 *pRefCnt[DC_L_POOL]; /* stack of reference count pointers */ UINT8 refCnt[DC_L_POOL]; /* actual reference count values */ ULONG * pFltrFrm; /* pointer to setup filter frame */ } DRV_CTRL; #define DRV_CTRL_SIZ sizeof(DRV_CTRL) #define RMD_SIZ sizeof(DC_RDE) #define TMD_SIZ sizeof(DC_TDE) /* globals */ /* RCP: Reference Removed for new function IMPORT void sysLanIntEnable (); */ IMPORT BOOL arpresolve (); /* IMPORT unsigned char dcEnetAddr []; *//* Ethernet address to load into lance */ BOOL dcKickStartTx = DC_KICKSTART_TX; ULONG dcCSR0Bmr = 0x8000; /* cache align 16 words */ /* locals */ LOCAL DRV_CTRL drvCtrl [MAX_UNITS]; /* array of driver control structs */ LOCAL int dcNumRds = NUM_RDS; /* number of ring descriptors */ LOCAL int dcNumTds = NUM_TDS; /* number of xmit descriptors */ LOCAL int dcLPool = DC_L_POOL; /* forward static functions */ LOCAL void dcReset (int unit); LOCAL void dcInt (DRV_CTRL *pDrvCtrl); LOCAL void dcHandleRecvInt (DRV_CTRL *pDrvCtrl); LOCAL STATUS dcRecv (DRV_CTRL *pDrvCtrl, DC_RDE *rmd); LOCAL int dcOutput (IDR *ifp, MBUF *m0, SOCK *dst); LOCAL int dcIoctl (IDR *ifp, int cmd, caddr_t data); LOCAL int dcChipReset (DRV_CTRL *pDrvCtrl); LOCAL DC_RDE * dcGetFullRMD (DRV_CTRL *pDrvCtrl); LOCAL void dcAuiTpInit (ULONG devAdrs); LOCAL void dcCsrWrite (ULONG devAdrs, int reg, ULONG value); LOCAL ULONG dcCsrRead (ULONG devAdrs, int reg); LOCAL void dcRestart (int unit); LOCAL STATUS dcEnetAddrGet (ULONG devAdrs, char * enetAdrs, int len); LOCAL STATUS dc21140EnetAddrGet (ULONG devAdrs, char * enetAdrs, int len); LOCAL BOOL convertDestAddr (IDR * pIDR, SOCK * pDestSktAddr, char * pDestEnetAddr, u_short * pPacketType, MBUF * pMbuf); LOCAL void dcLoanFree (DRV_CTRL *pDrvCtrl, char *pRxBuf, UINT8 *pRef); LOCAL int dcFltrFrmSetup (DRV_CTRL * pDrvCtrl, char * pPhysAdrsTbl, int tblLen); LOCAL int dcFltrFrmXmit (DRV_CTRL * pDrvCtrl, char * pPhysAdrsTbl, int tblLen); #ifdef DC_DEBUG void dcCsrShow (ULONG devAdrs); #endif /* DC_DEBUG */ /* RCP: Add utilities to read entries in Serial ROM for DEC21140 */ USHORT dcReadRom (ULONG devAdrs, UCHAR lineCnt); int dcViewRom (ULONG devAdrs, UCHAR lineCnt, int cnt); /* RCP: Temporary reference of new global symbol */ LOCAL STATUS sysLanIntEnable (int Level); /* The MII functions were borrowed from the Linux Tulip driver */ /* MII transceiver control section. Read and write the MII registers using software-generated serial MDIO protocol. See the MII specifications or DP83840A data sheet for details. */ /* The maximum data clock rate is 2.5 Mhz. The minimum timing is usually met by back-to-back PCI I/O cycles, but we insert a delay to avoid "overclocking" issues or future 66Mhz PCI. */ #define mdio_delay() sysInLong(mdio_addr) /* Read and write the MII registers using software-generated serial MDIO protocol. It is just different enough from the EEPROM protocol to not share code. The maxium data clock rate is 2.5 Mhz. */ #define MDIO_SHIFT_CLK 0x10000 #define MDIO_DATA_WRITE0 0x00000 #define MDIO_DATA_WRITE1 0x20000 #define MDIO_ENB 0x00000 /* Ignore the 0x02000 databook setting. */ #define MDIO_ENB_IN 0x40000 #define MDIO_DATA_READ 0x80000 static int mdio_read(int ioaddr, int phy_id, int location) { int i; int read_cmd = (0xf6 << 10) | (phy_id << 5) | location; int retval = 0; int mdio_addr = CSR(ioaddr,CSR9); /* Establish sync by sending at least 32 logic ones. */ for (i = 32; i >= 0; --i) { sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1); mdio_delay(); sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1 | MDIO_SHIFT_CLK); mdio_delay(); } /* Shift the read command bits out. */ for (i = 15; i >= 0; --i) { int dataval = (read_cmd & (1 << i)) ? MDIO_DATA_WRITE1 : 0; sysOutLong(mdio_addr,MDIO_ENB | dataval); mdio_delay(); sysOutLong(mdio_addr,MDIO_ENB | dataval | MDIO_SHIFT_CLK); mdio_delay(); } /* Read the two transition, 16 data, and wire-idle bits. */ for (i = 19; i > 0; --i) { sysOutLong(mdio_addr,MDIO_ENB_IN); mdio_delay(); retval = (retval << 1) | ((sysInLong(mdio_addr) & MDIO_DATA_READ) ? 1 : 0); sysOutLong(mdio_addr,MDIO_ENB_IN | MDIO_SHIFT_CLK); mdio_delay(); } return (retval>>1) & 0xffff; } static void mdio_write(int ioaddr, int phy_id, int location, int value) { int i; int cmd = (0x5002 << 16) | (phy_id << 23) | (location<<18) | value; int mdio_addr = CSR(ioaddr,CSR9); /* Establish sync by sending 32 logic ones. */ for (i = 32; i >= 0; i--) { sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1); mdio_delay(); sysOutLong(mdio_addr,MDIO_ENB | MDIO_DATA_WRITE1 | MDIO_SHIFT_CLK); mdio_delay(); } /* Shift the command bits out. */ for (i = 31; i >= 0; i--) { int dataval = (cmd & (1 << i)) ? MDIO_DATA_WRITE1 : 0; sysOutLong(mdio_addr,MDIO_ENB | dataval); mdio_delay(); sysOutLong(mdio_addr,MDIO_ENB | dataval | MDIO_SHIFT_CLK); mdio_delay(); } /* Clear out extra bits. */ for (i = 2; i > 0; i--) { sysOutLong(mdio_addr,MDIO_ENB_IN); mdio_delay(); sysOutLong(mdio_addr,MDIO_ENB_IN | MDIO_SHIFT_CLK); mdio_delay(); } return; } /* End functions borrowed from Linux */ /******************************************************************************* * * dcattach - publish the `dc' network interface. * * This routine publishes the `dc' interface by filling in a network interface * record and adding this record to the system list. This routine also * initializes the driver and the device to the operational state. * * The parameter is used to specify the device unit to initialize. * * The is used to specify the I/O address base of the device. * * The parameter is used to specify the interrupt vector associated * with the device interrupt. * * The parater is used to specify the level of the interrupt which * the device would use. * * The parameter can be used to specify the location of the * memory that will be shared between the driver and the device. The value * NONE is used to indicate that the driver should obtain the memory. * * The parameter is valid only if the parameter is not * set to NONE, in which case indicates the size of the * provided memory region. * * The parameter sets the memory pool's data port width (in bytes); * if it is NONE, any data width is used. * * The parameter defines the main memory base as seen from PCI bus. * * The parameter defines the mode in which the device should be * operational. * * RCP: Added for DEC21140 Serial ROM * * BUGS * To zero out LANCE data structures, this routine uses bzero(), which * ignores the specification and uses any size data access to * write to memory. * * RETURNS: OK or ERROR. */ STATUS dcattach ( int unit, /* unit number */ ULONG devAdrs, /* LANCE I/O address */ int ivec, /* interrupt vector */ int ilevel, /* interrupt level */ char * memAdrs, /* address of memory pool (-1 = malloc it) */ ULONG memSize, /* only used if memory pool is NOT malloc()'d */ int memWidth, /* byte-width of data (-1 = any width) */ ULONG pciMemBase, /* main memory base as seen from PCI bus */ int dcOpMode /* mode of operation */ ) { DRV_CTRL * pDrvCtrl; /* pointer to drvctrl */ unsigned int sz; /* temporary size holder */ char * pShMem; /* start of the LANCE memory pool */ char * buf; /* temp buffer pointer */ void * pTemp; /* temp pointer */ DC_RDE * rmd; /* pointer to rcv descriptor */ DC_TDE * tmd; /* pointer to xmit descriptor */ int ix; /* counter */ /* RCP: Added temporary value */ ULONG uTemp; /* temporary storage */ /* Sanity check the unit number */ if (unit < 0 || unit >= MAX_UNITS) return (ERROR); /* Ensure single invocation per system life */ pDrvCtrl = & drvCtrl [unit]; if (pDrvCtrl->attached) return (OK); pDrvCtrl->ivec = ivec; /* interrupt vector */ pDrvCtrl->ilevel = ilevel; /* interrupt level */ pDrvCtrl->devAdrs = devAdrs; /* LANCE I/O address */ pDrvCtrl->pciMemBase = pciMemBase; /* pci memory base */ pDrvCtrl->memWidth = memWidth; /* memory width */ pDrvCtrl->dcOpMode = dcOpMode; /* mode of operation */ /* Publish the interface data record */ ether_attach ( & pDrvCtrl->idr.ac_if, unit, "dc", (FUNCPTR) NULL, (FUNCPTR) dcIoctl, (FUNCPTR) dcOutput, (FUNCPTR) dcReset ); /* Create the transmit semaphore. */ if ((pDrvCtrl->TxSem = semMCreate (SEM_Q_PRIORITY | SEM_DELETE_SAFE | SEM_INVERSION_SAFE)) == NULL) { printf ("dc: error creating transmitter semaphore\n"); return (ERROR); } /* Establish size of shared memory region we require */ if ((int) memAdrs != NONE) /* specified memory pool */ { sz = (memSize - (RMD_SIZ + TMD_SIZ + (dcLPool * DC_BUFSIZ) + FLTR_FRM_SIZE)) / ((2 * DC_BUFSIZ) + RMD_SIZ + TMD_SIZ); dcNumRds = max (sz, MIN_RDS); dcNumTds = max (sz, MIN_TDS); } /* add it all up - allow for alignment adjustment */ sz = ((dcNumRds + 1) * RMD_SIZ) + (dcNumRds * DC_BUFSIZ) + ((dcNumTds + 1) * TMD_SIZ) + (dcNumTds * DC_BUFSIZ) + (DC_BUFSIZ * dcLPool) + FLTR_FRM_SIZE; /* Establish a region of shared memory */ /* OK. We now know how much shared memory we need. If the caller * provides a specific memory region, we check to see if the provided * region is large enough for our needs. If the caller did not * provide a specific region, then we attempt to allocate the memory * from the system, using the cache aware allocation system call. */ switch ( (int) memAdrs ) { default : /* caller provided memory */ if ( memSize < sz ) /* not enough space */ { printf ( "dc: not enough memory provided\n" ); return ( ERROR ); } pShMem = memAdrs; /* set the beginning of pool */ /* assume pool is cache coherent, copy null structure */ pDrvCtrl->cacheFuncs = cacheNullFuncs; break; case NONE : /* get our own memory */ /* Because the structures that are shared between the device * and the driver may share cache lines, the possibility exists * that the driver could flush a cache line for a structure and * wipe out an asynchronous change by the device to a neighboring * structure. Therefore, this driver cannot operate with memory * that is not write coherent. We check for the availability of * such memory here, and abort if the system did not give us what * we need. */ if (!CACHE_DMA_IS_WRITE_COHERENT ()) { printf ( "dc: device requires cache coherent memory\n" ); return (ERROR); } pShMem = (char *) cacheDmaMalloc ( sz); if ((int)pShMem == NULL) { printf ( "dc: system memory unavailable\n" ); return (ERROR); } /* copy the DMA structure */ pDrvCtrl->cacheFuncs = cacheDmaFuncs; break; } if (intConnect ((VOIDFUNCPTR *)INUM_TO_IVEC(ivec),dcInt,(int)pDrvCtrl) == ERROR) return (ERROR); /* Turkey Carving * -------------- * * LOW MEMORY * |-------------------------------------| * | The Rx descriptors | * | (dcNumRds * sizeof (DC_RDE)) | * |-------------------------------------| * | The receive buffers | * | (DC_BUFSIZ * dcNumRds) | * |-------------------------------------| * | The Rx loaner pool | * | (DC_BUFSIZ * dcLPool) | * |-------------------------------------| * | The Tx descriptors | * | (dcNumTds * sizeof (DC_TDE)) | cont next messg - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: DEC 21140 driver on pc486: some fixes Date: Mon, 14 Dec 1998 18:06:47 GMT From: david.hagood@ifrsys.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <753k3l$aht$1@nnrp1.dejanews.com> References: <366E73A6.32FD2550@sktc.net> /******************************************************************************* * * dcEnetAddrGet - gets the ethernet address from the ROM register. * * This routine gets the ethernet address from the ROM register. * This routine returns the ethernet address into the pointer supplied to it. * * RETURNS: OK/ERROR */ LOCAL STATUS dcEnetAddrGet ( ULONG devAdrs, /* device base I/O address */ char * enetAdrs, /* pointer to the ethernet address */ int len /* number of bytes to read */ ) { FAST ULONG csr9Value; /* register to hold CSR9 */ int ix; /* index register */ BOOL eRomReady = FALSE; /* ethernet ROM register state */ dcCsrWrite (devAdrs, CSR9, 0); /* reset rom pointer */ while (len > 0) { for (ix = 0; ix < 10; ix++) /* try at least 10 times */ { if ((csr9Value = dcCsrRead (devAdrs, CSR9)) & CSR9_DNV) { eRomReady = FALSE; DELAY(500); } else { *enetAdrs++ = (UCHAR) csr9Value; len--; eRomReady = TRUE; break; } } } if (!eRomReady) return (ERROR); else return (OK); } /******************************************************************************* * * RCP : New utility for DEC21140 * dc21140EnetAddrGet - gets the ethernet address from the ROM register * * This routine gets the last two bytes of the ethernet address from the ROM * register and concantenates this value to the predefined values for DEC PMCs.. * This routine returns the ethernet address into the pointer supplied to it. * * The procedure could be expanded in the future to allow for modification of * Ethernet addresses in the serial ROM. It will have to be modified to * accomodate the differences in the onboard 100Mb/s ethernet on future * Motorola products. * * RETURNS: OK/ERROR */ LOCAL STATUS dc21140EnetAddrGet ( ULONG devAdrs, /* device base I/O address */ char * enetAdrs, /* pointer to the ethernet address */ int len /* number of bytes to read */ ) { int i,ix, /* index register */ tmpInt; /* temporary int */ union mixed { char Char[4]; /* temporary 2 by char */ USHORT Short[2]; /* temporary USHORT */ } tmp; for (i = DEC_PMC_POS, ix = 0; i<(3+DEC_PMC_POS); i++, ix++) { if ((tmp.Short[0] = dcReadRom (devAdrs, i)) == (USHORT)ERROR) return (ERROR); #if (_BYTE_ORDER == _BIG_ENDIAN) enetAdrs[ix++] = tmp.Char[1]; enetAdrs[ix] = tmp.Char[0]; #else enetAdrs[ix++] = tmp.Char[0]; enetAdrs[ix] = tmp.Char[1]; #endif } tmpInt = -1; return (OK); } /******************************************************************************* * * dcFltrFrmXmit - Transmit the setup filter frame. * * This routine transmits the setup filter frame. * The setup frame is not transmitted actually over the wire. The setup frame * which is transmitted is 192 bytes. The tranmitter should be in an on state * before this function is called. This call has been coded so that the * setup frame can be transmitted after the chip is done with the * intialization taking into consideration for adding multicast support. * * RETURNS: OK/ERROR */ LOCAL int dcFltrFrmXmit ( DRV_CTRL * pDrvCtrl, /* pointer to device control structure */ char * pPhysAdrsTbl, /* pointer to physical address table */ int tblLen /* size of the physical address table */ ) { volatile DC_TDE * tmd; /* pointer to Tx ring descriptor */ ULONG * pBuff; /* pointer to the Xmit buffer */ int status = OK; /* intialize status as OK */ ULONG csr7Val; /* value in CSR7 */ semTake (pDrvCtrl->TxSem, WAIT_FOREVER); if (dcFltrFrmSetup (pDrvCtrl, pPhysAdrsTbl, tblLen) != OK) { status = ERROR; /* not able to set up filter frame */ goto setupDone; /* set up done */ } /* See if next TXD is available */ tmd = pDrvCtrl->txRing + pDrvCtrl->txIndex; DC_CACHE_INVALIDATE (tmd, TMD_SIZ); if ( ((tmd->tDesc0 & PCISWAP(TDESC0_OWN)) != 0) || ( ((pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds) == pDrvCtrl->txDiIndex ) ) { status = ERROR; /* not able to set up filter frame */ goto setupDone; /* set up done */ } /* Get pointer to transmit buffer */ pBuff = DC_CACHE_PHYS_TO_VIRT(PCI_TO_MEM_PHYS(PCISWAP(tmd->tDesc2))); /* copy into Xmit buffer */ bcopyLongs ((char *)pDrvCtrl->pFltrFrm, (char *)pBuff, FLTR_FRM_SIZE_ULONGS); tmd->tDesc0 = 0; /* clear buffer error status */ tmd->tDesc1 |= PCISWAP(TDESC1_SET); /* frame type as set up */ tmd->tDesc1 &= PCISWAP(~TDESC1_TBS1_MSK); tmd->tDesc1 |= PCISWAP(TDESC1_TBS1_PUT(FLTR_FRM_SIZE)); tmd->tDesc0 = PCISWAP(TDESC0_OWN); /* give ownership to device */ CACHE_PIPE_FLUSH (); /* Flush the write pipe */ /* Advance our management index */ pDrvCtrl->txIndex = (pDrvCtrl->txIndex + 1) % pDrvCtrl->dcNumTds; pDrvCtrl->txDiIndex = (pDrvCtrl->txDiIndex + 1) % pDrvCtrl->dcNumTds; csr7Val = dcCsrRead (pDrvCtrl->devAdrs, CSR7); dcCsrWrite(pDrvCtrl->devAdrs, CSR7, 0); /* mask interrupts */ if (dcKickStartTx) { dcCsrWrite(pDrvCtrl->devAdrs, CSR1, CSR1_TPD); /* xmit poll demand */ } /* wait for the own bit to change */ while (tmd->tDesc0 & PCISWAP (TDESC0_OWN)) { } tmd->tDesc0 = 0; /* clear status bits */ tmd->tDesc1 &= PCISWAP(~TDESC1_SET); dcCsrWrite(pDrvCtrl->devAdrs, CSR7, csr7Val); /* restore value */ setupDone: /* Release exclusive access. */ semGive (pDrvCtrl->TxSem); return (status); } /******************************************************************************* * * dcFltrFrmSetup - set up the filter frame. * * This routine sets up the filter frame to filter the physical addresses * on the incoming frames. The setup filter frame buffer is 192 bytes. This * setup frame needs to be transmitted before transmitting and receiving * any frames. * * RETURNS: OK/ERROR */ LOCAL int dcFltrFrmSetup ( DRV_CTRL * pDrvCtrl, /* pointer to device control structure */ char * pPhysAdrsTbl, /* pointer to physical address table */ int tblLen /* size of the physical address table */ ) { int ix; /* index variable */ int jx; /* inner index variable */ ULONG * pFltrFrm; /* pointer to the filter frame */ USHORT * pPhysAddrs; /* pointer to the physical addresses */ if (tblLen > FLTR_FRM_ADRS_NUM) return (ERROR); pFltrFrm = pDrvCtrl->pFltrFrm; for (ix = 0; ix < FLTR_FRM_SIZE_ULONGS; ix++) *pFltrFrm++ = FLTR_FRM_DEF_ADRS; pFltrFrm = pDrvCtrl->pFltrFrm; pPhysAddrs = (USHORT *) (pPhysAdrsTbl); for (ix = 0; ix < tblLen; ix++) { for (jx = 0; jx < (FLTR_FRM_ADRS_SIZE/sizeof (USHORT)); jx++) { #if (_BYTE_ORDER == _BIG_ENDIAN) *pFltrFrm = (*pPhysAddrs << 16); #else *pFltrFrm = *pPhysAddrs; #endif pPhysAddrs++; pFltrFrm++; } } return (OK); } #include "sys/socket.h" /******************************************************************************* * * convertDestAddr - converts socket addr into enet addr and packet type * */ LOCAL BOOL convertDestAddr ( IDR *pIDR, /* ptr to i/f data record */ SOCK *pDestSktAddr, /* ptr to a generic sock addr */ char *pDestEnetAddr, /* where to write enet addr */ u_short *pPacketType, /* where to write packet type */ MBUF *pMbuf /* ptr to mbuf data */ ) { /***** Internet family *****/ { struct in_addr destIPAddr; /* not used */ int trailers; /* not supported */ if (pDestSktAddr->sa_family == AF_INET) { *pPacketType = ETHERTYPE_IP; /* stuff packet type */ destIPAddr = ((struct sockaddr_in *) pDestSktAddr)->sin_addr; if (!arpresolve (pIDR, pMbuf, &destIPAddr, pDestEnetAddr, &trailers)) return (FALSE); /* if not yet resolved */ return (TRUE); } } /***** Generic family *****/ { ENET_HDR *pEnetHdr; if (pDestSktAddr->sa_family == AF_UNSPEC) { pEnetHdr = (ENET_HDR *) pDestSktAddr->sa_data; /* ptr to hdr */ bcopy (pEnetHdr->dst, pDestEnetAddr, 6); /* copy dst addr */ *pPacketType = pEnetHdr->type; /* copy type */ return (TRUE); } } /* Unsupported family */ return (FALSE); } /* End of convertDestAddr() */ /* END OF FILE */ /******************************************************************************* * * RCP : New utility for DEC21140 * dcReadRom - reads an specified entry in the Serial ROM * * This routine uses the line number passed to the function and returns * the two bytes of information that is associated with it. This will later * be used by the dc21140GetEthernetAdr function. It can also be used to * review the ROM contents itself. * * The function must first send some initial bit paterns to the CSR9 which * contains the Serial ROM Control bits. Then the line index into the ROM * will be evaluated bit by bit to program the ROM. The 2 bytes of data * will be extracted and processed into a normal pair of bytes. * * RETURNS: Short Value in ROM/ERROR */ #define BASE CSR9_SSR_FLAG|CSR9_SWO_FLAG USHORT dcReadRom ( ULONG devAdrs, /* device base I/O address */ UCHAR lineCnt /* Serial ROM line Number */ ) { int ix, /* index register */ intCnt; /* address loop count */ USHORT tmpShort; ULONG tmpLong; /* Is the line offset valid, and if so, how large is it */ if (lineCnt > SROM_SIZE) { printf ("dcReadRom FAILED, bad lineCnt\n"); return (ERROR); } if (lineCnt < 64) { intCnt = 6; lineCnt = lineCnt << 2; /* Prepare lineCnt for processing */ } else intCnt = 8; /* Command the Serial ROM to the correct Line */ /* Preamble of Command */ dcCsrWrite (devAdrs, CSR9, 0x00000000|BASE); /* Command 1 */ NSDELAY (30); dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE); /* Command 2 */ NSDELAY (50); dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE); /* Command 3 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE); /* Command 4 */ NSDELAY (100); /* Command Phase */ dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE); /* Command 5 */ NSDELAY (150); dcCsrWrite (devAdrs, CSR9, 0x00000007|BASE); /* Command 6 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE); /* Command 7 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, 0x00000007|BASE); /* Command 8 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, 0x00000005|BASE); /* Command 9 */ NSDELAY (100); dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE); /* Command 10 */ NSDELAY (150); dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE); /* Command 11 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, 0x00000001|BASE); /* Command 12 */ NSDELAY (100); /* Address Phase */ for (ix=0; ix < intCnt; ix++) { tmpLong = (lineCnt & 0x80)>>5; /* Extract and move bit to bit 3) */ /* Write the command */ dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000001|BASE);/* Command 13 */ NSDELAY (150); dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000003|BASE);/* Command 14 */ NSDELAY (250); dcCsrWrite (devAdrs, CSR9, tmpLong | 0x00000001|BASE);/* Command 15 */ NSDELAY (100); lineCnt = lineCnt<<1; /* Adjust significant address bit */ } NSDELAY (150); /* Data Phase */ tmpShort =0; for (ix=15; ix >= 0; ix--) { /* Write the command */ dcCsrWrite (devAdrs, CSR9, 0x00000003|BASE); /* Command 16 */ NSDELAY (100); /* Extract the data */ tmpShort |= (((dcCsrRead (devAdrs, CSR9) & 0x00000008)>>3) < SROM_SIZE) return (ERROR); total = 0; while (lineCnt/2 < SROM_SIZE && cnt > 0) { if (!(total%16)) printf ("\nValues for line %2d =>0x ", total); tmp.Short = dcReadRom (devAdrs, lineCnt); printf ("%4x ",tmp.Short); lineCnt++ ; total +=2; cnt -=2; } printf ("\n"); return (total); } void dcCsrShow ( ULONG devAdrs ) { printf ("\n"); printf ("CSR0\t 0x%x\n", dcCsrRead(devAdrs, CSR0)); printf ("CSR1\t 0x%x\n", dcCsrRead(devAdrs, CSR1)); printf ("CSR2\t 0x%x\n", dcCsrRead(devAdrs, CSR2)); printf ("CSR3\t 0x%x\n", dcCsrRead(devAdrs, CSR3)); printf ("CSR4\t 0x%x\n", dcCsrRead(devAdrs, CSR4)); printf ("CSR5\t 0x%x\n", dcCsrRead(devAdrs, CSR5)); printf ("CSR6\t 0x%x\n", dcCsrRead(devAdrs, CSR6)); printf ("CSR7\t 0x%x\n", dcCsrRead(devAdrs, CSR7)); printf ("CSR8\t 0x%x\n", dcCsrRead(devAdrs, CSR8)); printf ("CSR9\t 0x%x\n", dcCsrRead(devAdrs, CSR9)); printf ("CSR10\t 0x%x\n", dcCsrRead(devAdrs, CSR10)); printf ("CSR11\t 0x%x\n", dcCsrRead(devAdrs, CSR11)); printf ("CSR12\t 0x%x\n", dcCsrRead(devAdrs, CSR12)); printf ("CSR13\t 0x%x\n", dcCsrRead(devAdrs, CSR13)); printf ("CSR14\t 0x%x\n", dcCsrRead(devAdrs, CSR14)); printf ("CSR15\t 0x%x\n", dcCsrRead(devAdrs, CSR15)); } #endif /* DC_DEBUG */ /* RCP: New Versions of code that will be added to the BSP later. */ /**************************************************************************** ** * * sysLanIntEnable - enable the LAN interrupt * * This routine enables interrupts at a specified level for the on-board * LAN chip. LAN interrupts are controlled by the IBC chip. * The LANCE chip on this board is on the PCI bus. The PCI interrupts should * be routed through the IBC to the processor. LANCE chip asserts PCI IRQ0 * which has to be routed through IBC to generate ISA IRQ10. This routing * done through programming the PCI route registers in the IBC chip. * * RETURNS: OK, always. * * SEE ALSO: sysLanIntDisable() */ STATUS sysLanIntEnable ( int intLevel /* interrupt level to enable */ ) { sysIntEnablePIC (intLevel); return (OK); } - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.arch.embedded,comp.os.vxworks,comp.sys.m68k,comp.sys.powerpc.tech Subject: Re: MPC860 chip select & cache problems Date: Tue, 15 Dec 1998 11:37:26 +1100 From: Tom Evans Organization: OzEmail Ltd. Message-ID: <3675AB2C.54F6@nowhere.tennyson.com.au> References: <01be1f17$2c190a60$a1b975c0@euronet.euronet> <36680FE4.CB0BAC46@lucent.com> <74hppu$afb@hoax.cse.tek.com> <753et4$7c0$1@nntp3.uunet.ca> mdapoz@cambriansys.com wrote: > Both data and instruction caches are broken in Rev B parts. Besides > the Motorola documented cache problems, there is a new problem with > the instruction cache. It appears that if the instruction cache is > enabled and an exception occurs (eg. the decrementer goes off) during > branch prediction, occasionaly the instructions are not restarted properly. > The problem only occurs in Rev B parts and appears to be fixed in Rev C. > Below is a test case that I've come up with which demonstrates the problem. > I'll be submitting this to Motorola once I figure out where to send it. http://www.mot-sps.com/sps/General/feedback.html Don't paste too much into the "Message or Question" box. I've had trouble with these systems before (Scientific American blows up at about 500 bytes). You'll get an "Issue Reference Number", which you have to use in subsequent correspondence. Let us know what happens. Tom Evans initialSurname@somewhere --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Looking for 860SAR ATM driver for VxWorks ?? Date: Mon, 14 Dec 1998 22:14:49 GMT From: newsmine@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <7542km$o27$1@nnrp1.dejanews.com> References: <36751F02.B7B97050@cselt.it> Hi Achille, There are a few companies in North America that I have come across that specifically work in this area: 1.Inverness : http://www.invernessinc.com 2.Trillium : http://www.trillium.com 3.Harris & Jeffries : http://www.hjinc.com There are also the traditional networking equipment companies that deal with end-to-end ATm systems : cisco, newbridge, nortel and lucent to name a few. In Germany, you may want to try Cellware at (I think) www.cellware.de. Mittal In article <36751F02.B7B97050@cselt.it>, Achille Montanaro wrote: > Hi, > I'm going to use the PowerPC860SAR which includes an ATM controller with > UTOPIA interface. > I'm looking for VxWorks drivers which support Lan Emulation and/or > Classical IP Over ATM. > Could anyone give me information about where I can find those drivers ? > Thanks in advance > > - -- Mittal Monani Spacebridge Networks Corporation Hull J8X 3R1 - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: large files and rawFs ? Date: 14 Dec 1998 14:39:31 -0800 From: nigel@idiom.com (Nigel Standing) Organization: Idiom Message-ID: <754433$2ud$1@idiom.com> Have a project which is currently using rawFs to access disk data which is less than LONG_MAX in size, but there is a new requirement to modify the system to handle data greater than LONG_MAX in size (well large disks are cheap these days :-) My question, has anyone attempted this ? My initial idea was just to use multiple seeks to overcome the limitation of the "long offset". But then realized that if rawFs doesn't keep track of byte positions greater than LONG_MAX, then it wouldn't work. Thanks for any help, Nigel - --------------------------- Newsgroups: comp.os.vxworks Subject: Strange behaviour with global variable : have you seen it before? Date: Mon, 14 Dec 1998 22:36:22 GMT From: newsmine@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <7543t6$p8p$1@nnrp1.dejanews.com> Hi VxGurus, While doing some simple timer-driven code on VxWorks, I saw the following strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1, gcc 2.7.2 and a PPC860 board. My compilation flags are - -BC:\Tornado/host/x86-win32/lib/gcc-lib/ - -mcpu=860 - -ansi - -nostdinc - -O2 - -fvolatile - -f no-builtin - -fno-for-scope - -Wall - -I/h -IC:\Tornado/host/include -IC:\Tornado\target\config\all -IC: \Tornado\target/h -IC:\Tornado\target/src/config -IC:\Tornado\target/src/drv - -DCPU=PPC860 A global variable called count that is increased each time a timer interrupted function is run. However, this changed value is not always reflected in other functions. Here are the three scenarios int Count; void RxFunc (char * SomePtr) { /* This function is connected to an external timer and runs every 0.5 second Count is increrased each time */ logMsg ("Mittal After msg rx count %d message %s\n", Count++, (int)SomePtr,0,0,0,0); } I tried each of the following functions with RxFunc one at a time. Ran them from the shell as ->sp TaskInit Flavor 1 ~~~~~~~~ void TaskInit () { while (Count < 5 ); printf ("After while loop\n"); <----- I never reach this line. Count keeps increasing beyond 5. } Flavor 2 ~~~~~~~~ void TaskInit () { while (Count < 5 ) { if (Count >=5) break; } printf ("After while loop\n"); <----- I still never reach this line. Count still keeps going up. } Flavor 3 ~~~~~~~~ void TaskInit () { while (Count < 5 ) { logmsg ("Inside while : count %d\n", Count,0,0,0,0,0); } printf ("After while loop\n"); <----- Now I reach here!!. } I am really confused by this strange behaviour. Am I doing somethin wrong or is this a bug in gcc or VxWorks? Is there some wierd compiler optimization going on here? I'll really appreciate your experience on anything like this. Thanks, Mittal - -- Mittal Monani Spacebridge Networks Corporation Hull J8X 3R1 - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Wed, 16 Dec 1998 18:01:04 -0800 From: Matthew Downs Organization: Another Netscape Collabra Server User Message-ID: <367865E0.34EB0D02@ada.com> References: <36784811.108860281@news.phoenix.net> Peter Weatherall wrote: > Has anyone integrated Tornado with a source code version control > system ? Some IDEs have this built-in. Any ideas about what is the > best approach with Tornado... > > Thanks > Peter I 've done it, but you don't want to......Unfiortunately, the concept of source control is a foreign idea to those that make the product. Actually, I shouldn't say that, but it seems like it is true. My main suggestion is to put the entire tree under control and replicate it where necessary. DON'T use PVCS, if you are, I'm sorry. Matt --------------------------- Newsgroups: comp.os.vxworks Subject: PERL on VxWorks? Date: Thu, 17 Dec 1998 14:16:29 +1100 From: "Breck Thomas" Organization: OzEmail Ltd. Message-ID: <759son$vd6$1@reader1.reader.news.ozemail.net> Hi, Does anyone know if PERL 5 will run on VxWorks. I have contacted Wind River and had no response yet. Please send replies to breck@posnet.com.au Thanks in advance - -- Breck --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Build Output Requires Prompting? Date: Wed, 16 Dec 1998 21:06:53 -0700 From: Michael Oehrli Organization: Raytheon Optical Systems, Inc. Message-ID: <3678835D.A33C412@usa.net> References: <36704BD9.E91CCF8D@americasm01.nt.com> Tim Sohacki wrote: > We recently installed Tornado 1.0.1 on a particular Win 95 PC. > > If I try to build the BSP with: > Project->Make MV1603->Common Targets->vxWorks > > something very odd occurs ... a build output window appears, > but it has no output. Pressing a key on the keyboard results > in the first command (say ccppc) executing. Each command > must be prompted in a similar manner. > > The same thing occurs if you use a default generated > Wind River Makefile on your own "Hello world!" program, > or one of our application programs. > > However, the demo builds without prompting using the Makefile at: > $WIND_BASE/target/src/demo/color/Makefile ... > > Any suggestions? Has anyone encountered anything like this? > All other PC installations work okay (though not as well as > our Unix installations). > > Cheers, > Tim > > -- > Tim Sohacki, Nortel Networks > email: sohacki@nortelnetworks.com I recently installed VxWorks on a Win95 machine. However, the first thing I did was "Configured BSP." I believe it's a selection under one of the menus. You are then thrown into WindConfig which lets you select the various components to add or you can just select the defaults. Then you must save the configuration and afterwards build it. - -- Michael Oehrli Senior Software Engineer Raytheon Optical Systems, Inc. http://wwp.mirabilis.com/10888574 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Strange behaviour with global variable : have you seen it before? Date: Tue, 15 Dec 1998 05:49:42 GMT From: john@kivala.com Organization: Kivala Systems, Inc. Message-ID: <754t9l$ejc$1@nnrp1.dejanews.com> References: <7543t6$p8p$1@nnrp1.dejanews.com> In article <7543t6$p8p$1@nnrp1.dejanews.com>, newsmine@my-dejanews.com wrote: > Hi VxGurus, > > While doing some simple timer-driven code on VxWorks, I saw the following > strange behaviour. Here's what I have : Tornado on Nt 4.0, VxWorks 5.3.1, > gcc 2.7.2 and a PPC860 board. My compilation flags are ...edit > int Count; ... My guess is that "int Count" wants to be "volatile int Count". The compiler might be sticking it in a register and never re-getting it from memory, unless you have a "sufficiently complicated" line of code between uses of Count (case 3). This is not too hard to check: objdumpppc --disassemble file.o > file.lst (A reading knowledge of any given assembly language is far easier than a writing knowledge thereof.) If this is what's happening, and maybe even if it's not, the lesson is that if you have any variables shared by more than one task (or isr), then they should be volatile, since you don't (in general) know when task A is going to switch out and task B is going to switch in. This is a different kind of protection than that achieved by intLock, taskLock, or a semaphore. John - -------------------------------------------------- John Finley Kivala Systems, Inc. Project Manager (619) 689-0032 john@kivala.com http://www.kivala.com - -------------------------------------------------- VxTool - Build Tornado Apps with MS Visual Basic - -------------------------------------------------- - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: BOOTP / RARP server Date: Thu, 17 Dec 1998 10:16:54 -0000 From: "Facilities Rolls-Royce" Organization: UUNET WorldCom server (post doesn't reflect views of UUNET WorldCom) Message-ID: <75almq$o2i$1@plug.news.pipex.net> Does anyone have any experience of running either a BOOTP server or a RARP (Reverse Address Resolution Protocol) server under VxWorks? I require it for a pressure measurement system utilising PSI 9016 pressure "bricks". The Tornado distribution includes an unsupported CMU bootp server, intended for the Unix host. Is this a good starting point, or is there somewhere better to start from. Paul Tyler Measurement Systems Specialist Rolls-Royce E&MT Department Automation Team --------------------------- Newsgroups: comp.os.vxworks Subject: Re: DMA on MVME2600 Date: 17 Dec 1998 11:13:39 GMT From: ag@devsoft.devsoft.com (Armin Gruner) Organization: Customer of SpaceNet GmbH Message-ID: References: In article , Philippe Duhoux wrote: >Bonjour, >does someone have experience in DMA transfers on >MVME2600? >In my particalar case, I shall transfer CPU data >from/to an external VME board in A32/D32 space. > >Thanks for any hint. > >Best regards, >Philippe > >================================================================ >Philippe Duhoux Tel: (+49) >89-3200-6523 >Software Engineer VLT Fax: (+49) >89-3200-6494 >CCD Cameras & Instrument Motors >Karl-Schwarzschild-Str.2 >European Southern Observatory D-85748 Munich >- Germany >E-Mail : pduhoux@eso.org WWW >http://www.eso.org >================================================================ Hi, we were in the need for the same thing. I have added a DMA driver for the Universe chip, though we are using a MVME2700 board. But I think that makes no difference. If you're interested in the source code, get back to me. Regards Armin - -- Armin Gruner Forschung und Entwicklung - -- Armin Gruner, /dev Software GmbH Fon +49-89-286 598 43 Gabelsberger Str. 51 mailto:ag@devsoft.com D-80333 Muenchen http://www.devsoft.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: DMA on MVME2600 Date: 17 Dec 1998 11:15:52 GMT From: ag@devsoft.devsoft.com (Armin Gruner) Organization: Customer of SpaceNet GmbH Message-ID: References: In article , Philippe Duhoux wrote: >Bonjour, >does someone have experience in DMA transfers on >MVME2600? >In my particalar case, I shall transfer CPU data >from/to an external VME board in A32/D32 space. > >Thanks for any hint. > >Best regards, >Philippe > >================================================================ >Philippe Duhoux Tel: (+49) >89-3200-6523 >Software Engineer VLT Fax: (+49) >89-3200-6494 >CCD Cameras & Instrument Motors >Karl-Schwarzschild-Str.2 >European Southern Observatory D-85748 Munich >- Germany >E-Mail : pduhoux@eso.org WWW >http://www.eso.org >================================================================ Hi, we were in the need for the same thing. I have added a DMA driver for the Universe chip, though we are using a MVME2700 board. But I think that makes no difference. If you're interested in the source code, get back to me. Regards Armin - -- Armin Gruner Forschung und Entwicklung - -- Armin Gruner, /dev Software GmbH Fon +49-89-286 598 43 Gabelsberger Str. 51 mailto:ag@devsoft.com D-80333 Muenchen http://www.devsoft.com --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Thu Dec 17 07:46:19 1998 From: Charlie Grames Date: Thu Dec 17 07:46:22 PST 1998 Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply Carl, Minbo, and whoever else is interested, This is a tangent to the original question, but the d() command does not necessarily _access_ memory the way you request it to _display_ it. When I use d() with default nunits and width parameters to look at memory on the VMEbus with an MVME2700, I see a single-byte access at the beginning and end of each 16-byte segment (this is vxMemProbe() making sure the memory is present) followed by four 32-bit accesses. Memory is displayed in 16-bit units, however, followed by its ASCII representation. I guess the point is this: If you are not looking at well-behaved memory, you can't count on d() to access it properly. Use a shell construct such as the following, instead: val = (char)*0xffbf6005 By the way: You need to be careful with the m() command, too, because it reads the memory to display the current content before you write to it. If you try to modify a memory location for which an action is performed if it is read, you will get an unexpected side effect. I would recommend this shell construct, instead: *0xffbf6005 = (char)val Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/16/98 06:13pm >>> Submitted-by owner-vxwexplo-process Wed Dec 16 16:13:11 1998 Submitted-by: "Carl C. Chesbrough" Minbo, You can use the m() function, giving it a parameter of 1 to do 8-bit access rather than 16-bit accesses. I thought that the default d() access was 16-bits. You can specify the size with the 3rd parameter to the d() function. -> m 0xfbff6005,1 or -> d 0xfbff6005, 1, 1 ^ ^ # of bytes ----| | access size ------| HTH, -Carl. ******************************************************************** * * * Carl C. Chesbrough Telephone: (510) 252-0870 x 126 * * Themis Computer Facsimile: (510) 490-5529 * * 3185 Laurelview Court E-Mail : carl@themis.com * * Fremont, California 94538 * * * ******************************************************************** > The addressing looks fine. How are you doing your accesses? The 6005 > address suggests that you are addressing by byte. If so, your code should > be doing something equivalent to: > > someCharVar = *(char *)0xfbff6005; > > (though hopefully more elegantly). In particular, the d() funciton is > probably not useful, because it reads from memory 32 bits at a time. If > your board does not respond to D32 bus cycles, you get bus errors and > useless data. > > HTH > > Charlie Grames > The Boeing Company > (314) 233-1956 > Charles.R.Grames@boeing.com > > >>> the vxWorks Users Group Exploder 12/16/98 12:57pm >>> > Submitted-by owner-vxwexplo-process Wed Dec 16 10:56:55 1998 > Submitted-by: "Minbo Shim" > > Vxworks gurus: > > I have some difficulties to get access to a register in the A16-based > I/O board. > > Here is the story. We have an A16-based VMEbus I/O board with short > addressing map that tells us where to go to see the contents of some > registers in it. Suppose the local address to one of the registers is > 0x6005. We are using MVME2700 boards. "mv2600.h" is telling me that > VME MASTER WINDOW for A16 SPACE is following: > > /* > * Map access to A16 VMEbus - 64K : MAP FOR EXTENDED VME vxWorks > * This maps: MPU RANGE: 0xfbff0000 - 0xfbffffff > * to: PCI RANGE: 0xfbff0000 - 0xfbffffff > * to: VME RANGE: 0xfbff0000 - 0xfbffffff > */ > # define VME_A16_MSTR_LOCAL 0xfbff0000 > # define VME_A16_MSTR_SIZE 0x00010000 /* 64K */ > # define VAL_LSI3_BS_VALUE (VME_A16_MSTR_LOCAL) > > I believe the "sysPhysmemDesc" structure in "sysLib.c" uses this value: > > { > (void *) VME_A16_MSTR_LOCAL, > (void *) VME_A16_MSTR_LOCAL, > VME_A16_MSTR_SIZE, > VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, > VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT > }, > > However, every try to get access to "0xfbff6005" has been failed in the > sense > that the contents are NOT what we expect. > > Does anybody know what I am missing? > > Your help would be greatly appreciated. > > > ------------------------- > MINBO SHIM; mshim@rst.com > Voice: (410) 876-9200 (#189), Fax: (410) 876-9470 > ROBOTIC SYSTEMS TECHNOLOGY > 1234 Tech Court, Westminster, MD 21157 From owner-vxwexplo-process Thu Dec 17 15:05:17 1998 From: "John L Hagen" Date: Thu Dec 17 15:05:21 PST 1998 Subject: Multiple ethernet port - routing troubles. Hi All, vxWorks / powerPC First off, sorry for the extreme length of this note. I'm having trouble understanding how the routing tables are used in vxWorks. My network background is very limited and I'm hoping someone can point out the obvious things I'm missing and provide any pointers. We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143). In this example the [ifShow "dc"] command shows that 4 ports are attached. The [routeAdd] and [routeShow] commands give the following tables... ROUTE NET TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 131.198.68.0 131.198.68.249 3 1 206 dc0 131.198.68.0 131.198.68.202 1 0 0 dc0 131.198.69.0 131.198.69.63 1 0 0 dc12 131.198.69.0 131.198.69.62 1 0 0 dc11 131.198.69.0 131.198.69.61 1 0 0 dc10 131.198.69.0 131.198.69.60 1 0 0 dc9 ------------------------------------------------------------------------ ROUTE HOST TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 127.0.0.1 127.0.0.1 5 1 11 lo0 131.198.69.44 131.198.69.60 5 0 0 dc9 ------------------------------------------------------------------------ The dc0 interface is used to boot the os image from our company network. Subnet 69 is just one I made up - but the addresses are unique and not registered with the company network. At this point I can delete/add [routeAdd..] single routing paths using dc9 or 10 or 11 etc... I can ping to and from the powerpc ports individualy from another computer(dolch3/4) on the subnet 69. I can repeat this with some consistency with any one of my added interfaces. e.g. dolch4 is alive PING dolch4 (131.198.69.44): 56 data bytes 64 bytes from dolch4 (131.198.69.44): icmp_seq=0. time=960. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=1. time=0. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=2. time=1488. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=3. time=528. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=4. time=368. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=5. time=1152. ms 64 bytes from dolch4 (131.198.69.44): icmp_seq=6. time=192. ms ----dolch4 PING Statistics----12 packets transmitted, 7 packets received, 41% packet lossround-trip (ms) min/avg/max = 0/669/1488 Given, the packet loss is terrible! The problem I don't understand is when I add a second route using a different interface on the powerpc things don't go as I expect them. I'm expecting to be able to ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10. Is this correct??? ROUTE NET TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 131.198.68.0 131.198.68.249 3 1 224 dc0 131.198.68.0 131.198.68.202 1 0 0 dc0 131.198.69.0 131.198.69.63 1 0 0 dc12 131.198.69.0 131.198.69.62 1 0 0 dc11 131.198.69.0 131.198.69.61 1 0 0 dc10 131.198.69.0 131.198.69.60 1 0 0 dc9 ------------------------------------------------------------------------ ROUTE HOST TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 127.0.0.1 127.0.0.1 5 1 15 lo0 131.198.69.44 131.198.69.60 5 0 16 dc9 131.198.69.48 131.198.69.61 5 0 0 dc10 ------------------------------------------------------------------------ When I try a single ping over the second route the system gets crazy and the tornado tools wonder off to ???. e.g. a reboot is needed. ping "dolch3",1,0 can't read "event": no such variable value = -1 = 0xffffffff -> Error while polling for events: WTX Error 0x10197 (EXCHANGE_TIMEOUT) -> Error while polling for events: WTX Error 0x10197 (EXCHANGE_TIMEOUT) etc... This happens if I repeat the process and try to ping over the first dc9 route after just adding the second dc10 route. I can see from our ethernet analyzer that the ping command actually results in ARPs going out and responses are generated by the second computer. But vxWorks now seems to be lost and the tools are no longer communicating with the target and I have to reboot the system. I know it's not that tuff - It just hasn't dawned on me what I'm doing wrong. Any help is appreciated. John Hagen Rockwell Collins jlhagen@cacd.rockwell.com From owner-vxwexplo-process Thu Dec 17 15:28:40 1998 From: "TEM Koshimizu, Kazu" Date: Thu Dec 17 15:28:43 PST 1998 Subject: vxworks binary semaphore This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BE2A14.80C58676 Content-Type: text/plain Hello, Does anyone know the way to find out the task did the last semTake() for specific b-sem ? Thanks in advance. KazuKoshimizu / TokyoElectron ------_=_NextPart_001_01BE2A14.80C58676 Content-Type: text/html vxworks binary semaphore

Hello,

Does anyone know the way to find out the task did the last semTake() for specific b-sem ?

Thanks in advance.
KazuKoshimizu / TokyoElectron

------_=_NextPart_001_01BE2A14.80C58676-- From owner-vxwexplo-process Thu Dec 17 18:23:16 1998 From: Fred Roeber Date: Thu Dec 17 18:23:20 PST 1998 Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply On Thu, 17 Dec 1998, Carl C. Chesbrough answered a question about A16 access: > You can use the m() function, giving it a parameter of 1 to do 8-bit > access rather than 16-bit accesses. I thought that the default d() > access was 16-bits. You can specify the size with the 3rd parameter > to the d() function. I never realized that the "d" command supported the same width argument that the "m" command did. If anyone is interested in how these commands work, they are delivered in source form with VxWorks. Just look in the file src/usr/usrLib.c. Default command uses 16 bit accesses the way Carl thought (at least in my VxWorks 5.3 copy of the code). Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | | TraceMaker product manager -> www.tracemaker.bbn.com | From owner-vxwexplo-process Thu Dec 17 21:50:43 1998 From: "Keith Buchanan" Date: Thu Dec 17 21:50:46 PST 1998 Subject: RE: Multiple ethernet port - routing troubles. > Is this correct??? > > ROUTE NET TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 131.198.68.0 131.198.68.249 3 1 224 dc0 > 131.198.68.0 131.198.68.202 1 0 0 dc0 > 131.198.69.0 131.198.69.63 1 0 0 dc12 > 131.198.69.0 131.198.69.62 1 0 0 dc11 > 131.198.69.0 131.198.69.61 1 0 0 dc10 > 131.198.69.0 131.198.69.60 1 0 0 dc9 > ------------------------------------------------------------------------ > ROUTE HOST TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 127.0.0.1 127.0.0.1 5 1 15 lo0 > 131.198.69.44 131.198.69.60 5 0 16 dc9 > 131.198.69.48 131.198.69.61 5 0 0 dc10 > ------------------------------------------------------------------------ You have multiple net routes to the 69 net which should work (though they don't make much sense) but there is no guarantee which path the data will take. Since there is only physical port on the 68 net, there should only be one route. Are you trying to setup 2 logical addresses for dc0? I think (anyone know for sure?) the SENS stack will do that but not the normal stack that comes with Tornado. The point to point routes on the 69 net conflict with the net routes on the 69 net. You shouldn't do this unless the POINTOPOINT flag is set for the interface. Try this... If you are trying to set up multiple point to point connections with each physical port, put them on seperate nets. A true point-to-point route requires that the Ethernet driver support the ioctls that setup point-to-point operation. Often times, ethernet drivers (other than PPP and SLIP) do not include this capability because it is strictly unnecessary for devices that can broadcast. Eliminate one of the 68 net routes unless you have the SENS stack and are using multiple logical IP addresses on dc0. HTH ---------------------------------- /\\ Thomas Keith Buchanan ///\\ /////\\ SPARTA, Inc. ///// \\ 519 Interstate 30 / \\\\\ \\ Suite 140 \ \\\\\ // Rockwall, TX 75087 \ ////// \////// Voice: 972 672 9657 \//// FAX: 972 722 1216 \// WWW: www.sparta.com From owner-vxwexplo-process Fri Dec 18 01:39:29 1998 From: David Laight Date: Fri Dec 18 01:39:33 PST 1998 Subject: Re: Multiple ethernet port - routing troubles. You need to read up on IP routing. In practise you need to: 1) Put each interface on a system into a DIFFERENT subnet 2) Connect each interface to a diferent physical LAN 3) Only have one system/router linking any two subnets A problem because I don't believe you can disable IP-Forwarding in vxWorks. If you don't do the above packets will not go out the expected interfaces. Another possible area of confusion is that the typical Unix 'ping' does an address to name lookup on every returned packet. Misconinfigured DNS and the broken resolv code can cause this to take a long time. David > Hi All, > > vxWorks / powerPC > First off, sorry for the extreme length of this note. > > I'm having trouble understanding how the routing tables are used in > vxWorks. > My network background is very limited and I'm hoping someone can point out > the obvious things I'm missing and provide any pointers. > > We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected > via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143). > In this example the [ifShow "dc"] command shows that 4 ports are attached. > The [routeAdd] and [routeShow] commands give the following tables... > > ROUTE NET TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 131.198.68.0 131.198.68.249 3 1 206 dc0 > 131.198.68.0 131.198.68.202 1 0 0 dc0 > 131.198.69.0 131.198.69.63 1 0 0 dc12 > 131.198.69.0 131.198.69.62 1 0 0 dc11 > 131.198.69.0 131.198.69.61 1 0 0 dc10 > 131.198.69.0 131.198.69.60 1 0 0 dc9 > ------------------------------------------------------------------------ > ROUTE HOST TABLE > > Given, the packet loss is terrible! The problem I don't understand is No packets are being lost - just long latencies somewhere... > when I add a second route using a different interface on the powerpc > things don't go as I expect them. I'm expecting to be able to > ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10. > Is this correct??? Use a different subnet for the seond interface > John Hagen > Rockwell Collins > jlhagen@cacd.rockwell.com > ---------------------------------------------------------------- David Laight email: dsl@tadpole.co.uk Tadpole Technology plc phone: +44 1223 278 256 Cambridge, UK fax: +44 1223 278 201 From owner-vxwexplo-process Fri Dec 18 08:30:59 1998 From: daemon@csg.lbl.gov Date: Fri Dec 18 08:31:03 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Dec 18 04:00:14 PST 1998 Subject: Asserting RTS/CTS using Z85C30 UART Driver Subject: Re: Tornado + Version Control integration Subject: Re: Build Output Requires Prompting? (Update) Subject: Re: Dec Ethernet Driver? Subject: Re: PowerPc assembler & system tick accuracy Subject: Test Subject: Timeouts and signals Subject: VxWorks on Acer/Igel X terminal Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver Subject: Re: Tornado + Version Control integration Subject: How to get the system time on Vxworks. Subject: Re: Booting VxWorks from hard-disk Subject: Re: Multiple ethernet port - routing troubles. Subject: Re: Cross Reference File from ld68k Subject: Re: FAT disk full detection Subject: Re: FAT disk full detection Subject: RTIs HeapCheck() ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Asserting RTS/CTS using Z85C30 UART Driver Date: Thu, 17 Dec 1998 09:02:42 -0800 From: Tom jackson Organization: NeoPath Inc Message-ID: <36793932.F79C32CA@denali.neopath.com> Reply-To: tjackson Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30 driver in VxWorks? Thanks Thomas B. Jackson Neopath, Inc. Phone: 425-869-7284 Fax: 425-869-5325 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Thu, 17 Dec 1998 08:44:41 -0800 From: Matthew Downs Organization: Another Netscape Collabra Server User Message-ID: <367934F9.AA220556@ada.com> References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> But try and install patches to the OS......not an easy job! The whole philosophy of how they patch the os is flawed inmy opinion. Matt Saffi Hartal wrote: > Hi Peter Most people use make external IDE different from Tornado (we use > CodeWright), with version control. > It is a good solution that works fine. > > do it and enjoy your work. > Saffi > > Peter Weatherall wrote in message <36784811.108860281@news.phoenix.net>... > >Has anyone integrated Tornado with a source code version control > >system ? Some IDEs have this built-in. Any ideas about what is the > >best approach with Tornado... > > > > > >Thanks > >Peter --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Build Output Requires Prompting? (Update) Date: Tue, 15 Dec 1998 10:59:44 -0700 From: Mike Stimpson Organization: Utah Scientific, Inc. Message-ID: <3676A390.41C6@utsci.com> References: <754lui$8je$1@nnrp1.dejanews.com> paulvroberts@my-dejanews.com wrote: > > Tim Sohacki wrote: > > > > Update ... on one machine, it appears to be an interaction with > > Norton Anti-virus. On the other, it's something else, though > > we don't know what yet. > > > > Cheers, > > Tim > > > > Thanks to you and Philip Gaglia for giving me the idea that it was the virus > checker. > > I have verified this to be the case on the Win 95 machines that had problems. > We are running McAfee VShield 3.2.0, and if you disable it, Tornado make > windows then work fine. Some virus checkers work by not allowing anyone other than a recognized list of programs to write executable files. You might be able to tell the anti-virus software that Tornado (or some specific sub-program thereof) is legitimately able to write executables... > Oh the joy of developing under Windows... "Here's a nickel, kid. Get yourself a better computer." - a UNIX user in a Dilbert cartoon - -- Mike Stimpson (mstimp@utsci.com) Opinions expressed are not necessarily those of the management... The more I work as an engineer, the more I disbelieve the theory of evolution. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dec Ethernet Driver? Date: Thu, 17 Dec 1998 14:41:52 -0700 From: Rick Busser Organization: Dimensional Communications Message-ID: <36797AA0.51496C34@sitera.com> References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com> I am trying to use this driver on a MIPS BSP and am having problems getting it to work. What is the parameter string that you are using? Also how did you determine what interrupt level/vector the card is configured for? Thanks gtsang@glenayre.com wrote: > In article <36778DFF.D92F63F2@ibm.net>, > Dan DeVault wrote: > > Wind River has a driver that works with the SENS stack. At least for > > the Motorola MTX604 BSP. We are trouble shooting some problems with it > > now. > > > > Dan DeVault > > IBM Global Network > > devault@ibm.net > > Hi Dan, > > We have almost the exact config (MVME604, SENS) and I am having problem > bringing the driver up for DEC21143 (we did so for DEC21140). We have already > found a few bugs in this "END" driver. > > Gilbert Tsang > Glenarye R&D Inc. > > > > > Frankie Sierra wrote: > > > > > I am looking for a Dec 21140, or 21143 Ethernet driver for use with > > > VxWorks 5.1.3? Anyone done this? Any issues, caviats? > > > > > > Frankie Sierra > > > sierra@teralogic-inc.com > > > > > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own - -- Rick Busser rickb@sitera.com Software Engineer (303) 651-1935 x256 SiTera Corporation (303) 651-1199 fax 1820 Lefthand Circle Longmont, CO 80501 --------------------------- Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks Subject: Re: PowerPc assembler & system tick accuracy Date: 15 Dec 1998 11:05:08 -0500 From: Bill Pringlemeir Organization: PSINet Message-ID: References: <36760043.5D1F4E4E@ecitele.com> Followup-To: comp.sys.powerpc.tech [follow-ups set] Please don't cross post to this many newsgroups. The Gnu documentation on the assembler provides the syntax for the asm command. It is similar to a 'printf' or 'scanf'. The %0 means that the first arguement is taken from the list that follows. In this case, what ever register the compiler decides to put decCountVal in. The colon is used to seperate the output of the __asm__ statement from the arguement list. This is documented in your GNU toolKit user's guide which comes with VxWorks. Version 2.7 has the info on pg 129, and it is listed as 'Assembler Instructions with C expression operands'. You should RTFM. As for the trick with this code; It is what it doesn't say, the code will invalidate cache due to the change of the SPR value. This was discussed here recently. A better solution is to use one of the 16 RISC timers that are available on the PowerPC. Wind River doesn't provide these, but it would take at most two days to write them (plus an AUX clock to use SPY). Ok if you really want to know, read the VxWorks comment starting with: "The PowerPC decrementer doesn't reload the value by itself. The reload.." It wants to get the new value into the SPR as soon as possible because the decrementer doesn't reload. They load it with a value that will cause an interrupt every xx milliseconds. Missing time in the reload will cause an extra delay. If you use the RISC timers you can avoid this because they support reloading (restart). So the better 'trick' is to use hardware that fits the application. Good luck, Bill >>>>> "Yosi" == Yosi Yarchi writes: Yosi> Hello all The following is source copied from vxWorks system Yosi> timer interrupt routine, which is based on the decrementer Yosi> function of the PowerPc (in this case: MPC860). I'm looking Yosi> for some explanation about the syntax in this code: (1) what Yosi> is the %0 (implemented by the compiler as r9 register). (2) Yosi> what means the colon character (appears at the begining of Yosi> the last 3 lines). (3) what means of the "r", "3", and "cc" Yosi> commands which have special inverted commas (" ")? as I Yosi> could see, these lines have no effect on the code generated Yosi> by the compiler. (4) can someone explain me the trick of Yosi> compensation of the interrupt latency which is implemented Yosi> here in the loop(it required because the decrementer is not Yosi> auto reloaded)? - -- Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/" --------------------------- Newsgroups: comp.os.vxworks Subject: Test Date: Tue, 15 Dec 1998 16:28:41 GMT From: wlbrown@netcom.com (William L. Brown Jr.) Organization: Netcom Message-ID: Sender: wlbrown@netcom13.netcom.com This is a test of the vxWorks exploder. No adjustment of your set is necessary. --+---+ \/ -bill ++---+ |[]]|_^_[] wlbrown@netcom.com _|____+-+___|____|_ Concord, CA | o+o +-+ <>--<>-= \ C-250 #302 - "Amazing Grace" a.k.a. wlbrown@lbl.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Timeouts and signals Date: Thu, 17 Dec 1998 23:15:19 GMT From: Ephraim Ezekiel Organization: Quarry Technologies Message-ID: <3679902D.B21503A9@bbn.com> VxWorks provides a way of getting a signal synchronously using sigTimedWait() rather than calling an asynchonous signal handler.. Does anyone know if I can call timer_create() and get the signal via this synchronous interface? The documentation for the timers indicates that a signal handler must be installed in order to process the timeout. Thanks, - - Ephraim --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks on Acer/Igel X terminal Date: 17 Dec 98 23:52:36 GMT From: engel@math.uni-siegen.de Message-ID: <36799944.0@rainbow.hrz.uni-siegen.de> Sender: Michael Engel Hi, please excuse me if this posting is a little off-topic ... I just obtained a X terminal "Etherminal" from a german company named Igel. Upon further investigation I found out that this is an OEM'd Acer ViewX terminal based on a LSI Logic MIPS LR33020 CPU and running VxWorks. Imagine my surprise when I found out that I could telnet to my X terminal and actually get a login prompt ;-). Here my problem begins: the X11R5 X window server that comes with the terminal seems to be quite buggy - it usually doesn't survive a Netscape session. There is no support whatsoever for the terminals any more and the latest software release is from 1996. So I decided to try implementing a more recent version of X myself. As I own no VxWorks development license (and I'm afraid I won't be able to afford one as I have to live on a student's budget ...) I got the idea of porting some other OS to this X terminal. Linux or NetBSD are possibly out of reach as the LR33020 doesn't have an MMU - but Minix would probably fit quite well. I have some MIPS programming experience from the DECstation Linux port, so this isn't all new to me. So, my vague hope is that one of you might have worked on the VxWorks port to the ViewX X terminal and can provide me with information on the hardware of this terminal (I/O addresses, interrupt vectors used, IC datasheets). I would be quite happy if I could make something more useful out of that nice little terminal box ... it would make a really nice diskless workstation as it is expandable to 64 MB RAM with standard PS/2 SIMM modules. Best regards, Michael Engel (engel@unix-ag.org) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver Date: Thu, 17 Dec 1998 16:39:55 -0800 From: Matthew Downs Organization: Another Netscape Collabra Server User Message-ID: <3679A45B.C2E8E588@ada.com> References: <36793932.F79C32CA@denali.neopath.com> Tom jackson wrote: > Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30 > driver in VxWorks? Thanks > > Thomas B. Jackson > Neopath, Inc. > Phone: 425-869-7284 > Fax: 425-869-5325 85C30 or 35C30? I've used the 85C30 in my time, but not a 35C30. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Thu, 17 Dec 1998 16:39:00 -0800 From: Matthew Downs Organization: Another Netscape Collabra Server User Message-ID: <3679A423.AC5EAECC@ada.com> References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> <1998121719370883839@zetnet.co.uk> David & Bella Aldrich wrote: > Wind River announced in a recent seminar that Tornado II will have > hooks to allow 3rd party tools to interface to the development > environment. They mentioned version control systems in particular. > > David I'll have to go check the information about the beta. I'm on the Beta list and should have caught that one. If so, it about time! --------------------------- Newsgroups: comp.os.vxworks Subject: How to get the system time on Vxworks. Date: Thu, 17 Dec 1998 19:17:08 -0800 From: Venkat Emani Organization: QUALCOMM, Incorporated; San Diego, CA, USA Message-ID: <3679C934.DC671165@qualcomm.com> Greetings Folks, I would appreciate if someone can help me in the following regard. I am trying to get the system time from within the program. My code looks like this: #include ........ time_t tm Time = time(NULL) ; struct tm * tmp = localtime(&tmTime) ; ..... I thought tmTime should contain the no. of seconds from Jan 1st. 1970 ( At least on Solaris and NT it's like that ) However, tmTime is set to the no. of seconds elapsed since the card was booted last. ( Which meant if I run it in 5 minutes after booting my MC card, tmTime was being set to 5 * 60 = 300 . As a result the localtime() routine sets the time to Jan 1st 1970 , 00:05:00 which was n't what I wanted. Please let me know how I can get the system Time . My apologies if this question was previously answered. Please point me to that. Thanks, Ven. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Booting VxWorks from hard-disk Date: Tue, 15 Dec 1998 22:29:03 GMT From: david.hagood@ifrsys.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <756nra$1r8$1@nnrp1.dejanews.com> References: <7422lv$lg7@news.or.intel.com> <3667470D.AA598FFD@know_spam.wrs.com> I've tried to boot VxWorks from a hard disk only to fail miserably. The disk is partitioned with a FAT-16 partition as the first primary partition. That partition is bootable (marked active). I do a vxsys c:\, and it works. I copy a:bootrom.sys c:\bootrom.sys, and it works I verify that bootrom.sys is contiguous. I reboot the machine. VxLd complains that it cannot find bootrom.sys The bootrom.sys I copied over loaded fine from the floppy. I created the file system from VxWorks, so it ought to be a configuration that VxWorks likes. Any ideas? - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Multiple ethernet port - routing troubles. Date: Fri, 18 Dec 1998 06:37:48 -0500 From: Dan DeVault Organization: IBM.NET Message-ID: <367A3E8C.7B96F011@ibm.net> References: <862566DD.007EA688.00@crnotes.collins.rockwell.com> John, If you are using the dec21x40end driver with SENS then that would explain some of your troubles. We are currently troubleshooting this driver for dropped packets and xsmit problems. This driver can receive packets at a great rate. However it seems to have some problems in its transmit logic. I'll post more once we figure out if it is the driver or something else. Dan DeVault IBM Global Network John L Hagen wrote: > Hi All, > > vxWorks / powerPC > First off, sorry for the extreme length of this note. > > I'm having trouble understanding how the routing tables are used in > vxWorks. > My network background is very limited and I'm hoping someone can point out > the obvious things I'm missing and provide any pointers. > > We're running vxWorks 5.3.1 on a MVME2604 board (BSP 1.1/4) - connected > via pci expansion to multiple 4-port ethernet cards (DEC21140/DEC21143). > In this example the [ifShow "dc"] command shows that 4 ports are attached. > The [routeAdd] and [routeShow] commands give the following tables... > > ROUTE NET TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 131.198.68.0 131.198.68.249 3 1 206 dc0 > 131.198.68.0 131.198.68.202 1 0 0 dc0 > 131.198.69.0 131.198.69.63 1 0 0 dc12 > 131.198.69.0 131.198.69.62 1 0 0 dc11 > 131.198.69.0 131.198.69.61 1 0 0 dc10 > 131.198.69.0 131.198.69.60 1 0 0 dc9 > ------------------------------------------------------------------------ > ROUTE HOST TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 127.0.0.1 127.0.0.1 5 1 11 lo0 > 131.198.69.44 131.198.69.60 5 0 0 dc9 > ------------------------------------------------------------------------ > The dc0 interface is used to boot the os image from our company network. > Subnet 69 is just one I made up - but the addresses are unique and not > registered with the company network. > > At this point I can delete/add [routeAdd..] single routing paths using dc9 > or 10 > or 11 etc... I can ping to and from the powerpc ports individualy from > another > computer(dolch3/4) on the subnet 69. I can repeat this with some > consistency with any > one of my added interfaces. e.g. > > dolch4 is alive > PING dolch4 (131.198.69.44): 56 data bytes > 64 bytes from dolch4 (131.198.69.44): icmp_seq=0. time=960. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=1. time=0. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=2. time=1488. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=3. time=528. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=4. time=368. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=5. time=1152. ms > 64 bytes from dolch4 (131.198.69.44): icmp_seq=6. time=192. ms > ----dolch4 PING Statistics----12 packets transmitted, 7 packets received, > 41% packet lossround-trip (ms) min/avg/max = 0/669/1488 > > Given, the packet loss is terrible! The problem I don't understand is > when I add a second route using a different interface on the powerpc > things don't go as I expect them. I'm expecting to be able to > ping dolch4(.44) using dc9 and communicate with dolch3(.48) using dc10. > Is this correct??? > > ROUTE NET TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 131.198.68.0 131.198.68.249 3 1 224 dc0 > 131.198.68.0 131.198.68.202 1 0 0 dc0 > 131.198.69.0 131.198.69.63 1 0 0 dc12 > 131.198.69.0 131.198.69.62 1 0 0 dc11 > 131.198.69.0 131.198.69.61 1 0 0 dc10 > 131.198.69.0 131.198.69.60 1 0 0 dc9 > ------------------------------------------------------------------------ > ROUTE HOST TABLE > destination gateway flags Refcnt Use Interface > ------------------------------------------------------------------------ > 127.0.0.1 127.0.0.1 5 1 15 lo0 > 131.198.69.44 131.198.69.60 5 0 16 dc9 > 131.198.69.48 131.198.69.61 5 0 0 dc10 > ------------------------------------------------------------------------ > > When I try a single ping over the second route the system gets crazy and > the > tornado tools wonder off to ???. e.g. a reboot is needed. > > ping "dolch3",1,0 > can't read "event": no such variable > value = -1 = 0xffffffff > -> Error while polling for events: > WTX Error 0x10197 (EXCHANGE_TIMEOUT) > -> Error while polling for events: > WTX Error 0x10197 (EXCHANGE_TIMEOUT) > etc... > > This happens if I repeat the process and try to ping over the first dc9 > route after just adding the second dc10 route. I can see from our ethernet > analyzer that the ping command actually results in ARPs going out and > responses are generated by the second computer. But vxWorks now seems to be > lost and the tools are no longer communicating with the target and I have > to reboot the system. > > I know it's not that tuff - It just hasn't dawned on me what I'm doing > wrong. > Any help is appreciated. > > John Hagen > Rockwell Collins > jlhagen@cacd.rockwell.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Cross Reference File from ld68k Date: Fri, 18 Dec 1998 11:39:09 GMT From: whd@directors-1.zetnet.zet (Ag@whd) Organization: White Horse Design Message-ID: <367f3ebd.2868169@znews.zetnet.co.uk> References: <361A29E9.46DFD4C@email.mot.com> Reply-To: whd@directors-1.zetnet.zet On Tue, 06 Oct 1998 09:32:09 -0500, Lance C Brown penned these words: >I was trying to use 'ld68k --cref' and it seems that the >GNU Toolkit manual says this supported, but WindRiver >didn't build ld68k with this option turned on. So does >anyone know how to generate a Cross Reference >file without 'ld68k --cref'? I know that for ldppc the -Map option is case SENSITIVE. Worth checking this on your ld68k. Adrian WWW WWW Adrian Gothard WWW ww WWW White Horse Design WWWWWWWWWW WWWW WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd - --- Designers of video capture/filter/processing systems for aircraft --------------------------- Newsgroups: comp.os.vxworks Subject: Re: FAT disk full detection Date: Fri, 18 Dec 1998 11:41:09 GMT From: whd@directors-1.zetnet.zet (Ag@whd) Organization: White Horse Design Message-ID: <36803f38.2990259@znews.zetnet.co.uk> References: <6vi3b8$hi@overload.lbl.gov> <3620bc4d.30983072@znews.zetnet.co.uk> <3626639D.DB5A97B7@lynx.tsb.ca> Reply-To: whd@directors-1.zetnet.zet On Thu, 15 Oct 1998 17:05:33 -0400, Yibing Fan penned these words: > Adrian, > >Following 3 lines code will do what you want: > > int fd = open(YOUR_DOSSF_NAME, O_WRONLY, 0); > ioctl(fd, FIONFREE, (int)&freeMem); > close(fd); > >Where freeMem is an int your declared to hold return value. Thanks, but I did not post the original query. Adrian WWW WWW Adrian Gothard WWW ww WWW White Horse Design WWWWWWWWWW WWWW WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd - --- Designers of video capture/filter/processing systems for aircraft --------------------------- Newsgroups: comp.os.vxworks Subject: Re: FAT disk full detection Date: Fri, 18 Dec 1998 11:41:40 GMT From: whd@directors-1.zetnet.zet (Ag@whd) Organization: White Horse Design Message-ID: <36813f59.3023573@znews.zetnet.co.uk> References: <6vi3b8$hi@overload.lbl.gov> <3620bc4d.30983072@znews.zetnet.co.uk> <3626639D.DB5A97B7@lynx.tsb.ca> Reply-To: whd@directors-1.zetnet.zet On Thu, 15 Oct 1998 17:05:33 -0400, Yibing Fan penned these words: /snip/ >Hope this help. I meant to add that some "snipping" would probably go down well :-) Adrian WWW WWW Adrian Gothard WWW ww WWW White Horse Design WWWWWWWWWW WWWW WWWW whd@zetnet.co.uk, http://www.users.zetnet.co.uk/whd - --- Designers of video capture/filter/processing systems for aircraft --------------------------- Newsgroups: comp.os.vxworks Subject: RTIs HeapCheck() Date: Fri, 18 Dec 1998 12:50:40 +0100 From: Roberto Nunnari Organization: AGIE Message-ID: <367A4190.F9764253@agie.ch> Hi all, I tried to run RTI's HeapCheck() on 2 different x86 targets and its reports are strange to me... maybe some kind soul can help me understand what's going on... First target: default BSP from wind river 'pc486' with 16MB RAM I run HeapCheck --> OK HeapCheck 1 HeapCheck: Checking heap at 0xfff000... HeapCheck: 30 blocks checked. HeapCheck: 1 free blocks totalling 20 bytes (28 with headers). HeapCheck: 29 used blocks totalling 9740 bytes (9972 with headers). HeapCheck: Checking heap at 0xffc8f0... HeapCheck: 3653 blocks checked. HeapCheck: 20 free blocks totalling 13709140 bytes (13709300 with headers). HeapCheck: 3633 used blocks totalling 283892 bytes (312956 with headers). HeapCheck: Checking heap at 0x200000... HeapCheck: 1 blocks checked. HeapCheck: 0 free blocks totalling 0 bytes (0 with headers). HeapCheck: 1 used blocks totalling -8 bytes (0 with headers). 21 total free blocks found. Isn't that '-8' bytes strange??? Second target: third-party BSP for pentium with 32MB RAM I run HeapCheck --> ERROR 0xfae2ac (t16): Heap Error: 'prev ptr' is corrupt at 1ffff8 (count = 1) HeapCheck 1 HeapCheck: Checking heap at 0xfff000... HeapCheck: 8 blocks checked. HeapCheck: 1 free blocks totalling 9784 bytes (9792 with headers). HeapCheck: 7 used blocks totalling 152 bytes (208 with headers). HeapCheck: Checking heap at 0xffc8f0... HeapCheck: 104 blocks checked. HeapCheck: 1 free blocks totalling 13785724 bytes (13785732 with headers). HeapCheck: 103 used blocks totalling 340764 bytes (341588 with headers). HeapCheck: Checking heap at 0x200000... 0xfae2ac (t17): Heap Error: 'prev ptr' is corrupt at 1ffff8 (count = 2) HeapCheck: 1 blocks checked. HeapCheck: 1 free blocks totalling -10 bytes (-2 with headers). HeapCheck: 0 used blocks totalling 0 bytes (0 with headers). Here again I get a negative value for bytes, but this time for the free blocks! Any help/hint will be greatly appreciated... Best regards. Robi. --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Fri Dec 18 10:03:51 1998 From: Charlie Grames Date: Fri Dec 18 10:03:55 PST 1998 Subject: Re: VwWorks: A16 VME for PowerPC (MVME2700) -Reply -Reply Fred, Carl, Minbo, et al.: Actually, the way d() behaves depends on which version you use. The version in src/usr/usrLib.c is included in the target-based shell. The version available from WindSh behaves as I indicated in my other e-mail (i.e., vxMemProbe() of first and last byte of a 16-byte segment followed by four 32-bit reads). If you're using WindSh and want the usrLib.c version, put an "@" in front of the "d" when you perform the command. Personally, I still think it is safer to view or modify device memory using constructs like "val = (char)*0xfbff6005" or "*0xfbff6005 = (char)val". Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 12/17/98 08:23pm >>> Submitted-by owner-vxwexplo-process Thu Dec 17 18:23:16 1998 Submitted-by: Fred Roeber On Thu, 17 Dec 1998, Carl C. Chesbrough answered a question about A16 access: > You can use the m() function, giving it a parameter of 1 to do 8-bit > access rather than 16-bit accesses. I thought that the default d() > access was 16-bits. You can specify the size with the 3rd parameter > to the d() function. I never realized that the "d" command supported the same width argument that the "m" command did. If anyone is interested in how these commands work, they are delivered in source form with VxWorks. Just look in the file src/usr/usrLib.c. Default command uses 16 bit accesses the way Carl thought (at least in my VxWorks 5.3 copy of the code). Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | | TraceMaker product manager -> www.tracemaker.bbn.com | From owner-vxwexplo-process Fri Dec 18 10:20:02 1998 From: "Jijo Xavier" Date: Fri Dec 18 10:20:07 PST 1998 Subject: Re: Multiple ethernet port - routing troubles. Hi There! I'm quite new to VxWorks. I'm developing a Sharedmemory Backplane n/w device driver. I'd like to know how to load a device driver at the boot time. Thanks in advance. Jijo. From owner-vxwexplo-process Fri Dec 18 11:38:55 1998 From: Lori Fraleigh Date: Fri Dec 18 11:38:59 PST 1998 Subject: Re: RTIs HeapCheck() Have you tried running HeapFindPools? Sometimes the heuristic that identifies the default memory pools in the system fails and you need to make this call to properly initialize the data structures for HeapCheck. If this doesn't solve your problems or you have other questions concerning the Heap tools, feel free to contact our support department at support@rti.com. We will be happy to work directly with you. (I'll be on vacation.) Regards, Lori -- Lori Fraleigh Real-Time Innovations http://www.rti.com lori@rti.com 408-720-8312 ext. 121 Fax: 408-734-5009 Your message: Newsgroups: comp.os.vxworks Subject: RTIs HeapCheck() Date: Fri, 18 Dec 1998 12:50:40 +0100 From: Roberto Nunnari Organization: AGIE Message-ID: <367A4190.F9764253@agie.ch> Hi all, I tried to run RTI's HeapCheck() on 2 different x86 targets and its reports are strange to me... maybe some kind soul can help me understand what's going on... First target: default BSP from wind river 'pc486' with 16MB RAM I run HeapCheck --> OK HeapCheck 1 HeapCheck: Checking heap at 0xfff000... HeapCheck: 30 blocks checked. HeapCheck: 1 free blocks totalling 20 bytes (28 with headers). HeapCheck: 29 used blocks totalling 9740 bytes (9972 with headers). HeapCheck: Checking heap at 0xffc8f0... HeapCheck: 3653 blocks checked. HeapCheck: 20 free blocks totalling 13709140 bytes (13709300 with headers). HeapCheck: 3633 used blocks totalling 283892 bytes (312956 with headers). HeapCheck: Checking heap at 0x200000... HeapCheck: 1 blocks checked. HeapCheck: 0 free blocks totalling 0 bytes (0 with headers). HeapCheck: 1 used blocks totalling -8 bytes (0 with headers). 21 total free blocks found. Isn't that '-8' bytes strange??? Second target: third-party BSP for pentium with 32MB RAM I run HeapCheck --> ERROR 0xfae2ac (t16): Heap Error: 'prev ptr' is corrupt at 1ffff8 (count = 1) HeapCheck 1 HeapCheck: Checking heap at 0xfff000... HeapCheck: 8 blocks checked. HeapCheck: 1 free blocks totalling 9784 bytes (9792 with headers). HeapCheck: 7 used blocks totalling 152 bytes (208 with headers). HeapCheck: Checking heap at 0xffc8f0... HeapCheck: 104 blocks checked. HeapCheck: 1 free blocks totalling 13785724 bytes (13785732 with headers). HeapCheck: 103 used blocks totalling 340764 bytes (341588 with headers). HeapCheck: Checking heap at 0x200000... 0xfae2ac (t17): Heap Error: 'prev ptr' is corrupt at 1ffff8 (count = 2) HeapCheck: 1 blocks checked. HeapCheck: 1 free blocks totalling -10 bytes (-2 with headers). HeapCheck: 0 used blocks totalling 0 bytes (0 with headers). Here again I get a negative value for bytes, but this time for the free blocks! Any help/hint will be greatly appreciated... Best regards. Robi. From owner-vxwexplo-process Fri Dec 18 12:12:58 1998 From: heller@nm.picker.com (Mark Heller) Date: Fri Dec 18 12:13:06 PST 1998 Subject: MVME-2300 and MPMC202 second ethernet. Hello all, I've got a Motorola MVME-2303 cpu board and I was thinking of adding a second ethernet to it with the Motorola MPMC202 pmc module. Has anyone out there done this already? If so, what problems were encountered? What initialization was necessary? Thanks in advance. ------- -Mark ------- Mark Heller Picker International Inc. Nuclear Medicine Division heller@nm.picker.com VxWorks Tornado VxWorks Tornado VxWorks Tornado VxWorks Tornado From owner-vxwexplo-process Sat Dec 19 15:01:12 1998 From: darryl@cognex.com (Darryl Troxel) Date: Sat Dec 19 15:01:18 PST 1998 Subject: MVME-177 locks up with copyback caching VxWorks folks, Recently one of our typical configurations has been giving us trouble, and maybe somebody has seen something similar, or even fixed it. I'm running VxWorks 5.2 for MC68K on an MVME-167 as CPU 0 and an MVME-177 as CPU 1 in a VME cardcage. The two CPU's communicate by making their RAM accessible on the VMEbus at a unique "global" address, with VMEchip2 GCSR mailbox interrupts and message pointers in low RAM. On the 177 I'm using MMU tables to provide noncached RAM at the low end of the memory map for ethernet buffers, inter-CPU I/O and the MMU tables themselves; the rest of RAM can be set cachable-writethrough or cachable-copyback. When the CPU 1 code has data to send to CPU 0, the data blocks in copyback RAM are pushed out of cache before interrupting CPU 0 so the data won't be stale. We've shipped 10 systems or more with this configuration that have been working fine in the field. In the last month we've built 3 such systems that run for anywhere from 4 to 13 hours, then the 177 "locks up". Sometimes it just plain halts (STAT LED lit), other times it isn't halted; but it won't respond to the network or even to the serial port. The board still responds as a VME slave, so I can look around in memory a bit. I've verified that none of the task stacks have overflowed, none have suspended for bus errors or address faults. Of the 12 hangs I've investigated in detail, the vector table of the 177 has been trashed 3 times; it was undisturbed the other 9 times. I started recording the PC, SP, and SR values at each clock tick, and found one occurrence where non-interrupt code was running at interrupt level (SR = 0x2400). Other hangs show OK values (rational PC values, SP well within task statcks). If I run with the cached RAM as cachable-writethrough, however, the CPU doesn't hang. It seems like interrupt processing with copyback caching somehow causes the problem. On the 68060, there is no separate interrupt stack (interrupts are processed on the current task's stack). But interrupt processing would still reference memory from the CPU, which should hit in the cache anyway. I don't want to run the 177 writethrough or noncached, because the performance drop for the 50MHz CPU forced to cache-push on the 25MHz local bus makes it not much faster than the MVME-167 in these modes. One more fact I found today in the 5.2 Reference Manual: the ei device driver needs the ethernet buffers to be in noncached RAM, but it also uses 8 bytes in the .data section and 912 bytes in .bss. In addition, the driver allocates some fixed and variable-sized chunks with cacheDmaMalloc() to share with the 82596 controller. Since I'm doing the cache management outside of vxWorks (I'm not using VxVMI), cacheDmaMalloc is just doing a plain malloc, which will not be in noncached space. Does anyone know if these additional data blocks would cause this problem if in cached space, and if so, how can I "hotwire" the ei driver or cacheDmaMalloc() to use noncached RAM I can set aside for this purpose? And is it just luck that the 10 systems in the field haven't experienced this problem? Darryl __________________________________________________________________ Darryl Troxel COGNEX Surface Inspection darryl@cognex.com Systems Division Tel: 510.749.4038 2060 Challenger Drive Fax: 510.865.9927 Alameda, CA 94501 USA __________________________________________________________________ From owner-vxwexplo-process Sun Dec 20 04:01:29 1998 From: daemon@csg.lbl.gov Date: Sun Dec 20 04:01:32 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Dec 20 04:01:25 PST 1998 Subject: Re: vxworks binary semaphore Subject: Global Descriptor Table Subject: RPC: Procedure unavailable.... Subject: Re: off topic question Subject: Looking for firewall product or source code Subject: Re: Dec Ethernet Driver? Subject: Zip software needed Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver Subject: Network misbeviour Subject: man pages on NT Subject: Re: SCSI disk Subject: Re: Zip software needed Subject: Re: Tornado + Version Control integration Subject: Any Experience with Posix Message Queues? Subject: arp proxy form VME backplane to ethernet Subject: Re: Network misbeviour Subject: Re: embedded HTTP Subject: DDD For Tornado/vxWorks? Subject: Re: PowerPc assembler & system tick accuracy ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: vxworks binary semaphore Date: Fri, 18 Dec 1998 07:33:58 -0600 From: "Michael W. Johnson" Organization: NeoSoft, Inc. Message-ID: <367A59C6.FEB3DB63@wgcgps.com> References: <75c6q7$789@overload.lbl.gov> TEM Koshimizu, Kazu wrote: > Does anyone know the way to find out the task did the last semTake() for > specific b-sem ? semShow(), executed from the shell, prints the task's ID. Mike Johnson Western Geophysical Houston, TX --------------------------- Newsgroups: comp.os.vxworks Subject: Global Descriptor Table Date: Fri, 18 Dec 1998 12:47:25 GMT From: keshavbc@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <75diss$oq2$1@nnrp1.dejanews.com> hi, i want to know what a GDT (w.r.t 80x86 architecture) is and it's uses. also, i want to know it's relationship with the IVT(Interrupt Vector Table), if any. would you mind being elaborative. p.s: Please also reply at - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: RPC: Procedure unavailable.... Date: Fri, 18 Dec 1998 09:40:22 -0500 From: Jeff Daly Organization: Sanders A Lockheed Martin Company Message-ID: <367A6956.B4FFA4A7@lmco.com> Reply-To: jeffrey.j.daly@lmco.com This is a multi-part message in MIME format. - --------------146EA2B3899CEB21B8F78391 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit trying to attach tgtsvr to my target for the first time.... using the default BSP build (custom MIPS board) with windCfg from the launcher. no problem with vxWorks 5.3 bootrom and kernel boot (still using TYCODRV_5_2). WDB_COMM_NETWORK defined. using snoop on solaris2.5, i see one RCP call go to the target and the target responds with an accept status = 3 (Procedure unavailable). am i missing something in the kernel konfig, since the network connection is ok? - --------------146EA2B3899CEB21B8F78391 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jeff Daly Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jeff Daly n: Daly;Jeff org: Sanders, A Lockheed Martin Co. email;internet: jeffrey.j.daly@lmco.com title: SW Guy note: B-sharps x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard - --------------146EA2B3899CEB21B8F78391-- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: off topic question Date: Fri, 18 Dec 1998 09:59:50 -0600 From: "Michael W. Johnson" Organization: NeoSoft, Inc. Message-ID: <367A7BF5.A286B578@wgcgps.com> References: <01be2a8e$653ef520$b7c310ac@ndsuk1063> Robert Stedman wrote: > I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc > compiler for both ends. Packing structures at the target side is achieved > with __attribute__ ((packed)), however this doesn't work at the Sun side. > Any ideas on how to coerce gcc to pack structures on a Sun would be > gratefully received (#pragma pack (1) doesn't do the trick either) To the best of my recollection, when the same issue arose here several years ago, the solution was just to make all structure elements were some multiple of four bytes in length, because the Sun won't back bytes as expected. Mike Johnson Western Geophysical Houston, TX --------------------------- Newsgroups: comp.os.vxworks Subject: Looking for firewall product or source code Date: Fri, 18 Dec 1998 09:38:08 -0800 From: Randy Riggins Message-ID: <54C40CA7FBB3D111B0D200A0C9AB28C101DD4723@earth.telestream.net> Sender: Randy Riggins I need some basic firewall functionality between the two network ports of our product. What's available in VxWorks? Thanks, randy --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dec Ethernet Driver? Date: Fri, 18 Dec 1998 13:41:10 -0500 From: "Khoa" Message-ID: References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com> gtsang@glenayre.com wrote in message <75bmv6$79n$1@nnrp1.dejanews.com>... >We have almost the exact config (MVME604, SENS) and I am having problem >bringing the driver up for DEC21143 (we did so for DEC21140). We have already >found a few bugs in this "END" driver. >Gilbert Tsang >Glenarye R&D Inc. So does anyone know whether VxWorks has an updated patch for the driver or acknowledged this problem in an SPR? Khoa --------------------------- Newsgroups: comp.os.vxworks Subject: Zip software needed Date: Fri, 18 Dec 1998 11:13:25 -0800 From: Matthew Downs Organization: Another Netscape Collabra Server User Message-ID: <367AA955.ECDE28E7@ada.com> I need some compression software for saving files on my VxWorks target. Has any one ported gzip or some thing similar to VxWorks? Matt --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asserting RTS/CTS using Z85C30 UART Driver Date: Fri, 18 Dec 1998 11:11:59 -0800 From: Tom Jackson Organization: NeoPath Inc Message-ID: <367AA8FF.A2D3173@denali.neopath.com> References: <36793932.F79C32CA@denali.neopath.com> <3679A45B.C2E8E588@ada.com> Reply-To: tjackson Whoops, that should have said Z85C30. I've now got a good data sheet on the relevant control registers so I should be good to go. I'll write back if I run into trouble. Thanks for the reply. Tom Matthew Downs wrote: > > Tom jackson wrote: > > > Anybody know how to assert/deassert the RTS/CTS lines using the Z35C30 > > driver in VxWorks? Thanks > > > > Thomas B. Jackson > > Neopath, Inc. > > Phone: 425-869-7284 > > Fax: 425-869-5325 > > 85C30 or 35C30? I've used the 85C30 in my time, but not a 35C30. - -- Thomas B. Jackson Phone: 425-869-7284 Fax: 425-869-5325 --------------------------- Newsgroups: comp.os.vxworks Subject: Network misbeviour Date: Wed, 16 Dec 1998 08:34:41 -0800 From: "Dave Craig" Organization: Verio Northern California's Usenet News Service Message-ID: <758neq$5ql$1@news.ncal.verio.com> Here are some symptoms that we have in our system that I'm looking for some insight into. We run on x86 with SENS... * Two processors on a switched ethernet system communicate with each other by broadcasting UDP messages. * If severely loaded, one processor (lets call it A) gets into a state where it no longer seems to get messages broadcast from B in real time. They appear to accumulate in a buffer somewhere before finally the whole lot avalanches through. No messages appear to be lost. * However, the messages broadcast from processor A are all received by A immediately (these do not go out on to the network but loopback at the IP layer) * Pinging processor A from another processor times out most of the time...getting a target server to stay connected is difficult - unless there is already a steady stream of ethernet messages from processor B which seems to push the target server messages through (?!) My question is whether anyone else has seen this, and more importantly at what level in the SENS stack could such a problem be ocurring. Thanks, Dave Craig Palo Alto --------------------------- Newsgroups: comp.os.vxworks Subject: man pages on NT Date: Wed, 16 Dec 1998 08:44:17 -0800 From: "Abimael Peña" Organization: Raytheon Systems Company Message-ID: <3677E360.3E88304C@west.raytheon.com> I need info on how to make man pages on NT. Any hints or help would be greatly appreciated. Thanks in advance. Abimael Pena Raytheon Systems Company El Segundo apena@west.raytheon.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: SCSI disk Date: Fri, 18 Dec 1998 13:55:12 -0600 From: "Dennis C." Organization: Cisco Systems, Inc. Message-ID: <75eit2$hm2$1@news-sj-2.cisco.com> References: <75eenm$9dc$1@trsvr.tr.unisys.com> WRS has drivers for this chip. Talk to their field people and they can quote you a $. It is not cheap. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Zip software needed Date: Fri, 18 Dec 1998 13:54:36 -0600 From: "Dennis C." Organization: Cisco Systems, Inc. Message-ID: <75eiru$hi4$1@news-sj-2.cisco.com> References: <367AA955.ECDE28E7@ada.com> VxWorks BSP has a compression routine that it uses to uncompress a compressed image. Perhaps you can use that same routine. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Sat, 19 Dec 1998 01:35:16 GMT From: weatp@syntron.com (Peter Weatherall) Message-ID: <367b0209.287540781@news.phoenix.net> References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> <1998121719370883839@zetnet.co.uk> <367A7ADA.8EED1B31@nortelnetworks.com> I have a SourceSafe 6.0 installation setup. I haven't quite yet got around to attempting to integrate with Tornado... Peter On Fri, 18 Dec 1998 10:55:06 -0500, Tim Sohacki wrote: >> Wind River announced in a recent seminar that Tornado II will have >> hooks to allow 3rd party tools to interface to the development >> environment. They mentioned version control systems in particular. > > >The Tornado II Beta Release Notes (page 9) document specifically >mentions integration with ClearCase, which is what Wind River uses. > >We're currently using Visual Source Safe. >Anyone had any experience integrating VSS and Tornado? > >Cheers, >Tim > > > >-- >Tim Sohacki, Nortel Networks >email: sohacki@nortelnetworks.com --------------------------- Newsgroups: comp.os.vxworks Subject: Any Experience with Posix Message Queues? Date: Wed, 16 Dec 1998 20:52:17 GMT From: Ephraim Ezekiel Organization: Quarry Technologies Message-ID: <36781D29.BDCDAD5@bbn.com> We are considering using Posix Message queues as our primary mechanism for IPC between tasks. The only advantage of using them is the ability to notify a task to wake up via a signal when a message is posted on a queue, which therefore allows a task to wait on multiple queues. Has anyone had experience with VxWorks implementation of Posix queues? How does it compare to VxWork's message queues? Are they reliable? We also considered using UDP sockets but ruled it out due to too much CPU overhead. Thanks, - - Ephraim --------------------------- Newsgroups: comp.os.vxworks Subject: arp proxy form VME backplane to ethernet Date: Wed, 16 Dec 1998 14:48:08 -0800 From: Randy Kizer Organization: TRW, Inc. Message-ID: <36783834.25F4@pcsweb.net> I have some questions about how arp proxy works on vxworks. When there is a VME chassis with many cards with VxWorks and one gateway to the ethernet, how is the ip address mapped to the hosts on the ethernet? i.e. does the chassis controller report the arp mapping to the ethernet hosts or does each card report itself to the ethernet hosts? If it is the chassis controller that reports it, how can I get vxworks to report a non vxworks card to the ethernet hosts? Thanks, Randy Kizer TRW randy.kizer@trw.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Network misbeviour Date: Wed, 16 Dec 1998 16:28:10 -0800 From: "Dave Craig" Organization: Verio Northern California's Usenet News Service Message-ID: <759j6t$j4f$1@news.ncal.verio.com> References: <758neq$5ql$1@news.ncal.verio.com> The problem turned out to be... Our END driver does not handle overflows at all well. We don't have source for it - though I know that it is very similar to the templateEnd example (it prints out the same debug and was written by WRS). What was happening is that netTask was being locked out (due to a priority inversion) which resulted in an overflow of packets on the ethernet chip. This is because at interrupt time the END driver does very little except for scheduling some foreground time to process the received packets. If it doesn't get the foreground time, the chip will likely overflow. By fixing the priority inversion and setting netTask priority suitably high netTask always manages to get in before an overflow occurs on the chip and thus skirts around the driver bug. The driver bug appears to be that the receive ring buffer gets confused by a message overflow. After this it reacts to network interrupts but fails to process the received message because it's trying to read the wrong one from the ring - maybe the ring buffer in/out pointers have got back to front?. The messages are all flushed out when the ring buffer has cycled round - but for some reason the problem doesn't self rectify as one might hope and this behavious continues. Dave Craig. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: embedded HTTP Date: 17 Dec 1998 03:36:52 GMT From: kbeckley@aol.com (KBeckley) Organization: AOL http://www.aol.com Message-ID: <19981216223652.07675.00000289@ng-ce1.aol.com> References: <74ognu$nsv@newstoo.ericsson.se> Wind River has Wind Web Server which can setup an embedded http server that can also use CGIs, java, and javascripts. Another package that has just come out is HTMLWorks which works similar to the Wind Web Server. Currently the HTMLWorks has only been ported to the x86 platform. I am currently developing with the Wind Web Server on a 68k platform. --------------------------- Newsgroups: comp.os.vxworks Subject: DDD For Tornado/vxWorks? Date: Sat, 19 Dec 1998 08:44:45 -0600 From: "Peter A. Koren" Organization: Family Message-ID: <367BBBDD.66F40902@hex.net> Reply-To: pkoren@hex.zap-this.net Hi, I saw a reference to DDD being available for Tornado/vxWorks recently, but I can't find the copy I thought I made. Can anybody steer me to the DDD info. Thanks, Peter Koren - -- Remove the 'zap-this' from the email address to reach me. "One may proceed from absurd premise to ridiculous conclusion with impeccable logic." -- Santayana --------------------------- Newsgroups: comp.arch.embedded,comp.sys.powerpc.tech,comp.sys.powerpc,comp.os.vxworks Subject: Re: PowerPc assembler & system tick accuracy Date: Sat, 19 Dec 1998 18:01:13 +0100 From: Ola Liljedahl Organization: Enea Data AB Message-ID: <367BDBD9.C6272F96@enea.se> References: <36760043.5D1F4E4E@ecitele.com> Yosi Yarchi wrote: > > The following is source copied from vxWorks system timer interrupt > routine, which is based on the decrementer function of the PowerPc (in > this case: MPC860). I'm looking for some explanation about the syntax in > this code: (1) what is the %0 (implemented by the compiler as r9 > register). (2) what means the colon character (appears at the begining > of the last 3 lines). (3) what means of the "r", "3", and "cc" commands > which have special inverted commas (" ")? as I could see, these lines > have no effect on the code generated by the compiler. (4) can someone > explain me the trick of compensation of the interrupt latency which is > implemented here in the loop(it required because the decrementer is not > auto reloaded)? VxWorks is using the gnu compiler. So this example is using gcc inline assembly. Download any gcc manual and this should be explained under gcc extensions to the C language. Answers: 1) %0 is the first parameter (decCountVal in this case). The compiler will supply a proper register when compiling. 2) the syntax of gcc inline assembly is __asm__("string with instructions" : output operands : input operands : side effects ); 3) "r" means the parameter should be passed in a normal register gcc for 68k has "d" for data register and "a" for address register (I think, it was a while ago). PowerPC only has general purpose registers, "r". "3" and "cc" after the last colon means these registers are thrashed by the inline assembly. All other registers are unmodified (except for the register used for %0 but that is under control of the compiler). 4: Don't know. I am no VxWorks expert. Actually I am a VxWorks enemy. Please consider OSE for your next project! > > Thank you > Yosi > > __asm__ (" > mfdec 3 > sysClkIntLoop: > add. 3, %0, 3 > ble sysClkIntLoop /* check if we missed tick(s) */ > > mtdec 3" > : /* no output operands */ > : "r" (decCountVal) /* input operand, %0 = > decCountVal */ > : "3", "cc"/* side-effects: r3 clobbered, 'condition code' is > clobbered */ > ); - -- Ola Liljedahl olli@enea.se Enea OSE Systems "OSE - Design on a higher level" --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Sun Dec 20 23:58:11 1998 From: "Morbitzer, Dirk ZFL-Calden LE2" Date: Sun Dec 20 23:58:14 PST 1998 Subject: Tornado and Matlab's Real-Time Workshop Hi VxWorks Users! I am looking for any experience of Tornado in combination with automaticly generated code from Matlab's Real-Time Workshop. We are seeking a straight rapid prototyping solution from Simulink to controller on target system with as little code hacking as possible. Please send any information on that topic. Best regards, Dirk Morbitzer --------------------------------------------- Dirk Morbitzer Development Rotor Components ZF Luftfahrttechnik GmbH P.O. Box 101667 34016 Kassel, Germany eMail: dirk.morbitzer@zf-group.de Phone: +49 (0)5674 701-414 Fax: +49 (0)5674 701-345 --------------------------------------------- From owner-vxwexplo-process Mon Dec 21 04:00:12 1998 From: daemon@csg.lbl.gov Date: Mon Dec 21 04:00:15 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Dec 21 04:00:06 PST 1998 Subject: Need help: BIOS for Intel x86 and TX chipsets Subject: Re: Tornado + Version Control integration Subject: Re: Dec Ethernet Driver? Subject: Re: Tornado + Version Control integration Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency Subject: Exception: Interrupt Level 11 2ce card - 2nd request Subject: re: Multiple ethernet port - routing troubles. Subject: Re: off topic question Subject: off topic question Subject: Re: Target server windowsNT Subject: Re: Tools to track memory leaks Subject: Message Passing Interface (MPI) in VxWorks? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Need help: BIOS for Intel x86 and TX chipsets Date: Thu, 17 Dec 1998 08:10:13 -0500 From: John Kang Organization: AlliedSignal Inc. Message-ID: <367902B5.A0978014@alliedsignal.com> Hello. We're developing a Pentium board with Intel TX chipsets. It looks like there is a lot to do just to get system RAM alive, not to mention getting PCI and ISA bus alive. Does anyone know where we can get source code for commercially available BIOS? Thanks in advance. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Thu, 17 Dec 1998 17:36:26 +0200 From: "Saffi Hartal" Organization: NetVision Israel Message-ID: <75b9fp$787$1@news.netvision.net.il> References: <36784811.108860281@news.phoenix.net> Hi Peter Most people use make external IDE different from Tornado (we use CodeWright), with version control. It is a good solution that works fine. do it and enjoy your work. Saffi Peter Weatherall wrote in message <36784811.108860281@news.phoenix.net>... >Has anyone integrated Tornado with a source code version control >system ? Some IDEs have this built-in. Any ideas about what is the >best approach with Tornado... > > >Thanks >Peter --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dec Ethernet Driver? Date: Thu, 17 Dec 1998 19:44:39 GMT From: gtsang@glenayre.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <75bmv6$79n$1@nnrp1.dejanews.com> References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> In article <36778DFF.D92F63F2@ibm.net>, Dan DeVault wrote: > Wind River has a driver that works with the SENS stack. At least for > the Motorola MTX604 BSP. We are trouble shooting some problems with it > now. > > Dan DeVault > IBM Global Network > devault@ibm.net Hi Dan, We have almost the exact config (MVME604, SENS) and I am having problem bringing the driver up for DEC21143 (we did so for DEC21140). We have already found a few bugs in this "END" driver. Gilbert Tsang Glenarye R&D Inc. > > Frankie Sierra wrote: > > > I am looking for a Dec 21140, or 21143 Ethernet driver for use with > > VxWorks 5.1.3? Anyone done this? Any issues, caviats? > > > > Frankie Sierra > > sierra@teralogic-inc.com > > - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado + Version Control integration Date: Thu, 17 Dec 1998 19:37:08 GMT From: David & Bella Aldrich Message-ID: <1998121719370883839@zetnet.co.uk> References: <36784811.108860281@news.phoenix.net> <75b9fp$787$1@news.netvision.net.il> Wind River announced in a recent seminar that Tornado II will have hooks to allow 3rd party tools to interface to the development environment. They mentioned version control systems in particular. David --------------------------- Newsgroups: comp.os.vxworks,comp.realtime,misc.jobs.contract Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency Date: 18 Dec 1998 01:14:59 GMT From: Tate Consulting Organization: Tate Consulting, Inc. Message-ID: <75caaj$kaj$18@remarQ.com> Fortune 100 Company needs contractor to work on CHORUS and VxWorks Drivers and OS tuning. Refer to Job Code: JC-A10078-01. Please reference the JOB CODE listed above in any correspondence to us. Send your resume in ASCII or MSWord format to: Email: hotjobs@tateinc.com Fax: (561) 852-2385 Snail: Tate Consulting, Inc. 10647 Avenida Santa Ana Boca Raton, FL 33498 Please visit our Hi-Tech Job Database at http://www.tateinc.com Tate Consulting is a Computer Consulting and Placement Company in business since 1991. Andrew Tate, President/Owner Tate Consulting, Inc. atate@tateinc.com (561) 852-TATE (8283) We are an EOE. --------------------------- Newsgroups: comp.os.vxworks Subject: Exception: Interrupt Level 11 2ce card - 2nd request Date: Thu, 17 Dec 1998 20:36:38 -0500 From: "Albert S. Johnston" Message-ID: <3679B1A5.E8CDFA27@hom.net> >Exception: Interrupt Level 11 >program counter: 0x0002d4fc >next program counter: 0x0002d500 >processor status register: 0x904010c1 It looks like the below problem was defective hardware. But... I had noone reply to my inquiry... If one of you guru's understand this trap/exception would you please explain it to me... the discription (in the v8 arch manual) of the conditions that cause this trap seems to me to be a "normal" condition... ie one that should not cause an exception. There may be a typo in my book, or maybe I just am miss- understanding what it is saying... Would one of you guys please explain this to me... 1) is the exception being raised because ET=1 AND (IR=11) > (IPL=0) and if so, 2) what is wrong with this happening? ET=1 means traps are enabled. IPL=0 means int request levels above level 0 are enabled (which means ALL inturrupts are enabled) and IR=11 means a request at level 11 came in.... so why is that an "exception" somebody give me a clue PLEASE. more details follow... > HELP.... > > some sparc guru out there explain this to me. I am occasonally getting > the following msg > > Exception: Interrupt Level 11 > program counter: 0x0002d4fc > next program counter: 0x0002d500 > processor status register: 0x904010c1 > Task: 0xebf2c0 "rsiSvc" > > When I look this up the the arch manual, it says: > > "interrupt_level_n : an external interrupt request level (bp_IRL) > of value n was presented to the IU, while > ET=1 AND ( (bp_IRL=15) OR (bp_IRL>PIL))." > > if traps are enabled (ET=1) what in the world is wrong with > getting a level 15 (nmi) interrupt, or an interrupt that is larger > then the current PIL? PIL is defined in the manual to be > the IL ABOVE which the processor will accept the interrupt. > > Is the line " ET=1 AND ( (bp_IRL=15) OR (bp_IRL>PIL))." > a very bad typo? if so, what should it be? If not, why am I > totally confused about this???? > > Okay, the psr (shown above) decodes to ET=0 and PIL=0, > which means, according to the book, this exception CAN NOT > be raised in this situation.... what gives? What is happening???? > > thanks, > -al --------------------------- Newsgroups: comp.os.vxworks Subject: re: Multiple ethernet port - routing troubles. Date: Sun, 20 Dec 1998 22:06:21 GMT From: johnchann@home.deletethis.com (John Chann) Organization: @Home Network Message-ID: References: <199812180939.JAA21105@dsl-2.tadpole.co.uk> Good answer except... If you are using SENS you should try calling mRouteAdd() and make the subnet mask tight like 255.255.255.240 then the system will only see the last four bits as part of this subnet. IP forwarding is controlled by a variable in BSD 4.3 networking and by a bit in a control flags variable in SENS. I think the first is ipForwarding and the second is ipFlags. Try looking through usrConfig.c. Last but not least if you are using SENS you should get the SENS 1.1 update from the WRS web site (http://www.wrs.com/) which fixes a number of issues in SENS 1.0. JRC In article <199812180939.JAA21105@dsl-2.tadpole.co.uk>, David Laight wrote: >You need to read up on IP routing. > >In practise you need to: > 1) Put each interface on a system into a DIFFERENT subnet > 2) Connect each interface to a diferent physical LAN > 3) Only have one system/router linking any two subnets > A problem because I don't believe you can disable IP-Forwarding in > vxWorks. > >If you don't do the above packets will not go out the expected interfaces. > >Another possible area of confusion is that the typical Unix 'ping' does an >address to name lookup on every returned packet. Misconinfigured DNS and the >broken resolv code can cause this to take a long time. > > David >---------------------------------------------------------------- >David Laight email: dsl@tadpole.co.uk >Tadpole Technology plc phone: +44 1223 278 256 >Cambridge, UK fax: +44 1223 278 201 > --------------------------- Newsgroups: comp.os.vxworks Subject: Re: off topic question Date: Sun, 20 Dec 1998 22:19:01 GMT From: johnchann@home.deletethis.com (John Chann) Organization: @Home Network Message-ID: References: <01be2a8e$653ef520$b7c310ac@ndsuk1063> Being of an untrusting nature I have never expected to be able to recover data with a structure definition in anything execpt Ada (Oooo loveley representation clauses!) so I've always used pointers for this. I suppose you have to decide between wasted bandwidth and wasted processing. JRC In article <01be2a8e$653ef520$b7c310ac@ndsuk1063>, "Robert Stedman" wrote: >I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc >compiler for both ends. Packing structures at the target side is achieved >with __attribute__ ((packed)), however this doesn't work at the Sun side. >Any ideas on how to coerce gcc to pack structures on a Sun would be >gratefully received (#pragma pack (1) doesn't do the trick either) >Thanks >Rob. --------------------------- Newsgroups: comp.os.vxworks Subject: off topic question Date: 18 Dec 1998 13:57:50 GMT From: "Robert Stedman" Organization: NDS Broadcast, Eastleigh, UK Message-ID: <01be2a8e$653ef520$b7c310ac@ndsuk1063> I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc compiler for both ends. Packing structures at the target side is achieved with __attribute__ ((packed)), however this doesn't work at the Sun side. Any ideas on how to coerce gcc to pack structures on a Sun would be gratefully received (#pragma pack (1) doesn't do the trick either) Thanks Rob. - -- Rob Stedman NDS UK rstedman@nospamplease.ndsuk.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Target server windowsNT Date: Fri, 18 Dec 1998 17:25:02 GMT From: mark-oliver.heger@hgw.scn.de Organization: Deja News - The Leader in Internet Discussion Message-ID: <75e35a$7oi$1@nnrp1.dejanews.com> References: <366E95FF.8698382D@scanmar.no> In article <366E95FF.8698382D@scanmar.no>, Ole Asbjorn Fadum wrote: > Hi > > I could not manage to get the targetserver get the file image from the > target correctly. I've done two experiments but could not find out what > is wrong: > > 1. My host is called oaf, then if I try to start the targetserver I've > got the following errormessage: 'could not open > D:/Tornado/oaf:Tornado/target/config/pc486/vxworks' > > I though this may be that the WindowsNT, didn't like that I've called > the host (VxWorks boot parameters) for 'oaf' so I cleared the host name. > > 2. This time I've got the following error: 'could not open > D:/Tornado/Tornado/target/config/pc486/vxworks' > > The same error messages appear on both the command prompt start of the > target server and the start from the tools menu. Where did the extra > Tornado came from?? > > You have to configure your target server with the -c option. -c filename (filename specifies the path to the core file explicity) The host with the running target server must have read access to this location (local drive or mapped network drive). - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tools to track memory leaks Date: Mon, 21 Dec 1998 12:02:00 +0100 From: Roberto Nunnari Organization: AGIE Message-ID: <367E2AA8.BE3F5054@agie.ch> References: <75erfp$smr$1@nnrp1.dejanews.com> - - rtiLib from rti. They come boundled with Sthetoscope - - codeTest Robi sanavr@hotmail.com wrote: > Hi, I am working on optimizing the memory usage on an ATM interface card > running vxWorks. I would like to know whether there are any tools available > in the market to track the memory leaks and to measure the utilization of > memory on vxworks. Something similar to purify on unix. Any kind of inputs to > instrument a piece of code running under vxworks to track the memory are very > much appreciated. Thank you, Venkat > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Message Passing Interface (MPI) in VxWorks? Date: Fri, 18 Dec 1998 13:48:35 -0600 From: John Courtney Organization: General Dynamics Information Systems Message-ID: <367AB193.665D4B86@gd-is.com> The Message Passing Interface (MPI) standard specifies mechanisms for passing messages between processes on different computers. MPI is popular in the supercomputer and parallel processing community. Has anyone ported/implemented MPI to/on VxWorks? Did you start from scratch? Did you port an existing MPI suite? How long did it take? Is it publically available? Thanks, John Courtney john.l.courtney@gd-is.com General Dynamics Information Systems --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Mon Dec 21 07:56:13 1998 From: Roger Cruz Date: Mon Dec 21 07:56:16 PST 1998 Subject: Re: Booting VxWorks from hard-disk I believe this is due to the fact that vxsys places a loader in Sector 0 similar to the DOS sys cmd. Because of its small size, it can't search sub-directories looking for bootrom.sys, therefore, you need to place it in the root directory. The other possibility is that you didn't use vxcopy to copy the bootrom image generated by the compile to the hard disk correctly. Let me know if you need further help. Roger. PS: remove "_nojunk" from email address From: david.hagood@ifrsys.com I do a vxsys c:\, and it works. I copy a:bootrom.sys c:\bootrom.sys, and it works I verify that bootrom.sys is contiguous. I reboot the machine. VxLd complains that it cannot find bootrom.sys The bootrom.sys I copied over loaded fine from the floppy. vxworks, VxWorks -- Roger Cruz cruz_nojunk@xyplex.com Xyplex Networks w: 978-952-4783 295 Foster Street f: 978-952-4887 Littleton, MA 01460 From owner-vxwexplo-process Mon Dec 21 11:13:15 1998 From: Friedrich Scheurer / ZFS Date: Mon Dec 21 11:13:18 PST 1998 Subject: InterbusS under VxWorks Hello VxWorkers, is there anyone having experience with InterbusS-Interface under VxWorks and the x86-platform? We need a InterbusS-card (Master, PCI or ISA) and an acompanied driver to connect a CNC and a PLC. Are there any experiences out there? Any help appreciated! Best regards Friedrich Scheurer +-------------------------------------------------+ | | | Dipl.-Ing. F. Scheurer | | | | c/o Zentrum Fertigungstechnik Stuttgart | | Arbeitsbereich Steuerungstechnik | | Nobelstrasse 15 | | D-70569 Stuttgart | | | | Telefon +49 711 13162-41(-0) | | Fax +49 711 13162-11 | | E-Mail scheurer@zfs.rus.uni-stuttgart.de | | zfssrr@zfssun6.tz.rus.uni-stuttgart.de | +-------------------------------------------------+ | http://zfs.rus.uni-stuttgart.de | +-------------------------------------------------+ | | | privat: | | Telefon +49 7161 686362 | | Fax +49 7161 686301 | | E-Mail Friedrich.Scheurer@t-online.de | | | +-------------------------------------------------+ From owner-vxwexplo-process Tue Dec 22 04:00:24 1998 From: daemon@csg.lbl.gov Date: Tue Dec 22 04:00:28 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Dec 22 04:00:07 PST 1998 Subject: Re: off topic question Subject: Exceptions and Signals Subject: Re: Dec Ethernet Driver? Subject: Tools to track memory leaks Subject: MPC860SAR I & D Cache : Relation with memory type? Subject: HELP Please - 2604 & Console IO Subject: Re: Problem w/ Tornado 1.0.1/mv147 kernel build... Subject: Re: vxWorks.st_rom in floppy Subject: Re: man pages on NT Subject: Re: Primer ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: off topic question Date: Mon, 21 Dec 1998 08:19:17 -0500 From: Douglas Fraser Organization: Lucent Technologies Message-ID: <367E4AD5.FC3633E5@lucent.com> References: <01be2a8e$653ef520$b7c310ac@ndsuk1063> Robert Stedman wrote: > > I'm coding TCP/IP based comms between MPC860 target and a Sun, using gcc > compiler for both ends. Packing structures at the target side is achieved > with __attribute__ ((packed)), however this doesn't work at the Sun side. > Any ideas on how to coerce gcc to pack structures on a Sun would be > gratefully received (#pragma pack (1) doesn't do the trick either) > Thanks > Rob. Packed structures are non-portable across heterogeneous platforms. You are just begging for bugs if you do that. You may even find failures between different compiler release for the same processor as this attribute is wholly undefined. Also, even if you pack structures on the MPC860, depending on the structure layout, you will still have holes because the MPC860 can only access data on naturally aligned addresses. See section 14.4.5 of the MPC860 User's Manual, Motorola document MPC860UM/AD REV. 1. - -- Douglas Fraser dwfraser@lucent.com --------------------------- Newsgroups: comp.os.vxworks Subject: Exceptions and Signals Date: Mon, 21 Dec 1998 14:52:04 +0100 From: markus_mitterer@sbu1.storkgroup.com (Markus Mitterer) Organization: STK-Kufstein Message-ID: Hi VxWorkers, I could not found enough info about Exceptions and Signals in the VxWorks documentation. My target is a PPC mv2301 board. I tried to do a bus error -> I got the signal SIGILL I did a division by zero -> signal SIGILL. I do not know why I am always getting SIGILL instead of SIGFPE (floating point) or SIGBUS??? When I once save my enviroment with setjmp(), can i do several longjmp()s to this point??? I recognized that when I do the longjmp() more times I hang in the sigHandler-Routine (signal SIGILL -> "system call") Is the enviroment saved again when I come back to this position with longjmp()??? Thanks in advance Mark --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dec Ethernet Driver? Date: Mon, 21 Dec 1998 14:12:20 +0100 From: "Pierre Duval" Organization: Motorola Inc. Message-ID: <75lhn4$405$1@schbbs.mot.com> References: <36770B93.DCE5CB9A@teralogic-inc.com> <36778DFF.D92F63F2@ibm.net> <75bmv6$79n$1@nnrp1.dejanews.com> To all, For Motorola computer group boards there is a patch that can be asked to your local MCG support. It is an enhancement of the standard DEC driver. There is a new DEC21x4x driver for the PowerPlus Architecture family. This driver includes support for the dec21040, dec21140, and dec21143 chips as well as fixes a problem with the driver's cache usage. This driver still has the 100BaseT performance increases in BOTH directions, supports Full Duplex and includes additional enhancements. Hope that helps Khoa wrote in message ... >gtsang@glenayre.com wrote in message <75bmv6$79n$1@nnrp1.dejanews.com>... >>We have almost the exact config (MVME604, SENS) and I am having problem >>bringing the driver up for DEC21143 (we did so for DEC21140). We have >already >>found a few bugs in this "END" driver. >>Gilbert Tsang >>Glenarye R&D Inc. > > >So does anyone know whether VxWorks has an updated patch for the driver or >acknowledged this problem in an SPR? > >Khoa > > --------------------------- Newsgroups: comp.os.vxworks Subject: Tools to track memory leaks Date: Sat, 19 Dec 1998 00:20:10 GMT From: sanavr@hotmail.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <75erfp$smr$1@nnrp1.dejanews.com> Hi, I am working on optimizing the memory usage on an ATM interface card running vxWorks. I would like to know whether there are any tools available in the market to track the memory leaks and to measure the utilization of memory on vxworks. Something similar to purify on unix. Any kind of inputs to instrument a piece of code running under vxworks to track the memory are very much appreciated. Thank you, Venkat - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: MPC860SAR I & D Cache : Relation with memory type? Date: Mon, 21 Dec 1998 23:39:16 GMT From: newsmine@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <75mm74$134$1@nnrp1.dejanews.com> Hi All, I am trying to activate the data and instruction caches on my MPC860SAR board. I was wondering if anybody could share their experience with me on that. A few questions I have are : 1.The ADS BSP we have has a couple of lines like #ifdef EDO_DRAM undef USER_I_CACHE_ENABLE undef USER_D_CACHE_ENABLE undef INCLUDE_CACHE_SUPPORT #endif /* EDO_DRAM */ What is the relationship between DRAM type and turning on the caches? Why should the cache activation be restricted to SDRAM type of DRAM only? 2.A post earlier in this group mentioned that the caches must be disabled initially and activated only from bootConfig.c or usrConfig.c. Why? 3.What areas of memory need to be excluded from caching on MPC860SAR? Only the on-chip DPRAM or something else too? How do I specify these areas in VxWorks? 4.Is it sufficient to define these macros in config.h and rebuild the BSP? #define USER_I_CACHE_ENABLE #define USER_D_CACHE_ENABLE #define INCLUDE_CACHE_SUPPORT 5.Any performance indicators I may use to determine the speed-up gain? Thanks a lot in anticipation. Regards, Mittal - -- Mittal Monani Spacebridge Networks Corporation Hull J8X 3R1 - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: HELP Please - 2604 & Console IO Date: Sat, 19 Dec 1998 10:10:33 -0500 From: Peter Message-ID: <367BC1E9.8CDED908@metrolink.net> First, I have been browsing this NG for a few months now when I get the opportunity. Unfortunately, I am not able to view this (or any other newsgroup) while at work. As a result I am not able to view this NG as often as I would like. The posts that I have seen here when I do get the opportunity are informative and have helped. I am very new to working with VxWorks (3 months) and am continuously coming across questions alot of which I get answers (or ideas) from posts here. I cannot name all of the sources (names) that have provided information that has helped, but I would like to express my thanks to all those who provide information to this NG. With that being stated, to lead into my question, here is some background information. H/W configuration: Motorola MVME-2604 PPC SBC DY-4 SVME 739 Serial I/F Card Macrolink MVCP Serial I/F Card BrandyWine IRIG-B I/F Card Carroll Touch Touch Screen Display. The Carroll Touch Display that we are using is a serial device (RS-232) that emulates a VT320 terminal with additional capabilities for using the touch screen. This display is connected to the console port (COM1) and is intended to also serve as the console. The project team is currently leaning towards having two tasks oriented to the user display, one to handle the displaying of the data, and the second for the processing of user inputs. Our current implementation is turns OFF the terminal echo using the ioctl funtion with the OPT_TERMINAL and ~OPT_ECHO flags. Both tasks are spawned at the same priority level and utilizing Mutual Exclusion semaphores. The display routine will be providing continuous data updates during the real-time processing function of the application, while at the same time providing user feedback for user inputs whether it be by keyboard input or touch screen activation. Question/request for suggestion(s): What would be the "best" way for working with the serial ports for handling this? Does anyone have any examples that they can provide? Please respond to my e-mail address in addition to a NG post. I do not get to view the NG very frequently and would really appreciate receiving the information. Thank you in advance. And, best wishes for this holiday season and for the new year. - -- Peter - ----------------------------------------------- E-mail: funonh2o@metrolink.net (home) - ----------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Problem w/ Tornado 1.0.1/mv147 kernel build... Date: 19 Dec 1998 20:47:43 GMT From: fnordz@aol.com (Fnordz) Organization: AOL http://www.aol.com Message-ID: <19981219154743.14014.00001855@ng26.aol.com> References: <3674C43C.A10C8220@uma.com> You should check out the configdb.h file produced by WindCFG. configdb.h is #included at the end of config.h. After inspecting configdb.h, you may find that you have accidentally undefined some RTOS component needed to boot the image. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: vxWorks.st_rom in floppy Date: 19 Dec 1998 20:55:16 GMT From: fnordz@aol.com (Fnordz) Organization: AOL http://www.aol.com Message-ID: <19981219155516.14014.00001859@ng26.aol.com> References: <3668D8BE.CDD4381B@aucoasia.com> It was not clear in your posting whether you attempted the multi-stage boot - bootrom_uncmp loads vxWorks. Have you tried this? In other words, let the ROM BIOS use bootrom_uncmp as the boot loader. bootrom_uncmp should be able to boot a rather large vxWorks image. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: man pages on NT Date: 19 Dec 1998 21:10:23 GMT From: fnordz@aol.com (Fnordz) Organization: AOL http://www.aol.com Message-ID: <19981219161023.20337.00001921@ng25.aol.com> References: <3677E360.3E88304C@west.raytheon.com> Just taking a wild guess, but you could try using MKS ToolKit, or try the Cygwin32 Beta 20 (free download from www.cygnus.com). Both of these packages contain utilities which would commonly be used to create and view UNIX style man pages, and both packages run on Win32 machines (95 and NT). --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Primer Date: 19 Dec 1998 21:22:40 GMT From: fnordz@aol.com (Fnordz) Organization: AOL http://www.aol.com Message-ID: <19981219162240.20337.00001931@ng25.aol.com> References: <74rfco$jof@bgtnsc02.worldnet.att.net> The following are some of the more commonly available resources: 1. The "VxWorks Programmer's Guide" which comes with Tornado / VxWorks. 2. Tornado Classes taught by WRS - your mileage may vary, as the class does not exclusively cover vxWorks API; WRS development tools are also discussed 3. If you have purchased support, you can access an archive of vxWorks demo code on the "WindSurf" page (www.wrs.com->support link) 4. Publicly available archives of vxWorks code at: ftp://ftp.atd.ucar.edu/pub/vxworks/vx/ http://www.pso.com/vxhacks.html --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Tue Dec 22 05:44:45 1998 From: =?iso-8859-1?Q?Ro=DFmy_Reinhard____ICN_CM_E?= Date: Tue Dec 22 05:44:48 PST 1998 Subject: Tornado with NetROM Hallo, I am very unhappy about the support of WindRiver System, so I use this way to solve my "Tornado with NetROM" problem. The Tornado target agent can be configured to communicate with the target server using the NetROM. But in my case, the target server fails to connect to the target. My question is whether anyone else has seen this, and more importantly could such a problem be solving. Could it be a problem, that the configuration of the memory is: RAM start at the address 0x0 ROM (Flash 29f040) start at the address 0x200000 Thanks, Reinhard Roßmy ICN CM WE 322 Phone: +49-89-722-32633 FAX: +49-89-722-32541 mailto:Reinhard.Rossmy@icn.siemens.de From owner-vxwexplo-process Tue Dec 22 07:37:20 1998 From: MacroSystem_FE_trahn@t-online.de (Thomas Rahn) Date: Tue Dec 22 07:37:23 PST 1998 Subject: AW: Booting VxWorks from hard-disk just one more idea: in the request, David mentioned he "created the file system from VxWorks, so it ought to be a configuration that VxWorks likes." That is a very optimistic approach.... Check out the boot block of your dos partition (not the MBR). You must know where the partiton starts (offset in sectors). The Windriver partition demo software from the ftp-server will tell you. // read boot sector of partition partAtaLbaRW (ctrl, drive, offset, (UCHAR*)secBuf, O_RDONLY); After using dosFsVolFormat(...) to format the partition, the data in secbuf[] it should be similar to 00 3 bytes e9xxxx / ebxx90 jmp entry = eb 3c 90 03 8 bytes OEM Name = "VXDOS516" 0b 2 bytes Bytes per sector = 0x0200 = 512 0d 1 byte Sektoren pro Cluster = 2 0e 2 byte Reserved sectors (boot record) = 2 10 1 byte Anzahl der FATs = 2 11 2 bytes Anzahl der Root-Verz.einträge = 0x0200 = 512 13 2 bytes Anzahl der logischen Sektoren = 0xa035 15 1 byte Media-Byte = 0xf8 (Festplatte) 16 2 bytes Sektoren pro FAT = 0x0051 18 2 bytes Sektoren pro Spur = 0x003f = 63 1a 2 bytes Anzahl Köpfe = 0x0010 1c 2 bytes Hidden Sectors (Part. Offset) = ????? Maybe the entry at 0x1C is zero, then we are on the right track. The function ataDevCreate(ctrl, drive, 0, offset) is designed to use an offset. The ATA device is intended to use several partitions. However, the dosFs from Windriver assumes, it resides on a disk from the start on, not on a partition. That's why dosFsVolFormat() *clears* the Hidden Sectors entry. Try this: // this is the offset of the partition to the start of the disk (ULONG*)(secBuf[DOS_BOOT_NHIDDEN_SECS])= offset; // write back boot sector of partition partAtaLbaRW (ctrl, drive, offset, (UCHAR*)secBuf, O_WRONLY); Anyway: partAtaLbaRW uses ataRawio() similar to the function used in the WRS demo code (look it up at the ftp server) Happy Xmas #=================================================# # MS MacroSystem GmbH Thomas Rahn # # Forschung und tel: +49(0)6151-272576 # # Entwicklung fax: +49(0)6151-272577 # # email: trahn@macrosystem.de # #=================================================# From owner-vxwexplo-process Tue Dec 22 08:19:01 1998 From: Sergi Casas Date: Tue Dec 22 08:19:04 PST 1998 Subject: Re: Tornado with NetROM Reinhard Roßmy wrote: > The Tornado target agent can be configured to communicate with the > target server using the NetROM. > But in my case, the target server fails to connect to the target. > > My question is whether anyone else has seen this, and more importantly > could such a problem be solving. NetROM is a very nice idea with a rather poor implementation. Its firmware has some bugs (at least when I used it 1 year ago) that can make you crazy (beware with the dual port base address command, I recommend to put DualPort Mem in ROM offset 0 to avoid confusions), the supplied drivers need a lot of tweaking for some concrete architectures because of NetROM dual port memory contention problems, and the manuals are poor and contain many errors. I would encourage you to try to solve these "minor" problems, because when it works it is very useful in deeply embedded systems with no ethernet ports. Depending on the architecture, the interrupt priorities mapping, and the write protocol you may have very different problems; could you specify your system? For example, I played with an i960JX, with some interrupts in priorities beyond the OS intLockLevel (this is important!), and using read-read protocol. > > > Could it be a problem, that the configuration of the memory is: > RAM start at the address 0x0 > ROM (Flash 29f040) start at the address 0x200000 No, I cannot see any problem with that. Cheers. -- |===========================================================================| | Sergi Casas ##### / ##### Software Engineer (R&D) | | Hewlett-Packard ### /_ _ ### | | Barcelona Division (BCD) ## / / / / ## mailto:sergi@bpo.hp.com | | Avda. Graells, 501 ## / / /_/ ## | | 08190 S. Cugat (Barcelona) ### / ### | | SPAIN ##### / ##### | |===========================================================================| | "The question of whether a computer can think is no more interesting than | | the question of whether a submarine can swim." E. W. Dijkstra | |===========================================================================| From owner-vxwexplo-process Tue Dec 22 09:17:32 1998 From: Bill Pringlemeir Date: Tue Dec 22 09:17:35 PST 1998 Subject: Re: man pages on NT The following message is a courtesy copy of an article that has been posted as well. The Tornado man pages I have xxxx.1 use the groff program to create pages in a displayable form. I think that Linux/GNU is going toward 'Info' pages. They use 'tex' as source instead of groff. MKS toolkit doesn't come with any (rof/troff/groff) tool. I _believe_ the same is true for cygwin? I have tried to format these on HP-UX, but was unable to get pages that displayed well with MKS man program (actually more). I found that looking at the unformatted 'groff' files in emacs was pretty good. Emacs automatically syntax highlights them. Is the 'tex-info' format being used on Solaris, HP-UX, etc. I would think that this would be a better format for WindRiver to use in the long run. There are many possible output formats from tex-info; HTML, pdf, post-script, dvi, info, plain ascii, maybe even word (yech). Maybe WR will switch to the tex-info format. Bill fnordz> Just taking a wild guess, but you could try using MKS fnordz> ToolKit, or try the Cygwin32 Beta 20 (free download from fnordz> www.cygnus.com). Both of these packages contain utilities fnordz> which would commonly be used to create and view UNIX style fnordz> man pages, and both packages run on Win32 machines (95 and fnordz> NT). -- Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/" From owner-vxwexplo-process Tue Dec 22 09:25:17 1998 From: Bill Pringlemeir Date: Tue Dec 22 09:25:20 PST 1998 Subject: ARM target and ARM compiler? The following message is a courtesy copy of an article that has been posted as well. Does the compiler from ARM work with VxWorks? I have heard that it generates the best code for that platform. The Green Hills compiler seems to support more C++ functionality than either 'gcc' or ARM, and it includes the EC++ libraries. Does anyone have experiences with using the ARM or Green Hills compiler on an ARM target? I got the DIAB compiler to work with the the MPC821 and VxWorks. DIAB gave better performance than the supplied GCC. Does anyone know if WR will ever use the EGCS compiler. EGCS has a better backend to do instruction scheduling. This is one of the reasons gcc performs worse on ARM/PowerPC (RISC). I did find that gcc was better than the MRI compiler we have on a 68k processor. Thanks, Bill -- Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/" From owner-vxwexplo-process Wed Dec 23 04:00:20 1998 From: daemon@csg.lbl.gov Date: Wed Dec 23 04:00:24 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Dec 23 04:00:08 PST 1998 Subject: malloc() hanging with VxWorks on i960 platform Subject: ARM target and ARM compiler? Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Subject: Re: PC16550D UART drivers? Subject: What happens to command line arguments? Subject: Re: What happens to command line arguments? Subject: Wind River User Group Subject: VME Interrupts to MVME162 Subject: Re: What happens to command line arguments? Subject: 68040 sensitivity to reads of FPSR ??? Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Subject: Internet Resources Subject: Re: DDD For Tornado/vxWorks? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: malloc() hanging with VxWorks on i960 platform Date: Tue, 22 Dec 1998 12:13:26 GMT From: "Derek Syme" Organization: Libra Syscom Ltd Message-ID: <01be2da3$9ec6cb20$24b2dec2@server_1> Hi, We have an i960 based embedded system (64Mb RAM) running VxWorks. We have seen occassional hangs in the call to malloc() when asking for a large area of RAM (typically 20ish Mb). The call does not fail, it simply hangs forever. We are fairly sure that there is sufficient RAM available before malloc() is called and it should be available in a single contiguous block. Does anyone else have any experience of this problem and if so are there any known fixes or workarounds? Thanks in advance, Mark Kobine --------------------------- Newsgroups: comp.os.vxworks Subject: ARM target and ARM compiler? Date: 22 Dec 1998 12:19:24 -0500 From: Bill Pringlemeir Organization: PSINet Message-ID: Does the compiler from ARM work with VxWorks? I have heard that it generates the best code for that platform. The Green Hills compiler seems to support more C++ functionality than either 'gcc' or ARM, and it includes the EC++ libraries. Does anyone have experiences with using the ARM or Green Hills compiler on an ARM target? I got the DIAB compiler to work with the the MPC821 and VxWorks. DIAB gave better performance than the supplied GCC. Does anyone know if WR will ever use the EGCS compiler. EGCS has a better backend to do instruction scheduling. This is one of the reasons gcc performs worse on ARM/PowerPC (RISC). I did find that gcc was better than the MRI compiler we have on a 68k processor. Thanks, Bill - -- Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/" --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Date: Tue, 22 Dec 1998 10:48:25 -0800 From: Scott Johnson Organization: National Association for the Advancement of Computer Geeks Message-ID: <367FE979.7BA0@nospam.aracnet.com> References: <75mm74$134$1@nnrp1.dejanews.com> Reply-To: sj_nospam@nospam.aracnet.com newsmine@my-dejanews.com wrote: > > Hi All, > > I am trying to activate the data and instruction caches on my MPC860SAR board. > I was wondering if anybody could share their experience with me on that. A few > questions I have are : > > 1.The ADS BSP we have has a couple of lines like > > #ifdef EDO_DRAM > undef USER_I_CACHE_ENABLE > undef USER_D_CACHE_ENABLE > undef INCLUDE_CACHE_SUPPORT > #endif /* EDO_DRAM */ Don't know about EDO ram in particular (and I can't think of any reason why caching would NOT work with EDO)... However, early version of the 860 family (mask revision A and B) have caches that don't work. It is possible (PURELY speculation on my part) that ADS boards with EDO ram also have these earlier processors... Also, one of the errata related to the caches might be affected by EDO ram. Again, don't know for sure; go to Motorola's website if you want to look at the errata. (VERY important thing to do if you are porting VxWorks to a custom board...) > What is the relationship between DRAM type and turning on the caches? > Why should the cache activation be restricted to SDRAM type of DRAM > > only? Other than erratas, there should be no reason. Memory that cannot be cached ain't very useful, after all... > 2.A post earlier in this group mentioned that the caches must be > disabled initially and activated only from bootConfig.c or > usrConfig.c. Why? That is how the processor turns on, for one thing--with caches disabled. (Also, the caches are uninitialized, which is why romInit.s makes SURE they are disabled.) For another thing, proper cache operation also requires that the MMU be turned on. VxWorks does not enable the MMU until after quite a few other things happen. (You can run the caches without the MMU, but the only way to do so safely is to mark all of storage as "guarded"; which kills system performance.) > 3.What areas of memory need to be excluded from caching on MPC860SAR? > Only the on-chip DPRAM or something else too? How do I specify these > areas in VxWorks? There is a data structure in sysLib.c called sysPhysMemDesc, which is where you define the memory layouts of your board. (Did you get the BSP developers kit??? The documentation explains all this stuff-sort of.) As far as caching strategy goes...in general, RAM should be cached--unless it is an area of RAM being shared between more than one processor, or otherwise being read to or written from by something else other than the CPU. (This does not include other things internal to the CPU, such as the SCC---external RAM accessed by the SCC may be safely cached). The 860 family does not have support for bus snooping; so there is no way for an external bus master to know if memory it touches is up-to-date, or to mark it dirty. So turn off cacheing for any such memory. For ROM (direct access), it depends on how you use it. If you run directly out of ROM, turn on the cache for ROM. If all you do is use ROM as a boot device and then run out of RAM, it doesn't matter--the cache is disabled at this point anyway. :) (Major surgery on your BSP nonwithstanding.) If you use ROM as a filesystem only... I'd do some performance testing to verify this, but I suspect that this will run faster with cacheing off. If you have FLASH EEPROM, and should want to reprogram it, disable the cache before doing so. (Better yet, keep the storage as uncached.) Any area of memory which is used to map registers should be uncached and guarded. > 4.Is it sufficient to define these macros in config.h and rebuild the BSP? > #define USER_I_CACHE_ENABLE > #define USER_D_CACHE_ENABLE > #define INCLUDE_CACHE_SUPPORT To tun on the cache? In general, yes. But you ought to be turning on the MMU as well, and that requires modifying the sysPhysMemDesc structure. And, if you have revision A or B silicon, you ought not be turning on the cache at all. (At least not the D cache; the instruction cache also does have an error, but it is VERY rare.) > 5.Any performance indicators I may use to determine the speed-up gain? There is a package on the Motorola website which talks about optimizing the performance of the caches; it also includes some (primitive) benchmarking software. (This software only verifies that the CPU is operating as it should be; it doesn't determing whether cacheing or not is faster for YOUR application.) Don't have the specific URL handy, but it is in the "application notes" section of the 860 page. Hope this helps, Scott > Thanks a lot in anticipation. > > Regards, > Mittal > > -- > Mittal Monani > Spacebridge Networks Corporation Hull J8X 3R1 > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: PC16550D UART drivers? Date: 22 Dec 1998 19:59:52 +0100 From: jusa@bbn.hp.com (Juergen Sang) Message-ID: <367fec28.0@isoit370.bbn.hp.com> References: <366410CC.2AF5661@orbitworld.net> George Pontis (geo@z9.com) wrote: George, : You will find lots of serial drivers if you search the net for PC source : code. Almost all PCs built in the past five years use this UART or one : that is software-compatible with it. The drivers are a little tricky, but : I have seen several articles with example code. The "C User's Journal" : had a feature article with source in C several years ago. I'm sure there The folks at Windriver supplied us with a 16550 FIFO driver once we asked them for it. It is not in the standard distribution, though. - -- Cu, Jürgen - ------------------------------------------------------------------ Jürgen Sang Phone +49-7031-14-8929 Hewlett Packard GmbH FAX +49-7031-43-0349 Optical Communication Measurement Herrenberger Str. 130 71034 Böblingen WWW (HP internal access) Germany http://bidro63.bbn/~jusa - ------------------------------------------------------------------ Geschaeftsfuehrer: Joerg Menno Harms (Vorsitzender), Hans-Guenter Hohmann, Heribert Schmitz, Fritz Schuller, Rudi Speier Vorsitzender des Aufsichtsrates: Franz Nawratil Sitz der Gesellschaft: Boeblingen - Amtsgericht Boeblingen HRB 4081. - ------------------------------------------------------------------ --------------------------- Newsgroups: comp.os.vxworks Subject: What happens to command line arguments? Date: 22 Dec 1998 20:53:15 GMT From: rmd@swl.msd.ray.com (Regina DuBord {84134}) Organization: Raytheon Company Message-ID: <75p0rr$j3v$1@swlmail.msd.ray.com> Hi, I have a conventional C program with a 'main' function that takes command line arguments (i.e., its prototype is main(argc, char *argv[])). It runs ok when I don't specify any arguments, but when I do, the arguments seem to go to never- never land and I don't know how to access them in my program. For example, the first line of code in 'main' is a debug statement that prints the value of argc. Without any command line arguments, I get: - -> main argc is 0 If I add an argument, I get: - -> main "-b" argc is 28858832 Or if I take away the quotes, I get: - -> main -b argc is -1751164 These values of argc are obviously garbage. If I try to print out the associated argv's, I get a data access exception. Does anybody know what happens to command line argu- ments in VxWorks??? They certainly don't seem to get assigned to argv in a C program, though I haven't found *any* documentation about this. Arrrgh (tearing my hair out, etc....) Regina - -- - ------------------------------------------------- Regina DuBord, Software Engineer Advanced Modeling & Simulation Technology Raytheon Systems Company 50 Apple Hill Dr. (T3MJ21) Tewksbury, MA 01876 Voice: (978) 858-4787 Fax: (978) 858-4336 rmd@swl.msd.ray.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: What happens to command line arguments? Date: Tue, 22 Dec 1998 23:01:22 GMT From: bruce@CUTMEOUTscimisys.com (Bruce Wedding) Organization: NeoSoft, Inc. Message-ID: <36822455.9388285@news.neosoft.com> References: <75p0rr$j3v$1@swlmail.msd.ray.com> On 22 Dec 1998 20:53:15 GMT, rmd@swl.msd.ray.com (Regina DuBord {84134}) wrote: >Does anybody know what happens to command line argu- >ments in VxWorks??? They certainly don't seem to get >assigned to argv in a C program, though I haven't found >*any* documentation about this. Arrrgh (tearing my hair >out, etc....) This won't work. If you need command line args, you will have to pass them in just like VxWorks does in taskSpawn() and other places. In DOS or *NIX, the startup code processes the arguments and passes them in. You don't have that luxury here. Bruce Wedding Software Manager bruce@scimisys.com Scientific MicroSystems, Inc. http://www.scimisys.com Tomball, Texas --------------------------- Newsgroups: comp.os.vxworks Subject: Wind River User Group Date: Tue, 22 Dec 1998 18:30:06 -0500 From: "Michael McGarry" Message-ID: <75pa4j$s9a$1@news.eclipse.net> Hello fellow VxWorks users, Does anyone know of any Wind River User Groups in New Jersey? If so, I would be interested in joining. - -- Regards, Michael McGarry, Firmware Engineer II Cabletron Systems, Inc. (732) 394-6041 --------------------------- Newsgroups: comp.os.vxworks Subject: VME Interrupts to MVME162 Date: Tue, 22 Dec 1998 16:00:47 -0800 From: David Morris 222-7450 Organization: TRIUMF Message-ID: <368032AF.90F2FEB8@triumf.ca> Hello When all else has failed, ask the experts. I'm trying the get interrupts from a VME motor module to show up under VxWorks 5.2 The module generates IRQ5, I can see this on a bus monitor module. I have the intConnect function to attach my ISR to the particular vector, but all I get is a reboot. Arghh! Here's the code to get ints going. My vector is 180, for whatever reason, but it should be valid. If I enable the interrupt in the VMEchip, the system crashes. I suspect the vector is not working right, since all the ISR does is call logMsg right now. I can read the vector in the vector register on the board, so its OK. *pbdItem->pVectorRegister = sVector; if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR) omsInterrupt, (int) pbdItem)) return OMS_ERROR_INTERRUPT; piVMEChip2 = (unsigned int *) 0xfff4006C; *piVMEChip2 = 0x10; omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS); Can anyone give me an idea of what is missing here? The lack of simple information on Windserve or anywhere else is starting to get rather frustrating. - -- David B Morris TRIUMF Systems Designer/Analyst Canada's National Meson Facility cadfael@triumf.ca 4004 Wesbrook Mall 604-222-7450 Vancouver, B.C. V6T 2A3 "Remember, no matter where you go, there you are." - Buckaroo Banzai --------------------------- Newsgroups: comp.os.vxworks Subject: Re: What happens to command line arguments? Date: 23 Dec 1998 02:02:07 GMT From: litwin@litwin (Todd Litwin) Organization: Jet Propulsion Laboratory - Pasadena CA Message-ID: <75piuv$6ai@netline.jpl.nasa.gov> References: <75p0rr$j3v$1@swlmail.msd.ray.com> Regina DuBord {84134} wrote: >I have a conventional C program with a 'main' >function that takes command line arguments >(i.e., its prototype is main(argc, char *argv[])). As any number of experienced VxWorksers can tell you, there is nothing special about a function called main() in VxWorks. It's just another function, and it will get passed arguments the same way as any other. Thus when you do >-> main "-b" the system passes the pointer to the string "-b" as the first argument of main. >argc is 28858832 This is the address of "-b". If you want to do something more like the execution of a program from the C-Shell in Unix, for example, you need to do alot more. Below is one simple way of doing some of what you want. But be warned that you *cannot* just take an arbitrary Unix program, compile it for VxWorks, and expect it to work in general. There are all kinds of things to trip you up (compile-time-initialized variables, calling exit(), etc.). Good luck. /****************************************************************************** * * * C M D * * * * Todd Litwin * * Written: 21 Nov 1989 * * Updated: 21 Nov 1989 * * * ******************************************************************************* This function is used under VxWorks to call a program that has been written with a main() function that expects command-line arguments. */ cmd(arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10) char *arg1, *arg2, *arg3, *arg4, *arg5, *arg6, *arg7, *arg8, *arg9, *arg10; { int argc, i; char *argv[11], **p; /* Initialize the program argument */ argc = 1; argv[0] = ""; /* Fill the list with the pointer values */ argv[1] = arg1; argv[2] = arg2; argv[3] = arg3; argv[4] = arg4; argv[5] = arg5; argv[6] = arg6; argv[7] = arg7; argv[8] = arg8; argv[9] = arg9; argv[10] = arg10; /* Determine the number of arguments */ p = argv + 1; for (i=0; i<10; i++,p++,argc++) if (*p == 0) break; /* Call the main function */ main(argc, argv); return 0; } - -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 Todd.E.Litwin@jpl.nasa.gov --------------------------- Newsgroups: comp.os.linux.m68k,comp.os.vxworks,comp.sys.m68k Subject: 68040 sensitivity to reads of FPSR ??? Date: Wed, 23 Dec 1998 05:24:17 GMT From: "Don Bockenfeld" Organization: FlashNet Communications, http://www.flash.net Message-ID: <01be2e34$9dbdeec0$63cbc2d0@oemcomputer> I am cross-posting this message to comp.os.linux.m68k, comp.os.vxworks, and comp.sys.m68k; as well as sending it to Motorola technical support. Once I get our maintenance contract straightened out I will also send it to Wind Rivers technical support. Up until recently we have been using XC68040 chips [prototype 68040s] in our embedded systems. Ignoring for a moment the advisability of doing this, we have discovered an odd variation in behavior between CPU lots. In the old days (up until about 4 weeks ago) everything worked fine. Then we started using a newer lot of XC68040 chips and encountered two discrepancies: 1. Our CPU BIT [built-in test] detected that the seven unused bits of the FPSR could no longer be written to and read back. The newer CPUs only read back zeroes for these bits regardless of what we wrote to them. No big deal, we revised the CPU test to not check those bits. I'm not worried about this discrepancy, but only include it in case it helps in figuring out the following mystery... 2. We use version 5.2 of the vxWorks RTOS from Wind River Systems, which includes their variant of the FPSP. We implemented a custom BSP for our system. It intermittently, but almost always, locked up during its startup procedure after we installed the newer CPU chips. This startup code is part of the vxWorks object library and is currently a black box to us. We eventually determined that a single read of the FPSR at the beginning of our reset exception handler permitted vxWorks to start up normally. Furthermore, we found that a software reset of the FPU (via FRESTORE of a longword zero) after the dummy FPSR read caused the subsequent vxWorks startup to lock up again; and that a second dummy FPSR read after the FPU software reset permitted normal startup! My unsupported hypothesis is that FPU initialization, whether due to hardware or software reset, does not complete properly until after the first read of the FPSR. At this point we felt that the obvious solution to our problem was to get rid of these XC68040 chips and start using real MC68040s. We were amazed and dismayed to find that brand new MC68040 chips exhibited both of these problems with precisely the same symptoms. I can find nothing in the M68040 Microprocessors User's Manual (M68040UM/AD Rev. 1) to suggest that reading FPSR does anything to affect the state of the CPU. Does anybody out there know what is going on? Here are the identifications of the 68040 chips involved: Original XC chips tht seemed to work fine: XC68040RC25 20D43B DENF9110 Recent XC chips that exhibited the problems: (the print was very tiny so I might be mistaken) XC68040RC25B 09D50D DEHM9152 Current MC chips that also exhibit the problems: MC68040RC25 02E42K QQBF9814A --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Date: Tue, 22 Dec 1998 23:14:48 -0800 From: Scott Johnson Organization: National Association for the Advancement of Computer Geeks Message-ID: <36809868.1E4F@nospam.aracnet.com> References: <75mm74$134$1@nnrp1.dejanews.com> <367FE979.7BA0@nospam.aracnet.com> <75ppc8$isj$1@nnrp1.dejanews.com> Reply-To: sj_nospam@nospam.aracnet.com john@kivala.com wrote: > > In article <367FE979.7BA0@nospam.aracnet.com>, > sj_nospam@nospam.aracnet.com wrote: > > newsmine@my-dejanews.com wrote: > ... > > ... > > As far as caching strategy goes...in general, RAM should be > > cached--unless it is an area of RAM being shared between more than one > > processor, or otherwise being read to or written from by something else > > other than the CPU. (This does not include other things internal to the > > CPU, such as the SCC---external RAM accessed by the SCC may be safely > > cached). The 860 family does not have support for bus snooping; so > > there is no way for an external bus master to know if memory it touches > > is up-to-date, or to mark it dirty. So turn off cacheing for any such > > memory. > ... > > > I don't think the above is right. I think the CPM devices > (including SCCs) are external as far as caching is concerned, > so if your CPM devices use external memory, the memory should > either be noncacheable or you should take care of caching > issues manually. If you are right, and I am wrong...that might explain one annoying bug we have been facing on our BSP... :) > Perhaps some of you other 860 regulars could concur or > straighten me out? Yes, please do. Scott --------------------------- Newsgroups: comp.os.vxworks Subject: Internet Resources Date: Mon, 21 Dec 1998 12:03:32 -0800 From: Nina Pinto Organization: InterNex Information Services 1-800-595-3333 Message-ID: <367EA994.E2BA8A5E@eg3.com> Pertinent to comp.os.vxworks, EG3 maintains a list of realtime Internet resources, including FAQ's, papers, hot list pages, potential software/shareware, all known companies, etc. Specific pages are located at: http://www.eg3.com/real/index.htm http://www.eg3.com/realv/index.htm These resource pages are published as part of EG3's Free Electronic Engineers' Toolbox at: http://www.eg3.com/index.htm If you know of other resources, pertinent to comp.os.vxworks please email me at: ninapint@hotmail.com Thanks! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: DDD For Tornado/vxWorks? Date: Wed, 23 Dec 1998 09:57:52 +0100 From: Chris Hellwig Message-ID: <3680B090.C2EF2198@exp.bessy.de> References: <367BBBDD.66F40902@hex.net> "Peter A. Koren" wrote: > > Hi, > > I saw a reference to DDD being available for Tornado/vxWorks > recently, but I can't find the copy I thought I made. Can > anybody steer me to the DDD info. > > Thanks, > > Peter Koren > > -- > Remove the 'zap-this' from the email address to reach me. > > "One may proceed from absurd premise to ridiculous > conclusion with impeccable > logic." -- Santayana Yes, I'm using ddd with /opt/ddd/bin/ddd -debugger "vxgdb68k -fullname" where vxgdb68k the GNU-dbg for vxWorks is. You have to find a task tRdbTask _rdbTask f9ff20 20 PEND 6fb74 f9fe00 0 0 in your task list at the vxWorks-system. Bye Chris --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Wed Dec 23 06:19:29 1998 From: Fred Roeber Date: Wed Dec 23 06:19:32 PST 1998 Subject: Re: comp.os.vxworks newsdigest Dave Morris wrote: > I'm trying the get interrupts from a VME motor module to show up under > VxWorks 5.2 > > The module generates IRQ5, I can see this on a bus monitor module. I > have the intConnect function to attach my ISR to the particular vector, > but all I get is a reboot. Arghh! This sort of sympton could be caused by external hardware continuously generating interrupts. A lot of peripherals need to have some control register twiddled to clear a pending interrupt condition. This is normally done in the interrupt handler. If you don't do this, then the signal will keep causing new interrupts and the system will reboot due to a work queue overflow. Normally, it will try to print a message to this affect but if your boards serial interrupt priority is lower than level 5 then that won't show up either. Just a thought. Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | | TraceMaker product manager -> www.tracemaker.bbn.com | From owner-vxwexplo-process Wed Dec 23 09:26:52 1998 From: johill@lanl.gov (Jeff Hill) Date: Wed Dec 23 09:26:55 PST 1998 Subject: RE: comp.os.vxworks newsdigest vxWorks tornado > Newsgroups: comp.os.vxworks > Subject: VME Interrupts to MVME162 > Date: Tue, 22 Dec 1998 16:00:47 -0800 > From: David Morris 222-7450 > Organization: TRIUMF > Message-ID: <368032AF.90F2FEB8@triumf.ca> > > Hello > When all else has failed, ask the experts. > > I'm trying the get interrupts from a VME motor module to show up under > VxWorks 5.2 > > The module generates IRQ5, I can see this on a bus monitor module. I > have the intConnect function to attach my ISR to the particular vector, > but all I get is a reboot. Arghh! > > Here's the code to get ints going. My vector is 180, for whatever > reason, but it should be valid. If I enable the interrupt in the > VMEchip, the system crashes. I suspect the vector is not working right, > since all the ISR does is call logMsg right now. I can read the vector > in the vector register on the board, so its OK. > > *pbdItem->pVectorRegister = sVector; > > if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR) > omsInterrupt, (int) pbdItem)) > return OMS_ERROR_INTERRUPT; > > piVMEChip2 = (unsigned int *) 0xfff4006C; > *piVMEChip2 = 0x10; > > omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS); > > Can anyone give me an idea of what is missing here? The lack of simple > information on Windserve or anywhere else is starting to get rather > frustrating. Here are some possible causes of trouble: 1) You are not accessing the register in the OMS indexer that clears the interrupt in your interrupt service routine. 2) Your IACK daisy chain is incomplete. If there are any empty slots between your OMS stepper motor module and the CPU make certain that the IACK daisy chain jumper has been installed for these slots on the backplane. 3) I cant comment on your change to the default VME Chip II configuration as I don't which register you are writing to, but it is normally not necessary to use anything other than sysIntEnable() to enable VME interrupts in a vxWorks system. There is an OMS stepper motor indexer device driver in the EPICS source distribution. Rolf Keitel at Triumf has a copy. Jeff ______________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos NM 87545 USA FAX 505 665 5107 From owner-vxwexplo-process Wed Dec 23 09:27:05 1998 From: johill@lanl.gov (Jeff Hill) Date: Wed Dec 23 09:27:08 PST 1998 Subject: RE: comp.os.vxworks newsdigest > Newsgroups: comp.os.vxworks > Subject: VME Interrupts to MVME162 > Date: Tue, 22 Dec 1998 16:00:47 -0800 > From: David Morris 222-7450 > Organization: TRIUMF > Message-ID: <368032AF.90F2FEB8@triumf.ca> > > Hello > When all else has failed, ask the experts. > > I'm trying the get interrupts from a VME motor module to show up under > VxWorks 5.2 > > The module generates IRQ5, I can see this on a bus monitor module. I > have the intConnect function to attach my ISR to the particular vector, > but all I get is a reboot. Arghh! > > Here's the code to get ints going. My vector is 180, for whatever > reason, but it should be valid. If I enable the interrupt in the > VMEchip, the system crashes. I suspect the vector is not working right, > since all the ISR does is call logMsg right now. I can read the vector > in the vector register on the board, so its OK. > > *pbdItem->pVectorRegister = sVector; > > if (ERROR == intConnect (INUM_TO_IVEC (sVector), (VOIDFUNCPTR) > omsInterrupt, (int) pbdItem)) > return OMS_ERROR_INTERRUPT; > > piVMEChip2 = (unsigned int *) 0xfff4006C; > *piVMEChip2 = 0x10; > > omsIoctl(pbdItem, NULL, ENABLE_INTERRUPTS); > > Can anyone give me an idea of what is missing here? The lack of simple > information on Windserve or anywhere else is starting to get rather > frustrating. Here are some possible causes of trouble: 1) You are not accessing the register in the OMS indexer that clears the interrupt in your interrupt service routine. 2) Your IACK daisy chain is incomplete. If there are any empty slots between your OMS stepper motor module and the CPU make certain that the IACK daisy chain jumper has been installed for these slots on the backplane. 3) I cant comment on your change to the default VME Chip II configuration as I dont have an mv162 manual at the moment, but it is normally not necessary to use anything other than sysIntEnable() to enable VME interrupts in a vxWorks system. There is an OMS stepper motor indexer device driver in the EPICS distribution. Rolf Keitel at Triumf has a copy. Jeff From owner-vxwexplo-process Wed Dec 23 11:49:45 1998 From: Dale Luck Date: Wed Dec 23 11:49:48 PST 1998 Subject: RE: comp.os.vxworks newsdigest (about what?) Don't know what this message is about? Its because somebody replied to a newsdigest and forgot to replace the subject line with the subject line from the embedded message. Please folks, if you read the digests and reply with helpful information, please change the subject line so others can quickly see what it pertains too. Thanks Dale > -----Original Message----- > From: vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov] > Sent: Wednesday, December 23, 1998 9:27 AM > To: vxworks_users@csg.lbl.gov > Subject: RE: comp.os.vxworks newsdigest > > Submitted-by owner-vxwexplo-process Wed Dec 23 09:26:52 1998 > Submitted-by: name changed to protect the guilty ;-) > > > vxWorks tornado > > > Newsgroups: comp.os.vxworks > > Subject: VME Interrupts to MVME162 > From owner-vxwexplo-process Wed Dec 23 16:48:32 1998 From: Alistair Adams Date: Wed Dec 23 16:48:35 PST 1998 Subject: Fortran ggnu compiler? Has anyone tried using the gnu FORTRAN compiler with VxWorks, particularly with PowerPC? Alistair Adams Octant Technologies Inc. From owner-vxwexplo-process Thu Dec 24 04:00:12 1998 From: daemon@csg.lbl.gov Date: Thu Dec 24 04:00:15 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Dec 24 04:00:07 PST 1998 Subject: powerpc-vxworks-gdb Subject: curses for vxworks Subject: Re: How does one wait on more than one object in VxWorks ?. Subject: Re: VME Interrupts to MVME162 Subject: Re: off topic question Subject: Re: ARM target and ARM compiler? Subject: VxWorks, Rimfire 3573, 4GB Disks and NFS ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: powerpc-vxworks-gdb Date: Wed, 23 Dec 1998 13:11:59 +0100 From: Melih Ercan xe4 52754 Organization: Alcatel Telecom Message-ID: <3680DE0F.318C1F65@access.bel.alcatel.be> Hi all, I want to debug a powerpc(mpc860) vxworks build on a target(test) board without using the tornado tools. But instead, I want to use ddd/gdb pair. When I check the gdb-4.17 release I saw the targets for: vx29k, vx68, vx960, vxmips, vxsparc but not for powerpc. I think the file remote-vxppc.c is required to build powerpc-vxworks-gdb. Does anybody know where I can find this file or a prebuild gdb for vxworks/powerpc target on solaris platform. Thanx in advance. Melih. --------------------------- Newsgroups: comp.os.vxworks Subject: curses for vxworks Date: Thu, 24 Dec 1998 00:40:57 +0900 From: "ÀÌÀçÈ«" Organization: ELIMnet Internet News Message-ID: <36810F09.D02C3119@hanimail.com> Hi there, i am trying to find a curses library for vxworks. I would appreciate any information. thanks. JaeHong Lee jhong@hanimail.com Institute for Advanced Engineering South Korea --------------------------- Newsgroups: comp.os.vxworks Subject: Re: How does one wait on more than one object in VxWorks ?. Date: 23 Dec 1998 16:53:57 GMT From: litwin@litwin (Todd Litwin) Organization: Jet Propulsion Laboratory - Pasadena CA Message-ID: <75r775$ffk@netline.jpl.nasa.gov> References: <75oucf$5b2@news.or.intel.com> rvsaripa wrote: >I have 2 semaphores and file descriptor I need to wait on at the same time > in a certain task context that has access to them ). > >Can I use select() ?. When I read the documentation on select, it seems to >take only file descriptors ( semaphores are not file descriptors, are they Two mechanisms come to mind: 1. If you want to use select(), then try using pipes instead of semaphores. Look at the documentation for pipeDevCreate(). This will create a device, with a file descriptor usable in select(), that can be written to and read from, and can be used similar to a semaphore if desired. 2. Or you could use a single message queue. Look at msgQLib. Your different semaphores could be queued items with different (application-defined) ID numbers. - -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 Todd.E.Litwin@jpl.nasa.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VME Interrupts to MVME162 Date: Wed, 23 Dec 1998 10:31:07 -0800 From: David Morris 222-7450 Organization: TRIUMF Message-ID: <368136EB.E1877FB8@triumf.ca> References: <368032AF.90F2FEB8@triumf.ca> David Morris 222-7450 wrote: > Hello > When all else has failed, ask the experts. > > I'm trying the get interrupts from a VME motor module to show up under > VxWorks 5.2 > > The module generates IRQ5, I can see this on a bus monitor module. I > have the intConnect function to attach my ISR to the particular vector, > but all I get is a reboot. Arghh! > > Here's the code to get ints going. My vector is 180, for whatever > reason, but it should be valid. If I enable the interrupt in the > VMEchip, the system crashes. I suspect the vector is not working right, > since all the ISR does is call logMsg right now. I can read the vector > in the vector register on the board, so its OK. > > > Can anyone give me an idea of what is missing here? The lack of simple > information on Windserve or anywhere else is starting to get rather > frustrating. > What was missing was that the interrupts for VME are level, not edge triggered. The ISR must clear the interrupt line as part of it's work in processing the interrupt. The motor module holds the INT line active until the board status register is read, which clears all bit automatically. It was re-interrupting over and over until meltdown. Thanks to Fred Roeber for the solution! - -- David B Morris TRIUMF Systems Designer/Analyst Canada's National Meson Facility cadfael@triumf.ca 4004 Wesbrook Mall 604-222-7450 Vancouver, B.C. V6T 2A3 "Remember, no matter where you go, there you are." - Buckaroo Banzai --------------------------- Newsgroups: comp.os.vxworks Subject: Re: off topic question Date: Wed, 23 Dec 1998 17:31:06 -0500 From: Douglas Fraser Organization: Lucent Technologies Message-ID: <36816F2A.FC5FFB02@lucent.com> References: <01be2a8e$653ef520$b7c310ac@ndsuk1063> <367E4AD5.FC3633E5@lucent.com> <01be2e8f$7c013ed0$b7c310ac@ndsuk1063> Robert Stedman wrote: > > you do not need holes or padding in data strucutres, the MPC860 does allow > accesing of 16 and 32 bit data on missaligned address - although it > requires multiple accesses as stated in 14.4.5. The GNU toolkit Sorry, I stand corrected. > documentation describes the packed attribute for this purpose - again > portability across platforms is not a requirement. It appears that the > gcc documentation supplied for the Sun (SPARC/SunOS) makes no mention of > strucutre packing options - which I pressume can be controlled in a similar > fashion to the MPC860 compiler (no matter how undesirable their use may be) - -- Douglas Fraser dwfraser@lucent.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ARM target and ARM compiler? Date: Wed, 23 Dec 1998 16:11:12 -0800 From: Hwa-Jin Bae Organization: Idiom Communications Message-ID: References: <75onj6$7b4@overload.lbl.gov> I have been unsuccessful in using ARM SDK compiler with VxWorks. The ARM SDK compiler uses different object output format than ELF or COFF. The linker couldn't handle VxWorks objects and assembler uses different syntax than GAS. If you have been successful in using ARM SDK C toolchain with VxWorks/ARM let me know. THanks. Hwa-Jin Bae PSO Systems, Inc. http://www.pso.com mailto:hjb@pso.com On 22 Dec 1998, Bill Pringlemeir wrote: > The following message is a courtesy copy of an article > that has been posted as well. > > Does the compiler from ARM work with VxWorks? I have heard that > it generates the best code for that platform. The Green Hills > compiler seems to support more C++ functionality than either 'gcc' > or ARM, and it includes the EC++ libraries. > > Does anyone have experiences with using the ARM or Green Hills compiler > on an ARM target? I got the DIAB compiler to work with the the MPC821 > and VxWorks. DIAB gave better performance than the supplied GCC. > > Does anyone know if WR will ever use the EGCS compiler. EGCS has a better > backend to do instruction scheduling. This is one of the reasons gcc > performs worse on ARM/PowerPC (RISC). I did find that gcc was better than > the MRI compiler we have on a 68k processor. > > Thanks, > Bill > > -- > Brave New Waves, "http://www.radio.cbc.ca/programs/bnw/" > > > --------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks, Rimfire 3573, 4GB Disks and NFS Date: Thu, 24 Dec 1998 06:50:23 GMT From: muswick@uhrad.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <75so7f$am$1@nnrp1.dejanews.com> I am some intermittant problems on a VME system run VxWorks 5.1, a Rimfire 3573 Scsi controller, a new Baracuda 4GB disk, ethernet, and NFS to a Sun Sparc workstation run SunOS 4.1. Here is a copy of my status on the vx system: - -> i NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY ---------- ------------ - -------- --- ---------- -------- -------- ------- ----- tExcTask _excTask 3fbbb8 0 PEND 51a64 3fbb20 d0003 0 tLogTask _logTask 3f92b8 0 PEND 51a64 3f921c 0 0 tShell _shell 3c1b28 1 READY 546a8 3c17f0 320001 0 tRlogind _rlogind 3f12b0 2 PEND 51d6c 3f0f88 0 0 tTelnetd _telnetd 3ef40c 2 PEND 51d6c 3ef33c 0 0 tTelnetOutT_telnetOutTa 325bfc 2 READY 51d6c 325964 0 0 tTelnetInTa_telnetInTas 3246e4 2 READY 51d28 3243ec 0 0 tRdbTask _rdbTask 3ec9dc 20 PEND 51d6c 3ec8bc d0003 0 gantryTask _post_gc_rea 32afdc 30 PEND 51d6c 32af18 0 0 tNetTask _netTask 3f46e0 50 READY 52ad2 3f4678 0 0 rts_server _rts_server 3a3a20 50 PEND 51d6c 3a3900 d0003 0 rodTask _post_rr_rea 3292f4 50 PEND 51d6c 32923c 0 0 tFtpdTask _ftpdTask 3ea524 55 PEND 51d6c 3ea46c 0 0 tMountd _mountd 3e7318 55 PEND 51d6c 3e71f8 d0003 0 tNfsd _nfsd 3e4988 55 PEND 51d6c 3e484c d0003 0 tNfsd3 _nfsdRequest 3e1ff8 60 PEND 51a64 3e1f34 0 0 tNfsd2 _nfsdRequest 3df668 60 PEND 51a64 3df5a4 0 0 tNfsd1 _nfsdRequest 3dccd8 60 PEND 51a64 3dcc14 0 0 tNfsd0 _nfsdRequest 3da348 60 PEND 51a64 3da284 0 0 stor_data _stor_data 37fed0 99 PEND 51d6c 37fe0c 0 0 tPortmapd _portmapd 3edef4 100 PEND 51d6c 3eddc0 16 0 mcs_server _mcs_server 3a5708 100 PEND 51d6c 3a55e8 d0003 0 matrixServe_matrixServe 39ea70 100 PEND 51d6c 39e950 d0003 0 rfa_server _rfa_server 384e80 150 PEND 51d6c 384d60 d0003 0 value = 0 = 0x0 My first question is whether the ERRNO listed are normal for vxWorks? Second, are there any known problems using a 4.0GB SCSI drive on vxWorks using the 3573? Will the Format command work ok with this disk? Since the SUN OS can only see a 2GB partion, when NFS mount the 4.0GB Drive, it mostly shows 0% used. Are there any problems using SunOS 4.1 and NFS to access a 4.0GB drive? Any thoughts or suggestions would be appreciated. Gary Muswick muswick@uhrad.com (216)844-7793 (216)844-3106 fax. - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Fri Dec 25 04:00:11 1998 From: daemon@csg.lbl.gov Date: Fri Dec 25 04:00:14 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Dec 25 04:00:07 PST 1998 Subject: Simple I/O Subject: TCP/IP sockets Subject: How does one wait on more than one object in VxWorks ?. Subject: Re: What happens to command line arguments? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Simple I/O Date: Thu, 24 Dec 1998 08:43:33 -0500 From: Steve O'Neill Organization: Sanders, A Lockheed Martin Company Message-ID: <36824505.CAC5E1CD@lmco.com> A simple question... We are using Tornado with a MVME2307 PPC board. We have an application that outputs a menu and then reads responses to perform the desired actions. The application uses gets(ch) to read the responses into a 1 character item. The problem is that while the application is able to output the menu to the debug com port input through that port seems to be getting intercepted by the VxWorks shell. I know that I have done this sort of thing before but I can't seem to remember the setup/operations necessary to get things configured properly. Yes, I've tried several virtual I/O configurations but that sets up the Tornado shell as the output path - this isn't what I want. I actually want all I/O to be done with this application via the debug port. Any help would be appreciated... Steve O'Neill --------------------------- Newsgroups: comp.os.vxworks Subject: TCP/IP sockets Date: Tue, 22 Dec 1998 09:38:18 -0400 From: Kirk Bateman Organization: Johns Hopkins University Applied Physics Lab, Laurel, MD, USA Message-ID: <367FA0C9.C8C3A46C@jhuapl.edu> I've encountered a problem using TCP/IP sockets to communicate between a real-time system running on an MVME-167 board (VxWorks 5.2) and a graphical user interface (GUI) running on a Sun SPARC workstation (Solaris 2.5.1). Both applications use wrap messages, which they exchange periodically (every eight seconds), to monitor the socket. The real-time application uses three tasks, of equal priority, to monitor and maintain the socket. Specifically, an input handler task reads data from the socket, an output spooler task writes data to the socket, and a socket control task takes appropriate steps to open the socket during software initialization and to reconnect the socket when loss of communication between the MVME-167 board and the SPARCstation is detected. Additionally, the input handler task writes a response to the socket immediately upon reading a wrap request message from the socket. This is the only case in which a task other than the output spooler writes to the socket. When there is a high amount of traffic between the GUI and the real-time application, the input handler task has been observed to "hang." Specifically, executing a ti command at the shell prompt yields: 279cc _vxTaskEntry +10 : _ciwsShipInputHandler (0, 0, 0, 0, 0, 0, 0, 0, 0, 0) f4818a _ciwsShipInputHandler+1ba: _respondToWrapReq (f8fb40, f50dcc, &_shipSocketDown) f46976 _respondToWrapReq+12c: _tcpSocketWrite (f50dcc, 8, f8fb18) f494a0 _tcpSocketWrite+14 : f49c5e (b, f8fb18, 8) f49cae _tcpSocketReconnect+7ba: _write (b, f8fb18, 8) 445e4 _write +10 : _iosWrite ([b, f8fb18, 8, f8fae8, f49cb4]) 45354 _iosWrite +78 : 3e0dc ([ffdc30, f8fb18, 8, f8fac4, 445ea]) 3e10a _send +a8 : _sosend (ffdc30, 0, f8fb18, 8, f8fa98) 76038 _sosend +1c2: _sbwait (ffdcc0) 7733c _sbwait +10 : _semQPut ([ffdce0, f8fa6c, 7603e, ffdcc0, 8]) The input handler task appears to be blocked awaiting a semaphore within the VxWorks write function as it attempts to write a wrap request message to the socket. I don't know how to proceed in tackling this problem, as I'm not familiar enough with the kernel to troubleshoot it. However, as I was pressed for time to solve the problem, I did so by having the input handler task send the wrap request message to a message queue, rather than writing it to the socket. The output spooler task then takes the wrap request message from the queue and writes it to the socket. Isolating the reads and writes in two separate tasks seems to have solved the problem. However, I don't understand why the original software design didn't work. If there is a semaphore within the kernel controlling access to the socket, it seems that the input handler task should be able to get or take this semaphore when the output spooler or socket control tasks do not have it. Your help is greatly appreciated. --------------------------- Newsgroups: comp.os.vxworks Subject: How does one wait on more than one object in VxWorks ?. Date: Tue, 22 Dec 1998 11:45:36 -0800 From: "rvsaripa" Organization: Intel Corporation Message-ID: <75oucf$5b2@news.or.intel.com> Consider the following scenario . I have 2 semaphores and file descriptor I need to wait on at the same time in a certain task context that has access to them ). Can I use select() ?. When I read the documentation on select, it seems to take only file descriptors ( semaphores are not file descriptors, are they ? ) . In short , I am looking for a mechanism such as WaitForMultipleObjects() on Win32 ( NT / 95 / 98 ) . Thanks for any help in advance, rk please e-mail me at ramakrishna_Saripalli@intel.com All opinions are mine and mine only . --------------------------- Newsgroups: comp.os.vxworks Subject: Re: What happens to command line arguments? Date: 22 Dec 1998 16:55:45 -0500 From: Ken Taylor Organization: SpryNet Message-ID: References: <75p0rr$j3v$1@swlmail.msd.ray.com> Sender: ktaylor@sunspot.avid.com rmd@swl.msd.ray.com (Regina DuBord {84134}) writes: > Does anybody know what happens to command line argu- > ments in VxWorks??? They certainly don't seem to get > assigned to argv in a C program, though I haven't found > *any* documentation about this. Arrrgh (tearing my hair > out, etc....) > There is no standard C command line processing done in vxWorks. 'main' has no special meaning. It's just another function call. In your example: - -> main "-b" argc is 28858832 The shell pushes the address of the string "-b" onto the stack. Then it calls 'main'. argc gets set to the first int on the stack (etc). I'll bet if you looked at address 0x1b859d0 (28858832), you'd see "-b". - -- Ken Taylor Avid Technology, Inc. --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Sat Dec 26 04:00:09 1998 From: daemon@csg.lbl.gov Date: Sat Dec 26 04:00:12 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Dec 26 04:00:05 PST 1998 Subject: Re: Simple I/O Subject: Re: How does one wait on more than one object in VxWorks ?. Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Subject: Re: How to get the system time on Vxworks. Subject: Re: TCP/IP sockets Subject: The Interactive Dance Compilation you can play and Mix on your PC!! 3373 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Simple I/O Date: Fri, 25 Dec 1998 06:47:17 -0600 From: johncobyremovespam@orbitworld.net (John R. Cobarruvias) Organization: Self Message-ID: References: <36824505.CAC5E1CD@lmco.com> In article <36824505.CAC5E1CD@lmco.com>, Steve O'Neill wrote: If the shell is intercepting it, then the shell has higher priority than your task. While your application is running either suspend the shell or kill it. then before your application quits, start the shell up again with shellInit which is in usrConfig.c (I think.) > A simple question... > > We are using Tornado with a MVME2307 PPC board. We have an application > that outputs a menu and then reads responses to perform the desired > actions. The application uses gets(ch) to read the responses into a 1 > character item. > > The problem is that while the application is able to output the menu to > the debug com port input through that port seems to be getting > intercepted by the VxWorks shell. I know that I have done this sort of > thing before but I can't seem to remember the setup/operations necessary > to get things configured properly. > > Yes, I've tried several virtual I/O configurations but that sets up the > Tornado shell as the output path - this isn't what I want. I actually > want all I/O to be done with this application via the debug port. > > Any help would be appreciated... > Steve O'Neill - -- See "Closing Costs" by Brad Tyer, The Houston Press for a feature story on Ryland Homes and my webpage at: http://www.houstonpress.com/1998/102998/feature2-1.html ANTI_SPAM IN EFFECT RESPOND TO: JOHNCOBY@ORBITWORLD.NET --------------------------- Newsgroups: comp.os.vxworks Subject: Re: How does one wait on more than one object in VxWorks ?. Date: Wed, 23 Dec 1998 03:48:46 GMT From: Ephraim Ezekiel Organization: Quarry Technologies Message-ID: <368067B1.C10785EF@bbn.com> References: <75oucf$5b2@news.or.intel.com> There is really no easy way to wait on multiple objects. That is why the select is used in Unix and VxWorks. The select doesn't work for semaphores and queues. One option is to create multiple tasks which each waits on the different types of events and then have the 2 tasks coordinate their shared data. One thing that I did is to use the signal to wait on multiple events although I am not sure how a file descriptor can be mapped to a signal. Signals can either be processed asynchronously by a signal handler or synchrounously in the task's main thread. The select really only works for sockets, pipes and asynchronous events that use file descriptors. rvsaripa wrote: > Consider the following scenario . > > I have 2 semaphores and file descriptor I need to wait on at the same time > in a certain task context that has access to them ). > > Can I use select() ?. When I read the documentation on select, it seems to > take only file descriptors ( semaphores are not file descriptors, are they > ? ) . > > In short , I am looking for a mechanism such as WaitForMultipleObjects() on > Win32 ( NT / 95 / 98 ) . > > Thanks for any help in advance, > rk > > please e-mail me at ramakrishna_Saripalli@intel.com > > All opinions are mine and mine only . --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Date: Wed, 23 Dec 1998 03:51:35 GMT From: john@kivala.com Organization: Kivala Systems, Inc. Message-ID: <75ppc8$isj$1@nnrp1.dejanews.com> References: <75mm74$134$1@nnrp1.dejanews.com> <367FE979.7BA0@nospam.aracnet.com> In article <367FE979.7BA0@nospam.aracnet.com>, sj_nospam@nospam.aracnet.com wrote: > newsmine@my-dejanews.com wrote: ... ... > As far as caching strategy goes...in general, RAM should be > cached--unless it is an area of RAM being shared between more than one > processor, or otherwise being read to or written from by something else > other than the CPU. (This does not include other things internal to the > CPU, such as the SCC---external RAM accessed by the SCC may be safely > cached). The 860 family does not have support for bus snooping; so > there is no way for an external bus master to know if memory it touches > is up-to-date, or to mark it dirty. So turn off cacheing for any such > memory. ... I don't think the above is right. I think the CPM devices (including SCCs) are external as far as caching is concerned, so if your CPM devices use external memory, the memory should either be noncacheable or you should take care of caching issues manually. Perhaps some of you other 860 regulars could concur or straighten me out? John - -------------------------------------------------- John Finley Kivala Systems, Inc. Project Manager (619) 689-0032 john@kivala.com http://www.kivala.com - -------------------------------------------------- VxTool - Build Tornado Apps with MS Visual Basic - -------------------------------------------------- - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Re: How to get the system time on Vxworks. Date: Wed, 23 Dec 1998 23:00:38 GMT From: Suresh Gopalakrishna Organization: DSET Corporation Message-ID: <36817525.A42A5783@dal.dset.com> References: <3679C934.DC671165@qualcomm.com> <367A7025.ECAA7AFF@lmco-NOSPAM.com> Hey Guys, This is how it works, there is a clock_gettime() func in VxWorks, which gets current time of the clock. The code looks like below, struct timespec time_val; clock_gettime(CLOCK_REALTIME, &time_val); time_in_seconds=time_val.tv_sec; So finally you get the time in secs. For setting the clock, there is clock_settime(). The synopsis is as follows : int clock_gettime(clockid_t clock_id, struct timespec * tp) here clockid is always CLOCK_REALTIME --> for VxWorks, Same for settime also. Hope this helps for you, Suresh, Daniel Wong wrote: > You need to initialize your system time from the board's Real Time > Clock. Most SBCs have one. I don't know of a standard VxWorks function > that reads the RTC. Check your board documentation for specifics. > Check www.dejanews.com and search on this newsgroup for sample code > recently posted. > > Basically: 1. Read the RTC time > 2. Set the system clock (try clock_settime() ) > > I only know how I do this for the MVME 2604 board. Should be very > similar for many of the Moto boards since they use the same or similar > RTC chip. > > This approach will be as accurate as your RTC [not very]. See postings > in comp.protocols.time.ntp newsgroup _iff_ you need more accurate > (to << 1 sec) time and have access to an ntp server. > > HTH > > Dan Wong > > Venkat Emani wrote: > > > > Greetings Folks, > > > > I would appreciate if someone can help me in the following regard. > > > > I am trying to get the system time from within the program. > > > > My code looks like this: > > > > #include > > ........ > > > > time_t tm Time = time(NULL) ; > > > > struct tm * tmp = localtime(&tmTime) ; > > > > ..... > > > > I thought tmTime should contain the no. of seconds from Jan 1st. > > 1970 ( At least on Solaris and NT it's like that ) > > However, tmTime is set to the no. of seconds elapsed since the > > card was booted last. ( Which meant if I run it > > in 5 minutes after booting my MC card, tmTime was being set to 5 * > > 60 = 300 . As a result the localtime() routine > > sets the time to Jan 1st 1970 , 00:05:00 which was n't what I > > wanted. > > > > Please let me know how I can get the system Time . > > > > My apologies if this question was previously answered. Please point me > > to that. > > > > Thanks, > > > > Ven. > > -- > Daniel Wong Principal System Engineer > Lockheed Martin Ocean Radar and Sensor Systems > Electronics Park EP7-333 Syracuse, NY 13090 > (315)456-2162 [FAX (315)456-1430] > ------------------------------------------------------------------------ > Blessed is the man who always fears the Lord, > but he who hardens his heart falls into trouble. -- Proverbs 28:14 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP/IP sockets Date: Wed, 23 Dec 1998 16:08:14 -0800 From: Hwa-Jin Bae Organization: Idiom Communications Message-ID: References: <367FA0C9.C8C3A46C@jhuapl.edu> This sounds like the sending task is blocking due to tcp socket buffer exhaustion. TCP window is derived from socket level buffer (settable via setsockopt SO_SNDBUF). The send side has a limit on how many bytes can be queued on the send buffer queue at the socket level. If the receiver is not reading bytes off of its queue (receive side socket level queue), this causes the TCP window to close up. Until receiver opens up the window the sender will block. You can do a couple of things: 1. increase tcp window size (via setsockopt) 2. make sure receiver is emptying data that are coming in -- quickly enough to not get into a situation where the sender might wait for the TCP window to open up again. Hwa-Jin Bae PSO Systems, Inc. http://www.pso.com mailto:hjb@pso.com On Tue, 22 Dec 1998, Kirk Bateman wrote: > I've encountered a problem using TCP/IP sockets to communicate between a > real-time system running on an MVME-167 board (VxWorks 5.2) and a > graphical user interface (GUI) running on a Sun SPARC workstation > (Solaris 2.5.1). Both applications use wrap messages, which they > exchange periodically (every eight seconds), to monitor the socket. > > The real-time application uses three tasks, of equal priority, to > monitor and maintain the socket. Specifically, an input handler task > reads data from the socket, an output spooler task writes data to the > socket, and a socket control task takes appropriate steps to open the > socket during software initialization and to reconnect the socket when > loss of communication between the MVME-167 board and the SPARCstation is > detected. Additionally, the input handler task writes a response to the > socket immediately upon reading a wrap request message from the socket. > This is the only case in which a task other than the output spooler > writes to the socket. > > When there is a high amount of traffic between the GUI and the real-time > application, the input handler task has been observed to "hang." > Specifically, executing a ti command at the shell prompt yields: > > 279cc _vxTaskEntry +10 : _ciwsShipInputHandler (0, 0, 0, 0, 0, 0, 0, > 0, 0, 0) > f4818a _ciwsShipInputHandler+1ba: _respondToWrapReq (f8fb40, f50dcc, > &_shipSocketDown) > f46976 _respondToWrapReq+12c: _tcpSocketWrite (f50dcc, 8, f8fb18) > f494a0 _tcpSocketWrite+14 : f49c5e (b, f8fb18, 8) > f49cae _tcpSocketReconnect+7ba: _write (b, f8fb18, 8) > 445e4 _write +10 : _iosWrite ([b, f8fb18, 8, f8fae8, f49cb4]) > 45354 _iosWrite +78 : 3e0dc ([ffdc30, f8fb18, 8, f8fac4, 445ea]) > 3e10a _send +a8 : _sosend (ffdc30, 0, f8fb18, 8, f8fa98) > 76038 _sosend +1c2: _sbwait (ffdcc0) > 7733c _sbwait +10 : _semQPut ([ffdce0, f8fa6c, 7603e, ffdcc0, > 8]) > > The input handler task appears to be blocked awaiting a semaphore within > the VxWorks write function as it attempts to write a wrap request > message to the socket. I don't know how to proceed in tackling this > problem, as I'm not familiar enough with the kernel to troubleshoot it. > However, as I was pressed for time to solve the problem, I did so by > having the input handler task send the wrap request message to a message > queue, rather than writing it to the socket. The output spooler task > then takes the wrap request message from the queue and writes it to the > socket. Isolating the reads and writes in two separate tasks seems to > have solved the problem. However, I don't understand why the original > software design didn't work. If there is a semaphore within the kernel > controlling access to the socket, it seems that the input handler task > should be able to get or take this semaphore when the output spooler or > socket control tasks do not have it. > > Your help is greatly appreciated. > > --------------------------- Newsgroups: comp.os.vxworks Subject: The Interactive Dance Compilation you can play and Mix on your PC!! 3373 Date: 24 Dec 1998 12:03:03 GMT From: gericom@usa.net Organization: Centro Servizi Interbusiness Message-ID: <75tahn$gjq$1914@fe2.cs.interbusiness.it> The Interactive Dance Compilation you can play and Mix on your PC!! The best dance hits of '90 and 98 together in Discoparade the first double compilation that you can play and Mix ! Discoparade is the one and only interactive compilation ! http://www.discoparade.com/ http://www.discoparade.com/ ovnibogxpidfdrkixdvzivwouxikzrgegkxviegphwg --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Sun Dec 27 04:00:08 1998 From: daemon@csg.lbl.gov Date: Sun Dec 27 04:00:12 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Dec 27 04:00:06 PST 1998 Subject: Pussy shot from behind 324 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Pussy shot from behind 324 Date: 25 Dec 1998 22:02:45 GMT From: rwcrwd@aol.com Organization: Migros-Genossenschafts-Bund Message-ID: <761225$9ap@uranus.m-netz.ch> The sex gallery ! It's all FREE here ! FREE xxx memberships, passwords,pic,thumbnails,and much more ! Now featuring live hott erotic talk ! Cum by today ! WE'RE WAITING ! http://www.thesexgallery.com/ htsceortutuhwsirutjolikenphbcvyrbniqijhvwqwwhzjbjgieennxgpn --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Tue Dec 29 04:00:09 1998 From: daemon@csg.lbl.gov Date: Tue Dec 29 04:00:12 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Dec 29 04:00:06 PST 1998 Subject: Interrupt Vector Table Subject: Re: Interrupt Vector Table Subject: Request BSD for Cirrus Logic CL-PS7500FE Subject: Re: Loading (ld) over a serial port Subject: Re: Loading (ld) over a serial port Subject: Re: delete operator ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Interrupt Vector Table Date: Mon, 28 Dec 1998 15:50:36 -0500 From: "Michael McGarry" Message-ID: <768r1l$n3d$1@news.eclipse.net> Hello felow VxWorks users, I was wondering if anyone knew what the interrupt vector table that vxWorks sets up on the mpc860 looks like? and where in memory does it place this table? I put my interrupt handler in the vector table by calling intConnect(vector_num, (VOIDFUNCPTR) myHandler, param); correct? - -- Regards, Michael McGarry, Firmware Engineer II Cabletron Systems, Inc. (732) 394-6041 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Interrupt Vector Table Date: Tue, 29 Dec 1998 00:39:25 GMT From: john@kivala.com Organization: Kivala Systems, Inc. Message-ID: <7698bt$gn7$1@nnrp1.dejanews.com> References: <768r1l$n3d$1@news.eclipse.net> There are several tables used to demultiplex interrupts on the 860. When an interrupt happens, the "external interrupt" exception happens, and the CPU starts executing at 0x500. VxWorks attaches a handler to this that goes off and reads the SIU and CPM (as necessary) to see what interrupted. All this happens in Tornado/target/src/drv/intrCtl/ppc860Intr.c. When you do an intConnect(), you are putting an entry into the table intrVecTable[] in that file. The "vector" you pass in is an index into this table; there are defines for these in Tornado/target/h/drv/intrCtl/ppc860Intr.h. The "IV_..." things are the things to pass to intConnect. For example: intConnect(IV_TIMER3, yourHandler, 0) connects to timer 3 in the CPM. As with any other CPU, you have to make sure and properly acknowledge the interrupt in the ISR, or you go off into never-never land. This seems to be more common with the 860 due to the weight of the user's manual. Email me if you would like a little sample that sets up a CPM timer and handles interrupts from it, and I will dig it up. Good luck, John - -------------------------------------------------- John Finley Kivala Systems, Inc. Project Manager (619) 689-0032 john@kivala.com http://www.kivala.com - -------------------------------------------------- VxTool - Build Tornado Apps with MS Visual Basic - -------------------------------------------------- In article <768r1l$n3d$1@news.eclipse.net>, "Michael McGarry" wrote: > Hello felow VxWorks users, > > I was wondering if anyone knew what the interrupt vector table that vxWorks > sets up on the mpc860 looks like? and where in memory does it place this > table? > > I put my interrupt handler in the vector table by calling > intConnect(vector_num, (VOIDFUNCPTR) myHandler, param); > > correct? > > -- > Regards, > > Michael McGarry, Firmware Engineer II > Cabletron Systems, Inc. > (732) 394-6041 > > - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: Request BSD for Cirrus Logic CL-PS7500FE Date: Tue, 29 Dec 1998 12:32:12 +0800 From: Rayson Wai-sang Wong Organization: Cyber Express Communications (using Airnews.net!) Message-ID: Hi, My latest project is considering using Cirrus Logic CL-PS7500SE as platform. Does anyone know where can I find a BSP for it? This is urgent. Thanks. Wong Wai Sang wswong@wesoft.com.hk We Software Ltd. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Loading (ld) over a serial port Date: Tue, 29 Dec 1998 08:52:51 +0200 From: Yosi Yarchi Message-ID: <36887C43.6E5CE5AD@ecitele.com> References: <366EAFFE.CF8E6DF2@orbitworld.net> "John R. Cobarruvias" wrote: > According to the ld() command, I can load an object module from standard > input. > Has anyone done this? I'm a bit confused. > > I have a pc running NT with a target booting from rom with the shell and > symbol table. > I do not have a network. My only access is via a serial port. Two are > available. > > So, how do I use the ld command to load an executable, say a.out, from > the NT workstations into the target and run a.out from the shell? > > johncoby@orbitworld.net Hello John I'm also working with target without network. It has two serial ports, one is dedicated for STDIO, and the other is dedicated for connection to the debugger. When working with shell, you enter your commands (such as "ld") via a terminal connected to the stdio serial port. But, in the case of "ld" command, it requires a network (or a local disk) to load file from. Hence, I think, you cannot use it to load files if you have not configured network on your target. What you have to do, is to launch target server against your target (configuring it to work with serial backplane, the one dedicated to the debugger). After launching the target server, you can launch host shell, and from it load files (using the command "ld"). I hope it helps you Yosi --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Loading (ld) over a serial port Date: Tue, 29 Dec 1998 08:55:57 +0200 From: Yosi Yarchi Message-ID: <36887CFD.E196BFEA@ecitele.com> References: <366EAFFE.CF8E6DF2@orbitworld.net> "John R. Cobarruvias" wrote: > According to the ld() command, I can load an object module from standard > input. > Has anyone done this? I'm a bit confused. > > I have a pc running NT with a target booting from rom with the shell and > symbol table. > I do not have a network. My only access is via a serial port. Two are > available. > > So, how do I use the ld command to load an executable, say a.out, from > the NT workstations into the target and run a.out from the shell? > > johncoby@orbitworld.net Hello John I'm also working with target without network. It has two serial ports, one is dedicated for STDIO, and the other is dedicated for connection to the debugger. When working with shell, you enter your commands (such as "ld") via a terminal connected to the stdio serial port. But, in the case of "ld" command, it requires a network (or a local disk) to load file from. Hence, I think, you cannot use it to load files if you have not configured network on your target. What you have to do, is to launch target server against your target (configuring it to work with serial backplane, the one dedicated to the debugger). After launching the target server, you can launch host shell, and from it load files (using the command "ld"). I hope it helps you Yosi --------------------------- Newsgroups: comp.os.vxworks Subject: Re: delete operator Date: Tue, 29 Dec 1998 00:27:20 -0800 From: Scott Johnson Organization: National Association for the Advancement of Computer Geeks Message-ID: <36889268.58BE@nospam.aracnet.com> References: <769spl$vbo$1@nnrp1.dejanews.com> Reply-To: sj_nospam@nospam.aracnet.com keshavbc@my-dejanews.com wrote: > > hi, > i'm having problem with the c++ delete operator. while this code perfectly > works fine with a turbo C++ compiler on win95, it give 'memPartFree' error on > vxWorks. what could be the problem? i'm also attaching the code. > > > > -----------> start of code -------------> > #include "vxWorks.h" > #include "stdio.h" > #include "string.h" > > class mystring > { > char *str ; > > public: > mystring(){ str=0 ;} > mystring(char *s) > { > int len=strlen(s) ; > str=new char[len+1] ; > str=s ; > } Ah! Here is your problem!!!!! You are assigning str to point to the region pointed to by s, which probably was not allocated with new [x]. Calling delete[] on a region of memory not allocated with new[] will indeed cause a corrupt heap. This code also leaks memmory; the buffer you are allocating in the second statement is leaked in the third. What you want is this: mystring (const char *s) { str = new char [strlen(s) + 1]; strcpy (str, s); } Notice the use of const, too. Unless you intend to modify an argument passed by reference or pointer, you should make the declaration const. One more thing, and this depends on your compiler. If you are compiling with exceptions enabled (a bit dicey with vxWorks, as the current "officially" supported gcc variant from Wind River is 2.7.x, the exception handling capability of which is seriously broken), the above is OK--if new fails, an exception gets thrown. If your compiler DOES not throw exceptions, then you ought to check the return value of char::operator new[] to make sure that it isn't NULL (indicating out of memory). Of course, without exceptions, there isn't any clean way to indicate a failed constructor... > ~mystring() > { > if(str!=NULL) > delete [] str ; The test for NULL is redundant; delete foo (and delete [] foo) both check for foo==NULL, and return harmlessly if this is the case. However, you ought to after delete [] ing str, set it to NULL. Otherwise, it might well be deleted again.... > } > > mystring &operator= (mystring s1) Should be mystring &operator= (const mystring &s1) The argument to the assignment operator MUST be a reference parameter (and should, in most cases, be const). Likewise, the return value (if not void) MUST also be a reference. Otherwise, weird things will happen. (I'm actually surprised you got to the delete[] statement; one would expect that the call would recurse forever, at least until you run out of stack...) > { > delete [] str ; /* i'm getting error here - i also > tried with "delete str" only. but even that is not working */ delete [] str is correct. > str=s1.str ; > return ; The assignment operator should, in general, end with "return *this;" Not absolutely required, of course (operator = can return void, but doing so doesn't allow you to "use" the result of the assignment. Code such as if a = b = c won't work. May or may not be a problem.) > } > void putstr(char *s) > { > str=new char[strlen(s)+1] ; > str=s ; > } This suffers from the same problems as the constructor above; in addition, it contains an additional memory leak. If str points to something valid before this is called, your first statement will leak that storage away. Try this instead. void putstr (const char *s) { delete [] str; str = new char [strlen(s) + 1]; strcpy (str, s); } > > char *getstring() > { return str ; } Careful!!!! If you are going to return pointers to dynamic storage like this, make DAMN sure the calling code doesn't hold on to them. Otherwise, folks may do bad things like this: void nasty_function (int arg) { char *foo; foo = NULL; if (arg == 0) { mystring mystr = "foo"; foo = mystr.getstring(); } if (foo) printf (foo); } Do you see the problem?? If arg is nonzero, this works. If arg is zero, though, by the time the "printf(foo)" statement is executed, foo is pointing to garbage. Why? When the if block exits, str is destroyed. mystr.~mystring (the destructor) deallocates it's internal storage (mystr.str), which points to the same location as foo. Thus, the block of memory pointed to by foo is no longer valid. There may still be data there (causing printf to work), or not. This sort of bug (wild pointers) are MURDER to debug. This example is a bit contrived, of course, but similar things happen ALL THE TIME. And when it really happens, the offending deallocation and the offending use are usually far apart, making finding it even worse. In general, returning pointers or references to an object's private parts is a bad idea. The exception to this rule is if there is a "many to one" relationship; and multiple objects refer to a common object. The array str is most definitely private to mystring in this example. > void teststr() > { > mystring s1, s2 ; > > s1.putstr("abcdef") ; > s2.putstr("ghijkl") ; > > s1=s2 ; > > printf("\n %s \n",s1.getstring()) ; > > printf("\n %s \n",s2.getstring()) ; > } > -----------> end of code ----------------> I would suggest that you get yerself a good C++ book. The ones I recommend is "Effective C++; 50 Specific Ways to Improve Your Programs and Designs" by Scott Meyers, and its sequeel "More Effective C++". Most C++ texts teach how to program in C++--the syntax, the structures, etc. These two teach how to program in C++ **CORRECTLY**. C++ provides you with LOTS of ways to hurt yourself, muchmoreso than C does. Your code sample above (no offense) contains quite a few examples. Good luck, Scott --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Wed Dec 30 04:00:18 1998 From: daemon@csg.lbl.gov Date: Wed Dec 30 04:00:22 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Dec 30 04:00:15 PST 1998 Subject: FREE XXX 9798 Subject: Re: delete operator Subject: illegal instruction Subject: Calender time on VxSim? Subject: ccmips abnormal program termination Subject: Re: Loading (ld) over a serial port Subject: Vxworks IP -> NIC level binding question(s) ... Subject: Re: Booting VxWorks from hard-disk Subject: US-AZ-Tempe / Real-Time S/W Contractors (10) / Agency Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Subject: Re: Loading (ld) over a serial port ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: FREE XXX 9798 Date: 27 Dec 1998 02:19:57 GMT From: jftzii@ggggg.ggg Organization: SIAST Message-ID: <7645gd$r69929@www1.siast.sk.ca> The sex gallery ! It's all FREE here ! FREE xxx memberships, passwords,pic,thumbnails,and much more ! Now featuring live hott erotic talk ! Cum by today ! WE'RE WAITING ! http://www.thesexgallery.com/ oinbwcrplyljiiw --------------------------- Newsgroups: comp.os.vxworks Subject: Re: delete operator Date: Tue, 29 Dec 1998 11:13:50 -0500 From: "Lawrence T. Hoff" Organization: Brookhaven National Lab Message-ID: <3688FFBE.B302C391@bnl.gov> References: <769spl$vbo$1@nnrp1.dejanews.com> keshavbc@my-dejanews.com wrote: > > hi, > i'm having problem with the c++ delete operator. while this code perfectly > works fine with a turbo C++ compiler on win95, it give 'memPartFree' error on > vxWorks. what could be the problem? i'm also attaching the code. > > > > -----------> start of code -------------> > #include "vxWorks.h" > #include "stdio.h" > #include "string.h" > > class mystring > { > char *str ; > > public: > mystring(){ str=0 ;} Why do you use "0" here, and "NULL" later? > mystring(char *s) > { > int len=strlen(s) ; > str=new char[len+1] ; > str=s ; ^^^^^^^ Eeek! I think you wanted to say : "strcpy(str, s);" > } > ~mystring() > { > if(str!=NULL) > delete [] str ; > > } > > mystring operator= (mystring s1) > { > delete [] str ; /* i'm getting error here - i also > tried with "delete str" only. but even that is not working */ "delete str" is *wrong*, you must use "delete [] str" when deleting memory allocated with new [] > > str=s1.str ; ^^^^^^^^^^^^ Eeek again! Plus you forgot a separate allocation (unless you *want* to share the allocated memory, in which case you'll need a reference count, and special handling in the "putstr()" and "getstring()" methods). > return ; > } > void putstr(char *s) > { > str=new char[strlen(s)+1] ; > str=s ; ^^^^^^^ Triple eeeek! > } > > char *getstring() > { return str ; } "const char *" may be "better" than "char *" (unless you *want* users to be able to manipulate your private members directly) > } ; > I *assume* this is an educational exercise. There are plenty of public-domain string classes, with a variety of features. You may be better off starting with one of those. HTH -- Larry - -- Building 911-C, Brookhaven National Laboratory PO Box 5000, Upton, NY, 11973 http://www.rhichome.bnl.gov/~hoff, mailto:hoff@bnl.gov Phone: (516) 344-2194 FAX: (516) 344-5443 --------------------------- Newsgroups: comp.os.vxworks Subject: illegal instruction Date: Tue, 29 Dec 1998 17:43:42 +0100 From: ping1412@ping.be (Dirk Schelfhout) Organization: Donkergroen bvba Message-ID: How do I proceed to find out what causes this error. I checked that the code that causes this to happen is not altered. ( If i compare the assembly code at the specific address, before and after running ) The code that causes this is not special, it is a simple switch case block inside a function. Today I found out that one of the tasks running uses floating point, so I changed spawning of all tasks with the floatingpoint option. I am getting very desperate, all help welcome. --------------------------- Newsgroups: comp.os.vxworks Subject: Calender time on VxSim? Date: Tue, 29 Dec 1998 16:59:54 GMT From: jyl97@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <76b1qa$srk$1@nnrp1.dejanews.com> Hi, Does anyone know how to get correct time and date on VxSim? I'm running VxSim on Sun Solaris 2.6. Thanks a lot. - -- JYL - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: ccmips abnormal program termination Date: Tue, 29 Dec 1998 10:59:01 -0700 From: Rick Busser Organization: Dimensional Communications Message-ID: <36891865.761FE4B4@sitera.com> Has anyone else seen this when compiling templates in C++ files? - -- Rick Busser rickb@sitera.com Software Engineer (303) 651-1935 x256 SiTera Corporation (303) 651-1199 fax 1820 Lefthand Circle Longmont, CO 80501 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Loading (ld) over a serial port Date: Tue, 29 Dec 1998 11:00:11 -0800 From: Hwa-Jin Bae Organization: Idiom Communications Message-ID: References: <366EAFFE.CF8E6DF2@orbitworld.net> <36887C43.6E5CE5AD@ecitele.com> You could use SLIP or PPP over serial port. Hwa-Jin Bae PSO Systems, Inc. http://www.pso.com mailto:hjb@pso.com --------------------------- Newsgroups: comp.os.vxworks Subject: Vxworks IP -> NIC level binding question(s) ... Date: Tue, 29 Dec 1998 12:25:38 -0800 From: "rvsaripa" Organization: Intel Corporation Message-ID: <76bfe8$54b@news.or.intel.com> Hi, I am fairly new to vxworks . I am writing a device driver for a custom device. This device is a Ethernet NIC as far as the host is concerned and so accepts MAC layer packets for transmission . My questions are as follows :- a) If I am using SENS , what do I need to do to bind IP to my driver . Further , my device issues a MAC address for the host . If I wanted to use a DHCP client on the host to request an IP address for this interface , how would I provide the MAC address to the IP stack ?. Is there a standard / custom ioctl that my driver needs to support that the IP layer would call to get the MAC address for my interface ?. Thanks in advance, rk All opinions expressed are mine and mine only. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Booting VxWorks from hard-disk Date: Tue, 29 Dec 1998 17:50:13 -0800 From: John Fabiani Organization: Wind River Systems Message-ID: <368986D5.83A7AB03@nospam.wrs.com> References: <7422lv$lg7@news.or.intel.com> <3667470D.AA598FFD@know_spam.wrs.com> <756nra$1r8$1@nnrp1.dejanews.com> Reply-To: johnx@nospam.wrs.com david.hagood@ifrsys.com wrote: > I've tried to boot VxWorks from a hard disk only to fail miserably. Rest assured this can work. > > > The disk is partitioned with a FAT-16 partition as the first primary > partition. That partition is bootable (marked active). > > I do a vxsys c:\, and it works. Freshly format the drive. (With FDISK and FORMAT from MSDOS) Do "lock c:" to remove the partition protection (win95) Do "vxsys c:\" - This copies the VxLD 1.2 bootstrapping code to the filesystem bootsector. Note that the target hard drive should exist as "c:\" at this stage (ie: you cannot do "vxsys d:" and then switch the disk to C:, since the 0x80 BIOS representation is used when vxld looks for bootrom.sys), else this will fail with no bootrom.sys error. Do "vxcopy bootrom c:\bootrom.sys" - this copies the file, stripping the 32byte a.out header. Do "chkdsk c:\bootrom.sys /f", since bootrom.sys must be a contiguous file. > I copy a:bootrom.sys c:\bootrom.sys, and it works > I verify that bootrom.sys is contiguous. > I reboot the machine. > VxLd complains that it cannot find bootrom.sys > > The bootrom.sys I copied over loaded fine from the floppy. > > I created the file system from VxWorks, so it ought to be a configuration > that VxWorks likes. Hmm, that may be the problem. Create the HDD filesystem from MSDOS. This will force the use of partitions when making the file system (vxworks does not create partitions) but looking at the asm for vxsys.com, it does expect a partition if it is on a hard disk. > > > Any ideas? > > -----------== Posted via Deja News, The Discussion Network ==---------- > http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: az.jobs,misc.jobs.contract,comp.os.vxworks,comp.os.lynx,comp.realtime Subject: US-AZ-Tempe / Real-Time S/W Contractors (10) / Agency Date: 30 Dec 1998 05:46:45 GMT From: Tate Consulting Organization: Tate Consulting, Inc. Message-ID: <76ceo5$fq4$17@remarQ.com> Our client in Tempe Arizona is a Fortune 100 company building state of the art computer systems. 10 Real-time Systems Development Engineering Contractors needed for a January start date. JOB DESCRIPTION: System software integration for high availability real-time systems. Working with Compact PCI and real-time Operating system products to implement unique competence in system reliability. Responsible for designing and implementing integration test software for highly available products for customer specific applications. Knowledge of PowerPC highly desirable. Experienced C and C++ Programmers. Proven ability to debug and diagnose hardware and software problems on new hardware. Reference Job Code JC-A12048-01 on any correspondence. Please reference the JOB CODE listed above in any correspondence to us. Send your resume in ASCII or MSWord format to: Email: hotjobs@tateinc.com Fax: (561) 852-2385 Snail: Tate Consulting, Inc. 10647 Avenida Santa Ana Boca Raton, FL 33498 Please visit our Hi-Tech Job Database at http://www.tateinc.com Tate Consulting is a Computer Consulting and Placement Company in business since 1991. Andrew Tate, President/Owner Tate Consulting, Inc. atate@tateinc.com (561) 852-TATE (8283) We are an EOE. --------------------------- Newsgroups: comp.os.vxworks,comp.realtime,misc.jobs.contract Subject: US,AZ,Tempe - ChorusVxWorks OS/Driver Contract - Agency Date: 30 Dec 1998 05:46:48 GMT From: Tate Consulting Organization: Tate Consulting, Inc. Message-ID: <76ceo8$fq4$18@remarQ.com> Fortune 100 Company needs contractor to work on CHORUS and VxWorks Drivers and OS tuning. Refer to Job Code: JC-A10078-01. Please reference the JOB CODE listed above in any correspondence to us. Send your resume in ASCII or MSWord format to: Email: hotjobs@tateinc.com Fax: (561) 852-2385 Snail: Tate Consulting, Inc. 10647 Avenida Santa Ana Boca Raton, FL 33498 Please visit our Hi-Tech Job Database at http://www.tateinc.com Tate Consulting is a Computer Consulting and Placement Company in business since 1991. Andrew Tate, President/Owner Tate Consulting, Inc. atate@tateinc.com (561) 852-TATE (8283) We are an EOE. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MPC860SAR I & D Cache : Relation with memory type? Date: Wed, 30 Dec 1998 10:20:11 +0200 From: Yosi Yarchi Message-ID: <3689E23A.C5EE2C0E@ecitele.com> References: <75mm74$134$1@nnrp1.dejanews.com> newsmine@my-dejanews.com wrote: > Hi All, > > I am trying to activate the data and instruction caches on my MPC860SAR board. > I was wondering if anybody could share their experience with me on that. A few > questions I have are : > > 1.The ADS BSP we have has a couple of lines like > > #ifdef EDO_DRAM > undef USER_I_CACHE_ENABLE > undef USER_D_CACHE_ENABLE > undef INCLUDE_CACHE_SUPPORT > #endif /* EDO_DRAM */ > > What is the relationship between DRAM type and turning on the caches? Why > should the cache activation be restricted to SDRAM type of DRAM only? The cache activation is not restricted to SDRAM or DRAM. There were some bugs concerning the cache in the first revisions of the MPC860, and wind river, when created the BSP for the ADS860 board used one of this buggie chips. In my company, it works fine with both caches enabled with chip revision A3 or later and with EDO RAM. There is yet problem with data cache when working exactlly in 50 Mhz (solved in chip revision C and later). > > > 3.What areas of memory need to be excluded from caching on MPC860SAR? Only > the on-chip DPRAM or something else too? How do I specify these areas in > VxWorks? Excluded memory areas: (1) communication buffers (2) MPC860 internal DPR (3) board i/o memory mapped areas (4) FLASH ? The definition is done in "sysLib.c" file, in structure named "sysPhysMemDesc". vxWorks automatically exclude it's communication buffers out of the cache (ethernet, serial). Other communication buffers must be defined as not cacheable manually, or be dynamically allocated as non cacheable blocks ("cacheDmaMalloc()"). > > > 4.Is it sufficient to define these macros in config.h and rebuild the BSP? > #define USER_I_CACHE_ENABLE > #define USER_D_CACHE_ENABLE > #define INCLUDE_CACHE_SUPPORT > Yes. You can try to change the mode of the cache (WRITE_TROUGH, COPYBACK), but I'm not sure it have real meaning in the MPC860. In the MPC860 the instruction cache works only in COPYBACK mode, and from my experience vxWorks configure data cache to work in COPYBACK mode. The user can change this default manualy and force WRITE_THROUGH by commanding the DC_CST cache register. > > 5.Any performance indicators I may use to determine the speed-up gain? The performance for the instruction cache is improved significantlly. For the data cache, only load/store commands are accelerated by the cache. You can write small program, using some global variables, and check what going on with or without cache. In my small program (which not representing typical application at all !!!) I found that it runs X 8 faster when both caches are enables than when both caches are disabled. I estimate that data cache contributed 25% of the acceleration, and instruction cache - 75%. - -- Yosi Yarchi yosiy@ecitele.com eci-telecom --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Loading (ld) over a serial port Date: Wed, 30 Dec 1998 09:45:53 +0100 From: Sebastien Mallet Organization: Nortel Message-ID: <3689E841.DA51D4CE@nortel.ca> References: <366EAFFE.CF8E6DF2@orbitworld.net> <36887C43.6E5CE5AD@ecitele.com> Hi, You DON'T NEED a network to ld() from your host, a serial line with WDB_SERIAL backend does the job. The parameters are in config.h WDB_COMM_TYPE=WDB_COMM_SERIAL, WDB_TTY_CHANNEL, WDB_TTY_DEV_NAME, WDB_TTY_BAUD for communication type, channel, device name and baudrate. HTH Sebastien --------------------------- End of New-News digest ********************** From owner-vxwexplo-process Thu Dec 31 04:00:09 1998 From: daemon@csg.lbl.gov Date: Thu Dec 31 04:00:12 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Dec 31 04:00:05 PST 1998 Subject: NT4.0 as PPP server question Subject: ScsiMgr task? Subject: segmented memory Subject: I'm looking for development work ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: NT4.0 as PPP server question Date: Mon, 28 Dec 1998 12:33:21 -0700 From: Rick Busser Organization: Dimensional Communications Message-ID: <3687DD01.EE10F616@sitera.com> I am trying to run VxWorks over PPP, using NT4.0 as a host. I followed the instructions in the "Vinh's PPP guide" and I'm still having problems. I get the following error Attaching network interface ppp0... ppp0: ppp 2.1.2 started by ppp0: Connect: ppp0 <--> /tyCo/1 ppp0: sent [LCP ConfReq id=0x3 ] ppp0: sent [LCP ConfReq id=0x3 ] ppp0: sent [LCP ConfReq id=0x3 ] ppp0: sent [LCP ConfReq id=0x3 ] ppp0: sent [LCP ConfReq id=0x3 ] ppp0: timeout: could not establish link with peer. Can't load boot file!! ppp0: sent [LCP TermReq id=0x4] If I hook up COM2 on my PC to hyperterm, I see binary characters coming in. But NT never responds to any of these LCPs. Any ideas what could be going wrong? Thanks. - -- Rick Busser rickb@sitera.com Software Engineer (303) 651-1935 x256 SiTera Corporation (303) 651-1199 fax 1820 Lefthand Circle Longmont, CO 80501 --------------------------- Newsgroups: comp.os.vxworks Subject: ScsiMgr task? Date: Thu, 31 Dec 1998 10:52:04 +0900 From: Sang-Min Lee Organization: ETRI Message-ID: <368AD8C3.965C8F0D@puddle.etri.re.kr> Hi I want to know about the internal operations of scsi driver. If any system has many SCSI contollers and devices, then ScsiMgr tasks as many as controllers are spawned with same task priority. ^^^^^^^^^^^^^^^^^ How do those tasks perform? In the case of our system(5 contollers and one disk per controller), the system dies during boot.(tasks conflict?) have a happy holidays~ --------------------------------------------------------------- + Lee Sang Min + Input/Output System Research Team + Computer System Division, Computer & Software Institute + Electronics and Telecommunications Research Institute + (Home) http://puddle.etri.re.kr/~smlee + (Tel) 82-42-860-4926 --------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: segmented memory Date: Thu, 31 Dec 1998 05:32:51 GMT From: keshavbc@my-dejanews.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <76f2a4$1q3$1@nnrp1.dejanews.com> hi, does vxWorks use segmented memory or a flat memory addressing ? - -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own --------------------------- Newsgroups: comp.os.vxworks Subject: I'm looking for development work Date: Wed, 30 Dec 1998 20:55:52 -0700 From: Ryan Pedersen Message-ID: <368AF5C4.ACF248A6@hotmail.com> I'm looking for some a C/C++ development work. I have 6 years working with vxWorks. If interested, I will send you my resume in word format. ryan_pedersen@hotmail.com Ryan Pedersen --------------------------- End of New-News digest **********************