From biocca@bevsun.bev.lbl.gov Wed Apr 1 07:43:57 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Wed Apr 1 07:44:04 PST 1992 Subject: news to exploder feed problems There has been a drop in the newsgroup to exploder feeds. This resulted from loss of files during 'disk full' conditions that were resolved awhile back, but the file loss was not noticed until now. The repair will likely result in some duplication of older netnews articles in the feed to the exploder tomorrow morning. Alan K Biocca Exploder Maintainer From bernard@aar.alcatel-alsthom.fr Wed Apr 1 11:48:52 1992 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Wed Apr 1 11:48:59 PST 1992 Subject: Slip & flow control 1- First question: SLIP and flow control ---------------------------------------- We are using SLIP over a serial radio modem link and it seems that SLIP does not handle RTS / CTS protocol. This increases the number of retransmissions when our modem is overloaded and sometimes leads to connection breaks. I tried to modify the hardware initialization in "tyCoInitChannel": *cr = SCC_WR0_SEL_WR3; /* write reg 3 - receiv *cr = SCC_WR3_RX_8_BITS | SCC_WR3_RX_EN | SCC_WR3_AUTO_EN; ------------------ <- my modification in order to prevent the transmitter from sending bytes when CTS is low on our modem but since SLIP is interfaced with the ty driver this seems to have no effect .. Has anybody got a solution ? 2- Strange things ... --------------------- We use SLIP as a second link beetwen a mobile robot and our stations: UNIX gateway --- | |---| radio modem | --- | ----------------------------------- | ethernet | | -------------------------- | CPU1 | CPU2 | ... CPU4 | CPUi: MV147 -------------------------- | VME bus | radio modem |- We first boot via ethernet and then switch to SLIP to remove the ethernet cable. We notice the following things: 1- rlogin works on CPU2 ... CPU4 but not on CPU1 (the vxWorks gateway) 2- idem for NFS. We can load or list files on CPU2 ... CPU4 but not on CPU1. Has anybody and explanation or solution ? Thanks for any advice -- Olivier ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ----------------------------------------------------------- From purtell@csd.nad.northrop.com Wed Apr 1 12:17:46 1992 From: Russ Purtell Date: Wed Apr 1 12:17:54 PST 1992 Subject: VxWorks Job Opportunities Northrop Aircraft Division is looking to hire an Engineer (preferably Senior) to support the activities of a research laboratory conducting real-time aircraft simulations. Responsibilities include the production of real-time Ada code, embedded systems integration, and the development of hardware specific device drivers. Knowledge of the VxWorks real-time operating system is necessary. Familiarity with Sun workstations, local area networks, the Ada programming language, Motorola 680x0 processors, digital circuitry, and control theory are desirable. Prefer 4 years of experience plus BS in Electrical Engineering/Computer Science or equivalent. Please respond to Russ Purtell Northrop Corporation Orgn. 3832/62 One Northrop Ave. Hawthorne, CA 90250-3296 (310) 332-6909 purtell@csd.nad.northrop.com From stevem@assip.csasyd.oz.au Wed Apr 1 22:19:45 1992 From: stevem@assip.csasyd.oz.au Date: Wed Apr 1 22:19:54 PST 1992 From stevem@assip.csasyd.oz.au Thu Apr 2 14:57:07 1992 Received: from condor.anzac by assip.csasyd.oz.au (4.1/ASSIP-V1) id AA18350; Thu, 2 Apr 92 14:57:07 EST Received: by condor.anzac (4.1/SMI-4.1) id AA16839; Thu, 2 Apr 92 14:57:08 EST Date: Thu, 2 Apr 92 14:57:08 EST From: stevem@assip.csasyd.oz.au (Steven McCoy) Message-Id: <9204020457.AA16839@condor.anzac> To: vxwexplo%lbl.gov@metro.ucc.su.oz Subject: BOOTP Cc: stevem@condor I've heard BOOTP mentioned a number of times on the exploder. As indicated in the modification dates of our current version, it seems to have come and gone before our time. Can anyone tell me exactly what it was used for and if it's still in current use. /* usrConfig.c - user defined system configuration module */ 12x,02oct90,jcc removed code associated with INCLUDE_BOOTP. 12f,07may90,hjb added support for BOOTP forwarding. Thanks in anticipation, Steven McCoy Computer Sciences of Australia P/L stevem@assip.csasyd.oz.au From daemon@vxw.ee.lbl.gov Thu Apr 2 04:00:59 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 2 04:01:20 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 2 04:00:49 PST 1992 Subject: Task stacks & vxgdb Subject: Re: GCC-2.0 Subject: Taking down a network... Subject: Re: Bus Error on Valid Address Subject: Re: Bus Error on Valid Address --- same experience - Xylogics 7800 Subject: Re: taking down a network... Subject: Re: Taking down a network... Subject: Re: Taking down a network... Subject: Why -msoft-float in MV133 Makefile? Subject: RE: Why -msoft-float in MV133 Makefile? Subject: Re: GCC-2.0 Subject: Re: GCC-2.0 Subject: Query: SONIC driver Subject: Re: Sockets and clocks. Subject: Re: Taking down a network... Subject: Re: Why -msoft-float in MV133 Makefile? Subject: Re: Sockets and clocks. Subject: X.25 on vxWorks Subject: SCSI tape Subject: CFT: West Coast VxWorks Users Group Meeting Subject: gnu run time library Subject: Porting to vxworks Subject: Re: Receiving Broadcast messages via UDP sockets Subject: Remote program execution Subject: Re: Remote program execution Subject: VADSWorks time-slicing question Subject: Re: WRS Tech Notes Subject: re: booting Subject: rlogin to a target clobbers remote user name Subject: Low power VME termination Subject: RPCs and sockets Subject: Re: rlogin to a target clobbers remote user name Subject: Re: Low power VME termination Subject: Re: rlogin to a target clobbers remote user name Subject: Share a room at user group meeting? Subject: Re: Low power VME termination Subject: Re: RPCs and sockets Subject: Re: gcc -ansi with 5.0 Subject: Re: gcc -ansi with 5.0 Subject: Re: RPCs and sockets Subject: Re: gcc -ansi with 5.0 Subject: Re: exabyte.h file Subject: TCP Bandwith on VxWorks Subject: WANTED: Bay Area VxWorks person - contract work ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Task stacks & vxgdb Date: 9 Mar 92 18:48:02 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) I've run into a strange interaction between vxgdb and an attached task's stack: It looks as though vxgdb can use the area of the stack that is also used by dynamic variables declared in the task's main routine. I'm circumventing the problem by avoiding dynamic variables in the main routine, but it still looks like an unwanted feature (not to use the B-word...) to me. I don't recall seeing any warnings in the manuals about declaring dynamic variables - did I miss something? One other thing: Sometimes, after attaching to a pending task (say, in a msgQReceive()), the attaching doesn't seem to take place; I give a `next' command to gdb to complete the system call, cause whatever is necessary to send that message, and the supposedly attached task just comes alive as it would without gdb at this point. The `next' command never returns. Anyone else see this behavior? It only happens occasionally. Other than that, I think vxgdb is just great. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ I am a .signature virus. Copy me into your .signature today! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC-2.0 Date: 9 Mar 92 20:51:56 GMT From: marcu@leland.Stanford.EDU (Marc Albert Ullman) Organization: DSG, Stanford University Message-ID: <1992Mar9.205156.27189@leland.Stanford.EDU> References: <9202242233.AA12941@cutter.ssd.loral.com> In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes: >So, now that gcc-2.0 has been released, has anybody tried it with >VxWorks yet? I have built and installed it (as a Sun4 to 68k cross-compiler). I haven't tried rebuilding anything with it myself, but none of our other users have complained of any problems with it. - --Marc Ullman Stanford University P.S. Getting it to build the target version of libgcc.a is a little tricky. The cross-compiler needs to be able to find VxWork's version of stdio.h in order for this to complete successfully. --------------------------- Newsgroups: comp.os.vxworks Subject: Taking down a network... Date: Tue, 10 Mar 1992 13:45:40 GMT From: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Message-ID: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU> Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) Sender: usenet@murdoch.acc.Virginia.EDU I have been re-writing a driver for an 82586 ethernet controller for a VxWorks port to a custom embedded controller. Ialready have a working driver hacked from an existing 82596 driver so I do have network capabilities on the board. What I would like to do is load the new driver over the network, take down the existing driver and start up the new one. Otherwise I have to burn EPROMS all the time which is a pain, (also VxWorks doesn't seem to let me put breakpoints in EPROM resident routines). The question I have is resonably simple. How do I stop the old driver in a tidy way and replace it by the new one? I don't want to waste a lot of time trying to search out a bug which was really only due to not taking down the net properly. For your information. The VxWorks kernel is version 5.0.2 running on a 68020 with 256K ram and 512k EPROM. The limited RAM space means that all of the kernel runs from EPROM with only the data and bss segments in RAM. This means that I can't patch usrNetInit() or any of the other kernel routines. All of the RAM is cleared as part of the VxWorks boot sequence so I can't load the driver, disable the network, then reboot which is a trick I have used with other EPROM resident operating systems. Any good ideas would be welcome otherwise I'll have to start burning chips (yeuch).. thanks in advance, Graham Heyes - ------------------------------------------------------------------------------- Graham Heyes CEBAF Physics Division MS 12H Internet: heyes@dadev.cebaf.gov 12000 Jefferson Ave DECnet : dadev::heyes, cebaf::heyes Newport News VA 23606 BITNET : heyes@cebaf Tel: (804) 249-7030 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Bus Error on Valid Address Date: 10 Mar 1992 16:16:06 GMT From: wbrown@beva.bev.lbl.gov (Bill Brown) Organization: Lawrence Berkeley Laboratory, Berkeley Message-ID: <21874@dog.ee.lbl.gov> References: <9203091525.AA00313@spock.sparta.com> Reply-To: wbrown@beva.bev.lbl.gov (Bill Brown) >Dave Gawley Writes: > > > >Has anyone else seen bus errors from VxWorks when accessing valid addresses? > >... a We have had similar problems, altho they may not be not identical. In one case, we found the mv147 would crash if it tried to access the mailbox of an other processor on the bus while a DMA device was running. The '147 was acting as system controller, the secondary processor was a '143. It seems like the system-controller on the '147 gets bent if there is any bus contention. We found that the problem goes away if we use the '143 as the system controller, or if we use a seperate controller such as an '050. I talked to Motorola about problem, as well as a problem that the '147 has when dealing with multiple backplane interrupts. There answer was esentially that the '147 has no such problems; however I notice that the newer processor boards ('167?) do not use the same VME interface chip. The '143 does not use the same chip either. In short - IMHO the '147 sucks as a bus controller and should not be used as such in a multi-processor system; nor should it be used in any system that will have intense backplane interrupt traffic which the '147 will need to respond to. Other than that, it's a great board. Disclaimer: These opinions are my own and have | nothing to do with the official policy or the | -bill management of L.B.L, who probably couldn't | wlbrown@lbl.gov care less about employees who play with trains. | --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Bus Error on Valid Address --- same experience - Xylogics 7800 Date: Tue, 10 Mar 1992 20:07:05 GMT From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) Organization: TH-Darmstadt Message-ID: References: <9203091525.AA00313@spock.sparta.com> <21874@dog.ee.lbl.gov> Sender: news@infoserver.th-darmstadt.de (The Usenet-News System) 1) We tried to use various versions of MVME147 in multiprocessor setups. 2) Given that MVME147 was busmaster, we saw real _strange_ behaviour. 3) Writing with a DMA-device (Xylogics-7800 IPI controller) into the DRAM of a MVME147 triggered DMA-errors on the Xylogics. We had to lower dma chunk size to 16, resulting in only 4 consecutive accesses to the DRAM and releasing thereafter. As much as we could prove, this was not a fault caused by the Xylogics equipment. 4) VMExec running on a MVME147 host under Unix and a MVME147 as target running (in fact) pSOS, would hang from time to time --- bus error. Plain fun to reboot the Unix host and fsck the disks three times a day.... 5) Or even more strange, having transferred several MBytes over the VMEBus between host and target, one of the SCSI-controllers would hang resulting in same procedure as in (4). Might point again to problems around arbitration. 6) I doubt very that this behaviour results from bus time out, our fastest timer was set to more than 150 usecs.... 7) I suspect much more problems around ROR / ROD and bus arbitratration. More or less I am convinced, their VMEBus chip does not work as advertised...( Or to say it frank... It is not even B...S..T, later would fertilize the soil). #flame starts 8) It would have been very nice, if Motorola had confessed these problems, but the denied any known problem. Last November we solved it on our own, but a workaround would have saved us about half a year. 9) Beyond the arbitration problem the MVME147 lacks real DMA support for their SCSI controller (WD39C93), which dates itself from acient times. Their ethernet controller and supporting software in sysV68 does not show up to date performance, it barely reaches 1/10 of the performace of a nearby SUN 3/160 (70kB/s against 700kB/s running ftp to the same ftp server). 10) How many waitstates does the CPU need to access DRAM? How about ten? 10) Beside already mentioned problems and design flaws, the MVME147 is a great board to spend one's time with it .... # flame off best regards, adams --------------------------- Newsgroups: comp.os.vxworks Subject: Re: taking down a network... Date: 10 Mar 92 19:52:59 GMT From: hwajin@iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: <6602@mondo.iphasew.com> >>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes) said: Graham> I have been re-writing a driver for an 82586 ethernet Graham> controller for a VxWorks port to a custom embedded controller. Graham> Ialready have a working driver hacked from an existing 82596 Graham> driver so I do have network capabilities on the board. What I Graham> would like to do is load the new driver over the network, take Graham> down the existing driver and start up the new one. Otherwise I Graham> have to burn EPROMS all the time which is a pain, (also Graham> VxWorks doesn't seem to let me put breakpoints in EPROM Graham> resident routines). inserting breakpoints == modifying the code (replace the instruction at the given address with trap instruction). obviously it's not possible to do this for the code in eprom. Graham> The question I have is resonably simple. How do I stop Graham> the old driver in a tidy way and replace it by the new one? I Graham> don't want to waste a lot of time trying to search out a bug Graham> which was really only due to not taking down the net properly. Graham> For your information. The VxWorks kernel is version 5.0.2 Graham> running on a 68020 with 256K ram and 512k EPROM. The limited Graham> RAM space means that all of the kernel runs from EPROM with Graham> only the data and bss segments in RAM. This means that I can't Graham> patch usrNetInit() or any of the other kernel routines. All Graham> of the RAM is cleared as part of the VxWorks boot sequence so Graham> I can't load the driver, disable the network, then reboot Graham> which is a trick I have used with other EPROM resident Graham> operating systems. do the following from VxWork shell: - -> myifp = ifunit("xx0") - -> if_dettach(myifp) *hwajin - -- Interphase West Santa Clara, CA --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Taking down a network... Date: 10 Mar 92 19:46:40 GMT From: hwajin@mondo.iphasew.com (Hwa-Jin Bae) Organization: /u/koosh/hwajin/.organization Message-ID: References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU> Sender: hwajin@iphasew.com >>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes) said: Graham> I have been re-writing a driver for an 82586 ethernet Graham> controller for a VxWorks port to a custom embedded controller. Graham> Ialready have a working driver hacked from an existing 82596 Graham> driver so I do have network capabilities on the board. What I Graham> would like to do is load the new driver over the network, take Graham> down the existing driver and start up the new one. Otherwise I Graham> have to burn EPROMS all the time which is a pain, (also Graham> VxWorks doesn't seem to let me put breakpoints in EPROM Graham> resident routines). inserting breakpoints == modifying the code (replace the instruction at the given address with trap instruction). obviously it's not possible to do this for the code in eprom. Graham> The question I have is resonably simple. How do I stop Graham> the old driver in a tidy way and replace it by the new one? I Graham> don't want to waste a lot of time trying to search out a bug Graham> which was really only due to not taking down the net properly. Graham> For your information. The VxWorks kernel is version 5.0.2 Graham> running on a 68020 with 256K ram and 512k EPROM. The limited Graham> RAM space means that all of the kernel runs from EPROM with Graham> only the data and bss segments in RAM. This means that I can't Graham> patch usrNetInit() or any of the other kernel routines. All Graham> of the RAM is cleared as part of the VxWorks boot sequence so Graham> I can't load the driver, disable the network, then reboot Graham> which is a trick I have used with other EPROM resident Graham> operating systems. do the following from VxWork shell: - -> myifp = ifunit("xx0") - -> if_dettach(myifp) *hwajin - -- Interphase West Santa Clara, CA --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Taking down a network... Date: Tue, 10 Mar 1992 21:56:32 GMT From: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Message-ID: <1992Mar10.215632.485@murdoch.acc.Virginia.EDU> References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU> Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) Sender: usenet@murdoch.acc.Virginia.EDU In article , hwajin@mondo.iphasew.com (Hwa-Jin Bae) writes: |>In-reply-to: heyes@dadev.cebaf.gov's message of 10 Mar 92 13:45:40 |>GMT |> |>>>>>> On 10 Mar 92 13:45:40 GMT, heyes@dadev.cebaf.gov (Graham Heyes) |>said: |> |>Graham> I have been re-writing a driver for an 82586 ethernet |>Graham> controller for a VxWorks port to a custom embedded |>controller. |>Graham> Ialready have a working driver hacked from an existing 82596 |>Graham> driver so I do have network capabilities on the board. What |>I |>Graham> would like to do is load the new driver over the network, |>take |>Graham> down the existing driver and start up the new one. Otherwise |>I |>Graham> have to burn EPROMS all the time which is a pain, (also |>Graham> VxWorks doesn't seem to let me put breakpoints in EPROM |>Graham> resident routines). |> |>inserting breakpoints == modifying the code (replace the instruction |>at the given address with trap instruction). obviously it's not |>possible to |>do this for the code in eprom. |> Sorry but I have used several debuggers which allow this they work by making a copy of the code in RAM, correcting any absolute references correspondingly and executing that, essentially using the cpu as a cpu - emulator. I don't remember the specifics because I never took on apart completely but I do know that there are "tricks" which allow you to do it. This is probably heavy for VxWorks since most systems are RAM resident. I was just pointing out that it would be nice to put my driver in RAM so that I can use all of the debugging tools VxWorks provides since they are not aimed at development of rom esident code. Graham --------------------------- Newsgroups: comp.os.vxworks Subject: Why -msoft-float in MV133 Makefile? Date: 11 Mar 92 20:09:15 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Subject line kinda summarizes it: The MV133XT has an 68882, yet the Makefile in config/mv133 (under 5.0.2(b)) defines -msoft-float. Oversight or intentional? - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Fast, Cheap, Good: Choose Any Two --------------------------- Newsgroups: comp.os.vxworks Subject: RE: Why -msoft-float in MV133 Makefile? Date: Wed, 11 Mar 92 20:23:40 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) OK, so further inspection shows that somehow the floating point calls are vectored to _mathHard* calls, which show an abundance of instructions beginning with "F", i.e. it uses the FPC after all. Pretty strange...but I'm sure there is a good reason, right? - -hp - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Fast, Cheap, Good: Choose Any Two --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC-2.0 Date: 11 Mar 92 20:59:07 GMT From: bob@jupiter.UUCP (Bob Schulman) Organization: Jupiter Systems, Alameda, CA Message-ID: <1260@jupiter.UUCP> References: <1992Mar9.205156.27189@leland.Stanford.EDU> From article <1992Mar9.205156.27189@leland.Stanford.EDU>, by marcu@leland.Stanford.EDU (Marc Albert Ullman): > In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes: >>So, now that gcc-2.0 has been released, has anybody tried it with >>VxWorks yet? > > I have built and installed it (as a Sun4 to 68k cross-compiler). I haven't > tried rebuilding anything with it myself, but none of our other users have > complained of any problems with it. I have built and tested the X server using gcc 2.0 on top of a gcc 1.3 vxWorks. I am not impressed. Some things are faster under 2.0 (only a few). Some things are slower (more than a few). Overall, I'd say slower. Also, gcc 2.0 takes *alot* more time to compile than 1.3. This would be OK if the results were significantly better than 1.3. In my case this was not the case. bob --------------------------- Newsgroups: comp.os.vxworks Subject: Re: GCC-2.0 Date: 12 Mar 92 00:54:17 GMT From: bard@cutter.ssd.loral.com (James Woodyatt) Organization: Space Systems/Loral Message-ID: <1992Mar12.005417.5567@wdl.loral.com> References: <1992Mar9.205156.27189@leland.Stanford.EDU> <1260@jupiter.UUCP> Sender: bard@cutter (James Woodyatt) In article <1260@jupiter.UUCP>, bob@jupiter.UUCP (Bob Schulman) writes: |> From article <1992Mar9.205156.27189@leland.Stanford.EDU>, by marcu@leland.Stanford.EDU (Marc Albert Ullman): |> > In article <9202242233.AA12941@cutter.ssd.loral.com> bard@cutter.ssd.loral.com (James Woodyatt) writes: |> > >So, now that gcc-2.0 has been released, has anybody tried it with |> > >VxWorks yet? |> > |> > I have built and installed it (as a Sun4 to 68k cross-compiler). I haven't |> > tried rebuilding anything with it myself, but none of our other users have |> > complained of any problems with it. |> |> I have built and tested the X server using gcc 2.0 on top of a gcc 1.3 vxWorks. |> I am not impressed. Some things are faster under 2.0 (only a few). |> Some things are slower (more than a few). Overall, I'd say slower. Is this with the -O flag or with -O2 or -O3? I've seen postings on the gnu newsgroups showing the benchmark comparisons between gcc-1.40 and gcc-2.0. They indicated that the -O flag in gcc-2.0 produces slower code than it did for gcc-1.40, but using the -O2 and -O3 gave progressively better results -- to the point where it surpassed gcc-1.40. However, this was all on a sun4 configured as a native compiler. - -- James Woodyatt Space Systems/Loral Palo Alto, CA bard@cutter.ssd.loral.com ``I like your proposed schedule, but I think it's unnecessarily realistic.'' --Anonymous --------------------------- Newsgroups: comp.os.vxworks Subject: Query: SONIC driver Date: 12 Mar 92 20:16:10 GMT From: hwajin@mondo.iphasew.com (Hwa-Jin Bae) Organization: /u/koosh/hwajin/.organization Message-ID: Sender: hwajin@iphasew.com does anyone have a driver for sonic (national semi. dp83932b)? thanks. *hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Sockets and clocks. Date: Fri, 13 Mar 1992 16:59:42 GMT From: bgeer@javelin.sim.es.com (Bob Geer) Organization: Evans & Sutherland Computer Corporation Message-ID: <1992Mar13.165942.862@javelin.sim.es.com> References: <9203121924.AA00658@spock.sparta.com> Reply-To: bgeer@javelin.sim.es.com >>1. What is the best means of communication over the ethernet, where data >> rates are important? We're using the MVME-147 in a flight simulation task where Ethernet i/o will be running 50Hz or 60Hz. We decided to drop below the socket i/o level for increased efficiency, so we wrote a simple pair of functions, enetserverRead() & enetserver() that can efficiently process our time-critical incoming Ethernet packets. First, a task is spawned consisting of the function enetserver() which creates a semaphore, calls the etherInputHookAdd(enetserverRead) library routine, & starts a "while (TRUE)" loop that begins with semTake(). Packet processing functions are called once the semaphore is given by enetserverRead(), & then the "while" loop continues. The function enetserverRead() is inserted into the Ethernet packet processing stream by "etherInputHookAdd(enetserverRead)". It checks the source address, destination address, & data content of a received packet, returns FALSE if further processing of the packet is required (say, by NFS or socket routines), & returns TRUE if the packet requires no further processing. If the data is to be processed, the packet's data is transfered into a local buffer for the enetserver() routine mentioned below, & the semaphore is given to initiate the processing. An Ethernet packet may be sent using the etherOutput() library routine. The format of the packet header is: /* * ethernet packet layout * * data length doesn't include 1st 14 bytes -- s & d addrs & length * * ethernet destination addr msw = (packet_buffer + 0); * ethernet destination addr mw = (packet_buffer + 2); * ethernet destination addr lsw = (packet_buffer + 4); * ethernet source addr msw = (packet_buffer + 6); * ethernet source addr mw = (packet_buffer + 8); * ethernet source addr lsw = (packet_buffer + 10); * data length (bytes) = (packet_buffer + 12); * [1st data byte] = (packet_buffer + 14); * [46 bytes mininum length] */ The downside, of course, is these addr's are the Ethernet chip addresses instead of something more easily determined such as internet addresses & aliases. But it's fast & efficient enough for our requirements. - -- <> Bob `Bear' Geer <> bgeer@beorn.sim.es.com / <> <> <> (this *often* works) __o o ,______/o <> <> Salt Lake City, <> speaking only for myself, -\<, <\ ,__/ > <> <> Ootah <> one of my many tricks O/ O __ /__, / <> --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Taking down a network... Date: 11 Mar 92 14:21:59 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550004@hppad.waterloo.hp.com> References: <1992Mar10.134540.23961@murdoch.acc.Virginia.EDU> heyes@dadev.cebaf.gov (Graham Heyes) wrote: > The question I have is resonably simple. How do I stop the old driver > in a tidy way and replace it by the new one? I don't want to waste a lot of > time trying to search out a bug which was really only due to not taking down > the net properly. I would think that an "if_down(ifp)" [at splnet] followed by "ifreset()" if all net interfaces are being cleared [otherwise "eiReset(unit)" or equivalent driver routine], then turn off interrupts and last, an "if_dettach(ifp)". You ought to be able to start up cleanly after this by calling the new driver's attach routine and doing an ifAddrSet(). The 82596 seems to restart OK under these conditions (and network code ought to be happy). Ted Rypma HP Panacom Division Waterloo, Ontario --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Why -msoft-float in MV133 Makefile? Date: Wed, 11 Mar 1992 22:15:14 GMT From: geoff@wrs.com (Geoff Espin) Organization: Wind River Systems, Inc. Message-ID: References: Sender: usenet@wrs.com (News Manager) hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: >Subject line kinda summarizes it: The MV133XT has an 68882, yet the >Makefile in config/mv133 (under 5.0.2(b)) defines -msoft-float. >Oversight or intentional? The mv133 BSP supports the MVME-133, MVME-133A, MVME-133XT and MVME-134. Only the MVME-133XT has an FPU, if I recollect correctly. The MVME-134 has an MMU. Geoff - -- Thanks, Geoff - --- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Sockets and clocks. Date: 17 Mar 92 04:35:08 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Mar17.043508.9899@afterlife.ncsc.mil> References: <9203121657.AA01433@nettlerash.berkeley.edu> In article <9203121657.AA01433@nettlerash.berkeley.edu> hebo@mbari.org (Bob Herlien) writes: >I ported NTP (version 1) to VxWorks several months ago. It's on the >archives at thor.atd.ucar.edu, in files ntpvx*. I haven't gotten around >to trying to port version 3, and may never do so (it will require a large >rework to get rid of dependencies on async I/O, which VxWorks doesn't support). APLabs sells a VxWorks asynchronous I/O library. Can I assume that this would make the NTP 3.0 port easier? - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: X.25 on vxWorks Date: 17 Mar 92 21:20:31 GMT From: smeg@bnr.ca (Maarten Koning) Organization: Bell-Northern Research Ltd. Keywords: X.25 Message-ID: <1992Mar17.212031.14443@bnr.ca> Reply-To: smeg@bnr.ca Sender: news@bnr.ca (usenet) Hi, Does anyone offer an X.25 protocol stack for vxWorks? Any references or sharing of experiences would be appreciated. Thanks, Maarten Koning - -- //include1 pgm=disclaimer,parm='my opinions only' Maarten Koning | Internet: smeg@bnr.ca | Phone: (613) 763-8796 BNR Ltd. | This space for rent | FAX: (613) 763-2626 --------------------------- Newsgroups: comp.os.vxworks Subject: SCSI tape Date: Wed, 18 Mar 92 19:50:05 GMT From: singer@ll.mit.edu (Matthew R. Singer) Organization: MIT Lincoln Laboratory Message-ID: <1992Mar18.195005.28392@ll.mit.edu> Reply-To: singer@ll.mit.edu (Matthew R. Singer) Sender: singer@ll.mit.edu (Matthew R. Singer) - -- Anyone know of a PD or commercial set of routines for driving SCSI tape devices? Exebyte 8500 in particular.. Thanks ----------------------------------------------------------------------------- Matthew R. Singer MIT Lincoln Laboratory (617) 981-3771 244 Wood Street singer@ll.mit.edu Lexington, MA 02173 - ----------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: CFT: West Coast VxWorks Users Group Meeting Date: 18 Mar 92 21:57:21 GMT From: sjk@crl.labs.tek.com (Steven King) Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <3825@crl.LABS.TEK.COM> Followup-To: comp.os.vxworks Reply-To: sjk@crl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM Call for Talks West Coast VxWorks Users Group Meeting April 10, 1992 Newport Beach, CA A significant body of experience in the design and implementation of VxWorks applications has been developed over the last few years, both through research prototypes and industrial products. Given the growth of the off-the-shelf real-time development systems market, and the growth of VxWorks in particular, the time seems right to share our knowledge base so that we can impact the future of real-time systems development using VxWorks. Examples of interesting applications include state-of-the-art networking (e.g. SNMP, bootp, tftp, TLI), object-oriented languages, multi-processor applications, unique device interfaces, extensions of the VxWorks development environment, etc. Examples of useful paradigms for structuring VxWorks-based systems are object-oriented design, client-server models, minimal-kernel based applications, enforced deadline-scheduling algorithms, etc. This meeting should be the occasion for the VxWorks community to share the experiences on which their practice is based. In addition, we should use this opportunity to communicate to Wind River Systems our view of where the discipline of real-time applications development is heading. There will be two disctinct forums for users to share their experiences: 1) the applications presentation, where users will discuss their work with VxWorks and 2) the issues forum, which will allow users to present current limitations of VxWorks, along with potential solutions to these challenges. Each talk will run between ten and fifteen minutes in length. The atmosphere will be informal. We would all appreciate hearing about your VxWorks experiences. If you wish to participate, please submit a brief outline of your talk (two or three paragraphs) to: Steven King Software Technology Research Labs Tektronix, Inc. Telephone: 503-627-2736 Fax: 503-627-5502 Voice Mail: 503-727-6651 e-mail: sjk@crl.labs.tek.com Please include an electronic mailing address (if you have one) in your outline. We will need a paper copy of all handout and overhead materials. The meeting minutes including materials from all talks will be published by Wind River Systems. --------------------------- Newsgroups: comp.os.vxworks Subject: gnu run time library Date: 18 Mar 92 22:15:06 GMT From: votava@fndaud.fnal.gov (Margaret Votava) Organization: Fermi National Accelerator Laboratory, Batavia IL Message-ID: <1710@fnnews.fnal.gov> Sender: news@fnnews.fnal.gov Hi, Has anybody ported the gnu run time library (I believe it's called GLIB) to vxworks? We are trying to port some code to a vxworks target, but it makes several references to normal c run time library functions that are not supported in the WRS distribution. Thanks, Margaret Votava Fermilab (708)-840-2625 --------------------------- Newsgroups: comp.os.vxworks Subject: Porting to vxworks Date: 20 Mar 92 19:16:51 GMT From: mitchs@netcom.com (Mitch Stermer) Organization: Netcom - Online Communication Services (408 241-9760 guest) Message-ID: <1a#jtrnmitchs@netcom.com> References: <9203201801.AA05511@lodestar.gb.nrao.edu> I am looking a port a application that runs unders Unix SysV, ULTRIX, OS/2 and AIX 3.2 to vxworks. Most the the code was written following the POSIX 1003.1 base os standard for things as file system access, host name and the like. I am new to vxworks and haven't seen anything that shows that it has those interfaces. I know I will have to rewrite the message and semaphore code, but I was hoping the majority of the other code would come right over. Has anyone done a port of this nature to vxworks? Could any of you share the experience that you have had porting to this? Thanks mitchs - -- Mitch Stermer (System Slave) mitchs@netcom.COM --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Receiving Broadcast messages via UDP sockets Date: 21 Mar 92 01:53:34 GMT From: hwajin@pogo.omni.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <9203192129.AA27642@hns.com> Sender: hwajin@iphasew.com contrary to what's been already said, broadcasting using udp works fine with vxworks. i'd like to see the program that doesn't work. *hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Remote program execution Date: Mon, 23 Mar 92 22:41:01 GMT From: mkb+@cs.cmu.edu (Mike Blackwell) Organization: School of Computer Science, Carnegie Mellon Message-ID: <1992Mar23.224101.197222@cs.cmu.edu> Let's say I have a VxWorks box booting off a Unix box. In it's init file, VxWorks loads all of its code. At some later point, I'd like the Unix box to tell the VW box to execute a program. Is there any way to do this? Something simple like rsh would be ideal. Rsh doesn't work, but maybe something similar that would rlogin and shove some input to the VW console? Any ideas or solutions? Mike Blackwell mkb@cs.cmu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Remote program execution Date: 24 Mar 92 15:29:03 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <1992Mar23.224101.197222@cs.cmu.edu> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Well, simply redirecting input at the unix side works, i.e. rlogin target < command-script Then, there is th vxrsh package, available from the vxWorks archives, via ftp thor.ucar.edu. I haven't tried it myself. If you have multiple CPUs, you can also have a script on the "main" CPU rlogin to secondaries, with input redirected from startup scripts for the individual board. It's somewhat of a kludge, but it has worked for me for quite a while, and I only have to manually invoke one main script that starts up everything in the system. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ I am a .signature virus. Copy me into your .signature today! --------------------------- Newsgroups: comp.lang.ada,comp.os.vxworks Subject: VADSWorks time-slicing question Date: 24 Mar 92 03:44:56 GMT From: jeffm@assip.csasyd.oz.au (Jeff Melvaine) Organization: Computer Sciences of Australia Keywords: Ada VADS Message-ID: Reply-To: jeffm@assip.csasyd.oz.au Thank you to all who responded to my question. We appreciate the variety of insights and perspectives gained from the answers, and our quandary has been resolved. > This question is addressed to those familiar with the Sun VADSWorks system for > Sun-4 and/or 680x0 targets. Our system designers wish the code to run with > time slicing disabled for reasons of efficiency. (We are aware of the > consequences of blocking a lightweight task in this mode of operation). The > discussion point is that there are two ways of disabling time slicing: > statically (by modifying the VADS kernel configuration table entry), and > dynamically (by calling a subprogram in package vx_tasking). The latter appears > to require less work to set up. Is there any reason to prefer the static > method? > From: "David L. Levine" It doesn't require the addition to the code that would impair portability. I use the static approach to avoid implementation dependencies in my code. On the other hand, if you know that the code will always be used in a VADS environment, turning time slicing off in the code is much more visible than the modified ada.lib. David L. Levine Internet: levine@ics.uci.edu UUCP: uunet!ucivax!levine BITNET: levine@uci > I would expect that the effect of calling vx_tasking.set_time_slicing_enabled > was to enable/disable delivery of a periodic SIGALRM to trigger rescheduling, > and that choice between the two methods is largely a matter of style. I would > appreciate input from anyone who can shed more light on this. > From: esther%verdix.com@metro.ucc.su.OZ.AU (Esther Lumsdon) Several of the vx_tasking calls "queue" actions that will take effect the next time the kernel code is run. This is not intuitive. Sorry about that. set_time_slicing_enabled is one of those. (I think that all of the time slice manipulation calls are.) To make the set_time_slicing_enabled take effect, follow it by a delay (0.0) statement. This will enter the kernel, and your change will take effect. Generally, customers find that they need to alter the default task stack size, or change the memory allocation method, so they statically set time slicing since they have to build a usr_conf library anyway. And they avoid that delay (0.0) statement. - ------ Esther Lumsdon Product Support Engineer, Verdix Corporation 205 Van Buren St Herndon, Virginia, USA esther@verdix.com or esther%verdix.com@uunet.uu.net From: bobf%verdix.com@metro.ucc.su.OZ.AU Jeff, after reading your post, I uncovered a slight deficiency in our usr_conf implementation. There are actually *three* ways to enable time-slicing in a VADSworks application. One of these ways unfortunately does not work. (1) In file v_usr_conf_b.a in library usr_conf, configuration section #c2d provided the time-slicing defaults: -- #c2d: TIME SLICE CONFIGURATION PARAMETERS: TIME_SLICING_ENABLED => TRUE, TIME_SLICE_INTERVAL => 1.0, As you can see, time-slicing should be enabled by default, yet it is not. There is a slight problem in that at program startup, TIME_SLICING_ENABLED is incorrectly evaluated. As a result, modifying v_usr_conf to enable time-slicing will not work. However, there are two other methods: (2) The VADSexec call V_XTASKING.set_time_slicing_enabled can be used to turn time-slicing on and off. The slice interval is the one in v_usr_conf (this *does* work). This call turns time slicing on for Ada tasks. (3) The VxWorks kernelLib call kernelTimeSlice() turns time-slicing on for all tasks, not just Ada tasks. This call may be invoked from the VxWorks shell, or called from an Ada or C routine. The choice between these three methods is more than stylistic. Modifying v_usr_conf implements changes applied to *all* Ada applications linked with the user configuration. The latter two methods are used on an individual application basis. To summarize, modifying v_usr_conf implements GLOBAL changes, while calling VADSexec/VxWorks routines implement LOCAL changes. Bob Foery Verdix Product Support Engineer bobf@verdix.com From: vestal%src.honeywell.com@metro.ucc.su.OZ.AU (Steve Vestal) Well, I used a beta release of VADSWorks for a Mizar board a couple of years ago. I used the dynamic call to disable time slicing, but in the course of some very detailed benchmarking studies discovered that the runtime system still received and processed a signal at 1 second intervals. My speculation is that the disabling was done inside the runtime SIGALRM handler, rather than by just disabling SIGALRMs. These may possibly be needed for something else (e.g. resuming suspended tasks from the delay queue), and it may not depend on whether disabling is done statically or dynamically. So, no matter what you do, you may get periodic SIGALRMS, but time slicing will be disabled and "unnecessary" context swaps will be eliminated. > Jeff > --------------------------- Newsgroups: comp.os.vxworks Subject: Re: WRS Tech Notes Date: 25 Mar 92 04:11:54 GMT From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Organization: The Great Beyond Message-ID: <1992Mar25.041154.4223@afterlife.ncsc.mil> References: <9203202051.AA27423@yuba.WRS.COM> In article <9203202051.AA27423@yuba.WRS.COM> francis@yuba.wrs.com (Francis St. Amant) writes: > They are available in nicely formatted >(FrameMaker) hardcopy, which makes diagrams and tables come out better. > >They are also available in ascii format by dialling the WRS BBS at >510-814-2165. And Tech Support can email notes to you if you call >them at 800-872-4977 and submit a request, along with your email address. Why doesn't WRS simply POST THEM HERE! Post all existing ones now, and new ones as they become available. They could be part of the archive, and readily available. Put the FrameMaker documents out in MIF format, so those of us with FrameMaker can get the pretty pictures. This will save you on postage and phone bills, too :). - -- Steve M. Burinsky smb@afterlife.ncsc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: re: booting Date: 26 Mar 92 17:29:45 GMT From: brunner@kazoo.ssd.loral.com (Brian Brunner) Organization: Space Systems/Loral Message-ID: <1992Mar26.092945@kazoo.ssd.loral.com> References: <9203260059.AA10280@dtc163.VisiCom.COM> Reply-To: brunner@kazoo.ssd.loral.com (Brian Brunner) Sender: news@wdl.loral.com Our solution to this problem (60-something machines booting at once) was simplified by using a large-enough PROM to hold ALL of vxWorks... plus adding code to copy anything on the floppy disk (if present) to the hard disk, then to search the hard disk for the application to execute. Result: turn-key vxWorks applications. Which IP address the various boards claim is still set in NVRAM, but is profoundly less important and does not effect booting at all. Have a day. - -- HELP!! Somebody slapped a "stop payment" on my sanity check!! brunner@kazoo.ssd.loral.com; Space Systems/Loral; Palo Alto, Calif. Black Holes... the /dev/null of the Universe; the opinion of 65534. --------------------------- Newsgroups: comp.os.vxworks Subject: rlogin to a target clobbers remote user name Date: Thu, 26 Mar 92 19:02:03 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Has anyone else observed this? After a completed rlogin session to a vxWorks target, whoami on that target's console returns a null string. This happens even if I did nothing but rlogin and logout. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Fast, Cheap, Good: Choose Any Two --------------------------- Newsgroups: comp.os.vxworks Subject: Low power VME termination Date: Thu, 26 Mar 92 19:40:44 GMT From: mkb+@cs.cmu.edu (Mike Blackwell) Organization: School of Computer Science, Carnegie Mellon Message-ID: <1992Mar26.194044.23352@cs.cmu.edu> I know this isn't really the right group, but I'm not sure what is, and someone here might know... I have a low power VxWorks real time system (Dynatem boards), and it turns out that almost half of the power going in to the cage is eaten up by the VME bus terminators. Since this is a battery powered system, this is an important issue. Does anyone know of lower power terminators than the usual bank of resistors? I was thinking maybe some sort of active termination. Any advice or pointers would be much appreciated. Mike Blackwell mkb@cs.cmu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: RPCs and sockets Date: 26 Mar 1992 22:02:25 GMT From: lewis@bevsun.bev.lbl.gov (Steve Lewis) Organization: Lawrence Berkeley Laboratory, California Message-ID: <22298@dog.ee.lbl.gov> Sender: Steve Lewis Several articles have raised questions concerning VxWorks speed both at the socket level and at the RPC level. I have made some performance tests, although my notes are lost for the moment. The best results were obtained with a Sparcstation-2 against an MVME-147. I tried many combinations, including Sparc-Sparc, VME-VME across both Ethernet and backplane. Results were: (1) Maximum transactions rates of 550 very short (one long to RPC) round-trips/sec. (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to RPC) copying the data both ways. I concluded that: (1) All all cases were cpu-limited, not medium limited. (2) From previous tests, the 4.3BSD "fix" to the VxWorks TCP/IP stack indeed gave better than 2x improvement. (3) The cost of XDR was well worth the convenience; one could always minimize this with xdr_opaque() in the spirit of ARTSE. (4) One-way network latencies were about 1 msec--tcpdump confirms you can get an RPC on the wire and see the response back on the wire in 1-3 msec. So, the VxWorks implementation of RPC 4.0 works; I have patched a few things (like clnt_sperror()) but have only a dozen lines of #ifdef'd code in order to keep common source in a few *low-level* routines that I hide all my RPC behind. We have an MVME-167 (68040) on hand; I will repeat all my tests and post some accurate numbers for Sparc 1+, Sparc 2, '147, and '167 one of these days. Steve Lewis, Group Leader SALewis@LBL.gov Computer Controls Mail Stop 64-121 Lawrence Berkeley Laboratory Tel: 510/486-7702 Berkeley, CA 94720 Fax: 510/486-5788 - -- Steve Lewis, Group Leader SALewis@LBL.gov Computer Controls Mail Stop 64-121 Lawrence Berkeley Laboratory Tel: 510/486-7702 Berkeley, CA 94720 Fax: 510/486-5788 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: rlogin to a target clobbers remote user name Date: Thu, 26 Mar 1992 23:57:53 GMT From: litwin@litwin.jpl.nasa.gov (Todd Litwin) Organization: Jet Propulsion Laboratory Message-ID: <1992Mar26.235753.12827@elroy.jpl.nasa.gov> References: Sender: news@elroy.jpl.nasa.gov (Usenet) In article hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: > >Has anyone else observed this? > >After a completed rlogin session to a vxWorks target, whoami on that >target's console returns a null string. This happens even if I did >nothing but rlogin and logout. This has existed in VxWorks since version 5.0 (I believe). I spoke to customer support about this last year, and they said it was a known problem. What I don't understand is why it is still present in 5.0.2. You'd think that this would be important enough and simple enough to be history already! - -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 litwin@robotics.jpl.nasa.gov --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Low power VME termination Date: 27 Mar 92 13:23:36 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: References: <1992Mar26.194044.23352@cs.cmu.edu> Sender: news@nic.unh.edu (USENET News System) >>>>> "Mike" == Mike Blackwell writes: Mike> I have a low power VxWorks real time system (Dynatem boards), and it turns Mike> out that almost half of the power going in to the cage is eaten up by the Mike> VME bus terminators. Since this is a battery powered system, this is an Mike> important issue. Does anyone know of lower power terminators than the usual Mike> bank of resistors? I was thinking maybe some sort of active termination. Any Mike> advice or pointers would be much appreciated. Mike> Mike Blackwell mkb@cs.cmu.edu This is typically the case with passive terminators. Dynatem now sells a new actively terminated backplane from Oettle+Reichler that sucks much less juice. Just out of curiosity, are you using the Dynatem boards or the O+R boards that Dynatem distributes? We are using the 3U O+R boards. - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: rlogin to a target clobbers remote user name Date: 27 Mar 92 21:50:20 GMT From: hwajin@mondo.iphasew.com (Hwa-Jin Bae) Organization: /u/koosh/hwajin/.organization Message-ID: References: <1992Mar26.235753.12827@elroy.jpl.nasa.gov> Sender: hwajin@iphasew.com the bugs is due to the new login security code which was added for 5.0 release. workaround is to either enable INCLUDE_SECURITY in usrConfig.c or make a call to loginUserAdd(). see loginLib manual. *hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Share a room at user group meeting? Date: 29 Mar 92 18:42:12 GMT From: mkb+@cs.cmu.edu (Mike Blackwell) Organization: School of Computer Science, Carnegie Mellon Message-ID: <1992Mar29.184212.131752@cs.cmu.edu> If you'd be interested in splitting a room at the user's group meeting at Newport Beach, please send me mail. Mike Blackwell mkb@cs.cmu.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Low power VME termination Date: Mon, 30 Mar 1992 17:17:37 GMT From: rec@coquina.ucsd.edu (Richard Currier) Organization: MPL of SIO at UCSD Message-ID: <1992Mar30.171737.11397@chiton.ucsd.edu> References: <1992Mar26.194044.23352@cs.cmu.edu> Sender: news@chiton.ucsd.edu In article <1992Mar26.194044.23352@cs.cmu.edu> mkb+@cs.cmu.edu (Mike Blackwell) writes: >Does anyone know of lower power terminators than the usual >bank of resistors? I was thinking maybe some sort of active termination. Any >advice or pointers would be much appreciated. > Schroff Inc. makes backplanes with on-board active termination. They also make plug-in, off-board active termination modules that may be used with some non Shroff products. Many distributors will stare blankly at you when you talk about "active termination" but it will save you around an Amp of current draw. richard currier marine physical lab u.c. san diego rec@mpl.ucsd.edu 619-534-1730 - -- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: RPCs and sockets Date: Mon, 30 Mar 1992 21:04:36 GMT From: sns@deimos.caltech.edu (Sam Southard Jr.) Organization: Caltech Astronomy Department Message-ID: <1992Mar30.210436.22129@cco.caltech.edu> References: <22298@dog.ee.lbl.gov> Sender: news@cco.caltech.edu In article <22298@dog.ee.lbl.gov>, lewis@bevsun.bev.lbl.gov (Steve Lewis) writes: |> Several articles have raised questions concerning VxWorks speed both |> at the socket level and at the RPC level. I have made some performance |> tests, although my notes are lost for the moment. The best results were |> obtained with a Sparcstation-2 against an MVME-147. I tried many |> combinations, including Sparc-Sparc, VME-VME across both Ethernet and |> backplane. Results were: |> (1) Maximum transactions rates of 550 very short (one long to RPC) |> round-trips/sec. |> (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to |> RPC) copying the data both ways. |> |> I concluded that: |> (1) All all cases were cpu-limited, not medium limited. You must not have tried very hard with the socket level performance (or I'm reading your article incorrectly). I've seen sustained (several hours) throughputs of over 800KB/sec from a SPARCengine 1E to a SPARCserver 470 or Sun 4/110. What protocol were you using on the socket level? I was using UDP. - -- Sam Southard, Jr. {sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns} --------------------------- Newsgroups: comp.os.vxworks Subject: Re: gcc -ansi with 5.0 Date: 31 Mar 92 13:25:29 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <9203302030.AA10443@cutter.ssd.loral.com> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) I found that in moving to gcc (in the course of upgrading to vx5.0) there were a few minor nuisances: - - gcc (unlike cc) complains about missing parameters to functions, so I had to go and stick in a lot of NULL parameters to satifsy the compiler. OK, so they should have been there in the first place, but they weren't. - - Some of the vxWorks header files (and particularly the function prototypes declared in them) are incorrect or incompatible. For instance, if you include both fioLib.h and iosLib.h (I think those were the ones..), you get duplicate and conflicting declarations of some function prototypes. No big deal, although I hate having to modify files supplied with the OS. It feels like voiding a warranty on a new stereo by taking a soldering iron to it. - - Some files wre shuffled around, like iv68k.h became 68k/iv.h. Everything I've described was very obvious and just required some repetitious editing tasks to get things compiled, so I wasn't too upset. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ Fast, Cheap, Good: Choose Any Two --------------------------- Newsgroups: comp.os.vxworks Subject: Re: gcc -ansi with 5.0 Date: 31 Mar 92 17:14:33 GMT From: sjk@strl.labs.tek.com (Steven King) Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <3973@crl.LABS.TEK.COM> References: <9203302030.AA10443@cutter.ssd.loral.com> Followup-To: comp.os.vxworks Reply-To: sjk@crl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <9203302030.AA10443@cutter.ssd.loral.com>, bard@cutter.ssd.loral.com (James Woodyatt) writes: |> Okay, so I *finally* got some time to upgrade to version 5.0.2 and now |> I've got some questions that are probably easily answered by somebody |> on the exploder: |> |> * What problems are there, if any, with using gcc-2.x with the object |> shipped from WRS? |> |> * Can I really use the -ansi mode in gcc even though the PROM I'm |> burning is all compiled with -traditional? You must use -traditional with any WRS supplied code. They haven't ansi-fied their code yet. My understanding is that they will use -ansi in the next release. We mix objects compiled with -ansi and objects compiled with -tradtional with no problems. If you use bit-fields in structs, beware! When we were using the compiler supplied with 5.0, with the -ansi and -volatile switches, the compiler would emit incorrect bit-field instructions for the 68k. We ended up combing through the code and declaring things as volatile. Using -ansi worked for this case. This problem may be fixed in gcc 2.0. I recommend that you use -traditional until you correct for the WRS changes in 5.0.2, and then use -ansi. This will reduce the number of factors that could cause headaches. Steven - ---------------------------------------------------------------------- e-mail: sjk@strl.labs.tek.com | Steven King phone: 503-627-2736 | Software Technology Research Lab voice mail: 503-727-6651 | Tektronix, Inc. fax: 503-627-5502 | P.O. Box 500 MS 50-662 | Beaverton, OR 97077 - ---------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: RPCs and sockets Date: 1 Apr 1992 16:11:16 GMT From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Organization: Lawrence Berkeley Laboratory, California Message-ID: <22420@dog.ee.lbl.gov> References: <22298@dog.ee.lbl.gov> <1992Mar30.210436.22129@cco.caltech.edu> In article <1992Mar30.210436.22129@cco.caltech.edu> sns@deimos.caltech.edu (Sam Southard Jr.) writes: >In article <22298@dog.ee.lbl.gov>, lewis@bevsun.bev.lbl.gov (Steve Lewis) writes: >> Several articles have raised questions concerning VxWorks speed both >> at the socket level and at the RPC level. I have made some performance >> tests, although my notes are lost for the moment. The best results were >> obtained with a Sparcstation-2 against an MVME-147. I tried many >> combinations, including Sparc-Sparc, VME-VME across both Ethernet and >> backplane. Results were: >> (1) Maximum transactions rates of 550 very short (one long to RPC) >> round-trips/sec. >> (2) Maximum throughput rates of 600KB/sec using very long (8000 bytes to >> RPC) copying the data both ways. >> I concluded that: >> (1) All all cases were cpu-limited, not medium limited. >You must not have tried very hard with the socket level performance (or I'm >reading your article incorrectly). I've seen sustained (several hours) >throughputs of over 800KB/sec from a SPARCengine 1E to a SPARCserver 470 or >Sun 4/110. What protocol were you using on the socket level? I was using UDP. The above tests were using UDP based Sun-RPC with XDR. No particular performance tuning was done, and the code used the RPC library, not dealing with the sockets (if I remember correctly). The object was to measure the capability of the RPC system, not to tweak throughput. The MVME-147 is likely not as quick as a SPARC 1E, and 600/800 KB/sec is a small difference. I think this clearly illustrates that XDR gets a worse rap than it deserves. Alan K Biocca WB6ZQZ Computer Controls Group AKBiocca@lbl.gov Computer Systems Engineering Dept MS 64-121 Lawrence Berkeley Laboratory 510/485-7700 Berkeley, CA 94720 501/486-5788 fax - -------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: gcc -ansi with 5.0 Date: Wed, 1 Apr 1992 17:57:49 GMT From: geoff@wrs.com (Geoff Espin) Organization: Wind River Systems, Inc. Message-ID: References: <9203302143.AA04795@hns.com> Sender: usenet@wrs.com (News Manager) Carl and VxUsers, :-) symborski@hns.com (Carl Symborski) writes: >>* Has anybody had to modify their code to get it work under 5.0 because >> a programmer's interface changed? What trouble could I conceivably >> encounter in porting my code from 4.0.2 to 5.0.2 as a result of some >> goofy programmer in my shop using some weird feature of VxWorks that >> isn't supported in 5.0 anymore? (I've got a crawling horror on my >> hands that was originally developed under 3.0, I think.) >As I recall the renaming of certain "sys" functions to "vx" functions >were particularly irksome. Especially if you are maintaining a bunch of >device drivers. It has been a while but we did get bit by the following: >16jul91,gae changed sysIMR->vxIMR and sysIPNDBitClear->vxIPNDClear Gosh am I, Geoffrey A. Espin (gae) the "goofy programmer" over here? The intent of the these changes was to push the architecture level functions (in this case i960) out of the Board Support Package. My personal apology for the incompatibility, "Sorry". The rationale was: 1. Documentation of architecture specific functions should appear in one consistent place. Of course, WRS still has separate 5.0.[2,3,4] releases for different arch's so presently it is not ideal shifting from the 68K -centric Programmer&Reference Manual to the RISC supplements. 2. The code was reproduced and was completely redundant in the the original 3 BSPs, the tp960, hkv960, and cvme960. Perhaps to a customer this isn't significant as you are probably only using 1 brand name board. For WRS it is a maintenance nightmare. VxWorks is still very "close to the bare metal" -- BSPs and arch's do offer special features that you do want to customize around. The application engineer should try to isolate such h/w dependencies in a separate module when possible. We did weigh in the impact on a few dozen 4.0.2 users versus the future thousands of 5.x.x users. :-) 3. Why didn't we do it right the first time? Evolution. WRS's original motto was "VxWorks: a Revolution in Realtime", in between times, you better evolve or you'll fossilize. :-) I mean to say, that, unfortunately, there are a wealth of design deficiencies in certain areas, particularly BSPs. I say this having been the BSP Group Leader for a few years (not presently), and being, for good or for bad, the final arbiter on many of these crufty implementations. Hate mail to me alone. Our number one priority for many years had been simply to get a new BSP out the door; re-thinking the BSP paradigm always gave way to new ports and then the worry about backward compatibility. So, Carl, I hope I came back to your point of "compatability between versions". WRS does make this as an important goal. Like many S/W companies, it is often reactive "how do we get our butts out of this one", instead of proactive, "let's design this right for the next 20 years" but at the expense of much delayed product shipment. Hopefully, we at least document the "corrections". Hopefully, you are getting a better product. If not, let us know! Geoff - -- - --- Geoff Espin geoff@wrs.com (510)748-4100 Wind River Systems --------------------------- Newsgroups: comp.os.vxworks Subject: Re: exabyte.h file Date: 1 Apr 92 20:11:06 GMT From: brunner@kazoo.ssd.loral.com (Brian Brunner) Organization: Space Systems/Loral Message-ID: <1992Apr1.121106@kazoo.ssd.loral.com> References: <9203310201.AA09593@bach.jhuapl.edu> Reply-To: brunner@kazoo.ssd.loral.com (Brian Brunner) Sender: news@wdl.loral.com Could some kind soul please e-mail me the exabyte.c file this goes to? I lost mine. - -- HELP!! Somebody slapped a "stop payment" on my sanity check!! brunner@kazoo.ssd.loral.com; Space Systems/Loral; Palo Alto, Calif. Black Holes... the /dev/null of the Universe; the opinion of 65534. --------------------------- Newsgroups: comp.os.vxworks Subject: TCP Bandwith on VxWorks Date: 1 Apr 92 23:40:01 GMT From: mwm40@tony.ccc.amdahl.com (Marcelo W Mourier) Organization: Amdahl Corporation, Sunnyvale CA Message-ID: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> Sender: netnews@ccc.amdahl.com Does anybody know what's the maximum data throughput achivable at the socket (TCP) interface in VxWorks. As this figure depends highly on the particular hardware used, please specify the type and speed of CPU and network. Thanks! - ---- Marcelo Mourier --------------------------- Newsgroups: comp.os.vxworks Subject: WANTED: Bay Area VxWorks person - contract work Date: 1 Apr 92 18:56:36 GMT From: ksh@vine.COM (Kent S. Harris) Organization: Vine Technology, Cupertino, CA Message-ID: <3622@vine.COM> I have a tentative contract for a VxWorks device driver. Please give me a call. Must be in SF Bay area (South Bay preferred). Kent S. Harris Vine Technology 408-996-1294 - -- Kent S. Harris ...!ames!vine!ksh CONSULTING: Real-time system h/w & s/w, Vine Technology (ksh@vine.com) software development tools, project (408)996-1294 22 yr EE/CS exp. analysis, information modeling. --------------------------- End of New-News digest ********************** From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net Thu Apr 2 06:12:08 1992 From: "Roeber" Date: Thu Apr 2 06:12:20 PST 1992 Subject: Re: Slip & flow control > 1- First question: SLIP and flow control > ---------------------------------------- > > We are using SLIP over a serial radio modem link and > it seems that SLIP does not handle RTS / CTS protocol. > This increases the number of retransmissions when our > modem is overloaded and sometimes leads to connection breaks. > > I tried to modify the hardware initialization in "tyCoInitChannel": > > *cr = SCC_WR0_SEL_WR3; /* write reg 3 - receiv > *cr = SCC_WR3_RX_8_BITS | SCC_WR3_RX_EN | SCC_WR3_AUTO_EN; > ------------------ <- my modification I assume you are using some Zilog serial interface? The Z84C40? Have you checked out the ZILOG application note on async communication? On page 545 of the ZILOG Intelligent Peripheral Controllers book is the picture of how to handle auto enables in HW. You need DCD and DTR connected in addition to RTS CTS. Good Luck. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From sharpster@hns.com Thu Apr 2 06:25:40 1992 From: sharpster@hns.com (Stephen Harpster) Date: Thu Apr 2 06:25:47 PST 1992 Subject: Re: porting to VxWorks I'm currently working on a POSIX layer that sits between VxWorks and our applications. The idea is to do just what you are attempting: to use POSIX-conforming applications with VxWorks. (Yes, I've heard that VxWorks is moving towards POSIX, but the timeframe seems shaky.) All in all it isn't too bad. A lot of functions, are just inline routines that rearrange the parameters or rename the function. Here's a freebie: extern inline pid_t getpid(void) { return (pid_t) taskIdSelf(); } The only time things get tough is when you try to map the not-standard-yet POSIX things to VxWorks (like 1003.4 - realtime extensions and 1003.4a - threads). So the above could also be (more correctly) extern inline pthread_t pthread_self(void) { return (pthread_t) taskIdSelf(); } The problem isn't VxWorks, it's the drafts changing. The only two things to do are 1. Wait until the drafts become standard. 2. Pick one draft and design against it. We've decided on #2. Later releases of our "product" will bring it up to either the standard (when it becomes one), or at least a later draft. -- Stephen Harpster Hughes Network Systems sharpster@hns.com From iphasew!hwajin@apple.com Thu Apr 2 12:44:49 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Thu Apr 2 12:44:57 PST 1992 Subject: Re: Sockets and clocks. >The downside, of course, is these addr's are the Ethernet chip >addresses instead of something more easily determined such as internet >addresses & aliases. A new routine etherAddrResolve() has been added to VxWorks 5.0 to help ease this problem. -- Hwa-Jin Bae Interphase West From iphasew!hwajin@apple.com Thu Apr 2 12:45:42 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Thu Apr 2 12:45:51 PST 1992 Subject: BOOTP >12f,07may90,hjb added support for BOOTP forwarding. The BOOTP forwarding code started up a forwarder on gateway target for BOOTP traffic between backplane targets and the server. As you already know, the relevant code was subsequently deleted before 5.0 made out to door. Hang in there, I think WRS probably has something planned for the next release. -- Hwa-Jin Bae Interphase West From iphasew!hwajin@apple.com Thu Apr 2 12:50:01 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Thu Apr 2 12:50:11 PST 1992 Subject: Re: SLIP & flow control VxWorks SLIP implementation uses read() and write() routines for character I/O. The lowest tty-related level SLIP driver touches is the "protocol hook" related part in tyLib code which sits on top off various board- specific tyCoDrv.c. SLIP driver doesn't care what tyCoDrv does, and contrary to messages posted a while back, SLIP can work over a number of different point-to-point links -- asynchronous, synchronous, customized link hardware, and I know at least one user who wrote a parallel port driver and adapted it for SLIP under VxWorks. Regarding : > UNIX gateway > --- >| |---| radio modem | > --- > | >----------------------------------- > | ethernet > | > | > -------------------------- > | CPU1 | CPU2 | ... CPU4 | CPUi: MV147 > -------------------------- > | VME bus > UNIX gateway --- Does the CPU1 still think that ethernet interface is UP and RUNNING? Just removing ethernet cable is not enough. Do ifShow() to find out. You will need to at least mark the network interface down by doing ifFlagChange(). You will also need to delete any routing table entry that refers to the ethernet interface. Do routeShow() and delete such entries with routeDelete(). -- Hwa-Jin Bae Interphase West From daemon@vxw.ee.lbl.gov Fri Apr 3 04:00:34 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 3 04:00:42 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 3 04:00:27 PST 1992 Subject: Re: TCP Bandwith on VxWorks Subject: Motorola MVME 167 Subject: Intermittent Failure ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP Bandwith on VxWorks Date: 2 Apr 92 15:11:32 GMT From: davew@dslsn1.lampf.lanl.gov (David Whitehouse) Organization: Digital Equipment Corporation Message-ID: <1992Apr2.151132.7407@newshost.lanl.gov> References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> Reply-To: davew@dslsn1.lampf.lanl.gov (David Whitehouse) Sender: news@newshost.lanl.gov In article <0dfW028U0fSC01@JUTS.ccc.amdahl.com>, mwm40@tony.ccc.amdahl.com (Marcelo W Mourier) writes: |> Path: lanl!hellgate.utah.edu!dog.ee.lbl.gov!network.ucsd.edu!usc!zaphod.mps.ohio-state.edu!qt.cs.utexas.edu!yale.edu!jvnc.net!darwin.sura.net!europa.asd.contel.com!uunet!charon.amdahl.com!amdahl!JUTS!tony.ccc.amdahl.com |> From: mwm40@tony.ccc.amdahl.com (Marcelo W Mourier) |> Newsgroups: comp.os.vxworks |> Subject: TCP Bandwith on VxWorks |> Message-ID: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> |> Date: Wed, 1 Apr 92 16:40:01 GMT-0:03 |> Sender: netnews@ccc.amdahl.com |> Distribution: usa |> Organization: Amdahl Corporation, Sunnyvale CA |> Lines: 8 |> |> Does anybody know what's the maximum data throughput achivable at the socket |> (TCP) interface in VxWorks. As this figure depends highly on the particular |> hardware used, please specify the type and speed of CPU and network. |> |> Thanks! |> |> ---- |> Marcelo Mourier |> I am also interested in these results, it would also be useful to have the CPU usage for both the sending and receiving computers. Thanks, David Whitehouse --------------------------- Newsgroups: comp.os.vxworks Subject: Motorola MVME 167 Date: 2 Apr 92 23:24:50 GMT From: davew@dslsn1.lampf.lanl.gov (David Whitehouse) Organization: Los Alamos National Laboratory Message-ID: <1992Apr2.232450.4305@newshost.lanl.gov> Reply-To: davew@dslsn1.lampf.lanl.gov (David Whitehouse) Sender: news@newshost.lanl.gov Hello, My group is considering purchasing VxWorks for use with a VME based data acquisition system using MVME 167 monoboards. Since the support for the MVME 167 is rather new I would be interested in hearing from anyone who has used VxWorks with the MVME 167. Please reply by email. Thanks, David Whitehouse --------------------------- Newsgroups: comp.os.vxworks Subject: Intermittent Failure Date: Thu, 2 Apr 1992 23:29:57 GMT From: blue@forsight.jpl.nasa.gov (Randel Blue) Organization: Jet Propulsion Laboratory Message-ID: <1992Apr2.232957.2995@elroy.jpl.nasa.gov> Sender: news@elroy.jpl.nasa.gov (Usenet) I sometimes get a cryptic message from vxWorks, both 4.0.2 and 5.0.2, that I have not been able to figure out. The target is a Heurikon HKV3F (68030). This message appears sometimes at boot time and less frequently while running my application, and at times even when the machine is just siting idle. The text of the message is: RUStart: RU unexpectedly not idle - aborting. scb 0x1f4534 (Magic OK): fr rnr cuc=nop ruc=nop cus=idle rus=out of resources (RBD) cbl=0x1e730e rfa=0x1f3e44 tfdhd:0x1e7368, rfdhd:0x1f3e44 Counters: crc=0x0 aln=0x0 rsc=0xb ovrn=0x0 cdt=0x0 shrt=0x0 If anyone can explain the cause and prevention of this condition I would be very grateful. Randy Blue JPL --------------------------- End of New-News digest ********************** From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net Fri Apr 3 08:14:01 1992 From: "Roeber" Date: Fri Apr 3 08:14:10 PST 1992 Subject: Compiler option problems Greetings, We are trying to figure out how to handle a subtle compiler problem with the GCC compiler used with VxWorks and are wondering if anyone else has run into it. The problem has to do with how driver and configuration files are compiled. As delivered, configuration files are compiled with the the optimization switches: -O -fvolatile This says optimize things (-O) but don't remove accesses to anything that is referenced through a pointer (-fvolatile). The volatile part is important since you don't want the compiler removing code that, for instance, reads the same hardware register multiple times to retrieve different values. Without the -fvolatile the optimizer could eliminate such code. The problem comes in because the compiler generates stupid code for certain types of statements when these options are used. For this whole discussion, the same sample code below will be used: #define REG1 (char *)0x5000 #define REG2 (long *)0x6000 test() { *REG1 |= 10; *REG2 |= 1000; } This code code be code for updating control bits in various hardware control registers. When controlling hardware, this sort of code can be quite common. Note that one register is a single byte and one is a long word (32 bits). When this code is compiled with the -O -fvolatile switches, the following code is generated: _test: .stabd 68,0,5 link a6,#0 .stabd 68,0,7 movew #20480,a0 /* FIRST REGISTER */ moveb a0@,d0 orb #10,d0 /* POINT 1 */ moveb d0,a0@ .stabd 68,0,8 movew #24576,a0 /* SECOND REGISTER */ movel a0@,d0 orw #1000,d0 movel d0,a0@ .stabd 68,0,9 unlk a6 rts While this code works, it could introduce serious problems in certain cases since the hardware register is read, updated, and written back. If an interrupt occured at POINT 1, for instance, and the interrupt code updated a different bit of the same register, that update would be lost when the interrupt completed and the code wrote the register back out to the hardware. We originally noticed this problem resulting in spurious serial communication problems with one of our boards since control bit changes were (infrequently) getting lost. To get around it we compiled the code with no optimization yielding the following code: _test: .stabd 68,0,5 link a6,#0 .stabd 68,0,7 orb #10,20480:w /* FIRST REGISTER */ .stabd 68,0,8 orw #1000,24578:w /* SECOND REGISTER */ .stabd 68,0,9 L1: unlk a6 rts Note that for the first register, this code solves the problem since the hardware register is updated in one atomic instruction. Since our terminal device had all byte wide registers this was a perfect solution. The problem came in when we went to a different board that had some devices that could only be accessed as long word values. This is like the second register. Looking at the code generated in this case, we saw that it was wrong. In its infinite wisdom, the compiler was only updating the 2nd 16 bit half of our long word register. This didn't work and caused a bus error. From this, it seems that we must use the -fvolatile switch to get code that works at all. The code, however, can cause unreliable operation. We are caught between a rock and a hard place. The big question is whether anyone else has run into this and what they have done about it? For completeness, compiling the code with just the -O option yields: _test: .stabd 68,0,5 link a6,#0 .stabd 68,0,7 orb #10,20480:w .stabd 68,0,8 orw #1000,24578:w .stabd 68,0,9 unlk a6 rts Same problem as without optimization. Any ideas???? Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| The statement was adding a new bit value to a specific hardware control register. If the same code is compiled with no optimization what the compiler produces is: .stabd 68,0,1221 orw #1024,67108926 From stan@rti.com Fri Apr 3 15:59:29 1992 From: stan@rti.com (Stan Schneider) Date: Fri Apr 3 15:59:36 PST 1992 Subject: Re: Compiler option problems >> #define REG1 (char *)0x5000 >> #define REG2 (long *)0x6000 >> >> test() >> { >> *REG1 |= 10; >> *REG2 |= 1000; >> } >> >> ...with the -O -fvolatile switches... While this code works, it could >> introduce serious problems in certain cases since the hardware register >> is read, updated, and written back. >> >> ...without -fvolatile... >> Note that for the first register, this code solves the problem since the >> hardware register is updated in one atomic instruction. The "volatile" declaration is intended precisely for this type of application. I don't think you should be trying to get around it. Code that depends on atomic instruction execution to avoid interrupt interactions seems risky and non-portable at best. How about just using intLock? Are your latency requirements that critical? This will also prevent the possible problem of register sets that may be dependent (i.e. if REG1 and REG2 have to have consistent values. -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From daemon@vxw.ee.lbl.gov Sat Apr 4 04:00:35 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 4 04:00:43 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 4 04:00:28 PST 1992 Subject: Re: Compiler option problems Subject: PEP 3U VME Cards ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Compiler option problems Date: 3 Apr 92 18:45:32 GMT From: sjk@strl.labs.tek.com Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <4019@crl.LABS.TEK.COM> References: <9204031525.AA04096@ss4u02.ssd.ray.com> Reply-To: sjk@crl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <9204031525.AA04096@ss4u02.ssd.ray.com>, fjr@ss4u02.ssd.ray.com (Roeber) writes: |> Greetings, |> |> We are trying to figure out how to handle a subtle compiler problem with the |> GCC compiler used with VxWorks and are wondering if |> anyone else has run into it. The problem has to do with how driver and |> configuration files are compiled. As delivered, configuration files are |> compiled with the the optimization switches: |> -O -fvolatile |> This says optimize things (-O) but don't remove accesses to anything that is |> referenced through a pointer (-fvolatile). The volatile part is important |> since you don't want the compiler removing code that, for instance, reads |> the same hardware register multiple times to retrieve different values. |> Without the -fvolatile the optimizer could eliminate such code. |> The problem comes in because the compiler generates stupid code for certain |> types of statements when these options are used. For this whole discussion, |> the same sample code below will be used: |> |> |> #define REG1 (char *)0x5000 |> #define REG2 (long *)0x6000 |> |> test() |> { |> *REG1 |= 10; |> *REG2 |= 1000; |> } Have you tried: test() { asm ("movew #20480,a0"); asm ("orb #10,a0@"); asm ("movew #24576,a0"); asm ("orl #1000,a0@"); } or: test() { int intKey; intKey = intLock(); *REG1 |= 10; *REG2 |= 1000; intUnlock(intKey); } Sometimes you just have to bite the bullet when dealing with devices. It always pays to look at the disassembled code to see if it is really talking to the hardware in the correct manner. After a few go-rounds, you'll know what works and what doesn't. Welcome to the wonderful world of controlling bit-mapped I/O with C! ;^) Steven - ---------------------------------------------------------------------- e-mail: sjk@strl.labs.tek.com | Steven King phone: 503-627-2736 | Software Technology Research Lab voice mail: 503-727-6651 | Tektronix, Inc. fax: 503-627-5502 | P.O. Box 500 MS 50-662 | Beaverton, OR 97077 - ---------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: PEP 3U VME Cards Date: 3 Apr 92 19:52:46 GMT From: shi@frc2.frc.ri.cmu.edu (WenFan Shi) Organization: Field Robotic Center, CMU Message-ID: Reply-To: shi@frc2.frc.ri.cmu.edu (Wenfan Shi) Hello, Is there anyone have experience with PEP 3U VME cards and VxWorks software supports? any ups and down? I am especially concern about software device drivers, how robust it is, and how long since PEP support VxWorks in general or the boards you are using. Email is preferd. Thank you in advance! - -wenfan - -- Wenfan Shi Research Programmer Field Robotics Center ARPAnet/Internet: shi@frc2.frc.ri.cmu.edu Robotics Institute Office: (412) 268-6558 Carnegie-Mellon University Home: (412) 621-3153 Pittsburgh, PA. 15213 --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Mon Apr 6 04:00:24 1992 From: daemon@vxw.ee.lbl.gov Date: Mon Apr 6 04:00:32 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Apr 6 04:00:16 PDT 1992 Subject: Re: select problems Subject: Re: TCP Bandwith on VxWorks Subject: Re: Intermittent Failure ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: select problems Date: Sun, 5 Apr 1992 03:49:13 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550005@hppad.waterloo.hp.com> References: <9203280034.AA01155@comtec.UUCP> From some of our internal notes. This may be of some help. Ted Rypma HP Panacom Division This basenote provides an overview on how to use the new VxWorks 5.0 select() facilities. The discussion is targetted for developers of VxWorks IO System compliant device drivers. Its assumed that you know how the VxWorks IO System works and how you tie in your device driver into the IO system. If you don't, there is some rather pleasant reading that you should do in Chapter 4 of the VxWorks 5.0 Programmers Guide, and in particular, all of subsection 4.9. First of all, the selectLib library has these routines that you need to be aware of: - - selectInit(): initialaizes the select() library, - - select() - - selWakeup(): wake up a pended task in select(), - - selWakeupAll(): wake up all tasks on a select() wake up list, - - selNodeAdd(): add a wakeup node to the select wakeup list, - - selNodeDelete(): remove a wakeup node - - selWakeupListInit(): initialize a list of nodes, - - selWakeupListLen(): gets number of nodes in the wakeup list, - - selWakeupType(): type of wakeup node. If you want the detailed guts of the above functions, see the VxWorks 5.0 Reference Manual. The first thing you do is make sure that selectLib is initialized by calling selectInit(). This should be done ONCE and ONLY ONCE. It should be done in usrRoot() in usrConfig.c, for example. A driver must include selectLib.h if the select() facilities are to be used. Each driver must declare a structure that contains the wakeup nodes. This is a list of type SEL_WAKEUP_LIST and should be a part of the device descriptor data structure. Its important that it be here since the driver code may be installed as a number of different devices, all being of the same driver type, and each instance of the device will manage its own device descriptor data structure block. This preserves code re-entrancy. So to accomplish this, the device driver xxDevCreate() entry call must call selWakeupListInit() to intialize the device's wakeup list structure: SEL_WAKEUP_LIST *pWakeupList; selWakeupListInit (pWakeupList); In the device driver interrupt handler, when the device is ready for writing, it should call: selWakeupAll (pWakeupList, SELWRITE); In the device driver interrupt handler, when the device has data for reading, it should call: selWakeupAll (pWakeupList, SELREAD); That takes care of the interrupt handlers. The device driver xxIoctl() entry must support two new io contols: - - FIOSELECT - - FIOUNSELECT When an application calls select() with the fd set for this device, the select() service calls the device's xxIoctl(..,FIOSELECT,..) to arm the device for responding with the desired IO action. The device driver will do the following in FIOSELECT: /* add the pending caller info to the select wakeup list of this device driver */ selNodeAdd (pWakeupList, (SEL_WAKEUP_NODE *)arg); /* now check if we already have the right conditions for the original caller to continue IO. If the conditions are met, notify the pended caller via selWakup(). Doing this here just takes care of the case where the driver is ready to go and the caller calls select(). It allows an immediate result to be returned to the caller. */ if (selWakupType ((SEL_WAKEUP_NODE *)arg) == SELREAD) && thereIsDataToRead) selWakeup ((SEL_WAKEUP_NODE *)arg); if (selWakupType ((SEL_WAKEUP_NODE *)arg) == SELWRITE) && thereIsRoomToWrite) selWakeup ((SEL_WAKEUP_NODE *)arg); If the device doesn't meet the above conditions, the interrupt handler(s) will wakeup the pended caller when data is available by calling selWakeupAll(). After a select completes due to a timeout or because data is available, the io control entry for FIOUNSELECT is called to remove the caller wakeup node from the device wakeup list. FIOUNSELECT will do: selNodeDelete (pWakeupList, (SEL_WAKEUP_NODE *) arg); That's what you gotta do. Please note, this stuff hasn't been tested yet. It's just my current understanding, so please no flames :-) (With thanks to Louis Gaiot) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP Bandwith on VxWorks Date: Sun, 5 Apr 1992 03:56:30 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550006@hppad.waterloo.hp.com> References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> > Does anybody know what's the maximum data throughput achivable at the socket > (TCP) interface in VxWorks. As this figure depends highly on the particular > hardware used, please specify the type and speed of CPU and network. We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this data rate there appears to be enough horsepower left to do other things. Ted Rypma HP Panacom Division --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Intermittent Failure Date: Mon, 6 Apr 1992 01:29:12 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550007@hppad.waterloo.hp.com> References: <1992Apr2.232957.2995@elroy.jpl.nasa.gov> > I sometimes get a cryptic message from vxWorks, both 4.0.2 > and 5.0.2, that I have not been able to figure out. The target > is a Heurikon HKV3F (68030). . . > RUStart: RU unexpectedly not idle - aborting. > > scb 0x1f4534 (Magic OK): fr rnr I can't explain it, but I can tell you where it's coming from... The ethernet controller sounds like it is an Intel 82596 (or pretty close). The way the driver is written, it must be shutting off the LAN controller receive unit from time to time, and is not being successful when your message is issued. I would suspect an ethernet or a driver problem. (I remember seeing similar messages from our hkv960 version when we were working on the driver.) Ted Rypma HP Panacom Division --------------------------- End of New-News digest ********************** From Christina_Goette@mac_smtp.wrs.com Mon Apr 6 09:45:51 1992 From: Christina_Goette@mac_smtp.wrs.com (Christina Goette) Date: Mon Apr 6 09:45:59 PDT 1992 Subject: West Coast Users Meeting Subject: Time:8:41 AM OFFICE MEMO West Coast Users Meeting Date:4/6/92 Just one last reminder that the next VxWorks Users Group meeting is this Friday, April 10, 1992 in Newport Beach. The meeting, chaired by Steven King with Tektronix, will run from 8:30 am to about 4:30 pm. In addition to presentations by Wind River Systems representatives covering WRS, VxWorks and POSIX status, users will be making applications and issues presentations. The meeting will be held at the Newport Beach Marriott, 900 Newport Center, Newport Beach, CA 92660 714/640-4000. There is a $50 registration fee to attend the meeting which may be paid at the door with Visa, Mastercard, check or cash. If you are interested in attending, please contact me via email at tina@wrs.com or at 1-800-545-9463 for more information. Christina Goette From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net Mon Apr 6 20:30:38 1992 From: "Roeber" Date: Mon Apr 6 20:30:46 PDT 1992 Subject: Re: Compiler option problems > Newsgroups: comp.os.vxworks > Subject: Re: Compiler option problems > Date: 3 Apr 92 18:45:32 GMT > From: sjk@strl.labs.tek.com > Organization: Software Technology Research Lab, Tektronix, Inc. > Message-ID: <4019@crl.LABS.TEK.COM> > References: <9204031525.AA04096@ss4u02.ssd.ray.com> > Reply-To: sjk@crl.labs.tek.com (Steven King) > Sender: news@crl.LABS.TEK.COM > > In article <9204031525.AA04096@ss4u02.ssd.ray.com>, fjr@ss4u02.ssd.ray.com (Roeber) writes: > > |> Greetings, > |> > |> We are trying to figure out how to handle a subtle compiler problem > |> with the GCC compiler used with VxWorks .. > > Have you tried: > > test() > { > asm ("movew #20480,a0"); > asm ("orb #10,a0@"); > asm ("movew #24576,a0"); > asm ("orl #1000,a0@"); > } > > or: > > test() > { > int intKey; > > intKey = intLock(); > *REG1 |= 10; > *REG2 |= 1000; > intUnlock(intKey); > } > > Sometimes you just have to bite the bullet when dealing with devices. > It always pays to look at the disassembled code to see if it is really > talking to the hardware in the correct manner. After a few go-rounds, > you'll know what works and what doesn't. Welcome to the wonderful world > of controlling bit-mapped I/O with C! ;^) The reason I brought up this problem was mainly to see how people were dealing with the fact that all the configuration code is by default compiled with the "-O -fvolatile" switches. As I showed, using these switches can cause code to be generated that will result in execution errors if interrupts occur at the wrong time. Specifically, there are problems with any of the config code that can run at interrupt and task level, possibly concurrently, that uses the "|=" or "&=" assignment statements. My feeling is that this could be the cause of some of the infrequent glitches people see when running VxWorks. I was sort of hoping that some of the Wind River people who had thought this stuff through would chime in. I say the compiler is busted and should be fixed but Richard Stallman (who wrote gcc) wasn't too interested (although he said the problem is likeley in code in the combine.c routine). I have seen some good suggestions for fixing the erroneous code (like that above). The question is how to attack the problem since it crosses all the BSPs. Also, the drv source code is compiled with the same options. That means that the various SCSI chip interface routines in that library could have problems. From marc@sun-valley.stanford.edu Tue Apr 7 00:38:28 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Tue Apr 7 00:38:36 PDT 1992 Subject: Re: Compiler option problems >The reason I brought up this problem was mainly to see how people were dealing >with the fact that all the configuration code is by default compiled with the >"-O -fvolatile" switches. Since using the -fvolatile flag basically defeats the purpose of having an optimizer we dealt with this by cleaning up the WRS supplied code (and makefiles) until it would compile error and warning free using "-O -Wall" (WITHOUT the -fvolatile flag). This meant ANSIfying it, reordering it, adding "volatile" to variable declarations corresponding to hardware registers, fixing header files, etc. > As I showed, using these switches can cause code >to be generated that will result in execution errors if interrupts occur >at the wrong time. Specifically, there are problems with any of the config >code that can run at interrupt and task level, possibly concurrently, that >uses the "|=" or "&=" assignment statements. My feeling is that this could >be the cause of some of the infrequent glitches people see when running >VxWorks. This would be a fundamental design/coding flaw--not a compiler bug. Task and interrupt code should not be mucking with the same piece of hardware at the same time (unless it is "dual ported"). Clearly said hardware represents a "critical section" and should be appropriately protected using semaphores (e.g. the TAS variety) or int locks. BTW, would you care to point out a specific instance of this problem in one of the common config source files? > I was sort of hoping that some of the Wind River people who had >thought this stuff through would chime in. I say the compiler is busted and >should be fixed but Richard Stallman (who wrote gcc) wasn't too interested >(although he said the problem is likeley in code in the combine.c routine). As for GCC being "busted"--that is a rather unfair accusation. There is nothing in the ANSI C standard that says how efficiently a compiler has to perform any particular operation. I will grant you that GCC does not produce the tightest possible code when pointers are declared to be volatile, but to make assumptions of the nature you imply is simply unreasonable. If you want atomic actions, you should surround them with int locks. This would be true even if you were writing in assembly language. --Marc Ullman Stanford University From daemon@vxw.ee.lbl.gov Tue Apr 7 04:00:27 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 7 04:00:34 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 7 04:00:20 PDT 1992 Subject: X for vxworks? Subject: Re: TCP Bandwith on VxWorks Subject: etherAddrResolve() help, please Subject: Re: etherAddrResolve() help, please ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: X for vxworks? Date: 6 Apr 92 16:05:58 GMT From: amidi+@CS.CMU.EDU (Omead Amidi) Organization: Carnegie Mellon University Message-ID: <1992Apr06.160558.278791@cs.cmu.edu> Hello, I would like to run some X clients on my vxworks target. I found an old (v. 3.0) port of Xlib from thor.ucar. but nothing more recent. Is anyone using or porting X to vxworks? thanks. - -- Omead --------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP Bandwith on VxWorks Date: 6 Apr 92 16:00:45 GMT From: els@icf.hrb.com (Eric L. Schott) Organization: HRB Systems, Inc. Message-ID: <1992Apr6.110045.19052@icf.hrb.com> References: <0dfW028U0fSC01@JUTS.ccc.amdahl.com> <27550006@hppad.waterloo.hp.com> In article <27550006@hppad.waterloo.hp.com>, rypma@hppad.waterloo.hp.com (Ted Rypma) writes: >> Does anybody know what's the maximum data throughput achivable at the socket >> (TCP) interface in VxWorks. As this figure depends highly on the particular >> hardware used, please specify the type and speed of CPU and network. > > We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an > Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this > data rate there appears to be enough horsepower left to do other things. > I have measured over 800 Kbytes/sec between an 040 SBC (VxWorks) and a SPARCstation 2 (SunOS 4.1.1). We used TCP sockets. - -- Eric L. Schott, HRB Systems, Inc. 814/238-4311 Internet: ELS@ICF.HRB.COM --------------------------- Newsgroups: comp.os.vxworks Subject: etherAddrResolve() help, please Date: 6 Apr 92 17:51:30 GMT From: bgeer@javelin.sim.es.com (Bob Geer) Organization: Evans & Sutherland Computer Corporation Message-ID: <1992Apr6.175130.16667@javelin.sim.es.com> Reply-To: bgeer@javelin.sim.es.com The man page for the VxWorks function etherAddrResolve() (as well as the page for etherOutput) includes the following reference via code fragment: struct ifnet *pIf; pIf = ifunit ("ln0"); I can't find a macro definition or function prototype for ifunit() anywhere in the Vx stuff. Structure "ifnet" includes a member "short if_unit", which doesn't look pertinent. I can infer that ifunit() can be properly prototyped as: "struct ifnet *ifunit( char *)" However, I'd appreciate confirmation... Thanks in advance, Bob - -- <> Bob `Bear' Geer <> bgeer@beorn.sim.es.com __o <> <> bike-a-holic <> (this *often* works) -\<, <> <> Salt Lake City, <> speaking only for myself, ......O/ O <> <> Ootah <> one of my many tricks <> --------------------------- Newsgroups: comp.os.vxworks Subject: Re: etherAddrResolve() help, please Date: 6 Apr 92 20:00:31 GMT From: bgeer@javelin.sim.es.com (Bob Geer) Organization: Evans & Sutherland Computer Corporation Message-ID: <1992Apr6.200031.17695@javelin.sim.es.com> References: <1992Apr6.175130.16667@javelin.sim.es.com> Reply-To: bgeer@javelin.sim.es.com bgeer@javelin.sim.es.com (Bob Geer) writes: >The man page for the VxWorks function etherAddrResolve() (as well as >the page for etherOutput) includes the following reference via code >fragment: > struct ifnet *pIf; > pIf = ifunit ("ln0"); >I can't find a macro definition or function prototype for ifunit() >anywhere in the Vx stuff. Structure "ifnet" includes a member "short >if_unit", which doesn't look pertinent. >I can infer that ifunit() can be properly prototyped as: > "struct ifnet *ifunit( char *)" >However, I'd appreciate confirmation... To follow up, my contrived prototype (as mentioned above) appears to work. However, I now note that if I try to arp an unresponsive machine, the timeout status is OK, not ERROR as advertised. Is there a work-around for this? I'm using vw5.0.2 for a -147 board. As before, thanks in advance...Bob Hope this damned e-mail system works! - -- <> Bob `Bear' Geer <> bgeer@beorn.sim.es.com / <> <> <> (this *often* works) __o o ,______/o <> <> Salt Lake City, <> speaking only for myself, -\<, <\ ,__/ > <> <> Ootah <> one of my many tricks O/ O __ /__, / <> --------------------------- End of New-News digest ********************** From rayssd!ss4u02.ssd.ray.com!fjr@uunet.uu.net Tue Apr 7 11:28:16 1992 From: "Roeber" Date: Tue Apr 7 11:28:25 PDT 1992 Subject: Re: Compiler option problems > Submitted-by marc@sun-valley.stanford.edu Tue Apr 7 00:38:28 1992 > > Since using the -fvolatile flag basically defeats the purpose of having an > optimizer we dealt with this by cleaning up the WRS supplied code (and > makefiles) until it would compile error and warning free using "-O -Wall" > (WITHOUT the -fvolatile flag). This meant ANSIfying it, reordering it, > adding "volatile" to variable declarations corresponding to hardware > registers, fixing header files, etc. Wow, that clearly is the right way to handle things but involves a lot of work. It will be nice when VxWorks is all ansified but I haven't heard any definitive schedule for when that will be. > This would be a fundamental design/coding flaw--not a compiler bug. Task > and interrupt code should not be mucking with the same piece of hardware at > the same time (unless it is "dual ported"). Clearly said hardware represents > a "critical section" and should be appropriately protected using semaphores > (e.g. the TAS variety) or int locks. > > BTW, would you care to point out a specific instance of this problem in one of > the common config source files? Very good points. Note though that the restriction that you are mucking with hardware only this way is not valid. This problem applies to any data structure that is shared across interrupt and task level and is updating using bit fields or the "|=" and "&=" constructs; some task level code moves a flag value into a register, gets interrupted by a handler that changes the flag value, and then when the tasks resumes it moves a new copy of the register back to memory overwriting the flag. I initially ran into this problem more than a year ago when we were using an older VxWorks release with the GNU tools before GNU support was available officially. We had compiled the whole system (including all the VxWorks source code) with -fvolatile and were having strange problems. After much enlightening discussion, Dave Wilner at WRS tracked it down to the -fvolatile problem. Well, since most of the kernel doesn't use -fvolatile (only the SCSI drivers in the drv library do), there isn't a problem. But this is only because the bit modification instructions DO generate atomic instructions in the normal case. Sure it would be "correct" to always lock interrupts before doing anything that is messing with structures shared across task and interrupt level but think of the performance penalty. When you are coding things, don't you have a mental model of what is and isn't safe to do? I guess I had figured that bit operations were. In a number of places, VxWorks is coded around the concept that bit manupulation operations are safe (the terminal library and ethernet driver are two examples that I can think of). I went through the configuration code, though, and couldn't find any examples of where there could be problems. In the specific board support packages I checked there were a few places where this problem could bite one. Also, in some configuration code we had added there were problems (we got bit by the fact that since we could see how WRS had done some things we used the same mechanisms but without the safety of having the code in a directory that got compiled with the right options). > As for GCC being "busted"--that is a rather unfair accusation. There is > nothing in the ANSI C standard that says how efficiently a compiler has > to perform any particular operation. I will grant you that GCC does not > produce the tightest possible code when pointers are declared to be > volatile, but to make assumptions of the nature you imply is simply > unreasonable. If you want atomic actions, you should surround them > with int locks. This would be true even if you were writing in assembly > language. Again, I guess I agree about GCC not being "busted". It is just unfortunate that it generates such poor code with volatile things. Since you have dealt with ANSI code out of GCC it sounds like we can count on any volatile variables accessed through pointers to generate non atomic operations. Do you also have to make sure that global variables that are shared across task and interrupt level are declared volatile to make sure that all updates to them get written to memory in the order performed? If such is the case then ANSIfying VxWorks may not be so easy since bit field and read modify write operations (like &=) will have to all be fixed. I guess the bottom line is having an accurate model of the compiler generated code when programming. You can't assume the worst case code and still have a system that works but if you are too optimistic, you can end up with buggy code. > --Marc Ullman > Stanford University Thanks for the info. Fred From iphasew!hwajin@apple.com Tue Apr 7 14:29:42 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Tue Apr 7 14:29:49 PDT 1992 Subject: Re: Compiler option problems >Since using the -fvolatile flag basically defeats the purpose of having an >optimizer we dealt with this by cleaning up the WRS supplied code (and >makefiles) until it would compile error and warning free using "-O -Wall" >(WITHOUT the -fvolatile flag). This meant ANSIfying it, reordering it, >adding "volatile" to variable declarations corresponding to hardware >registers, fixing header files, etc This is definitely the right thing to do in my opinion. It is also a lot of work. If you prefer to stay with "-traditional" (non-ANSI, K&R) GCC, you can still use the "volatile" type. GCC provides "__volatile__" and a few other ANSI types and qualifiers that can be used for non-ANSI mode compilation. A convenient hack most people perform to make "__volatile__" equal to "volatile" when "-traditional" is being used is adding a line like "%{traditional:-Dvolatile=__volatile__}" to the "struct compiler compilers[]" array in gcc.c. With a compiler like this, all one has to do is to add "volatile" to variable declarations corresponding to hardware registers, etc.; no need to muck with headers or ANSI-fy your code. -- Hwa-Jin Bae Interphase West From Enterprise!arete.com!reder@uu.psi.com Tue Apr 7 14:30:46 1992 From: reder@arete.com (Leonard J. Reder) Date: Tue Apr 7 14:30:54 PDT 1992 Subject: Re: comp.os.vxworks newsdigest > >> Does anybody know what's the maximum data throughput achivable at the socket > >> (TCP) interface in VxWorks. As this figure depends highly on the particular > >> hardware used, please specify the type and speed of CPU and network. > > > > We get between 600 and 700 Kbytes/sec with a 25 MHz Intel i960 processor and an > > Intel 82596 LAN controller. We haven't measured the CPU overhead, but at this > > data rate there appears to be enough horsepower left to do other things. > > > > I have measured over 800 Kbytes/sec between an 040 SBC (VxWorks) > and a SPARCstation 2 (SunOS 4.1.1). We used TCP sockets. > I have measured the data rate between a SPARCstation2 (SunOS 4.1.1) and a MV147S (68030) SBC (VxWorks 5.0) tobe as high as 200Kbytes/sec. I could not get any more speed out of the configuration. We also used TCP sockets. s From marc@sun-valley.stanford.edu Tue Apr 7 15:47:05 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Tue Apr 7 15:47:12 PDT 1992 Subject: Re: Compiler option problems >> This would be a fundamental design/coding flaw--not a compiler bug. Task >> and interrupt code should not be mucking with the same piece of hardware at >> the same time (unless it is "dual ported"). Clearly said hardware represen > ts >> a "critical section" and should be appropriately protected using semaphores >> (e.g. the TAS variety) or int locks. >> >> BTW, would you care to point out a specific instance of this problem in one > of >> the common config source files? > >Very good points. Note though that the restriction that you are mucking with >hardware only this way is not valid. This problem applies to any data >structure that is shared across interrupt and task level and is updating using >bit fields or the "|=" and "&=" constructs; some task level code moves >a flag value into a register, gets interrupted by a handler that changes the >flag value, and then when the tasks resumes it moves a new copy of the registe > r >back to memory overwriting the flag. I certainly agree that "shared" data structures present the same problem. >I initially ran into this problem more >than a year ago when we were using an older VxWorks release with the GNU tools >before GNU support was available officially. We had compiled the whole system >(including all the VxWorks source code) with -fvolatile and were having strang > e >problems. After much enlightening discussion, Dave Wilner at WRS tracked it >down to the -fvolatile problem. Well, since most of the kernel doesn't use >-fvolatile (only the SCSI drivers in the drv library do), there isn't a >problem. But this is only because the bit modification instructions DO >generate atomic instructions in the normal case. Sure it would be "correct" >to always lock interrupts before doing anything that is messing with structure > s >shared across task and interrupt level but think of the performance penalty. >When you are coding things, don't you have a mental model of what is and isn't >safe to do? I guess I had figured that bit operations were. I guess this comes down to a choice of speed vs. portability. Again there is nothing in the ANSI-C language spec about the atomic nature of any opera- tion. For instance, if I recall correctly, most Load/Store RISC chips (e.g. SPARC) do not have instructions for doing bitwise read-modify-write operations. Thus on those machines, the compiler is forced to generate multiple instruc- tions. Consider the following code example: int *a = 0; void main () { *a |= 0x1; } Compile this with Sun's stock distribution C compiler using the -O flag and you get: 0x2290
: sethi %hi(0x4000), %o0 0x2294 : ld [%o0+0x98], %o0 ! 0x4098 0x2298 : ld [%o0], %o1 <==== READ 0x229c : or 1, %o1, %o1 <==== MODIFY 0x22a0 : retl 0x22a4 : st %o1, [%o0] <==== WRITE (in delay slot) Thus in my opinion, one should either code "conservatively" in C, meaning you take the hit of placing intlocks around events that must be atomic, or you code in assembly when you really want to specify a specific set of machine level instructions. > In a number of places, VxWorks is coded around the concept that bit >manupulation operations are safe (the terminal library and ethernet driver >are two examples that I can think of). If what you say is true, and I assume that it is, I suspect you have just found a boatload of latent bugs in the various RISC ports of VxWorks. I believe that the code example above clealy invalidates this notion of "safe". > I went through the configuration >code, though, and couldn't find any examples of where there could be problems. >In the specific board support packages I checked there were a few places >where this problem could bite one. Also, in some configuration code we had >added there were problems (we got bit by the fact that since we could see how >WRS had done some things we used the same mechanisms but without the safety of >having the code in a directory that got compiled with the right options). See above. Of course when VxWorks was originally written, its authors were probably not overly concerned with issues like portability etc. It's the kind of thing you only learn about after you've been burned by it. ">Again, I guess I agree about GCC not being "busted". It is just unfortunate >that it generates such poor code with volatile things. Since you have dealt >with ANSI code out of GCC it sounds like we can count on any volatile >variables accessed through pointers to generate non atomic operations. That seems to be my observation, even with the latest version (2.1) and the -O2 flag. I have not tried playing with the many additional optimization options to see if any of them affect this. It would probably not be a big deal to "fix" this up in the 68k code generator; however, even if that were done, the source code should still be rewritten to be portable and robust. >Do you also have to make sure that global variables that are shared across >task and interrupt level are declared volatile to make sure that all updates >to them get written to memory in the order performed? Effectively, the answer is YES. The compiler can very easily elect to cache any non-volatile variable in a register. And most new optimizing compilers will. This is where much of the performance improvement comes from. > If such is the case >then ANSIfying VxWorks may not be so easy since bit field and read modify >write operations (like &=) will have to all be fixed. I guess the bottom >line is having an accurate model of the compiler generated code when >programming. You can't assume the worst case code and still have a system >that works but if you are too optimistic, you can end up with buggy code. As mentioned above, one should design and code in such a way as to not make assumptions on unspecified behaviors. If performance is paramount (as it often is in a real-time kernel or a device driver), there is still no substitute for assembly language. However, a properly designed system should minimize the occurances of this type of situation (the philosophy behind micro-kernels--which Wind essentially is). I believe in the approach that ISRs should be as small as possible and do as little as possible. This helps make interrupt latency more predictable and overall performance better (by among other things eliminating as much as possible, occurances of the type of mutual access problems you have described). --Marc P.S. While on the subject of ANSI C coding style--the liberal use of "const" (the exact opposite of "volatile"), can help improve one's code by (1) exposing coding errors (like trying to overwrite constants) and/or ROM and (2) by telling the compiler when it is safe to leave things in registers across function calls (i.e. it reduces the compiler's burden of having to worry about side effects). From marc@sun-valley.stanford.edu Tue Apr 7 15:54:11 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Tue Apr 7 15:54:18 PDT 1992 Subject: Re: Compiler option problems >This is definitely the right thing to do in my opinion. It is also a lot >of work. If you prefer to stay with "-traditional" (non-ANSI, K&R) GCC, >you can still use the "volatile" type. GCC provides "__volatile__" and >a few other ANSI types and qualifiers that can be used for non-ANSI >mode compilation. A convenient hack most people perform to make >"__volatile__" equal to "volatile" when "-traditional" is being used >is adding a line like "%{traditional:-Dvolatile=__volatile__}" to >the "struct compiler compilers[]" array in gcc.c. With a compiler >like this, all one has to do is to add "volatile" to variable declarations >corresponding to hardware registers, etc.; no need to muck with headers >or ANSI-fy your code. This does circumvent the "volatile" issue, but it does not provide all the other benefits that clean ANSI code provides. IMHO, not using ANSI C, now that the spec is formally approved and excellent conforming compilers like GCC are available, is like programming with one hand tied behind one's back. In the PC and Mac world, any tool vendor who didn't support ANSI C would be dead meat. It baffles me why the UNIX community (e.g. Sun, WRS, etc.), which prides itself as being at the leading edge of technology, is so far behind on this one. --Marc From hill@luke.atdiv.lanl.gov Wed Apr 8 10:17:06 1992 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Wed Apr 8 10:17:15 PDT 1992 Subject: Re: Compiler option problems > Consider the following code example: > > int *a = 0; > > void main () > { > *a |= 0x1; > } > > Compile this with Sun's stock distribution C compiler using the -O flag > and you get: > > 0x2290
: sethi %hi(0x4000), %o0 > 0x2294 : ld [%o0+0x98], %o0 ! 0x4098 > 0x2298 : ld [%o0], %o1 <==== READ > 0x229c : or 1, %o1, %o1 <==== MODIFY > 0x22a0 : retl > 0x22a4 : st %o1, [%o0] <==== WRITE (in delay slot) hm ... thats interesting that "*i |= 1" is also not atomic when compiled with sun's stock compiler for the sparc. Is this a architecture limitation? While I have never assumed that "*i |= 1" was atomic I have always assumed that "(*i)++" was an atomic operation. This turns out to be the case with every compiler/architecture combination that I have written code for. This is certainly the case with sun's sparc compiler and with gcc68k -O -fvolatile (and all other gcc68k compiler switches that I tried). Has anyone out there ever seen an architecture/compiler combination where "(*i)++" or "i++" were not atomic? Jeff From bernard@aar.alcatel-alsthom.fr Wed Apr 8 10:46:24 1992 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Wed Apr 8 10:46:32 PDT 1992 Subject: SLIP overrun We have some problems when using SLIP between our UNIX host (a SPARC II with sunOS 4.1.2) and VxWorks 5.0. Slip is used over a radio modem link (9600 bds, full duplex). After a few minutes of correct working, the following message appeared on the UNIX console: >> Apr 8 14:57:28 serpentine vmunix: slip0: inlen(1075) > SLIPMTU(1006) >> Apr 8 14:58:00 serpentine vmunix: slip0: inlen(1056) > SLIPMTU(1006) >> Apr 8 14:59:14 serpentine vmunix: slip0: inlen(1063) > SLIPMTU(1006) >> Apr 8 15:00:04 serpentine vmunix: slip0: inlen(1070) > SLIPMTU(1006) We use, on the UNIX side, sliplogin 1.4 and the module tty_slip.c has version 1.10. Does anybody can help ? Are our slip version obsolete ? In that case where can I find a new version ? Thanks -- Olivier PS: sorry for my last message about flow control on the VxWorks side, I ran ifShow and it reported there was no transmit error .. so I guess flow control is ok on vxWorks. ----------------------------------------------------------- ! ! ! Olivier BERNARD ! ! Alcatel Alsthom Recherche ! ! Route de Nozay ! ! 91460 Marcoussis ! ! France ! ! ! ! mail: bernard@aar.alcatel-alsthom.fr ! ! ! ----------------------------------------------------------- From marc@sun-valley.stanford.edu Wed Apr 8 11:29:14 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Wed Apr 8 11:29:22 PDT 1992 Subject: Re: Compiler option problems >hm ... thats interesting that "*i |= 1" is also not atomic when compiled >with sun's stock compiler for the sparc. Is this a architecture >limitation? YES. >While I have never assumed that "*i |= 1" was atomic >I have always assumed that "(*i)++" was an atomic operation. This turns >out to be the case with every compiler/architecture combination that I >have written code for. This is certainly the case with sun's sparc compiler >and with gcc68k -O -fvolatile (and all other gcc68k compiler switches >that I tried). Has anyone out there ever seen an architecture/compiler >combination where "(*i)++" or "i++" were not atomic? Are you sure about that? (*i)++ is also a RMW operation, which most load/ store risc architectures do not support. Consider the following example: int *a = 0; void main () { (*a)++; } Compile this with Sun's standard C compiler (with optimization) and you'll get: 0x2290
: sethi %hi(0x4000), %o0 0x2294 : ld [%o0+0x98], %o0 ! 0x4098 0x2298 : ld [%o0], %o1 <==== READ 0x229c : inc %o1 <==== MODIFY 0x22a0 : retl 0x22a4 : st %o1, [%o0] <==== WRITE (in delay slot) --Marc From jones@cs.buffalo.edu Wed Apr 8 12:18:57 1992 From: jones@cs.buffalo.edu (Terry A. Jones) Date: Wed Apr 8 12:19:18 PDT 1992 Subject: Re: Compiler option problems. > hm ... thats interesting that "*i |= 1" is also not atomic when compiled > with sun's stock compiler for the sparc. Is this a architecture > limitation? This depends on your definition of atomic. I would not assume that any C statement generated code that was atomic. Excepting maybe the case of assignment. It is up to the architecture to support non-interruptable read-modify-writes for the operation you desire. Then you would have to check to make sure that the C code generator you are using actually knows enough to make use of these machine instructions. > While I have never assumed that "*i |= 1" was atomic > I have always assumed that "(*i)++" was an atomic operation. This turns > out to be the case with every compiler/architecture combination that I > have written code for. This is certainly the case with sun's sparc compiler I would not rely on this to be atomic either. In the case of the Sparc, there is no read-modify-write instruction that performs this increment operation. The code sequence: (*i)++; Gives you: ld [%o0],%o1 inc %o1 st %o1,[%o0] Which is not atomic as far as I can see. Terry Jones From iphasew!hwajin@apple.com Wed Apr 8 13:17:27 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Wed Apr 8 13:17:38 PDT 1992 Subject: Re: Compiler option problems >IMHO, not using ANSI C, now >that the spec is formally approved and excellent conforming compilers like >GCC are available, is like programming with one hand tied behind one's back. >In the PC and Mac world, any tool vendor who didn't support ANSI C would >be dead meat. It baffles me why the UNIX community (e.g. Sun, WRS, etc.), >which prides itself as being at the leading edge of technology, is so far >behind on this one. [Soapbox begin...] Partly this is perhaps due to the sheer amount of source code that needs to be converted to ANSI. One could condemn an engineer to sit down and ANSI-fy the vast amount of operating system source code, or one could encourage incremental conversion while promoting use of ANSI style prototypes, etc. for any new code being written (well, maybe not ;-) ). UNIX C programs have existed long before ANSI C was developed, long before the DOS and MAC versions of C compilers. Not only the kernel source, but a vast amount of UNIX utilities as well --- now including a good megaton of X11 code and, yes, GCC itself, which is written mostly in elegant K&R C. Another reason is that most operating system vendors (and certainly the lint-religious engineers at WRS) lint every single line of their operating system software, including cross-file checking using generated lint libraries. Apart from the benefit you get using "const, volatile ", etc., lint actually does more checking beyond what's possible even with GCC with "-Wall". It also does not have ANSI C brain-damage that defines a scope of type declaration to function prototypes, causing in some cases incompatible type error for the same type depending on the order of declaration. Using automatic prototype generators or ANSI conversion programs is at best too risky for operating system source code. I agree that in an ideal world, we'd all have enough time to invest in ANSI-fying every line of C code we come across, and the world would be "better" place. In the mean time, hacking up GCC gives you what's missing in K&R C, and lint gives you all the checking you usually want for your code. A caveat of course is that most UNIX vendors do ship their lint libraries, while WRS may or may not. [ ... end] Obligatory technical content: Even GCC, a mind-bogglingly good compiler, when used with -ansi option, is not 100% ANSI compatible. For that one must also use rare and exotic options such as -pedantic and -trigraphs. -- Hwa-Jin Bae From christ@mordor.pen.tek.com Wed Apr 8 14:02:52 1992 From: christ@mordor.pen.tek.com Date: Wed Apr 8 14:03:00 PDT 1992 Subject: Handling events at a guaranteed rate. Question. Hi folks. Reading the latest commentary on ISR level processing has me asking some questions. Timely too, because we are designing a system with at least one hard dead-line. How can I build a system that will guarantee that an event will be processed every X time units? And announce via logMsg() if I missed one? For example, let's say X = 10 msec and we can get a system clock tick every 10 or 5 or so msec (programmable). From what I've heard I want to have a high priority task that "takes" a binary semaphore and an ISR that "gives" the semaphore (see section 3.3.3.2 of vxWorks programmer's guide)... taskInit() { semId = semBCreate (SEM_Q_FIFO, SEM_EMPTY); taskSpawn (..., taskCode); } taskCode () { while (1) { semTake (semId, WAIT_FOREVER); /* wait for event */ /* * Do processing of event here... */ } } taskISR () { semGive (semId); /* let taskCode process event */ } Given something like this, no work is being done at interrupt level, which seems good because it makes the system easier to tune via priority levels and doesn't turn off interrupts with intLock(). Are there better ways to do this for timer based events? I'd also like to add some code that warns me if I miss this dead line. Initialy I wanted to put in a watch dog, but at a clock rate so close to the event rate, the resolution seems to be questionable. The other approach might be to add an extra call to semTake (semId, NO_WAIT) above the semtake (..., WAIT_FOREVER) and check for absence of ERROR which indicates that an event was missed because we expect to block until the "give" happens. Was that clear? The point is that I'd like to know if I miss an event, but if interrupts are flogging the processor we may not get to the semTake() until after another event has passed; in this case, we would never know we missed one because the semTake (..., NO_WAIT) never happened. Whew! So, do you guys mask off interrupts (which seems deadly) in the ISR "give" code and then turn them on again in the "take" code to guarantee that you don't miss an event? I'm probably going to get pulverized with flames here, but I'd appretiate an in-depth explanation of the trade-offs. Thanks in advance! Chris Tilt Tektronix, Inc. From marc@sun-valley.stanford.edu Wed Apr 8 16:21:59 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Wed Apr 8 16:22:06 PDT 1992 Subject: Re: Compiler option problems >Submitted-by iphasew!hwajin@apple.com Wed Apr 8 13:17:27 1992 >Submitted-by: hwajin@iphasew.com (Hwa-Jin Bae) > > >>IMHO, not using ANSI C, now >>that the spec is formally approved and excellent conforming compilers like >>GCC are available, is like programming with one hand tied behind one's back. >>In the PC and Mac world, any tool vendor who didn't support ANSI C would >>be dead meat. It baffles me why the UNIX community (e.g. Sun, WRS, etc.), >>which prides itself as being at the leading edge of technology, is so far >>behind on this one. > > >[Soapbox begin...] > >Partly this is perhaps due to the sheer amount of source code that >needs to be converted to ANSI. One could condemn an engineer to >sit down and ANSI-fy the vast amount of operating system source code, >or one could encourage incremental conversion while promoting use >of ANSI style prototypes, etc. for any new code being written (well, >maybe not ;-) ). Not that my objective is to get into a shouting match, but ANSI C has become very dear to me, so I must add a few caveats: Yes, it takes time and effort, but it only needs to be done once and the benefits, in my opinion and experience, more than justify the effort. We have ANSIfied everything we write as well as much of what we deal with. This means fixing header files for SunOS, VxWorks, etc. If a couple of busy students can do this, I fail to understand why big companies can't. Further- more, I do a fair amount of consulting work to "real companies" and I have pushed all of them to do the same with very positive results. >UNIX C programs have existed long before ANSI C was developed, long >before the DOS and MAC versions of C compilers. Not only the kernel >source, but a vast amount of UNIX utilities as well --- now including >a good megaton of X11 code and, yes, GCC itself, which is written mostly >in elegant K&R C. I imagine that there are far more total lines of code running on the 40 million PC's than the couple of million UNIX boxes. I admit that it frustrates me that GCC 2.X was not written in ANSI C. Now that it has such fabulous cross development support, it could always be bootstraped by using GCC 1.X and then using 2.X on an originally supported platform to cross compile for one of the newer platforms they now support. >Another reason is that most operating system vendors (and certainly >the lint-religious engineers at WRS) lint every single line of >their operating system software, including cross-file checking >using generated lint libraries. The problem with lint is that it requires extra effort. Compiling with GCC and the -Wall flag is totally automatic. Your code gets re-checked everytime you change anything. See also comments below on automatic header file generation--something else that lint doesn't do for you automatically. >Apart from the benefit you get using "const, volatile ", etc., >lint actually does more checking beyond what's possible >even with GCC with "-Wall". It also does not have ANSI C brain-damage >that defines a scope of type declaration to function prototypes, causing >in some cases incompatible type error for the same type depending >on the order of declaration. If lint does more than GCC -Wall, then why does GCC -Wall pick the WRS supplied code to pieces. GCC V2.1 does everything and more than lint, including validating arguments to printf format strings, again without any extra effort on the part of the pro- grammer. I think that's pretty hot! >Using automatic prototype generators or ANSI conversion >programs is at best too risky for operating system >source code. We have developed a system (and philosphy) for automatically generating header files (which we have being trying to get WRS to adopt) that has been used both at Stanford and by a number of commerical software vendors. It works very nicely. [Note: it does NOT convert K&R code to ANSI C. It produces header files from C source files automatically everytime you update your source code--thus guaranteeing that the protoypes that you export to other source files always match the defini- tions in the implementing source file. It works for typedefs and structure, variable, constant, etc. definitions as well.] > I agree that in an ideal world, we'd all have enough >time to invest in ANSI-fying every line of C code we come across, >and the world would be "better" place. I fully admit to being a idealist. :-) > In the mean time, hacking up >GCC gives you what's missing in K&R C, and lint gives you all the >checking you usually want for your code. A caveat of course is that >most UNIX vendors do ship their lint libraries, while WRS may or may not. See comments regarding lint above. Again it requires a conscience extra effort, which is usually only performed when one is getting ready to release a product, whereas GCC checks your code every time you recompile it and makeheader (our header file generating tool) updates your header files every time you run make. Everything is totally automatic and thereby prevents any part from getting out of sync with any other part. It really does work and it really is worth it. The amount of time now spent using a debugger has been reduced by an order of magnitude. By the time code compiles warning free, it ususally runs the first time it's tried (assuming the under- lying design was sound). >Obligatory technical content: > >Even GCC, a mind-bogglingly good compiler, when used with -ansi >option, is not 100% ANSI compatible. For that one must also use rare and exo > tic options such as -pedantic and -trigraphs. Tis true. --Marc From marc@sun-valley.stanford.edu Wed Apr 8 16:35:23 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Wed Apr 8 16:35:30 PDT 1992 Subject: Re: Handling events at a guaranteed rate. Question. > How can I build a system that will guarantee that an event will be >processed every X time units? And announce via logMsg() if I missed one? > > For example, let's say X = 10 msec and we can get a system clock tick >every 10 or 5 or so msec (programmable). From what I've heard I want >to have a high priority task that "takes" a binary semaphore and an >ISR that "gives" the semaphore (see section 3.3.3.2 of vxWorks >programmer's guide)... I would certainly agree with that approach. You could add the additional event checking you wanted by clearing a TAS flag at the end of your "task code" just before the call to semTake. The ISR could then call TAS before doing the semGive and call logMsg() if it doesn't get the flag, meaning the task code didn't finish in time. Note--I'm dashing this suggestion off with out a lot of thought, so it may have subtleties I haven't considered. For instance, I assuming that rather than "missing an event" you want to know if you finished processing the previous event "in time for the next one". Also, I'm assuming that you aren't trying to recover gracefully from falling behind, since the call to logMsg from the ISR will slow things down even more. --Marc Ullman Stanford University From daemon@vxw.ee.lbl.gov Thu Apr 9 04:00:27 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 9 04:00:34 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 9 04:00:20 PDT 1992 Subject: Need information on VXWORKS for VME Subject: for sale ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Need information on VXWORKS for VME Date: 8 Apr 92 18:40:40 GMT From: syong@gridlock.ardfa.calpoly.edu (Shane Shew-Shin Yong) Organization: Applied Research and Development, San Luis Obispo CA Message-ID: <1992Apr8.184040.13682@petunia.csc.calpoly.edu> Sender: news@petunia.csc.calpoly.edu (Flower Power) I am a student researcher here at Cal Poly doing work for California Dept. of Transportation (CAL TRANS). We (my research group) have been using OS/9 for our VME (147A) as a platform for developing real-time data collecting software. Recently, we've heard of the operating system, VXWORKS. Someone suggested that it would be a good replacement for OS/9 since we have encountered some problems with it. However, it will take a lot of work to port over code developed on another operating system (especially real-time software). I was hoping that somebody out there has had a similar experience and would care to share his/her ideas and comment on VXWORKS as a software development platform. Of course, I would welcome any opinions, suggestions, etc. I know very little about this operating system; therefore, I would also appreciate the names of any books (and their author) and references that can help me. I am most interested in these areas: 1. TCP/IP, and RPC support (our VME will be communicating with a bunch of Suns). 2. Reliability; our real-time software must not fail because of OS bugs. 3. Serial device communications. (modems & serial connected workstations). 4. Good technical support. 5. A UNIX-like interface would be nice. Thanks in advance. sHaNe email: syong@onramp.ardfa.calpoly.edu --------------------------- Newsgroups: comp.os.vxworks Subject: for sale Date: 8 Apr 92 20:42:42 GMT From: fester@etorofu.island.COM Organization: Island Graphics, Marin County, California Keywords: heurikon Message-ID: <1992Apr8.204242.841@island.COM> Sender: usenet@island.COM (The Usenet mail target) For sale: Heurikon HK68 and MLZ-91/21 Microcomputer. Includes all manuals and documentation. Still in box. $1500 OBO Mike Fester day (415) 491-1000 x190 evening (415) 750-9220 or email me at fester@island.com - -- Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d X ^? exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..." --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Fri Apr 10 04:00:26 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 10 04:00:33 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 10 04:00:20 PDT 1992 Subject: heurikon ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: heurikon Date: Thu, 9 Apr 1992 16:41:29 GMT From: fester@etorofu.island.COM () Organization: Island Graphics, Marin County, California Keywords: for sale Message-ID: <1992Apr9.164129.8597@island.COM> Sender: usenet@island.COM (The Usenet mail target) Heurikon HK68 and MLZ-91/21 Microcomputer. Includes all manuals and documentation. Still in the box. $1500 OBO Mike Fester day (415) 491-1000 x190 evening (415) 750-9220 or email me at fester@island.com - -- Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d X ^? exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..." --------------------------- End of New-News digest ********************** From bard@cutter.ssd.loral.com Fri Apr 10 05:43:17 1992 From: bard@cutter.ssd.loral.com (James Woodyatt) Date: Fri Apr 10 05:43:26 PDT 1992 Subject: Exabyte 8200/8500 driver wanted for VxWorks 5.0.2 Does such a beast exist? We've got a bunch of 8200's now and we're replacing them with 8500's. I've got a driver that came from I'm-not-sure-where that we use under VxWorks 4.0.2 but it makes some faulty assumptions about the filesystem for 5.0 and the SCSI interface is otherworldly. Before I go blindly into the task of porting this monster, is there any chance of finding a driver already built to go with the 5.0 scsiLib? I've heard rumors that such a creature exists, and that someone on the net knows where to find it. Is this true? Please point me in the right direction. -- __________________________________________________________________ | | James Woodyatt VOICE: (415) 852-5429 | Space Systems/Loral (M/S G87) FAX: (415) 852-6286 | 3825 Fabian Way E-MAIL: bard@cutter.ssd.loral.com | Palo Alto, CA 9430 | From susanna@tomato.lbl.gov Fri Apr 10 14:34:36 1992 From: susanna@tomato.lbl.gov (Susanna Jacobson) Date: Fri Apr 10 14:34:43 PDT 1992 Subject: SCSI DMA from offboard VME mem In hopes of saving hours of search through catalogs and calls to sales offices, I ask you, the vxWorks community, for pointers to VME boards that 1. Do DMA to SCSI from off-board memory. 2. Run vxWorks or run with vxWorks software. And of course if you have actually used used such a board, I'd like to hear about your experience. (I guess I wouldn't object to an SBC with DMA to SCSI from its onboard 8MB of VSB-port data memory, in excess of any system memory. However I am also guessing that boards fitting that description are less likely to exist than what I have specified above.) The current system setup includes a VME crate, with an MVME147 running a "Taper" process among others, that receives data via VSB from other VME crates and then writes to tape via the 147's SCSI. (MVME165's in the other VME crates write directly into dual-ported VME/VSB memory cards in the Taper crate.) Since the 147 does DMA to SCSI only from on-board memory, data must first be transferred from the dual-ported memory to the 147 onboard memory. (The 147 is running Version 5.0.1 of VxWorks; the 165 Version 5.0.2.) The goal of this query is to learn whether we can add a board to the VME crate that will eliminate that intermediate mem-to-mem copy. Any information welcome. ======================================================================== Susanna Jacobson MS 46A-1123 SRJacobson@LBL.Gov Lawrence Berkeley Laboratory VOICE: (510) 486-7801 1 Cyclotron Road FAX: (510) 486-5936 Berkeley, CA 94720 ======================================================================== From daemon@vxw.ee.lbl.gov Sat Apr 11 04:00:24 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 11 04:00:32 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 11 04:00:18 PDT 1992 Subject: Differences between shell and sp task starts?? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Differences between shell and sp task starts?? Date: 10 Apr 92 06:32:07 GMT From: paulg@tplrd.tpl.oz.au (Paul Gittings) Organization: Telectronics Pacing Systems Message-ID: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au> This is a beginners question and I apologize in advance if I've wasted bandwidth by asking for information which I should have been able to find in the manual (I did look, Honest). Are there any major differences in a tasks environment when it is run from the shell: -> main to when it is spawned off using "sp" ?: -> sp main The reason I ask is that we have just started to play around with vxworks and I wrote a simple "socket" program which, prints a line of text sent to it from the unix boxes (code is at the end of this article). Well if I run the program from the shell everything works, if I use sp to spawn off the program the target locks up and has to be reset with the off/on button. I traced through with vxgdb and for some reason it shows that accept() has 5 arguments instead of the 3 I would expect. The extra two are 0xeeeeeeee, which is what vxworks writes to the stack right? Within accept() (or a function called by accept() ) a call is made to bcopy() with 0xeeeeeeee as the length of the copy, no wonder the target locks up :-). We have vxWorks 5.0.2 and our target is National Instruments VXIcpu030. Cheers, Paul Gittings ________________________________________T_e_l_e_c_t_r_o_n_i_c_s__|/\ __ Pacing Systems \/ 7 Sirius Rd, Lane Cove, NSW 2066, Australia 61-2-4136963 (voice), 61-2-4136868 (fax). Telex: AA 120576 ACSnet/AARnet/usent: paulg@tplrd.tpl.oz.au - ------------------------------------------------------------------------ /* Hacked sample program to try out sockets on vxi target */ #include "vxWorks.h" #include "types.h" #include "in.h" #include "socket.h" struct sockaddr_in cnnSocket; main() { int sd,ns; char buf[256]; int fromlen; sd = socket(PF_INET,SOCK_STREAM,0); if(sd < 0) { perror("socket"); exit(1); } bzero((char *) &cnnSocket, sizeof(struct sockaddr_in)); cnnSocket.sin_family = AF_INET; cnnSocket.sin_addr.s_addr = htonl(INADDR_ANY); cnnSocket.sin_port = 7000; if(bind(sd, (struct sockaddr *) &cnnSocket, sizeof(struct sockaddr_in)) < 0) { perror("test->bind"); exit(1); } if(listen(sd,1) == ERROR) { perror("test->listen"); exit(1); } printf("Socket = %d\n", sd); for(;;) { ns = accept(sd, &cnnSocket, &fromlen); if( ns == ERROR) { perror("test->accept"); exit(1); } read(ns, buf, sizeof(buf)); printf("server read '%s'\n", buf); close(ns); } } --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Apr 12 04:00:22 1992 From: daemon@vxw.ee.lbl.gov Date: Sun Apr 12 04:00:29 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 12 04:00:15 PDT 1992 Subject: Request Basic VxWorks Info Subject: heurikon for sale ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Request Basic VxWorks Info Date: 9 Apr 92 15:09:54 GMT From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) Organization: Brookhaven National Laboratory, Upton, NY 11973 Message-ID: <1992Apr9.150954.5631@bnlux1.bnl.gov> Sender: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) I wonder if some experienced VxWorks users could answer some questions for a non-user (me :-), so that I can make a rational decision about using it in an upcoming project (where network support is crucial) ? 1) Has anyone used VxWorks NFS work with NFS servers from either : HP/Apollo NFS (Domain 10.3.5) or SGI (IRIX 4.0)? What other NFS servers have you used? 2) What is the maximum number of (simultaneously active) sockets in a VxWorks system? Is this configurable by the user? 3) What is the default size for a UDP socket (what is the maximum length that can be used in sendto(), without first using setsockopt())? Is this configurable by the user? 4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation of RPC use setsockopt() to allow 8Kbyte UDP transmissions? 5) Does VxWorks support parts of XDR which are *not* needed for RPC (specifically xdr_stdio_create())? 6) Does VxWorks provide some mechanism for allowing a task to 'clean up' I/O objects when it is deleted? Specifically, if a task creates a socket and binds to an address, but then the task is deleted, will that socket (and address) continue to be in use by 'the system', even though the task has been deleted (effectively 'orphaned')? I would be content with the answer that VxWorks has a 'signal' interface, allowing one to install a 'signal' handler which can do the cleanup. Although this would require me to *only* delete tasks with signals, this is acceptable. The VRTX32 solution of 'task delete hooks' is ideal, because there is no restriction on *how* the task was deleted. 7) Is there any word on Xclient in the near future? 8) Does VxWorks provide 'C' function prototypes for it's system calls? Thanx in advance - Larry - -- _ @_ _@_ _ @_ _@_ _ @_ _@_ _ @_ _@_ --------------------------- Newsgroups: comp.os.vxworks Subject: heurikon for sale Date: 10 Apr 92 17:35:05 GMT From: fester@etorofu.island.COM Organization: Island Graphics, Marin County, California Message-ID: <1992Apr10.173505.3673@island.COM> Sender: usenet@island.COM (The Usenet mail target) Heurikon HK68 and MLZ-91/21 Microcomputer. Includes all manuals and documentation. Still in the box. $1200 OBO Mike Fester day (415) 491-1000 x190 evening (415) 750-9220 or email me at fester@island.com - -- Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d X ^? exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..." --------------------------- End of New-News digest ********************** From leonid@amil.co.il Sun Apr 12 07:08:55 1992 From: leonid@amil.co.il (Leonid Rosenboim) Date: Sun Apr 12 07:09:03 PDT 1992 Subject: Re: Vx Exploder Digest > Date: 9 Apr 92 15:09:54 GMT > From: hoff@bnlux1.bnl.gov (Lawrence T. Hoff) > Organization: Brookhaven National Laboratory, Upton, NY 11973 > > ..... > 2) What is the maximum number of (simultaneously active) sockets > in a VxWorks system? Is this configurable by the user? Configurable, actually as maximum number of file descriptors. > > 3) What is the default size for a UDP socket (what is the maximum > length that can be used in sendto(), without first using setsockopt())? > Is this configurable by the user? 4400 bytes, if I remember well. It was some time ago that I've handled that. Didnt look for a configuration parameter to change this. Used setsockopt on the socket before that socket was passed to RPC. > > 4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation > of RPC use setsockopt() to allow 8Kbyte UDP transmissions? No. I think I reported this to WRS, so maybe your version already will include a fix to this. NFS client code however has it's own RPC library, which apparently works just great with 8KB buffers. > .... > > 6) Does VxWorks provide some mechanism for allowing a task to > 'clean up' I/O objects when it is deleted? Specifically, if a task > creates a socket and binds to an address, but then the task is deleted, > will that socket (and address) continue to be in use by 'the system', > even though the task has been deleted (effectively 'orphaned')? By default, the socket will not be deleted, simply because the application could have passed the FD on to some other task. If you want to do such a cleaup, you can use the taskDeleteHookCreate() and program whatever you want to be done when the task is deleted. > I would be content with the answer that VxWorks has a 'signal' > interface, allowing one to install a 'signal' handler which can do the > cleanup. Although this would require me to *only* delete tasks with > signals, this is acceptable. The VRTX32 solution of 'task delete hooks' > is ideal, because there is no restriction on *how* the task was deleted. Vx's solution is as ideal then. > > 7) Is there any word on Xclient in the near future? Sure there is. It's a whole product from WRS ! Plus there is one from 3rd party too, and an Xserver from 3rd party if you fancy. > > 8) Does VxWorks provide 'C' function prototypes for it's system calls? > Yes, and they're supposed to come out right with the current release. > Thanx in advance - Larry You're welcome. --------------------------------------------------------------------- | Leonid Rosenboim | | Freelance Consultant P.O.Box 13652, Azur ISRAEL | | Computer Systems and Networks Phone: +972-3-5561-661 | --------------------------------------------------------------------- From mea@sparta.com Sun Apr 12 11:20:10 1992 From: mea@sparta.com (Mike Anderson) Date: Sun Apr 12 11:20:26 PDT 1992 Subject: New rsh support for VxWorks Greetings! As I had promised, here is a new copy of a working rshd for VxWorks as developed my John Monroe here at SPARTA. I checked with him and found that he essentially completely rewrote the vxrshd from the archives in order to incorporate support for the Berkeley flavor of rsh. He used the good ideas from the archive's version (thanks Benny...) and grafted them into the UC Berkeley code and got a pretty flexible version for VxWorks. There are a few caveats that are documented in the code, but the vast majority of VxWorks functions work even if someone else is logged into the shell! Well, the file that is attached to this mail message is a compressed tar file that's been uuencoded for mail transfer. There're 3 files in the tar file: Makefile rshd.c rshd.c.VxVer402 The last file probably isn't needed because John's incorporated all of the 402 specific stuff into rshd.c and used a compiler define flag to deal with the make. As usual, there are no warrantees expressed or implied with the use of this code and SPARTA, Inc. makes no guarantees of merchantability nor fitness for particular purpose, etc... This code is FREE so please respect the spirit of the Free Software Foundation's copyleft as we do. Good luck and have fun, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== ----------------------------- Cut Here ------------------------------------- begin 644 rshd.tar.Z M'YV03<*L*6,F#9LR !(J7,BPH<.'$"-*G$@1 (B+-FC0 &'Q8HP;,SA>]!A# MY,B1-&+,L'&QQD<8,V+4N&'CQL@:-6S$L%BQI\^?0(,*'4JTJ-&C2),J73IQ M1(($6T"\J#-'3HX7>-F#H@W9D!DW0J"S9LP@=N\(5/G MX!P79,T^E3(%R9>],%R\>>JB=0++F$%HYAS6S!LY()*X>3.F MS)PYM^>(3D#:]. EJEF[GMT9KFW<3=[0N?V&31C!A T''U[\^'#E95TL*5($ MRII-<9@:ZCU1AMP&)08"'?@Y08(5*7AQAG@-5@28W:%(<<99=!A'Q)&?&'% M#(45D4""1 P!114]-#'$8##UU0(=%F;L%UA8F!29$&8G*'B8E3MZ>$<+)B% AMI#*06 M&G^=(2D((M3!9!MEN("&"':E)<(2Y>+WTE#DN(SG+;,)M.,^ITKWYWZZ_'WO??S-M..%6&(VXY M[SBLX?OYP%-/O-;L(Z]YV,V3_7ST:K,\1;U/3/&V^+@CWPM,- 8VU.%A]@/! M_MS0/^;5[TX*A$(0I# $<,UI1$F PA#L,X(.@F!T+WL;TVX'-0$22PQ/BY(5 MKI""R44(!%<0D<"NX!N0Q:A;N$F>"\)FGX&AQ@AL )7,H@2F-,$@!1>)$@AG M@,3KS4UU"A@8AH HQ 00L48WRA$2E3B]ES51;JG;F7T4\"0VZ& TI0F3$^;# M!.:DL0ESR5E^@C#&$?3@CGC,HQ[WR,<^^O&/@-RC68:PH0Z%Q00@8(*),O2= M?C4)AQB#BVYXXQO4[&E+7<+5>(AC'.1D)33-42,;S^A&TZ!&-0-20"A/^88S MGJ%4S5&-TL[ !C)8,E, 2LLJ^8+*5XXAEF^8Y1SN0+%;]F:7J0EF A3@2V"2 M,@&3(8,+QC#+4EDR2OC1#W^:F)9FE@:5*L3##X,X!R1&T,QSO@@0$>^L*G3 9,.)P\3G) ^<8X2F&. M9PSE)>[9V+\Q:* 2:$,FGF+ O'"AMZ0(0R(98S3 M4ID *J A#8ZA0QCFD"&%@:!DE;G,PQH&&-^XP0YO&$BGAM,&OX 7'*@0QW@ MH+$V_*5ACK%-8T4VA_HL$T)N,,,8D #6^PE A8P"RPE(%2ED+L6#N&^!P0?Z":PQKF$(:]% &YI9A-W+(0Q#(0 :V'&=<]DE $?"PI7UI M$C9D6-9M7_O@D2WK+G Y;&+A,@7&.A:RFG'#&<5&R-VY_H+T21UC&,"$<9$:NC]C@!?*1;,$-/B^[VJ%PX3VCH$([IP,2M=+Q;V/6GUYZ2AK4?I$M MP#KM?%=@'?3MHCQH$M9S4#<5AB $Y3R%27R'=>!/0DBCQR@OP4T+BQ8O!$C" M6FS7YCMFY, "%X&J-9,]B8,AO+ 6<9:Y%>X!KW.]83KT(->66D,/;N!KL<%Z M]2/+;W994&$6U)X%N2]]BTO_HL^T1H&R=NWG'Q\8M4M^\A#>U]LU5?[%D:_!1:XX0ZW M009ST 6 1P28=2YA8'C0HADI)C9P8 9PP%Q0%H&2D084"(%]]W?9=X#>87@/ M2('7QEP71H$[AH$!8W^<)39R, .9(A/V!0,M< 8QL!$GX7?>EW8&>&T=Z%IL MH2S1A1LGJ'YB@T\C G]EQW8F,B_=YAA$:%JVP5P[)@9D-B_$X@8*IG=;HG;- MLG-R( +])P(/=AQW0 8BD':61B)<*'S04FV!$8;#1 9B$R*7P25&N'9M-R\H MIX97F /8P?A5X=EITB6XFQE4'#E(3:'IH4/=A?4,GEG. 9U( >T,B\ J#C+ MLHAHX(!C"(A\AX1[5HEK<(END8E/P09_"'); (:C6(:!)XCS8BI.MAM1YFQI MP!9C@'=B,V#ZARUM, ?]YP9O$ 12&%L$F$BB166!82*F=3$+>!M>0G,)P(EJ MAP*\Z!C_P3"OE0=M((6F&&^:53%E4!_0*(UJUP(E\1_ :(6C]A^T] 9B\"3\ M=8Y^T5BE]AIK<&6H>"UU( :6TH6 =Q*NF(W;V!V.H8S8$EVMQ8O(=%((G >!&Z8D!P$7B> M."]3IG)!:$&]DI)UL(-Y5L) MP%BT18XCT9)&Z1C$8BGX)P9G@ 0FTY32")4/(P9U< 8P@AM,Z83*E "M)7HM M9H0(E@9FH("1U8!/,5Y8R09:R8E0.5[?EI5D*3962 =S69> >)8<@4 9X4 :0>$%V$9J5J9>7698WN2$Y"2),!R_(@A@_.1>?508G9A?&P2E$ MZ76/R6P=IY2FHIEEEXHF4H9?^ ;.PHH704C*J8S.%6_0.2_7B0)]\1^6DHQN M\ +968]M<%B@@HH:.'EKV9;=QUD9UX-W-UC+""FW^"HFLYF/- M2'G(V-2\[-J1,\B0C%F148(XE<:3% M 7IQ4)-E0&(C8:2%B*0=6G93L*6^Z:5FP!9P<6T:"1U65?%F9C MT!@Y0 ./QJAY\JAP,(8J.'*;6A*F^*GP$JJ5X5T\@ 1+( 1?, 14( 5,H!J9 M"JJH\:AL<(^T=5QP@ >S6JJU6A*AAP:[REPB$ ,Y( ,N0 ,XX )R&@.; P. M9JPRD . IJJLZJJP"FC7QJN=JS4RBS6VJJOR@3VNJV/]JVFNGJP),*E/,03RLB%3JFT7IBQ.TAM1)P2),1!^HB$/ TE+Z$!+ M0T &E&.WLGW0(HM[4G$E6P5X5H!0)!(!RE>[I@]A3KF0;PAJ"9 ME187LV$GA@)(A$BU9+SQ]J%DW^%IRS#!R\ 7*6%UE/!+OXB()6_&2? MI'!@TK#07++-T8 ;N M%9$NPB2W4K*;O!7J]FQ)Q@5N( (IL ,F7,$#D@!YE0!#P!:ILD](",:&)\1S M#$G$+(L)8,MO'!DH@ )?7'AB'%L@X)UR?$,H$ 0ULA]%0 7,-05/, 1+\!ZO M6@1!T 0!# 50\%!4\ 1?L'A0D )(=$< $@-(M,4GD0#Y.1QRX%[L'",ZH'%. M4K07 R/STH]MD9#]'%_=+#9GH!UIL<&8-UG (F4%V437Z< M.:6008U(HL7=DA?1ONQ=B <=+N^)OZ],Y0%F\(:EKQ?-CSK-A3";_V#-GX/,8L( ,9[=H= M[8")(=+N-=TGI@.[3=,V[2OI%=P*L--V.LY-)LTU&6])MB05,F7I7'ATK<_Z MI)%,4G!T8'AVG<*6!1>,BLTL<@*PIGT=J&X6A%BP+&U_X1=T<"D<%F_?DAA. M^EJV]:=*4\N$N(,E8\>^&6VGE5ID^QD785E'6:C!6YBT)=19&HVL;-&$BE@@ M,5/'$Y4P2N(P4@L,5ZY\R/0;U? M4-*79@+WS,:QQ5PFT)]J?-U;#@)='M-U#(!(Y .Z1FI/'F-/D5?,G9E0+$*NK04MZ4'B.6;N5EKNEH MF!B=_EJB[O07L8C@'YLB39NOC3%=FSW)*6/)CGXHK5[G-LLML$G;82J]<1',HY%K (QW6[/KFZ(= +I9X1N1\3#^PA;2 M=!$GL/3,$S*=$1B@-64HEW&6@;>YX?+M$A9.SX6FK&YW8!"]P3RP>/0C4@9= M]R%L'[E2&9G*F 0N7R'?\>BWXH;PQCS*.&6!K18TB@)3=G.C_O"3_A1W<&%O M<>E]W>H9NEPTN6/)+.YZM32'51SVZ5J3/]=INB'[)'#Y M7EJHJ9K.DA<#E\EN^&,9T[I&IOE)GNI0AB2@/\>BKQ9UQLN>/NLHH,N\3.K, M@OV,ANI/\?NK609#4&?7/_V,YNF8#H#M#HMKG >2K>NQ?I)M9DRT). 9E_U"B- 08P)W?*F-CH VV.E24VY59# M*%]C61:;S_=X'P67@% KL%_JZPRW!#M@!>0C?>9%?6B6J2%24?<@-N2D7\[ MI[J%)@88[=B";$DYIF]II##41*0NQD&Z%(9- 1 W!< +)C$.X)(, DJP27( M!)N@$VR"2D/%.08F0!SZ5)&I.[!K4QB'?8+\Z@Z[B7!R( 4VG.\@ ZQ-\E,: M26"YP8%(1-9V3@6\&. O^.V3V]?Z2DO>NPO9"034-.-'N38IOMS)4FDC0M<%L^XGQG(@3IPF/TY M6E:%X (-ZV*';!6V0A#S"E=A++P-.R#^2;)=^)UT@YA#1D_ 6?"U.3;#*M@6 MRV 0PPHE@*OC!%Q5[( 0I>/T*:@CQIH,DC9:2-\H+- P;+C"$@ 2* )8P$9P MO"J@(Q) ]3A])T"@J)L*D0^Q (-#$LLB8.089;'+.-D+9$CJ@!>!,UB MRXII,:8OA;D9OX#41I<:J!!FX!:-"&I$@6J)B:$# PR)3#JA&!7I@!LHBG3@ M*,H!59;"-%L3,!%042HJ-LE3,I8%FQH9V48K5K $ !_D0RB$&S)I#AR6&^@& M_D.B(HNL+%&] *'Q4)Q<7I0,,2(262&?6*/(X2.9=' L 12$K! 67T0.3&'_ M@1MZPZ+!7-YA/+0"\[ (:!C1&73K8C[M0D4D,J ;-$PMV8[1<+(]AN](!\A +(1D.Q /W!VW MJ%D6H!P(#%##)_$ZC9@:15G(40%P8,5D!5RX U&,!WH#70P%^+%.@D0"QDCL M,*@1;M0+?W$&%N.QP(W_[5%<1E9V(!^)"(B02:H D/)2 9F8@J[3F!O+5@@ M?X*=J->[,S?.12/FM2>0'_3.'- ^UVO#3$A6QB7F0'%H+'\!U/4*"G<;\)NN"%_@B#XB MMI>8DC1,H[$TS"4)68$G49.@T(M@ B?&C0E%TP,%D(0#7&]P0SN6Q_"XSWS# M&S@"EN$=L8'M> 3\&7SX8$^@"E !$*@4PX!NN@T8\?_UAN_T&*2A/%L,>-(= M/8GM>(90P)_\ H&2H*G")S,,UX!;BVU*\88PRCRH3T8A_9.+/2U.DD?S*(GJ M)*3,DY.R//;)@7,I"2.A9&5SP%"ZJ;NE*)%1HYP7C_).PLH]61XK9:V4 E*@ M&#Z98R@'/J5/"Y4MK3S^2DAB*I57,FMBO(X@^#I@)\)(F-*8=B( )^T8>D)D M8!G-FPPG+=MMLTUG_LS 3/MV \\,I,JW]A2@@(MP@P&P.G8,#G;)Y@7-$SCQ M#BA*GDEW'5! &K@]R3 -\(!&EC!7P I@."_B(Z8!G_,?G #680(.$":^" '! MCNQ?B\(T_>@@S!I;J/ULH9D\ W: U&1,MH1I8B((0'-]H;OMNE[7'+BEL!M) M2+ M4 ("P[Q3E],E#9Q,B=D%WB6XDY=/06R,,[KHF[Q>5AE$.G%QS0L(]_?\8XZ; M,K&Q-Z3#_;7YQF80*!4F:EX /B"#&TZ Z=F'?9.HO0AUTW!B -I\$3N1#A P M2;?\YADUTD9F!C (@3Q@RA[G')!B5.QD% 60QL$!T"2 M@11P;>X0K:M>68$XE@'C: :(U1=8=M/%(VZ!SHG_RB*+.3=?0-TTPMI9 */< MXVP#D9,,3,[*>9 P9\78=LC32=Z&Y9D*L9Q^%)VDL[693INRYLH.8M)&8%$L MULG7J=[LA.RLC"@B,U:!;H@[BP9O>PK$;7>F$HE3V1(;"OB?M#. "E "&CLZ MVNE+ E(F8QA.)U4[B4EN@4ZE)?)E#'E6/Y3B.92-GI.ZD*'2>42>7 34HM3"\HV?3TZ17E),FR:T92;NF'X40/,U.\#1X MF6/D9><8FP_+6*0+MG!X,H;8JT4#L'/E)[=0(3 -#T PU4'-15$9F@ HWENP M>&F!396'WB3B?M,)X &$L[3@&-FP&:*IRIFF;!))U$GI&0,>6>< I @3!!#2 MD%F\V*DME:>(=,TITI;Y(MJD'*BE\O.;JALUMP>^J(NY(5/&]-"U)/0AINE3 ML*=UT@2DTW^J!E9 .P6,\>;1T1;(0+/ Z5-HB4M##.RXF7CZ=@R0X7\L;5J> M!(>:2W&IG5IE3\%1_*9Q2AUJ \=0H_2L?-4-UI$WFISZ<@+RLZW!R9##(>LD M\9HUFY.195$IP-!<'@C\HK "@;D <[,.OV8-RZE/9*=NCY[:/8J&_*P!XR+^ M%=7_<%3Y*21MI\R%J3*U4(,';H!;59E0]4-D#JI:P7AIN!NJ$()E\CH"HVNZ MFUA];$DH%@(C[C33/IJT^VZV303LS*#2,T$ LYQR)V99.)?R9EA_%FJA+RD M7"[6K=!8A\!?0'"0E<2M0>W$,4[ LCL!+F"/7M%VJC+/GF:1+7HQ,::<.DD8 M<\8M#9MBE7>:#-_Y4E<9X7(+%,ZOA9:)E TOY %BD@<>'N.$?%+.=5%!$(,":F01*)U"D@D0R5": M_X(G9@67Z$5\P86+,5XSQ!5L+,W.K3G4TR<%*R!0A& %=7':A.U1[HRZ>"/(TF5)=&2JJ3R4O7,!?S"E=#8%3U&G25+%A5 M;*G8CNSYXAY[ ZAJ-+#*/)[L?TA>N<:\TM)V6CU9652=JT'0KOK2I>%>AR>X MI$E $ML%AO\@4$H 'B":7?+<]08;*\Q&0W!:GQ*6PB(23=$6\&7&<%T)LG"U M6#WY8FEEC%4CWI$,;$?= /]6;'2C1D:FOJ* ])KQT.N0/*]#U=."-,0ZTFI- M4#EIGG5$I"S$>!"2Z#YQ7?F5MZE: 5>84Y1"/E'-FT6L!![B9_.RB!?7TT=LP*GGZ5Q"X D[ MC));D/I OB@*N(/P0H.%@7P1'%Q$=CDV/P6GLM%?YT9O9APUGB2-MM11KWA' M\ZAJA:1]])W:MD!J2.5I(3VD4!/*V0EWFTGK:2R=I&C.DIH 3$I/9\TFG:2> M%)3J4U&*<1L1'K4SI_1%I-+A62>QIJ=#$K 4DLI2>4I+.>EM'6Z=8Y=:U5_* MRL@98X 5VLE&/1*5$V^5*A*!@VZ3K'6Q 7D<""XU92]Y841I71;!-D^3VQ2A M:^J$RDWY"B',KMW$FQ5N;Y; <_,W'T/@[+MC$'&JS15[;/,J/>-%X7-\9A?+ M:3XUISW]G.^3R\5/C78ZZV=EE8Q2,7^VSN#P/G5G91MNO1,N_$XZ>UF'9_', MF2A .";/]"GGXBV?VBASHL^'L7J+8_ODGY(W#SR* M%'!'*N]LN[Q=\2NN3OWI.COOO-2EH7?-R5X&2P52S(_)IM'G.U1(%C%K(9$D M>C)_"\? FP+X>2VK\,RL/=>T)I[\HAVF#;R)8;+A+777C_L16>O1M!-Y<2\J M1MJ*+&WK](6ZN76!KMSP^EJI@OZ=K2'@/]16)^=7_ZJ956Q)* 4X-DPS:@>H MCWA5Q!-_+M^F6(_&!J9)OIIW^:Q8I8AM.H5:U&S[]:.&'.DI [*H])P!+OB* M)D?F+;I[%EWY64#[))C+DW5K47?!>EM6MF_7XOCQMP!7 MX-:D-)KDT,:YA7WK-@ZSDW9+@.4 %>VZG9-8C2O68V\U&K[]HA?2^Q H:J&T MUG"Y+;BYD!!V'16&]&YP+TH!$E=;ULR*ZRTO;A7>P\%GXRH9DN-Q72D?C;W^ M<^0*4I,KIU N>_6>BJWF=EU.2DEE+LU%NBY7Z>+<1J9S5:XEEIH^MY0&W3,P M=%>IT7VEL?@C+ETUT'1!L2X-PW)VP9X^JWM:,%QC)(EW>*0=P-?W^R[_%!PG@'" MZ9$$+RRS$X4WRJ5BR,DJ%"^T8+RY]WPF5;0JYH"OF)N\?I%^'M_R"X(W<%IJ MOJ'3\Q)5W?HCI2_I/;^G5VJJ7O7I>YLGLWB>?P;VJM@5RS(1;S^VO?\8]TXQ M@;R1E6?K+P">4I#"[5K[J9M>*7$0I9^9M:/?%J]3GW%T+D M7]D*8AUK_Y4"!]2E!N#>*D7',E\$ 0G8+!=&@MHY@)Z=2+5VX@$;S*8U@16; M9H0"&%AU1C/]625.'R9>&$V1_'H.%* QSZKGQ!K?]OV<4ZFL:B_7=D@#7;<% MD[K\)WDJ#*+\;PFR_&(-9HJ97W#79 'YK_;\"Q 1@$)S9880I+GK)L?-'!&I MUJ=3; C/.*#*RXLU&O)@1FJH.01*GFKL@]]MPK_!^J9IWLLW_6E0;:+YP,PS#:&,/, MXC 3XC-JB(MD;\TKFZ_:!#X4T^ ;\*/XV$$E+(VML5AL] R#WN9 M%>!"6V@Z:1.6-1S=OJ.N,6)1LP URX,B?H3PW$)='B'D:,[%-X]C,X$#3I8&D4"?P01'I!?:A% MZ%V7J-ZID^;HM@ZMG9M7'29&=3-1)B>NS=NS89E'"F/&,1HKF9N(M.?B382; M)&4@+ D,,FD<$NQ?$9&T^P#I;T-,7' P($^+3^1@V]U-U>HVNZ,1\NE+TD?I3+!I08< ) M.%Z(I'-<7@H\495J0$742(0/\ '%5JM9JT8[ ?X0E!*N4[Q/&98?5G,0M';^ M!\]H&HL JLZKNV%,JJ0ZB1?P@ Q(0BA HH[J?ZJ9G_5#-=444['ALLVVC*1U M34*/K(PM(*#B ")>@(_FMMWKNM;$,L ?61DBX8'SX@2,Z;E7!M2-9=@P9A>! M,H^6NDS<-%Y+ !B4_6:X:OVN-]U#RA#[C1 ]Z=Z 9R&$0QV;,-H9PTB+J$ MXHEH<0SZ53P)6(:G];2Y-@X;]L8&ZD$-6AQ&HER;093 \4C%9B1 0 Y (M#H MN^:[;;U.P?73Q2P;6Q#^!_/Z=.'ITC2YE1IMYH!V113:$^+4/EV"C8J]]L2FRUA#3(+J:W29K7:S1-66 M.EQ?/_NH I"(VE9)&%5=>P=V;:.O\'YUMWOG6".19!U 04!I!(T-T5D[D+Z' M7>DUV4AA]UH]YNM]?5D.@K\F,[1%P2ICWLFO(7#3W)BZ#EM.7)M9B:5=SZ5X M3*I/:>*..X#H+Q8-RZ/T)[T!IQ%!K9&>_;AC #^[6Y>)YDH"L3;:@_1SOQ)3 M3*9G;RJ&Q3;WY9ZY2@JKCWZ@[RP:P"%F^W[? QL93]T+A@D;N -?@@K W?:C._R)B56Q MZ\-\M@$+VCI9P"EP!>Z&@%D*9. V$(*;)? 4 ?,!/I2\V^T&@L 9" ,F@FAV MFAD0:F@I>[ZB[EGG+G@4P]Q<9,XVD//(DK\6166?5R M!/;@?SDP:^#?W&+J\T?MNN/YBI;GI'J>D^H-AZ0Y/)QAC>M]17MX=$["'S&( M7]$ASDZ+^!AOK9V#*N_GM:UG[?<6%M!=>(.#X0-]^BYT;\C0>[=D=6C'N"X< MM-A4 1(ZD>.1)0J_1>\7_9]%#]2' E#YR:P1-SVDVHJ- M<,O/PQT::[$R3@!.O&DEUE]MTA,>\*5:(D]%0D_G]!)\GF7Q&L8"L M.5 3O\S_H&ZX]LQ5;'/;143T*]K,>0!%]P-<6V9B#3E>A?ES'>>S]]O<4/02 M, ;437]V#"810/OO!S*@\WB@M>?0PDN:@3.TSQNY1;[(^KFDTW'_C-+Q]TLO MB5HX0$^7\@TA:GH]W^8Y'5?L]!NRQY<&<7.I$._[562T :+!I7!<88$A;J;+ M5AH].;HQ1DP%.+:^905\EF_I58>Z(1I!HZA:.XA*0HK>,TP&=Z!'ZDD/RA2OM0!!GX M$K_M2'""'>Q!3A(OQH,IT:[EF3.!(Y$8;$6J" QSK1?J]H=:6FS@_GU)-A%+ MVV/&91MJXR3$[=@]$S(3C]E\AD7$^ (B\PS;2"[?FN "&O1"\GQCQC@;* M&"U4 ;W0O=O'>*8"/&(9@W+C^FB]A1B TF7 #6 N^KT,R(#^+@/.M*0X),Z& M:(6% *\BQW4M=&/ 4&O*TS?Y:=-[>"]*&NVU.?>40UB3XL2[F$/O5FQ%*!LQ M(/Q_=F-JX,0K#7YM,/FJA5_O=T&D-V9A'*YE8OZSL%8(#W!0%'&-S=WF8_&* M306,@01\ KC U)ZY%%C(WY&*G@)T-0I0\CV@R-.!5^WDH?P)8 $AG7J_,3.M M%LST%Q52M"4,^4OO4$_XRS<2G>LF![?4FULG;3QLO"$*E#6WX6>-&B"T@7X,W)$ M_]H*_9.7]#T@P%M2"RK)'C8D"?!AW6.?IQ3\N%D9KSX.],[T@TNP>*RB )UX-[8KKQ5*3#+20ND>C9,AN]-UY_'@/J6%"]]IC>/ MBW"^);R0WW1>,UXNV#3 Y<> E_^BFD$WB7D1J"1N18 OTHJ#X++Y_^#F(3>A MCI9UFF_":P@!Y"\]D1_TS=O=9_IE LS5@8NP7RZ' -$4\CK MUVE*[5= ,K3V!O] HXU(O^3A/0BP]&G@T"=Z]JYS&ST*>/0.4'1+XC8ZZ^'H M4P"716#@W0IU?*U)]"LVNF"%?)TL\J[:PR/&=6VB13Z*^/8V^M@8=Q+9;JO]M3]]V1XN;'M0'_.? MH5?B$)'<5!07@LNTD^&X5PNWM-W?^R@/[Y'\I5_RYZ;)\X&S3_:GO-IG^U?^ M5>M[B\TQS\V@S]LF:F_#A:1?W/\?TW?G!?_@FVF%G]53M:"?V@^_:D=\1/_= M+SP:J/BH'>.CC:]?[G$EG(^6T4R3W/D\3RSV_)]_@$!YP8K](4_VC[P)D/=, M'LF/?2G_JE4_Z8_[8=$K#XF-\@TJ6-<36/T'3?;E5]T_6AF>FMLP/'TS)%@VE MX>#Q(Y(PI$828I,DK4STS,2'X?T'&AYJ=T1@5,)=U3?IR'GR2'S'Q:AX;PL% MR.+M'06& ?CX[5Q?'P3H1W5N]8S_)P>4!'$9T-?Z85(B( E(T:5]%YVL]N1! M@' 918?EV7LP8 G(!;A]%T$*H'*-!('?;Q&-7 00X. GL'E/+^#_%U"E?99> M"AA0S8")7Y ' _YJ-Z#U M*8%0H-L72I4=06#"IX*=!($?%P@"O'4^7;Z5POQV\T+ D%#%?PY@XS02I(%^ ME!:H!L)U;\O3E\) ?_O$7?>*@%#EEM*02ZE_!5VCY_[M&?#?&9 X?5"U49SU M-9E.3$#^UU4Y ?9!+F4?V';972AX"4TPAE9LL/@@?PG=K1733!9>P9H2B0@_ MO@*486)49%J"9O&Z2"*WP74G"NZ"E5 %4^DX/T+,\Y<*52KBT7<#+")(P!F@D*, \B@R:&)'(,)H.WU03G%GB$D@@]> 80*]/5=I 66 8G M@O?S%+0!>< 7P&J!/B&A'* 2AF4&X0)V?^52G%OE!A=-.+?,4,$OU&(%#EL$;%\/DH[V@"%,&BR8R7"*K"W'0'?@6@N%38&90 M1K&,8O$?+#R[$6,P%!*$,@Z$$ 38.7C.6BC2Q%]W(<#C&$(<'<[!5EGT?4TA MO&&C?0=62+\3,;2&RP]?R*HA@'C,1M@1F@"Z(4$V#[:%,$*T8Q)>.<'AO)5K MK7B>#_WS#_*%ZILCQ1>Z;W7956<$D878H1*TWN@5'LY(P-M=$'T./T?E6#G9 M6I;C_F W8HZ7XQZ=AV'.F!/Z9#IA%7=8=6D?3M(( A[Z-$) =>%M$!-+@F2E M^&Q*>\:,TEB !I6A[-,6!"IPDP+4_N0W\T)-M(T(/FF! +3'; <$HFMH)\A4 MC0& I2#B-U9.*I;^O &#&]PQV$DB%>+8T&0 ./C_#D91X,4/1 MAY@7^C27S6D#8O@QJHVS82F =W(AAX4=^0;D'9$SU3AXO PC\Q?Z-'",IQ"2 MS &WQ_,'*/(:.DV,,<[DAW(,B ##J3ON#(O8XDB(A]@X8V*I/AX)4N,;Y75O M3)U4#3HS:>(TQ"::""K6IQ7D88D R#6"=UT:M8QY*-EP.0(('>/9B#E[A\ZE MT9@C&EQL4]NT6L95WD3>C&2QC<6W ')8"11BX\Q@&H$;8C0&V %/'JGHZE _ MGP5_X2>""CI7@8%O$3LW8:VAFM@!,J%H5R:^AV;.+>4KAHK!8J;(M@%(BPVC M$2JVBG!B52/6$#G46EHS!]0S=4"5@US$%G:;KE/A>J(PLXQBCV_"*+(4"""X:BGC-B>ACJ8CX MAJ-(J B,N]'.%#'&10RB8T?/0(HF(]3('DXVC)1IXRDF9IP-NNC9E&^;8M>( MV: V+89JP]K(C+6B3^,S'CN, 8JX*^I:J9%E$ -MB] /?$@WP@W?XB #=7%8 M%E_I(P1-A4SB$[3<;4-*&7,CI.DW%<=H>.?D.1<#0Q66*(F%XQ)4P8Q=;5N M,:[Y(N[4%M/%:$UN0,94EBU-2D/!I#3M +[(Q#31W6A,#R*1.OH<'MVYL;7M M 5?/5*6J2NLS(A@$KV.TU4^= *X,1;?:E/&#$%48>7(!!V.W^$C<3$X@E/& M%1:$R&DQ'^5H/#9!%4RU=JWM!M3(+$2WJ3=0#AQSMP6*,=^D%B:Y,4J#1#2I M:8K(6_8(X=5ADL+Y"#-1;Z9C/*4PF8]IDF^03XU>VQC"UA@PC(:@PR@"O7"] M <-6L=%AC%D]PSL>>JQCO,<[QHY:FQ38!#(/!N06H#HBD'Z314=S29"P(T5G M!CB0A9X8)X51(QCDZG@"! $69"H60C*01H #>9_]=(5+M-:G(')9A0WPK-UM M)9%W$D+..[YC. =ZG5O%VRK#)59A$D\2T%CD:7T*]$BG84 F#"?6NKE2Y80W MDX+UC5^40AA%M51 87&C65F/$=A)P_N]="C !CCO.&DM'7$*@ 46PHUP)9P5%XU@<6C<%K#%F68V7!T9QC%A/E@=^<-E9W4D M&[=:N7%+0PZH0R8 )!TN)D9F83(='H?-]2E5'0+5QV%H&IH@YZ$9D\@D7A'[\!5!Q33A M5T OOX-@H1@4%K%>9*%8W%='!K0Q6<08_97DT6XX6U 9:0&>H!:J1>.B^YR" MTL:-U!B^9;B!?"A9YA7 @<@(9S 5U<"H!&=?$DF#*/1L+@74P8\"1Y M85Z4&Y:&>T%/;COTA7V14.87 84XE\ &!W8J3%M0%/."X1PF$D8V06%H9]X M/AG&E--A'%WZCHA!8I@8_I%81"#9*3,&GN*F1 89UJVP8[Q%Z46/$V18DT1& MLV'@*!D^X'OS9,PB<-/J=&4X%UH&A,!ED ]7P:0B9DPA9H9G@&;P!8?#FM%F M^)1PAIS!2^@R=X:=D&<@@ID&L9!<#!I$)5ALU6PZ4Y3IA$*:F8E6CEI=)J;!2OAB F M:] :ML:GD6OL&K[&KQ%LP!@%6P)0[@@^QA1-.0C=E!505M;HP)3P1L$(%Y0L M H<.1VZ\E0$3&M#)Z$O?Y*M3]:0%^[D>&0'Y4'ON"8A&;/ 8C N?A>=P?B E@,A( *"T*SP)R$"CM MR1H >UP8LD>OH6%P&.!C[K%[]!Z/AV 9HQ ZQ"PWW0F(_'*7(2X)B."%5 O:0?T\>!V7Z4'4!FX"%_T!\=)OX1>.P? M+<8O4HD((,7(!J*#)"#Q%P."GT @$D@(4H%<($W)?KD&X" <");Y@7@Z%,@( M H64%B9(3B2$L!0LR A8 [P@,<@,@IY4)(9;F6EX? ?PR0^B2?"8J!SGPB*0 M(U!)]")HDCA/2*/3M5 AMR$6X MCNA!PU(\LD[1([D(KK*/\0(B%.89"R5<.B=0"S4PD M)$=ZHG8$))+'AY$A?#KA6& DH@D'Q])8I*D!:X<2V*:O"042DR2UKUK8L-L M0GCP&]XE3^*3_%?@Y7EYE(0=8X=>=@8C"X.(<) M9Z*9+)V!R<4Y?MB7DLF6 "V(); )TEEA;B:=R78 !X FH@G5"7] ):.0\NB: M<)TWI]?96(I+(& M!W5"CHT(U\GP(@UM)]W)M1F>C"K'>Y*GQ2==#T.5 M)-0GB(&?X-WH)S9F?_*?+!\9YH 2?1@H$2*-\HW)&Z3GV-)82"@G!H7RI5PH MRX6&PJ&4'4/ EA:B9)PCBH=0HIPH\\)(H*+ F +*B\)ALIX64(*2..(HQR#- MQJ.L3[ "D()9\#A$"K.@:L*:WF$@A*(\*>E%E$(L>"EPBI5"B!@B>\@<8*9T M*2N)]DFG)"E\1YG"I: I=(XVY::,".6GG')^(BECA-)0!(0!*N4L0LYY=LU& M=REWUCB&2EJ J"@J&0O4O K6,*AFHQ"*J MH"K["K82J[P!6LO"PJ8:6WLH(N+(>9NV*N]!KHBKK"KEAGY&S=)QI 66P\[R?(@ /@LB M&;0D>/O(@D?O)2UG%-,B=Z2A40M$0K4T+#$"UK(&E*!0"]Z++A>_S"_UR_W"&.@O_(O_$A\$,$?,XH0"&#!( M1 *SP,@ #8PF*8_Z$1-,!7/!L$,>@ZSW1GTS^<]!Q,'H$S1GU+0=. L:D1&# MQ" 0.P9@!2/&%A#>,G@R;HTEZ9&D+/:&8=#9N":F-H%,G!C*&#+/#D@D]%% KPPF M\Q.)EK1, 40+<3LV:?YS$8R::XJYM)..EA^G.SB3YC+MDB\#S#!;3N-<$^"8 M,+4>C3;-1)/5S+_H;" 9C$&NU22&,^Y-OHC.=(GK3$S3**Y"<\"&13)B=*KB MQ3@-^3-;F.U:.6<-/&52M-- MB$I(PDOSELHT?I1O<],,*>J-3Q,N@C5635$S!QPU#UENX 0P-4[-%P#52#4< M%F4JUF U?R>"8+L$-$Z 5Q.: C56#;NH=IPU[N):,X.X-2E,7 ,OS#4\X_)S M*.XU'2+3&%H*-F5-8?,HT3.XC2GDQ9"EJR*'9=F4-B[I&H""<39C(_P1VI 8 MHTVGF-G I*M-Z40K?F=PP_'U\56+Q>G0N#I/3**=7W3ASW"">%8)R M\RC2*":"6BHL2C?QR:S1EFXYEA3;N'.]C>*-DN']E*? C=\X!,E0[TWC)M\P M!O2-,0<7W#?66%FSWX">&,:QQ6L1.",'98G@;$ F0P+R#Z4*@U?;!5SM,.*8%.7GB3!;]UY$,%8H2%V0; 0_-< M,H@+BK#X''AP06ZF27"&AD?#,[O997:"S&--A2,7P<43"FD\B!OB\_%X54F MR",$D#Q.@,F#\D@!3"K+X_+\/!%/$JEVT#Q?A\WC+. \\X+.TR_U/&4'N'J7 M+0U"#YJJ(>P&,)R#I(R4/8-J=L'TG!M/#^5#,L %4\_.<5H")UA/A>"H<3T% MR==C'+2#DP6^N@K=/6U=<3U:HNT1PTRS0WED_&$%W*B&A#%-7Y+ G.X8V2X&J+203FDJET"G$+.ZI3V.5N#5V M6@:0W9BS4!'M "F/\6 MD52G#[Z6464+_694.$;4=M-C51@%%2?CE174;&"C3B&W88TV&U_0B! &+0P> M225E!G4<1TX:-&"Q0?//&T2-M5!RD.2CM":EPTD>M ?U.'W0'Y0Q ".IVZ+4 M;!Q&CVA IE[@]1+49"JNPGFU+6D&T_*Q)JU4JD_^\GB;1 ME9$2^0U$&F3T$CE-RUE^$=WA1$73)-AP'0?P!LTS^6Q%P%$\(Y@914B-T+<4 MF45AP%.$&R1?J5A5A%_$"%G1;V3(Q#.^&16+%,%G3=%91+WN"6J1&/5^M$6W M F9)=$TZ=1$H)/)HA&Z! 4:6)608E6"T@&4DL!5BQ!%%L2\9Z'4>=K&$6(8JESQ$O(AT%0M01\_HH[1G9T:K4'05VEIUX MY&&=1Z6K>F0IL$>WA8L '[T \E&@(L\X>/$,_U2ON5WCV$+E=F1C!9+:5%]),1BUH2"$IA[0D81E"BW$@(G$8]8WF82)M'"E2 M2R07M$AOS(OTM3T)C"R5=2--13#(S289\$BSH!L4))U:QU9D).$I245LD_0D MD7E24F:QRU5)N]&59'!D28X=EY3']7,Q0ICD0JHD)].DIB9%L?7=MO8FY;*" M'1E )X58>QV)96)92I.=H%30Y4J'$J^TV'UVQIE>%RE!=GV=I04H"4KS:VE' MP#Y+EE^TI&TLGA5"M33;D;3;42SD*J6T?!*,]<'82F>:@\79]4HTK6/'U$9V M.NT70!C-K_7K3PLW0$N^$JE4U+:OIU*1I/%-JA17Q_Y&Y5C MDS0G/J%DSN$\=\W14MY9-Y<5?'/0COQD?,U+EH5DJYPM55)=3\_1HA;)=4^.DW;KCW6W M&NEW2R*D3R[9[Q63Y7/#EWEKD]E/G,D49\;N9.VM__3>%FX2K $E>P6+.XT MIIPZ4**<1A/B!EQ>5 J3L$T9U6T'Q4Y6@N48"=4\F% 9['';(T6S+!1L!PMZ M:6,3#048V%"/ @YU1%$^/)2O0!E)(#+$E#%$G1B0PI%;#A:DJ\P\JL@1D.]6 M%57!@5%-6@P;KA;9J[2W6S+@7UN;JID3J45X9R'76 M(4TC#U;*Z9 IH\WE_3V266$$6<51DH!7?1;]C;S31=\ M+HVG_9QO@>[8IL#AM85692$0X!LNPDJY3QQ3RZ8R!2F02,X410D7H$J5[K** M31UEVY2*RJ(*5(W.LP5D36:=PT35LSEFMQ7PAK0!NE_9TG8_@E=FU:HF2054 MX%0.Z$49=CN/2Y(QQ'D DI-!%[ISWYIC%E%!;1952+0<95, T4;5:)P;'A62 MXT#\J (!2546E18GE7TQ DE#*Q6S2[8-J P6ACAM_%C1U'6"X#I.#U065E8] M7FH5$<#:2(NU8AQ5+1Y5E-5?E4BNN0EOH$RWE&2"?=EBZ;%GVV/%U*RV*%7 )-WG559O3GEB7UHRU)PQ/ MAR0U96U.&3R6C[5M!5E9IC,2L#U@45::=?/NO'7O!8.2]"EGEBDD^-)#(AD! MJT^DDM/DB !GO3S,KL_K7BR2=IQ2YX79=)!DX7NPR1^(7:(%5"U:VX>ME5S5 M'38NBW73\G7&4MS[R/*RY1&GY7DI4JD8S4M>Z;RFEGJ%:AUG;V,T 6M%.+,6 MHV7Z/EI&QG)XG/%:TH:OQ9L 6_I)KT!@'00&5H5@;$%J,!#]LVSE/\W6NKOW MNKO3UN>%H%E;R,LQDFVQN]*6&&:8C;DN3R$6G#AH$,(;5N5:N9MD,B?!;83P MUI:[;W6YP^Z7>VV(N>\'&L;BJK]L6,W77MEH"A?#]=L]7(/%; ?:ZJ,6E^E6 MA84>;BX>M40JO/)66 9/E5R$%)[+M.FYBU2C&[WYN9>4\Y9T.;H$QO3&\\9N M/Y@278MN= B]#6/%&,-[[FI9E&X(!*JW&=F:V]^R3QZ9 M" "245UJ6W?)CTYP\U^""P7/P2S8&D[?$5P]PWF*X3T$9N]ZNP3W9_T7Q M_E]#F?6UO6!?2)DHN74Q91 6^&5X6);DEZ=E^1*BIY7"YGYYKT-6P@M[M598 M@UNV?[%U$:\CW :S9?-O'JO6[5]QV1^;[S9UB"\$QI?!#118%"?"J;>$V?/R M@:7!&RX-%A&58&RL5V3*!FQ/6+/[$=V15U07QX-E4368(Z:-%9(KF Q61YIQ M5]0/-X1EPY"4&@=)"9)*V%B@@T%A#D035O=^PIAO4:?Y"EJ;[Z!5H!UC?)S^ M6V^98?VO!)&&E;GK;T.GU>T<7ES,EF%2WE=N,@7,;P([T]L< #& M0^*W^9GIQ=]"N*ML'7P'-[[_5TG&!V^W:#$]MWL-1WWQ6CS>ML4TF2$,%\?% M7E$)1QP6=O&@IUFG-GXX9EQE-<9 M=&8=1\/8<0BDFA5R4V9W3#;$9M,P;?;EV693"FZF%.IFYO'8H B+1=!Q9)8A M+'0UK6@6GO%PCUDBUIS%QZ-9-]P?4VP,,S)9 MW%D%#9]571Q>!IVM9PNR>P:?O0BX(V7F.5AQZO IQPX/=8QD2L>%/9+R<*WZ MU@TW^M9## G@@\:(B<0.U$4VH]DH5&2@5PTF3P6Q1%H:CR1-= Z06K$8IG4.^B#D<^TI M1:M3FO:]*DW8+:"6)1N1R%\CA$$X&2:;E4SU)F(KVR"R%!EJ.!H_-"7'&XT: MNN,T4+]/VYET8O0 'O"E=N9H:@TQ$.BIN7+4;V/F3\VZ7!.J5BF? :M:,_>K M(7XM(#[F[_)JVYJM]JOA:DV@VR8K4W3!FK!!G_60 QBQB!$.;A]NG?3!)F[> MFDM$!YQLU!IJ.;5:M_:\-+;_W+A6MY5K?%HKI[>U*>T:J(ST0@@L[[F6 MB$5N1(J^IH *A9<;P+9?D6V 8&-9Z29LL]9W4"5SM)$HQ/8?BLE0&I]FL3&[ M&-OB."\$;5:0J >R;2DBF\@T+Y1L'\+)EI9>; >;H#:(M&RT"$$4S,EL( K- M-EWYLSE;G[S#CDZS9M:=LB!;5U M 5(;H5>UK,K%+] TGVK+3)N4$;GP6LA8L_PWREDJXVQ)XD9*E2AI"'+N$9J*>ZR%LE>LJ!<)D<915"C M7"7;K)ER9=9O?#M_8JW<%=:Q]@:QW!TRR\V+=( MQ^SBTJ? LRA^QF79 N;6 ML3DME2)84E$AC=:\8-?A@9CBV4MB%91_764W(KYMH%*Z=F@14U/M3"LM-7;! MTNH[34MV.ZVFY&&%1YB=-@V9<-,RK65!RZS<.MH)0W*,:6?Q ;)Z[%O6 MVM6,:*MLYZ"QKNGS\6C"6(:)HV\G) =W%Q-QY__$ALB=7WL;#M0P47/7_D%W M#^*:+ FJ390@8* +!M1)D"_(W8$*WIT5HMXI>F@ >1 2>@6?PP 6(Q-"2B,(%#)X8BQL\ M> '@&S, VBD.E 8H/R6 ?%&'%P(U@+S?B'=FE7@3()^%XEF 0F&+EP&NU"2U MC$?Y48,W1)T7R?5X:70",/J]>Z9?DH?I,7E5WEL=!;Y]5AX3&/LI?PC?F1:* MA'F;Q9CW%QP,$@C%@.8E'6J>V#!6?WEP7NTDYWVO9O7FI^"$)C@K;M#GW2*? M7Z1V^+G,AA[C)U([?I!?5"WYX9>+%)1'Z:70HO5.O>FUN,.,IZ=/4'WR*JFG M-9MZ A*J%WVN>GA!6.?J7009,:7: %>E3O+(MU/O>D]"KY?R 7M5D[ 7[*D% MQ=ZQ=R*TP)[S&W?SU3(P']I, P/%99K!U^4Q?U"?[2?U]=7<7J^J4^MZ8$R& M$$4=UJ>/ IOY\7[J'L&U5I=^):2\-UHOSF-?OI<1&K[]WE[][P5\:#/EVSG@ MU4+@$&A9R]6('\0G\8'5%!^C%_F%;FHS6DNZ>7R %2X6\GG7))]B8?(%URC? MK[?R'4S'MZU?VG7YP M'Q*X]@EZ;E]3-@+%?+71B_X[LW]+\8B]]%0+!1V,3?KNMX0=@8]8&TX"] M6;/4G;5B=/'=7^0U6(NB+$4!@V.MYT76A1W4/Q.*P/UY?Z=!+CWVY0_O&O' SZ=]IY MUHU@^S?]U8&ZWT6-;(:RHB_^E+[GA4IX IJ0 XX<48336!?0!F%694 M5"VYGCY4-50X%SV!^Q*]EE7K&ENU5KWB==488+0]4A?8*E<'^/]]@$(A1J<$ MVH"FGQ-H!): >7:M:FZ#@24@$WC1?8$JH-V' Y(:.^!%T .Z@7S@ P1:AX!/ MX HH!J[;YX@,"&:3@5>@&3@%XM9I(*/M!K:!;J 72'"?&THVP!U0S=5G(,B1 M;W.;]G9_/1+ @9WDZ4,'%E/&GZV]9T3:;,X>^/]IW!GW']A24=I?%"%X!XK< MAZ"FO?PL@@6S=J&-LR=4;N#08-.8L*P&U"#UL\UB&]D@Y((EDG#O'?@(#(X#HX(Y:!I6"&D@VYA MF=L.!D'X73R8$ZJ$?B$^J#34R<9;/Z@6F@ !(1(Q$-9G!F'/6KJ>@PMA0_@0 M\C(2H4Q$$6(:%N&>(;@5;Q-<1P@=FH9C=TFX$9Z$HS>U,.^XA*%%3!B6G84W MX7.8$B*#/*'DA@+XA,8 M=5^%[$56*._(JO:.WCWGW:HB@UBH8&3=9F%-&'M[W:9A$T A@NS\+T9_C^=(0=S$)8:!:*9FN2M>>*$H)2%AU$J>4BESD!>8GJ(I5JIRF)\2",F1.JL?=@D MA(>((HC!+BR*_F'*2@$)B&Q B8@UA*F9Q:-UDE:-#N)-I#CRK4OCL5H@7HC4 M2^\JN.Y&+F(1#DE\)[&0%:XD$ZFW"')E,!8SBZEB [K2K+5,#GX1V(AP0XX( MPQD0;($>/GG\B-.5D'A<">+F9B(NC:#/-G@#Y[\.O$,->0BZ4HGK899:A*?4 M/^1(*AX-14,X29IVXXWV3Z9S)N)%S*F:Z)QBIVZBJRB3;DG%9XC],I(Q'!:> M>!PQR%--G_@I (JY!C\28A:*Q4U>L_'RAXQB*2(UTR*3F,V5B3Q MB9JB]6.=HHU_#*A8B],SH^*':"HRMYA&)CXEBCEB(_=M L2*,>-?NI %IFFA M") KN+@XU[")LNB[ B_)BC.@;V(NG M3SESB^J+$..ADVT C%LXP4@54T"33L)XZ2Z,4/?:U+MVY&^J5NJ05HP1>5X* M!6B,'"/5(32 C-/5R#B?AH!G^-:8,KH806-LX3(2.;*B.%XS.@$W(P\R-;8A M=8V'O&J5XT CD2.>6LA]XT'>BRN-$^)?TS2N0BWB%BXU>N1$5VXJ)UZ-Q7C6 MZ+:NBF:C*?Z:'C.92-S_A+FC:"BMKIS*B./^7@#=P(AM\BZ;C]I"T6 MX>-I5<[> (ZHG>!(/"[?$/6.G+G.JS%:*JB 6SB$;I<_6H+&-KF#EN-!31U-[C1EMBBGKB MHV_0?M./99DJUD1R,>SCB> ^>K8J5VOK&P0QS'G]6#MZJ0>;;O!TA]R)D_]X M$ "0>8FY,4#*O\X,(@E"3I"B>7M=FLN.'.2N!D&^YSX'!1D&R. \J(=A(I <.YC.X9^42RXU$DY9UH#X&Y5%YQ10[G38L6B?QQ MD5ZDQ!9&DLADI$9[+#\)9^1?S\BP_J\'T,QUY/]>1^C,D]<5]1-SS M&_<_ V$!]/A,Q)7/;QP"'4G/<:@T49?4-=!Z7(%6#[,R$S0@5S!;T-IUNI]_I<'I.R]*6T]:T27O9_;3$ M[CJ=V'5VB]([#=K%XO(T %M/S[[W-#$-Q[EVK$P_;0K-=D10;6Z;)^:X^0WF M!GT'PIU"37PWU,RK<@=1[QBZ>8ARQ(K%\A\(]28WXD?0UBV/O8L:H$FMCFQ. M9#?*9U3_WE :O/D%!=M!354"QN MA%0;R\*VDL14%X#&-KR0X27;9K;OG<(TV\V=:8LWCJ5-T7KLNN^%YC[7G)UF+,GZ>C+UO MV^OL=0J]^&F 93:']UG_UY/>3EWIC8&8GGS-Z:764LNG!VK'?-=P"05;5ZVI M7I&&%=767>]/8=8FV&ANV]Q@ [RVGF]=\IU\OI[*=UQCV,4UZEZPS[%V5>ZS/H=0FT[LW9 M!T&=W;'#UZ3?>_UNQ]>F=91-7_=<_M[+AU\/?(#?EHW5D>QKNX"M698]=I._;@$?W53CCW MC\WEC=5H@[Q^9(> ;[62G:\WV4OV6PUE9X0^WQ6(8BO->A_3?+IGV7F[ZOX' MILN;-\<^K]?*'_NY;F##VK=4FAW4?J]L=F3@9G=^<#8'?=^*?D0VZK>[KWYY MMOGN]O79_'J6!Z+]Z[7?[4>-E1:18![(9=="$J$)V&A3X"&W_5Y=HUQ"7[A[ M:<_N*$+M7OUQVB\[]L<8M #:7^TT:MLUWU^X'?ZAVHF+JDU,L=KK7FQN9J]_ MQ.[-C55&@DHLKEW_Z=J9(*^]__WJO[8'F%0?M 0@?3IFD]1/]> ^:RS;VSJ( M1W*#-$;@50VN3]NDX[A.;5_;=':V#;)S@&![7AV^?W"KWO@UOAX%JG\3]JS&!26"_;<6S-O5V MJLC%*]QK(,.]!CK<9CQ!_C7+??JXW((\S/T()H)P'2-H<^]?.#<(CU'31O3?=)W8[-KZ M'R!HVX(8AP"SV -Z^=L(P>->#[/?0@7BC8HKW/\AXLRV.-P((>=O>DO<. M1'E7" RA0^BE081F0.9]2[E;G;<='36?8J$WY#IZU]TD8>=P'**$.B%(R"RT MA)HK3'@&R(1FB?:=%LK> 7T_;R?TA&?93Z@(>LWB6E'H>]-$G4'PO13R[UGX MFN)L"T$+5"A?.3+?[DZLRA7.JM(WJ;#O5-^YZO5-=&??:"%XP]![W^:W+R]^ M2\OEMSIX?F?SNF$W_UL$A@<;8;@2&8:#[,!Z?QL_+,S#L7]WA69$!&X9?I+" MZ@#N)!3@GR$"[AH^Y@SX]^UPM&A._6L(8U?@1>#Z? MK8G@W3<)SI)ZHFL]"DZ0B0 K^,WZ^9=2C2U_)04![>'5X$ MBCD/#B7V->5AE=H>]N19JGN8-YHY.+B'@X37AR/2$HX?ZH=/>']X*T1L4WCK M.2!NAV,#%GYKA>1E31<.(&&;Z%I^%;ZAI^3:_V$ )6GB)J MY6IJBVB62HE6(AXN']:(9-F-Z(?OB('X8 _: (D+XY"H'!CWBGAS#X@ YX ] M]:@E]N!1XB3>ME;BZ.$E#@QIXT$X)ZXUBHF?^$KZ#J*)I?C7.)>/" YY+8[+ MNN)V8BP^W^6)M+B<>,8\B[BXH+B+PTE(HR^>* +C47AN_R@6XPCC,2YK)N-, M\3*.V#3CU"FG6-Y?I^=]J.A 5>-TZS6>-V7CUCU;_B:^BM^XFE.7MXU>3+5X MCM,!?3G-(9@/YB1C/6.L&8OS.-O*+.;C>\(^KN;@NV3:/WXL!N0(T$"N-Z(- M(_[?R(S_S.6BN]207_BLZ;KHEJ(U$WGJ59'#C&D 1I[":.2/]KX(EH/D6F/5 MJ%FJJ0%^H':2L_)$"H3CY+?D$V-?,RE#-Z]XG91!S.1P2DWN,>+D(N,T+FXS M]FYI5#[&#.46^8;_Y!SE23F?N917C3UCM>CFQQ93^7-ID$NF^;UM[XW,X;M! M5Q[E?^4M>6S;E(_EXEI9[MV?Y=A-6F[>TX5A(Y!O[)&-SOB"#XVKC7+^.-[A ME^.08HC_T?SE6VI@_N?K^.MX5&V8$XY$]VU>R7WAC7GC2!I"CFF!Y"B98]]: M8FQ6G,N76T#GJ"6"CIZYN Z:AY 4Y&A^TA^8)Y.*,[,O,.%NA=Y\S_!5D@:XZ,I ;9(+>04[\Q#Y%1Z [ M_ ;Z"8"@XVPK)%X,K>WHO0$,R3!%Z WZA/Y:1/LY)(9^%Q,NRTS/U:$7_+T! MB(Y$LC(C.AEIHF_+4.3D?1JNZ'!=B[ZA [Q=)(PN=\CH=1J-WD38Z&,RCLY$ MZNAKI#?CH[=_:B2/'J2#<,1Q',F$&>E)%?Z\!23I']&2O@4TZ=CPD^[#1>E' MV()L0#]A5KHIC:7[S*FT)NU)=^D0-(LL0>/(8WK\H)@7I&P.A(:F-U%X>N%O )^!_^B'_B'Z<# end From mea@sparta.com Sun Apr 12 11:40:56 1992 From: mea@sparta.com (Mike Anderson) Date: Sun Apr 12 11:41:04 PDT 1992 Subject: Re: comp.os.vxworks newsdigest Greetings! ----- Begin Included Message ----- From: paulg@tplrd.tpl.oz.au (Paul Gittings) Organization: Telectronics Pacing Systems Message-ID: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au> This is a beginners question and I apologize in advance if I've wasted bandwidth by asking for information which I should have been able to find in the manual (I did look, Honest). Are there any major differences in a tasks environment when it is run from the shell: -> main to when it is spawned off using "sp" ?: -> sp main We have vxWorks 5.0.2 and our target is National Instruments VXIcpu030. Cheers, Paul Gittings ----- End Included Message ----- Well, first there was a syntax error in the code: sd = socket(PF_INET,SOCK_STREAM,0); should have been sd = socket(AF_INET,SOCK_STREAM,0); but that's not what's causing your problems. The differences you're experiencing are a result of the context your main is executing in. When you run main from the shell, "main" runs as a subroutine within the shell task's context and as such uses the shell task's stack. -> main |---------------Shell Task---------------| | |----------| | |----------| | Stack | | | main | |----------| | |----------| | |----------------------------------------| But, when you use "sp", "main" becomes a separate task and uses a new stack whose size is determined by the parameters to "sp" as defined in /config/all/usrLib.c. -> sp main |---------------Shell Task---------------| |------ main task -----| | |----------| | |-------| | | Stack | | | Stack | | |----------| | |-------| | | |----------------------| |----------------------------------------| To set it up so main has the same stack size as the shell task, either use taskSpawn and explicitly fill in the stack size or modify the stack size parameter in usrLib.c when sp calls taskSpawn to actually spawn the task. Remember that "sp" is really just a front end for taskSpawn that fills some of the pieces for you. You can check the current stack parameters for a given task using checkStack. Also, anytime you use NFS in any of your tasks, be sure to have at least a 7K stack and preferably more like 10K if you expect your code to avoid stack crashes. Good luck, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From iphasew!hwajin@apple.com Mon Apr 13 12:29:30 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Mon Apr 13 12:29:37 PDT 1992 Subject: Re: Differences between shell and sp task starts?? >Well, first there was a syntax error in the code: > >sd = socket(PF_INET,SOCK_STREAM,0); > >should have been > >sd = socket(AF_INET,SOCK_STREAM,0); PF_INET == AF_INET. This isn't syntax error, it is now a preferred way to specify protocol families. [ there is a reason for this. ] From the original program, > ns = accept(sd, &cnnSocket, &fromlen); Notice that fromlen is never initialized to any value. The last argument to accept() is a value/result. You should set it to something like "sizeof (struct sockaddr_in)". [ there is a reason for this. ] *hwajin From iphasew!hwajin@apple.com Mon Apr 13 12:30:22 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Mon Apr 13 12:30:35 PDT 1992 Subject: Re: Request Basic VxWorks Info >> 3) What is the default size for a UDP socket (what is the maximum >> length that can be used in sendto(), without first using setsockopt())? >> Is this configurable by the user? > >4400 bytes, if I remember well. It was some time ago that I've handled that. >Didnt look for a configuration parameter to change this. Used setsockopt >on the socket before that socket was passed to RPC. Global variables (not changed from 4.3 Tahoe network code): udp_sendspace = 2048 udp_recvspace = 4 * (1024 + sizeof (struct sockaddr_in)); These are adjustable via setsockopt() SO_SNDBUF and SO_RCVBUF on per socket basis. >> >> 4) If the answer to 3 is < 8Kbytes, does VxWorks' implementation >> of RPC use setsockopt() to allow 8Kbyte UDP transmissions? > >No. I think I reported this to WRS, so maybe your version already will >include a fix to this. >NFS client code however has it's own RPC library, which apparently works >just great with 8KB buffers. > NFS code uses setsockopt() to allow 8 K byte UDP transmissions over RPC. NFS uses the same RPC library as everyone else. Other RPC applications would control socket buffer size themselves -- this is the standard method -- SunOS RPC library does the same. From daemon@vxw.ee.lbl.gov Wed Apr 15 04:00:31 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 15 04:00:39 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 15 04:00:24 PDT 1992 Subject: Heurikon for sale Subject: Re: rlogin to a target clobbers remote user name Subject: Re: heurikon for sale ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Heurikon for sale Date: 13 Apr 92 20:13:25 GMT From: fester@etorofu.island.COM Organization: Island Graphics, Marin County, California Message-ID: <1992Apr13.201325.4749@island.COM> Sender: usenet@island.COM (The Usenet mail target) $1200 OBO Mike Fester day (415) 491-1000 x190 evening (415) 750-9220 or email me at fester@island.com - -- Disclaimer - These opiini^H^H damn! ^H^H ^Q ^[ .... :w :q :wq :wq! ^d X ^? exit X Q ^C ^? :quitbye CtrlAltDel ~~q :~q logout save/quit :!QUIT ^[zz ^[ZZZZZZ ^H man vi ^@ ^L ^[c ^# ^E ^X ^I ^T ? help helpquit ^D ^d man help ^C ^c help exit ?Quit ?q CtrlShftDel "Hey, what does this button d..." --------------------------- Newsgroups: comp.os.vxworks Subject: Re: rlogin to a target clobbers remote user name Date: 15 Apr 92 06:34:34 GMT From: pat@wrs.com (Patrick Boylan) Organization: Wind River Systems, Inc. Message-ID: References: Sender: usenet@wrs.com (News Manager) hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: >Has anyone else observed this? >After a completed rlogin session to a vxWorks target, whoami on that >target's console returns a null string. This happens even if I did >nothing but rlogin and logout. As Hwajin mentioned this problem surfaced when login security was introduced for 5.0. The original user and password before a secure login is restored from originalUser and originalPasswd. These were not stored. The problem has been fixed for the next release and the patch for 5.0 and 5.0.2 is as follows: - -> remCurIdGet (&originalUser, &originalPasswd); Patrick - -- Patrick Boylan, Consulting Engineer, FAE Asia/Pacific Wind River Systems 1010 Atlantic Ave. Alameda, CA 94501 pat@wrs.com (510)748-4100 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: heurikon for sale Date: 15 Apr 92 01:23:32 GMT From: lampman@moose.heurikon.com (Ray Lampman) Organization: Heurikon Corporation, Madison, WI Message-ID: <1423@heurikon.heurikon.com> References: <1992Apr10.173505.3673@island.COM> Followup-To: comp.os.vxworks Reply-To: Ray.Lampman@Heurikon.Com (Ray Lampman) Sender: news@heurikon.heurikon.com In article <1992Apr10.173505.3673@island.COM> fester@etorofu.island.COM writes: # # Heurikon HK68 and MLZ-91/21 Microcomputer. Includes all manuals and # documentation. Still in the box. # # $1200 OBO # # Mike Fester day (415) 491-1000 x190 # evening (415) 750-9220 # # or email me at fester@island.com I wasn't aware that the MLZ-91 has had VxWorks ported to it. Can Heurikon get a copy? :-) Maybe this article would be more appropriate in one of the "forsale" groups. Here's a list: comp.forsale.computers misc.computers.forsale misc.forsale misc.forsale.computers Ray.Lampman VxWorks Coordinator Heurikon Corporation - -- Ray.Lampman@Heurikon.Com ,^-_ "I say, what it occurs to me to 8310 Excelsior Drive L `; say, when I think I hear people Madison, WI 53717, USA \ . J say things, more I can not say" +1 608 828 3431 L__] - the man in the shack, D Adams --------------------------- End of New-News digest ********************** From jbg.MAILSERVER@wrsec.fr Wed Apr 15 08:22:09 1992 From: jbg Date: Wed Apr 15 08:22:16 PDT 1992 Subject: OSI/MMS Feedback required Subject: Time:16:40 OFFICE MEMO OSI/MMS Feedback required Date:15/04/92 As you might know, MARBEN is a french company developping OSI related products. MARBEN did port part of their OSI software to VxWorks. 1-WHAT HAS BEEN DONE: Today MARBEN/OSI protocol stack runs a VxWorks 68k based target up to the transport layer (TP4 interface). The Data Link level which has been tested is 802.3 (ethernet). They tested it actually over on board ethernet link available on a typical VME single board computer. They also did some evaluation on porting MMS client on VxWorks. WARNING: These ports must not be considered as off the shelf products. 2-MMS (Manufacturing Message Specification): To be simple and quick MMS is a standard protocol standardized by OSI. The aim of MMS is to inter-connect any kind of factory equipments (e.g: robots, PLCs, numeric machine tools ...) and to have them communicate easily and efficiently. The biggest part of MMS is the server side. MMS server services are subdivided into several classes such as Communication,Equipment, Tasks, Domains, Variables, Semaphores, Events and so forth. As some equipments and applications don't have to support all MMS services, big customers or OEMs have defined MMS Profiles. A MMS profile is actually a subset of available MMS services. As an example the EDF Profile seems to be a reference in France. A MMS server software package can't be fully developped hardware independent. That means MARBEN would provide a MMS server environment package that allows customers to interface with their specific hardware equipments. 3-FEEDBACK NEEDED: In order for MARBEN to port MMS server (or at least part of it) MARBEN and WRS need to know whether or not it makes sense. Is there a real market and how big is it? What MMS services are required? Does it make sense to productize something? Idea of Pricing eventually? Whenever you have a request regarding OSI and MMS feel free to let us know. Although there is no real product for time being MARBEN is able to provide high level consulting services around potential OSI/MMS implementation with VxWorks. We need inputs from anyone and especially from the field (WRS ,OEMs and Partners Sales and FAEs for instance). Send comments and inputs to me and thanks in advance for your contribution. Jerome BRING Wind River Systems Europe e-mail: jerome@wrsec.fr From jbg.MAILSERVER@wrsec.fr Wed Apr 15 10:02:47 1992 From: jbg Date: Wed Apr 15 10:02:54 PDT 1992 Subject: Defining Embedded Systems Subject: Time:18:42 OFFICE MEMO Defining Embedded Systems Date:15/04/92 Hi everybody, As we talk more and more about embedded/real-time systems I think it is good to propose a sort of definition. So please find below some caracteristics of embedded systems I have been collecting. Feel free to comment and/or add anything to it. * The difference between an embedded system and a free standing computer largely depends on how users perceive their interaction with it. If users believe they are working with a computer, it's a computer. If users see themselves as interacting with something else (a fax machine, an airplane or a printer for instance), it's an embedded system. * Embedded systems are part of a larger system whose main purpose is not computing. There is a strong interaction with the rest of the system which normally means direct physical and electrical connection. * Embedded systems have absolute performance requirements. The system must satisfy all requirements in absolute terms: if the requirements are not satisfied, the system will not work. The most critical requirements are generally specified in terms of time or temporal reactions, so, the terms "real-time" and "embedded" are very closely related. * Embedded systems have a specific purpose. Although most embedded systems are a combination of hardware and software which allows a certain flexibility, the purpose of the embedded system does not change during its lifetime. One consequence is that operators do not generally load or change the software, this being regarded as a maintenance operation. Thanks in advance. Bye Jerome BRING jerome@wrsec.fr From dit@bach.jhuapl.edu Wed Apr 15 11:31:44 1992 From: dit@bach.jhuapl.edu (Daryl I. Tewell) Date: Wed Apr 15 11:31:51 PDT 1992 Dear Sirs: Please change my "Exploder" subscription address from dit@melchor.jhuapl.edu to dit@bach.jhuapl.edu. Thank You, Daryl Tewell From @ada3.ca.boeing.com:crispen@efftoo.boeing.com Wed Apr 15 11:39:27 1992 From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> Date: Wed Apr 15 11:39:35 PDT 1992 Subject: Re: Defining Embedded Systems Jerome Bring writes: >* The difference between an embedded system and a free standing computer >largely depends on how users perceive their interaction with it. Well, yes, but who's a user? I'll offer two counter definitions. (1) Embedded systems are something that embedded systems kinds of people do. In the flight simulation business, there are people who need to be concerned with exactly the same kinds of things that concern people who design black boxes, controllers, and so on. They need to know about interrupts, hard time deadlines, scheduling, resource locking, device control, and so on. To the guy who's gotta know that stuff, a flight simulator is an embedded system. To the other engineers a flight simulator *shouldn't* be an embedded system. (2) Embedded systems are systems that are actually embedded in something. The Air Force a while back defined "Embedded Training" as something that was "built into or added onto" a system (aircraft, etc.) that provided training capability. For example, an embedded training system in a submarine would let the sonarman turn a switch and his radar would start showing bad guys. By definition (2) an embedded system probably ought to be "built into or [designed to be] added onto" something. I *love* religious discussions like this, and it really just depends on where you start drawing your boundaries. I prefer to start at the extremes (to find out if they really are extremes) rather than at the middle. Best to you, Bob Crispen crispen@foxy.boeing.com From daemon@vxw.ee.lbl.gov Thu Apr 16 04:00:27 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 16 04:00:34 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 16 04:00:19 PDT 1992 Subject: Stethoscope Subject: Re: Defining Embedded Systems ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Stethoscope Date: 15 Apr 92 19:19:28 GMT From: mkb@frc.ri.cmu.edu (Mike Blackwell) Organization: Field Robotics Center, CMU Message-ID: <1992Apr15.191928.126541@cs.cmu.edu> Reply-To: mkb@cs.cmu.edu Could someone please send me a contact (email or phone) for the Stethoscope product? I think it will perfectly solve a problem I'm having. Thanks... -mike- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Defining Embedded Systems Date: 15 Apr 92 22:31:47 GMT From: rlk@VisiCom.COM (Bob Kitzberger) Organization: VisiCom Laboratories, Inc., San Diego, California Message-ID: <173@visicom.com> References: <9204151839.AA23989@vxw.ee.lbl.gov> Sender: news@VisiCom.COM Bob Crispen writes: >In the flight simulation business, there are people who need to be concerned >with exactly the same kinds of things that concern people who design black >boxes, controllers, and so on. They need to know about interrupts, hard time >deadlines, scheduling, resource locking, device control, and so on. These aspects make flight simulators real-time systems, not necessarily embedded systems. A flight simulator can also be considered an embedded system, the characteristics that determine this being that the computer(s) is embedded inside of controls, gauges, and other sundry devices not normally part of a general purpose computer. There are real-time systems, and there are embedded systems, and then there are real-time embedded systems. 'Real-time' and 'embedded' are often used interchangeably, but to me they are quite distinct, the former implying a set of temporal requirements, and the latter implying a set of hardware/sensor interaction requirements. I don't know how often I've seen something advertised as being a real-time tool, when really it's just an embedded systems tool. >(2) Embedded systems are systems that are actually embedded in something. This I like better. >I *love* religious discussions like this, and it really just depends on >where you start drawing your boundaries. I prefer to start at the extremes >(to find out if they really are extremes) rather than at the middle. Good point. Can anyone think of a system that directly interacts with sensors, gauges, or other non-general-purpose hardware that we would NOT consider to be an embedded system? There may be a kernal of a definition here... (no pun intended) unless of course one of Bob Crispen's extreme's blows this out of the water ;-) .Bob. - ---------------- Bob Kitzberger VisiCom Laboratories, Inc. rlk@visicom.com 10052 Mesa Ridge Court, San Diego CA 92121 USA +1 619 457 2111 FAX +1 619 457 0888 --------------------------- End of New-News digest ********************** From honce@rhine.stx.com Thu Apr 16 04:16:58 1992 From: Jhon Honce Date: Thu Apr 16 04:17:07 PDT 1992 Subject: BEEP! Re: comp.os.vxworks newsdigest This is an automatic reply. Feel free to send additional mail, as only this one notice will be generated. I'm at the IMS retreat for the week of 4/13/1992 to 4/17/1992. /jwh jhon honce -- honce@spso.gsfc.nasa.gov -- honce@rhine.stx.com From hebo@mbari.org Thu Apr 16 08:49:51 1992 From: Bob Herlien Date: Thu Apr 16 08:49:58 PDT 1992 Subject: Re: Embedded Systems > From: rlk@VisiCom.COM (Bob Kitzberger) > > Good point. Can anyone think of a system that directly interacts with > sensors, gauges, or other non-general-purpose hardware that we would NOT > consider to be an embedded system? There may be a kernal of a definition > here... (no pun intended) unless of course one of Bob Crispen's extreme's > blows this out of the water ;-) > > .Bob. > In the early '70s (around '70-'72) I did some work on the original PLATO system at the University of Illinois. PLATO was one of the early computer- aided-instruction machines. At the time, it was being migrated from a CDC 1600 to a CDC 6600 (both general-purpose, although now ancient, machines). I was working with (taking a special projects class in) the EE department. We had a "typical" EE lab setup: oscilloscope, function generator, oscillator, etc., all wired through sensors & guages so that the students' configuration could be sensed by the main CPU. We wrote CAI software to "teach" EE lab. This software ran in a typical (for the day) timesharing type environment. This was not an embedded system -- we had no embedded CPU's (this was before the age of micros. Oops, my age is showing :-). ----------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@hp850.mbari.org From harvey@yuba.wrs.com Thu Apr 16 11:57:37 1992 From: harvey@yuba.wrs.com (Harvey Wong) Date: Thu Apr 16 11:57:44 PDT 1992 Subject: Stethescope Dear VxWorks Users, Wind River Systems is now a distributor for Real-Time Innovation's Stethoscope product. WRS will be shipping and supporting this unique data collection and graphical monitoring tool by the end of April. Stethoscope allows developers to choose any program variable and watch them change in real-time. This data can also be saved for later analysis. Stethoscope also includes a dynamic execution profiler which enables developers to analyze the execution flow of their aplication and how the CPU is being used. Please feel free to call WRS directly at 510/748-4100 for more information. Sincerely, Harvey Wong Wind River Systems, Inc. From daemon@vxw.ee.lbl.gov Fri Apr 17 04:00:44 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 17 04:00:53 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 17 04:00:36 PDT 1992 Subject: Stethoscope found Subject: UNIX compatible rsh for VxWorks? Subject: tar/rmt ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Stethoscope found Date: Thu, 16 Apr 92 14:09:44 GMT From: mkb@frc.ri.cmu.edu (Mike Blackwell) Organization: Field Robotics Center, CMU Message-ID: <1992Apr16.140944.69631@cs.cmu.edu> Reply-To: mkb@frc.ri.cmu.edu I now have the contacts for Stethoscope. Sheesh, I must be the only person in the world who didn't know... cheers, -m- --------------------------- Newsgroups: comp.os.vxworks Subject: UNIX compatible rsh for VxWorks? Date: Thu, 16 Apr 1992 16:25:32 GMT From: jsnow@javelin.sim.es.com (John Snow) Organization: Evans & Sutherland Computer Corporation Keywords: rsh vxworks Message-ID: <1992Apr16.162532.7341@javelin.sim.es.com> Now that we have a UNIX compatible rsh deamon for VxWorks that allows UNIX boxes to rsh to a VxWorks node, does anyone have a UNIX compatible rsh command that will run under VxWorks? We would like to be able to rsh from VxWorks back to UNIX or from VxWorks to VxWorks. Doesn't seem like it would be to difficult to write rsh for VxWorks since VxWorks already supports rcmd. But, not being one to reinvent the wheel, I was wondering if someone has already done it. Please, no responses about VxRsh - it's not UNIX compatible. - -- - ----------------------------------------------------------------------------- John F. Snow INET: jsnow@javelin.sim.es.com Evans & Sutherland Computer Corp. Salt Lake City, Utah America Online: JohnSnow GEnie: J.SNOW2 --------------------------- Newsgroups: comp.os.vxworks Subject: tar/rmt Date: 16 Apr 92 19:38:16 GMT From: singer@ll.mit.edu (Matthew R. Singer) Organization: MIT Lincoln Laboratory Message-ID: <1992Apr16.193816.18979@ll.mit.edu> Reply-To: singer@ll.mit.edu (Matthew R. Singer) Sender: singer@ll.mit.edu (Matthew R. Singer) - -- Before I go off and reinvent the wheel, does anyone have a hacked version of one of the PD tar clones running under vxWorks? I'd sure like to tar off files on local disks to a tape drive on my Sun. Of course this would all go away if there was just server side NFS... Thanks for you time and bandwidth... - --------------------------------------------------------------------------- Matthew R. Singer MIT Lincoln Laboratory (617) 981-3771 244 Wood Street singer@ll.mit.edu Lexington, MA 02173 - ----------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sat Apr 18 04:00:25 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 18 04:00:32 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 18 04:00:18 PDT 1992 Subject: accepted method of ld'ing many .o files Subject: setting up SCSI w/ vxWorks 5.0 Subject: Re: tar/rmt Subject: Re: Differences between shell and sp task starts?? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: accepted method of ld'ing many .o files Date: Fri, 17 Apr 1992 13:14:13 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: Sender: news@nic.unh.edu (USENET News System) Now that I'm getting moving beyond one or two object file test programs into a big project, I'm curious how people handle the need to load large numbers of object files. I was thinking about having some C code generated through shell scripts and the makefile that would automatically produce some code like this: char *app-name[] = { "/path/objfile1.o", "/path/objfile2.o", "/path/objfile3.o", "/path/objfile4.o", "/path/objfileN.o", 0 }; boot(app, variable args) { foreach string in app, do a ld then invoke the first one with the variable args. } Am I missing something easier? - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: setting up SCSI w/ vxWorks 5.0 Date: 17 Apr 92 13:50:14 GMT From: kwaldman@bbn.com Organization: bbn Message-ID: I am trying to setup a scsi disk on two different vme systems running VxWorks. The system consists of a MV167 motorola board (68040) and and 4 SkyBolt AP's (i860's), a harddisk connected using the scsi port on the 712M transition module which connects to the MV167 via the P2 adapter board. The boot files reside on a Sun Sparcstation. Both systems are using the same file. I have done this in the past, the only difference is I added the #define INCLUDE_SCSI to the target config.h file. Both setups identical. The first fails right after it loads the kernel with Starting at 0x100... The second one boots fine! The difference is the type of vme chassis the first one uses a Force Target 32 chassis and the second uses a ruggedized chassis by Cyberchron, I have no reason to think either chassis is faulty. The main problem I have is how do I set up the scsi? I do have the VxWorks Technical Notes "Using SCSI devices with VxWorks 5.x" I have run out of ideas, any suggestions? Thanks in advance Karl Please reply to kwaldman@bbn.com if you can. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: tar/rmt Date: 17 Apr 92 17:24:36 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems, Inc. Message-ID: References: <1992Apr16.193816.18979@ll.mit.edu> Sender: usenet@wrs.com (News Manager) You could ftp from the sun to the vxWorks system and get the files that way. - -- James Moore | james@wrs.com Wind River Systems | Alameda, California "Half of what he said meant something else, and the other half meant nothing at all" --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Differences between shell and sp task starts?? Date: 17 Apr 92 17:17:14 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems, Inc. Message-ID: References: <1992Apr10.165244.20964@tpl68k0.tplrd.tpl.oz.au> Sender: usenet@wrs.com (News Manager) paulg@tplrd.tpl.oz.au (Paul Gittings) writes: >Are there any major differences in a tasks environment when it is run >from the shell: > -> main >to when it is spawned off using "sp" ?: > -> sp main 99 times out of a hundred, when something exhibits different behaviour under the shell and as it's own task, it's a problem with the stack. Run checkStack() and make sure you're not using any uninitialized variables. The hundredth time, it's a priority problem. - -- James Moore | james@wrs.com Wind River Systems | Alameda, California "Half of what he said meant something else, and the other half meant nothing at all" --------------------------- End of New-News digest ********************** From dave@yuba.wrs.com Mon Apr 20 23:26:31 1992 From: dave@yuba.wrs.com (David N. Wilner) Date: Mon Apr 20 23:26:38 PDT 1992 Subject: bit-fields, volatile, ANSI-C Folks, This is a response to the discussion last week about bit-fields, "volatile", ansi C, etc. I didn't see all of the discussion because it went to the exploder and I had dropped off the exploder because I thought the exploder and comp.os.vxworks were interconnected. But I guess not because the discussion didn't show up on the newsgroup. Anyway, the issue is a confusing one, but we *have* sorted it out fairly thoroughly. Fred Roeber brought it to our attention about a year ago and we dealt with it then. I wrote an excruciatingly detailed account of the problem that I still have if anyone wants it, but I'll try to summarize the results here. The basic question is about the atomicity of modifying bit-fields. The basic answer is you can't assume the atomicity of modifying bit-fields. It turns out that, as Fred discovered, you can get away with it in some cases on the 68k, but some compilers with some options may generate non-atomic bit-field code. And, as was pointed out by someone else, on most RISC processors bit-fields operations are never atomic. Someone wrote that "in a number of places, VxWorks is coded around the concept that bit manipulation operations are safe" (meaning atomic with respect to interrupts). Well, in actuality there was only one module in the kernel that made this assumption. This was in tyLib in which we kept a word of software status bits indicating the state of the serial line. It turns out that this worked in our 68k distribution because we didn't use "-fvolatile" which as Fred pointed out causes gcc to generate non-atomic bit-field code. (We have also carefully verified that tyLib does not need to be compiled with "-fvolatile".) However, it was clear that it would be a problem for our RISC ports. The fix was quite simple: we changed all the bit-field flags to byte-wide flags, the setting of which are atomic. This is the way tyLib is currently distributed in all our RISC ports, and will be in all ports in future releases. As a side note, you should be careful using "-fvolatile". This flag says "treat all pointers as volatile". This is a very big club to hammer the code with. It doesn't say "treat the things pointed to by all pointers as volatile". It's even stronger than that, since it says the pointer itself might change. This is the crudest thing you can do to force just about everything referenced indirectly to be treated as "volatile", and is clearly a sledge-hammer fix until the code has been "ansi-fied" to use the "volatile" construct correctly. So this leads to the other part of the discussion: the use of ANSI C. Yes, we too are big believers in ANSI C. We've just completed a big effort to ansi-fy most of our code. It's been a big job. We're still working on removing all the warning messages. But we're committed to it, because we too believe that we will have "safer" code once it's all ansi and warning free. The biggest obstacles for us in going to ANSI C is that we had to wait until all the other tools we have to work with supported it. We compile VxWorks with lots of different compilers and until they all supported full ANSI C, we were pretty stuck. The fact that SunOS compilers haven't supported ANSI C until recently has been a big deterrent to use of ANSI C in the Unix world. The support of ANSI C was a big plus of switching to the GNU compiler for 68k cross-development. However, we are still compelled to use native compilers for some of the RISC ports. Sigh. ---- David Wilner V.P. of Engineering Wind River Systems dave@wrs.com From daemon@vxw.ee.lbl.gov Tue Apr 21 04:00:27 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 21 04:00:34 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 21 04:00:21 PDT 1992 Subject: VxWorks with gcc 1.39/2.1 Subject: windEx Local Clients Subject: Re: accepted method of ld'ing many .o files ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks with gcc 1.39/2.1 Date: Mon, 20 Apr 1992 20:23:56 GMT From: ameres@sol.ral.rpi.edu (Eric Ameres) Organization: Rensselaer Polytechnic Institute, Troy NY Message-ID: <2x-vs!q@rpi.edu> I have taken over as Software Engineer at the center for robotics and am in the process of making sure all of our software is up to date. To make a long story short it isn't. We have been using VxWorks 5.0.1 with gcc 1.39 and cc (SunOS 4.1.1) for quite a while (Sun hosts, 680X0 targets) and I have encountered a strange superstition amongst the other staff members and students. Is it possible to use gcc (1.39 or better) to cross compile VxWorks kernels (i.e. compile on a Sun 4 for a 680X0) ? We have been keeping one Sun 3 around just to compile kernels. If anyone has done this could they send me the makefile (I am updating gcc 1.39 to 2.1)? I have seen some info on the GNU toolkit and am waiting on a return call from WRS. Any comments from users? Is it necessary? Does it come with GCC 2.1? Can I make the modifications myself and save the $$$? Mail responses to ameres@ral.rpi.edu Thanks in advance - -- Eric Ameres ameres@ral.rpi.edu Center for Intelligent Robotic Systems for Space Exploration Rensselaer Polytechnic Institute - CII 8313, Troy, NY 12180-3590 --------------------------- Newsgroups: comp.os.vxworks Subject: windEx Local Clients Date: 20 Apr 92 21:13:51 GMT From: vapspcx@prism.gatech.EDU (S. Keith Graham) Organization: BARCO Chromatics Message-ID: <55176@hydra.gatech.EDU> We are trying to figure out if there is a backdoor for local Xwindows clients that doesn't go through the socket handler? Since VxWorks doesn't appear to support AF_UNIX, we were wondering if it supports some other connection path other than using an internet socket with "localhost". Keith Graham vapspcx@cad.gatech.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: accepted method of ld'ing many .o files Date: 21 Apr 92 01:03:01 GMT From: litwin@litwin.jpl.nasa.gov (Todd Litwin) Organization: Jet Propulsion Laboratory Message-ID: <1992Apr21.010301.4244@elroy.jpl.nasa.gov> References: Sender: news@elroy.jpl.nasa.gov (Usenet) In article rg@msel.unh.edu (Roger Gonzalez) writes: > >Now that I'm getting moving beyond one or two object file test programs into a >big project, I'm curious how people handle the need to load large numbers of >object files. We use the Unix ld command. When I create a Unix program, I usually use cc to invoke ld by doing something like: cc -o progname prog1.o prog2.o prog3.o ... To build the corresponding file for VxWorks, I do: ld -r -o progname prog1.o prog2.o prog3.o ... Note the the "-r" is necessary to keep the output in relocatable object format. You can combine any number of object files in this way into a single file for downloading. Not only is downloading time greatly decreased, but you no longer need to worry about the order of downloading the modules. In fact, this method is the only way to deal with two different object files that make references to functions in each other. Hope this helps. - -- Todd Litwin Jet Propulsion Laboratory (818) 354-5028 litwin@robotics.jpl.nasa.gov --------------------------- End of New-News digest ********************** From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net Tue Apr 21 06:17:35 1992 From: "Roeber" Date: Tue Apr 21 06:17:43 PDT 1992 Subject: Re: cc vs gcc Eric, We are using gcc on a SUN4 to cross compile VxWorks for 680X0. Everything works fine. You need gas and gld too though. We had been using a copy of version 1.39 we got on our own with no problems. When we got VxWorks 5.0.2 though it came with a full set of GNU tools to use. Its whats called the stable version (1.37) vs the developer version. We switched to it just to avoid any potential problems. The makefiles come with 5.0.2. You also get full source for the tools from WRS in case you want to change/fix them. Good luck. Fred From biocca@bevsun.bev.lbl.gov Tue Apr 21 09:08:34 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Tue Apr 21 09:08:42 PDT 1992 Subject: Exploder - Newsgroup connection It is nice to see comments from WRS on the newsgroup/exploder. I would like to address the problem Dave mentioned: > Submitted-by dave@yuba.wrs.com Mon Apr 20 23:26:31 1992 (David N. Wilner) > This is a response to the discussion last week about bit-fields, > "volatile", ansi C, etc. I didn't see all of the discussion because it > went to the exploder and I had dropped off the exploder because I thought > the exploder and comp.os.vxworks were interconnected. But I guess not > because the discussion didn't show up on the newsgroup... I did some searching and could not find any articles relating to this topic that had not been posted to comp.os.vxworks in the past week or so. It does appear that some articles were not posted a bit earlier, but the verbose logs that would indicate why don't last this long. I did find one article 'stuck' in the posting process -- a request for a change in address or some such -- something that should never have been sent to the exploder in the first place. I did find that a number of articles on this topic had been labeled with a different subject. My hypothesis as to why these articles were not posted is that the news system rejected them due to too many lines of quoted text. Please remember to edit quotations down - lines added must comprise 50% or so of the total message to make it through the posting.filter! Please use the addresses at the bottom of the exploder messages for subscription changes! The news system will reject articles for a number of reasons. The only one I've seen with any frequency is a lack of subject. At the current time when an article fails to post it will retry until it becomes too old and is deleted. I'll setup a cron job that will let me know when an article is stuck, but it doesn't happen very often. Make sure you put subject lines on all submissions! Thanks again Dave, for the comments! Alan K Biocca Exploder Maintainer From visicom!VisiCom.COM!trest@nosc.mil Tue Apr 21 13:15:18 1992 From: Mike Trest Date: Tue Apr 21 13:15:25 PDT 1992 Subject: Re: comp.os.vxworks newsdigest > rg@msel.unh.edu (Roger Gonzalez) > >Now that I'm getting moving beyond one or two object file test programs into a >big project, I'm curious how people handle the need to load large numbers of >object files. Roger: We use gnu with the following makefile snippets: AR = ar68k cq LD = ld68k -r -d -X RANLIB = ranlib68k OBJS = \ ActionHook.o Alloc.o ArgList.o Callback.o \ ClickTime.o Composite.o ..... all:: libXt.a Xt.o Xt.o: $(OBJS) $(RM) $@ $(LD) -o Xt.o $(OBJS) libXt.a: $(OBJS) $(RM) $@ $(AR) $@ $(OBJS) $(RANLIB) $@ The first "Xt.o:" produces a single ".o" file from all of the ".o" files in the list defined by $(OBJS). The second "libXt.a:" produces a linkable library from which the user's link activity may selectively include only the modules which are needed in the specific X application. My point is that you can "Have It Your Way" and use GNU under VxWorks to provide either (1) individual named ".o" files in your makefile, (2) a large incrementally linked agregate ".o" file, or (3) a collection of ".o" within the library structure. For X and Motif clients we find that all three are used depending on the application requirements. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From kozubal@luke.atdiv.lanl.gov Tue Apr 21 13:41:47 1992 From: kozubal@luke.atdiv.lanl.gov (Andy Kozubal) Date: Tue Apr 21 13:41:55 PDT 1992 Subject: VxWork Users Group Meeting My compliments and thanks to Steve King for chairing the recent Users Group meeting. The program ran very well, and I thought it was well worth attending. Also, thanks to the WRS people who worked so hard on the logistics and made some fine presentations. Finally, thanks to all the users who made the customer presentations. ------------------------------------------------------------------ Andy Kozubal | Mail Stop H820 Phone: (505) 667-6508 | Los Alamos National Laboratory E-mail: kozubal@ATDiv.lanl.gov | Los Alamos, New Mexico 87545 ------------------------------------------------------------------ From daemon@vxw.ee.lbl.gov Wed Apr 22 04:00:28 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 22 04:00:35 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 22 04:00:22 PDT 1992 Subject: mathLib Subject: Re: mathLib ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: mathLib Date: 21 Apr 92 15:53:03 GMT From: hayes@ddemo3.aero.org (Brian Hayes 74-35 x65129) Organization: Hughes Aircraft Company; El Segundo, CA Message-ID: <21325@hacgate.UUCP> References: <1992Apr21.010301.4244@elroy.jpl.nasa.gov> Followup-To: hayes@hac2arpa Sender: news@hacgate.UUCP We recently encountered this problem: Undefined symbol _mathInit. One of our programmers used the mathInit function in his code. But, why do we get this error? According to the documentation, the linker is suppose to load the math library. Using 5.0.1 (Sun) with GNU Toolkit 1.37.1. Crosscompiling to TI 147 platform. Thanks. - -- <<<<<<<<<< Brian Hayes hayes%bh_ddemo3@hac2arpa (310) 616-5129 >>>>>>>>>>>> --------------------------- Newsgroups: comp.os.vxworks Subject: Re: mathLib Date: 22 Apr 92 00:38:33 GMT From: kent@wrs.com (Kent Long) Organization: Wind River Systems, Inc. Alameda, CA Message-ID: <1992Apr22.003833.363@wrs.com> References: <21325@hacgate.UUCP> Sender: usenet@wrs.com (News Manager) Hi, Folks - In article <21325@hacgate.UUCP> hayes@ddemo3.aero.org (Brian Hayes) writes: > >We recently encountered this problem: > > Undefined symbol _mathInit. > >One of our programmers used the mathInit function in his code. But, >why do we get this error? According to the documentation, the linker >is suppose to load the math library. > >Using 5.0.1 (Sun) with GNU Toolkit 1.37.1. Crosscompiling to TI 147 >platform. The problem here is that the hardcopy documentation is not quite up-to-date with the latest releases. The mathInit() function Brian mentions was used in VxWorks 5.0 and earlier releases to include and initialize the interface library which supports the 68881/68882 math coprocessor. When we changed from using the Sun native compiler for the 68k to the Gnu tools (beginning with VxWorks 5.0.1), it was necessary to include floating point emulation routines in addition to this hardware library. To avoid confusion, the old "mathLib" was renamed to "mathHardLib," and the emulation library was named "mathSoftLib." As a result, the mathInit() function was renamed to mathHardInit(). However, it is usually not necessary to call this routine from your application code. If you are using the standard VxWorks configuration file, configAll.h, you simply define INCLUDE_MC68881 if the hardware you are using has a math coprocessor (68881 or 68882). The mathHardInit() function will then be called automatically when the system is initialized (in usrConfig.c). The use of INCLUDE_MC68881 remained the same during the change from VxWorks 5.0 to the later Gnu tools releases. So, the renaming of mathInit() to mathHardInit() is usually not an issue. To summarize, the mathInit() call is probably not required in your application code, since mathHardInit() should already be getting called when the system comes up. I suspect that Brian's co-worker simply read the description of mathInit() in the VxWorks Reference Manual and (rightly) decided that it was appropriate. This is an unfortunate effect of having only one manual for the various 5.0[.x] releases. In reality there are only a handful of differences; Brian just happened to get caught by one of them. I hope this clears up the confusion. Bye for now, Kent Long Wind River Systems kent@wrs.com --------------------------- End of New-News digest ********************** From jsnow@moons.sim.es.com Wed Apr 22 08:38:29 1992 From: jsnow@moons.sim.es.com (John Snow) Date: Wed Apr 22 08:38:38 PDT 1992 Subject: gcc compiler and 68040 We have identified an instruction sequence generated by the gcc compiler when generating code targeted for the 68K family which runs very slowly on the 68040. When run with the optimize switch (maybe without it, but we've only seen it happen with the optimizer on), the gcc compiler will generate fmovecr instructions to move floating point constants from the 68881/2 constant ROM to floating point registers if the constant is available in ROM. This is faster on the 68881/2 than doing a move of immediate data to the floating point register. However, the 68040 FPU has no constant ROM and a fmovecr instruction generates a trap to software emulation which runs very slowly. With the 68040, it is far faster to generate the immediate data move instruction which doesn't trap. I generated a 68040 specific version of gcc which doesn't generate the fmovecr instruction. It's quite easy to do. There is a function called standard_68881_constant_p() in the file out-m68k.c which is called to determine if a constant is available in the 68881 constant ROM. If this function returns 0, the constant is not available in the ROM and a fmovecr instruction will not be generated. If you hack this function to always return 0, you won't get any fmovecr instructions. Obviously, the real fix should be to add a -m switch indicating that the target was a 68040 and that fmovecr instructions shouldn't be issued. However, I didn't want to spend much time trying to figure out gcc's switch mechanism. Maybe someone (WRS? Cygnus?) out there will do it. ----------------------------------------------------------------------------- John F. Snow INET: jsnow@moons.sim.es.com Evans & Sutherland Computer Corp. Salt Lake City, Utah From jody@rti.com Wed Apr 22 23:15:14 1992 From: jody@rti.com (Jody G. Blank) Date: Wed Apr 22 23:15:22 PDT 1992 Subject: RTI releases version 4.0 of StethoScope ***************************************************************************** Product Announcement ***************************************************************************** VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED. Real-Time Innovations, Inc. is pleased to announce that Version 4.0 of StethoScope is now ready for customer shipment. StethoScope is a real-time graphical monitoring and data collection tool. StethoScope collects data from your program in real-time, buffers it, and transmits it to your workstation for full-color graphical display. The data can then be saved, printed, or exported to analysis packages such as MATLAB and MatrixX++. StethoScope version 4.0 includes many new or enhanced features, including a real-time execution profiler. ***************************************************************************** SUMMARY OF MAJOR NEW FEATURES: * Pan and zoom - Focus on a specific region of a graphical display. * On-screen measurements - Measure the coordinates of any point or differences between points. * Multiple buffers - Save many individual sets of collected data while you continue to collect more. Re-load buffers from disk for further analysis. * X vs Y plot mode - Plot with respect to any signal, rather than just plotting time histories. * Presentation-quality PostScript output. * Derived signals - Create signals from combinations of other signals. * Much expanded on-line help and man pages - Become an expert user easily! * Repetitive store-to-disk - Automatically save data sets to disk. * Execution profiling - Monitor the execution flow of VxWorks programs on a procedure-by-procedure basis, and analyze exactly how a VxWorks program is utilizing the processor. ***************************************************************************** AVAILABILITY: StethoScope 4.0 is available immediately for the following environments: Host architecture: Sun3 or Sun4 SunOS: 4.1 or better Windowing systems: X11 or OpenWindows VxWorks targets: 680X0 or SPARC The ScopeProfile execution profiler module is only available for 680x0 targets at this time. ***************************************************************************** FOR FURTHER INFORMATION: StethoScope is a tool you won't know how to live without! To get more information, contact your sales representative: In the United States and Canada: Wind River Systems ==== ===== ======= Phone: (800) 545-WIND [800 545-9463] Fax: (510) 814-2011 email: sales@wrs.com In Europe: Wind River Systems EC ==== ===== ======= == Phone: 33.1.69.07.78.78 Fax: 33.1.69.07.08.26 email: sales@wrsec.fr In Japan, Korea, and Taiwan: ASR Corporation === =========== Phone: 3-3502-5573 Fax: 3-3502-5570 You may also contact your local WRS sales representative. ***************************************************************************** ++ MATLAB is a trademark of The MathWorks, Inc. MatrixX is a trademark of Integrated Systems, Inc. =============================================================================== = = = = Jody G. Blank = email: jody@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From daemon@vxw.ee.lbl.gov Thu Apr 23 04:00:26 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 23 04:00:33 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 23 04:00:20 PDT 1992 Subject: Re: accepted method of ld'ing many .o files ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: accepted method of ld'ing many .o files Date: 22 Apr 92 16:37:12 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <1992Apr21.010301.4244@elroy.jpl.nasa.gov> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) In article <1992Apr21.010301.4244@elroy.jpl.nasa.gov> litwin@litwin.jpl.nasa.gov (Todd Litwin) writes: >We use the Unix ld command. When I create a Unix program, I usually use cc >to invoke ld by doing something like: cc -o progname prog1.o prog2.o prog3.o ... >To build the corresponding file for VxWorks, I do: ld -r -o progname prog1.o prog2.o prog3.o ... >Note the the "-r" is necessary to keep the output in relocatable object format. >You can combine any number of object files in this way into a single file >for downloading. Not only is downloading time greatly decreased, but you >no longer need to worry about the order of downloading the modules. In fact, >this method is the only way to deal with two different object files that make >references to functions in each other. I agree and use the same method. I'd just add that this way also avoids a problem that can happen during the development cycle of several modules: suppose you initially download modules A and B, then recompile B and download it again. If module A references anything out of B, it will still be using the *original* version, not the recompiled one. This is usually not what you want. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ I know it's a non sequitur, but what does that have to do with it ? --------------------------- End of New-News digest ********************** From Enterprise!arete.com!reder@uu.psi.com Thu Apr 23 13:49:37 1992 From: reder@arete.com (Leonard J. Reder) Date: Thu Apr 23 13:49:48 PDT 1992 Subject: Re: RTI releases version 4.0 of StethoScope > Submitted-by jody@rti.com Wed Apr 22 23:15:14 1992 > Submitted-by: jody@rti.com (Jody G. Blank) > > > > ***************************************************************************** > Product Announcement > ***************************************************************************** > > VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED. > Why is it that the price of these things is never given? How much does this product cost? From briggs@thalia.jpl.nasa.gov Thu Apr 23 16:47:57 1992 From: briggs@thalia.jpl.nasa.gov (Clark Briggs) Date: Thu Apr 23 16:48:12 PDT 1992 Subject: gcc compiler and 68040 John Snow pointed out how to get gcc to stop using fmovecr which generate traps on the 68040. His fix is quite nice but I agree with closing request for someone to add specific capabilities to gcc for the 68040. WRS included the software lib to makeup for the missing fpu functions such as cos & sin. Like fmovecr, there are several other simple functions that must be trapped to this soft lib but could be avoided if gcc were modified to take advance of 68040 specific opcodes. The ones that really make me crazy are the data conversion from/to ints,floats, & doubles. Prior architectures had lots of op codes to the permutations, but the 040 only has one or a few. Like John, I would like someone to change gcc to do these few things that are in appropriate to do with soft libs. I was told by my support engineer that given the speed of the 040, these traps are no slower than the 030 in total execution time. Ok so I'm not being killed by the situation, but I'm also not getting the speed enhancement I paid for. The seriousness of this clearly depends on the number of times the soft lib is used, and I've been content to date because this is not a big hit on my application performance. Now it looks like there are several simple things that could be improved by a knowledgable someone. Please upgrade gcc to incorporate these 040 peculiar features. Clark Briggs briggs@csi.jpl.nasa.gov Jet Propulsion Laboratory Pasadena, CA From visicom!VisiCom.COM!trest@nosc.mil Thu Apr 23 17:14:02 1992 From: Mike Trest Date: Thu Apr 23 17:14:10 PDT 1992 Subject: Re: RTI releases version 4.0 of StethoScope >> reder@arete.com (Leonard J. Reder) >>Why is it that the price of these things is never given? >>How much does this product cost? I also would not mind seeing price stuff here. However, several years of network experience in a public formum like this have shown that detail pricing data for a product with a lot of options is hard to communicate correctly. It is hard for the vendor because they do not want to miss a sale for a lignt weight version of something by blasting a prospect with the heavy weight maximum price version. It is also a waste of time for those who do not care. As a seller of products and services in the VxWorks community, VisiCom is sensitive to many network users who do not appreciate the clutter of commercial literature on the public net. In reality, the network is sustained by us users to foster exchange of technical ideas among a group of developers who use VxWorks. I truly appreciate the work involved and the community service it renders. Therefore, VisiCom does not announce product except in response to specifc inquiry on the network. We do send price data to the exploder. However, we use the EMAIL address of an individual and will include price data since it is simple. On the other hand, availability of products (Free/Share/Commercial) is important to me as a technical developer. Therefore I really do want to see announcements. So my personal desire for announcements is greater than VisiCom's corporate position. ==================================================================== For those who may care to know about VisiCom Laboratories ==================================================================== VisiCom Laboratories (1) sells turn-key products for Mil-ON-143(v)6/7/11, UYK-20, UYK-44, and UYK-7 computer replacement (2) resells VxWorks (3) specialty shop for VxWorks BSPs, Device Drivers for the OEM market or for custom board builders (4) application developer for real time (5) custom embedded hardware design/prototype house (especially if they need VxWorks real time kernels) Collectively these activities are in the $10M revenue range. We have approximately 100 employees and more than 40 software developers who work with VxWorks every day. I would like to receive EMAIL with announcements of any products which anyone in the exploder community may think useful to someone like me or my company. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From stan@rti.com Thu Apr 23 20:27:57 1992 From: stan@rti.com (Stan Schneider) Date: Thu Apr 23 20:28:04 PDT 1992 Subject: Re: RTI releases version 4.0 of StethoScope >> > VERSION 4.0 OF STETHOSCOPE FOR VXWORKS RELEASED. >> > >> Why is it that the price of these things is never given? >> How much does this product cost? >> Sorry. Our understanding was that net etiquette frowns on publishing prices. Besides, a variety of licenses are available; pricing structures are not always that simple to relate in a short email message. We will send you a complete price list immediately. -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From daemon@vxw.ee.lbl.gov Fri Apr 24 04:00:24 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Apr 24 04:00:32 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 24 04:00:17 PDT 1992 Subject: X11 for VxWorks 5.0.3? Subject: GNU C and Sun's ld.so Subject: SCSI from multiple CPUs ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: X11 for VxWorks 5.0.3? Date: 22 Apr 92 16:54:35 GMT From: sharpster@hns.com (Stephen Harpster) Organization: Hughes Network Systems Keywords: X11, VxWorks Message-ID: <1992Apr22.165435.26475@hns.com> Sender: news@hns.com (USENET news system) I looked at the X11 libraries in the VxWorks Software Archive only to find that they are the R3 libraries for VxWorks 4.x. :-( The work in going from 4.x to 5.0.3 looks like it would be some doing. Does anyone have a 5.0.3 version, preferably X11R4? --------------------------- Newsgroups: comp.os.vxworks Subject: GNU C and Sun's ld.so Date: 23 Apr 92 20:17:28 GMT From: junel@bilbo.heurikon.com (June Liesch) Organization: Heurikon Corporation, Madison, WI Message-ID: <1431@heurikon.heurikon.com> Reply-To: junel@heurikon.heurikon.com (June Liesch) Sender: news@heurikon.heurikon.com I have a customer with an HK68/V30XE running vxWorks 5.0.1 and a Sun 3/60 running 4.0.3_EXPORT. This customer is trying to compile ~vw/demo/1/demo.c with the GNU C compiler, version 1.37.1. I believe he has his environmental variables set up properly. He compiles as follows: cc68k -v -traditional -O -c -I/home/vw/h demo.c and gets the error: ld.so: warning: /usr/lib/libc.so.0.12 has older revision than expected 14 ld.so: call to undefined procedure _tolower from 0x20116 From what little I know about ld.so, I would guess this is a Sun problem, although it appears he doesn't have problems other than compiling with GNU. Has anyone seen this problem before? Does anyone know what to do about it? Should I have him upgrade his SunOS? Thanks, June - -------------------------------------------------------------------------------- June Liesch | "I don't think much of our profession, but con- Software Customer Support | trasted with respectability, it's comparatively Heurikon Corporation | honest." - The Pirate King, from G&S's junel@heurikon.com | "The Pirates of Penzance" - -------------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: SCSI from multiple CPUs Date: 24 Apr 92 02:56:57 GMT From: flash@austin.lockheed.com (James W. Melton) Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744 Keywords: SCSI, disk Message-ID: <933@shrike.com> To the vxWorks community: I have a problem which, based on recent discussions in this newsgroup, is not unique to me. I also expect it to become much more common in the future. I have a hardware suite consisting of multiple CPUs on a backplane with a separate SCSI controller, attached to a hard disk. I would like to have access, from any CPU, to the disk. I believe the controller supports multiple hosts talking to it, but my concern is how vxWorks would manage a filesystem accessed by several hosts. There are really two issues here. The first is support for off-board SCSI. My sales rep tells me that there is at least one SCSI board with vxWorks support. Mine is not one of them; but porting/writing a device driver is a fairly well bounded problem (if anyone has one they would like to give me... :-) ). The second, and more difficult problem is ensuring consistency of a filesystem accessed from multiple hosts. This problem can be demonstrated apart from the SCSI issue. Create a RAM disk in VME address space. Make a filesystem on it. Create the same RAM disk on another CPU. Initialize the filesystem to that CPU. What will happen? I am almost positive that vxWorks will not support this configuration. At issue is whether periphals (or even RAM disks) are resources for the entire VME system, or only for one arbitralily selected CPU. While only supporting on-board SCSI skirts the issue (the periphal is directly connected to a CPU, so yes it is dedicated), the real-time world begs for a more open solution. Of course, one solution is server NFS support in vxWorks ;-) I am interested in the discussion this will (hopefully) stimulate. If anyone has any experience in this area, please email me. - ---- Jim Melton flash@austin.lockheed.com in person: (512) 386-4303 | "So far as we know, our voice mail: (512) 386-4486 | computer has never had fax: (512) 386-4223 | an undetected error" --------------------------- End of New-News digest ********************** From biocca@bevsun.bev.lbl.gov Fri Apr 24 08:45:14 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Fri Apr 24 08:45:45 PDT 1992 Subject: Re: Exploder - Newsgroup connection In answer to a question regarding the exploder and the newsgroup: The VxWorks Users Group Exploder: The exploder is an email redistribution engine. It preceded the newsgroup and offers two kinds of service -- immediate and daily. The immediate service resends each article as soon as it arrives and compiles a digest that goes to the daily list early the next morning. Users can subscribe to either the daily service, or the immediate service, or both. Cross Coupling with comp.os.vxworks: Articles from the exploder are spooled as they come in and a periodic daemon posts them to comp.os.vxworks. Articles from comp.os.vxworks are gathered daily and filtered to remove posts from the exploder, compiled into a digest, and emailed to immediate exploder users early in the morning as well as being included into the regular digest targeted for digest users. Theoretically articles in each medium appear in all other mediums. Occasionally the articles are rejected by the news system. If I don't take action these articles will be lost in five days or so. I've set up a cron job to show me these stuck posts, so I should be able to fix their problems. Alan K Biocca Exploder Maintainer AKBiocca@lbl.gov From visicom!VisiCom.COM!trest@nosc.mil Fri Apr 24 09:14:26 1992 From: Mike Trest Date: Fri Apr 24 09:14:34 PDT 1992 Subject: Re: comp.os.vxworks newsdigest >>From: sharpster@hns.com (Stephen Harpster) >>Organization: Hughes Network Systems >>I looked at the X11 libraries in the VxWorks Software Archive only to >>find that they are the R3 libraries for VxWorks 4.x. :-( The work in >>going from 4.x to 5.0.3 looks like it would be some doing. Does anyone >>have a 5.0.3 version, preferably X11R4? VisiCom Laboratories has X11R4 (client, server, and all MIT libraries, and clients) and MOTIF 1.1 (mwm, all libraries, most clients) running with VxWorks 5.0.x. WRS WindX is also X11R4 (client and libraries). Both are commercial products rather than ARCHIVE contributions. VisiCom Laboratories recommends and sells both products. To use VX-SERVER you need a hardware vidio card, either smart-card or dumb-frame-buffer. However, all X clients may talk to network displays. We have done applications for in which a MOTIF based local interface was also capable of using multiple remote control windows on network workstations (All clients on VxWorks with a small workstation requestor task). We have even done a TOUCH SCREEN ONLY version of X-server and simulated KEYBOARD, MOUSE, and BUTTONS on the screen. For more details please contact me. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From visicom!VisiCom.COM!trest@nosc.mil Fri Apr 24 10:18:02 1992 From: Mike Trest Date: Fri Apr 24 10:18:09 PDT 1992 Subject: Re: comp.os.vxworks newsdigest >>Subject: SCSI from multiple CPUs >>From: flash@austin.lockheed.com (James W. Melton) >>I have a hardware suite consisting of multiple CPUs on a backplane >>with a separate SCSI controller, attached to a hard disk. Alas, one of my favorite applications of scsi and VxWorks! >>There are really two issues here. The first is support for off-board >>SCSI. My sales rep tells me that there is at least one SCSI board with >>vxWorks support. Mine is not one of them; but porting/writing a device >>driver is a fairly well bounded problem (if anyone has one they would >>like to give me... :-) ). Another problem, neither WRS or my company allows us to give away the store. Privately, I have been thinking about posting a generic SCSI block driver which interfaces to scsiLib (mabey some weekend when I feel energetic). >>At issue is whether periphals (or even RAM disks) are resources for >>the entire VME system, or only for one arbitralily selected CPU. While >>only supporting on-board SCSI skirts the issue (the periphal is directly >>connected to a CPU, so yes it is dedicated), the real-time world begs >>for a more open solution. There is a more fundamental description of the problem in the real-time market place. We are doing custom hardware with embedded VxWorks where there are 7 processors on a single processor board (VME/9U) which is designed to talk via backplane to 7 other boards. With 56 processors all needing a piece of the SCSI disk pool the concerns which you expressed are obviously multiplied. Regardless of 1 or N, in the present VxWorks technology we must either: (1) Create a server or Pseudo-Server (2) Allow Writing by only one CPU (3) Come up with a new file system (4) Encourage WRS in multi-processor architectural improvements Creating a server or pseudo-server, means using IPC facilities between processors to pass operations against file handles between the processors. Such a scheme is actually rather simple to implement, but the problem is that each file opened on one processor must have a matching file opened on the processor actually running dosFs. There are also performance concerns which with any single CPU server (unless you have the ability to dedicate a processor to this functionality). Writing by only one CPU has been my most frequent solution. If your application is such that only one CPU is creating new files and updating FATs, then all of the additional processors with their own copies of dosFs will be quite happy. However, you will, from time to time have to cause the read-only CPUs to refresh their directory from time to time to discover the newly created files. A new file system is not out of the question. An associate here at VisiCom has written a BSD-compatible file system. I am trying to convince her to let me bring it up to dosFs and rawFs VxWorks interface standards. But that takes time (and budget). If we users will encourage WRS in multi-processor architectural improvements, perhaps we will see a natural solution to the dosFs problem in a fully distributed VxWorks model. In this approach all processors in a cluster divide execution of system functions, like file systems, in a reasonably seamless manner. WRS is asking at user's group meetings "What do you want to see in the future?". Perhaps if we continue our suggestions, they will assign a budget and make it happen. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From comtec!orincon!robert@ucsd.edu Fri Apr 24 12:30:48 1992 From: comtec!orincon!robert@ucsd.edu (Robert Redfield) Date: Fri Apr 24 12:30:55 PDT 1992 Subject: Re: RTI releases version 4.0 of StethoScope I'm very interested in StethoScope. Unfortunately we run VxWorks on an i960 machine (Heurikon V960E). Put me on a mailing list or whatever so that I know when your product is available for me. Thanks. Robert Redfield ORINCON Corp. (619) 455-5530 x252 From daemon@vxw.ee.lbl.gov Sat Apr 25 04:00:25 1992 From: daemon@vxw.ee.lbl.gov Date: Sat Apr 25 04:00:33 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 25 04:00:19 PDT 1992 Subject: VxWorks 5.0.x and ifMaskSet() byte order Subject: FDDI Subject: How do you get task id when using taskInit()/taskActivate()? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VxWorks 5.0.x and ifMaskSet() byte order Date: 23 Apr 92 14:00:32 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550008@hppad.waterloo.hp.com> It seems that one must be on the lookout for queer things when going from VxWorks 4.0.2 to 5.0.x. I made all the changes made necessary by header file changes and ANSI prototype definitions that were incompatible with current usage - not a pleasant job, I might add. Then I linked everything together and found that the network code stopped working soon after downloading our code and starting it. The eventual cause was a change in the byte order of the network mask parameter to ifMaskSet(). Seems Wind River changed the required order from network to host without warning us (at least I didn't see any reference to a change anywhere). ifMaskSet() now does an htonl() before passing the mask to a socket ioctl. Whether the previous behavior was correct or incorrect doesn't matter in the least - it's the unannounced change that caused the grief. All this occurred with the Heurikon hkv960 BSP - although the library causing the problem would be the same for any BSP, I suppose. There would be no apparent effect on 68K based systems as network == host order. Ted Rypma HP Panacom Division --------------------------- Newsgroups: comp.os.vxworks Subject: FDDI Date: 24 Apr 92 19:12:54 GMT From: singer@ll.mit.edu (Matthew R. Singer) Organization: MIT Lincoln Laboratory Message-ID: <1992Apr24.191254.10270@ll.mit.edu> Reply-To: singer@ll.mit.edu (Matthew R. Singer) Sender: singer@ll.mit.edu (Matthew R. Singer) - - Anyone have a list (are there more than one) of FDDI vendors with VxWorks support? Thanks - ----------------------------------------------------------------------------- Matthew R. Singer MIT Lincoln Laboratory (617) 981-3771 244 Wood Street singer@ll.mit.edu Lexington, MA 02173 - ----------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: How do you get task id when using taskInit()/taskActivate()? Date: 23 Apr 92 15:42:19 GMT From: sharpster@hns.com (Stephen Harpster) Organization: Hughes Network Systems Message-ID: <1992Apr23.154219.18000@hns.com> Sender: news@hns.com (USENET news system) Okay, I give. How do you get the task id when using taskInit()/taskActivate()? Unlike taskSpawn(), taskInit() does not return the task id. Instead it returns OK or ERROR. Now taskActivate() expects a task id in order to activate the task. The only way I can see to get the task id is to name the task in taskInit() and then taskActivate(taskNameToId(name)); but this seems pretty silly. Am I missing something?? P.S. I'm using Vx960 5.0.3. --------------------------- End of New-News digest ********************** From iphasew!hwajin@apple.com Sat Apr 25 13:36:15 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Sat Apr 25 13:36:21 PDT 1992 Subject: Re: VxWorks 5.0.x and ifMaskSet() byte order Ted Rypma justly points out... Ted> Seems Wind River changed the required order from network to host Ted> without warning us (at least I didn't see any reference to a Ted> change anywhere). ifMaskSet() now does an htonl() before passing Ted> the mask to a socket ioctl. Whether the previous behavior was Ted> correct or incorrect doesn't matter in the least - it's the Ted> unannounced change that caused the grief. Last time I checked ifMaskSet() did not do any conversion (this was in beta 5.0). If ifMaskSet() indeed has been changed to do htonl(), this is inconsistent with the rest of network code in VxWorks as well as original UNIX "ifconfig" convention. The reason is that the users may want to do things like, -> ifMaskSet("ln0", inet_addr("255.255.255.0")) This is essentially functionally equivalent of what UNIX ifconfig would do internally. Since inet_addr() returns Internet address in network order, doing htonl() inside ifMaskSet() would result in incorrect value for the mask. The confusion is partly due to inconsitent function call interface provided by ifMaskSet(), which requires an "int" whereas other "if" routines such as ifAddrSet(), ifBroadcastSet(), etc. require "char *" for the Internet address argument. The network mask is used in network order, and should have been passed around as such. I didn't think changing ifMaskSet() was a good idea (although it would be more consistent with other "if" routines) for historial reasons at the time. Sigh... ~Hwajin From iphasew!hwajin@apple.com Sat Apr 25 15:31:52 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Sat Apr 25 15:31:58 PDT 1992 Subject: Re: do you get task id when using taskInit()/taskActivate()? The first arg to taskInit() (address of new task's TCB) can be used as task id. -- Hwa-Jin Bae Interphase West Santa Clara, CA From cruise@cfht.hawaii.edu Sat Apr 25 21:57:37 1992 From: Bill Cruise Date: Sat Apr 25 21:57:45 PDT 1992 Subject: Sparc 1e boot ROM's I have 4 SparcEngine 1e boards -- 2 old, and 2 new. The old ones came with 2 boot ROM's from Sun. I put the 2 vxWorks boot ROM's on, and everything works quite well, version 4 or 5. The new ones come with only 1 boot ROM from Sun, but there are still two sockets, and everything else looks the same. I received no documentation with the boards. I put the vxWorks ROM's on (version 4 only, so far) and nothing happens. The boards appear to stay locked up, and nothing appears on the console. Am I, as I suspect, missing something very fundamental? Or, is there some trick that I haven't come across yet -- I'd feel better about that. Of course I can't find anything in the vxWorks docs. Any help will be gratefully appreciated. Bill Cruise Canada-France-Hawaii Telescope From marc@sun-valley.stanford.edu Sun Apr 26 01:25:33 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Sun Apr 26 01:25:41 PDT 1992 Subject: Re: Sparc 1e boot ROM's >Submitted-by cruise@cfht.hawaii.edu Sat Apr 25 21:57:37 1992 >Submitted-by: Bill Cruise >Am I, as I suspect, missing something very fundamental? Or, is there >some trick that I haven't come across yet -- I'd feel better about that. >Of course I can't find anything in the vxWorks docs. > >Any help will be gratefully appreciated. I have never actually used one of the new Sparc boards, but noting that you're working on this late on a Sat. evening, I figured I'd toss in my 2 cents. My guess would be that Sun switched to a larger size EPROM and that there is probably a little address jumper somewhere that configures the board for one or two EPROMS. Another possibility is that they were using a 16 bit path to ROM and, in as much as you say it only came with one), are now using only an 8 bit path. This could again require the changing of a jumper or more radically, that you re program your prom in an 8 bit wide fashion (e.g. no more odd/even). Hope that helps, --Marc Ullman Stanford University From daemon@vxw.ee.lbl.gov Sun Apr 26 04:00:24 1992 From: daemon@vxw.ee.lbl.gov Date: Sun Apr 26 04:00:31 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 26 04:00:18 PDT 1992 Subject: Re: distributed vxWorks! ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: distributed vxWorks! Date: 26 Apr 92 03:29:23 GMT From: flash@austin.lockheed.com (James W. Melton) Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744 Message-ID: <937@shrike.com> References: <9204241512.AA22749@dtc163.VisiCom.COM> In article <9204241512.AA22749@dtc163.VisiCom.COM> trest@visicom.com (Mike Trest) writes: |>>Subject: SCSI from multiple CPUs |>>From: flash@austin.lockheed.com (James W. Melton) | |>>I have a hardware suite consisting of multiple CPUs on a backplane |>>with a separate SCSI controller, attached to a hard disk. | |Alas, one of my favorite applications of scsi and VxWorks! | |>>At issue is whether periphals (or even RAM disks) are resources for |>>the entire VME system, or only for one arbitralily selected CPU. While |>>only supporting on-board SCSI skirts the issue (the periphal is directly |>>connected to a CPU, so yes it is dedicated), the real-time world begs |>>for a more open solution. | |There is a more fundamental description of the problem in the real-time |market place. We are doing custom hardware with embedded VxWorks |where there are 7 processors on a single processor board (VME/9U) |which is designed to talk via backplane to 7 other boards. With 56 |processors all needing a piece of the SCSI disk pool the concerns |which you expressed are obviously multiplied. | |Regardless of 1 or N, in the present VxWorks technology we must |either: | | (1) Create a server or Pseudo-Server | (2) Allow Writing by only one CPU | (3) Come up with a new file system | (4) Encourage WRS in multi-processor architectural improvements | |If we users will encourage WRS in multi-processor architectural |improvements, perhaps we will see a natural solution to the |dosFs problem in a fully distributed VxWorks model. In this approach |all processors in a cluster divide execution of system functions, |like file systems, in a reasonably seamless manner. WRS is asking |at user's group meetings "What do you want to see in the future?". |Perhaps if we continue our suggestions, they will assign a budget and |make it happen. Wind River, if you are listening, my vote is for a truly distributed real-time kernel. For now, it doesn't even have to be symmetric. In the future we will all be doing more applications with multiple processors (whether on the same card or merely on the same backplane). In many respects, my current system (SCSI problem aside) would be much simpler if the kernel could know about everything happening inside the chassis, instead of having to carefully partition functions to discrete processors and coordinate between autonomous kernels. Case in point. (Disclaimer. The hardware was chosen before the software was designed. It happens.) My application needs access to several serial lines. The system contains an Ironics board with 16 serial lines. Unfortunately, this is a _smart_ board, with a 68EC030 processor running a vxWorks kernel. Current technology requires A. Write some sort of IPC interface to treat this card as a "dumb" serial card and make it accessible the processor pool. B. Isolate all parts of the application which require access to serial lines and host them on the Ironics card. A distributed vxWorks would allow features of all cards in the chassis to be available to any processor. A symmetric vxWorks would not require the a priori allocation of tasks to processors (of course, some allowance must be made for software compiled for different processors) Now that you've stimulated my wishful thinking... - --- Jim Melton, novice guru in person: (512) 386-4303 | "So far as we know, our voice mail: (512) 386-4486 | computer has never had fax: (512) 386-4223 | an undetected error" e-mail: flash@austin.lockheed.com | --------------------------- End of New-News digest ********************** From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net Sun Apr 26 18:49:55 1992 From: "Roeber" Date: Sun Apr 26 18:50:02 PDT 1992 Subject: Re: distributed vxWorks > > In article <9204241512.AA22749@dtc163.VisiCom.COM> trest@visicom.com (Mike Trest) writes: > |If we users will encourage WRS in multi-processor architectural > |improvements, perhaps we will see a natural solution to the > |dosFs problem in a fully distributed VxWorks model. In this approach > |all processors in a cluster divide execution of system functions, > |like file systems, in a reasonably seamless manner. WRS is asking > |at user's group meetings "What do you want to see in the future?". > |Perhaps if we continue our suggestions, they will assign a budget and > |make it happen. > > > Wind River, if you are listening, my vote is for a truly distributed > real-time kernel. For now, it doesn't even have to be symmetric. In > the future we will all be doing more applications with multiple > processors (whether on the same card or merely on the same backplane). > In many respects, my current system (SCSI problem aside) would be > much simpler if the kernel could know about everything happening > inside the chassis, instead of having to carefully partition functions > to discrete processors and coordinate between autonomous kernels. I beg to differ on the desire for trying to make VxWorks support symmetric multiprocessing. We are enhancing VxWorks to support a form of multiprocessing that I'll call "snuggly coupled multiprocessing" to borrow a term I first saw in Lynx OS literature. This is a very restricted subset of what would be required to really have standard multiprocessing. Even so, we are trading off some performance to make things work. One of the main points behind VxWorks is that it is fast. If one really wanted multiprocessing (and therefor things like virtual memory management that are almost certainly required to support it) then one could always get something like Lynx OS. We didn't do that because we couldn't stand to have things be a lot larger and a lot slower than they are under VxWorks. If WRS tries to go that way things will definitely run slower. Is that what everyone wants? One of the biggest issues with multiprocessing is handling the fact that shared data may be cached across multiple processors. Since the VME bus doesn't support the notion of cache coherency, getting this sort of shared data to work involves tricky cache manipulation on every processor or requires turning the cache off. At the last East Coast user group meeting I asked a question about this and got the impression that most people ran with cache disabled for there multiprocessor applications. On a 68030, this has a moderate impact (perhaps a 30% performance reduction for data intensive applications). The problem is that for a 68040 the impact is much greater (I have heard that things can run one third the speed). There are some serious questions with getting multiprocessing to work in any one particular environment. To get it to work in the wide range of heterogenous environments that VxWorks now supports would seem to be an impossible feat in my mind (at least with any reasonable performance). Just figured I would throw in my two cents. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From @ada3.ca.boeing.com:crispen@efftoo.boeing.com Mon Apr 27 05:58:30 1992 From: crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> Date: Mon Apr 27 05:58:38 PDT 1992 Subject: Re: distributed vxWorks! Jim Melton, novice guru writes: >Wind River, if you are listening, my vote is for a truly distributed >real-time kernel. Heck, I'll settle for multi-processor semaphores. No, wait a minute, I'll settle for multi-processor semaphores that only work on the most popular CPU boards. Or how about MPSs that work on one or two boards.... You know what I'm looking for -- not just a VME test and set, but a VMETAS that will automatically pend my process and revive it (hell, even through a VME interrupt). I'm willing to live with the "only semTake at task level" rule. Doesn't SOMEBODY have a hack for this? I'm willing to accept something that isn't elegantly integrated with the Wind kernel, so long as it doesn't actually crash VxWorks (and VADSWorks). Hey, I know -- WRS can release it on the exploder as a kind of "dangerous beta" item and get users' reactions to it. Instead of waiting for a full-blown elegant release, give us a little bitty tool we can use to avoid the backplane and sockets. What do some others think? Bob Crispen crispen@foxy.boeing.com From prb@aplexus.jhuapl.edu Mon Apr 27 06:00:39 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Mon Apr 27 06:00:47 PDT 1992 Subject: Re: distributed vxWorks Fred Roeber writes: > One of the biggest issues with multiprocessing is handling the fact that > shared data may be cached across multiple processors. Since the VME bus > doesn't support the notion of cache coherency, getting this sort of shared > data to work involves tricky cache manipulation on every processor or requires > turning the cache off. At the last East Coast user group meeting I asked a > question about this and got the impression that most people ran with cache > disabled for there multiprocessor applications. On a 68030, this has a > moderate impact (perhaps a 30% performance reduction for data intensive > applications). The problem is that for a 68040 the impact is much greater > (I have heard that things can run one third the speed). > > Perhaps most people run with cache disabled but that can really give you a big hit in processing power with the 68040. VxWorks does provide the flexibility such that with a little MMU work you don't have to turn the cache off. We are using a MV167 (68040 board) and have specified that the backplane memory pool be in upper memory and is mapped as write-thru with bus snooping. Caching is definitely significant with TCPIP. We also have an area in low memory for custom communications which is cache disabled since we are always either doing one time copies into/out of this area (no need to be cached) (no bus snooping) Middle memory is not mapped to the VMEbus (not a shared resource) and can thus be configured as cacheable copyback. It may take a little work but it is well worth the trouble; you may as well get the processing power you paid for in the 68040. Paul Bade Johns Hopkins University / Applied Physics Lab prb@aplexus.jhuapl.edu From marc@sun-valley.stanford.edu Mon Apr 27 10:09:56 1992 From: marc@sun-valley.stanford.edu (Marc Ullman) Date: Mon Apr 27 10:10:03 PDT 1992 Subject: Re: distributed vxWorks > > >Submitted-by prb@aplexus.jhuapl.edu Mon Apr 27 06:00:39 1992 >VxWorks does provide the flexibility such that with a little MMU >work you don't have to turn the cache off. >We are using a MV167 (68040 board) and have specified that >the backplane memory pool be in upper memory >and is mapped as write-thru with bus snooping. I think that both WRS and their user community would enjoy seeing the necessary changes if you'd be will to post them. We have been concerned with this same issue (on a speculative level--no 167's in house yet) and have surmised that what you have just described could be done. If you're willing to share it, it would eliminate the need to "re-invent the wheel." Thanks, --Marc Ullman Stanford University From ROSS%SCFF.decnet@scfb.nwc.navy.mil Mon Apr 27 10:52:23 1992 From: "SCFF::ROSS" Date: Mon Apr 27 10:52:31 PDT 1992 Subject: RE: Sparc 1e boot ROM's We encountered your problem - here's what we found: 1) All new Sparc 1e boards come with the boot ROM daughter board configured for two 2-megabit EPROMS instead of the two 1-megabit chips of the older borads. You need to either use a 2-megabit EPROM or modify the daughter board. We recommed that you burn the vxworks boot ROM file into a 2-megabit chip. 2) After you get that far, it still won't work - you need to apply a patch to get the new boards to work. Ask Wind River for the uninitialized variable fix to kernel init() for the Sparc 1e. And that should do it!! RSVP if you have questions! Pamela Ross Naval Air Warfare Center - Weapons Division China Lake, CA From daemon@vxw.ee.lbl.gov Tue Apr 28 04:00:27 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Apr 28 04:00:36 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 28 04:00:20 PDT 1992 Subject: Re: vme address questions Subject: chomped on by a compiler optimization Subject: Re: chomped on by a compiler optimization Subject: Re: vme address questions Subject: Re: Sparc 1e boot ROM's ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: vme address questions Date: 27 Apr 92 18:47:37 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) In article rg@msel.unh.edu (Roger Gonzalez) writes: >How does one specify VME address modifier codes to VxWorks? For example, if >I want to access A24 address 0x80200, I guess I would use AMC 0x39, and in >pSOS I would have tacked this onto the front end of the address, 0x3980200. >At least I think this is the way I used to do it. I've been using Sun's mmap >since I last played with pSOS so I haven't had to think about AMCs for a while. Typically, the CPU board generates the AM codes based on the address specified. For example, most Motorola boards generate a short IO access for addresses above 0xffff0000. Similarly, other AM codes are generated for other ranges of physical addresses; the manual usually contains a table with the pertinent info. >Does the shell grok off board VME addresses? Absolutely ;-) Actually, it doesn't really know about on- vs. off-board; the CPU card does. In sysLib.c for your board, check out sysLocalToBusAdrs() and sysBusToLocalAdrs() -- that should give you some insight. >One big deficiency of the VxWorks shell that I had in pSOS is the ability to >examine or modify exactly -one- byte of memory at a time. This is important >when you are playing with funky hardware where, for example, accessing the odd >bytes will give you a bus error. Agreed. I wouldn't be surprised if someone else out there has already implemented such a function; I'd imagine it would be pretty simple to modify the m() routine in usrLib.c to access memory as single bytes. - -Henning - -- Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University - ------------------------------------------------------------------------------ The Door is a Jar --------------------------- Newsgroups: comp.os.vxworks Subject: chomped on by a compiler optimization Date: 27 Apr 92 20:27:32 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: Sender: news@nic.unh.edu (USENET News System) A code snippet that worked on 6 systems, but failed on VxWorks: DG_REG *dg = (DG_REG *) max_io; /* max_io is the addr of digimax regs */ while(dg->dgTcsr & 0x80) /* sit 'n spin till retrace */ ; ... Resulting code: 0c6504 2079 000d 0938 MOVEA .L _max_io,A0 0c650a 1010 MOVE .B (A0),D0 0c650c 0200 0080 ANDI .B #0x80,D0 0c6510 4a00 TST .B D0 0c6512 66fc BNE 0x0c6510 Not quite what I wanted! I've determined that a lot of my programming habits are kind of sloppy. :-) I presume that notifying the compiler that dg->dgTcsr is volatile would help some, but I haven't been able to get gcc to parse "volatile" as anything but a syntax error. Incidently, is there a better way to do this sort of thing than a busy wait on the hardware register? Has a nasty habit of burning cpu cycles... - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: chomped on by a compiler optimization Date: 27 Apr 92 22:10:56 GMT From: hwajin@pogo.omni.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: Sender: hwajin@iphasew.com >>>>> On 27 Apr 92 20:27:32 GMT, rg@msel.unh.edu (Roger Gonzalez) said: Roger> I presume that notifying the compiler that dg->dgTcsr is Roger> volatile would help some, but I haven't been able to get gcc to Roger> parse "volatile" as anything but a syntax error. If this is due to "-traditional" mode gcc, you can use "__volatile__" instead. - -- Hwa-Jin Bae Interphase West --------------------------- Newsgroups: comp.os.vxworks Subject: Re: vme address questions Date: 27 Apr 92 22:34:39 GMT From: hwajin@pogo.omni.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: Sender: hwajin@iphasew.com >>>>> On 27 Apr 92 18:47:37 GMT, hmp@frc2.frc.ri.cmu.edu (Henning Pangels) said: Henning> Nntp-Posting-Host: squash.frc.ri.cmu.edu Henning> Agreed. I wouldn't be surprised if someone else out there has already Henning> implemented such a function; I'd imagine it would be pretty simple to Henning> modify the m() routine in usrLib.c to access memory as single bytes. Modifying m() in usrLib.c is easy enough. One of many ways to accomplish the same thing inside VxWorks shell: - -> junk='a' - -> junk2='b' - -> bcopy(&junk2,&junk,1) - -- Hwa-Jin Bae Interphase West --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Sparc 1e boot ROM's Date: 27 Apr 92 23:18:04 GMT From: bjh@healy2.Eng.Sun.COM (Brian Healy) Organization: Sun Microsystems Message-ID: References: <9204260455.AA04740@uwila.cfht.hawaii.edu> Reply-To: bjh@healy2.Eng.Sun.COM The "New" SPARCengine 1E board uses bigger boot proms. The three pins on the daughter board (right between the proms) enables the user of the larger proms. What you need to do is to copy the two VxWorks proms onto a single large prom an AM27C020, or jumper the daugheter board to enable the use of the appropiate prom. The small prom requires pins 1 & 2 jumpered, the large prom needs pins 2 & 3 jumpered. The following is a description on how to modify the daughter board to accept the larger proms and enable the NextPROM feature. It has the information you need but is concerned with going form smaller to larger rather than going form larger to smaller proms. Hope it helps! Brian - --------------- Use of the 1E CPU's "NextPROM" feature requires that the PROM daughter board on the CPU be able to support the "Version 1.6" single, 256KB Boot PROM (in CPU revisions -11 or earlier, the Sun Boot code was resident in *two* 128KB PROMs). CPUs with a dash number of -12 or higher are delivered from the factory with NextPROM capability, and require no rework. CPUs with a dash number of -11 or lower will require the modifications below. The dash number of the CPU is listed on the *BACK* of the barcode label affixed to the CPU's front panel. Notes: These modifications are provided for your information only. Be aware that customer modifications will void your Sun warranty, and may render your hardware "unserviceable" by Sun. When handling your 1E hardware, be sure to follow the static electricity precautions outlined in the 1E CPU User's Manual. Refer to Chapter 8 of the current (March 27, 1991) 1E CPU User's Manual for further information on the Boot PROM and the NextPROM feature. Materials you will need: 1. Two blank Intel 27C020 PROMs: * 256 Kbyte of ROM * 32-pin JEDEC DIP package * 200 nanoseconds or faster * Operating temperature 0 to 10 degrees C Note: Only Intel 27C020 PROMs have been qualified with the 1E CPU. Other, similiar devices have not been tested by Sun. 2. A -11 or newer 1E CPU from which you can remove and copy the Boot PROM(s). CPU versions -11 and -12 have identical PROM code. Version -11 CPUs use a "Version 1.5" PROM *set* in which the boot code resides in two, 128KB PROMs (Intel 27C010). Version -12 or higher CPUs use a "Version 1.6" PROM in which all boot code is contained in a single, 256KB PROM (Intel 27C020). If you are not sure which Version of boot PROM is present, look at the "banner" on the monitor during boot-up. Tools you will need: 1. Electrostatic Discharge Prevention kit (ESD mat and wrist grounding strap). 2. Basic electronic tools (soldering iron, hobby knife, wire, etc...). 3. An appropriate PROM programming system. 1. Modify the PROM daughter board to accept 256KB PROM devices: a) Remove PROM daughter board by removing the hex nut and washer located between the two PROMs, the gently unplug the daughter board. b) Cut trace on component side of daughter board between pins 1 and 2 of J0101 (silk screen on back). c) Jumper pin 2 to pin 3 of J0101. d) Replace PROM daughter board, washer, and hex nut. 2. Upgrade the PROMs: a) Remove the two existing Boot PROMs, devices U0101 and U0102, from the PROM daughter board. b) Make a "Version 1.6" PROM. If you are copying a 1.6 PROM, this is a straightforward "copy" procedure. If you are copying a 1.5 PROM *set*, consult your PROM Programming Machine Instructions to determine how to read the contents of the two 128KB PROMs and program the combined code into the single 256KB PROM. Read in the U0101 PROM code first, then read in the U0102 PROM code. Install your "new" Version 1.6 PROM at location U0101 on the PROM daughter board. --------------------------- End of New-News digest ********************** From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net Tue Apr 28 06:58:55 1992 From: "Roeber" Date: Tue Apr 28 06:59:03 PDT 1992 Subject: Re: vme address questions > In article rg@msel.unh.edu (Roger Gonzalez) writes: > > One big deficiency of the VxWorks shell that I had in pSOS is the ability to > examine or modify exactly -one- byte of memory at a time. This is important > when you are playing with funky hardware where, for example, accessing the odd > bytes will give you a bus error. One way I get around this problem is to use the set of bcopy routines to access just the size you want. There are bcopyBytes, bcopyWords, and bcopyLongs. They all work like bcopy but use fixed access size. You can malloc a chunk of memory from the shell and then read the data into it. If you have to, you can do single bytes (e.g. bcopyBytes(src, dest, 1)). This approach isn't pretty since it involves a bit of typing but at least it works. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From briggs@thalia.jpl.nasa.gov Tue Apr 28 08:16:48 1992 From: briggs@thalia.jpl.nasa.gov (Clark Briggs) Date: Tue Apr 28 08:16:58 PDT 1992 Subject: using mmus in realtime Recent discussions about virtual memory and cache management reminded me of a long standing question I have about the cost of using mmus vs the benefit gained. Back when 68020s came with 68451 mmus it was pretty clear how to choose to use or not use them. The mmu added one or two wait states for each address cycle, a big hit. Now that the mmu is integral to the CPU, its harder to tell what the performance hit is, if any. Besides, it seems that many of the manufacturers are using the mmus to simplify the hardware. For example, I understand (but dont know where I got this info) that the mmu in the 68030 contributes to implementing the VMEbus memory map on HK68/V3Es. If mmus are less expensive in that you get one naturally and they are always on anyway, doesnt that make a few software features a lot cheaper to get? Like protected logical address spaces for tasks. The task would run at the same speed but the context would be larger (a concern during switching, depending on the mmu) and the system must be prepared to handle the exceptions. Like shared data regions. But a new system service would be required to arrange the mapping. Like virtual memory. But the system must handle the page faults and its not clear how to do this reasonably in a real-time system. (This is different, that is its more than, just logical address spaces for tasks.) With all of these available, the user could choose which to use in building a set of tasks. Some might run like tasks do now, or some of the wilder ones or the more important ones might get private logical spaces. Maybe even a noncritical task like a console keeper might be implemented using virtual memory, and maybe on its own cpu. But there could be a place for each of these features. I always liked the sound of Masscomp's rtu where the user could scale the Unix features down to a kernel. You could chose to memory lock your code, or not use certain system functions. I think you always got a private logical space. I was told the minimal kernel would run in single digit multiples of real kernels like VxWorks on such metrics as context switch times or semaphore gives. Plus they have had multiprocessing for a while and can put 2 or 4 68040s on a (9U?) board. Yeah, I always thought that sounded nice. So why cant we have some of these features? Clark Briggs briggs@csi.jpl.nasa.gov From prb@aplexus.jhuapl.edu Tue Apr 28 10:37:18 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Tue Apr 28 10:38:10 PDT 1992 Subject: Re: distributed vxWorks ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 30 For those of you that are interested in using the MMU with MV167 boards, here is the heart of the MMU code. Several other corresponding changes were made to bootConfig.c, usrConfig.c, and most importantly to sysLib.c to make the whole thing work. Briefly, we have low memory set up as noncacheable and mapped to the VMEbus without snooping. Then we have changed the start of the system memory pool to allow for a fixed area to load our code and write protect it. This area and the system memory pool is not visible from the VMEbus and is cacheable copyback. We have also lowered the end of the system memory pool to allow for a the backplane memory pool (BP_MEM_ADRS & BP_MEM_SIZE). This area is setup to be writethrough cacheable. It is mapped to the VMEbus using the 2nd set of regs on the MV167, so it can be mapped with bus snooping. Our boards are mapped at addresses 0x10000000 (proc0), 0x11000000 (proc1), 0x12000000 (proc2), etc. so the BP anchor is 0x10000600. VMEbus addresses 0x20000000 thru 0x3fffffff are transparently translated as non-cacheable. It has worked out well for us. Have fun, Paul Bade Johns Hopkins University / Applied Physics Lab prb@aplexus.jhuapl.edu ---------- X-Sun-Data-Type: c-file X-Sun-Data-Description: c-file X-Sun-Data-Name: mmu.c X-Sun-Content-Lines: 1753 static char resid[] = "$Id: mmu.c,v 1.4 1992/04/08 12:09:46 prb Exp $"; /**************************************************************************** * * * MMU Initialization * * * *--------------------------------------------------------------------------* * * * Module: mmu.c * * * *--------------------------------------------------------------------------* * * * Function: This module intializes the mmu and creates the translation * * tables required for operation. To make the mmu work with * * VxWorks required modification to the location that VxWorks * * runs at as well as specification of where the application * * module would be loaded. The following addresses are noteworthy* * * Note: The vxWorks files were modified to load the applic at the locations * shown below using loadModuleAt(). In the future the code will * be loaded via load script and then write protected. * * * CEP ADDRESSES * * * * Processor Description Block 0x400 * * ADP Input Data Pointer 0x500 * Backplane Anchor 0x600 * Vmebus Global Mem Pool 0x01000 * * MMU translation tables SYS_TTABLE * VxWorks text start VX_CODE_SPACE = 0x8000 * VxWorks data start VX_DATA_SPACE = 0x100000 * Application text start &end * Application data dynamically computed by ldFile.c * VMEbus Access 0x1000000 thru 0x3ffffff * * * * * * Note: The MV167 boards are mapped to the VMEbus at locations: * * * * Proc 0 => 0x10000000 * * Proc 1 => 0x11000000 * * Proc 2 => 0x12000000 * * Proc 3 => 0x13000000 * * * * For each processor, there is a window from the VMEbus at * * low memory and another window at high memory. For protection, * * middle memory is not visible from the VMEbus. * * * *--------------------------------------------------------------------------* * * * Resources: * * * * Hardware Resources: * * MMU * * * * * * Communication Resources: * * - NONE - * * * * * * Task Requirements: * * Task Name Priority * * --------- -------- * * PMMUTask 200 uses excessive CPU - must be LP * * * * * * Stack Requirements: * * Name Stack Size * * --------- ---------- * * PMMUTask 2048 * * * * * * Interrupt Vectors: * * Name Vector * * --------- ------ * * PMMU Config 56 * * PMMU Operation 57 * * PMMU Access Lvl Vio 58 * * NOTE: Exception handlers have not been written for the MMU for * * following reasons: * * * PMMU Config: this is completed during usrRoot and my past * * experience tells me that you can't attach a signal handler to * * root. * * * * PMMU Oper: Because logical=physical in this application and all * * tasks run at the supervisor level, the only types of operating * * exceptions possible are bus errors resulting from access * * with the result being suspending the task and reporting the 'bad' * * address - VxWorks already does this. * * Future modifications to the memory map and translation tables may * * benifit from an exception handler or two, but another way to check* * the translation tables in this environment is to run 'map167Bd', * * see below, which will check all 4 gigabytes of address space and * * print the results. * * * * * * Libraries Required: * * Library Name Description * * ------------ ----------- * * cmnd Library logs Commands to Cmnd Processor * * error Library Used to Report Errors that occur * * * *------------------------------------------------------------------------ */ /* $Log: mmu.c,v $ * Revision 1.4 1992/04/08 12:09:46 prb * CEC release 1.4 * * Revision 1.3 1992/02/28 14:43:38 prb * Made Burst Pool Non-cacheable, fixed Wasp Program space so it is copyback * * Revision 1.2 1992/02/26 13:25:10 prb * Added MMU writeProtect() for code space * * Revision 1.1 1992/02/17 14:47:19 prb * Initial revision * * */ /******************* * Module Includes * *******************/ #include "vxWorks.h" #include "taskLib.h" #include "mv167.h" #include "pccchip2.h" #include "memc040.h" #include "config.h" #include "cmnd_.h" #include "error_.h" IMPORT char end; /* automatically defined by the loader */ /******************************* * Module Defines * *******************************/ #define EIGHT_KBYTE 0x2000 #define PAGE_SIZE EIGHT_KBYTE #define MMU_SUPV 1 /* supervisor access */ #define MMU_USR 0 /* user/supervisor access */ #define MMU_RONL 1 /* WP = read only */ #define MMU_RDWR 0 /* WP = read/write */ #define MMU_EN_WRITETHROUGH 0 /* Cachable, WriteThrough */ #define MMU_EN_COPYBACK 1 /* Cachable, CopyBack */ #define MMU_INHIB_SERIAL 2 /* NonCachable, Serialized */ #define MMU_INHIB_NONSERIAL 3 /* NonCachable, NonSerialized */ #define MMU_OUR_POOL MMU_EN_WRITETHROUGH #define MMU_UDT_RESIDENT 2 /* Upper descriptor resident */ #define MMU_UDT_INVALID 0 /* Upper descriptor invalid */ #define MMU_PDT_RESIDENT 1 /* page resident */ #define MMU_PDT_INVALID 0 /* page invalid */ #define MMU_PDT_INDIRECT 2 /* page descriptor indirect */ #define MMU_GLOBAL 0 #define MMU_NON_GLOBAL 1 #ifdef CEP #define A_TBL_LEN 128 /* 128 entries x 4 bytes/entry */ #define MAX_LVL_A_TBLS 1 /* 1 Level A Table */ #define B_TBL_LEN 128 /* 128 entries x 4 bytes/entry */ #define MAX_LVL_B_TBLS 5 /* 2 Level B Tables */ #define PAGE_TBL_LEN 32 /* 32 entries x 4 bytes/entry(8KByte pages)*/ #else #define A_TBL_LEN 128 /* 128 entries x 4 bytes/entry */ #define MAX_LVL_A_TBLS 1 /* 1 Level A Table */ #define B_TBL_LEN 128 /* 128 entries x 4 bytes/entry */ #define MAX_LVL_B_TBLS 2 /* 2 Level B Tables */ #define PAGE_TBL_LEN 32 /* 32 entries x 4 bytes/entry(8KByte pages)*/ #endif #define MMU_TASK_STACK 2048 /* stack size of task that prints table */ #define MMU_TASK_PRIOR 254 /* priority of task that prints table */ typedef unsigned int U_INT; struct RP { unsigned addr :23, fixed :9; }; struct TC { unsigned short e :1; /* enable translation */ unsigned short ps :1; /* 1 => 8k page size, 0 => 4k page size */ unsigned short reserved :14; }; typedef struct { unsigned address : 8, /* logical address */ addrmask : 8, /* logical address mask */ e : 1, /* enable translation */ sfield : 2, /* supervisor/user mode matching */ zero : 3, u1 : 1, u0 : 1, zero1 : 1, cm : 2, /* cache mode */ zero2 : 2, wp : 1, /* 1=write protect; 0=r/w */ zero3 : 2; } TTR; /* Transparent translation register */ typedef struct { unsigned addr : 20, b : 1, /* buss error indicator */ g : 1, /* global */ u1 : 1, /* user page attribute 1 */ u0 : 1, /* user page attribute 0 */ s : 1, /* supervisor privilage only */ cm : 2, /* cache mode */ m : 1, /* modified */ zero : 1, wp : 1, /* write protected */ t : 1, /* located in transparent trans reg */ r : 1; /* resident */ } MMU_SR; typedef struct { unsigned int address : 23; /* address of level B table (16 byte aligned) */ unsigned int reserved : 5; unsigned int used : 1; unsigned int wp : 1; /* 1=write protect; 0=r/w */ unsigned int udt : 2; /* upper descriptor type */ /* 0,1 = invalid 2,3 = next descriptor resident (2 is preferred)*/ } LVL_A_TBL_ENTRY; /* level A table descriptor */ typedef struct { unsigned address : 25, /* address of page table (16 byte aligned) */ reserved : 3, used : 1, wp : 1, /* 1=write protect; 0=r/w */ udt : 2; /* upper descriptor type */ /* 0,1 = invalid 2,3 = next descriptor resident (2 is preferred)*/ } LVL_B_TBL_ENTRY; /* level B table descriptor */ typedef struct { unsigned address : 19, /* address of page table (16 byte aligned) */ ur : 2, global : 1, u1 : 1, u0 : 1, s : 1, /* supervisor privilage only */ cm : 2, /* cache mode */ m : 1, /* modified */ u : 1, /* used */ wp : 1, /* 1=write protect; 0=r/w */ pdt : 2; /* page descriptor type */ /* 0,3 = invalid 1 = page resident 1 = indirect descriptor */ } PAGE_ENTRY; /* 8K page descriptor */ /******************************* * Required External Functions * *******************************/ /******************************* * Local Functions * *******************************/ LOCAL void createADesc(LVL_A_TBL_ENTRY *tableAEntry, int wp, int valid, LVL_B_TBL_ENTRY *tableBEntry); LOCAL void createBDesc(LVL_B_TBL_ENTRY *tableBEntry, int wp, int valid, PAGE_ENTRY *tableCEntry); LOCAL void createCDesc(PAGE_ENTRY *pageEntry, int global, int sup, int cm, int wp, int valid, unsigned int pageAddr); LOCAL void printAttribs(char* firstAddr, char* lastAddr, MMU_SR attributes); /******************************* * Global Functions * *******************************/ void mmuInit(); void mapAdrs(U_INT,U_INT); void testmmu(); void map167Bd(); void turnMmuOff(); void showMmuRegs(); void writeProtect(); void unProtect(); /******************************* * Local Variables * *******************************/ LOCAL LVL_A_TBL_ENTRY *pA000T; LOCAL LVL_B_TBL_ENTRY *pB000T; LOCAL PAGE_ENTRY *pC000T; /* pointer to descriptors where vxWorks Code Starts */ LOCAL PAGE_ENTRY *pCDescCodeStart = (PAGE_ENTRY*)0; /* pointer to descriptors where application Code Starts */ LOCAL PAGE_ENTRY *pCDescapplicCodeStart = (PAGE_ENTRY*)0; LOCAL PAGE_ENTRY *pCDescTransTableStart = (PAGE_ENTRY*)0; LOCAL struct RP cpuRootPtr; LOCAL struct TC transCntlReg; LOCAL TTR instruTransTransReg0; LOCAL TTR instruTransTransReg1; LOCAL TTR dataTransTransReg0; LOCAL TTR dataTransTransReg1; LOCAL U_INT *testAddrOld; LOCAL U_INT *testAddrNew; LOCAL MMU_SR copyOfSrNew; LOCAL MMU_SR copyOfSrOld; LOCAL U_INT tempReg; /* used to force the reg to be read as D32, when */ /* setting up snoop control */ /******************************* * Global Variables * *******************************/ applicCodeStart = 0; applicCodeSize = 0; /******************************* * Module Routines * *******************************/ /*********************************************************************** * MMU Initialization * * * * Routine: mmuInit() * * * * Description: initializes the mmu translation table, then calls * * then turns on the mmu. * * * * Calling Seq: mmuInit() * * * * Return param: none * * * * Characteristics: If after changing this routine to remap any * * sections of memory, the mmu causes a halt * * immediately after turning it on, check here. The * * tables must be correct to get anything to work * ************************************************************************/ void mmuInit() { short i, j; unsigned int addr; /* address counter for table construction */ unsigned int *regPtr; static char *memTop; int lockKey; memTop = (char *)((4 << (*MEMC_MCR & 0x07)) << 20); applicCodeStart = (int)(((int)&end + PAGE_SIZE - 1) & (~((int)PAGE_SIZE - 1))); /* the tables are set up as hardcoded offsets from the base location; these values will need to change if the size of a table changes */ pA000T = (LVL_A_TBL_ENTRY *)SYS_TTABLE; pB000T = (LVL_B_TBL_ENTRY *)(pA000T + (MAX_LVL_A_TBLS * A_TBL_LEN)); pC000T = (PAGE_ENTRY *)(pB000T + (MAX_LVL_B_TBLS * B_TBL_LEN)); /* set up root pointer register value */ cpuRootPtr.addr = ((unsigned int) pA000T) >> 9; /* table addr >> 9 */ cpuRootPtr.fixed = 0; /* unused */ /* set up instruction transparent translation reg 0 */ instruTransTransReg0.address = 0x00; /* from address 0x00000000 */ instruTransTransReg0.addrmask = 0xff; /* to address 0xffffffff */ instruTransTransReg0.e = 1; /* enable transparent transl */ instruTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ instruTransTransReg0.zero = 0; instruTransTransReg0.u1 = 0; instruTransTransReg0.u0 = 0; instruTransTransReg0.zero1 = 0; instruTransTransReg0.cm = MMU_EN_WRITETHROUGH; instruTransTransReg0.zero2 = 0; instruTransTransReg0.wp = MMU_RDWR; instruTransTransReg0.zero3 = 0; /* set up instruction transparent translation reg 1 */ instruTransTransReg1.e = 0; /* disable transparent trans r1 */ /* set up data transparent translation reg 0 */ dataTransTransReg0.address = 0x10; /* from address 0x10000000 */ dataTransTransReg0.addrmask = 0x0f; /* to address 0x1fffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; /* set up data transparent translation reg 1 */ dataTransTransReg1.address = 0x20; /* from address 0x20000000 */ dataTransTransReg1.addrmask = 0x1f; /* to address 0x3fffffff */ dataTransTransReg1.e = 1; /* enable transparent transl */ dataTransTransReg1.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg1.zero = 0; dataTransTransReg1.u1 = 0; dataTransTransReg1.u0 = 0; dataTransTransReg1.zero1 = 0; dataTransTransReg1.cm = MMU_INHIB_SERIAL; dataTransTransReg1.zero2 = 0; dataTransTransReg1.wp = MMU_RDWR; dataTransTransReg1.zero3 = 0; /* set up translation register value */ transCntlReg.e = 0x1; /* enable translation */ transCntlReg.ps = 0x1; /* 8kByte pages */ transCntlReg.reserved = 0; /* reserved */ /* creating the symbol table ... */ printf ("Trans Table Addrs... \n"); printf ("A tables begin at %08x\n",pA000T); printf ("B tables begin at %08x\n",pB000T); printf ("C tables begin at %08x\n",pC000T); /* create tables... */ /******************************************/ /* create A table entry for lower 32MByte */ /******************************************/ createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); #ifdef DEBUG_PRINT pA000T--; printf("A Desc at 0x%x = 0x%x\n", pA000T, *((unsigned int*)pA000T)); pA000T++; #endif /*************************************************/ /* create B and C table entries for lower 1MByte */ /*************************************************/ for (addr = 0; addr < 0x100000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { if (addr >= VX_CODE_SPACE) { /* Map Application Code As CopyBack */ createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); } else if (addr >= SYS_TTABLE) { /* Map Translation Tables As Read Only */ createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RONL,MMU_PDT_RESIDENT,addr); } else { /* Map BackPlane Anchor and CEP_POOL As Inhibited Serial */ createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); } addr += EIGHT_KBYTE; if(addr == VX_CODE_SPACE) { /**************************************************************/ /* Save Pointers to the Descriptors where vxWorks code starts */ /* so we can write protect later */ /**************************************************************/ pCDescCodeStart = pC000T; } if(addr == applicCodeStart) { /*************************************************************/ /* Save Pointers to the Descriptors where applic code starts */ /* so we can write protect later */ /*************************************************************/ pCDescapplicCodeStart = pC000T; } } } /* create B and C table entries for rest of on-board memory */ for (addr = 0x100000; addr < memTop; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { if((sysProcNumGet() == 0) && (BP_MEM_ADRS != NONE)) { #ifdef INCLUDE_BURST_POOL if(addr< (memTop - BURST_POOL_SIZE - BP_MEM_SIZE)) createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); else createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); #else if(addr< (memTop - ANTARES_POOL_SIZE - BP_MEM_SIZE)) createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); else createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_WRITETHROUGH,MMU_RDWR,MMU_PDT_RESIDENT,addr); #endif } else { #ifdef INCLUDE_BURST_POOL if(addr < (memTop - BURST_POOL_SIZE)) createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); else createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); #else if(addr < (memTop - ANTARES_POOL_SIZE)) createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); else createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_WRITETHROUGH,MMU_RDWR,MMU_PDT_RESIDENT,addr); #endif } addr += EIGHT_KBYTE; if(addr == applicCodeStart) { /*************************************************************/ /* Save Pointers to the Descriptors where applic code starts */ /* so we can write protect later */ /*************************************************************/ pCDescapplicCodeStart = pC000T; } } } #define TEMPORARY #ifdef CEP /* Create none resident B table entries n lower 16 MB if needed */ /* none resident (i.e. handled by transparent translation) */ for (addr = (unsigned int)memTop; addr < 0x1000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /* Create resident B table entries 16 thru 32 Mbytes (Main Cntlr VSB) */ for (addr = 0x1000000; addr < 0x2000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /*******************************************/ /* create A table entry for second 32MByte */ /*******************************************/ createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */ for (addr = 0x2000000; addr < 0x4000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /*******************************************/ /* create A table entry for third 32MByte */ /*******************************************/ createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */ for (addr = 0x4000000; addr < 0x6000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /*******************************************/ /* create A table entry for fourth 32MByte */ /*******************************************/ createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); /* Create resident B table entries 32 thru 64 Mbytes (IO & UG Cntlrs VSB) */ for (addr = 0x6000000; addr < 0x8000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /********************************************/ /* create A table entries for middle memory */ /********************************************/ for (addr = 0x8000000; addr < 0xfe000000; ) { createADesc(pA000T++,MMU_RDWR,MMU_UDT_INVALID,(LVL_B_TBL_ENTRY*)0); addr += (128 * 32 * EIGHT_KBYTE); } #else /* Create none resident B table entries for memTop thru 32 Mbytes */ /* none resident (i.e. handled by transparent translation) */ for (addr = (unsigned int)memTop; addr < 0x2000000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); addr += (32 * EIGHT_KBYTE); } /********************************************/ /* create A table entries for middle memory */ /********************************************/ for (addr = 0x2000000; addr < 0xfe000000; ) { createADesc(pA000T++,MMU_RDWR,MMU_UDT_INVALID,(LVL_B_TBL_ENTRY*)0); addr += (128 * 32 * EIGHT_KBYTE); } #endif /******************************************/ /* create A table entry for upper 32MByte */ /******************************************/ createADesc(pA000T++,MMU_RDWR,MMU_UDT_RESIDENT,pB000T); /* create B and C table entries for A24 area 0xffe00000 to 0xffbfffff */ for (addr = 0xfe000000; addr < 0xfe040000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /* Create none resident (96) B table entries for 0xfe000000 to 0xff7fffff */ /* none resident (i.e. handled by transparent translation) */ for (addr = 0xfe040000; addr < 0xff800000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); addr += (32 * EIGHT_KBYTE); } /* create B and C table entries for EPROM area 0xff800000 to 0xffbfffff */ for (addr = 0xff800000; addr < 0xffc00000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } /* Reserved area */ /* Create none resident (8) B table entries for 0xffc00000 to 0xffdfffff */ for (addr = 0xffc00000; addr < 0xffe00000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); addr += (32 * EIGHT_KBYTE); } /*Create (1) B and C table entries for SRAM area 0xffe00000 to 0xffe1ffff */ for (addr = 0xffe00000; addr < 0xffe40000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 16; j++) /* SRAM here */ { createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } for ( j = 0; j < 16; j++) /* mirror of SRAM here */ { createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_INVALID,addr); addr += EIGHT_KBYTE; } } /* More repeated SRAM area */ /* Create none resident (3) B table entries for 0xffe40000 to 0xffefffff */ for (addr = 0xffe40000; addr < 0xfff00000; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_INVALID,(PAGE_ENTRY*)0); addr += (32 * EIGHT_KBYTE); } /* create B and C table entrs for Local I/O and VMEbus Short I/O area */ /* (0xfff00000 to 0xfffeffff) and (0xffff0000 to 0xffffffff) */ for (addr = 0xfff00000; addr != 0x0; ) { createBDesc(pB000T++,MMU_RDWR,MMU_UDT_RESIDENT,pC000T); for ( j = 0; j < 32; j++) { createCDesc(pC000T++,MMU_GLOBAL,MMU_USR,MMU_INHIB_SERIAL,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } } printf("Last table entry address = %x\n", ((unsigned int)pC000T) - 1); printf("Chip..."); lockKey = intLock(); /* Obtain VMEbus while changing translation stuff */ tempReg = *VMECHIP2_DMACR1; /* |= does not work properly on 32 bit regs */ tempReg |= DMACR1_DWB; *VMECHIP2_DMACR1 = tempReg; tempReg = 0; while (!(tempReg & DMACR1_DHB)) /* wait til we have the bus */ tempReg = *VMECHIP2_DMACR1; #ifdef NEW_ASSEMBLER /* push and invalidate caches */ /* asm ("cpusha bc"); */ asm (".word 0xf4ff"); /* Disable Cache */ asm ("movel #0, a0"); asm ("movec a0, cacr"); /* Disable Translation */ asm ("movel #0, a0"); asm ("movec a0, tc"); /* Set up Translation Tree Root Pointers */ asm ("movel _cpuRootPtr, a0"); asm ("movec a0, urp"); asm (".word 0xf518"); asm ("movec a0, srp"); asm (".word 0xf518"); /* flush address translation caches */ /* asm("pflusha"); */ asm (".word 0xf518"); /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm ("movec a0, tc"); /* Set up Transparent Translation Registers */ asm ("movel _instruTransTransReg0, a0"); asm ("movec a0, itt0"); asm (".word 0xf518"); asm ("movel _instruTransTransReg1, a0"); asm ("movec a0, itt1"); asm (".word 0xf518"); asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); asm ("movel _dataTransTransReg1, a0"); asm ("movec a0, dtt1"); asm (".word 0xf518"); #else /* push and invalidate caches */ asm (".word 0xf4ff"); /* cpusha bc */ /* Disable Cache */ asm ("movel #0, a0"); asm ("movec a0, cacr"); /* Disable Translation */ asm ("movel #0, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ /* Set up Translation Tree Root Pointers */ asm ("movel _cpuRootPtr, a0"); asm (".word 0x4e7b,0x8806"); /* movec a0, urp */ asm (".word 0xf518"); asm (".word 0x4e7b,0x8807"); /* movec a0, srp */ asm (".word 0xf518"); /* flush address translation caches */ asm (".word 0xf518"); /* pflusha */ /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ /* Set up Transparent Translation Registers */ asm ("movel _instruTransTransReg0, a0"); asm (".word 0x4e7b,0x8004"); /* movec a0, itt0 */ asm (".word 0xf518"); asm ("movel _instruTransTransReg1, a0"); asm (".word 0x4e7b,0x8005"); /* movec a0, itt1 */ asm (".word 0xf518"); asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); asm ("movel _dataTransTransReg1, a0"); asm (".word 0x4e7b,0x8007"); /* movec a0, dtt1 */ asm (".word 0xf518"); #endif /* Turn On Snoop Control for PCC Chip2 Serial Port */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ *PCC2_SCC_RICR |= SCC_RICR_SINK_DATA; /* |= works for 8 bit reg */ /****************************************************/ /****************************************************/ /* Instead of using bus snooping for the sockets, */ /* one could create a seperate memory pool */ /* LN_POOL_ADRS and LN_POOL_SIZE are defined in */ /* the config.h for the target. */ /* a LN_POO_ADRS == NONE (-1) means use the */ /* global memory pool and malloc. */ /* */ /****************************************************/ /****************************************************/ /* Turn On Snoop Control for PCC Chip2 Lanc */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ *PCC2_LANC_BEICR |= LANC_BEICR_SINK_DATA; /* |= works for 8 bit reg */ #if FALSE #endif /* Check Rev of memc040 chip */ /* *MEMC_RCR |= MEMC_RCR_SWAIT; Needed for errata when bus snooping */ if(*MEMC_REVISION == 0x00) /* MEMC_REVISION can be read as a byte */ *MEMC_RCR |= MEMC_RCR_SWAIT; /* |= works for 8 bit reg */ /* Turn On Snoop Control when VME Slave */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ tempReg = *VMECHIP2_VSAMSR; /* prb */ #ifndef INCLUDE_BURST_POOL tempReg |= VSAMSR2_SNP_WSD; /* snoop upperwindow for bp_network/antares*/ #endif /* turn off snooping in this lower window since nonCacheable */ tempReg &= ~(VSAMSR1_SNP_WSD | VSAMSR1_SNP_WI); *VMECHIP2_VSAMSR = tempReg; /* Turn On Snoop Control for VME DMA */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ tempReg = *VMECHIP2_DMACR2; tempReg |= DMACR2_SINK_DATA; *VMECHIP2_DMACR2 = tempReg; /* WARNING SCSI Snoop Control not set up */ #ifdef NEW_ASSEMBLER /* Enable Cache */ asm ("movel #0x80008000, a0"); asm ("movec a0, cacr"); #else /* Enable Cache */ asm ("movel #0x80008000, a0"); asm (".word 0x4e7b,0x8002"); /* movec a0, cacr */ #endif tempReg = *VMECHIP2_DMACR1; /* |= does not work properly on 32 bit regs */ tempReg &= ~DMACR1_DWB; *VMECHIP2_DMACR1 = tempReg; intUnlock(lockKey); printf(" Done\n"); #ifdef INCLUDE_ANTARES printf(" ANTARES_POOL_ADRS = %x\n",ANTARES_POOL_ADRS ); printf(" ANTARES_POOL_SIZE = %x\n",ANTARES_POOL_SIZE ); #else printf(" ANTARES_POOL Not_included\n"); #endif #ifdef INCLUDE_BURST_POOL printf(" ADP BURST_POOL_ADRS = %x\n",BURST_POOL_ADRS ); printf(" ADP BURST_POOL_SIZE = %x\n",BURST_POOL_SIZE ); #endif if (sysProcNumGet() == 0) { printf(" BP_MEM_ADRS = %x\n",BP_MEM_ADRS ); printf(" BP_MEM_SIZE = %x\n",BP_MEM_SIZE ); } else printf(" BP_MEM_OFF_BOARD\n"); /* register mmu diagnostics to Cmnd Processor */ Log_Cmnd(NO_PASSWORD, "map167Bd", "Display the MMU memory map", map167Bd, 1); } int temp; void showMmuRegs() { #ifdef NEW_ASSEMBLER asm ("movec tc, a0"); asm ("movel a0,_temp"); printf("tc = %x\n",temp); asm ("movec cacr, a0"); asm ("movel a0,_temp"); printf("cacr = %x\n",temp); asm ("movec urp, a0"); asm ("movel a0,_temp"); printf("urp = %x\n",temp); asm ("movec srp, a0"); asm ("movel a0,_temp"); printf("srp = %x\n",temp); asm ("movec itt0, a0"); asm ("movel a0,_temp"); printf("itt0 = %x\n",temp); asm ("movec itt1, a0"); asm ("movel a0,_temp"); printf("itt1 = %x\n",temp); asm ("movec dtt0, a0"); asm ("movel a0,_temp"); printf("dtt0 = %x\n",temp); asm ("movec dtt1, a0"); asm ("movel a0,_temp"); printf("dtt1 = %x\n",temp); #else asm (".word 0x4e7a,0x8003"); /* movec tc,a0 */ asm ("movel a0,_temp"); printf("tc = %x\n",temp); asm (".word 0x4e7a,0x8002"); /* movec cacr,a0 */ asm ("movel a0,_temp"); printf("cacr = %x\n",temp); asm (".word 0x4e7a,0x8806"); /* movec urp,a0 */ asm ("movel a0,_temp"); printf("urp = %x\n",temp); asm (".word 0x4e7a,0x8807"); /* movec srp,a0 */ asm ("movel a0,_temp"); printf("srp = %x\n",temp); asm (".word 0x4e7a,0x8004"); /* movec itt0,a0 */ asm ("movel a0,_temp"); printf("itt0 = %x\n",temp); asm (".word 0x4e7a,0x8005"); /* movec itt1,a0 */ asm ("movel a0,_temp"); printf("itt1 = %x\n",temp); asm (".word 0x4e7a,0x8006"); /* movec dtt0,a0 */ asm ("movel a0,_temp"); printf("dtt0 = %x\n",temp); asm (".word 0x4e7a,0x8007"); /* movec dtt1,a0 */ asm ("movel a0,_temp"); printf("dtt1 = %x\n",temp); #endif } /*********************************************************************** * Write Protect the Application and VxWorks Code Space * * * * Routine: writeProtect() * * * * Description: Changes the page table descriptors to write * * protect the code space. * * * * Calling Seq: writeProtect() * * * * Return param: none * * * ************************************************************************/ int CACR; void writeProtect() { short j; unsigned int addr; /* address counter for table construction */ /* Save Cache Control Reg */ #ifdef NEW_ASSEMBLER asm ("movec cacr, a0"); asm ("movel a0,_CACR"); #else asm (".word 0x4e7a,0x8002"); /* movec cacr,a0 */ asm ("movel a0,_CACR"); #endif turnCacheOff(); /* We also need to disable page translation so we can write to tables */ /* set up data transparent translation reg 0 to translate everything */ dataTransTransReg0.address = 0x00; /* from address 0x00000000 */ dataTransTransReg0.addrmask = 0xff; /* to address 0xffffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; #ifdef NEW_ASSEMBLER /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm ("movec a0, tc"); #else /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ #endif /*****************************************/ /* change C table entries for code space */ /*****************************************/ pC000T = pCDescCodeStart; for (addr = VX_CODE_SPACE; addr < VX_DATA_SPACE; ) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } pC000T = pCDescapplicCodeStart; for (addr = applicCodeStart; addr < (applicCodeStart + applicCodeSize); ) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RONL,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } /* restore data transparent translation reg 0 */ dataTransTransReg0.address = 0x10; /* from address 0x10000000 */ dataTransTransReg0.addrmask = 0x0f; /* to address 0x1fffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; #ifdef NEW_ASSEMBLER /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm ("movec a0, tc"); #else /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ #endif /* Restore Cache Control Reg */ #ifdef NEW_ASSEMBLER asm ("movel _CACR, a0"); asm ("movec a0, cacr"); #else asm ("movel _CACR, a0"); asm (".word 0x4e7b,0x8002"); /* movec a0, cacr */ #endif } /*********************************************************************** * Don't Write Protect the Application and VxWorks Code Space * * * * Routine: unProtect() * * * * Description: Changes the page table descriptors to no longer * * write protect the code space. * * * * Calling Seq: unProtect() * * * * Return param: none * * * ************************************************************************/ void unProtect() { short j; unsigned int addr; /* address counter for table construction */ /* Save Cache Control Reg */ #ifdef NEW_ASSEMBLER asm ("movec cacr, a0"); asm ("movel a0,_CACR"); #else asm (".word 0x4e7a,0x8002"); /* movec cacr,a0 */ asm ("movel a0,_CACR"); #endif turnCacheOff(); /* We also need to disable page translation so we can write to tables */ /* set up data transparent translation reg 0 to translate everything */ dataTransTransReg0.address = 0x00; /* from address 0x00000000 */ dataTransTransReg0.addrmask = 0xff; /* to address 0xffffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; #ifdef NEW_ASSEMBLER /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm ("movec a0, tc"); #else /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ #endif /***********************************************/ /* change B and C table entries for code space */ /***********************************************/ pC000T = pCDescCodeStart; for (addr = VX_CODE_SPACE; addr < VX_DATA_SPACE; ) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } pC000T = pCDescapplicCodeStart; for (addr = applicCodeStart; addr < (applicCodeStart + applicCodeSize); ) { createCDesc(pC000T++,MMU_NON_GLOBAL,MMU_USR,MMU_EN_COPYBACK,MMU_RDWR,MMU_PDT_RESIDENT,addr); addr += EIGHT_KBYTE; } /* restore data transparent translation reg 0 */ dataTransTransReg0.address = 0x10; /* from address 0x10000000 */ dataTransTransReg0.addrmask = 0x0f; /* to address 0x1fffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ /* restore data transparent translation reg 0 */ dataTransTransReg0.address = 0x10; /* from address 0x10000000 */ dataTransTransReg0.addrmask = 0x0f; /* to address 0x1fffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; #ifdef NEW_ASSEMBLER /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm ("movec a0, tc"); #else /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); /* Enable Translation */ asm ("movel #0, a0"); asm ("movew _transCntlReg, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ #endif /* Restore Cache Control Reg */ #ifdef NEW_ASSEMBLER asm ("movel _CACR, a0"); asm ("movec a0, cacr"); #else asm ("movel _CACR, a0"); asm (".word 0x4e7b,0x8002"); /* movec a0, cacr */ #endif } /*********************************************************************** * TURN THE CACHE OFF FOR DEBUGGING * * * * Routine: turnCacheOff() * * * * Description: This routines turns the cache off * * * * Calling Seq: turnCacheOff() * * * * Return param: none * * * * Characteristics: * * ************************************************************************/ void turnCacheOff() { #ifdef NEW_ASSEMBLER /* push and invalidate caches */ asm (".word 0xf4ff"); /* asm ("cpusha bc"); */ /* Disable Cache */ asm ("movel #0, a0"); asm ("movec a0, cacr"); #else /* push and invalidate caches */ asm (".word 0xf4ff"); /* Disable Cache */ asm ("movel #0, a0"); asm (".word 0x4e7b,0x8002"); /* movec a0, cacr */ #endif } /*********************************************************************** * TURN THE MMU OFF FOR REBOOT * * * * Routine: turnMmuOff() * * * * Description: This routines turns the mmu of by writing to the * * tc register and clearing the e bit * * * * Calling Seq: turnMmuOff() * * * * Return param: none * * * * Characteristics: * * ************************************************************************/ void turnMmuOff() { /* push and invalidate caches */ turnCacheOff(); /* set up data transparent translation reg 0 */ dataTransTransReg0.address = 0x00; /* from address 0x00000000 */ dataTransTransReg0.addrmask = 0xff; /* to address 0xffffffff */ dataTransTransReg0.e = 1; /* enable transparent transl */ dataTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ dataTransTransReg0.zero = 0; dataTransTransReg0.u1 = 0; dataTransTransReg0.u0 = 0; dataTransTransReg0.zero1 = 0; dataTransTransReg0.cm = MMU_INHIB_SERIAL; dataTransTransReg0.zero2 = 0; dataTransTransReg0.wp = MMU_RDWR; dataTransTransReg0.zero3 = 0; /* set up instruction transparent translation reg 0 */ instruTransTransReg0.address = 0x00; /* from address 0x00000000 */ instruTransTransReg0.addrmask = 0xff; /* to address 0xffffffff */ instruTransTransReg0.e = 1; /* enable transparent transl */ instruTransTransReg0.sfield = 0x3; /* ignore FC2 matching */ instruTransTransReg0.zero = 0; instruTransTransReg0.u1 = 0; instruTransTransReg0.u0 = 0; instruTransTransReg0.zero1 = 0; instruTransTransReg0.cm = MMU_INHIB_SERIAL; instruTransTransReg0.zero2 = 0; instruTransTransReg0.wp = MMU_RDWR; instruTransTransReg0.zero3 = 0; #ifdef NEW_ASSEMBLER /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm ("movec a0, dtt0"); asm (".word 0xf518"); asm ("movec a0, dtt1"); asm (".word 0xf518"); asm ("movel _instruTransTransReg0, a0"); asm ("movec a0, itt0"); asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm ("movec a0, tc"); #else /* Set up Transparent Translation Registers */ asm ("movel _dataTransTransReg0, a0"); asm (".word 0x4e7b,0x8006"); /* movec a0, dtt0 */ asm (".word 0xf518"); asm (".word 0x4e7b,0x8007"); /* movec a0, dtt1 */ asm (".word 0xf518"); asm ("movel _instruTransTransReg0, a0"); asm (".word 0x4e7b,0x8004"); /* movec a0, itt0 */ asm (".word 0xf518"); /* Disable Page Table Translation */ asm ("movel #0, a0"); asm (".word 0x4e7b,0x8003"); /* movec a0, tc */ #endif #if FALSE /* Turn Off Snoop Control for PCC Chip2 Serial Port */ *PCC2_SCC_RICR &= ~SCC_RICR_SINK_DATA; /* Turn Off Snoop Control for PCC Chip2 Lanc */ *PCC2_LANC_BEICR &= ~LANC_BEICR_SINK_DATA; /* Turn Off Snoop Control when VME Slave */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ /* Obtain VMEbus while changing snoop */ tempReg = *VMECHIP2_DMACR1; /* |= does not work properly on 32 bit regs */ tempReg |= DMACR1_DWB; *VMECHIP2_DMACR1 = tempReg; tempReg = 0; while (!(tempReg & DMACR1_DHB)) /* wait til we have the bus */ tempReg = *VMECHIP2_DMACR1; tempReg = *VMECHIP2_VSAMSR; tempReg &= ~VSAMSR2_SNP_WSD; tempReg &= ~VSAMSR1_SNP_WSD; *VMECHIP2_VSAMSR = tempReg; *VMECHIP2_DMACR1 &= !DMACR1_DWB; /* Release VMEbus */ /* Turn Off Snoop Control for VME DMA */ /* snoop option -> update snooped cache */ /* NOTE errata says that inval. cache does not work properly for reads */ tempReg = *VMECHIP2_DMACR2; tempReg &= ~DMACR2_SINK_DATA; *VMECHIP2_DMACR2 = tempReg; #endif } /*********************************************************************** * MAP ALL ADDRESS SPACE FOR 167 BOARD * * * * Routine: map167Bd() * * * * Description: This routines prints a map of the entire 4 Gig * address range as mapped in the mmu. A PTESTR * * instruction is executed on every location and the * * location attributes are determined in the * * translation table. This routine uses the routine * * mapAdrs. * * * * Calling Seq: map167Bd() * * * * Return param: none * * * * Characteristics: A task is actually spawnded to generate the table * * so that the priority of the routine will be lower * * than the shell priority. * * * * Map format: * * XXXXXXXX->XXXXXXXX: Read-only Enabled User * * * ************************************************************************/ void map167Bd() { taskSpawn("PMMUTask",MMU_TASK_PRIOR,VX_DEALLOC_STACK,MMU_TASK_STACK, (FUNCPTR) mapAdrs,0,0xFFFFFFFF); } void mapAdrs(U_INT start, U_INT stop) { /* variable declaration */ short i; /* loop variable */ U_INT addr; /* address to be tested */ U_INT addrStep; /* address increment */ short cacheStat,rdwrStat,accessStat,residentStat; /*Current attributes */ addrStep = EIGHT_KBYTE; testAddrOld = testAddrNew = (U_INT *)0; printf("\n"); printf("This routine takes a short time to run - BE PATIENT\n\n"); printf("ADDRESS RANGE PERMISSIONS CACHE MODE\n"); printf("-----------------------------------------------------------------\n"); /* start loop with first address to be tested */ for (addr=start; addr= (U_INT *)(stop-addrStep)) { printAttribs(testAddrOld, (char *)testAddrNew +addrStep -1, copyOfSrOld); break; } else { /* if transition point and not 1st entry */ if((copyOfSrOld.r != copyOfSrNew.r) || ((copyOfSrOld.r == TRUE) && (copyOfSrOld.cm != copyOfSrNew.cm || copyOfSrOld.wp != copyOfSrNew.wp|| copyOfSrOld.s != copyOfSrNew.s))) { /* print old attributes */ printAttribs(testAddrOld, (char *)testAddrNew -1, copyOfSrOld); copyOfSrOld = copyOfSrNew; testAddrOld = testAddrNew; } } } } /*********************************************************************** * PRINT ATTRIBUTES * * * Routine: printAttribs() * * * * Description: This routine decodes the translation table * * descriptor given by the address param. The encoding* * is the same for page and early term descriptors * * * * Calling Seq: printAttribs(address, type of printout) * * * * Return param: none * * * * Characteristics: ************************************************************************/ LOCAL void printAttribs(char* firstAddr, char* lastAddr, MMU_SR attributes) { unsigned int ttaddr1; unsigned int ttaddr2; unsigned int temp; if((attributes.r) && (!attributes.t))/* if resident */ { printf("%08x->%08x ",firstAddr, lastAddr); if(attributes.wp) printf (" Read-Only "); else printf (" Read-Write "); if(attributes.cm == MMU_EN_WRITETHROUGH) printf (" Writethrough "); else if(attributes.cm == MMU_EN_COPYBACK) printf (" CopyBack "); else if(attributes.cm == MMU_INHIB_SERIAL) printf (" Off/Serial "); else printf (" Off/NotSerial"); if(attributes.s) printf (" Supv Only\n"); else printf (" User/Supv\n"); } else if ((attributes.r) && (attributes.t)) { #ifdef NEW_ASSEMBLER asm ("movec dtt0, a0"); asm ("movel a0, _dataTransTransReg0"); asm ("movec dtt1, a0"); asm ("movel a0, _dataTransTransReg1"); #else asm (".word 0x4e7a,0x8006"); /* movec dtt0,a0 */ asm ("movel a0, _dataTransTransReg0"); asm (".word 0x4e7a,0x8007"); /* movec dtt1,a0 */ asm ("movel a0, _dataTransTransReg1"); #endif if(dataTransTransReg0.e) { ttaddr1 = (dataTransTransReg0.address & ~dataTransTransReg0.addrmask) <<24; ttaddr2 = ((dataTransTransReg0.address | dataTransTransReg0.addrmask) <<24) | 0xffffff; if((ttaddr1 >= firstAddr) && (ttaddr1 <= lastAddr)) { printf("%08x->%08x ",ttaddr1, ttaddr2); if(dataTransTransReg0.wp) printf (" Read-Only "); else printf (" Read-Write "); if(dataTransTransReg0.cm == MMU_EN_WRITETHROUGH) printf (" Writethrough "); else if(dataTransTransReg0.cm == MMU_EN_COPYBACK) printf (" CopyBack "); else if(dataTransTransReg0.cm == MMU_INHIB_SERIAL) printf (" Off/Serial "); else printf (" Off/NotSerial"); if(dataTransTransReg0.sfield == 00) printf (" User Only\n"); else if(dataTransTransReg0.sfield == 01) printf (" Supv Only\n"); else printf (" User/Supv\n"); for(temp = (dataTransTransReg0.addrmask & 0xff); (temp & 1); temp = temp >> 1); if(temp != 0) printf("WARNING: Above Transparent Translation has holes in it \n"); } } if(dataTransTransReg1.e) { ttaddr1 = (dataTransTransReg1.address & ~dataTransTransReg1.addrmask) <<24; ttaddr2 = ((dataTransTransReg1.address | dataTransTransReg1.addrmask) <<24) | 0xffffff; if((ttaddr1 >= firstAddr) && (ttaddr1 <= lastAddr)) { printf("%08x->%08x ",ttaddr1, ttaddr2); if(dataTransTransReg1.wp) printf (" Read-Only "); else printf (" Read-Write "); if(dataTransTransReg1.cm == MMU_EN_WRITETHROUGH) printf (" Writethrough "); else if(dataTransTransReg1.cm == MMU_EN_COPYBACK) printf (" CopyBack "); else if(dataTransTransReg1.cm == MMU_INHIB_SERIAL) printf (" Off/Serial "); else printf (" Off/NotSerial"); if(dataTransTransReg1.sfield == 00) printf (" User Only\n"); else if(dataTransTransReg1.sfield == 01) printf (" Supv Only\n"); else printf (" User/Supv\n"); for(temp = (dataTransTransReg1.addrmask & 0xff); (temp & 1); temp = temp >> 1); if(temp != 0) printf("WARNING: Above Transparent Translation has holes in it \n"); } } } else { printf("%08x->%08x ",firstAddr, lastAddr); printf (" Not Resident\n"); } } /*********************************************************************** * CREATE DESCRIPTOR * * * Routine: createDesc() * * * * Description: This routine creates a generic translation table * * descriptor according to the format specified for * * a long format descriptor in the 68030 manual. * * * * Calling Seq: createDesc(...) * * * * Return param: none * * * * Characteristics: * * Since this is a '1 routine fits all' routine, not * * all of the parameters are meaningful for every * * descriptor type. * * * ************************************************************************/ int prin = 0; LOCAL void createADesc(LVL_A_TBL_ENTRY *tableAEntry, int wp, int valid, LVL_B_TBL_ENTRY *tableBEntry) { tableAEntry ->address = ((unsigned int)tableBEntry) >> 9; tableAEntry ->reserved = 0; tableAEntry ->used = 0; tableAEntry ->wp = wp; /* set write protect */ tableAEntry ->udt = valid; /* set descriptor type */ return; } LOCAL void createBDesc(LVL_B_TBL_ENTRY *tableBEntry, int wp, int valid, PAGE_ENTRY *tableCEntry) { tableBEntry ->address = ((unsigned int)tableCEntry) >> 7; tableBEntry ->reserved = 0; tableBEntry ->used = 0; tableBEntry ->wp = wp; /* set write protect */ tableBEntry ->udt = valid; /* set descriptor type */ return; } LOCAL void createCDesc(PAGE_ENTRY *pageEntry, int global, int sup, int cm, int wp, int valid, unsigned int pageAddr) { pageEntry ->address = ((unsigned int)pageAddr) >> 13; pageEntry ->ur = 0; pageEntry ->global = global; pageEntry ->u1 = 0; pageEntry ->u0 = 0; pageEntry ->s = sup; /* supervisor/user */ pageEntry ->cm = cm; /* cache mode */ pageEntry ->m = 0; /* set modified field */ pageEntry ->u = 0; /* set used field */ pageEntry ->wp = wp; /* set write protect */ pageEntry ->pdt = valid; /* set descriptor type */ return; } From daemon@vxw.ee.lbl.gov Wed Apr 29 04:00:29 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Apr 29 04:00:37 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 29 04:00:22 PDT 1992 Subject: Re: distributed vxWorks! Subject: Re: chomped on by a compiler optimization Subject: Modifying interrupt stack placement on VxWorks 5.0.3 Subject: Re: chomped on by a compiler optimization ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: distributed vxWorks! Date: 28 Apr 1992 13:47:33 GMT From: lewis@bevsun.bev.lbl.gov (Steve Lewis) Organization: Lawrence Berkeley Laboratory, California Message-ID: <22995@dog.ee.lbl.gov> References: <9204271255.AA03190@efftoo.boeing.com> In article <9204271255.AA03190@efftoo.boeing.com> crispen <@ada3.ca.boeing.com:crispen@efftoo.boeing.com> writes: >... >Heck, I'll settle for multi-processor semaphores. No, wait a minute, >I'll settle for multi-processor semaphores that only work on the most >popular CPU boards. Or how about MPSs that work on one or two boards.... >... Bob, I agree whole-heartedly. At every Users' group meeting I have attended, I have spoken out for such a facility. I have even pointed out that a competitor, SCG, with their pSOS+m product, has offered this functionality (and more) since about 1986--they really offer a good multi-processor environment. (They were always weak in TCP/IP support, however.) WRS has insisted that sockets across the backplane are sufficient...not clear on the concept! - -- Steve Lewis, Group Leader SALewis@LBL.gov Computer Controls Mail Stop 64-121 Lawrence Berkeley Laboratory Tel: 510/486-7702 Berkeley, CA 94720 Fax: 510/486-5788 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: chomped on by a compiler optimization Date: Tue, 28 Apr 1992 14:49:43 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: References: Sender: news@nic.unh.edu (USENET News System) Wow, neat. When I figured out how to declare the register as volatile, (the - -traditional option had been getting in my way) the code was optimized to something pretty slick! It noticed that I was and-ing a byte with 0x80 to see if the top bit was set; so it changed the code to just check to see if the byte was negative. That's a pretty obscure optimization! Here is another place where I need to have a keyword like "volatile", but I don't think it exists: On this hardware I am using, there is an 8 bit index register i that you vary to change which slot three other registers (r, g, and b) point to. In other words, to set g[123], you first set i to 123, and then write to the g register. Am I mistaken, or would the optimizer notice that I'm writing to the same spot repeatedly in a loop, nuke the loop, and reduce it to the last values assigned? What would be the appropriate way to protect this from happening, without completely turning the optimizer off? Thanks, Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Modifying interrupt stack placement on VxWorks 5.0.3 Date: Tue, 28 Apr 1992 15:14:51 GMT From: srangachar@hns.com (Suresh Rangachar) Organization: Hughes Network Systems Inc. Message-ID: <1992Apr28.151451.12131@hns.com> Sender: news@hns.com (USENET news system) Hi, We need to locate the interrupt stack into a different static RAM area after initialization. (the OS gets interrupt stack location from system memory pool). I tried to post a software interrupt and modify sp in the interrupt handler and that did not seem to fix it. ANy suggestions ? suresh rangachar Hughes Network systems srangachar@hns.com (301-601-4083) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: chomped on by a compiler optimization Date: Wed, 29 Apr 92 06:31:18 GMT From: marcu@leland.Stanford.EDU (Marc Albert Ullman) Organization: DSG, Stanford University, CA 94305, USA Message-ID: <1992Apr29.063118.736@leland.Stanford.EDU> References: Sender: news@leland.Stanford.EDU (Mr News) In article rg@msel.unh.edu (Roger Gonzalez) writes: > >Here is another place where I need to have a keyword like "volatile", but I >don't think it exists: > >On this hardware I am using, there is an 8 bit index register i that you vary to >change which slot three other registers (r, g, and b) point to. In other >words, to set g[123], you first set i to 123, and then write to the g >register. > >Am I mistaken, or would the optimizer notice that I'm writing to the same spot >repeatedly in a loop, nuke the loop, and reduce it to the last values >assigned? Not if that location was declared "volatile". >What would be the appropriate way to protect this from happening, without >completely turning the optimizer off? "volatile" is exactly what you need here as well. Declaring something to be volatile tells the compiler that "something else" is looking at that memory location asychronously to the compiler generated accesses, and thus no programmatic access can be left out (e.g. your writes). - --Marc Ullman Stanford University --------------------------- End of New-News digest ********************** From rayssd!pike.ssd.ray.com!fjr@uunet.uu.net Wed Apr 29 08:28:55 1992 From: "Roeber" Date: Wed Apr 29 08:29:02 PDT 1992 Subject: Re: using mmus in realtime > Submitted-by briggs@thalia.jpl.nasa.gov Tue Apr 28 08:16:48 1992 > Submitted-by: briggs@thalia.jpl.nasa.gov (Clark Briggs) > If mmus are less expensive in that you get one naturally and they are always > on anyway, doesnt that make a few software features a lot cheaper to get? > Like protected logical address spaces for tasks. The task would run at the > same speed but the context would be larger (a concern during switching, > depending on the mmu) and the system must be prepared to handle the > exceptions. I feel that getting VxWorks to use all these features supported by a MMU is a mistake since it will make it look more like a incomplete UNIX than the fast kernel it is now. The amount of context required to do task level memory mapping is quite large on most systems (you need lots of page tables). The bigger issues revolve around the fact that VxWorks is designed to be a fully shared memory architecture and everything runs in the same mode (supervisor). With normal mapped systems, things like shared data and shared code (libraries) are a real bear to set up. VxWorks would likely have to be restructured to use separate kernel and and user modes. I could see some simple support like maybe just allowing text areas to be protected as execute only but anything much more would require a boatload of rework. > I always liked the sound of Masscomp's rtu where the user could scale the Unix > features down to a kernel. You could chose to memory lock your code, or not > use certain system functions. I think you always got a private logical space. > I was told the minimal kernel would run in single digit multiples of real > kernels like VxWorks on such metrics as context switch times or semaphore > gives. Plus they have had multiprocessing for a while and can put 2 or 4 > 68040s on a (9U?) board. Yeah, I always thought that sounded nice. Some of these UNIX versions with good real time multiprocessor features (my favorite is SGI IRIX) are really nice to use from a development perspective. They make errors a lot easier to find than in a shared everything environment like VxWorks but it all boils down to that several times slower value you mention. In a large multitasking system on those UNIX versions, executive overhead can easily start approaching 30% or more of your CPU. Things do run a lot slower than on VxWorks with the same hardware platform. I think it is instructive to look at the new POSIX standards. The 1003.13 (Realtime profiles) group, that us and WRS have people on, is looking at different "flavors" of POSIX to satisfy different target needs. There are 4 profiles covering everything from embedded controllers up to full blown multiprocessors. The key point is that the different profiles support different levels of capabilities so you can get the desired execution speed and program size. My feeling is that one kernel won't cover all four domains (well). Trying to make one piece of software do too many jobs makes it handle all of them in a mediocre fashion. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From interf!zeus!brackett@uunet.uu.net Wed Apr 29 08:47:20 1992 From: interf!zeus!brackett@uunet.uu.net (Todd Brackett) Date: Wed Apr 29 08:47:31 PDT 1992 Subject: Re: distributed vxWorks Hi!! For everybody's reference, Dave Wilner of WRS announced at the West Coast user group meeting (10 April 92) that WRS will release a new version (5.x ?) of vxWorks which does contain multiprocessor connection on the backplane. (Yes they have seen the light). This connection is not TCP/IP driven and so will supply the yearned for "tight coupling" that we all have been whining about for years. As usual he was very vague about dates for release but was willing to give away a "sometime late this year". The system will include the semaphore and message queue IPC functions. With respect to questions I have heard about releasing beta copies on the net. I think this is something that WRS, a company with a real support department, that costs money, will never do. You have to consider the fact that unlike the GNU world they are in business to make money. Let's face it, "support" is a necessary money sink in any company. I don't think they would want to be associated with anything as half baked as a netwide "beta". I am sure that if one was really interested in that you could make a one on one beta site arrangement with them. If there are "extensions" that we want as users and we as users are willing to become more GNU-like in our handling of this (eg. the UG archives) then we can become very influential with WRS. I encourage any of you, especially those in or associated with government projects, to let us know about your "extensions" so they can be added to the public domain. I doubt that WRS would have responed at all on this and other topics if it weren't for the efforts of this exploder/newsgroup and the user group meetings. Let's consider this our first victory. Regards, PS See you all at the UG in Boston in September ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From tlusco@inquisitor.gsfc.nasa.gov Wed Apr 29 09:40:57 1992 From: tlusco@inquisitor.gsfc.nasa.gov (C. Tom Lusco) Date: Wed Apr 29 09:41:04 PDT 1992 Subject: FDDI Does anyone out there have experience with FDDI in a VxWorks system? Any information you can give would be greatly appreciated. Tom Lusco tlusco@kraken.gsfc.nasa.gov From symborski@hns.com Wed Apr 29 11:33:17 1992 From: symborski@hns.com (Carl Symborski) Date: Wed Apr 29 11:33:25 PDT 1992 Subject: RE: bit-fields, volatile, ANSI-C > On Mon Apr 20 23:26:31 1992 (David N. Wilner) wrote: > > .... Well, in actuality there was only one > module in the kernel that made this assumption. This was in tyLib > in which we kept a word of software status bits indicating the state > of the serial line. > . . . > However, it was clear that it would be a problem for our RISC ports. > The fix was quite simple: we changed all the bit-field flags to byte-wide > flags, the setting of which are atomic. This is the way tyLib is > currently distributed in all our RISC ports, and will be in all ports > in future releases. Folks, Been catching up on my EMail post vacation and noticed the thread concerning what assumptions can be made with atomic "C" functions, and alledged VxWorks latent bugs on RISC based processors. Had to comment on this one :-) .... We certainly ran into this problem in the i960 implementation of Vx!!! Yup, the problem was in the tylib and was discovered after *much* effort during the development of one of our board support package. Anyway we reported our results back to Intel and indirectly WR. I know that there is now a patch for this in the current 5.0.3 commercial release. Glad to see that the problem is resolved from now on. Good discussion thread! Carl Symborski symborski@hns.com From visicom!VisiCom.COM!trest@nosc.mil Wed Apr 29 20:02:59 1992 From: Mike Trest Date: Wed Apr 29 20:03:06 PDT 1992 Subject: Re: using mmus in realtime > | Fred J Roeber, Raytheon Submarine Signal Division | > I think it is >instructive to look at the new POSIX standards. The 1003.13 (Realtime >profiles) group, that us and WRS have people on, is looking at different >"flavors" of POSIX to satisfy different target needs. There are 4 profiles >covering everything from embedded controllers up to full blown multiprocessors. >The key point is that the different profiles support different levels of >capabilities so you can get the desired execution speed and program size. My >feeling is that one kernel won't cover all four domains (well). Trying to >make one piece of software do too many jobs makes it handle all of them in >a mediocre fashion. Fred I agree! There is no single solution. Lets keep the granular approach where we can build a kernel with the facilities desired. If we want the features we pay the performance price. BUT lets all keep the inputs here and to WRS to define and clarify what we want. We are, after all, the market place that WRS is trying to satisfy. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From daemon@vxw.ee.lbl.gov Thu Apr 30 04:00:26 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Apr 30 04:00:35 PDT 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 30 04:00:19 PDT 1992 Subject: gcc et al Subject: Re: gcc et al Subject: Re: vme address questions Subject: Re: gcc et al ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: gcc et al Date: 29 Apr 92 15:04:48 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: Sender: news@nic.unh.edu (USENET News System) What are the changes to the build procedure in building gcc to make it into the cross compiler that comes with vxworks? I'd like to be able to build new versions of it when they are released from gnu. I'd like to do the same with gas. - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Re: gcc et al Date: Wed, 29 Apr 92 18:16:41 GMT From: marcu@leland.Stanford.EDU (Marc Albert Ullman) Organization: DSG, Stanford University, CA 94305, USA Message-ID: <1992Apr29.181641.28646@leland.Stanford.EDU> References: Sender: news@leland.Stanford.EDU (Mr News) In article rg@msel.unh.edu (Roger Gonzalez) writes: > >What are the changes to the build procedure in building gcc to make it into >the cross compiler that comes with vxworks? I'd like to be able to build new >versions of it when they are released from gnu. I'd like to do the same with >gas. I don't know if the following comments are of any help but we have gotten GCC V2.1 to work as a cross compiler for both C and C++ (with libg++ 2.0 and streams) from SPARC to 68K for VxWorks 5.0.2. There are a number of subtleties that have to be addressed in order to get it all to work, and immediate time constraints prevent me from providing more details here. Suffice it to say, it can be make to work and work well. - --Marc Ullman Stanford University --------------------------- Newsgroups: comp.os.vxworks Subject: Re: vme address questions Date: 30 Apr 92 03:13:16 GMT From: flash@austin.lockheed.com (James W. Melton) Organization: "Lockheed Austin Division, 6800 Burleson Rd, Austin, TX 78744 Message-ID: <963@shrike.com> References: In article hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: > >In article rg@msel.unh.edu (Roger Gonzalez) writes: > >>How does one specify VME address modifier codes to VxWorks? [ stuff deleted ] >Typically, the CPU board generates the AM codes based on the >address specified. For example, most Motorola boards generate a short >IO access for addresses above 0xffff0000. [ stuff deleted ] >In sysLib.c for your board, check out >sysLocalToBusAdrs() and sysBusToLocalAdrs() -- that should give you >some insight. Adress modes for non-Motorola boards may be a little hairier. I spent a few hours one day wrestling with the Tadpole TP-41 addressing scheme. In the process I found a bug in sysBusToLocalAdrs(). If anyone else has one of these beasties and is interested in my experience, I will be happy to respond via email. LET ME EMPHASIZE: This was a TP-41 BSP specific problem. The other boards (and BSPs) that I have used have worked just fine. The problem has been reported to WRS and (presumably) will be fixed in the next release. The point is, if you have any interest in writing portable code, you should use sysBusToLocalAdrs() and sysLocalToBusAdrs() rather than assuming that 0xffff.... will generate a short address. - ---- Jim Melton, novice guru in person: (512) 386-4303 | "So far as we know, our voice mail: (512) 386-4486 | computer has never had fax: (512) 386-4223 | an undetected error" e-mail: flash@austin.lockheed.com | --------------------------- Newsgroups: comp.os.vxworks Subject: Re: gcc et al Date: 30 Apr 92 05:08:38 GMT From: hwajin@mondo.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1992Apr29.181641.28646@leland.Stanford.EDU> Sender: hwajin@iphasew.com I'm running GCC 1.40 which is a production level compiler and is mostly as good as the latest version as far as m68k code generation goes (so I'm told by my contacts at Cygnus). The compiler is setup to allow compilation on either sun3 or sun4 architecture machines to generate code for mc68020 type machines. Actually the full setup I have here includes C & C++ compilers that run on either architecture and generates code for mc68020, mc68000, sparc, sun3, sun3x. Setting up a complex configuration such as this takes a bit of time. In my experience (this was before the days of very useful Cygnus "configure" script provided now with recent releases), the following things need to be done to have a complex cross development environment setup (that is, in addition to reading installation doc's and doing/learning the standard stuff): 1. config.gcc may need modification; you may need to add special entries for your setup. 2. The default Makefile might not do the proper thing when creating a cross compiler. I resolved this by using GNU make's "include" directive which allows a configuration file to be included. Inside the configuration file, MACH is defined to be the machine architecture for running the compiler, XMACH is defined to be machine architecture for target code. The Makefile is then modified to set correct values for such things as: XCFLAGS, CC, AR, bindir, libdir, STANDARD_EXEC_PREFIX, and rules for the install: target This helps in keeping track of correct compilers for various combinations of host/target pairs. The convention I use is: binaries reside in bin-`mach` directory and libraries reside in lib-`mach` directory. For each type of compiler, correct versions of libraries much be provided. For example, bin-sparc/mc68000-gcc (a compiler running on sparc but generates mc68000 code) needs lib-sparc/mc68000-gnulib et. al. You can figure out the a whole list of combinations that can occur (there are a lot) to support a flexible environment. My lib-sparc directory contains, for example the following files: g++-include gcc-as gcc-cc1plus gcc-ccrt0.o gcc-cpp gcc-gccrt0.o gcc-gnulib gcc-include gcc-ld icombine libg++.a mc68000-as mc68000-cc1 mc68000-cc1plus mc68000-ccrt0.o mc68000-cpp mc68000-g++-include mc68000-gccrt0.o mc68000-gnulib mc68000-gnulib.old mc68000-include mc68000-ld mc68000-lib mc68020-as mc68020-cc1 mc68020-cpp mc68020-gnulib mc68020-gnulib.old mc68020-include mc68020-ld sparc-as sparc-cc1 sparc-cpp sparc-gnulib sparc-include sparc-ld sun3-Fcrt1.o sun3-Mcrt1.o sun3-as sun3-cc1 sun3-cpp sun3-crt0.o sun3-gnulib sun3-include sun3-ld sun3-libc.a sun3-libc_p.a sun3-libg.a sun3x-Fcrt1.o sun3x-Mcrt1.o sun3x-as sun3x-cc1 sun3x-cpp sun3x-crt0.o sun3x-gnulib sun3x-include sun3x-ld sun3x-libc.a sun3x-libc_p.a sun3x-libg.a and bin-sparc contains: g++ g++dep gcc gdb gdb-old mc68000-g++ mc68000-gcc mc68020-gcc mc68020-gcc-old ranlib sparc-gcc sparc-gdb sun3-gcc sun3x-gcc 3. When you're compiling for VxWorks, it's a good idea to do away with UNIX library routines. GCC uses native compiler to generate many of gnulib routines (numeric conversion, etc.) which means that you'll get SunOS versions of these routines. You can instead build SunOS independent equivalent routines using Kai-Uwe Bloem's collection of numeric routines, available from various sources for free. 4. You'll also need GNU "binutils" for things such as ranlib, nm, and especially gas. - -- Hwa-Jin Bae Interphase West --------------------------- End of New-News digest ********************** From jjohnson@hns.com Thu Apr 30 08:08:27 1992 From: jjohnson@hns.com (Jayne Johnson) Date: Thu Apr 30 08:08:48 PDT 1992 Subject: RPC problem ? We are using Vx960 5.0.3 (production ) GNU 1.3 (Intel release) and are experiencing a problem for initializing gdb960 over our T1 link. We are not experiencing gdb960 problems when we initialize rdb task over the ethernet. My question to the user community is : Can we use RPC clnt_control() primitive to extend the timeout period for RPC before we execute rdbInit() or is there something else we must configure in RPC for T1 communications to be allowed between the client and server debuggers? What host is the RDB trying to reach? In the GNU source can anyone direct me to the source that does this registration? At the workstation dcn7 we have gdb960 up and running: At the target card ( over the T1 ) the Host table : -> hostShow hostname inet address aliases -------- ------------ ------- localhost 127.0.0.1 dcn7 139.85.200.53 value = 0 = 0x0 At the target ( the other side of the T1 ) we execute : -> rdbInit value = 0 = 0x0 -> Cannot register service: RPC: Unable to send; errno = 65 rdbTask: couldn't register RDB service At the target this is the Routing table entries: -> routeShow ROUTE NET TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 18.1.1.0 18.1.1.41 1 0 0 ei0 18.1.0.0 18.1.1.253 3 1 5 ti0 ------------------------------------------------------------------------ ROUTE HOST TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 127.0.0.1 127.0.0.1 5 0 0 lo0 18.0.2.2 18.1.1.253 7 1 6 ti0 139.85.200.53 18.1.1.253 7 1 59 ti0 18.1.1.253 18.1.1.254 5 0 8 ti0 ------------------------------------------------------------------------ value = 73 = 0x49 = 'I' From thor@thor.atd.ucar.edu Thu Apr 30 23:02:04 1992 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Thu Apr 30 23:02:17 PDT 1992 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 1629 -rw-r--r-- 1 thor 238 Apr 1 08:02 MANIFEST -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 41669 Dec 6 14:07 dhrystones01 -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 9206 Apr 1 08:07 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 27824 May 30 1989 jobCondLib -rw-r--r-- 1 thor 25014 May 30 1989 jobLib lrwxrwxrwx 1 root 10 Aug 14 1991 jobcondlib -> jobCondLib lrwxrwxrwx 1 root 6 Aug 14 1991 joblib -> jobLib -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 1991 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 41667 Feb 5 11:39 ntpvx01 -rw-r--r-- 1 thor 38524 Feb 5 11:39 ntpvx02 -rw-r--r-- 1 thor 41997 Feb 5 11:39 ntpvx03 -rw-r--r-- 1 thor 39218 Feb 5 11:39 ntpvx04 -rw-r--r-- 1 thor 39625 Feb 5 11:39 ntpvx05 -rw-r--r-- 1 thor 28741 Feb 5 11:39 ntpvx06 -rw-r--r-- 1 thor 32516 Feb 5 11:39 ntpvx07 -rw-r--r-- 1 thor 37119 Feb 5 11:39 ntpvx08 -rw-r--r-- 1 thor 41643 Feb 5 11:39 ntpvx09 -rw-r--r-- 1 thor 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 1991 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 1991 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 8424 Apr 1 08:02 syslog.shar -rw-r--r-- 1 thor 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 11747 Feb 4 09:49 tp41.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 14:05 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 14:05 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 14:05 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 14:05 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 14:05 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 14:05 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 14:05 vwcurses07 -rw-r--r-- 1 thor 4636 Feb 4 11:50 vx_cplusplus -rw-r--r-- 1 thor 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 13:28 wdog_class Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Mar 17 07:33 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn.