From Greg.J.Marshall@lmco.com Wed Apr 1 06:15:55 1998 From: Greg J Marshall Date: Wed Apr 1 06:15:58 PST 1998 I am trying to build 3rd party drivers into our vxWorks image. I have modified RAM_HIGH_ADRS in both config.h and Makefile to a suitable value. My kernel (with drivers) builds without errors. However when trying to boot vxWorks (over ethernet) i get to "Loading 245820". It hangs here and never returns. However, if I delete some of the drivers out of my build (some drivers are still built in) it boots ok. I am running on an MVME2604/BSP 1.1/4 with Tornado1.0.1/VxWorks 5.3.1. thanks greg.j.marshall@lmco.com From kkauper@draper.com Wed Apr 1 06:18:10 1998 From: "Kris A. Kauper" Date: Wed Apr 1 06:18:14 PST 1998 Subject: NI VXI-MIO-64E-3 driver? message-based? tornado Has anyone written a VxWorks driver for NI's VXI-MIO-64E-3 A/D VXI card? Or, does anyone have a class framework for message-based VXI modules? Thanks. Kris Kauper C.S. Draper Laboratory 555 Technology Square, M/S 18 Cambridge, MA 02139 kkauper@draper.com 617-258-1590 617-258-3858 (fax) From chris_calley@dlcc.com Wed Apr 1 09:45:44 1998 From: Chris Calley Date: Wed Apr 1 09:45:48 PST 1998 Subject: Vxworks SENS stack Has anyone used the new SENS tcp/ip stack? I'd appreciate any comments regarding feature content, ease of use. Does it live up to the claims made by WRS? Thanks in advance, Chris -- Christopher A. Calley chris_calley@dlcc.com DiamondLane Communications Corp. 1310 Redwood Way Petaluma, CA 94954 From joew@wreck.wtc.gov Wed Apr 1 12:55:58 1998 From: "Joe W." Date: Wed Apr 1 12:56:01 PST 1998 Subject: Memory Fragmentation in VxWorks 5.3.1 I have a VxWorks 5.3.1 system running on MVME167 cards which is experiencing massive memory fragmentation, to the point that the largest available memory chunk is too small for dosFs to be able to open a file. The same code running on a VxWorks 5.1 system doesn't have the problem. Anyone have any ideas what might be configured wrong? Thanks for any help. --Joe W (joew@wtc.gov) From gzhang@utstar.com Wed Apr 1 14:59:08 1998 From: "Greg Zhang" Date: Wed Apr 1 14:59:12 PST 1998 Subject: cc386 -g puzzle VxWorks! Hello, I have been compiling some ATM signaling stack code with the cc386, ar386, and ranlib386. Just found out that code compiled with -g is more than ten times bigger than what is produced without it. A 349KB library swells to 4.5MB. Is this a known problem with gcc? If so, I'd like to hear some sensible explanation of it. - Greg From rtp.co.uk!ihw@rtp.co.uk Wed Apr 1 23:30:24 1998 From: Ian Willats Date: Wed Apr 1 23:30:29 PST 1998 Subject: Re: cc386 -g puzzle Greg Zhang asked: > ... Just found out that code compiled > with -g is more than ten times bigger than what is produced without > it.=20 > Is this a known problem with gcc? If so, I'd like to hear some > sensible explanation of it. Depends what you mean by "bigger". If you simply compare the size of = the object file, this is normal because the "-g" object file contains = lots of extra information for the debugger. If you look at the size of = the text, data and bss sections (use size386) they should be similar to = the original non "-g" case. So it's known, but not a problem! HTH Ian --------------------------------------------------------------- Ian Willats e-mail: mailto:ihw@rtp.co.uk Real-Time Products Ltd. direct: +44 (0) 121 234 6637 Chancery House, tel: +44 (0) 121 234 6600 8 Edward Street, Birmingham. fax: +44 (0) 121 234 6611 B1 2RX. England. web: http://www.rtp.co.uk --------------------------------------------------------------- (VxWorks) From harald.grundner@ri.dasa.de Thu Apr 2 00:33:17 1998 From: Harald Grundner Date: Thu Apr 2 00:33:21 PST 1998 Subject: Re: >Submitted-by: Greg J Marshall > > I am trying to build 3rd party drivers into our vxWorks image. > I have modified RAM_HIGH_ADRS in both config.h and Makefile > to a suitable value. My kernel (with drivers) builds without > errors. However when trying to boot vxWorks (over ethernet) > i get to "Loading 245820". It hangs here and never returns. > However, if I delete some of the drivers out of my build > (some drivers are still built in) it boots ok. Sorry if it's a stupid question, but did you burn new boot PROMs with your modified RAM_HIGH_ADRS? Harald harald.grundner@ri.dasa.de From daemon@csg.lbl.gov Thu Apr 2 04:02:24 1998 From: daemon@csg.lbl.gov Date: Thu Apr 2 04:02:27 PST 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 2 04:02:22 PST 1998 Subject: - <<< Test Drive THIS for 30 Days - FREE! >> Subject: Newbie question: Kontron ICE ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: - <<< Test Drive THIS for 30 Days - FREE! >> Date: 1 Apr 1998 20:16:37 GMT From: Ted Bilmer Organization: TMnet Malaysia Message-ID: <6fu7b5$61m$968@news.tm.net.my> YES, you can test-drive this MLM (Multi-Level Marketing) for 30 day, FREE. Build your downlines during this period. If you don't succeed just quit, no questions asked. No obligation. No string attached. All you need is just sponsor (recruit) 6 people. That's it. Watch what happens if you manage to do that: Sponsoring 6 is just damned EASY. For easy calculation let's assume you and all your downlines sponsor 10 each. Watch what happens: (For every person you sponsor US5 will be given to you as bonus) Level 1 : 10 = 10 x US5 = US50 Level 2 : 10 x 10 = 100 x US5 = US500 Level 3 : 10 x 10 x 10 = 1,000 x US5 = US5,000 Level 4 : 10 x 10 x 10 x 10 = 10,000 x US5 = US50,000 Level 5 : 10 x 10 x 10 x 10 x 10 = 100,000 x US5 = US500,000 Level 6 : 10 x 10 x 10 x 10 x 10 x 10 = 1,000,000 x US5 = US5,000,000 ----------- Total (1st quarter) = US5,555,550 You will be receiveing that amount every 3 months (quarterly) as long as you pay your membership fee of US40. TOTAL Income 1 year = 4 x US5,555,550 = US22,222,200 YES, about US20 million every year for the rest of your life. If you are interested write to me for more info or if you just can't wait, go to my site: http://www.opamerica2.com/ssc.cfm?m_uid=tedbilmer v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ Good thing about this MLM: v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ * You just need to sponsor ONLY 6. (NB: Most sponsor more than this 'cos it's damned EASY!) Statistical projection shows that OVER 100 MILLION people will have E-mail accounts within the next year! So you have plenty to choose from: 6 out of 100 million prospects! * It's 6 levels deep, therefore more income. * You don't buy any product. (I hate buying thing and have it delivered to my door). Here, you just buy membership instead of product. * You will be notified automatically whenever someone register under your name. Or you just go to the MLM site and see for yourself how many have registered under you. You can than contact and motivate them. * You can open a FREE cyber bank account and instruct this MLM to deposit your bonus there. You can login to your account ANY TIME and watch your money grow. v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ OK, this is my guarantee: v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^ If you register under me, meaning you are my downline, than I'll personally couch you on how to find at least 10 as your downlines. I've found an easy way to sponsor 100 or more within a week. It's a snap. You'll wonder how easy it is. Go to my site NOW and check it out yourself! http://www.opamerica2.com/ssc.cfm?m_uid=tedbilmer Thanks for your time Bilmer --------------------------- Newsgroups: comp.os.vxworks Subject: Newbie question: Kontron ICE Date: Wed, 01 Apr 1998 18:52:20 -0600 From: Randy Wentworth Message-ID: <3522E143.F3657AFD@ti.com> Reply-To: rwent@ti.com We've got a chicken-and-egg problem that we haven't found a decent solution for. Our only hardware tool is a Kontron KSE5 ICE, which only accepts OMF.386 or IEEE695 images. Does anyone see how we can get onto the target, at least far enough to get the WDB agent and serial line up? Hopeless question #2: any chance on their being a target server backend out there for the Kontron? Thanks(tm), - -Randy Wentworth rwent@ti.com --------------------------- End of New-News digest ********************** From bmcgonig@mariners.com Thu Apr 2 06:56:29 1998 From: Brian Date: Thu Apr 2 06:56:33 PST 1998 Subject: Re: comp.os.vxworks newsdigest (VxWorks) http://techweb.cmp.com/eet/news/98/1001news/windowsce.html/ Hi: This is not strictly a technical question but I would very much welcome other's thoughts regarding the above announcement about Windows CE going hard-real-time, as well as Integrated Systems intention to ally with MSFT. Thanx Brian From bmcgonig@mariners.com Thu Apr 2 10:33:07 1998 From: Brian Date: Thu Apr 2 10:33:10 PST 1998 Subject: Hard Real Time CE ?? (VxWorks) http://techweb.cmp.com/eet/news/98/1001news/windowsce.html/ Hi: This is not strictly a technical question but I would very much welcome other's thoughts regarding the above announcement about Windows CE going hard-real-time, as well as Integrated Systems intention to ally with MSFT. Thanx Brian From brett.smith@wg.com Thu Apr 2 10:52:49 1998 From: brett.smith@wg.com Date: Thu Apr 2 10:52:52 PST 1998 Subject: recvfrom() and close() What is the proper way to stop a task whose sole purpose is to continually call recvfrom() and put the results in a queue? I have 2 tasks (actually they are Java threads). The 1st task creates a queue and spawns the 2nd task which just continually calls the recvfrom() function. When it is time for cleanup, the 1st task changes the state of the 2nd task from running to notRunning and must interrupt the recvfrom() call. I have tried calling close() on the socket in question, but the results are not consistant. Some times cleanup will occur, and sometimes the application appears to be deadlocked; until I attempt an ftp connection (this connection attempt seems to allow partial cleanup). psuedo code for task 2: while(state == running) { numBytes = recvfrom(fd, packet, ...); que.add(packet); } I am looking for something similar to select() or poll(), for which I can wait on 2 events (either an application setable event, or a packet received event). Any suggestions are appreciated. Brett vxWorks From bobperry@bellatlantic.net Thu Apr 2 14:27:26 1998 From: "Robert L. Perry" Date: Thu Apr 2 14:27:29 PST 1998 Subject: Re: Memory Fragmentation in VxWorks 5.3.1 Joe, A theory - I don't think that you have a configuration problem, however, you've uncovered an interresting feature of dosFs: at open/creat time, the dosFs malloc()'s a directory entry and a cluster; at close time the cluster is free()'d and the cluster is *not* -it remains memory resident and is simply marked as available. Consider what happens when any malloc() is followed by a creat(). The new directory entry will lie in the middle of the origional cluster area and the new cluster has to be moved elsewhere. Memory is now forever fragmented, and given the right conditions, its only a matter of time. > >I have a VxWorks 5.3.1 system running on MVME167 cards which is >experiencing >massive memory fragmentation, to the point that the largest available >memory chunk >is too small for dosFs to be able to open a file. The same code running >on a VxWorks 5.1 >system doesn't have the problem. Anyone have any ideas what might be >configured wrong? > >Thanks for any help. > >--Joe W (joew@wtc.gov) From cgrames@mdc.com Thu Apr 2 17:01:12 1998 From: Charlie Grames Date: Thu Apr 2 17:01:15 PST 1998 Subject: recvfrom() and close() -Reply Brett, recvfrom() is already associated with a file descriptor, so you can use select() with it. As far as an application-settable event (also associated with a file descriptor, if you plan to use select), how about a pipe? Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 04/02/98 12:52pm >>> Submitted-by brett.smith@wg.com Thu Apr 2 10:52:49 1998 Submitted-by: brett.smith@wg.com What is the proper way to stop a task whose sole purpose is to continually call recvfrom() and put the results in a queue? I have 2 tasks (actually they are Java threads). The 1st task creates a queue and spawns the 2nd task which just continually calls the recvfrom() function. When it is time for cleanup, the 1st task changes the state of the 2nd task from running to notRunning and must interrupt the recvfrom() call. I have tried calling close() on the socket in question, but the results are not consistant. Some times cleanup will occur, and sometimes the application appears to be deadlocked; until I attempt an ftp connection (this connection attempt seems to allow partial cleanup). psuedo code for task 2: while(state == running) { numBytes = recvfrom(fd, packet, ...); que.add(packet); } I am looking for something similar to select() or poll(), for which I can wait on 2 events (either an application setable event, or a packet received event). Any suggestions are appreciated. Brett From LegoasMarcoA@space.honeywell.com Fri Apr 3 05:11:06 1998 From: "Legoas, Marco A (FL51)" Date: Fri Apr 3 05:11:14 PST 1998 Subject: Help with as68k Hi, VxWorks world, When using as68k to assemble the following file, I am getting execution errors in what it seems illegal code generated by the as68k (VxWorks 5.2). .extern _SCPInd BEES: .long 0xaabbccdd OVER: cmp.l BEES.w(pc),d2 move sr,_SCPInd cmp.w BEES.b(pc,d7.w),d2 move sr,_SCPInd The following output is produced by the as68k assembler: sds2> as68k -a -R -mc68000 -l tst.s 68K GAS tst.s page 1 1 .extern _SCPInd 2 0000 AABB CCDD BEES: .long 0xaabbccdd 3 0004 B4BA FFF8 OVER: cmp.l BEES.w(pc),d2 4 0008 40F9 0000 move sr,_SCPInd 4 0000 5 000e B47B 7000 cmp.w BEES.b(pc,d7.w),d2 6 0012 40F9 0000 move sr,_SCPInd 6 0000 7 68K GAS tst.s page 2 DEFINED SYMBOLS tst.s:2 1:00000000 BEES tst.s:3 1:00000004 OVER UNDEFINED SYMBOLS _SCPInd sds2> =================================== Comments: This code Line 3 : B4BA FFF8 Shows a relative displacement of -8. Other assemblers show B4BA FFFA Line 5 : B47B 7000 The displacement now seems to be absolute and it follows what it seems to be the value of the location of BEES (0000). Any Ideas in what I am doing wrong? Marco A. Legoas malegoas@space.honeywell.com From shoutchen@SYSTRAN.com Fri Apr 3 05:40:24 1998 From: Steve Houtchen Date: Fri Apr 3 05:40:28 PST 1998 Subject: mempartfree VxWorks or Tornado Greetings VxWorks or Tornado users Can anyone explain the potential causes for getting a mempartfree error other than the obvious one where you call free on a pointer value that was not returned by malloc? I would guess something that corrupts the memory "free list" would do something similar, but does anybody know what else can go wrong? Also, does anybody know what is kept in the "overhead portion" that is used when a memory is malloced? I assume that is some housekeeping info for the free list... and trashing this may potentially lead to the mempartfree error... Steve Houtchen shoutchen@systran.com From jford@sadira.gb.nrao.edu Fri Apr 3 06:23:45 1998 From: John Ford Date: Fri Apr 3 06:23:48 PST 1998 Subject: mv167 cache configuration Hello to all VxWorks fans! I am upgrading my vxWorks 5.3 system to use the new SENS code. In my original config.h, I have the following code, and in the new config.h supplied with SENS, this code does not exist. As I was not the first to mess with this file, I don`t know if this is a necessary bit or not. Does anyone know? Surely the hardware did not heal itself? Thanks for any information. /* cache configuration */ /* * VMEbus snooping is unreliable on the MVME167. To ensure proper * synchronization during shared memory packet exchange, the snooping feature * must not be relied upon when using local memory (SM_OFF_BOARD==FALSE). * Rather, the MMU will be utilized to mark the pages of concern as cache * inhibited. When the hardware stabilizes, the CACHE_SNOOP_ENABLE bit will * provide even greater network and shared memory object performance. */ #if (defined(INCLUDE_SM_NET) || defined(INCLUDE_SM_OBJ)) #if SM_OFF_BOARD #define USER_D_CACHE_MODE (CACHE_COPYBACK | CACHE_SNOOP_ENABLE) #define BUS_SNOOP #else #undef USER_D_CACHE_MODE #define USER_D_CACHE_MODE (CACHE_COPYBACK) #endif /* SM_OFF_BOARD */ #endif /* (defined(INCLUDE_SM_NET) || defined(INCLUDE_SM_OBJ)) */ -- John Ford National Radio Astronomy Observatory Green Bank, WV 24944-0002 jford@nrao.edu From ste@ply.wg.com Fri Apr 3 07:12:51 1998 From: Steve James Date: Fri Apr 3 07:12:54 PST 1998 Subject: Re: comp.os.vxworks newsdigest This is a multi-part message in MIME format. --------------00C9D58FA4AFB71A229E20EE Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit the vxWorks Users Group Exploder wrote: > Newsgroups: comp.os.vxworks > Subject: Newbie question: Kontron ICE > Date: Wed, 01 Apr 1998 18:52:20 -0600 > From: Randy Wentworth > Message-ID: <3522E143.F3657AFD@ti.com> > Reply-To: rwent@ti.com > > We've got a chicken-and-egg problem that we haven't found a decent > solution for. Our only hardware tool is a Kontron KSE5 ICE, which only > > accepts OMF.386 or IEEE695 images. Does anyone see how we can get onto > > the target, at least far enough to get the WDB agent and serial line > up? > > Hopeless question #2: any chance on their being a target server > backend > out there for the Kontron? > > Thanks(tm), > - -Randy Wentworth > rwent@ti.com We had a lot of agro getting our Kontron going with our 386 target. Don't give up hope yet though. We did suceed in getting the KSE5 to work with Tornado 1.0. We were supplied with a 'new' conversion tool to get from a.out object format as generated by GCC to whatever it was the KSE wanted. I'm sorry I'm having trouble remembering much more about it than that! To complicate things we had two diferent user interfaces to the KSE. One was called Organon. I've got this tool here that says this... aout3bnd - Organon A.OUT Debug-Converter - Version: V100C aout3bnd: Usage: aout3bnd [options] file aout3bnd: aout3bnd -h[elp] aout3bnd: options: -[] aout3bnd: key: h c d b File name: So do get back to Kontron about the conversion tool. Hope that helps! Steve. -- --Steve James, Senior Design Eng.--............................ --Wandel & Goltermann Ltd........--.+44 (0)1752 765367 (vmail). --Eurotech House, Burrington Way.--.+44 (0)1752 791101 (FAX)... --Plymouth, Devon. PL5 3LZ. U.K..--.+44 (0)1752 772773 (switcb) --------------00C9D58FA4AFB71A229E20EE Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve James Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Steve James n: James;Steve org: Wandel & Goltermann Ltd., Plymouth email;internet: ste@ply.wg.com title: Senior Design Engineer x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------00C9D58FA4AFB71A229E20EE-- From nguyend2@ttc.com Fri Apr 3 09:48:35 1998 From: "Dzung Nguyen" Date: Fri Apr 3 09:48:38 PST 1998 Subject: EXCHANGE_TIMEOUT I'm rather frustrated with this error. I'm trying to download a large file (2.5M) in tornado debug window using "ld < file", but dowloading always failed and WDB always returned this error message: "Error while polling for events: WTX Error 0x10197 (EXCHANGE_TIMEOUT) I tried to increase the cache as suggested by WRS support, but the problem persists. Note that downloading the same file via the shell window was always successful. Could anyone give me a clue? Thank you very much in advance. Dzung Nguyen From jaa@mclean.sparta.com Fri Apr 3 10:06:37 1998 From: "Jeff Angielski" Date: Fri Apr 3 10:06:40 PST 1998 Subject: Tcl8.0 in VxWorks 5.3.1 Does anyone know how you actually invoke and run Tcl8.0 on a VxWorks platform? Do you spawn a task? Invoke something from the shell prompt? Any information regarding Tcl8.0 and VxWorks would be greatly appreciated. Thanks in advance, Jeff Angielski jaa@mclean.sparta.com From RadaJA@corning.com Fri Apr 3 10:11:38 1998 From: "Rada, Jeff A" Date: Fri Apr 3 10:11:42 PST 1998 Subject: RE: Hard Real Time CE ?? > ---------- > From: Rada, Jeff A > Sent: Thursday, April 02, 1998 3:58 PM > To: 'vxwexplo@lbl.gov' > Subject: RE: Hard Real Time CE ?? > > All vxWorks users, > > The Question of about Windows CE going real time is interesting. I have > looked into CE a little the following blurb of text is right out of the > Windows CE documentation. > > Microsoft Windows CE is designed as a general-purpose operating system > that supports a virtual memory system. Windows CE should not be used in > hard real-time systems. > > Other Considerations > > Interrupt service routines (ISTs) at the highest priority > level are not preempted by any other threads. These threads continue > execution until they either yield or are blocked. Windows CE does not > support nested interrupts. This means that an interrupt can not occur > while a previous interrupt is being processed. That is, if an interrupt is > raised while the kernel is within an ISR, execution continues to the end > of that ISR before starting the ISR for the new IRQ. This can introduce > latencies, or delays between the time of the hardware interrupt and the > start of the ISR. The inability to immediately process a hardware > interrupt makes Windows CE unsuitable for hard real-time systems. However, > because the ISR processing times involved are very small, specific > implementations of Windows CE can meet the system requirements for soft > real-time systems. > > I have more but I thought this would at least cover the basics. If > Microsoft can fix these issues and not create a monster OS then they have > a good chance of being a real monopoly. > > > > Hard Real Time CE ?? > > Submitted-by bmcgonig@mariners.com Thu Apr 2 10:33:07 1998 > Submitted-by: Brian > > > (VxWorks) > > http://techweb.cmp.com/eet/news/98/1001news/windowsce.html/ > > Hi: > > This is not strictly a technical question but I would > very much welcome other's thoughts regarding the > above announcement about Windows CE going hard-real-time, > as well as Integrated Systems intention to ally with MSFT. > > Thanx > > Brian > > > From stan@rti.com Fri Apr 3 13:51:25 1998 From: stan@rti.com (Stan Schneider) Date: Fri Apr 3 13:51:28 PST 1998 Subject: Re: Vxworks scripting, please help "news.ed.ray.com" wrote: > putenv "VER=5" > < TEMP/getenv("VER")/executable >When I execute this I get a systax error, any help would be greatly >appreciated. The shell doesn't do this type of string concatenation. File redirection also assumes a string filename. You can do something like this: sprintf(str=malloc(100), "TEMP/%s/executable", getenv("VER")) ld (0, 0, str) HTH, -- Stan From bawilson@llnl.gov Fri Apr 3 14:14:05 1998 From: "Bruce A. Wilson" Date: Fri Apr 3 14:14:08 PST 1998 Subject: RE: Hard Real Time CE ?? VxWorks Users: Doesn't the mv1603 PowerPC operate exactly as described below with VxWorks? Once an ISR is invoked, it runs to completion and cannot be interrupted. I don't think that means the PowerPC is incapable of hard realtime operation, and I don't think eliminates Windows CE as a candidate RTOS either. --Bruce Wilson >> Interrupt service routines (ISTs) at the highest priority >> level are not preempted by any other threads. These threads continue >> execution until they either yield or are blocked. Windows CE does not >> support nested interrupts. This means that an interrupt can not occur >> while a previous interrupt is being processed. Bruce A. Wilson U.C. LLNL ( L-054 ) P.O. Box 808 Livermore, CA 94550 From Greg.J.Marshall@lmco.com Sat Apr 4 10:29:51 1998 From: Greg J Marshall Date: Sat Apr 4 10:29:55 PST 1998 I am having some trouble generating a software VMEBus reset with VxWorks 5.3.1 and an MVME2604 board with rev 1.1/4 BSP (with extended VME). With the rev 1.1/3 BSP (with Psuedo-PReP memory) I was able to execute the following to generate a VMEBus reset: *UNIVERSE_MISC_CTL = LONGSWAP(MISC_CTL_SW_SRST); This does not work with the 1.1/4 BSP with extended VME defined. I get an exception when I try it. Any ideas? Greg Marshall Lockheed Martin Syracuse, NY From mmcquade@aa.net Sat Apr 4 17:44:04 1998 From: "Mike McQuade" Date: Sat Apr 4 17:44:07 PST 1998 Subject: MBX - 821 and Floppy / EIDE VxWorks Has anyone got the Floppy and / or EIDE drive to work on the MBX - 821 boards ? Id like to hear what your setup is to get either of the drives to work. I try to configure the EIDE with: -> usrAtaConfig(0,0,"/ata/") but the console prints out: "Error during ataDevCreate: 0" Also, When I try to configure the floppy with: -> usrFdConfig(0,0,"/fd0") The floppy drive light comes on, then the WindShell shows the function returns a -1, and the console prints out: "dosFsDevInit failed" Ive put all the code into the BSP for the floppy, and modified config.h for the first EIDE drive: #define ATA_DEV0_CYL DEV_AUTO_CONFIG /* controller 0, drive 0 */ Thanks. Mike From daemon@csg.lbl.gov Sun Apr 5 04:03:05 1998 From: daemon@csg.lbl.gov Date: Sun Apr 5 04:03:08 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 5 04:03:03 PDT 1998 Subject: Re: virtual IO ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: virtual IO Date: Fri, 03 Apr 1998 07:16:19 -0800 From: Rob Mapes Organization: Pacific Bell Internet Services Message-ID: <3524FD42.54F72265@pacbell.net> References: <3523127E.35F5E9EE@pacbell.net> <352465F9.A669F425@india.hp.com> Reply-To: rmapes@pacbell.net I'm actually not using windsh. I'm setting up the vio (with code just like your example), then connecting to the target server with a wtxtcl session and polling for WTX events. What puzzles me is why each printf doesn't generate its own VIO_WRITE event. Does the target server buffer them up? If so, is there any way to configure this to isolate each printf as a separate event? Devaraj Das wrote: > Rob, > > Try this fragment of code: > vf0=open("/vio/0",2,0) > ioGlobalStdSet(1,vf0) #stdout > ioGlobalStdSet(2,vf0) #stderr > logFdAdd(vf0) > > The file name can be a .sh file(for ex:io.sh) > > Then at windshell prompt type, > > --> < io.sh > > Rob Mapes wrote: > > > When I use virtual I/O, I see odd behavior. My target program is doing a ton of printf's, but on the host side, all I see are two VIO_WRITE events. A bunch of the printfs have been combined in two vio events. I need each message separately since they're status during long hardware tests. Any ideas? > > > > Thanks. > > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Devaraj Das, Tel :(91)(80)225-1554 > Hewlett Packard ISO, Ex :1180 > 29, Cunningham Road, Fax :(91)(80)220-0196 > Bangalore-560 052.(India). mailto:ddas@india.hp.com > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --------------------------- End of New-News digest ********************** From pascal@wrs.com Mon Apr 6 00:35:21 1998 From: Pascal Corbillon Date: Mon Apr 6 00:35:25 PDT 1998 Subject: Re: EXCHANGE_TIMEOUT the vxWorks Users Group Exploder wrote: > > Submitted-by nguyend2@ttc.com Fri Apr 3 09:48:35 1998 > Submitted-by: "Dzung Nguyen" > > > I'm rather frustrated with this error. I'm trying to download a large > file (2.5M) in tornado debug window using "ld < file", but dowloading > always failed and WDB always returned this error message: > > "Error while polling for events: > WTX Error 0x10197 (EXCHANGE_TIMEOUT) > > I tried to increase the cache as suggested by WRS support, but the > problem persists. Note that downloading the same file via the shell > window was always successful. > > Could anyone give me a clue? > > Thank you very much in advance. > > Dzung Nguyen > > Hi, in the shell, go in Tcl mode and type: set wtxCmdTimeout (wtxObjModuleLoad) Pascal From MSchrape@atomika.com Mon Apr 6 02:04:16 1998 From: Martin Schrape Date: Mon Apr 6 02:04:20 PDT 1998 Subject: Re: Tcl8.0 in VxWorks 5.3.1 Hi Jeff, I'm working on a TCL8.0 port. My System at a glance: VxWorks 5.3.1 on Motorola MVME 162 (68k), 8MB RAM ; local DOS File System; IOP162 Transition Module; IP Modules (DAC, ADC, Serial) from Greenstring and TEWS. Tornado 1.0.1 on NT4.0; Telnet opens tclsh; A starting point for me was the work of Chris Frank incomplete. See: . My port should run the UNIX tcl tests without failure. I'm currently working on exec and pipe mechanism. I will make my work public available when I'm through with tcl8.1 (thread interface). Other people that have worked on a TCL to VxWorks port or that are interested in a port: Matt Berney, Tektronix, Inc., Measurement Business Division, Joe VanAndel, National Center for Atmospheric Research, Vincent Chen, Real-Time Innovations, Inc., Chris Frank, Texas Instruments, or John Maline, Texas Instruments, Johan Kovacs, Sun Microsystems, /* TCL on Chorus */ For more information including the priority problem between windsh and tclsh please contact me. -martin --------------------------------------------------------------- Dipl.-Phys. Martin Schrape schrape@atomika.com Senior Software Engineer Tel. +49 89 315 891 34 Atomika Instruments GmbH Fax +49 89 315 59 21 Bruckmannring 40 www.atomika.com 85764 Oberschleissheim/Munich, Germany --------------------------------------------------------------- At 10:06 4/3/98 PST, you wrote: >Submitted-by jaa@mclean.sparta.com Fri Apr 3 10:06:37 1998 >Submitted-by: "Jeff Angielski" > > >Does anyone know how you actually invoke and run Tcl8.0 on a VxWorks >platform? Do you spawn a task? Invoke something from the shell prompt? > >Any information regarding Tcl8.0 and VxWorks would be greatly appreciated. > >Thanks in advance, >Jeff Angielski >jaa@mclean.sparta.com > From msaunders@taz.dera.gov.uk Mon Apr 6 05:24:04 1998 From: "Land Systems 4" Date: Mon Apr 6 05:24:08 PDT 1998 Subject: Re. Choosing vxWorks host ( vxWorks, vxWorks ) We run Tornado under Solaris, If you need to run RtX Windows you can display the graphics on the host by just running the client bits on your target. Pete Gardiner DERA Chertsey UK ls4@taz.dra.hmg.gb From mmcquade@aa.net Mon Apr 6 11:47:50 1998 From: "Mike McQuade" Date: Mon Apr 6 11:47:53 PDT 1998 Subject: RE: Hard Real Time CE VxWorks Early on the PowerPC wouldn't handle nested interrupts, it does now, or at least it does on the MVME-2600 boards. Even WITHOUT nested interrupts, we are only talking on the order of ~50 uSec max response time on the PowerPC, with typical response times around 5 - 6 uSec. CE on the other hand is in the 1 mS range for 'deterministic' response times. To me the bigger issues are: 1. Win32 API, MFC, et-al, can you say convoluted ? 2. With commodity software and hardware, we could have some ineresting times for the software to "GPF" - Medical Device, Oh sorry Mrs Smith, your husbands defibulator had a "GPF", we called Dr Watson, but it was too late. - You see the massive melt down of the Nuclear Plant was caused by a bad version on MFC, this was the pre service pack version. - The F-15 took an abrupt turn and crashed due to an illegal instruction, we will have this fixed in CE version 04. - Oh no someone hacked into our CE based router, I thought they used the security code from NT. I know M$ wants the market, hell I have friends that work there, and hear horror stories all the time. We have just shipped instrument #40 out of here, we are using VxWorks 5.3.1 and PowerPC MVME-2603s, we use NEARLY EVERYTHING in the OS, and on this CPU board. Our customers run our instruments 24 hours a day, they are reporting back very happy, NO lockups, NO problems. This instrument is off to the most successful start of any we have made. Our customers like the fact that its NOT DOS, or WINDOWS. When they come through and see the picture of the Mars Rover on the wall, and understand that we are using an "Industrial Strength" O/S, the same one thats used in SPACECRAFT, they are very impressed. I cannot imagine going to Win CE, we need to ship product, and ship product that is reliable. By the time MickySoft ships a stable and powerful RTOS version of CE, WindRiver will have their next version of Tornado well into the market place. I read somewhere that WRS made $38 Million in the last quarter, do you think they are not pouring massive effort into the next generation of their tools ? There will allways be markets for Wind River and others, and I believe that some people will adopt CE / Microsoft. If we are lucky, it will be our competition. Mike -----Original Message----- From: the vxWorks Users Group Exploder To: vxworks_users@csg.lbl.gov Date: Friday, April 03, 1998 4:00 PM Subject: RE: Hard Real Time CE ?? >Submitted-by bawilson@llnl.gov Fri Apr 3 14:14:05 1998 >Submitted-by: "Bruce A. Wilson" > >VxWorks Users: > Doesn't the mv1603 PowerPC operate exactly as described below with >VxWorks? Once an ISR is invoked, it runs to completion and cannot be >interrupted. I don't think that means the PowerPC is incapable of hard >realtime operation, and I don't think eliminates Windows CE as a candidate >RTOS either. >--Bruce Wilson > >>> Interrupt service routines (ISTs) at the highest priority >>> level are not preempted by any other threads. These threads continue >>> execution until they either yield or are blocked. Windows CE does not >>> support nested interrupts. This means that an interrupt can not occur >>> while a previous interrupt is being processed. > >Bruce A. Wilson >U.C. LLNL ( L-054 ) >P.O. Box 808 >Livermore, CA 94550 > From jieming@Brocade.COM Mon Apr 6 15:30:43 1998 From: jieming@Brocade.COM (Jieming Zhu) Date: Mon Apr 6 15:30:50 PDT 1998 Subject: recompiling code for VxWorks 5.3 As recommended by WindRiver, we recompiled code for VxWorks 5.3 using cc960 (rev 2.7) instead of gcc960. However, we encountered a problem where cc960 couldn't recognize i960's built-in instructions such as bswap and halt. Here is the output of the compiling: {standard input}: Assembler messages: {standard input}:110: Error: invalid opcode, "bswap". {standard input}:124: Error: invalid opcode, "halt". *** Error code 1 The following command caused the error: cc960 -mca -mstrict-align -mintel-asm -mic-compat -O2 -fno-builtin -fvolatile -Wall -ansi -pedantic -pipe -nostdinc -DCPU=I960JX -DVX_IGNORE_GNU_LIBS -c -o obj/xxx.o xxx.S We are running on the I960JX platform. Any insights why this happened? Thanks in advance. From daemon@csg.lbl.gov Tue Apr 7 04:02:23 1998 From: daemon@csg.lbl.gov Date: Tue Apr 7 04:02:26 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 7 04:02:21 PDT 1998 Subject: Re: virtual IO ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: virtual IO Date: Fri, 03 Apr 1998 12:30:49 +0800 From: Devaraj Das Organization: Hewlett Packard ISO Ltd. Message-ID: <352465F9.A669F425@india.hp.com> References: <3523127E.35F5E9EE@pacbell.net> Rob, Try this fragment of code: vf0=open("/vio/0",2,0) ioGlobalStdSet(1,vf0) #stdout ioGlobalStdSet(2,vf0) #stderr logFdAdd(vf0) The file name can be a .sh file(for ex:io.sh) Then at windshell prompt type, --> < io.sh Rob Mapes wrote: > When I use virtual I/O, I see odd behavior. My target program is doing a ton of printf's, but on the host side, all I see are two VIO_WRITE events. A bunch of the printfs have been combined in two vio events. I need each message separately since they're status during long hardware tests. Any ideas? > > Thanks. - -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Devaraj Das, Tel :(91)(80)225-1554 Hewlett Packard ISO, Ex :1180 29, Cunningham Road, Fax :(91)(80)220-0196 Bangalore-560 052.(India). mailto:ddas@india.hp.com %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% --------------------------- End of New-News digest ********************** From SMWLI@n2sun1.ccl.itri.org.tw Tue Apr 7 06:09:16 1998 From: SMWLI@n2sun1.ccl.itri.org.tw Date: Tue Apr 7 06:09:39 PDT 1998 Subject: Raw Serial line timeout To Tornado Vxworks user group Dear Sirs : Under the GDB, as I download an object code (about 600K) to my target via a raw serial line, the target server always shows API_REQUEST_TIME_OUT and the downloading fails. Is there any limitation for the raw serial line ? Could you show me the way how to solve this problem as soon as possible ? Thanks ! Yi-Ping Kao SMWLI@N2SUN1.CCL.ITRI.ORG.TW From jtmark@most.fw.hac.com Tue Apr 7 07:08:30 1998 From: "Jimmie T Marks" Date: Tue Apr 7 07:08:34 PDT 1998 Subject: symbol table TORNADO 5.3.1 Our application has real time downloads of applications. I want to kick off the executables like anyone one do from dos or unix. I am trying to use symFindByName to get the address of application_main to subsequenly spawn. Below is the sample code I am testing with. This seem to not return the address of the entry point function like I want. int test { char **pvalue, *p, ch; SYM_TYPE * ptype, a; char *ap_name = "application_man" ptype = &a; p = &ch; pvalue = &p; symFindByName (sysSymTbl, name, pvalue, ptype); cout << " pvalue = " << pvalue << " type = " << ptype << endl; } Is there a better way to execute run time downloaded executables? jtmark@most.fw.hac.com From froeber@bbn.com Tue Apr 7 08:32:44 1998 From: Fred Roeber Date: Tue Apr 7 08:32:48 PDT 1998 Subject: Re: symbol table Jimmie T Marks wrote: > > TORNADO 5.3.1 > > Our application has real time downloads of applications. I want to kick > off the executables like anyone one do from dos or unix. > > I am trying to use symFindByName to get the address of application_main to > subsequenly spawn. Below is the sample code I am testing with. This seem to > not return the address of the entry point function like I want. > > int test > { > char **pvalue, *p, ch; > SYM_TYPE * ptype, a; > char *ap_name = "application_man" > > ptype = &a; > p = &ch; > pvalue = &p; > > symFindByName (sysSymTbl, name, pvalue, ptype); > > cout << " pvalue = " << pvalue << " type = " << ptype << endl; > Method of getting name is fine. Code is not. Change: char * pvalue; symFindByName(sysSymTbl, ap_name, &pvalue, ptype); Note, pass address of variable to store address in. Also, pass the correct variable for the name. I think you got caught up in the "always slightly ambiguous" issue of parameters that are the address of a pointer instead of a pointer to a pointer. Code should work fine although you should check the return code to be safe. Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From Brent.Carlson@hia.nrc.ca Tue Apr 7 09:44:14 1998 From: Brent Carlson Date: Tue Apr 7 09:44:17 PDT 1998 Subject: VxWorks 5.2...unexplained task deletions Dear VxWorks Users: I am running some pretty complex yet mature code on VxWorks 5.2 and occassionally, I get a case where a task simply dissappears from the CPU. It does not get suspended (as one would expect if there is an exception) and it happens (very rarely I might add) in more than one task. I have written a 'software monitor task' which checks for suspended tasks (and now dissappearing tasks) and restarts them to help mitigate the problem, but it is still disturbing that it happens at all. Has anyone seen this kind of thing before? Or, do I just have a very intermittent bug to find? Comments welcome, Brent. From mcneils@applique.dh.trw.com Tue Apr 7 11:11:33 1998 From: Sean McNeil Date: Tue Apr 7 11:11:36 PDT 1998 Subject: RE: symbol table What you are doing is exactly what I used for our implementation -- almost. Here is a copy of our implementation of "system" for VxWorks: #include #include #include #include #include #define STACK_SIZE 500000 extern char *strdup (char *); int system (char *string) { char *fname; char *args[10]; char *p; int i; char *pValue; SYM_TYPE pType; p = fname = strdup (string); for (i=0; i<10; i++) { while (*p && (*p != ' ' && *p != '\t')) p++; while (*p && (*p == ' ' || *p == '\t')) *p++ = 0; if (*p && *p != '&') args[i] = p; else args[i] = NULL; } if (symFindByName (sysSymTbl, fname, &pValue, &pType)) { printf("vxwork_system() cannot find symbol %s\n", string); return -1; } taskSpawn (fname, 150, 0, STACK_SIZE, pValue, args[0], args[1], args[2], args[3], args[4], args[5], args[6], args[7], args[8], args[9]); /* Give the new "process" time to get started. */ taskDelay (200); return 0; } From mea@mclean.sparta.com Tue Apr 7 12:17:42 1998 From: "Mike Anderson" Date: Tue Apr 7 12:17:46 PDT 1998 Subject: Using Ide drives on a 486 VxWorks Greetings! OK, I usually use SCSI disks, but I'm finally getting around to trying the IDE drive on a 486 under 5.3.1. I boot to the prompt (Tornado or native target shell doesn't seem to matter) and do an ideShow. All looks good. I do the -> pBlkDev = ideDevCreate(0,0,0) ; Disk 0, take the whole disk, no offset This returns the pointer as expected. Since this is the first time that I've used this disk under VxWorks (and I don't care what was there before) I try: -> dosFsMkfs("/ide0", pBlkDev) This fails with a NULL pointer return :-(. So I try a simple program: #include #include #include char buffer [1024]; /* so I can see it from the shell */ STATUS myIdeConfig ( int drive, /* drive number of hard disk (0 or 1) */ ) { BLK_DEV *pBlkDev; IDE_RAW ideRaw; bzero(buffer, 1024); /* read the boot sector */ ideRaw.cylinder = 0; ideRaw.head = 0; ideRaw.sector = 1; ideRaw.pBuf = buffer; ideRaw.nSecs = 1; ideRaw.direction = 0; return(ideRawio (drive, &ideRaw)); } With this piece of code, I can see the disk light blinking, but the call eventually fails. The ideDrv() call is being invoked with the 0 option to get the info from the BIOS (I've tried the "1" option as well with the drive info structure with the same results). This disk and PC combination work fine from DOS. Is there anything obvious that I'm missing? TIA, ============================================================================ === Real-Time System Development, Integration, Training and Services Mike Anderson mea@mclean.sparta.com Chief Engineer http://www.mclean.sparta.com SPARTA, Inc. V: (703) 448-0210 F: (703) 893-5494 "Software development is like making a baby... You can't make a baby in one month by impregnating nine women. Some things just take time." The opinions are mine... no one else would want to claim them ;-). ============================================================================ === From bcrozier@fci.com Tue Apr 7 16:35:18 1998 From: bcrozier@fci.com (Bruce Crozier) Date: Tue Apr 7 16:35:22 PDT 1998 Subject: WDB over serial port - loadFlashElf() ? Fellow vxWorks'ers, Greetings! Hopefully someone can help me with my question ... How can I get 'loadflashElf' working in my environment ? I am running Tornado 1.0.1 on a Solaris host, with a PowerPC target, and am trying to use Tornado tools over the console serial port to the target, (since I don't have an Ethernet connection in this case). I include the following in my config.h file #undef WDB_COMM_TYPE #define WDB_COMM_TYPE WDB_COMM_SERIAL #undef WDB_TTY_CHANNEL #define WDB_TTY_CHANNEL 0 #undef WDB_TTY_BAUD #define WDB_TTY_BAUD 38400 #undef WDB_TTY_DEV_NAME #define WDB_TTY_DEV_NAME "/tyCo/0" then, 'make vxWorks.st_rom', and program that into flash on my PPC target. It boots, and prints the 'WDB Ready' message on the console serial port. Launcher / Target / Create is set up with core = "vxWorks.st" and Backend = wdbserial. WindSh comes up fine, and I can execute most commands just fine (e.g. 'ld <', 'ls', 'pwd', etc). However, when I try to execute 'loadFlashElf()', it complains that it "cannot open the file". ---------------------------------------------- -> loadFlashElf "vxWorks.st_rom", 1, 0x100 value = -1 = 0xffffffff Sorry, can't open file! ---------------------------------------------- Any help would be appreciated ! Thanks, Bruce PS: One (possible) clue is that the wdb logfile reports: Warning: Unable to start synchronization on target If I've selected that option in the target /create menu. From daemon@csg.lbl.gov Wed Apr 8 04:01:37 1998 From: daemon@csg.lbl.gov Date: Wed Apr 8 04:01:41 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 8 04:01:36 PDT 1998 Subject: Re: Hard Real Time CE ?? Subject: IEEE RTSS 98 -- Submission Deadline May 1 Subject: ATA driver ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Hard Real Time CE ?? Date: Fri, 03 Apr 1998 07:10:58 GMT From: wkdugan@ix.netcom.com (Bill Dugan) Organization: Netcom Message-ID: <352886c6.9518569@nntp.ix.netcom.com> References: <3.0.32.19980402103005.00a33e20@38.169.89.102> On Thu, 02 Apr 1998 10:30:06 -0800, Brian wrote: >http://techweb.cmp.com/eet/news/98/1001news/windowsce.html/ > >Hi: > >This is not strictly a technical question but I would >very much welcome other's thoughts regarding the >above announcement about Windows CE going hard-real-time, >as well as Integrated Systems intention to ally with MSFT. Is it significant that this story is dated April 1st? --------------------------- Newsgroups: comp.os.vxworks Subject: IEEE RTSS 98 -- Submission Deadline May 1 Date: 8 Apr 1998 03:07:43 GMT From: Jennifer Hou Organization: Ohio State University Message-ID: <6geplv$10p$1@charm.magnus.acs.ohio-state.edu> Followup-To: poster ======================================================================= CALL FOR PAPERS The 19th IEEE Real-Time Systems Symposium Madrid, Spain December 2-4, 1998 Sponsored by The IEEE Computer Society Technical Committee on Real-Time Systems ======================================================================= SCOPE OF THE CONFERENCE RTSS '98 brings together a diverse body of researchers and developers, to advance the science and practice of real-time and embedded systems. All papers on real-time, embedded or reactive systems are welcome, including (but not limited to) the following topics: * Real-time and embedded operating systems. * Systems design and analysis: theories, methods and tools. * Scheduling techniques: CPUs, devices, networks, end-to-end. * Programming languages for real-time and embedded systems. * Specification, verification and automated analysis. * Middleware and APIs for real-time and embedded systems. * Performance evaluation: theory, analysis and tool support. * Domain-specific architectures for embedded systems. * Instrumentation, profiling, testing and debug support. * Support for COTS-based integrated systems. * Fault-tolerance, reliability and safety. * Program analysis and tools. * Object-oriented languages: designs, programs, interfaces. * Real-time and reactive databases and file systems. * Computer networks and communications. * Signal processing, control and robotics. * Digital video, audio, animation and multimedia. Papers on these or other relevant topics are solicited for RTSS '98. Of particular interest are case-study reports on experimental results, from any core application area in real-time, embedded and/or reactive systems. ======================================================================= SUBMISSION GUIDELINES Papers should describe original research (i.e., not published elsewhere), and should not exceed 20 double-spaced pages. All accepted submissions will appear in the proceedings published by IEEE, with the committee recommending a selection of the best papers for publication in a journal. If possible, submissions should be made electronically, either in postscript or PDF format. Additional details on submission guidelines will be posted at the RTSS'98 Home Page: http://www.cs.umd.edu/~rich/rtss98/ Electronic submissions are preferred; however postal submissions will be accepted for review, provided they arrive by the Submission Deadline of May 1, 1998. All authors taking this option should mail eight (8) copies of their submitted papers to the Program Chair: Richard Gerber Email: rich@cs.umd.edu Department of Computer Science URL: www.cs.umd.edu/~rich University of Maryland Phone: +1-301-405-2710 College Park, MD 20742 USA Fax: +1-301-405-6707 ======================================================================= IMPORTANT DATES * May 1, 1998 -- Deadline for paper submissions * July 25, 1998 -- Notification of acceptance * September 1, 1998 -- Final paper due * December 2-4, 1998 -- RTSS '98, Madrid, Spain ======================================================================= EXHIBITION, WORKSHOP AND WORK-IN-PROGRESS SESSIONS Exhibition and Show: RTSS '98 will include an industrial exhibition in a centrally located space, for vendors to demonstrate state-of-the-art systems, development tools and applications; where RTSS attendees can engage in technical discussions with product engineers and developers; and where company representatives meet (and potentially recruit) young researchers specializing in real-time and embedded systems. To reserve space for the exhibition, please contact the RTSS '98 Industrial Chair, Dr. Alan Burns (burns@minster.cs.york.ac.uk). Workshop: RTSS '98 will co-host a workshop on December 1, 1998, directly before the conference. The focus of the workshop will be a "hot topic" of special interest to researchers and developers of real-time systems. Recent RTSS workshops were on topics such as Middleware/APIs (1997) and Multimedia Systems (1996). More information on the 1998 workshop topic will be announced shortly, and publicized on the conference home page. Work-in-Progress Session: As in previous years, RTSS '98 will include a Work-In-Progress (WIP) session, featuring short presentations on new and evolving work. Accepted WIP papers will be included in a special proceedings, and distributed to RTSS'98 conference participants. The proceedings will then be published electronically on the IEEE-CS TC-RTS Home Page. WIP papers will be due approximately one month before the Symposium. ======================================================================= ORGANIZING COMMITTEE General Chair: Kwei-Jay Lin, University of California, Irvine Program Chair: Richard Gerber, University of Maryland Finance Chair: Walt Heimerdinger, Honeywell Technology Center Registration Chair: Linda Buss Local Arrangements Chair: Angel Alvarez, Universidad Politecnica de Madrid Local Treasurer: Juan A. de la Puente, Universidad Politecnica de Madrid Publicity Co-Chairs: Alejandro Alonso, Universidad Politicnica de Madrid (Europe) Chao-Ju Jennifer Hou, Ohio State University (Americas) Joseph Ng, Hong Kong Baptist University (Asia/Pacific) Industrial Chair: Alan Burns, University of York Ex-Officio: (RTS-TC Chair) Doug Locke, Lockheed Martin Corporation ======================================================================= PROGRAM COMMITTEE James Anderson (University of North Carolina) Azer Bestavros (Boston University) Sanjoy Baruah (University of Vermont) Giorgio Butazzio (Scuola Superiore e Sant'Anna) Gerhard Fohler (Malardalen University) Michael Gonzalez Harbour (Universidad Cantabria) Jeffrey Hollingsworth (University of Maryland) Seongsoo Hong (Seoul National University) Farnam Jahanian (University of Michigan) Kevin Jeffay (University of North Carolina) Hermann Kopetz (Vienna University of Technology) Kim G. Larsen (Aalborg University) Insup Lee (University of Pennsylvania) Jane W.S. Liu (University of Illinois) Keith Marzullo (University of California at San Diego) Sang Lyul Min (Seoul National University) Al Mok (University of Texas at Austin) Ragunathan Rajkumar (Carnegie Mellon University) Jennifer Rexford (AT&T Research) Manas Saksena (Concordia University) Bran Selic (ObjectTime, Ltd.) Andy Wellings (University of York) David Wilner (Wind River Systems) Sergio Yovine (CNRS/VERIMAG) Hui Zhang (Carnegie Mellon University) ======================================================================= --------------------------- Newsgroups: comp.os.vxworks Subject: ATA driver Date: Tue, 07 Apr 1998 16:48:52 -0600 From: radcliff@jps.net Organization: Deja News - The Leader in Internet Discussion Message-ID: <6ge704$93n$1@nnrp1.dejanews.com> Reply-To: cory@synerdyne.com I have noticed in the documentation that all references to the ATA driver in VxWorks were coupled with references to the x86 architecture. I am hoping that this is due to the fact that the BIOS on the x86 platform always expects to see an IDE drive with an ATA interface. But the lack of other references to the ATA driver in other contexts (such as the Motorola specific or PPC specific) platforms don't support ATA. Is this true? Or is it only true because other platforms don't even have the interfaces so why mention it? The reason it's a concern of mine is because I want to use an ATA device on a non-x86 platform. So I need to know if the ATA driver is supported on all platforms. - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- End of New-News digest ********************** From bpringle@teklogix.com Wed Apr 8 07:43:52 1998 From: Bill Pringlemeir Date: Wed Apr 8 07:44:00 PDT 1998 Subject: Exception handling. Hello, I am trying to use excIntConnect on the PowerPC. The default handler is excExcHandle. This routine prints out task and PC information and suspends the task. It appears that the excEnt() routine sets up a stack frame and this information is passed to the excExcHandle function. However, there is no definition that I can find of this frame. The most obvious place would seem to be arch/ppc/excPPClib.h. Also, the excVecGet() function will return excExcHandle before I connect to it. Yet I can not seem to chain to this exception. Is assembler needed to do this? How is anyone suppose to implement there own Exception handling routines under VxWorks? I think that there are many interesting applications here. Thanks, Bill From wheat@wg.com Wed Apr 8 08:11:24 1998 From: Lee Wheat Date: Wed Apr 8 08:11:28 PDT 1998 Subject: Re: Using Ide drives on a 486 vxWorks...vxWorks...vxWorks... we use ide disks all of the time in our stuff on x86 platforms. under 5.3 all it took to mount the disk so we could do fileio was a call like: usrIdeConfig (0, "/"); with #define INCLUDE_IDE in the config.h file. this would mount the first disk (or as DOS would say, C:) as /. we could then access stuff, like the autoexec.bat file as /autoexec.bat from within our software. under 5.3.1, wind river added support for ata drives so we now use: usrAtaConfig (0, 0, "/"); with #define INCLUDE_ATA to get the same effect. hope this helps, lee wheat wheat@wg.com From cgrames@mdc.com Wed Apr 8 09:25:10 1998 From: Charlie Grames Date: Wed Apr 8 09:25:14 PDT 1998 Subject: Zip Drive Support VxWorks 5.3.1 MVME2604 1.1/4 All, Has anyone ever tried to hang an Iomega SCSI Zip drive from a VxWorks target? Do you need a special driver? I am considering hanging it from a Motorola MVME2604 board. Thanks for any information you might have. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com From johill@lanl.gov Wed Apr 8 09:27:23 1998 From: Jeff Hill Date: Wed Apr 8 09:27:26 PDT 1998 Subject: RE: VxWorks 5.2...unexplained task deletions vxWorks > I am running some pretty complex yet mature code on VxWorks 5.2 and > occassionally, I get a case where a task simply dissappears from the > CPU. It does not get suspended (as one would expect if there is an > exception) and it happens (very rarely I might add) in more than one > task. I have written a 'software monitor task' which checks for suspended > tasks (and now dissappearing tasks) and restarts them to help mitigate the > problem, but it is still disturbing that it happens at all. This happens if the task calls exit() or it calls assert(0). We frequently replace the stock WRS assert() with our private version that calls taskSuspend() so that we get a post-mortem. Jeff ______________________________________________________ Jeffrey O. Hill Internet johill@lanl.gov LANL MS H820 Voice 505 665 1831 Los Alamos NM 87545 USA FAX 505 665 5107 From John_W_Cosgrove@res.raytheon.com Wed Apr 8 11:48:43 1998 From: John_W_Cosgrove@res.raytheon.com Date: Wed Apr 8 11:48:47 PDT 1998 Subject: MVME 2604, vxWorks and not booting Hi, Folks, Are there any known problems with the MVME 2604-2141 that would cause it not to boot after Loading vxWorks over the ethernet. The problem is not a hard failure but occurrs on all three systems I have setup with a varing degree of repeatitivity. One systems boots 99.9% of the time, one boots about 85% and the other about 66% on the time. This is annoying when you are ready to try and sell off a mission critical system that may or may not boot. The error manifests itself as either a dead stop after the vxWorks "Starting at 0x100000" or a tRoot task program exception (located in strcpy of vxWorks). This occurs after a "SYSRESET assertion" reset. No user code has been executed at this point, only vxWorks startup code. My configuration is: MVME 2604-2141 VxWorks 5.3.1 & vxWorks BSP 1.1/4 w/EXTENDED_VME enabled booting over the ethernet from an HP Computer using tftp The two systems with the worst record are on private (just the HP and 2604) lans. If anyone knows of any problems/fixes, I would greatly appreciate the description (and solution, if avaiable). John Cosgrove Raytheon (401)842-4167 (desk) (401)842-3511 (lab) jwc_NOSPAM@ssd.ray.com Pls remove the _NOSPAM to respond to my messages. From Kenneth.Lin@Australia.Boeing.com Wed Apr 8 23:13:19 1998 From: "Lin, Kenneth" Date: Wed Apr 8 23:13:22 PDT 1998 Subject: Writing file mark Hi, I'm using SCSI tape drive to record a long sonar data. I used scsiPhsyDevIdGet to get the physical device id of tape unit. I used scsiSeqDevCreate to initialise the sequetial device. Then I used tapeFsDevInit to initialise th tape file system. To record the data, I then called "open" with write only option. Data recording then is done by calling "write". I also write a "short file mark" to the tape every 5 minutes of data recording. Everything seemed fine. But every now and then, scsiWrtFileMarks failed with exception 768. I run Tornado on Unix host connected to a target power PC 603. Windshell is used to test the program. The exception Stack Frame Contents are the following vecOffset 768 -error 0 dar 167774776 dsisr 45360 fpcsr 15867656 Does any one have a similar problem before? Does any one know what could be going wrong? From rtp.co.uk!ihw@rtp.co.uk Thu Apr 9 00:45:40 1998 From: Ian Willats Date: Thu Apr 9 00:45:43 PDT 1998 Subject: Zip drive support Charlie Grames asked: > Has anyone ever tried to hang an Iomega SCSI Zip drive from a VxWorks target? Do > you need a special driver? I believe people have used Iomega Jaz drives successfully with the SCSI-2 software, and would assume that the firmware on a SCSI Zip was similar so it "should just work" without any special drivers. You should be able to use the scsiIoctl() routine to issue commands specific to removable devices, such as Prevent/Allow Medium Removal. If you have any problems using scsiAutoConfig() or scsiPhysDevCreate() with default arguments, it might be worth trying scsiPhysDevCreate() with explicit settings for the and arguments. I know there have been some problems with this (for other types of drive) because the SCSI-2 software is not clued up about all the possible SCSI device types the Inquiry command might report. HTH Ian --------------------------------------------------------------- Ian Willats e-mail: mailto:ihw@rtp.co.uk Real-Time Products Ltd. direct: +44 (0) 121 234 6637 Chancery House, tel: +44 (0) 121 234 6600 8 Edward Street, Birmingham. fax: +44 (0) 121 234 6611 B1 2RX. England. web: http://www.rtp.co.uk --------------------------------------------------------------- From daemon@csg.lbl.gov Thu Apr 9 04:02:44 1998 From: daemon@csg.lbl.gov Date: Thu Apr 9 04:02:48 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 9 04:02:43 PDT 1998 Subject: Re: Dynamic linking of C and C++ code ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dynamic linking of C and C++ code Date: Wed, 8 Apr 1998 15:07:29 -0400 From: "Joshua Yoo" Message-ID: <352b93e1.0@news.ronconet.com> References: <35252C01.2B96BEFD@bnr.ca> Vittal, Chiradeep (EXCHANGE:CAR:9H24) wrote in message <35252C01.2B96BEFD@bnr.ca>... >Hi, > >I have an object file, lets say x.out compiled using the gnu C >compiler. There is an unresolved reference to 'a_b_c'. >'a_b_c' happens to be a global defined in y.cpp (i.e., a C++ >program). I load in x.out: > >-> ld < x.out >Undefined symbol: a_b_c (binding 1 type 0) >Then I load in y.out: >->ld < y.out >->lkup "a_b_c" >a_b_c 0x0067dc64 data (y.out) >_GLOBAL_$I$a_b_c 0x0067b688 text (y.out) > >If I run the routines in x.out, they still don't see the definition >of 'a_b_c'. >y.cpp has been munched and the loader's constructor/destructor strategy >is automatic. >Loading y.out before x.out works fine, as well as statically >linking x.out, y.o and munching the result. Is this the right behavior? >Why isn't the loader resolving the reference to 'a_b_c' in the above >case? > >Is there any way to make this work? > >Thanks >-- >Chiradeep Vittal >Software Designer >Multimedia Communication Systems >Nortel The way I understand dynamic Linking is that: Before you link the object files, each object file keeps its own symbol pools used in the associated source code. Linking process finds out the address ( offset from refence address). When you load x.out, Loader does dynamic link to objects you are loading. Because y.o module does not exist, shell prints our error message such as "Undefined symbol" then leaves arbitrary ( I guess ) number in the place where a_b_c is supposed to be. Even you load y.o that includes a_b_c after, x.out does not know where a_b_c is. x.out should be linked again to find out the address of a_b_c. --------------------------- End of New-News digest ********************** From larry.dalessandro@ae.ge.com Thu Apr 9 07:54:46 1998 From: "DAlessandro, Larry (GEAE)" Date: Thu Apr 9 07:54:49 PDT 1998 Subject: MMU Mapping w/177 cards Hello all, I'm using some Mot 177 68060 cards w/vxWorks 5.3 & Tornado 1.01. I need access to A32 VME space. Here's the question: with basic MMU support enabled, can I define a range of A32 space available in the sysPhysMemDesc table, or do I need to do it on a device by device basis? What I would like to do is be able to have a reserved area of A32 address space that I could plug devices in and out of without having to rebuild the kernel every time, i.e. 0x40000000 - 0x50000000. This would be handy because I plug a lot of different A32 devices in and out. Since a lot of the time I'm trying to replicate problems from other systems, I don't want to have to touch the boards in term of addressing or anything else, just in case the addressing is the problem. I've tried this with smaller memory ranges, i.e. 0x40000000 - 0x40100000 and it seems to work fine. But as soon as I expand it out by 0x10000000 the processors *never* boot. Am I attempting to do the impossible? Or am I missing something really fundamental (probably). In any event, WRS couldn't answer this. I've got a two+ week old TSR on it. Any light shed greatly appreciated. Thanks Larry D'Alessandro x4-1852 / (781)-594-1852 / DialComm 8*263-1852 Fax (781)-594-4703 e-mail larry.dalessandro@ae.ge.com MZ14008, 1000 Western Ave Lynn MA 01910 From Rick.Rorex@vmic.com Thu Apr 9 08:39:08 1998 From: Rick Rorex Date: Thu Apr 9 08:39:12 PDT 1998 Subject: FTP Server password VxWorks Where does the FTP server on VxWorks get it's user and passwd information for validation? I am trying to FTP into a VxWorks CPU and the server keeps requesting a user name and a passwd. The host doesn't have an FTP server so I can't ftp from the VxWorks CPU. I used what was included in the boot parameters and it didn't work. I also used iam and set up a user and passwd and it still didn't work. I do not have INCLUDE_SECURITY in my build. Any help would be appreciated. Thank You --------------------------------------------------------------------- Ricky Rorex VME Microsystems International Corporation 12090 South Memorial Parkway Huntsville, Al 35803-3308 (205)650-8296 EMAIL - Rick.Rorex@vmic.com From Greg.J.Marshall@lmco.com Thu Apr 9 09:51:04 1998 From: Greg J Marshall Date: Thu Apr 9 09:51:07 PDT 1998 We have a Motorola 2604 board/BSP 1.1/4 running VxWorks 5.3.1. WindView has been installed and we are having problems getting accurate timing results. What should be included to support WindView on this board? We added the following includes after installing WindView and it still don't work! INCLUDE_INSTRUMENTATION INCLUDE_WINDVIEW INCLUDE_TIMESTAMP Should we be using INCLUDE_Z8536_TIMESTAMP? thanks, Greg Marshall Lockheed Martin Syracuse, NY From larry.dalessandro@ae.ge.com Thu Apr 9 11:46:05 1998 From: "DAlessandro, Larry (GEAE)" Date: Thu Apr 9 11:46:08 PDT 1998 Subject: FW: Booting multiple targets across the backplane > Hello all, > > Sorry if this shows up twice, I mis-posted the first time. > > I'm wondering if anyone else has seen this: > > I run a system with 4 mvme177 68060 processor cards. I have the wrs supplied > bootroms for 5.3 > with Tornado 1.01. I boot the first target via ethernet and the next three > targets using the sm network on the backplane. I've been using this > configuration for years going back to bpConnect in 5.02. Here's the joke: > Whenever I have the board with 5.3 bootroms in slot 1, I cannot boot the other > targets through it. When I put a board with 5.2 bootroms in slot 1 I can load > a 5.3 kernel onto it, and boot my other three boards (all with 5.3 bootroms) > through the smConnect. I know another group that uses 167 68040 cards that > had to give up making smConnect work and supply each target with its own > ethernet connection. I have a lot of reasons for not wanting to do this, not > the least of which is that it would be nice to see a function I've been using > for the last 5 years still work. > > Anyone else seen this? I'm currently in the wrs tech support queue for 3+ > weeks and counting. > > Any and all suggestions appreciated. > > Larry D'Alessandro > > x4-1852 / (781)-594-1852 / DialComm 8*263-1852 > Fax (781)-594-4703 > e-mail larry.dalessandro@ae.ge.com > MZ14008, > 1000 Western Ave > Lynn MA 01910 > From froeber@bbn.com Thu Apr 9 13:46:44 1998 From: Fred Roeber Date: Thu Apr 9 13:46:47 PDT 1998 Subject: Re: MMU Mapping w/177 cards larry.dalessandro@ae.ge.com wrote: > I'm using some Mot 177 68060 cards w/vxWorks 5.3 & Tornado 1.01. I need access > to A32 VME space. Here's the question: with basic MMU support enabled, can I > define a range of A32 space available in the sysPhysMemDesc table, or do I need > to do it on a device by device basis? What I would like to do is be able to > have a reserved area of A32 address space that I could plug devices in and out > of without having to rebuild the kernel every time, i.e. 0x40000000 - > 0x50000000. This would be handy because I plug a lot of different A32 devices > in and out. Since a lot of the time I'm trying to replicate problems from other > systems, I don't want to have to touch the boards in term of addressing or > anything else, just in case the addressing is the problem. I've tried this with > smaller memory ranges, i.e. 0x40000000 - 0x40100000 and it seems to work fine. > But as soon as I expand it out by 0x10000000 the processors *never* boot. > > Am I attempting to do the impossible? Or am I missing something really > fundamental (probably).. The problem you are running into is that the MMU page register setup code on the 680x0 processors is REAL slow. When you try to map a large region of memory, the initialization function takes a long time. I haven't tried to map 256MB like you are since even smaller regions can take minutes to set up. The easiest thing to do for this problem is to use one of the two "transparent translation" registers in the 68060 to allow access to the whole upper half of the memory address space. I don't have a BSP for a MVME177 card but in the MVME162 (68040) BSP, there is some code that shows how to set up these registers in the sysALib.s file in the BSP directory. The other thing you could try is to just turn off the data cache to avoid problems messing with a external boards (use cacheDisable function). Hope this helps. Fred -- | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From John.Ahrens@PSS.Boeing.com Thu Apr 9 14:06:12 1998 From: "Ahrens, John L" Date: Thu Apr 9 14:06:15 PDT 1998 Subject: Tornado - License Manager Problems I am trying to get Tornado running on my Sparc and I get the launcher up, but when I try to connect to a target, using VxSim I get a license not found error. The license manager is running and the license file is in /opt/wind/.wind/license. It contains 10.lic and 20.lic. Any clues as to what to look for, what's wrong? TIA. -- I don't speak for my employer. john@misfit.ca.boeing.com -- I don't speak for my employer. john@misfit.ca.boeing.com From aguilar@popler.lansce.lanl.gov Thu Apr 9 14:48:52 1998 From: aguilar@popler.lansce.lanl.gov (Ron Aguilar) Date: Thu Apr 9 14:48:55 PDT 1998 Subject: Development Methodology VxWorks Users, Please forgive me as this in not a direct VxWorks question, but I felt that this community would have ample experience in real-time object oriented development methodology. Has anyone used the Shlaer-Mellor method for real-time project lifecycle? I am interested in pros/cons. I would also like to know what other methods people are using for OOA/OOD. Thanks, 0000,0000,8080 Ron Aguilar Los Alamos National Laboratory Manuel Lujan Jr. Neutron Scattering Center LANSCE-12, MS H805 Los Alamos, NM 87545 505-667-8369 505-665-2676 (fax) rgaguilar@lanl.gov From carl@themis.com Thu Apr 9 15:23:48 1998 From: "Carl C. Chesbrough" Date: Thu Apr 9 15:23:51 PDT 1998 Subject: Re: Tornado - License Manager Problems John, You may need an environment variable set. For csh (in .cshrc): setenv LM_LICENSE_FILE /opt/wind/.wind/license/10.lic HTH, -Carl. ******************************************************************** * * * Carl C. Chesbrough Telephone: (510) 252-0870 x 126 * * Themis Computer Facsimile: (510) 490-5529 * * 3185 Laurelview Court E-Mail : carl@themis.com * * Fremont, California 94538 * * * ******************************************************************** > I am trying to get Tornado running on my Sparc and I get the launcher > up, but when I try to connect to a target, using VxSim I get a license > not found error. The license manager is running and the license file is > in > /opt/wind/.wind/license. It contains 10.lic and 20.lic. > > Any clues as to what to look for, what's wrong? From don.blake@lmco.com Thu Apr 9 15:39:26 1998 From: "Donald R. Blake" Date: Thu Apr 9 15:39:30 PDT 1998 Subject: Hang when using Tornado target agent I'm running VxWorks 5.3.1 with Tornado 1.0.1 on a PowerPC. I have new PMC I/O hardware on which I'm running contention testing. I'm beating on this pretty hard - doing lots of DMA transfers and interrupts. I have a single ISR which "wakes-up" one of two tasks spawned to handle I/O and DMA interrupts. I find my contention test runs fine when kicked off from the console or a rlogin session. However, when I run this test from the Tornado WindShell or CrossWind, the SBC will eventually lock up. I was seeing WTX time-out messages until I lowered the priority of my interrupt tasks. I don't get the WTX time-out message any more but I still get lock-ups after running for maybe an hour or more. The target agent task is running at priority 3, net task is running at priority 50. My I/O interrupt task is running at priority 5 and the DMA interrupt task is running at priority 75. One experiment I've yet to try is changing the I/O task priority to be a lower priority (higher number) than net task (currently 50). I suspect I'm experiencing a problem with the target agent or net task (or both). Anyone have any experiences like this or any ideas? Thanks, Don -- Donald R. Blake Sr. Programmer Lockheed Martin Federal Systems 1802 State Route 17C Owego, NY 13827-3994 From matsuda@mach.kokusaidenki.co.jp Thu Apr 9 21:58:49 1998 From: matsuda@mach.kokusaidenki.co.jp (Mitsuhiro Matsuda) Date: Thu Apr 9 21:58:53 PDT 1998 Subject: Re: Tornado - License Manager Problems In article <9804092106.AA23408@csg.lbl.gov> vxwexplo@lbl.gov writes: >> Submitted-by John.Ahrens@PSS.Boeing.com Thu Apr 9 14:06:12 1998 >> Submitted-by: "Ahrens, John L" >> >> I am trying to get Tornado running on my Sparc and I get the launcher >> up, but when I try to connect to a target, using VxSim I get a license >> not found error. The license manager is running and the license file is >> in >> /opt/wind/.wind/license. It contains 10.lic and 20.lic. >> >> Any clues as to what to look for, what's wrong? I had same situation when I upgraded Tornado 1.0 to Tornado 1.0.1. Please check the license manager parameters. Following are my configuration. I suggest you should also see target server log file. > WIND_BASE=/usr1/wind > ${WIND_BASE}/host/sun4-solaris2/bin/wlmd -e ${WIND_BASE}/.wind/license \ > -m 50k -s0 -l ${WIND_BASE}/.wlmd.log -- Mitsuhiro Matsuda(matsuda@mach.kokusaidenki.co.jp) Kokusai Electric Co., Ltd. Toyama Works From daemon@csg.lbl.gov Fri Apr 10 04:03:28 1998 From: daemon@csg.lbl.gov Date: Fri Apr 10 04:03:32 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 10 04:03:27 PDT 1998 Subject: CodeWarrior for PowerPC VxWorks ? Subject: Re: MVME3604 & VME Interrupts ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: CodeWarrior for PowerPC VxWorks ? Date: Wed, 08 Apr 1998 09:13:46 -0600 From: hwa-jin@npal.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <6gg0mp$vt7$1@nnrp1.dejanews.com> Hi! Have you used CodeWarrior PowerPC compiler for VxWorks? If so, can you tell us your experience with it? Thanks! - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MVME3604 & VME Interrupts Date: Wed, 8 Apr 1998 07:29:06 -0700 From: "Tim Meier" Organization: Lawrence Livermore National Laboratory Message-ID: <6gg1ju$jfo$1@lll-winken.llnl.gov> References: <6gbptt$9cu$1@lll-winken.llnl.gov> John R. Cobarruvias wrote in message ... >Hum......sysIntEnable()? Possibly? > Yes, I am using it. (See first line of my original Post). I can generate VME interrupts just fine. I have verified this with a Bus Analyzer. Now I need to be able to detect and handle them. I am using what I consider to be standard, almost boiler plate, code - as shown below. I don't get an 'intConnect()' failure, so I think something is getting installed, just not connected up to my desired interrupt. In fact, when I generate the interrupt, I see the message; "bad vme interrupt 0" which I traced back to code within "universe.c". I think this is the default interrupt handler, and the error is due to an invalid or un-decodable Interrupt Vector. This is what makes me think I have to use some special offset or other method for installing my Interrupt Handler. Is this a PPC Thing? ============================================================== void I_watch(void) { int i, j; STATUS connected; i = 123; if((connected = intConnect(INUM_TO_IVEC(INTERRUPT_VECTOR_NUM), (VOIDFUNCPTR)InterruptHandler, GlobalInterruptCounter)) == ERROR) logMsg("**** intConnect failed *****\n", 0, 0,0,0,0,0); else { for(i= 0; i < ITER1; ++i) { for(j = 0; j < LONG_TIME; ++j) { logMsg("NP\n", 0,0,0,0,0,0); taskDelay(ONE_SECOND/6); } } } logMsg("\n****** fgi_watch exited ********\n", 0,0,0,0,0,0); } void InterruptHandler(int arg) { int i; GlobalInterruptCounter++; logMsg("******* Caught Interrupt! ********\n", 0,0,0,0,0,0); for(i = 0; i < 5; ++i) logMsg("** Interrupt Processing **\n", 0,0,0,0,0,0); } =========================================== Tim Meier meier3@llnl.gov --------------------------- End of New-News digest ********************** From daemon@csg.lbl.gov Sat Apr 11 04:01:25 1998 From: daemon@csg.lbl.gov Date: Sat Apr 11 04:01:29 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 11 04:01:23 PDT 1998 Subject: HELP: Defining paths for ldsparc?!? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: HELP: Defining paths for ldsparc?!? Date: Tue, 07 Apr 1998 14:01:32 -0400 From: "Jeffrey J. Mathes" Organization: GTE Message-ID: <352A69FB.754E27D5@gsc.gte.com> Hey all, Is there any way, from the command line, to tell ldsparc where to look for object files? i.e., x number of people can build in their /home/username directories, but we only want to have one place where our object files are stored, say /files/objects, thus eliminating multiple copies of object files in everyone's home directories. Any help will be much appreciated. Thanks. - - Jeff Mathes jeffrey.mathes@gsc.gte.com --------------------------- End of New-News digest ********************** From daemon@csg.lbl.gov Sun Apr 12 04:01:41 1998 From: daemon@csg.lbl.gov Date: Sun Apr 12 04:01:44 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 12 04:01:39 PDT 1998 Subject: Re: filesystems ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: filesystems Date: Thu, 09 Apr 1998 10:56:50 -0400 From: "John W. Edwards" Organization: Orbital Sciences Corporation Message-ID: <352CE1B1.2E846DF7@oscsystems.com> References: <6ggpea$t8$1@nnrp1.dejanews.com> arnulf@ct.med.ge.com wrote: > I am working on an application that will need to strip incoming data across > multiple ultra scsi drives. > > Has any seen a filesystem for vxWroks that will do this? > > Does anyone have any experience with writing and installing a filesystem layer > for vxWorks? > > Thanx, > Roy > Boy, I'm right in the middle of doing this myself. My research has found only two alternatives so far. 1. Programmed Logics StackVM which implements RAID0 through RAID5. For our application it seemed a little much. Check them out @: http://www.plc.com 2. Storage Concepts FibreRAID product. This is a RAID which appears to an FCP/SCSI controller as a single SCSI device. All the RAID functionality is taken care of within the FibreRAID chassis. It implements RAID3. http://www.storageconcepts.com I am leaning toward FibreRAID right now. The StackVM software seemed like it would require a much higher level of software development, slowing our products development time. Regards, - -- John W. Edwards, Sr. Software Eng Orbital Sciences Corporation / Fairchild Defense Germantown, MD USA JohnEdwards@oscsystems.com --------------------------- End of New-News digest ********************** From daemon@csg.lbl.gov Mon Apr 13 04:01:05 1998 From: daemon@csg.lbl.gov Date: Mon Apr 13 04:01:09 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Apr 13 04:01:03 PDT 1998 Subject: Xwindow port ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Xwindow port Date: Fri, 10 Apr 1998 09:46:39 -0600 From: cwilli03@harris.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <6glbcf$dcn$1@nnrp1.dejanews.com> Has anyone ported X11R6 Xlib to VxWorks. I have been having problems compiling the X11R6.3 distribution. Goal Port X11R6.3 Xlib and X extension to VxWorks (X extension has the Shape feature for transparent windows) There ~200 files for Xlib Development Systems: hardware: Sun Sparc Ultra-2 OS Solaris 2.5.1 Tools Green Hills C compiler and Multi GNU gcc 2.7.x with -m680x0 Porting Platform: OS: VxWorks 5.x for a 68K board Source: OpenGroups X11R6.3 distribution obtained from ftp.x.org Porting approaches 1. modify makefiles that came with X distribution 2. use Green Hills Multi In the X documentation there are a set of files that need to be modified Imakefile, site.def, host.def, and (since we are using Vxworks) generic.cf but there is no detail description of what to change in these files. I searched to the outer reaches of the internet and have found minimal information. Using Green Hills Multi I compiled each program under /xc/lib/X11 until I ran into an error. The errors are, cant find "*.h" files, in which case I just replace "<>" with the direct path to the "*.h" file. Other errors are Multiple defined declarations. There are conditional compilation directive embedded in the code for some of the include statement as well. So use of an include is dependent on info from the compiler. The process doing this is slow. Is there a more direct way of doing this? Are there other approaches? Thanks cw PS I did get the X11r3 version and I am having the same problem. You can email me directly. - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- End of New-News digest ********************** From wheat@wg.com Mon Apr 13 07:44:42 1998 From: Lee Wheat Date: Mon Apr 13 07:44:46 PDT 1998 Subject: disabling icmp echo vxWorks...vxWorks...vxWorks... is there a(n) (un)documented global variable or routine that allows one to disable vxwork's ability to respond to ICMP Echo (ping) frames? thanks, lee wheat wheat@wg.com From lars.antback@pullmax.se Mon Apr 13 23:02:06 1998 From: lars.antback@pullmax.se Date: Mon Apr 13 23:02:10 PDT 1998 Subject: How to catch loadModule() errors ? Hi VxWorkers ! I am currently trying to get my system running stand-alone as we want it to run when delivered. We are going to use a dynamic system configuration which will load modules using loadModule(). The question is how to catch if there is any undefined symbols in the module. If I load a module with any undefined symbols the symbols are displayed on the console but there is no warning that can be checked by the program. The intent is not to have any undefined symbols in the delivered system but if anything fails I would like to be able to detect it. Any one else who has had this problem/question ?? I am running Tornado 1.0.1 PPC, release 1, on a MVME 2603 board. /Ant Lars Antb„ck, ant@pullmax.se Pullmax AB Sweden From daemon@csg.lbl.gov Tue Apr 14 04:06:36 1998 From: daemon@csg.lbl.gov Date: Tue Apr 14 04:06:39 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 14 04:06:34 PDT 1998 Subject: Re: Intel 28F400 drivers for VxWorks? Subject: FS: Radstone 68-33 VME/VSB Dual Bus Board -- $450 Subject: FS: Force Sparc 2CE VME Board / 16M -- $450 Subject: How do you run a shell script from your program? Subject: Re: MPC860 data cache support ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Intel 28F400 drivers for VxWorks? Date: 13 Apr 1998 12:37:47 GMT From: "Simon Tourangeau" Organization: Metrix Interlink Message-ID: <01bd66d8$bbca2c40$65c6cdcd@nelson.cgltech.com> References: <352E3D81.30072695@NOSPAMredstonecom.com> We have a very nice flash driver solution. We currently support most of the flash technologies available. We sell our driver with sources included. email me if you want more info. Simon Tourangeau simon@cgltech.com Software engineer Informission Group, Telecom division Michael Carr wrote in article <352E3D81.30072695@NOSPAMredstonecom.com>... > Does anyone have a driver for the Intel 28F400 flash parts, written for > (or easily ported to) VxWorks? > > Thanks in advance! > > -- > ----------------------------------------------------------- > Michael Carr Redstone Communications > *** Remove 'NOSPAM' from my email address when replying *** > > > --------------------------- Newsgroups: comp.os.vxworks Subject: FS: Radstone 68-33 VME/VSB Dual Bus Board -- $450 Date: Mon, 13 Apr 1998 08:41:58 -0600 From: huen@hotmail.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <6gt4n6$odc$1@nnrp1.dejanews.com> For Sale: Radstone VME/VSB 68-33 Dual Bus Board: built-in: *4 M DRAM *Dual VME/VSB Bus Desgin *Dual Internal Bus *68030 / 33MHz CPU *2 Serial Port *Document Asking US$350/best offer Buyer pays shipping charge. - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- Newsgroups: comp.os.vxworks Subject: FS: Force Sparc 2CE VME Board / 16M -- $450 Date: Mon, 13 Apr 1998 08:53:35 -0600 From: huen@hotmail.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <6gt5cu$pfo$1@nnrp1.dejanews.com> For Sale: Force Sparc 2CE VME Board: * Sparc 2 on a single VME Board * 16M Memory * SCSI/Ethernet Built-in * P2 Adaptor included * Document available Asking US$450/best offer Buyer pays shipping charge. - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- Newsgroups: comp.os.vxworks Subject: How do you run a shell script from your program? Date: Mon, 13 Apr 1998 15:28:00 -0500 From: Ron Anderson Message-ID: <35327550.36EC259E@ti.com> How can you run a shell script from your program with a target based shell already running? --------------------------- Newsgroups: comp.os.vxworks Subject: Re: MPC860 data cache support Date: Mon, 13 Apr 1998 08:28:48 -0700 From: "John Finley" Organization: Netcom Message-ID: <6gtavu$10d@sjx-ixn2.ix.netcom.com> References: <01bd65e4$feac5e60$ba1dea93@YOSIY.ecitele.com> <3531F113.42895228@alum.mit.edu> >Right now, I am wrestling with a number of cache configuration issues >and appreciate any pointers, references, etc that would give some >understanding of exactly how vxWorks memory management works with the >'860. So far WindRiver has not been much help. I did that wrestling match a couple of months ago. My conclusion was that several of the cache functions just don't work. I don't remember exactly which ones (wrong office now), but I ended up settling on static cache settings in sysLib.c, and changing little at run time. All drivers use staging buffers in the on-chip RAM, which is not cached, and doesn't hurt us significantly performance-wise. I do recall that I couldn't get cacheDisable/Enable to work, but could turn off cache at runtime using the vmBaseLib functions, although that's only used in special debugging situations. We don't use Ethernet. John - -------------------------------------------------- John Finley Engineering Consultant john@finley.com Real Time Systems (619) 689-0032 Networking Protocols - -------------------------------------------------- --------------------------- End of New-News digest ********************** From ptp@mclean.sparta.com Tue Apr 14 08:03:34 1998 From: "Patrick T. Pinkowski" Date: Tue Apr 14 08:03:37 PDT 1998 Subject: Updating VxWorks FDDI Driver for the SENS Release I am updating a VxWorks FDDI Device driver to work under the SENS for Tornado 1.0 Beta-2 release. In my test setup I have run blaster/blastee and ping. The first operation performed by blaster/blastee or ping is to do an arp (ethernet type 0806) . The arp works successfully. The next operation involves an IP packet being sent and received (ethernet type 0800). The packet is sent correctly. When I receive the packet, I do some formatting to remove the FDDI header and put on an Ethernet header, and then send the packet up the protocol stack using do_protocol. Nothing happens after I send the packet up the protocol stack using do_protocol. Somehow I am not formatting the packet correctly. Does anyone have any advice? Regards Pat -- -------------------------------------------------- /\ Patrick T. Pinkowski, Senior Engineer /##\ ptp@mclean.sparta.com /####\ 703.448.1683 x228 /####/-- /####/---- SPARTA, Inc. -\####\__--- 7926 Jones Branch Drive, Suite 900 ---\##\ /---- McLean, Virginia 22102 ----\##\/\---- (703)448-0210 (Main) ----\####\-- (703)893-5494 (Facsimile) ----\####/ http://www.mclean.sparta.com ---/###/ -/###/ SPARTA \##/ ~~~~~~ \/ Pride In Performance From John.Ahrens@PSS.Boeing.com Tue Apr 14 11:45:06 1998 From: "Ahrens, John L" Date: Tue Apr 14 11:45:09 PDT 1998 Subject: RE: Tornado - License Manager Problems > ---------- > From: vxwexplo@lbl.gov[SMTP:vxwexplo@lbl.gov] > Sent: Thursday, April 09, 1998 9:58 PM > To: vxworks_users@csg.lbl.gov > Subject: Re: Tornado - License Manager Problems > > Submitted-by matsuda@mach.kokusaidenki.co.jp Thu Apr 9 21:58:49 1998 > Submitted-by: matsuda@mach.kokusaidenki.co.jp (Mitsuhiro Matsuda) > > > In article <9804092106.AA23408@csg.lbl.gov> > vxwexplo@lbl.gov writes: > > >> Submitted-by John.Ahrens@PSS.Boeing.com Thu Apr 9 14:06:12 1998 > >> Submitted-by: "Ahrens, John L" > >> > >> I am trying to get Tornado running on my Sparc and I get the > launcher > >> up, but when I try to connect to a target, using VxSim I get a > license > >> not found error. The license manager is running and the license > file is > >> in > >> /opt/wind/.wind/license. It contains 10.lic and 20.lic. > >> > >> Any clues as to what to look for, what's wrong? > > I had same situation when I upgraded Tornado 1.0 to Tornado 1.0.1. > Please check the license manager parameters. > > Following are my configuration. I suggest you should also see target > server log file. > > > WIND_BASE=/usr1/wind > > ${WIND_BASE}/host/sun4-solaris2/bin/wlmd -e > ${WIND_BASE}/.wind/license \ > > -m 50k -s0 -l ${WIND_BASE}/.wlmd.log > > -- > Mitsuhiro Matsuda(matsuda@mach.kokusaidenki.co.jp) > Kokusai Electric Co., Ltd. Toyama Works > Thanks for the suggestions. Turns out the above would probably fix it. I had the wlmd running with ${WIND_BASE}/.wind after -e switch, instead of ${WIND+BASE}/.wind/license. This was caused by an error in the Tornado installation manual (Appendix A pg 32, in case anyone else needs it). > -- > I don't speak for my employer. > > john@misfit.ca.boeing.com > > From Robert.J.Bollhorst@lmco.com Tue Apr 14 15:25:30 1998 From: Robert J Bollhorst Date: Tue Apr 14 15:25:34 PDT 1998 Subject: Using vmBaseLib to protect text segments for MVME1603 VxWorks Gurus, I am having trouble using vmBaseLib to write-protect text segments in RAM. Performance is SIGNIFICANTLY (unacceptably) slower with what I thought was the correct implementation. Has anyone out there used vmBaseLib for this purpose? I am using sysBatDesc for larger areas of the address space, while sysPhysMemDesc contains only 4 entries covering a total of 48MB + 8K. Of the 48MB+, 31MB is cacheable RAM, and 16MB of the remainder is Flash. Our system configuration: VxWorks : 5.3 (5.3.1 coming soon), Tornado 1.0 Target : Motorola MVME1603 (100 MHz PPC 603e) Host : HP 9000's running HPUX 10.2 In the delivery system, our vxWorks Bootrom loads our application (also containing VxWorks, but configured differently from the Bootrom) from either a PCMCIA device or a SCSI Removable Magneto-Optical disk. The main application runs standalone, but can talk to a network printer. The write-protection code in usrConfig.c is as follows: /*************************************************************/ if (vmBaseLibInit(vmBasePageSizeGet()) != ERROR) { taskDelay /* Processor hangs without some delay ;-| */ (FIVE_HUNDRED_MILLISECONDS); vmContextId = vmBaseGlobalMapInit (sysPhysMemDesc, sysPhysMemDescNumEnt, TRUE); /* Same result with FALSE, but */ /* what is the purpose of FALSE? */ if (vmContextId != NULL) { taskDelay /* Processor hangs without some delay ;-| */ (FIVE_HUNDRED_MILLISECONDS); /* Make Text Segment non-writable */ if (vmBaseStateSet (vmContextId, textStart, textLength, /* ~ 7-8 MB */ VM_STATE_MASK_WRITABLE, VM_STATE_WRITABLE_NOT) == ERROR) { /* Handle Error */ } } else { /* Handle Error */ } } else { /* Handle Error */ } /*************************************************************/ After execution, the system reponds sluggishly but does generate the appropriate bus error when attempt are made to write into the text area. The lack of performance with this implementation is unacceptable but we have a requirement to protect the text segment. Am I missing something? Would the use of the optional VxVMI package behave better? Any assistance would be appreciated. TIA Bob Bollhorst Lockheed Martin Launching Systems Robert.J.Bollhorst@lmco.com From hwa-jin@mylex.com Tue Apr 14 23:04:53 1998 From: "Hwa Jin Bae" Date: Tue Apr 14 23:04:56 PDT 1998 Subject: Re: Using vmBaseLib to protect text segments for MVME1603 The problem has to do not only with vxWorks implementation of MMU support, but MPC603e hardware implementation of MMU. Unlike 604e, the 603e's have to handle TLB misses in software via trap handler. Pretty awful slow. Use of BAT is faster. From cruz_nojunk@xyplex.com Wed Apr 15 12:02:56 1998 From: Roger Cruz Date: Wed Apr 15 12:03:06 PDT 1998 Subject: Re: MsgQReceive failures with Posix timers... ++ vxworks ++ vxWorks ++ VxWorks ++ A while ago I posted the following message to see if anyone had experienced a similar problem. Well, after several man hours of debugging, renting an analyzer and disassembling VxWorks code, WE finally found the problem. It is a bug in the VxWorks signal context restore that affects the PC486 BSP. There is a small time window where they are not interrupt protected. The result is that 2 registers being restored are loaded with the wrong values. This causes all sorts of problems as you can imagine. For our case, it showed as msgQReceive failing unexplicably. The SPR is 20903. Now, if I could only find the reason why their dos Fs is causing cross-linked files... Roger ----------------------- ++ vxworks ++ VxWorks ++ Has anybody else run into a weird problem with msgQReceives returning with ERROR but no error value set in errno? I've been tracking this problem for 2 months now and the only clue I have is that is due to the Posix timer. I have a posix timer handler which sends a msg to the queue the task is pending on. If the task is pended on the msgQReceive and the timer goes off, the receive fails. I have look at the msgQReceive ID after the failure and I can see that the "timeouts" field has been incremented by one, even though this call was made with a WAIT_FOREVER argument. Any ideas? Thanks. PS. Remove '_nojunk' from email address. -- Roger Cruz cruz_nojunk@xyplex.com Xyplex Networks w: 978-952-4783 295 Foster Street f: 978-952-4887 Littleton, MA 01460 From Huang.Wu@nrc.ca Wed Apr 15 12:04:43 1998 From: "Wu, Huang" Date: Wed Apr 15 12:04:48 PDT 1998 Subject: Arinc429-v Hello vxworks world, Does anyone have any experience in ARINC A429-V (or V2) board in vxworks? I am using vxworks 5.3 and vme167 board and the low level codes supplied by SBS which are originally designed for Lynx and other OSs. I have difficulty to open this device. The following is the piece of code I used: #define DEVNUM 0 #define BASE_ADDRESS 0x48000000 /*** Global Variables ***/ unsigned long *device_ptr[MAX_DEV]; int open_dev(dev,b_add) ULONG b_add; int dev; { device_ptr[dev] = (ULONG *) b_add; if((get_ram(dev,0x14))==0x2) { return(SUCCESS); } else { return(FAILURE); } } int get_ram(dev,add) int dev; ULONG add; { ULONG stuff, *temp_ptr; temp_ptr = device_ptr[dev] + (add/4); printf("before getting data \n"); stuff = *temp_ptr; printf(" get_ram() is done now \n"); return(stuff); } When I run open_dev(0,0x48000000) at target shell, I get: ->before getting data Access Fault Program counter: 0x007ff168 Status Register: 0x3000 Access address: 0x48000014 Special status: 0x0505 .. 7e4f0 _yystart +734:_open_dev(0,48000000,0,0..) 7ff0f6 test2.txt +1e :_get_ram([0,14,&yyval, ..) Can anyone illuminate me forward? Any suggestions or hints are greatly appreciated. Huang Huang.wu@nrc.ca Flight Research Lab,NRC, Canada From Les.Ziobronowicz.leszek@nt.com Wed Apr 15 14:37:47 1998 From: "Les Ziobronowicz" Date: Wed Apr 15 14:37:51 PDT 1998 Subject: RE: comp.os.vxworks newsdigest ------ =_NextPart_001_01BD68A5.B419B79E Content-type: text/plain; charset="us-ascii" Hi there, Please remove me from vxworks user group, thanks Les Ziobronowicz ( ziobrolx@nt.com ) ------ =_NextPart_001_01BD68A5.B419B79E Content-type: text/html Content-transfer-encoding: quoted-printable RE: comp.os.vxworks newsdigest

Hi there,

Please remove me from vxworks user = group, thanks

        Les Ziobronowicz ( ziobrolx@nt.com )

------ =_NextPart_001_01BD68A5.B419B79E-- From kernin@research.moore.com Thu Apr 16 07:06:06 1998 From: kernin@research.moore.com (Kevin Kernin) Date: Thu Apr 16 07:06:09 PDT 1998 Subject: Starting up from target shell Hello vxworks users, We are running our application with vxWorks 5.3.1 on a 2604-1131 board (32Meg DRAM) with version 1.1/4 of the BSP. In our debug mode we bring up the Tornado Launcher and load our code through CrossWind. In our production mode we create a version of the kernel with the target shell and we load and spawn our application from a startup script. We have a 2604-1141 board (64Meg DRAM) that we can use ok in our system if we bring up the Tornado Launcher and load and run our code from CrossWind. But when we try to startup from the target shell we get the following error that keeps repeating: ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]] ]]]] ]]]]]]]]]] ]] ]]]] (R) ] ]]]]]]]]] ]]]]]] ]]]]]]]] ]] ]]]] ]] ]]]]]]] ]]]]]]]] ]]]]]] ] ]] ]]]] ]]] ]]]]] ] ]]] ] ]]]] ]]] ]]]]]]]]] ]]]] ]] ]]]] ]] ]]]]] ]]]] ]]] ]] ] ]]] ]] ]]]]] ]]]]]] ]] ]]]]]]] ]]]] ]] ]]]] ]]]]] ] ]]]] ]]]]] ]]]]]]]] ]]]] ]] ]]]] ]]]]]]] ]]]] ]]]]]] ]]]]] ]]]]]] ] ]]]]] ]]]] ]] ]]]] ]]]]]]]] ]]]] ]]]]]]] ]]]]] ] ]]]]]] ] ]]] ]]]] ]] ]]]] ]]]] ]]]] ]]]] ]]]]]]]] ]]]]] ]]] ]]]]]]] ] ]]]]]]] ]]]] ]]]] ]]]] ]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Development System ]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]] VxWorks version 5.3.1 ]]]]]]]]]]]]]]]]]]]]]]]]]] KERNEL: WIND version 2.5 ]]]]]]]]]]]]]]]]]]]]]]]]] Copyright Wind River Systems, Inc., 1984-1997 CPU: Motorola MVME2600 - MPC 604e. Processor #0. Memory Size: 0x4000000. BSP version 1.1/4. WDB: Ready. Executing startup script /opt/MOOREdps/PRIP/bin/startup_prip ... # This shell script is automatically run upon VxWorks bootup, # when the bootline 'startup script' is set, and the VxWorks # kernel is configured with the proper facilities # (INCLUDE_STARTUP_SCRIPT, INCLUDE_SHELL, etc.). This particular # script loads the PRIP executable and launches it on a thread # with the following settings: # # Priority 100, FP Enabled, Tack Stack 20KB # ----------------------------------------------------------------- cd "/opt/MOOREdps/PRIP/bin" value = 0 = 0x0 ld < prip.out cd "/opt/MOOREdps/PRIP/bin" value = 0 = 0x0 Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. This error occurs while loading, even before we try to spawn a task. I tried changing LOCAL_MEM_SIZE in config.h to 0x04000000 for the 64Meg DRAM board but I still get the "Relocation" error. We do have LOCAL_MEM_AUTOSIZE defined in config.h so I thought it didn't matter what LOCAL_MEM_SIZE was. Would someone please let me know what I am overlooking? Thank You. From jbt@mclean.sparta.com Thu Apr 16 08:36:53 1998 From: Jason Trizna Date: Thu Apr 16 08:36:56 PDT 1998 Subject: VxWorks USB Drivers VxWorks, Does anyone know of any USB libraries for VxWorks? I've found one source, but the upfront licensing costs are just a *little* higher ;) than we wanted to pay. We are currently just researching it and don't have a very big budget yet. Any info would be greatly appreciated! TIA, Jason Trizna From ptp@mclean.sparta.com Thu Apr 16 11:33:10 1998 From: "Patrick T. Pinkowski" Date: Thu Apr 16 11:33:13 PDT 1998 Subject: VxWorks SENS END/MUX Device Driver VxWorks Guru's, I have been converting a FDDI device driver from the BSD 4.3 device driver model to the BSD 4.4 SENS MUX/END Device Driver model. I have written a helper routine called iphase4511InstallDriver to perform the mux calls to install the driver. muxDevLoad and muxDevStart run without returning an error. But for an unknown reason the END structure does not get inserted in the OS's END Link List. endFindByName returns with a NULL. Does anyone have any ideas? END_OBJ* iphase4511InstallDriver () { END_OBJ * pCookie; END_OBJ * pEnd; char deviceName[]="pg\0"; int unit = 0; M2_INTERFACETBL endM2Tbl; if((pCookie = muxDevLoad(0, iphase4511EndLoad, "0x6000:0:0xa0:3:128:0xf", 1, 0)) == NULL) { printf("Failed muxDevLoad for device %s\n", deviceName); return (ERROR); } if(muxDevStart (pCookie) != OK) { printf("Failed muxDevStart for device %s\n", deviceName); return (pCookie); } /* Find the END_OBJ associated with it. */ if((pEnd = endFindByName (deviceName, unit)) == NULL) { printf("Failed endFindByName for device %s\n", deviceName); return (pCookie); } pEnd = pCookie; if(muxIoctl (pEnd, EIOCGMIB2, (char *)&endM2Tbl) == ERROR) { printf("Failed muxIoctl for device %s\n", deviceName); return (pCookie); } if(ipAttach (unit, deviceName) != OK) { logMsg ("Failed to attach TCP/IP to device %s", (int)deviceName, 2, 3, 4, 5, 6); return (pCookie); } printf ("Attached TCP/IP interface to %s%d.\n", deviceName, unit); return (pCookie); } TIA, Pat -- -------------------------------------------------- /\ Patrick T. Pinkowski, Senior Engineer /##\ ptp@mclean.sparta.com /####\ 703.448.1683 x228 /####/-- /####/---- SPARTA, Inc. -\####\__--- 7926 Jones Branch Drive, Suite 900 ---\##\ /---- McLean, Virginia 22102 ----\##\/\---- (703)448-0210 (Main) ----\####\-- (703)893-5494 (Facsimile) ----\####/ http://www.mclean.sparta.com ---/###/ -/###/ SPARTA \##/ ~~~~~~ \/ Pride In Performance From jtmark@most.fw.hac.com Thu Apr 16 13:14:25 1998 From: "Jimmie T Marks" Date: Thu Apr 16 13:14:31 PDT 1998 Subject: Vxworks on a CP310 pentium --0__=B2FLeYWJrcuGr17WqPO9gW76mpyvbtgKeSZTM1FAeFjhlAskOx9wntyn Content-type: text/plain; charset=us-ascii Content-Disposition: inline Has anybody developed a vxWorks BSP for a CP310 (pentium based) cPCI card from PEP Modular computers? --0__=B2FLeYWJrcuGr17WqPO9gW76mpyvbtgKeSZTM1FAeFjhlAskOx9wntyn Content-type: application/X-Lotus-Encap2; name="encap2.ond" Content-transfer-encoding: base64 GgAAAwAAEQABAC8WbwDoZSUFAAAAFgAADgEAABsAAAAAAEUWbwDoZSUFDf8BAgAEAAAAAwAAAAgA CAAAAQAAsAAAegEAAH4BAAAcAIAAAAQAAkAAAAIAAAC2AAAAAAAAAAAAAAQAAAADAAAAAgAAAAwA AAABAAAAAAAAAAAAAACAsAAAAAQAAEQWbwDoZSUFAAAAAAAAAAAAAAAAAJ4AAAAAAAAAAAAAAAAB gAAAAAAAAAAALxZvAOhlJQUAAAAAAAAAAAAAAABFbmNhcHN1bGF0ZWQgTm90ZSBlOlx0ZW1wXEVO Q0FQMi5UTVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAGAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEFm8A6GUlBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAABAAAAQAYAAIAygEAAAAAAAAAAAAAAAAAAAAA AAABFgAABgEAAACwAAB6AQAAAKYAAEUWbwDoZSUFAAAJAAEF3d0JAA8AAQVwYRgACgABBXBhIgAE AAEFcGEmAAQAAQVwYSoABAABBXBhLgAHAAEFcGE1ABYAAQVwYUsACQABBXBhVAAEAAEAcGFYAAwA AQVwYWQABwABBXBhawAGAAEFcGFxAAYAAQVwYXcACwABBXBhggAEAAEFcGGGAAoAAQRwYZAACgAI AHBhmgAMAAEFcGGmAAoAAQRwYbAACgABBXBhugAFAAQAcGG/AAUAAQNwYcQACgAABXBhUHJpbmNp cGFsTWFpbFNhdmVPcHRpb25zU0VDVVJFTUFJTEZvcm1Mb2dvU2lnbkVuY3J5cHREZWZhdWx0TWFp bFNhdmVPcHRpb25zU2VuZGVyVGFnQm9keSRLZWVwUHJpdmF0ZVN1YmplY3RTZW5kVG9Db3B5VG9C bGluZENvcHlUb0Zyb21Qb3N0ZWREYXRlJFNpZ25hdHVyZVJvdXRlU2VydmVyc1JvdXRlVGltZXMk VXBkYXRlZEJ5JE9yaWckSG9wc0Zyb21Eb21haW6qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoAEgAA AABwDQAAcA0AAAAAAAAAAKqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqAAAAAAAAAAAB AOD8AAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAAAAAAAAA/AAA/wAA/P////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8HANYAAAABAP// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAN76DwAAIAAgAQAAAAEAAAAEAAwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD7u7uAAAAAAAAAAADAAAAAAAAABAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAMAAAAABgAAAA6AAAAXAAAAH4A AKqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqAQAAABUACgEAAAAAAAAAAAAAQ049Tm90ZXNTZXJ2ZXIxL089SERD qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqgYKAAAAAAYBAAAA FAAAAAAAAP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqAAAA/wAgAAAAAAAA AAAAAK8eAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqgEAAP8AIAAAAAAAAAAAAACvHgEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqoCAAD/ACAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqAwAA/wAg xB8AAAEAAQAAAAPuAR8QACAA3wABAAAAAADwHwEAAAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnAAAV AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqgICqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoEAD4CAAB6AQAAe0wZzCdNMkRD Fm8A6GUlBQEAAABDFm8A6GUlBQAAAQBEFm8A6GUlBRgAAAAAAACqAADnAwAAQxZvAOhlJQUAAAwA GwAAAAEADAAFAAAAAgAMAAQAAAADAAwACAAAAAQADAARAAAABQAMAAUAAAAGAAwABQAAAAcADAAF AAAACAAMAAQAAAAJAAsAngAAAAoADAAEAAAACwANAB4AAAAMAE0AFAAAAA0ATQAEAAAADgBMAAQA AAAPAE0AGwAAABAADAAMAAAAEQAKAPUCAAASAAgAMAAAABMACAAkAAAAFABMAEkAAAAVAAwAEgAA ABYADAAMAAAAFwAMABoAAAABABcAQ049SmltbWllIFQgTWFya3MvTz1IREMBAAEAMQEAAAABAAQA TWVtbwEADQBTdGROb3Rlc0x0cjE3AQABADEBAAEAMAEAAQAxAQAAAAEAAAABABoAVnh3b3JrcyBv biBhIENQMzEwIHBlbnRpdW0BABAAdnh3ZXhwbG9AbGJsLmdvdgEAAAABAAAAAQAXAENOPUppbW1p ZSBUIE1hcmtzL089SERDAQAAAM8hbwDoZSUFAwAXABUAFQBDTj1KaW1taWUgVCBNYXJrcy9PPUhE Q0NOPU5vdGVzU2VydmVyMy9PPUhEQ0NOPU5vdGVzU2VydmVyMS9PPUhEQwEAQ01dXJWjw8SXuW4A 6GUlBQEAAAAAAAAAAAA4QEhEQyBAIG5vdGVzbWFpbC5mdy5oYWMuY29tIyMDAIABAAAjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjAwBAAQAA IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IwMAAAEAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMDAMAAAAAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjAwCAAAAAIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIwMAQAAAACMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyODBAEAhf8IAAEAAAqBAoMEAQCF/24AAQAACkhh cyBhbnlib2R5IGRldmVsb3BlZCBhIHZ4V29ya3MgQlNQIGZvciBhIENQMzEwIChwZW50aXVtIGJh c2VkKSAgY1BDSSBjYXJkIGZyb20gUEVQIE1vZHVsYXIgY29tcHV0ZXJzP4ECgwQBAIX/CAABAAAK gQKDBAEAhf8JAAEAAAogAAEAoxhvAOhlJQVIAgAAEAAAAE8AAABIAgAAAQABAAAAAgDnPAdONQMA AAAAAgBGSk8As2QlAAAAAAD///8AAwEAABUBAAAB7QACQrRjAAFkJQBCtGMApocl7QACBQBPPUhE QwAABQBPPUhEQwAAiABCVgQAMS4wAEJDAQADQkEBADBCTAIAdgJOTlAAycxi02xFdeRiDU3UI31K W/nbDHSylzbjBGF++bC266T9gwuVmm9RhDPzFVPNyAx8D/LeSHm59tJDTRcRl5jGizOVtgsRuxrq W/GLfLkyIgBFTgQAWXgAAE1BCAB9YliBVGOqFYAAUFVSU0FGTwD7DxMShDMrdNcFZwC8RahH1POh R53yV7AK3wtc4bWXVXyGIsuNSq90h9Wqo6b7V55laDzTwBLUbR+54ZdpVPpIyqjHltoKdfQmLmEW +x8LASAAAHBKTwCyZCUA1OZOAI1nJQUAAAUATz1IREMAABcAQ049SmltbWllIFQgTWFya3MvTz1I REMAAIgAQlYEADEuMABCQwEAA0JBAQAwQkwCAHYCTk5QAPXYqQMZ9RVFczkW0c1wT087bdPiYvsI KAWnXDGq8/6J2vFMWeSYEZkYN7+DisG5JbcKNeN/ah2ZAsb57I+eNNpAujtjwFbLY7TwLIT1PCQA RU4EAF9xAABNQQgA00gJiXJnFaqAAFBVUlNBRk8AdCeQ6gCLXfUMo9tmOpsq3Kk2A4BcPQjLGsun +vwZYYPdy1USMmPhjudFoObo2Aqxm3HGfiRBY4makKOBLAskH90Y0/FBBAzlDPcPPrRgCTM4xxeB Mk4ZKffcu2upnIhvjRWgA66Q7yKyjbB12dN1YrlO+n+iaLCVgDqTCNlxUnG+67wzcPIV/BKC/M6z g6h0FCGt/I316gqleUcBGuJmZuz+XJyHH2YGoJUscdMiBQAFACAAAAAAAAAAAAAAAAAAAAAAAAAA Qm9keQBTdWJqZWN0AFNlbmRUbwBDb3B5VG8ARnJvbQACABUAFQBDTj1Ob3Rlc1NlcnZlcjMvTz1I RENDTj1Ob3Rlc1NlcnZlcjEvTz1IREMAAAIA2yFvAOhlJQUDIm8A6GUlBa8UbwDoZSUF4xRvAOhl JQWqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqoGCgAAAAB6AQAAQKYAAP////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wQAAAABAAEAAQAAAAAAAAAA AAB6AQAAqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqo= --0__=B2FLeYWJrcuGr17WqPO9gW76mpyvbtgKeSZTM1FAeFjhlAskOx9wntyn-- From cgrames@mdc.com Thu Apr 16 15:53:12 1998 From: Charlie Grames Date: Thu Apr 16 15:53:16 PDT 1998 Subject: Starting up from target shell -Reply Kevin, NOT the dreaded "Relocation value does not fit in 24 bits" problem! The cause for this problem is that the PowerPC ABI requires that all direct subroutine linkage be performed with a simple "bl" (branch and link) instruction, which uses a 24-bit word offset. Wind River is following this ABI to the letter of the law. Unfortunately, the effect of a 24-bit word offset is that all text sections must reside within a 32 MB memory space for linkage to be valid. Since VxWorks typically loads objects at the top of memory, using a target with more than 32 MB of memory causes the span between your object and the VxWorks kernel (which you are referencing) to be greater than 32 MB. Whew! There are two workarounds to this. The first is to limit the initial size of your memory to 32 MB, load your objects, and then add the remaining memory with the memAddToPool() routine. (If you have routines or applications that rely on sysMemTop() returning the correct value, you will also have to modify your BSP to support setting that value after making your memAddToPool() call.) The second is to use a compiler that generates "far calls" where branch-and-links would normally be (Green Hills compilers do this; I don't know whether the GNU compiler does or not). In our case, we have to load third-party objects (which do NOT use "far calls"), so we use a combination of the two. This is a somewhat complicated problem with no simple solution from Wind River. If you have any success getting them to address this more directly, you will have achieved what I could not. HTH. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com >>> the vxWorks Users Group Exploder 04/16/98 09:06am >>> Submitted-by kernin@research.moore.com Thu Apr 16 07:06:06 1998 Submitted-by: kernin@research.moore.com (Kevin Kernin) Hello vxworks users, We are running our application with vxWorks 5.3.1 on a 2604-1131 board (32Meg DRAM) with version 1.1/4 of the BSP. In our debug mode we bring up the Tornado Launcher and load our code through CrossWind. In our production mode we create a version of the kernel with the target shell and we load and spawn our application from a startup script. We have a 2604-1141 board (64Meg DRAM) that we can use ok in our system if we bring up the Tornado Launcher and load and run our code from CrossWind. But when we try to startup from the target shell we get the following error that keeps repeating: Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. Relocation value does not fit in 24 bits. This error occurs while loading, even before we try to spawn a task. I tried changing LOCAL_MEM_SIZE in config.h to 0x04000000 for the 64Meg DRAM board but I still get the "Relocation" error. We do have LOCAL_MEM_AUTOSIZE defined in config.h so I thought it didn't matter what LOCAL_MEM_SIZE was. Would someone please let me know what I am overlooking? Thank You. From mfischer@qualcomm.com Thu Apr 16 16:40:26 1998 From: Mark Fischer Date: Thu Apr 16 16:40:29 PDT 1998 Subject: Re: Starting up from target shell -Reply According to the vxWorks Users Group Exploder: > NOT the dreaded "Relocation value does not fit in 24 bits" problem! The cause > for this problem is that the PowerPC ABI requires that all direct subroutine Actually, it is not the PowerPC's problem, per se, so much as adhering to the EABI (Embedded Applications Binary Interface), where some genius (probably committee) decided 32MB was more than _any_ embedded application would need. (Sound familiar?). > I don't know whether the GNU compiler does or not). In our case, 2.8+ does. Use -mno-eabi. However, it is unknown to me when Wind River will support it. Last time I talked to them they were not in any hurry. Cheers, Mark Fischer Qualcomm, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From froeber@BBN.COM Thu Apr 16 19:00:15 1998 From: Fred Roeber Date: Thu Apr 16 19:00:19 PDT 1998 Subject: Re: Starting up from target shell -Reply On Thu, 16 Apr 1998, Charlie Grames wrote about vxworks: > NOT the dreaded "Relocation value does not fit in 24 bits" problem! > Unfortunately, the effect of a 24-bit word offset is that all text > sections must reside within a 32 MB memory space for linkage to be > valid. Since VxWorks typically loads objects at the top of memory, > using a target with more than 32 MB of memory causes the span between > your object and the VxWorks kernel (which you are referencing) to be > greater than 32 MB. Whew! Charlie went on to describe various workarounds. We haven't run into this problem (yet) since we don't have boards with that much memory. I am wondering though whether a small change in VxWorks use I will propose could help people avoid the problem in a lot of cases. The root of the problem is how the default VxWorks memory allocator works. Namely, it uses a "first fit" linked list based approach to allocation. When a request for memory is made, it gets the first free block that is large enough to fill the request and takes the amount the user asks for FROM THE END of the block and reduces the size of the free block by that much. Initially, all of the available memory is in a single free block going from the end of the kernel to the top of memory. All the initial requests end up getting memory that is at the top of memory since that is where the end of the free block is. You could trick the system so that it allocated your code within the 32MB range of the PowerPC address offset by taking advantage of how the system works. You could start by allocating a large dummy block right off the bat (you could even do it from the shell startup script). If you have 64MB of memory, make the dummy block 40MB. That will tie up the last 40MB of your memory area. If you load your code now, it will come from the end of what is left free; which is within the 32MB limit (BTW, I don't see how what I assume is a "signed" 24bit offset gives a 32MB range but I'll leave that to the PowerPC experts). This will allow code to load ok. There is still the problem of how to be able to make use of the memory in that dummy block (I am assuming the board has all that memory because it is needed). Unfortunately, this isn't as easy as it could be. If you knew when all your code was loaded, you could safely free up the dummy block at that point. When the block is freed it gets stuck AT THE FRONT of the list of free memory. Thus, if any more requests were made for memory to load code into, that memory would come from the end of the first large enough free block. Since the dummy block was put at the start of the free block, the new memory comes from the end of it which puts us back at the top end of memory resulting in problems. Sorry, but I don't have a clean solution to this. Of course, Wind River could change their memory allocator to add new free blocks to end of the free block list instead of the start. This wouldn't hurt performance too much since the list is doubly linked but would certainly affect it a bit. Some number of years ago when I could look at VxWorks code and needed to do a lot of allocation, I went through the VxWorks allocator in detail. We ended up using a custom allocator to get the far higher performance we required. The standard allocator uses one of the "simplest" algorithms there is but implements it just about as efficiently as is possible. Maybe the allocator needs to be changed for PowerPCs with large memories. Well, I just wanted to offer some suggestions so that by the time we get to using a large memory PowerPC card, someone will have come up with a clean solution to the problem. In the meantime, happy coding. Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From daemon@csg.lbl.gov Fri Apr 17 04:04:36 1998 From: daemon@csg.lbl.gov Date: Fri Apr 17 04:04:38 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Apr 17 04:04:34 PDT 1998 Subject: Re: Blocking for another task's death? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Blocking for another task's death? Date: Thu, 16 Apr 1998 22:28:10 -0400 From: Kevin Bradley Organization: Doctoral student, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA Message-ID: References: Excerpts from netnews.comp.os.vxworks: 16-Apr-98 Blocking for another task's.. by "John Freeborg"@etcconne > How can I get task A to block until task B dies? In Win32 I just do a > WaitForSingleObject() on the task B's handle, but I can't find anything > similiar in VxWorks. The closest thing I thought of was to add some state > data member to my class object such that task A ends up calling > taskSuspend() on itself and task B does a taskResume() on task A right > before it terminates with a taskDelete(). Crude, but I think it would work. I'm writing this from home, where I don't have my manuals, so this is going to be fuzzy. VxWorks has "hooks"; one of these (I think) is taskDeleteHook, where you can add custom code to do e.g. a semGive(). Try either taskLib.h or taskHookLib.h (vaguely sounds right). > Q2: > How can I get task A to block until task B dies until 'n' clock ticks > pass (i.e a block with a timeout). In Win32 the WaitForSingleObject() call > takes a timeout parameter so this is trivial. My strategy in Q1 doesn't > work in this case. All the ideas I've had seem to degenerate to some form > of busy waiting which I want to avoid if possible. One easy way is to use a message queue as your hook callback, and then do msgQReceive() with a timeout. Overhead: msgQ data structure. Benefit: msgQ already does everything you need. Another way is to use a semaphore, a flag variable, and a watchdog timer. If the watchdog expires, it sets the flag and gives the semaphore. If the task exits, it lowers the flag and gives the semaphore. Your task does semTake() followed by the appropriate behavior based on the flag state. Overhead: semaphore + watchdog + flag Benefit: semGive() a little cheaper than msgQReceive(), but not much. Hope this helps... -- Kevin --------------------------- End of New-News digest ********************** From cgrames@mdc.com Fri Apr 17 07:17:55 1998 From: Charlie Grames Date: Fri Apr 17 07:17:59 PDT 1998 Subject: Re: Starting up from target shell -Reply -Reply I'll kill two birds with one stone, here. Mark: >Actually, it is not the PowerPC's problem, per se, so much as adhering >to the EABI (Embedded Applications Binary Interface), where some >genius (probably committee) decided 32MB was more than _any_ embedded >application would need. (Sound familiar?). Actually, though Wind River likes to say this problem lies in the EABI (Embedded Application Binary Interface), it is really defined in the System V Application Binary Interface (ABI), PowerPC Processor Supplement, to which the EABI refers. In the Function Calls section, it says: Programs use the PowerPC bl instruction to make direct function calls. A bl instruction has a self-relative branch displacement that can reach 32 megabytes in either direction. Hence, the use of a bl instruction to effect a call within an executable or shared object file limits the size of the executable or shared object file text segment. It goes on to say: A compiler normally generates the bl instruction to call a function... The called function may be in the same module (executable or shared object) as the caller, or it may be in a different module. In the former case, the link editor resolves the symbol and the bl branches directly to the called function. In the latter case, the link editor cannot directly resolve the symbol. Instead, it treats the bl as a branch to "glue" code that it generates, and the dynamic linker modifies the glue code to branch to the function itself. The problem is that Wind River's link editor (dynamic linker) does not produce this "glue" code. That would be the cleanest solution to this problem, but as far as I know, Wind River has no plans to do this. Green Hills (and possibly GNU) gets around the whole issue by using indirect linkage (i.e., setting up the link register and using the blrl instruction) when the "far calls" option is used. This makes the call sequence less efficient but without limit. Fred: >(BTW, I don't see how what I assume is a "signed" 24bit offset gives a >32MB range but I'll leave that to the PowerPC experts). The offset is actually 26 bits, but the two least significant bits are assumed zero. That is why I have been careful to refer to it as a 24-bit _word_ offset. As the ABI says, the offset allows displacements that can reach 32 MB in either direction. However, since you can't closely control where your stuff is loaded relative to where the stuff you are calling is located, you must contain everything in a 32 MB space to be safe. I liked your suggestion of malloc-ing upper memory and then doing loads, but I would be concerned that any VxWorks initialization done before I did my loads might allocate and then free areas in upper memory that would be too big to be allocated for a single large block, but big enough to contain my program. Making that memory inaccesible is probably safer. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com From Susan.J.Henry@lmco.com Fri Apr 17 10:04:12 1998 From: Susan J Henry Date: Fri Apr 17 10:04:16 PDT 1998 Subject: Exchange Timeout Error in Tornado Shell Hello, Is there a way to change/increase the time-out value when loading an object from the Tornado Shell? We are experiencing Exchange Time-outs when we load the object (which is about 8 meg). Target: MVME1603 Host: HP-UX 10.x Sorry if this questions has been posted previously. TIA, Sue Henry Lockheed Martin Launching Systems 410.682.0776 sussan.j.henry@lmco.com From t_wmoles@qualcomm.com Fri Apr 17 10:57:52 1998 From: Hugh Molesworth Date: Fri Apr 17 10:57:56 PDT 1998 Subject: Re: Exchange Timeout Error in Tornado Shell We get this problem all the time; it depends very much on your network loading. To extend the timeouts in the Tornado "Create Target Server" window set the "Backend timeout" and "Backend resend" windows to something like 30 secs. Also increase the "Memory cache size" to some (very) large value; we use 16000000, this speeds things up considerably. If you use the tgtsvr command add "-Bt 30 -Br 30 -m 16000000" to the command line. If you use windsh directly without loading Tornado, um, forgot how to extend that one :-) HTH Hugh >Submitted-by Susan.J.Henry@lmco.com Fri Apr 17 10:04:12 1998 >Submitted-by: Susan J Henry > > >Hello, > >Is there a way to change/increase the time-out value when loading an object from >the Tornado Shell? We are experiencing Exchange Time-outs when we load the >object (which is about 8 meg). > >Target: MVME1603 >Host: HP-UX 10.x > >Sorry if this questions has been posted previously. > > >TIA, >Sue Henry >Lockheed Martin Launching Systems >410.682.0776 >sussan.j.henry@lmco.com VxWorks From daemon@csg.lbl.gov Sat Apr 18 04:04:21 1998 From: daemon@csg.lbl.gov Date: Sat Apr 18 04:04:24 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 18 04:04:19 PDT 1998 Subject: Re: TCP socket problem ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP socket problem Date: Fri, 17 Apr 1998 08:02:49 -0600 From: Chris Webster Organization: NCAR Research Aviation Facility Message-ID: <35376109.98CD2A72@raf.atd.ucar.edu> References: <35371BEC.79AB7BE9@mclink.it> > I made a program that establishes a TCP socket connection between a > MVME162 board running vxWorks 5.3.1 (client side) and a PC WinNT (server > side). The client asynchronously transmits messages to the server by > means of the write() function. The problem I have is that the client > must recognize when the connection drops; actually if I disconnect the > cable this does not happen, i.e. the write() function does not return > any error !. I also tried the function setsockopt() with the > SO_KEEPALIVE option, without any apparent result. Does anybody know a > method to detect the absence of the cable ? KEEPALIVE works on a granularity of hours or something. I have the same problem. However I had synchronous data as well, so if no sync data arrived in x seconds, then I considered it a disconnect. Since you only have async, then you need to send your own activity packet. I would just have the vxWorks side send a small packet once a second, if NT doesn't receive one within say 2-3 seconds, consider the line down. Someone know something else...... - --Chris --------------------------- End of New-News digest ********************** From daemon@csg.lbl.gov Sun Apr 19 04:04:06 1998 From: daemon@csg.lbl.gov Date: Sun Apr 19 04:04:09 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 19 04:04:04 PDT 1998 Subject: TCP socket problem Subject: Re: Tornado 1.0.1 for pc486 and third party boards ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: TCP socket problem Date: Fri, 17 Apr 1998 11:07:57 +0200 From: TSdev Organization: Techno System Dev Message-ID: <35371BEC.79AB7BE9@mclink.it> Reply-To: TSdev@mclink.it Hi, I made a program that establishes a TCP socket connection between a MVME162 board running vxWorks 5.3.1 (client side) and a PC WinNT (server side). The client asynchronously transmits messages to the server by means of the write() function. The problem I have is that the client must recognize when the connection drops; actually if I disconnect the cable this does not happen, i.e. the write() function does not return any error !. I also tried the function setsockopt() with the SO_KEEPALIVE option, without any apparent result. Does anybody know a method to detect the absence of the cable ? Thank you, Daniele Titomanlio - -- ******************************* Techno System Dev. S.r.l. Zona Ind. San Martino, 27 80078 - Pozzuoli (NA) Italy Tel. +39 81 5268313/5263475 Fax. +39 81 5262701 E-mail : TSdev@mclink.it ******************************* --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Tornado 1.0.1 for pc486 and third party boards Date: Fri, 17 Apr 1998 07:36:48 GMT From: kam@oce.nl (Gerald van Kampen) Organization: Oci-Technologies b.v. Message-ID: References: <01bd6712$a1cc1260$4921b00a@system2> Sender: news@oce.nl (The Daily News @ nntp01.oce.nl) In article <01bd6712$a1cc1260$4921b00a@system2>, "thierry" wrote: >I have got a couple of io boards, but I need to create a map of the memory >that can be shared by the CPU and the IO boards. For instance, if I use >DOS, I can map my DIO board to address 0x260, and output words to my >hardware. This does not seem as easy within Tornado. Has anybody tried >that. >BSP is pc486 in a PC104 form factor. Manufacturer is AMPRO for the CPU and >DIAMOND for the IO boards. I assume your talking about I/O mapped I/O. In that case you can use the sysInWord() and sysOutWord() functions which are documented in the vxWorks Programmers Guide (appendix Intel i386/i486). If you want to access memory mapped I/O make sure it's not part of the memory pool and add it to sysPhysMemDesc [] as non cacheable (in syslib.c). The PC486 uses for example adress 0xA0000 to 0xFFFFF as memory mapped I/O. Gerald van Kampen (kam@oce.nl) --------------------------- End of New-News digest ********************** From yzur@qualcomm.com Sun Apr 19 05:16:30 1998 From: Joseph Zur Date: Sun Apr 19 05:16:33 PDT 1998 Subject: VxWorks FTP server - how does it work ? Hi, I need to implement FTP server over PPP on serial link in an embedded system. How does the FTP server work in VxWork? Does it require any file system ? or can it run with just a pointer to a memory buffer ? The ftpdInit() and ftpdTask() does not relate to any memory buffers or any other storage, so how does the data is being stored ? and where ? How do I know that the FTP session is over ? Does any one know about sample code that ilustrates the usage of FTP server ? Thanks in advance --- Joseph Zur --- Qualcomm Israel From SMWLI@n2sun1.ccl.itri.org.tw Sun Apr 19 16:52:00 1998 From: SMWLI@n2sun1.ccl.itri.org.tw Date: Sun Apr 19 16:52:04 PDT 1998 Subject: WTX error Vxworks; tornado ; Dear Sirs : I downloaded a object about 1.5Mbytes via serial line to target board. I set the WTX-load-timeout to a value large enough such that I can download without difficulty. However, as I watched the window of shell, it showed that "Error while polling for events :" "WTX Error 0x10197 (EXCHANGE_TIMEOUT)" and, all the tasks activated originally (eg. WDB, Demo tasks) were disappeared ! Anybody ever hitted the similar problem ? Appreciate ! Paul SMWLI@N2SUN1.CCL.ITRI.ORG.TW 840178@CCL.ITRI.ORG.TW From SMWLI@n2sun1.ccl.itri.org.tw Sun Apr 19 19:58:33 1998 From: SMWLI@n2sun1.ccl.itri.org.tw Date: Sun Apr 19 19:58:42 PDT 1998 Subject: [Fwd: WTX error] Message-ID: <352DDFF1.34C2@n2sun1.ccl.itri.org.tw> Date: Fri, 10 Apr 1998 17:01:38 +0800 From: SMWLI@n2sun1.ccl.itri.org.tw Reply-To: SMWLI@n2sun1.ccl.itri.org.tw X-Mailer: Mozilla 3.04 (Win95; I) MIME-Version: 1.0 To: vxwexplo@lbl.gov CC: support@wrs.com Subject: WTX error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Vxworks; tornado ; Dear Sirs : I downloaded a object about 1.5Mbytes via serial line to target board. I set the WTX-load-timeout to a value large enough such that I can download without difficulty. However, as I watched the window of shell, it showed that "Error while polling for events :" "WTX Error 0x10197 (EXCHANGE_TIMEOUT)" and, all the tasks activated originally (eg. WDB, Demo tasks) were disappeared ! Anybody ever hitted the similar problem ? Appreciate ! Paul SMWLI@N2SUN1.CCL.ITRI.ORG.TW 840178@CCL.ITRI.ORG.TW From daemon@csg.lbl.gov Mon Apr 20 04:03:27 1998 From: daemon@csg.lbl.gov Date: Mon Apr 20 04:03:29 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Apr 20 04:03:25 PDT 1998 Subject: Re: TCP/IP over 1553 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: TCP/IP over 1553 Date: Sun, 19 Apr 1998 19:56:48 -0700 From: "Jim Ellis" Organization: Silicon Solutions Message-ID: <6hedkh$eje$1@news.hughes.net> References: <3535EF69.8CA@mailgw.sanders.lmco.com> As far as I know you cannot 'implement' TCP/IP over a 1553 bus. Mil-Std-1553 IS a communication protocol. If your talking about using TCP/IP to communicate between your host and target in a system that is providing data acquisition of 1553 data from a 1553 bus (like an aircraft) then that's entirely different. Did this help? Jim Ellis Lead Software Engineer Integrated Test Systems Northrop Grumman B2 Division user wrote in message <3535EF69.8CA@mailgw.sanders.lmco.com>... >anyone had any experience trying to implement TCP/IP over 1553 bus >network? any code, advice, pointer greatly appreciated. > >-jeff --------------------------- End of New-News digest ********************** From aguilar@popler.lansce.lanl.gov Mon Apr 20 09:27:25 1998 From: aguilar@popler.lansce.lanl.gov (Ron Aguilar) Date: Mon Apr 20 09:27:29 PDT 1998 Subject: Development Methodology VxWorks Experts, We are in the throws of deciding a development methodology for future projects. After reading a few white papers on the ObjecTime web site, I am curious as to what real-time/VxWorks developers using ObjecTime Developer tools have to say about their efforts/project development. I get the impression that the is the best thing since sliced bread. Could this be true? 0000,0000,8080 Ron Aguilar Los Alamos National Laboratory Manuel Lujan Jr. Neutron Scattering Center LANSCE-12, MS H805 Los Alamos, NM 87545 505-667-8369 505-665-2676 (fax) rgaguilar@lanl.gov From tkb@mclean.sparta.com Mon Apr 20 10:24:09 1998 From: Thomas Keith Buchanan Date: Mon Apr 20 10:24:12 PDT 1998 Subject: Re: Development Methodology > We are in the throws of deciding a development methodology for future projects. > > After reading a few white papers on the ObjecTime web site, I am curious as to > > what real-time/VxWorks developers using ObjecTime Developer tools have to say > > about their efforts/project development. > We have found the ObjecTime Toolset to be a great tool and ROOM to be an excellent methodology for real-time embedded work. We don't use it for smaller scale efforts but it is the cats meow for larger efforts. It really hits it's stride in large-scale distributed projects. adios From aguilar@popler.lansce.lanl.gov Mon Apr 20 12:13:20 1998 From: aguilar@popler.lansce.lanl.gov (Ron Aguilar) Date: Mon Apr 20 12:13:23 PDT 1998 Subject: Re: Development Methodology At 10:24 AM 4/20/98 PDT, you wrote: >Submitted-by tkb@mclean.sparta.com Mon Apr 20 10:24:09 1998 >Submitted-by: Thomas Keith Buchanan < > >> We are in the throws of deciding a development methodology for future projects. >> >> After reading a few white papers on the ObjecTime web site, I am curious as to >> >> what real-time/VxWorks developers using ObjecTime Developer tools have to say >> >> about their efforts/project development. >> > >We have found the ObjecTime Toolset to be a great tool and ROOM to be an >excellent >methodology for real-time embedded work. We don't use it for smaller >scale efforts >but it is the cats meow for larger efforts. It really hits it's stride >in large-scale >distributed projects. > >adios Hi Thomas, Thanks for responding. I am curious as to what you consider the cut off point for use of the Toolset (i.e., project size). Also, do you use the Tool set in developing user interfaces? 0000,0000,8080 Ron Aguilar Los Alamos National Laboratory Manuel Lujan Jr. Neutron Scattering Center LANSCE-12, MS H805 Los Alamos, NM 87545 505-667-8369 505-665-2676 (fax) rgaguilar@lanl.gov From gpbeedu@net.com Mon Apr 20 13:09:25 1998 From: Guru Prasad Beedu Date: Mon Apr 20 13:09:29 PDT 1998 Subject: Ftp client Source code Dear VxWorks users, Does anybody know where to find ftp client source code for VxWorks ? - Thanks, Guru Prasad Network Equipment Technologies( NET) From Bob.Ferrara@digital.com Mon Apr 20 14:32:52 1998 From: Bob Ferrara Date: Mon Apr 20 14:32:55 PDT 1998 Subject: VxWorks driver for the ISP 1020A SCSI Controller chip VxWorks World - Does anyone have a device driver for the ISP 1020A SCSI controller chip from QLogic? Thanks, Bob Ferrara Digital Equipment Corporation Phone: 603-884-3094 Fax: 603-884-5191 E-mail: Bob.Ferrara@Digital.com From espin@idiom.com Mon Apr 20 15:56:58 1998 From: Geoffrey Espin Date: Mon Apr 20 15:57:02 PDT 1998 Subject: Re: VxWorks driver for the ISP 1020A SCSI Controller chip Bob, > Does anyone have a VxWorks device driver for the ISP 1020A > SCSI controller chip from QLogic? Contact Shishir Shah at QLogic: s_shah@qlc.com Geoff -- Geoffrey Espin espin@idiom.com From wheat@wg.com Mon Apr 20 16:24:51 1998 From: Lee Wheat Date: Mon Apr 20 16:24:59 PDT 1998 Subject: turning off listening to redirects vxworks...vxworks...vxworks... i'm running vxworks 5.3.1 on an x86 platform with a 3Com 3c509 ethernet card. is there a way to tell the networking stack to not listen to icmp redirects? i just spent most of a day (and yes, i should have noticed it sooner :) tracking down why i was losing connectivity to another machine i was talking to. if i bring the unit up with no network connections, all of the routes look like they should and the route table (from routeShow) also looks fine. however, when i connect the machine up to the network, the first frame that is sent to the host (the host is on a different subnet than the unit i'm using) generates a redirect that changes the routing table. doing a routeShow at this point shows the new route with a flag value of 39 (previously it was 7) which indicates that the routing entry was modified dynamically by a redirect. i do not want stuff like this to happen. how can i get vxworks to ignore the redirects? thanks, lee wheat wheat@wg.com From ktsubota@keck.hawaii.edu Mon Apr 20 22:55:38 1998 From: ktsubota@keck.hawaii.edu (Kevin Tsubota) Date: Mon Apr 20 22:55:42 PDT 1998 Subject: windview license queue Does anyone know why my windview license request is being queued when no one has it, or it seems? When I first installed it (about a week ago), I was able to get windview up and running but now it always tells be that it's queueing my license request. I've restarted wlmd and made sure no one else is using it. Here is a copy of the output of "License" from the launch tool: ---------------------- Wind License Manager - Copyright 1989-1996 Elan Computer Group, Inc. Server apua: CID LID User Feature Group Started --- --- ------------------------------------ ---------- -------- ------------ S 1 1 vxworks@apua,alii:0 10 - Apr 20 18:51 S 2 1 vxworks@apua,kahala:0 10 - Apr 20 18:51 S 4 1 vxworks@apua,kahala:0 10 - Apr 20 18:51 S 5 1 vxworks@apua,kahala:0 10 - Apr 20 18:52 S 6 1 vxworks@apua,kahala:0 10 - Apr 20 18:53 10: 10 licenses, 1 in use; installed Apr-20-98 20: 1 license, 0 in use; installed Apr-20-98 ---------------------- Thank you very much! Kevin Tsubota California Assoc. for Research in Astronomy 65-1120 Mamalahoa Hwy. Kamuela, HI 97643 ph: (808)885-7887 From taher@teil.soft.net Mon Apr 20 23:56:12 1998 From: Mohd Taher Shaikh Date: Mon Apr 20 23:56:16 PDT 1998 Hello, We have recently purchased vxworks and using it. Please include me in your mailing list on my email id for all informations Hoping for an earliest reply Regards taher shaikh From mirie@telegate.co.il Tue Apr 21 00:00:13 1998 From: Miri Epstein Date: Tue Apr 21 00:00:17 PDT 1998 Subject: Re: turning off listening to redirects Hi Lee, the vxWorks Users Group Exploder wrote: > Submitted-by wheat@wg.com Mon Apr 20 16:24:51 1998 > Submitted-by: Lee Wheat > > vxworks...vxworks...vxworks... > > i do not want stuff like this to happen. how can i get vxworks to ignore > the redirects? > What I know is from "SENS for Tornado, Component Release Supplement 1.0 edition 1, January 1998": in your BSP, in config.h - there is a define for IP_FLAGS_DFLT which includes ICMP REDIRECT MESSAGE which can be configured. VxWorks default value enables sending redirect messages. Hope it helps. Miri Epstein mirie@telegate.co.il From jbhawth@aptec.com Tue Apr 21 08:01:30 1998 From: "James B. Hawthorne" Date: Tue Apr 21 08:01:37 PDT 1998 Subject: PINGing in VxWorks??? Greetings VxWorkers- In VxWorks is there a way to "ping" another node on the network to determine if we still have a network connection? I have an application that runs on a remotely controlled VME chassis that is generating UDP state-of-health packets. If the network connection is lost (disconnected) the socket daemon detects the error and dies. After the network connection is restored, rebooting the system gets everything up and running again just fine. My application needs to be robust enough to wait until the network connection is restored and recover on its own. I have determined that if I ping the broadcast address for the network, any node hearing the packet will respond and in so doing the chassis can determine that the network connection was restored. I am not sure how I can accomplish this. Any help would be greatly appreciated! ----------------------------------------------------------------- _/_/_/ _/_/_/_/ _/_/_/ Jim Hawthorne _/ _/ _/ _/ _/ Realtime Systems Engineer _/_/_/_/ _/ _/_/_/_/ Applied Technology Associates _/ _/ _/ _/ _/ 1900 Randolph Road SE _/ _/ _/ _/ _/ Albuquerque, New Mexico 87106 Phone: (505)767-1228 Applied Technology Associates Fax: (505)768-1379 A-TECH Corporation jbhawth@aptec.com http://www.aptec.com __________________________________________________________________ From caprio@research.moore.com Tue Apr 21 12:19:43 1998 From: Jim Caprio Date: Tue Apr 21 12:19:46 PDT 1998 Subject: Using vararg We are attempting to compile a TIFF library (from SGI) to run on Vxworks/PPC (2604 BSP). We successfully build and load the vxWorks executable (i.e., no compilation errors, no unresolved symbols), but at runtime get garbage in the return value from the va_arg() macro, which allows reading a variable number of input arguments. I see routines in fioLib (e.g. vprintf) which take a va_list input, so it looks like vxWorks does support this. Has anyone successfully used this feature? Are there any issues we should be aware, for instance, regarding alignment? vxWorks configuration requirements? Thanks. ================================= Jim Caprio Moore Research Center, Inc. (716)773-0333 FAX : (716)773-0462 email: caprio@research.moore.com ================================= From vince@rti.com Tue Apr 21 15:42:57 1998 From: vince@rti.com (Vince Chen) Date: Tue Apr 21 15:43:00 PDT 1998 Subject: Re: Using vararg Jim, This is a problem w/ the header files shipped w/ WindRiver. They use TRUE before it's been defined, so as a result, the wrong var_args code get pulled in. I don't know if this has been fixed in Tornado 1.0.1, but it was a problem with Tornado 1.0. In the $VXHOME/target/h/arch/ppc/toolPpc.h, look for the line: #if TRUE /* TPR XXX */ Right before it, (if not there already), add: #ifndef TRUE #define TRUE 1 #endif Hope that helps! -vince ========================================================================== = = = = Vincent Chen = email: vince@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 155A Moffett Park Drive, Suite 111 = Fax: (408) 734-5009 = = Sunnyvale, CA 94089 = = ========================================================================== ------------- Begin Included Message ------------- We are attempting to compile a TIFF library (from SGI) to run on Vxworks/PPC (2604 BSP). We successfully build and load the vxWorks executable (i.e., no compilation errors, no unresolved symbols), but at runtime get garbage in the return value from the va_arg() macro, which allows reading a variable number of input arguments. I see routines in fioLib (e.g. vprintf) which take a va_list input, so it looks like vxWorks does support this. Has anyone successfully used this feature? Are there any issues we should be aware, for instance, regarding alignment? vxWorks configuration requirements? Thanks. ------------- End Included Message ------------- From froeber@BBN.COM Tue Apr 21 18:26:26 1998 From: Fred Roeber Date: Tue Apr 21 18:26:29 PDT 1998 Subject: Re: turning off listening to redirects On Mon, 20 Apr 1998, Lee Wheat wrote: > vxworks...vxworks...vxworks... > > i do not want stuff like this to happen. how can i get vxworks to ignore > the redirects? I do not know of any sort of flag you can set to cause redirects to be ignored but you could always use an etherInputHook to check the packets and discard any redirect messages. Not pretty but should work fine. Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From ashoka@teil.soft.net Wed Apr 22 00:26:30 1998 From: K Ashoka Date: Wed Apr 22 00:26:33 PDT 1998 Subject: Regarding GCT tool... Is there any code coverage(similar to GCT) tools available in VxWorks?. Please give me the info about it. Thanx in advance Bye Ashoka ---------------------------------------------------------------------- Ashoka K, Specialist - D & D, Tata Elxsi (India) Ltd. email : ashoka@teil.soft.net, Tel : 91-80-8410148, Fax 91-80-8410152 ----------------------------------------------------------------------- From Thomas.Arand@oen.siemens.de Wed Apr 22 01:08:06 1998 From: Arand Thomas Date: Wed Apr 22 01:08:10 PDT 1998 Subject: AW: PINGing in VxWorks??? See pingLib.h. Try #INCLUDE_PING in config.h. Ciao, Thomas ---------------------------------------------------------------------- Thomas Arand Siemens AG Tel. +49 - 89 - 722 42296 Fax. +49 - 89 - 722 26572 thomas.arand@oen.siemens.de > -----Urspr=FCngliche Nachricht----- > Von: vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov] > Gesendet am: Dienstag, 21. April 1998 17:02 > An: vxworks_users@csg.lbl.gov > Betreff: PINGing in VxWorks??? >=20 > Submitted-by jbhawth@aptec.com Tue Apr 21 08:01:30 1998 > Submitted-by: "James B. Hawthorne" >=20 > Greetings VxWorkers- >=20 > In VxWorks is there a way to "ping" another node on the network to > determine if we still have a network connection? >=20 > I have an application that runs on a remotely controlled VME chassis > that is generating UDP state-of-health packets. If the network > connection is lost (disconnected) the socket daemon detects the error > and dies. After the network connection is restored, rebooting the > system > gets everything up and running again just fine. >=20 > My application needs to be robust enough to wait until the network > connection is restored and recover on its own. I have determined that > if > I ping the broadcast address for the network, any node hearing the > packet will respond and in so doing the chassis can determine that = the > network connection was restored. I am not sure how I can accomplish > this. >=20 > Any help would be greatly appreciated! >=20 > ----------------------------------------------------------------- > =20 > _/_/_/ _/_/_/_/ _/_/_/ Jim Hawthorne > _/ _/ _/ _/ _/ Realtime Systems Engineer > _/_/_/_/ _/ _/_/_/_/ Applied Technology Associates > _/ _/ _/ _/ _/ 1900 Randolph Road SE > _/ _/ _/ _/ _/ Albuquerque, New Mexico 87106 > Phone: (505)767-1228 > Applied Technology Associates Fax: (505)768-1379 > A-TECH Corporation jbhawth@aptec.com > http://www.aptec.com > __________________________________________________________________ >=20 >=20 From daemon@csg.lbl.gov Wed Apr 22 04:02:44 1998 From: daemon@csg.lbl.gov Date: Wed Apr 22 04:02:47 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 22 04:02:42 PDT 1998 Subject: Re: Largest file size for dosFS? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Largest file size for dosFS? Date: Fri, 17 Apr 1998 15:44:49 -0400 From: Doug Litke Organization: Watkins-Johnson Corporation - (415) 493-4141 Message-ID: <3537B131.375E@wj.com> References: <3533A6AC.9741A287@oscsystems.com> <6h4932$9nb$1@swapw4.swa.epson.co.jp> We had problems with large files in the root directory. We put the large files in a subdirectory, and that solved our problem. Does not really answer your problem Girish V. Gulawani wrote: > > (unsigned) int count=0; > > ioctl(fd, FIONCONTIG, &count) > > while allocating > > ioctl(fd, FIOCONTIG, count) > > but i also do not know why: > #define CONTIG_MAX -1 ( ioLib.h ) > ???????? > > G. > > John W. Edwards wrote in message <3533A6AC.9741A287@oscsystems.com>... > >Can anyone tell me what the largest file size is for a file using dosFS? > > > >I'm having to write files > 2G. If dosFS does not support this does > >anyone know of a VxWorks compatible file system which can? > > > >Thanks, > >-- > >John W. Edwards, Sr. Software Eng > >Orbital Sciences Corporation / Fairchild Defense > >Germantown, MD USA > >JohnEdwards@oscsystems.com > > > > --------------------------- End of New-News digest ********************** From frank@info-age.net Wed Apr 22 05:22:14 1998 From: Frank Fischer Date: Wed Apr 22 05:22:19 PDT 1998 Subject: Network breaks down when using MMU Hi... we are currently using a Motorola MPC821 and vxWorks. We are using the SCC1 for Ethernet. But when switching on LCD we loose ethernet connection ( tNetTask crushes with Software Implementation fault ). All works quite fine when switching off the I-MMU and the I-Cache. Is there a workaround ?? It breaks the performance to a third not using the cache !! CU 0xff Frank Fischer DHF - Gesellschaft fuer Datenverarbeitung From stevens@ims.fhg.de Wed Apr 22 05:40:11 1998 From: Torsten Stevens Date: Wed Apr 22 05:40:15 PDT 1998 Subject: java virtual mashine for 68xxx ? (VxWorks) Hi, VxWorkers ! The JVM is already adapted to PowerPc and Intel machines, but it is not fitted to Motorola CPU's yet (and it doesn't seems to happen soon). The official reason is that Motorola 68K CPUs are not able to run the VM because of to less computing performance! In my opinion this can't be the true reason, because a MC 68060 is surely a more powerful CPU than a Intel 80386. I think it is only because of to less MC68K - applications for this kind of product, so that WRS can't calculate with a big profit. Now you could say:"Simple take an other realtime os (e.g. delivered by sun) or use a Java CPU". This idea is not so bad, but until now we have written about 3Megs Sourcecode, and although we tried hard to program OS independent. I think it will be a big deal to port the software to a new os (or hardware), especially because it's a lot of driver and protocol software. So we want to try the other way and port the JVM on our system. My question is: Where can we get sources or a detailed specification for a JVM, that we port to VxWorks ? (SUN does not help!) Has anybody solved this problem already? Is there someone who needs a JVM on a 68xxx board and did not ask WRS? So please do it now. Eventually it helps! Torsten -- *********************************************************************** fraunhofer institute of microelectronic circuits and systems department sat name torsten stevens mailto:stevens@ims.fhg.de address finkenstrasse 61 phone +0049/203/3783-238 47057 duisburg fax +0049/203/3783-266 germany *********************************************************************** From pat.shaw@canada.cdev.com Wed Apr 22 09:05:33 1998 From: "Shaw, Pat" Date: Wed Apr 22 09:05:37 PDT 1998 Subject: PCI Bus Hi: I am currently writting LAN/VME drivers for a Pentium based VxWorks system. We are encountering problems when multiple PCI devices connected to the second 8259 are in use. On or the other appears to crash or hang. The problem may be due to PCI devices being level triggered has compared to the edge for standard PC. I was wondering if anyone else may have seen such problems Thanks, Patrick Shaw Computing Devices Canada From nmehrotra@yurie.com Wed Apr 22 09:35:38 1998 From: nmehrotra@yurie.com Date: Wed Apr 22 09:35:43 PDT 1998 Subject: Decrementing TTL field in IP header (vxWorks) Hi folks, In vxWorks 5.2.1, the TTL field in the IP header does not seem to get decremented when vxWorks routes a packet between two physical interaces, for example between ethernet and shared memory. This is causing problems of packets that bounce forever between multiply linked machines where routing is based on subnets and default routing. Does anyone know if this problem has been fixed (SPR number?), or has some suggestion or fix we can implement ourselves. I have a TSR open with WRS. Our environment is vxWorks 5.2B with a MIPS 4700 target and a custom BSP. Host is Solaris 2.6.1. I get the daily digest so if you could please copy me (nmehrotra@yurie.com) on your responses I'd appreciate it. thanks, nitin From cbriles@lanl.gov Wed Apr 22 10:41:21 1998 From: Carolyn Briles Date: Wed Apr 22 10:41:24 PDT 1998 Subject: Flash/NVRAM weirdness on 162 Hello Everyone, We are having problems writing a second time to flash on a MVME162LC board. We are using vxWorks/Tornado 1.0 and the bsp for the 162. This entire system was set up previously with the ORV360 board, and we had no problems. The flash drivers have been rewritten for the 162 board, but the loader is the same. It seems the problem has something to do with NVRAM also, as some of it gets trashed when the flash is written to. Here's what happens: System Description 1. In the ROM we have the kernel and one task, flashTask (which reads the executable application from Flash, loads it and starts it). We have a loader application which is run on a PC and connects to the 162 via an ethernet socket. By exchanging commands with flashTask, this loader downloads the binary executable to flash. This loader worked successfully with the OR board, and when the flash is examined on the 162, it "looks like" the code is successfully in the flash. What Happens 1. We load the executable code to unwritten flash with the loader. It is happy and works just fine. The NVRAM params are set and can be reconfigured. The kernel boots and flashTask successfully retrieves and starts the application. Life is good. 2. When code is loaded for the second time, the loader works just fine. It connects to the 162 and a display from the loader screen shows some semblance of code in the right partition. HOWEVER, when I reboot the processor -- DISASTER! FlashTask completely hangs on the loadModule command. I've include the code after the body of this message, and noted where the system hangs. 3. To get restarted, I use the BUG prom and by hand, erase the first sector of Flash memory so that flashTask will not try to load the code but will start so that the loader will work. I use the loader to load the executable again. This time, rebooting the processor works just fine and the executable is retrieved, started and runs successfully. BUT, the processor type has changed from ei, to ?i! When I modify bootParams with my ROM, the changes don't stay. So I use the vxWorks ROM to change the processor back to ei, and this "sticks." However, after doing this "fix" procedure, I cannot change parameters in NVRAM, such as the host ip address and gateway. When I do try to change them, on power cycle they go back to the parameters which were used when I had the vxWorks ROM installed and booted off of my NT machine. Any thoughts or ideas as to what could be causing this problem would be greatly appreciated. What could cause loadModule to fail? Any explanations or insight into NVRAM or Flash on the 162 (it is the Intel 28F008SA part) would help also. Many thanks!! Carolyn cbriles@lanl.gov Here's the code sample from FlashTask: /************************************************************* * System startup code goes here. * * 1) Start the flashDisk device driver. * 2) Check startup arguments. * 3) Create all the flashDisk partitions. * 4) Open the code partition. * 5) Get the size of the data in the code partition. * 6) Check the size of the code partition. * 7) Get the startup parameters from eeprom. * 8) Load code from the partition. * 9) Find the startup task. * 10) Check for auto start flag. * 11) Spawn the startup task with the proper parameters. */ fd = ERROR; if(flashDiskDrv(0) != OK) logMsg("Unable to install device driver, errno=0x%x.\n", errnoGet()); else logMsg("flashDiskDrv completed successfully....\n",0,0,0,0,0,0); if(flashConfigCheck() == ERROR) logMsg("Invalid data in FLASH - auto start disabled.\n"); else logMsg("flashConfigCheck completed successfully....\n",0,0,0,0,0,0); if(flashDiskDevCreate()!=OK) logMsg("Unable to create FLASH disk, errno=0x%x.\n", errnoGet()); else logMsg("flashDiskDevCreate completed successfully....\n",0,0,0,0,0,0); if((fd = open("/fDisk/0", O_RDONLY, 0777)) == ERROR) logMsg("Unable to open code partition, errno=0x%x.\n", errnoGet()); else logMsg("Opened code partition successfully....\n",0,0,0,0,0,0); if(ioctl(fd, FIONREAD, (int)&arg) == ERROR) logMsg("Unable to get size of code partition, errno=0x%x.\n", errnoGet()); else logMsg("Size of code partition read successfully....\n",0,0,0,0,0,0); if(arg <= 50000) logMsg("Invalid code stored in FLASH, size=%d.\n", arg); else logMsg("check for invalid code completed successfully....\n",0,0,0,0,0,0); if(sysNvRamGet((char *)args,FLASH_CONFIG_SIZE,FLASH_CONFIG_OFFSET) == ERROR) logMsg("Unable to get startup info, errno=0x%x.\n", errnoGet()); else last line returned ->logMsg("sysNvRamGet completed successfully....\n",0,0,0,0,0,0); fails -> if(loadModule(fd, LOAD_ALL_SYMBOLS) == NULL) here!!! logMsg("Unable to load FLASH code into RAM, errno=0x%x.\n", errnoGet()); else logMsg("loadModule completed successfully....\n",0,0,0,0,0,0); if(symFindByName(sysSymTbl, "_mfcmStart", &addr, &type) != OK) logMsg("Unable to find system entry point, errno=0x%x\n", errnoGet()); else logMsg("symFindByName completed successfully....\n",0,0,0,0,0,0); if(args[0] == 0) logMsg("System auto-start disabled.\n"); else logMsg("Check for system auto start completed successfully....\n",0,0,0,0,0,0); From bawilson@llnl.gov Wed Apr 22 10:42:29 1998 From: "Bruce A. Wilson" Date: Wed Apr 22 10:42:32 PDT 1998 Subject: Re: windview license queue Kevin, There is a vxworks SPR #8508 that may correct your problem. Take a look on the Windsurf support webpage at wrs.com. Here's the advice given there: SPR# 8508 RTOS: VxWorks Ver: 5.3.1 Component: tornado-unknown Release #: 1.0.1 Release Status: FCS Host: All UNIX DESCRIPTION WindView fails to get a license when the user installs a single user license via the pop-up menu on Unix hosts. The work-around for the problem is: 1) If the license key has already been installed in the default directory at $WIND_BASE/.wind/license, delete the file '20.lic' in that directory. 2) Use Setup program with the -L option to install the license key in a directory other than $WIND_BASE/.wind/license. For example use $WIND_BASE/.wind. 3) Start the license daemon to serve the single user license by invoking the command line : wlmd -e $WIND_BASE/ -s 0 (The above command line could be placed in a startup script so that the daemon is run automatically when the user reboots or cycles power on his machine.) 4) Run WindView, it should successfully get a license. HTH --Bruce Wilson >Submitted-by ktsubota@keck.hawaii.edu Mon Apr 20 22:55:38 1998 >Submitted-by: ktsubota@keck.hawaii.edu (Kevin Tsubota) > > >Does anyone know why my windview license request is being queued >when no one has it, or it seems? Bruce A. Wilson U.C. LLNL ( L-054 ) P.O. Box 808 Livermore, CA 94550 From cgrames@mdc.com Wed Apr 22 12:25:30 1998 From: Charlie Grames Date: Wed Apr 22 12:25:34 PDT 1998 Subject: Odd Interrupt Vectors on MVME2604 VxWorks 5.3.1 MVME2604 1.1/4 A while back, someone mentioned in this venue that they could not use the 1.1/4 release of the MVME2604 BSP because it did not handle odd-numbered VMEbus interrupt vectors properly. Wind River's stance has been that this is because of the way the Universe PCI-VME chip handles interrupt acknowledges. The claim is that the least significant bit of the vector is used to indicate a software interrupt acknowledge and is reserved. Well, Wind River is wrong. The information they are referring to applies to how the Universe DELIVERS interrupt vectors IN RESPONSE TO interrupt acknowledge cycles (as defined in the Interrupt Status/ID Out or STATID register), _not_ how it ACCEPTS interrupt vectors WHEN GENERATING interrupt acknowledge cycles (as defined in the VIRQx Status/ID or Vx_STATID registers). Wind River's misunderstanding led to a coding error in the file universe.c. To correct the error, locate the following line in the routine sysUnivLevelDecode(): *vecNum = vector & 0xFE; /* only seven bits of useful info */ and change it to this: *vecNum = vector & 0xFF; /* vector is in 8 LSBs */ After making this change, my 2604 board was able to handle odd-numbered interrupt vectors without problem, just as it had done with the 1.1/3 BSP. I have submitted this problem to Wind River, and I'm sure a formal correction will be forthcoming. Until then, I hope this tweak will help out someone else. Charlie Grames The Boeing Company (314) 233-1956 Charles.R.Grames@boeing.com From caprio@research.moore.com Wed Apr 22 12:40:23 1998 From: Jim Caprio Date: Wed Apr 22 12:40:27 PDT 1998 Subject: Profiling/Memory Usage We are experiencing a problem with our vxWorks/PPC (mv2604) application in which the PPC board completely hangs up, prohibiting any post-mortem analysis at all. Naturally, we suspect memory problems (leaks and/or corruption). Do you know of any profiler tools available for this configuration, which provide a more complete picture of memory utilization than that given by the Tornado browser? We also have WindView, but it does not seem to provide this capability. Thanks. ================================= Jim Caprio Moore Research Center, Inc. (716)773-0333 FAX : (716)773-0462 email: caprio@research.moore.com ================================= From bpringle@teklogix.com Thu Apr 23 07:03:02 1998 From: Bill Pringlemeir Date: Thu Apr 23 07:03:05 PDT 1998 Subject: java virtual mashine for 68xxx ? (VxWorks) Hello, The obvious reason for lack of 68xxx support is that Sun doesn't have a version of the JVM for the 68k. At least some parts of JDK1.1.x were written in assembler to increase the speeds of the JVM. Sun is more interested in supporting Solaris than the Mac. However, our Mac friends have done some work to get Java working on the 68K. There are several freeware versions of a JVM. http://www.hungry.com/products/japhar/ http://www.kaffe.org/ I think that the linux version of Kaffe maybe easiest to port. Your main problem is not with the JVM, but with the mapping of JDK methods to the VxWorks functions. Also, you must have some sort of windowing/simple raster graphics to map the AWT to. Have fun, Bill Pringlemeir Software Engineer Teklogix Inc. Toronto, On. Canada From tony.mayes@epid.eurotherm.co.uk Thu Apr 23 07:23:09 1998 From: "Tony Mayes" Date: Thu Apr 23 07:23:13 PDT 1998 Subject: VxWorks and RPL We currently remote boot our embedded PC targets using the FTP facility of VxWorks. However I have heard of a microsoft way of doing this called RPL. Does anyone know if Vxworks supports the micorsoft remote boot "RPL"? Or has anyone any experience of this? Thanks in advance Tony Tony Mayes (The opinions expressed within are my own) Email address tony.mayes@epid.eurotherm.co.uk Phone (0039)(0)31 975243 Fax (0039)(0)31 977252 Eurotherm SpA, Via XXIV Maggio, 22070 Guanzate (CO), Italy From larry@dogwood.com Thu Apr 23 08:21:43 1998 From: Larry Gadallah Date: Thu Apr 23 08:21:51 PDT 1998 Subject: Modification of TCP timers Hello, I would like to use the SO_KEEPALIVE socket option to detect a dead TCP/IP connection, and the manual makes clear reference to the TCP timer values declared in h/netinet/tcp_timer.h. However, I do not have a source licence for VxWorks and the question arises: What is the best way to modify these timer values at runtime? Should this be done before or after network initialization? Is there a better way to achieve the same result without fooling with the tcp_* globals? Thanks, -- Larry Gadallah, VE6VQ larry@ve6vq.ampr.org Calgary, Alberta +1 403 295-4271 Key fingerprint = D6 79 5D 9D 41 27 74 03 68 FD D7 F3 86 68 EB A5 From roddy.pratt@oxtel.com Thu Apr 23 08:23:13 1998 From: Roddy Pratt Date: Thu Apr 23 08:23:16 PDT 1998 Subject: Fast Ethernet ISA card. Keywords : VxWorks, Tornado Yet another question about driver availability (sorry!) We're looking for an ISA 100Mbit Ethernet card (preferably 10/100) to = use with Vxworks/Tornado 1.0.1 in our embedded products. If anybody knows of a = suitable card for which VxWorks drivers are available, please contact = me. Thanks, Roddy Pratt From kb+@andrew.cmu.edu Thu Apr 23 09:39:19 1998 From: Kevin Bradley Date: Thu Apr 23 09:39:22 PDT 1998 Subject: PentiumPro Memory Init In a twist of fate, I have an experimental PentiumPro system that was given to us ages ago by Intel. I'm interested in using VxWorks on it, but there's problems in memory performance. Apparantly the PentiumPro can define memory ranges as cacheable or uncacheable, with uncacheable being default on power-up. The BIOS in this computer doesn't mark its pages as cacheable as production systems do. Instruction memory marked as uncachable has serial access to the pipeline, apparantly, as we're observing CPI of +50. VxWorks doesn't appear to know about this feature in its cache or memory initialization functions, so it remains in its power-on default state (uncacheable). It strikes me that I've seen ads for PentiumPro boards running VxWorks, and definitely not in PC BIOS-based systems, so somebody must know how to configure the memory somewhere. This leads me to three questions. 1) How are the memory systems initialized, esp. caches, initialized in VxWorks? I realize it's system-specific, so information for x86 systems is especially relevant. I don't want to have my "patch" interfered with by what VxWorks does by itself... 2) Has anyone out there written a PentiumPro memory system initialization routine using the MTRRs? If so, are you willing to share? This for research purposes, not for products. 3) Where in the boot sequence would it be proper to insert code to initialize the memory hierarchy, given adequate answers (1) and (2)? Should this be done in the boot code, or in the kernel code before usrRoot is spawned? Background on why I care about this: We're doing performance modeling, and one thing we'd like to try is evaluating performance across architectures. So we have a model of how a Pentium system works, and were trying to get a similar model for a PentiumPro system. This lead to the terrible discovery of how hosed the memory system we have is (after discussions with contacts at Intel). Our model is a first-order linear approximation for a code block, with number of instructions, number of reads, and cache performance incorporated into it. We'd like to be able to take a model from one system, predict performance on another, and see how close it comes. Having vastly different features on the Pentium Pro system isn't helping this process. Upgrading motherboard, BIOS, CPU, etc. aren't viable options, as these cost, and it's not worth it for us to do this. The machine was free in the first place, after all... I appreciate any help I can get! -- Kevin From leg@tsg.adc.com Thu Apr 23 11:57:56 1998 From: leg@tsg.adc.com (Gioi Le) Date: Thu Apr 23 11:58:04 PDT 1998 Subject: PowerPc 750 Will your vxWorks BSP support PowerPc 750? leg@adc.com Gioi Le. From shoutchen@SYSTRAN.com Thu Apr 23 13:59:00 1998 From: Steve Houtchen Date: Thu Apr 23 13:59:03 PDT 1998 Subject: VxWorks or Tornado users Greetings VxWorks or Tornado users Can anyone tell me where to get an FTP server to run on NT workstation so I can do development on it.? Steve Houtchen shoutchen@systran.com From cbriles@lanl.gov Thu Apr 23 14:01:30 1998 From: Carolyn Briles Date: Thu Apr 23 14:01:34 PDT 1998 Subject: mmu on 162 Hello Everyone, I am following several paths regarding the Flash/NVRAM weirdness questions of a previous message, and in that, am wondering about the MMU on the mvme162. I have all MMU stuff commented out in my vxWorks headers files. My questions are: 1. What does the MMU do? Why would I enable it? Why would I not? What are the ramifications of not enabling it when it should be enabled? 2. How do you configure the MMU in vxWorks for a mvme162? The reason I have references to it commented out in my header files is because when I was initially working with the flash memory, I could not address it with the MMU enabled. Thanks for your help! Carolyn cbriles@lanl.gov From blohm@vs.dasa.de Fri Apr 24 01:36:53 1998 From: "Gundula Blohm" Date: Fri Apr 24 01:36:58 PDT 1998 Subject: Re: VxWorks or Tornado users On 23 Apr 98 at 13:59, the vxWorks Users Group Explo wrote: > Submitted-by shoutchen@SYSTRAN.com Thu Apr 23 13:59:00 1998 > Submitted-by: Steve Houtchen > > Greetings VxWorks or Tornado users > > Can anyone tell me where to get an FTP server to run on NT > workstation so I can > do development on it.? > > > Steve Houtchen > shoutchen@systran.com Steve, With NT4 WS use the MicrosoftPeerWebServer which includes a FTP server. Install with start | control panel | network | services | add Configure it to allow non anonymous login, add a NT user with password, use this user and password in your target board configuration, set the ftproot to the directory where the vxworks file resides, tell the target board configuration only the filename and all works fine. two more hints: - you need administrator rights on your local machine to install MicrosoftPeerWebServer. - after installing MicrosoftPeerWebServer you must (!) reinstall servicepack3 once more. HTH, dula =================================================== Gundula Blohm Tel. +49 (731) 392-4731 Fax +49 (731) 392-4958 mailto:blohm@vs.dasa.de =================================================== From tony.mayes@epid.eurotherm.co.uk Fri Apr 24 04:10:53 1998 From: "Tony Mayes" Date: Fri Apr 24 04:10:56 PDT 1998 Subject: Re: VxWorks or Tornado users Steve Houtchen wrote:- > Greetings VxWorks or Tornado users > > Can anyone tell me where to get an FTP server to run on NT > workstation so I can > do development on it.? > Install the internet FTP services, works in servers and workstations, I think its called Internet Information Services, or something like. We have had to make our user, that FTP logs in to, an administrator otherwise the remote boot does not work. Tony Tony Mayes (The opinions expressed within are my own) Email address tony.mayes@epid.eurotherm.co.uk Phone (0039)(0)31 975243 Fax (0039)(0)31 977252 Eurotherm SpA, Via XXIV Maggio, 22070 Guanzate (CO), Italy From mea@mclean.sparta.com Fri Apr 24 04:58:37 1998 From: "Mike Anderson" Date: Fri Apr 24 04:58:40 PDT 1998 Subject: RE: mmu on 162 > Submitted-by: Carolyn Briles > > Hello Everyone, > > I am following several paths regarding the Flash/NVRAM weirdness > questions of a previous message, and in that, am wondering about > the MMU on the mvme162. I have all MMU stuff commented out in my > vxWorks headers files. My questions are: > > 1. What does the MMU do? Why would I enable it? Why would I not? > What are the ramifications of not enabling it when it should be enabled? Well, of course, then MMU is the Memory Management Unit. But, I'm sure you already knew that. In a typical system, the MMU is responsible for dealing with the mapping of phyical memory (or memory mapped devices) into a *virtual* address space of the processor. With the MMU, two physically separate address spaces like $800000 in A24 and $40000000 in A32 could be made to appear as though they are contiguous. But that's not all. The MMU is also used to mark regions of memory as accessible, writable and cacheable. As to why you should enable it, the answer is "it depends". Each memory access that is generated by the processor is checked by the MMU for those three charateristics I just mentioned. This slows the processor down. There are DTTRs (data transparent translation registers) on the CPU that can be used to mark regions of memory as accessible, but I'm not sure about cacheability. Having the caches enabled can make as much as %30-%50 improvement in you application's performance. So, that feature alone may make the overhead of the MMU worth the price. The MMU simply makes the cacheability of regions of memory easier to deal with. To enable it on the 162, just go into the config.h in your BSP directory and make sure that the MV162_68EC040 define is not enabled and that INCLUDE_MMU_BASIC is defined. Providing you haven't made any other hacks to the BSP, the sysPhysMemDesc (system physical memory descriptor) located in sysLib.c should be enabled. Your FLASH memory will then have to be mapped by adding a section to sysPhysMemDesc like this: /* FLASH */ { (void *) , (void *) , , VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE_NOT }, The VM_STATE_CACHEABLE_NOT flag should be changed to VM_STATE_CACHEABLE if you want the FLASH to be cacheable (This might interfere with FLASH programming). Then you'll need to rebuild VxWorks an reload. Provided your CPU wasn't a MC68EC040 (which doesn't have an MMU), your system should be up and the FLASH accessible. > > 2. How do you configure the MMU in vxWorks for a mvme162? > See above. > The reason I have references to it commented out in my header files > is because when I was initially working with the flash memory, I could > not address it with the MMU enabled. > HTH, ============================================================================ === Real-Time System Development, Integration, Training and Services Mike Anderson mea@mclean.sparta.com Chief Engineer http://www.mclean.sparta.com SPARTA, Inc. V: (703) 448-0210 F: (703) 893-5494 "Software development is like making a baby... You can't make a baby in one month by impregnating nine women. Some things just take time." The opinions are mine... no one else would want to claim them ;-). ============================================================================ === From abbottd@jlab.org Fri Apr 24 06:47:39 1998 From: David Abbott Date: Fri Apr 24 06:47:42 PDT 1998 Subject: MVME230X Full Duplex Hello vxWorks folks, Does anyone out there know how to set up the Dec21140 driver for the MVME230X/MVME260X to run in full duplex mode. Presumably it should be as simple as setting the right bits in the DC_MODE definition in config.h and rebuilding the kernel. However, I do not have access to the driver source code so I am clueless as to what all the DC_MODE options are. Also, Is there any reason why the half-duplex/full-duplex mode switching could not be done on the fly after the board is booted? It would be nice NOT to have two different kernels for the two modes of operation Thanks, David David Abbott Jefferson Lab Data Acquisition Group EMAIL: abbottd@jlab.org Tel: (757) 269-7190 FAX: (757) 269-5800 From caprio@research.moore.com Fri Apr 24 09:22:56 1998 From: Jim Caprio Date: Fri Apr 24 09:23:03 PDT 1998 Subject: Bootable application I'm modifying usrConfig.c as directed in Sec 9.5 of the Tornado User's Guide ("Creating Bootable Applications"), in preparation for statically linking my application with the kernel, and am a bit confused about where to place the taskSpawn() hook to my user application. (1) The user's guide suggests placing it after the INCLUDE_DEMO example. (2) However, the usrConfig.c file contains an #ifdef INCLUDE_USER_APPL block that seems to imply this is the proper spot. The relative behavior between these options is different, in that option (1) would only execute if INCLUDE_SHELL was false (which perhaps is logical for a statically linked application), while option (2) would launch the user application independent of this variable. I'd appreciate some insights into the most reasonable way to approach this. Thank you. ================================= Jim Caprio Moore Research Center, Inc. (716)773-0333 FAX : (716)773-0462 email: caprio@research.moore.com ================================= From mikem@sdlabs.com Fri Apr 24 10:09:09 1998 From: Michael Morrison Date: Fri Apr 24 10:09:12 PDT 1998 Subject: SENS 1.0 Beta2 -- Does it work?? Hi vxworks users, I recently installed SENS 1.0 Beta2. I have a server running on the target that listens on a socket for data. After sending data to the socket, the tNetTask crashes with a page fault. I figure it's either an installation problem, or there is something broken in the stack. Yes, I did recompile everything. Target is a pc486. Has anyone else come across problems like this? Thanks mikem@sdlabs.com From jford@sadira.gb.nrao.edu Fri Apr 24 11:22:47 1998 From: John Ford Date: Fri Apr 24 11:22:50 PDT 1998 Subject: Re: SENS 1.0 Beta2 -- Does it work?? > Submitted-by mikem@sdlabs.com Fri Apr 24 10:09:09 1998 > Submitted-by: Michael Morrison > > Hi vxworks users, > > > I recently installed SENS 1.0 Beta2. I have a server running on the > target that listens on a socket for data. After sending data to the > socket, the tNetTask crashes with a page fault. I figure it's either an > installation problem, or there is something broken in the stack. Yes, I > did recompile everything. Target is a pc486. Has anyone else come > across problems like this? We just installed SENS for 68k, and found it to be configured way too small for our use. Our systems all managed to deplete the buffers allocated by the standard configuration. We quadrupled the allocated mbufs, and things are much better. There are 2 show routines that might shed light on your problem: netStackDataPoolShow and netStackSysPoolShow However, the kernel came up fine for us, and then our application code crashed, not the net task. We found, though, that some code compiled with pre-SENS headers and libraries *Would* completely lock the system if we tried to execute them. John From caprio@research.moore.com Fri Apr 24 11:40:06 1998 From: Jim Caprio Date: Fri Apr 24 11:40:10 PDT 1998 Subject: Task Context Switch Can you tell me if a VxWorks task calls semTake on a (counting) semaphore which is immediately available, will that task continue to run uninterrupted, or will the call serve as a rescheduling event regardless of the semaphore's state? Thanks. -- ================================= Jim Caprio Moore Research Center, Inc. (716)773-0333 FAX : (716)773-0462 email: caprio@research.moore.com ================================= From froeber@BBN.COM Fri Apr 24 13:05:15 1998 From: Fred Roeber Date: Fri Apr 24 13:05:19 PDT 1998 Subject: RE: mmu on 162 Carolyn Briles asked some questions and Mike Anderson answered most of them. I'd like to add a bit to some of Mike's answers: > > 1. What does the MMU do? Why would I enable it? Why would I not? > > What are the ramifications of not enabling it when it should be enabled? > > In a typical system, the MMU is responsible for > dealing with the mapping of phyical memory (or memory mapped devices) > into a *virtual* address space of the processor. With the MMU, two > physically separate address spaces like $800000 in A24 and $40000000 > in A32 could be made to appear as though they are contiguous. But > that's not all. The MMU is also used to mark regions of memory as > accessible, writable and cacheable. VxWorks uses a "flat" memory model by default where physical and virtual memory don't differ in terms of addresses. Unlike some embedded OSes like QNX, VxWorks doesn't typically provide different address spaces for different tasks. This means VxWorks requires less MMU manipulation and therefor improves execution speed (at some cost in terms of bug isolation). The MMU in VxWorks is primarily used simply to control the readability and cacheability of memory (some people do use VxVMI extended memory management support to do more but not many as far as I know). If you want to enable the data caches on your 162 processor then you will most likely need to use the MMU too. I say "most likely" because the 162 also has two DTTR registers that can be used to provide more efficient memory access control than the MMU. The DTTR registers let you specify cacheability on large areas of memory with a single register setup. Trying to set up access to large memory areas with the MMU is not recommended since the MMU control table setup is slow and the tables get big. The restriction with the DTTR is that there are only two of them and they can only control access coarsely. If you are using a single CPU system, then you could set DTTR1 to make all of memory uncached and then use DTTR0 to make just the local DRAM cached. DTTR0 overrides DTTR1 when both cover the same address area. In general, you don't want anything other than local DRAM cached because the other accessible things are typically areas that are mapped for access by other devices. If those areas are set as cacheable, you can run into all sorts of weird problems when the memory is changed by the external device but not recognized by the local processor since it is looking at the value in cache. This is an area where many people have been burnt. Now as to why you would need to actually use the MMU. In some cases, you can't just make all of local memory cached. A prime example of this is the case where local memory is accessed by external devices. With the MVME162, the local peripherals actually provide some "cache coherency" support so it is safe to have the local memory cached and still used by the on board devices (e.g. the ethernet chip). The problem comes in if some off card device wants to access the MVME162 memory. This is the case, for example, with the memory used on "processor 0" with the VxWorks backplane IP driver. If you are using the backplane driver or other processors trying to write to your CPUs memory then you HAVE to use the MMU if you want the data cache on. The reason for this is that setting up DTTR0 to make memory cached is limited to ranges that are power of two multiples of 16MB. If your board only has 4MB of DRAM, then your only choice with DTTR0 would be to make all DRAM cached (as well as 12MB of memory space past the end of the DRAM). The MMU gives you control over memory access with a granularity of 4KB. If you use the DTTR1/DTTR0 scheme above, you could use the MMU to make the local memory areas that need to be shared externally uncached using the MMU. It might be simpler, however, to just mark all of memory as uncached using DTTR1 and then use the MMU to make the unshared local DRAM areas cached. The 162 version of the BSP provides an assembler function to set up DTTR1 and the MMU is controlled statically by the sysPhysMemDesc table or dynamically by the different vmLib functions. Hope the information helps. Unfortunately, getting caching set up right is not easy or well described in many places. Worse, caching problems are among the toughest to track down. Oh well. Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From prewitt@ticipa.Works.ti.com Fri Apr 24 13:38:46 1998 From: prewitt@ticipa.Works.ti.com (Jim Prewitt) Date: Fri Apr 24 13:38:50 PDT 1998 Subject: VxWorks BSP for the MVME2304? Date: 24 Apr 98 To: vxwexplo@lbl.gov From: James O. Prewitt Subj: VxWorks BSP for the MVME2304? I have worked extensively with the MVME2604, based on the 604. I now have a potential application for the MVME2304, which supposedly uses the 603. Does anyone have any experience in both the 2604 and 2304 they could share with me? Thanks, Jim Prewitt prewitt@works.ti.com From caprio@research.moore.com Fri Apr 24 14:17:54 1998 From: Jim Caprio Date: Fri Apr 24 14:17:57 PDT 1998 Subject: PPC mv2604 Lockup (new BSP) Here's a problem I reported to WRS support. I'd appreciate any information you might have! Configuration: VxWorks 5.3.1, Tornado 1.0.1, PowerPC 604e (mv2604 BSP) Problem: MVME2604 locks up after 20 - 30 min of running application (BSP rev "/4") Problem disappears when using previous version of BSP (rev "/2"). Details: Our VxWorks application performs raster image processing of a data stream into a bitmap for printing. After running ~300 pages of a given job, the CPU board locks up tight. This only occurs when running outside the debugger; while running in the debugger, the job will run indefinitely. The browser indicates a slow memory leak, but nothing that explains a complete processor lockup. We recently upgraded to the rev "/4" mv2604 BSP release (as indicated in the config.h), which supposedly resolved many interrupt problems from rev "/2", including some that would lock up the board, particularly during ethernet activity. The above problem occurs when running with the new BSP. NOTE that the problem disappears when running with the OLDER mv2604 BSP! Please alert us to any problems detected with the upgraded (rev "/4") mv2604 BSP which may cause board lockup. Note that this is not explained by application task deadlock, as even the target shell task is frozen. Here's a final clue: we originally ran with the following kernel configuration (in addition to the default factory settings): (INCLUDE_)CPLUS, CPLUS_IOSTREAMS, CPLUS_VXW, // C++ CPLUS_HEAP, CPLUS_TOOLS DEBUG, RDB // Debug support SHELL, LOADER, UNLOADER // Target shell & loader SYM_TBL, NET_SYM_TBL, STAT_SYM_TBL, SYM_TBL_SYNC // Symbol table support STARTUP_SCRIPT SHOW_ROUTINES TIMESTAMP, INSTRUMENTATION, WINDVIEW // WindView An alternative kernel was built with the following features (from the above set) removed: {DEBUG, RDB, STAT_SYM_TBL, SYM_TBL_SYNC, SHOW_ROUTINES, TIMESTAMP, INSTRUMENTATION, WINDVIEW} THIS kernel causes the lockup to occur almost immediately!! -- ================================= Jim Caprio Moore Research Center, Inc. (716)773-0333 FAX : (716)773-0462 email: caprio@research.moore.com ================================= From mike@CastleNetworks.com Fri Apr 24 14:18:21 1998 From: Mike Catalanotti Date: Fri Apr 24 14:18:24 PDT 1998 Subject: MTX60x and PCI Adapters & Booting MTX from ATA Drive Fellow vxWorkers: ******* Anyone have experience with getting a PCI card's address space enabled on an MTX 603 - 001a SBC? We can see the card in the slot(s), read and write it's PCI Configuration Address space, enable the board, but are unable to do any direct I/O to the registers on said card. It seems the BSP does does not account for these three PCI slots on the board (the MTX 603-003a flavor of the board only has one PCI slot which we cant make work, and 2 PMC slots). ******* Anyone ever successfully booted a vxWorks image from an ATA hard drive on an MTX60x SBC? There is no support for this from WRS, but I have managed to get it to boot from flash, locate the hard drive, load the vxWorks file from the root partition of the DosFS. The following events show up on the console: ======== BEGIN CONSOLE DATA DUMP ============ [VxWorks Boot]: c '.' = clear field; '-' = go to previous field; ^D = quit boot device : ata=0,0 processor number : 0 host name : serenity file name : /ad0/vxworks inet on ethernet (e) : inet on backplane (b): host inet (h) : gateway inet (g) : user (u) : anonymous ftp password (pw) (blank = use rsh): mtx1 flags (f) : 0x8 target name (tn) : mtx1 startup script (s) : other (o) : [VxWorks Boot]: @ boot device : ata=0,0 processor number : 0 host name : serenity file name : /ad0/vxworks inet on ethernet (e) : host inet (h) : user (u) : anonymous ftp password (pw) : mtx1 flags (f) : 0x8 target name (tn) : mtx1 Creating ATA disk device: done. Loading /ad0/vxworks... program Exception current instruction address: 0x03ffaa98 Machine Status Register: 0x0008b000 Condition Register: 0x24000080 Task: 0x3ff5a58 "tBoot" r0 = 3ffaa98 sp = 3ff5360 r2 = 0 r3 = 3fffeb0 r4 = 3ff5370 r5 = 0 r6 = 0 r7 = 2e r8 = 32 r9 = 3ffab80 r10 = 3ffae28 r11 = 260000 r12 = 0 r13 = 0 r14 = 0 r15 = 0 r16 = 0 r17 = 0 r18 = 0 r19 = 0 r20 = 0 r21 = 0 r22 = 0 r23 = 0 r24 = 0 r25 = 0 r26 = 0 r27 = 0 r28 = 4 r29 = 3ff59e0 r30 = 3ff5594 r31 = 3ffff50 msr = 8b000 lr = 22e694 ctr = 0 pc = 3ffaa98 cr = 24000080 xer = 20000000 [VxWorks Boot]: ======== END CONSOLE DATA DUMP ============ The routine named "bootLoadModule" which loads and boots the new vxWorks image is where the problem trail off from. I will be more than happy to share any/all relevant information back to the VxWorks Exploder list. Mike C Castle Networks, Inc Westford MA 01886 "And so castles made of sand slip into the sea, eventually" - J Hendrix From daemon@csg.lbl.gov Sat Apr 25 04:04:09 1998 From: daemon@csg.lbl.gov Date: Sat Apr 25 04:04:12 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Apr 25 04:04:07 PDT 1998 Subject: intConnect Subject: Re: Poor TCP/IP performance ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: intConnect Date: Wed, 22 Apr 1998 14:44:00 -0600 From: radcliff@jps.net Organization: Deja News - The Leader in Internet Discussion Message-ID: <6hlha0$98b$1@nnrp1.dejanews.com> Reply-To: cory@synerdyne.com I was told in the Device Drivers class by WindRiver that intConnect was never to be called within the driver but rather in the system initialization code, which means that you have to actually compile the driver in with the OS and download the whole darn thing everytime you add a driver. This is rather unsavory, in my opinion. I would rather download a driver that has a static method that installs it into the system, including connecting to the interrupt. Does anyone really know what the problem with calling intConnect within driver code is? I am assuming that the reason is that they don't want to have just *anyone* calling intConnect and supplanting ISRs from other drivers, but if we are all using the same information to develop the drivers we all know which interrupt is take and which is not. - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Poor TCP/IP performance Date: Tue, 21 Apr 1998 12:37:39 -0600 From: Chris Webster Organization: NCAR Research Aviation Facility Message-ID: <353CE773.EB090D22@raf.atd.ucar.edu> References: <353CA1B5.7D5F22C3@sea.ericsson.se> <353CB0F4.49501CAA@raf.atd.ucar.edu> <353CE0FA.914F73C0@pop3.ancore.com> > I have found two problems with network performance under 5.3. One is a > bug with the TCP NODELAY option. It seems to break big packets into > several small packets. Aren't all packets broken down into 1500 byte segments for ethernet? > The second problem is the default buffer size for > send and receive, they are way to small. They work best as multiples of > the MAX_SEG size of the TCPIP. Use the global variables tcp_sendspace > and tcp_recvspace to change the default buffer sizes. Does setsockopt() just set these variables or are these something different? I couldn't find any reference to them in the manuals. Also I noticed things could be sped up by using the zbufSockSend() instead of send()/write().... > I do not know how well it will help the UDP stuff though ... If it's the same as the setsockopt(SO_SENDBUF/SO_RECVBUF), then it works for UDP (at least on the Solaris side). - --Chris I worry that the person who thought up Muzak may be thinking up something else. --------------------------- End of New-News digest ********************** From bob@seaweed.com Sat Apr 25 19:51:21 1998 From: bob schulman Date: Sat Apr 25 19:51:32 PDT 1998 Subject: compiling PPC-based gcc for VxWorks Anyone have a clue as to which command line flags to give to ./configure when generating a version of gcc for PowerPC targets which run VxWorks? I've got gcc, of course, from WRS running on my Sun and generating code for my PowerPC target, but I'd like to run gcc from a Linux box as well (please, no harping about WRS' lack of support of Linux in response to this note!). Looking through the source for the ./configure shell script indicates use of some header files which, eh-hem, are not in the public distribution of gcc. Anyone got a clue? Thanks. Bob Schulman bob@seaweed.com +1 510.482-3575 From daemon@csg.lbl.gov Sun Apr 26 04:02:17 1998 From: daemon@csg.lbl.gov Date: Sun Apr 26 04:02:21 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Apr 26 04:02:13 PDT 1998 Subject: Booting from flash Subject: Re: VxWorks Driver for 1553 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Booting from flash Date: Tue, 21 Apr 1998 17:17:05 -0500 From: "Paul A. Bennett" Organization: Virtual Prototypes Inc. Message-ID: <353D1AE1.A0AD2471@VirtualPrototypes.CA> Reply-To: bennett@VirtualPrototypes.CA Hello! Has anyone tried booting VxWorks x86 from a flash disk? Any suggestions on reading? We're trying to work with an M-Systems PC-104 flash disk. Any help would be appreciated. Thanks. Paul - -- - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Paul A. Bennett, TEL: +1-514-341-3874 #280 Manager, Technical Marketing, FAX: +1-514-341-8018 Virtual Prototypes Inc., E-MAIL: bennett@VirtualPrototpes.CA 4700 de la Savane, URL: http://www.VirtualPrototypes.CA Suite 300, Montreal, Quebec, Canada H4P 1T7 - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks Driver for 1553 Date: 25 Apr 1998 14:33:45 GMT From: le_roy@club-internet.fr Organization: Linux site Message-ID: <6hss89$1l5$1@localhost.no-domain> References: <6hrcg9$pjj@news1.saix.net> Paul Chien wrote: > Does anyone know where I can a 1553 board with VxWorks driver support ? > Any VxWorks drivers for a Condor 1553 board ? Look at www.vita.com - - VME product directory, Product Function Index, VME bus interfaces to other buses, VME bus to MIL-STD-1553) - - Mezzanine product directory, ... SBS products are shipped with vxWorks drivers ... Marc. --------------------------- End of New-News digest ********************** From mea@mclean.sparta.com Sun Apr 26 13:55:30 1998 From: "Mike Anderson" Date: Sun Apr 26 13:55:34 PDT 1998 Subject: RE: comp.os.vxworks newsdigest > Subject: intConnect > > I was told in the Device Drivers class by WindRiver that intConnect was never > to be called within the driver but rather in the system initialization code, > which means that you have to actually compile the driver in with the OS and > download the whole darn thing everytime you add a driver. This is rathe= r > unsavory, in my opinion. I would rather download a driver that has a static > method that installs it into the system, including connecting to the > interrupt. Does anyone really know what the problem with calling intConnect > within driver code is? I am assuming that the reason is that they > don't want to have just *anyone* calling intConnect and supplanting > ISRs from other drivers, but if we are all using the same information > to develop the drivers we all know which interrupt is take and which is not. > VxWorks Greetings! I beg to differ. If you are writing the device driver, then the intConnect calls *should* be called in your xxDrv or the xxDevCreate function (depending on whether you can instantiate multiple devices with your driver or not). The only concern that you should have is whether or not the interuppt vectors that you're planning to use are already occupied. For that, download the "veclist.c" code from the user's group archives (many thanks to Jeff Hill who wrote it) and run a "veclist" to see the vectors that are in use. Then just pick ones that are idle for your device(s). Obviously, you should take every effort to make sure that your device is in a quiesent state prior to attaching the interrupt handler. But, there have never been any WRS enforced restrictions as to when you can call intConnect. I can only imagine that you must have heard the WRS instructor incorrectly. I could understand saying that regarding calling intConnect in an ISR (sort of), but not calling intConnect in a device driver is insane. You do not have to link your device driver into the O/S either. Dynamic loading and instantiation of the device driver/device is perfectly legitimate. HTH, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Real-Time System Development, Integration, Training and Services Mike Anderson=A0=A0=A0=A0=A0=A0=A0=A0 mea@mclean.sparta.com Chief Engineer=A0=A0=A0=A0=A0=A0=A0 http://www.mclean.sparta.com SPARTA, Inc.=A0=A0=A0=A0=A0=A0=A0=A0=A0 V: (703) 448-0210=A0 F: (703) 893= -5494 "Software development is like making a baby... You can't make a baby =A0in one month by impregnating nine women.=A0 Some things just take time= ." =A0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =A0 From vxworks@orbital.com Sun Apr 26 14:30:01 1998 From: vxworks@Orbital.COM Date: Sun Apr 26 14:30:05 PDT 1998 Subject: Job Opportunity! Looking for a Software Engineer to design, implement, and test real-time embedded software for satellite microprocessors. Requires a minimum of 5 years experience, including C, real-time OS familiarity, embedded microprocessors, and cross-platform software development in a UNIX environment. Ideal candidate would have VxWorks/Tornado experience on a 68xxx microprocessor in a UNIX development environment. Position is with Orbital Sciences Corporation at it's Dulles, VA headquarters. Please send email replies, with attached (MS Word or ASCII text) or embedded resume, to: VXWORKS@orbital.com. Faxed responses may be sent to 703-406-5579, to the attention of S. Eckardt. From roghol@lin.foa.se Sun Apr 26 23:56:59 1998 From: Roger Holmquist Date: Sun Apr 26 23:57:02 PDT 1998 Subject: Re: Job Opportunity! >Submitted-by vxworks@orbital.com Sun Apr 26 14:30:01 1998 >Submitted-by: vxworks@Orbital.COM > > > > Looking for a Software Engineer to design, implement, and test > real-time embedded software for satellite microprocessors. Requires a > minimum of 5 years experience, including C, real-time OS familiarity, > embedded microprocessors, and cross-platform software development in a > UNIX environment. Ideal candidate would have VxWorks/Tornado > experience on a 68xxx microprocessor in a UNIX development > environment. > > Position is with Orbital Sciences Corporation at it's Dulles, VA > headquarters. > > Please send email replies, with attached (MS Word or ASCII text) or > embedded resume, to: VXWORKS@orbital.com. Faxed responses may be sent > to 703-406-5579, to the attention of S. Eckardt. > Hello! I read the above ad for a RTOS SW engineer. Im working here in Sweden, Europe for the National Defence Research Establishment. We have been developing SW on different platforms for a VME-system containing Motorola VME-cards, MVME 147, 162, 165, 167, 177 for over 10 years. My own part is developing SW for a MVME 162-card including an IP-module containing a Greenspring A/D-converter. This also includes some experience in socket programming. Out targets are connected to the host machine via ethernet. The SW is a part of a RF direction finding system, and is intended to analyze RF-signals emitted by digitally modulated "short-time-transmitters". Our development platform for the last 2 years is an Ultra SPARC and we are running vxWorks on that machine. I dont know if you are interested in foreign SW developers. If you are, please reply for additional information. Greetings / Roger #------------------------------------------------------------------# # Roger Holmquist, FOA, National Defence Research Establishment # # sect 750, Olaus Magnus vag 42, Box 1165, 581 11 LINKOPING ------# #---------------------------- SWEDEN ------------------------------# # Phone: +46 13-378382 --------------------------------------------# # Fax: +46 13-378009 ----------------------------------------------# # Home: +46-13-214733 Mobile +46-706-250123 ----------------------# # Email: roghol@lin.foa.se ----------------------------------------# #------------------------------------------------------------------# From rtp.co.uk!ihw@rtp.co.uk Mon Apr 27 00:30:20 1998 From: Ian Willats Date: Mon Apr 27 00:30:24 PDT 1998 Subject: Re: Booting from flash Paul A. Bennett asked: > Has anyone tried booting VxWorks x86 from a flash disk? I have done this, using a PC-104 board from Megatel. They provided DOS-based tools to initialise a DOS file system in flash memory, and then I simply used the WRS utilities (vxcopy, vxsys, makeboot, et al) to copy either the VxWorks boot code or the system image itself into the flash as a bootable file. I did not access the flash memory at all once VxWorks was running. Although a simple-minded solution, this worked fine. I'd imagine it was applicable to other similar hardware, too. HTH Ian --------------------------------------------------------------- Ian Willats e-mail: mailto:ihw@rtp.co.uk Real-Time Products Ltd. direct: +44 (0) 121 234 6637 Chancery House, tel: +44 (0) 121 234 6600 8 Edward Street, Birmingham. fax: +44 (0) 121 234 6611 B1 2RX. England. web: http://www.rtp.co.uk --------------------------------------------------------------- From larry.dalessandro@ae.ge.com Mon Apr 27 06:42:15 1998 From: "DAlessandro, Larry (GEAE)" Date: Mon Apr 27 06:42:19 PDT 1998 Subject: Caching and Snooping with MV177/68060 @ 60 Mhz > Hello everyone, > > I while back I posted the following: > > " I run a system with 4 mvme177 68060 processor cards. I have the wrs supplied > bootroms for 5.3 with Tornado 1.01. I boot the first target via ethernet and > the next three targets using the sm network on the backplane. I've been using > this configuration for years going back to bpConnect in 5.02. Here's the > joke: Whenever I have the board with 5.3 bootroms in slot 1, I cannot boot the > other targets through it. When I put a board with 5.2 bootroms in slot 1 I > can load a 5.3 kernel onto it, and boot my other three boards (all with 5.3 > bootroms) through the smConnect. I know another group that uses 167 68040 > cards that had to give up making smConnect work and supply each target with > its own ethernet connection. I have a lot of reasons for not wanting to do > this, not the least of which is that it would be nice to see a function I've > been using for the last 5 years still work. " > > After much back and forthing with WRS tech support here was the fix, just in > case anyone else runs into the same problem. > > In /usr/wind/target/config/mv177/config.h > > #define INCLUDE_MMU_BASIC /* bundled mmu support */ > #undef USER_D_CACHE_MODE > #define USER_D_CACHE_MODE (CACHE_COPYBACK | CACHE_SNOOP_ENABLE) > > was changed to > > #define INCLUDE_MMU_BASIC /* bundled mmu support */ > #undef USER_D_CACHE_MODE > #define USER_D_CACHE_MODE (CACHE_COPYBACK) > > This worked. I went back and checked my older bsps on some other systems, and > found that the line that worked in my other mv177 bsps was: > > #define USER_D_CACHE_MODE (CACHE_WRITETHROUGH | CACHE_SNOOP_ENABLE). > This works also. Arguably I should have caught that sooner, but I made the > ever fatal assumption WRS knew what they were doing when thay made the change. > > I remembered when the 177 first came out there was a problem with BUS snooping > that made it unreliable for a certain stepping of the processor, but that was > in the 1995 time frame with the 50 Mhz parts. These are new boards with 60 > Mhz parts. > > So here's my latest question: How is cache snooping related to bus snooping, > or is it? Or does it depend on how I have the MMU configured with the > sysPhysMem descriptor tables? My Motorola rep is interested in getting an > explanation of what bits are being changed where on the board by this > configuration so that he can pass the info on to one of his FAE's for an exact > explanation ( if one exists). I've forwarded his question to WRS. > > Also, does anyone know where I can dig up some information on how the various > caching combinations work. We had a contractor do some work for us last year > and although he spent a lot if time mumbling about 'dirty caching' I don't > think he ever fixed the problem he was working on. > > Any help/info greatly appreciated. > > Also, thanks to Mitch and Fred for their excellent explanation of how the MMU > works. > > > > Larry D'Alessandro x4-1852 / (781)-594-1852 / DialComm 8*263-1852 Fax (781)-594-4703 e-mail larry.dalessandro@ae.ge.com MZ14008, 1000 Western Ave Lynn MA 01910 From sinnl@sd-star.com Mon Apr 27 09:57:29 1998 From: Larry Sinn Date: Mon Apr 27 09:57:33 PDT 1998 Subject: Re: IntConnect > > Radcliff wrote: > > > > Subject: intConnect > > > > I was told in the Device Drivers class by WindRiver that intConnect was never > > to be called within the driver but rather in the system initialization code, > > which means that you have to actually compile the driver in with the OS and > > download the whole darn thing everytime you add a driver. This is rather > > unsavory, in my opinion. I would rather download a driver that has a static > > method that installs it into the system, including connecting to the > > interrupt. Does anyone really know what the problem with calling intConnect > > within driver code is? I am assuming that the reason is that they > > don't want to have just *anyone* calling intConnect and supplanting > > ISRs from other drivers, but if we are all using the same information > > to develop the drivers we all know which interrupt is take and which is not. > > > > Mike Anderson Responded: > > VxWorks Greetings! > > I beg to differ. If you are writing the device driver, then the > intConnect calls *should* be called in your xxDrv or the xxDevCreate > function (depending on whether you can instantiate multiple devices > with your driver or not). The only concern that you should have is > whether or not the interuppt vectors that you're planning to use > are already occupied. For that, download the "veclist.c" code from the > user's group archives (many thanks to Jeff Hill who wrote it) and > run a "veclist" to see the vectors that are in use. Then just pick > ones that are idle for your device(s). > > Obviously, you should take every effort to make sure that your device > is in a quiesent state prior to attaching the interrupt handler. But, > there have never been any WRS enforced restrictions as to when you can > call intConnect. > > I can only imagine that you must have heard the WRS instructor > incorrectly. I could understand saying that regarding calling > intConnect in an ISR (sort of), but not calling intConnect in a > device driver is insane. You do not have to link your device driver > into the O/S either. Dynamic loading and instantiation of the > device driver/device is perfectly legitimate. > > HTH > When doing an intConnect(), it remembers all intConnects done since the last reboot of VxWorks, and if several intConnets are done on the same vector, when that interrupt occurs, all the routines connected to this vector will be called. So while debugging your code, you load the code containing the intConnect, find some bugs, correct the code, reload that code that contains intConnect, call intConnect again, get an interrupt, you will get 2 calles to your ISR (assuming the changes didn't cause the location of your ISR to change where loaded again, if it did, strange things may happen). The jist of all this is, reboot vxWorks if you reload code containing intConnect(). As a side, we wanted different ISR's to be called from the same vector depending on what was being run on vxWorks (Diagnostic vs. Application code), so I contacted WRS Support to see if they had a hidded intDisConnect() to accomplish this, they don't. The ISR must be made aware of what is being run and call the appropiate code. Larry. Larry Sinn Spectral Dynamics (408)474-1746 voice 1983 Concourse Drive (408)474-1780 fax San Jose, Ca. 95131-1708 sinnl@sd-star.com From sinnl@sd-star.com Mon Apr 27 10:35:35 1998 From: Larry Sinn Date: Mon Apr 27 10:35:39 PDT 1998 Subject: Re: VxWorks BSP for the MVME2304? the vxWorks Users Group Exploder wrote: > > Submitted-by prewitt@ticipa.Works.ti.com Fri Apr 24 13:38:46 1998 > Submitted-by: prewitt@ticipa.Works.ti.com (Jim Prewitt) > James O. Prewitt Wrote: > > I have worked extensively with the MVME2604, > based on the 604. > > I now have a potential application for the > MVME2304, which supposedly uses the > 603. > > Does anyone have any experience in both the > 2604 and 2304 they could share with me? > Motorola changed its number schema for the 2300 series. They are: mvme2301 PPC603 @200MHz 16MB Memory mvme2302 PPC603 @200MHz 32MB Memory mvme2303 PPC603 @200MHz 64MB Memory mvme2304 PPC603 @200MHz 128MB Memory mvme2305 PPC604 @300MHz 16MB Memory mvme2306 PPC604 @300MHz 32MB Memory mvme2307 PPC604 @300MHz 64MB Memory mvme2308 PPC604 @300MHz 128MB Memory We have experience with mvme2604, mvme2301/2 and mvme2305. They all work well and if you don't use the extra stuff on the mvme2604, the same executable you produce will run on all 3 types (2604, 230x with 603 and 230x with 604). You should be using the latest BSP 1.0.1/4 to avoid IACK occuring twice during long ISR's (> 12 usec). This didn't seem to cause any problems but is not a VME standard. Also note Jim Caprio's problems with "/4" (High activity causes board lockup on 2604). Note that WRS produces a BSP for each type (2603, 2604, 230x 603 and 230x 604) and gladly accepts a $1500 donation for each. Larry. Larry Sinn Spectral Dynamics (408)474-1746 voice 1983 Concourse Drive (408)474-1780 fax San Jose, Ca. 95131-1708 sinnl@sd-star.com From mam@pluto.dspt.com Mon Apr 27 10:54:08 1998 From: "Mark Menge" Date: Mon Apr 27 10:54:12 PDT 1998 Subject: GNU copyleft and vxWorks I think I read somewhere that GNU tools are freeware with the copyleft provision. I have run into bugs with the vxWorks gdb I wish I could just fix on the spot. Has anyone ever asked vxWorks for the source code? From froeber@BBN.COM Mon Apr 27 12:42:26 1998 From: Fred Roeber Date: Mon Apr 27 12:42:29 PDT 1998 Subject: Re: Caching and Snooping with MV177/68060 @ 60 Mhz Larry DAlessandro wrote about an MVME177 problem he was having with the shared memory backplane driver due to caching under vxworks: > After much back and forthing with WRS tech support here was the fix, just in > case anyone else runs into the same problem. > > In /usr/wind/target/config/mv177/config.h > > #define INCLUDE_MMU_BASIC /* bundled mmu support */ > #undef USER_D_CACHE_MODE > #define USER_D_CACHE_MODE (CACHE_COPYBACK | CACHE_SNOOP_ENABLE) > > was changed to > > #define INCLUDE_MMU_BASIC /* bundled mmu support */ > #undef USER_D_CACHE_MODE > #define USER_D_CACHE_MODE (CACHE_COPYBACK) > > This worked. > > I went back and checked my older bsps on some other systems, and > found that the line that worked in my other mv177 bsps was: > > #define USER_D_CACHE_MODE (CACHE_WRITETHROUGH | CACHE_SNOOP_ENABLE). > This works also. Arguably I should have caught that sooner, but I made the > ever fatal assumption WRS knew what they were doing when thay made the change. To start, I am not an MVME177 expert and when it comes to cache issues, you have to be an expert in both the particular board and processor you are using to have a chance of coming up with definitive answer when it comes to detailed cache questions. My experience has shown that there are so many variations on the details of how caching is implemented that no two systems work alike. Worse, most every SBC I have worked with has had problems working in all the caching modes it supported. This is an area that is devilishly complex and where HW designers are really starting to make things miserable for us SW developers. Since I have spent more time trying to fix and understand caching problems than most people I know, I will offer some information in the hope it will be of use. First off, most of the details of cache management under VxWorks are handled in the cacheLib module. This module provides a generalized interface (i.e. API) that is meant to be architecture independent. However, the implementation is extremely architecture dependent. It always used to be the case that the cacheLib functionality for the 680X0 family was implemented with a single set of source code for all members of the family. The code had numerous ifdefs to support features specific to individual members. To find out exactly what the cache mode affects on the 68060 on the 177 board, you will probably need to ask WRS directly. I would hope they would provide this information so that this issue can get solved once and for all. While they have some smart engineers, they aren't infallible (nobody is). Worse, my experience has been that they are getting spread thinner as time goes on and some BSPs seem to be becoming less reliable. I was initially quite surprised that the fix you list above to use Copyback caching without snooping works. I'll try to present an explanation of why I think this fix works. First, it would be useful to provide some background. Hopefully people (from Motorola and Wind River) can verify this hypothesis as to why the fix does work for the MVME177 board. There are two main types of write caching; writethrough and copyback. Writethrough causes data written to cached locations to also get written to the external processor bus at the same time. Copyback, causes data written to cached locations to only get written to the external processor bus "when it needs to be". Copyback caching can improve system peformance as compared to writethrough since bus accesses by the processor are reduced in cases where the processor writes to the same location multiple times with nobody else needing to access the data. The determination of when the data in the cache needs to be "copied back" to memory is the tough issue. Normally, some sort of "bus snooping" mechanism is used by the processor to determine when someone else needs the updated data it has cached, at which point it writes it out. The mechanism is called "bus snooping" but in every case I know of in the VME world it would be better referred to as "local bus snooping". You see, snooping is a mechanism where different entities with caches in them (typically processors) monitor bus addresses and then use special control signals when they see cases where their cache contains the information at the address being requested. The details (as always) are more complex but the key issue is that snooping uses special signals to carry out its work. The VME bus doesn't include any snooping support signals so snooping can't work across it (other than with vendor specific add ons using unused VME signals). The thing is there are a number of different snooping protocols with acronyms like ESI, MESI, MOESI... They all use different and incompatible mechanisms. The bottom line is that snooping is restricted to the local bus on each SBC in the system. If multiple boards in a VME system could keep cached copies of the same physical memory area, there is no way that all the copies could be kept in sync even if they did have snooping support because that would require that all the processors that could cache the data be able to see all addresses referring to the data. The processors, however, only see addresses on their local bus. They don't see all address transactions on the VME bus. Thus, they couldn't make decisions required on how to update their cache right. In VxWorks, the single most common case where we deal with multiprocessor access to cached data is with the shared memory backplane driver (and VxMP which piggybacks on the same mechanism). This is a special, more restricted, case of caching. In this case, all the data involved is physically stored in memory on the backplane master board (unless a special memory card is provided and the OFF_BOARD option is used). The backplane master is usually "processor 0". All processors other than processor 0, read and write their data over the VME bus to processor 0 when communicating. These other processors always (should) set it up such that this memory is marked as uncached from their perspective. The issue of how this memory is cached should only apply to processor 0 itself. Because of this architecture and the fact that the backplane memory is not distributed across processors, the snooping and caching issues here are restricted to how processor 0 handles things. All the other processors will do discrete VME transactions to access processor 0 memory any time they need to perform any communication. For things to work right, we only need to guarantee that any VME accesses to the backplane memory area and any processor 0 accesses get consistent versions of the information. If all the hardware worked as it "should" then any caching mode could be used on processor 0 as long as snooping was enabled to make sure that processor 0's cache was kept consistent with the local memory area being used for the data. On many previous Motorola 680x0 boards, things didn't all work as they should due to hardware problems. In particular, the VME interface chip used on most of the boards (e.g. MVME167 and MVME162) didn't handle snooping signals right. Thus, the backplane memory was marked as uncacheable on those boards. To be fair, this was a pretty minor flaw in the Motorola boards which I otherwise consider to be exemplary (most other 680X0 SBCs I have worked with have had to be sent back to cycled back to the vendors to fix design flaws we uncovered that couldn't be worked around). It is my guess that the VME interface chip still doesn't handle caching right on the 177 board. Thus, for things to work, the memory where the backplane data is stored has to be marked as uncached using the MMU. This is where things get a bit tricky. VxWorks provides a cacheDmaAlloc function that is normally used to get memory blocks that are set up in such a way that they can be used properly for shared access. From days when I could check this in the VxWorks source, I know that with the 68040, the cache functions assumed that snooping worked and thus didn't do anything different for the cacheDmaAlloc than for a normal malloc. With those boards, it was up to the user to realize that this was the case and that a cacheDmaAlloc buffer wouldn't really work for shared VME access and therefor do something to fix the buffer themselves. It is my guess that VxWorks is now "smart" enough to know that if snooping isn't enabled but copyback caching is then cacheDmaAlloc has to do something special to get an uncached buffer. When it sees snooping enabled it doesn't do anything special (even though it should when the buffer is going to be shared over VME). This operation needs to be checked by Wind River or someone with source access to get us an answer. There are a few questions this hypothesis raises. If one turns off snooping as WRS suggested then not only is it disabled for data shared over VME but it is also disabled for data shared with the on-card peripherals. This means that this "fix" would make things like ethernet and SCSI run slower. That could hurt some applications. Also, it still isn't clear how the old writethrough caching with snooping would work. While the writethrough mode means that data being written to the cached area but the backplane master would also get immediately stored in memory where the other processors could get it correctly, if the snooping support of the VME interface is broken, then reads by the local processor to data that is cached but has also been updated by other processors wouldn't work. This is a question for Motorola. > I remembered when the 177 first came out there was a problem with BUS snooping > that made it unreliable for a certain stepping of the processor, but that was > in the 1995 time frame with the 50 Mhz parts. These are new boards with 60 > Mhz parts. > > So here's my latest question: How is cache snooping related to bus snooping, > or is it? Or does it depend on how I have the MMU configured with the > sysPhysMem descriptor tables? My Motorola rep is interested in getting an > explanation of what bits are being changed where on the board by this > configuration so that he can pass the info on to one of his FAE's for an exact > explanation ( if one exists). I've forwarded his question to WRS. I'm thinking the the early 177 boards had "processors" with broken bus snooping. The processors got fixed such that they could snoop their local bus correctly. The 177 "boards" still have broken VME interfaces with respect to snooping. > Also, does anyone know where I can dig up some information on how the various > caching combinations work. We had a contractor do some work for us last year > and although he spent a lot if time mumbling about 'dirty caching' I don't > think he ever fixed the problem he was working on. Part of the reason I have been answering these questions in some detail is that there is no good central source for the information as far as I know. I have spent years reading bits here and there to try to gain expertise in the area (plus endless hours chasing problems due to caching bugs). The Motorola processor manuals tend to have a pretty accurate and detailed description of how they handle caching from a "processor perspecitive". Expect the explanations to take a few readings to understand. There is little written on caching issues at the board level. Some of the documentation that came out of the FutureBus development process discussed caching issues pretty well (FutureBus was a military backplane that was supposed to become a follow on to VME bus and was going to cover cache coherency between boards). Many of the workstation and mainframe vendors have cache coherency solutions that work in their proprietary environments. Finally, you can always check out the academic research. I hope that people with VxWorks source access for the 177 and with detailed knowledge of 177 erratta can answer this question once and for all. Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From prewitt@ticipa.Works.ti.com Mon Apr 27 13:15:17 1998 From: prewitt@ticipa.Works.ti.com (Jim Prewitt) Date: Mon Apr 27 13:15:21 PDT 1998 Subject: Re: VxWorks BSP for the MVME2304? Larry, Thanks for your inputs. If our customer winds up selecting this particular board, I will keep you informed of any peculiarities that we encounter. Jim prewitt@works.ti.com 972-927-5771 From Andy_Wacaser@anteonwest.com Mon Apr 27 17:19:01 1998 From: Andy_Wacaser@anteonwest.com Date: Mon Apr 27 17:19:05 PDT 1998 Subject: Job Opportunity In San Diego Looking for a Software/System Engineer to design, implement and test system level diagnostics and executive functions in a real-time embedded system containing a mix of COTS and custom boards. Integrate new VMEbus COTS and custom boards into the existing system and develop the hardware and software diagnostic functions. Need a self-starter that can analyze the existing system and design the appropriate level of diagnostics and implement them. Requires a minimum of 5 years experience, including C, real-time OS familiarity, embedded microprocessors and cross-platform software development in a UNIX environment. ADA a plus. Ideal candidate would have VxWorks/Tornado experience on a 68xxx and Powere PC microprossor in a UNIX development environment. The position is with ANTEON Corp, a premiere engineering services company. Please send email replies, with attachjed (MS Word or ASCII text) or embedded resume to From ng@netstal.ch Tue Apr 28 00:17:14 1998 From: ng@netstal.ch (Niklaus Giger) Date: Tue Apr 28 00:17:17 PDT 1998 Subject: Re: GNU copyleft and vxWorks I've asked WindRiver-Support for the GNU-sources and got an answer like this: > >Each of the Tornado 1.0.1 CD-ROM has the GNU and GDB Sources on them. > >A customer can use the installation key they received for their >Tornado Development system. > >Using SETUP (installation wizard), the customer gets to the screen that >lists out the products licensed, they select the Object file and click on >the DETAILS button. They will see a total of about 6 files: > > >Tornado Object file for their target > >WTX Object files > >Man pages > >GNU Source > >GDB Source > >Unsupported Sources > > >Only the first 3 files are part of the mandatory installation. The last 3 >files are optional so the customer can install it as needed. I hope this answers your question. Regards Niklaus Giger dept. TEI Netstal Maschinen AG CH-8752 Naefels email: ng@netstal.ch FAX: + 41 55 612 42 41 Phone: + 41 55 618 64 68 From blohm@vs.dasa.de Tue Apr 28 00:28:10 1998 From: "Gundula Blohm" Date: Tue Apr 28 00:28:13 PDT 1998 Subject: Re: GNU copyleft and vxWorks On 27 Apr 98 at 10:54, the vxWorks Users Group Explo wrote: > Submitted-by mam@pluto.dspt.com Mon Apr 27 10:54:08 1998 > Submitted-by: "Mark Menge" > > I think I read somewhere that GNU tools are freeware with the copyleft > provision. I have run into bugs with the vxWorks gdb I wish I could just fix > on the spot. Has anyone ever asked vxWorks for the source code? The sourcr code is on your tornado cd, when installing select tornado | details | gnu sources (this is disabled for default) HTH, dula =================================================== Gundula Blohm Tel. +49 (731) 392-4731 Fax +49 (731) 392-4958 mailto:blohm@vs.dasa.de =================================================== From han2326@shinbiro.com Tue Apr 28 03:56:43 1998 From: "Han, Jeong Soo" Date: Tue Apr 28 03:56:46 PDT 1998 Subject: hdlc driver question on mc68360 vxWorks Hello, During a coding & testing of HDLC driver s/w(RS-485) on mc68360(vxWorks), I got abort error and crc error about 0.5% error rate in receive buffer descriptor. (point to point connection, 38.4kbps, NRZI) Is it common error rate in RS-485 HDLC? Does anyone know how to fix above error to 0 % error rate. Any comments will be appreciated. Thanks. -- ========================================================================== JEONG-SOO HAN E-MAIL: han2326@shinbiro.com Assist. Research Engineer/EECR Dept. TEL : 82 - 331 - 288 - 3521 HYUNDAI PRECISION & IND. CO., LTD. FAX : 82 - 331 - 284 - 0341 80-9,MA BOOK-RI,KUSEONG-MYUN,YONG IN-SHI, KYUNG GI-DO, KOREA(449-910) From daemon@csg.lbl.gov Tue Apr 28 04:04:33 1998 From: daemon@csg.lbl.gov Date: Tue Apr 28 04:04:36 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Apr 28 04:04:31 PDT 1998 Subject: Re: VxWorks BSP for the MVME2304? Subject: SBus DVMA on SPARC Subject: Porting Apache Web Server to VxWorks.. Subject: Re: Looking for a cross compiler ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VxWorks BSP for the MVME2304? Date: 27 Apr 1998 07:05:44 +0100 From: Michael Carr Organization: UltraNet Communications, Inc. http://www.ultranet.com/ Message-ID: References: <199804242038.PAA02720@gonzo.works.ti.com> prewitt@ticipa.Works.ti.com (Jim Prewitt) writes: > Subj: VxWorks BSP for the MVME2304? > > > > I have worked extensively with the MVME2604, > based on the 604. > > I now have a potential application for the > MVME2304, which supposedly uses the > 603. > > Does anyone have any experience in both the > 2604 and 2304 they could share with me? I've done an analogous transition: mv2603 to mv2302. I tweaked the 2603 BSP to work with the 2302 by changing the BOARD macro to MVME2300, changing an EXTRA_DEFINE from -DMV2600 to -DMV2300, and stripping out some things in configdb.h (like aux clock, scsi2, etc.). Works like a champ. - -- - ----------------------------------------------------------- Michael Carr Redstone Communications *** Remove 'NOSPAM' from my email address when replying *** --------------------------- Newsgroups: comp.os.vxworks Subject: SBus DVMA on SPARC Date: 27 Apr 1998 18:16:10 GMT From: "James Wills" Organization: Raytheon Systems Company, Falls Church Message-ID: <01bd7209$555be5c0$10a6cfc0@JWills-PC> Looking to implement DMA to an SBus card on a Force CPU-5VT SPARC card. The Force BSP doesn't support SBus at all. So, there's on DVMA sysLib support. (They do support DMA to the VMEbus). At the very least, I'm trying to locate programming information on the microSPARC CPU that is on the board so that I could write my own support lib. Can anyone help? Thanks. - -- James Wills Raytheon Systems 7700 Arlington Blvd Falls Church VA 22042-2900 --------------------------- Newsgroups: comp.os.vxworks Subject: Porting Apache Web Server to VxWorks.. Date: Mon, 27 Apr 1998 23:50:40 -0700 From: Ed Costello Organization: Million Monkeys Message-ID: <35457C40.59012716@million-monkeys.com> I just downloaded Apache V1.2.6 and am about to start porting it to VxWorks. Does anyone know if this has already been successfully done? If so, can I get a pointer to those that know about such things in order to avoid pitfalls/gotchas that I will certainly otherwise encounter? Thanks in advance - --- Ed Costello costello@million-monkeys.com costello@hyperspectral.com --------------------------- Newsgroups: comp.os.vxworks,comp.lang.ada Subject: Re: Looking for a cross compiler Date: Tue, 28 Apr 1998 08:16:04 GMT From: mark.bennison@gecm.com (Mark Bennison) Organization: GEC Marconi Radar & Defence Systems Message-ID: <35458e85.54734824@news.geccs.gecm.com> References: <3544828B.1381@ipnsun5.in2p3.fr> Xavier Grave thought long and hard and wrote: >Hello, > >I'm starting to work on vxWorks and I'm looking for a cross compliler >from Sun 5.6 or Dec Osf3.2 to a power pc 603 under vxworks. Do I have >to built it myself with the cross compiler given with the tornado >distribution ? Well, both Rational, GNAT (soon!), Aonix and Greenhills produce an Ada 95 compiler that is targetted to the PowerPC 603 (we're using Rational's) and run under Solaris (Dec stuff I can't comment on). I would suspect you need to contact them with your requirements. Cheers, Mark. - -- Mark Bennison MBCS, +-----------------------------------+ Technical Consultant, | All opinions expressed are my own | EASAMS Software Systems. +-----------------------------------+ "Death is a fickle hen, and random are her eggs" - Armando Iannucci --------------------------- End of New-News digest ********************** From ste@ply.wg.com Tue Apr 28 06:16:26 1998 From: Steve James Date: Tue Apr 28 06:16:30 PDT 1998 Subject: Anyone know if Make in Tornado 1.0.1 is Y2K OK? This is a multi-part message in MIME format. --------------6A1AE9FC53D4F3275C46F487 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --------------6A1AE9FC53D4F3275C46F487 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve James Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Steve James n: James;Steve org: Wandel & Goltermann Ltd., Plymouth email;internet: ste@ply.wg.com title: Senior Design Engineer x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------6A1AE9FC53D4F3275C46F487-- From cruz_nojunk@xyplex.com Tue Apr 28 07:16:33 1998 From: Roger Cruz Date: Tue Apr 28 07:16:36 PDT 1998 Subject: Re: GNU copyleft and vxWorks The source code for GDB is included in the distribution. Unfortunately, it does not build. It requires some files and environment setup from WRS which we couldn't obtain. Good luck. We just obtained the latest release of GDB from GNU and use it without the window interface. --------- I think I read somewhere that GNU tools are freeware with the copyleft provision. I have run into bugs with the vxWorks gdb I wish I could just fix on the spot. Has anyone ever asked vxWorks for the source code? PS: Remove "_nojunk" from email address" -- Roger Cruz cruz_nojunk@xyplex.com Xyplex Networks w: 978-952-4783 295 Foster Street f: 978-952-4887 Littleton, MA 01460 From froeber@BBN.COM Tue Apr 28 08:52:25 1998 From: Fred Roeber Date: Tue Apr 28 08:52:28 PDT 1998 Subject: Re: IntConnect Larry Sinns provided additional information to some advice Mike Anderson had given on using intConnect: > When doing an intConnect(), it remembers all intConnects done since the > last reboot of VxWorks, and if several intConnets are done on the same > vector, when that interrupt occurs, all the routines connected to this > vector will be called. Boy, I learn something new every day. Todays lesson was that the interrupt model VxWorks uses isn't consistent from one architecture to another. Larry's statement above is NOT true for 680X0 processors. With those, intConnect replaces any existing interrupt routine at the vector specified with the new routine. It is up to the programmer to make sure that there isn't an important interrupt handler already using that vector. It sounds like the interrupt connection support for Larry's architecture (I think it was PowerPC) is very different. I guess it's just another example of the fact that the details on what system you are using matter and any advice has to be qualified with respect to the particulars of what systems it applies to. Fred | Fred J Roeber, BBN Systems & Technologies | | 4 John Clarke Road Middletown, RI 02842-5202 | | froeber@bbn.com 401-848-3548 | From tkb@mclean.sparta.com Tue Apr 28 10:05:55 1998 From: Keith Buchanan Date: Tue Apr 28 10:05:59 PDT 1998 Subject: Re: IntConnect the vxWorks Users Group Exploder wrote: > > Submitted-by froeber@BBN.COM Tue Apr 28 08:52:25 1998 > > When doing an intConnect(), it remembers all intConnects done since the > > last reboot of VxWorks, and if several intConnets are done on the same > > vector, when that interrupt occurs, all the routines connected to this > > vector will be called. > > Boy, I learn something new every day. Todays lesson was that the interrupt > model VxWorks uses isn't consistent from one architecture to another. > Larry's statement above is NOT true for 680X0 processors. With > those, intConnect replaces any existing interrupt routine at the vector > specified with the new routine. It is up to the programmer to make sure > that there isn't an important interrupt handler already using that vector. The "chaining" of interrupts by WRS follows the convention of the processor involved. The 68k processes vectored interrupts in hardware. WRS fakes the vectored interrupts in families that do not support them such as i86 and SPARC. In these families, chaining ISRs is a normal (albeit inferior) practice. adios From adamakis@nosc.mil Tue Apr 28 11:04:27 1998 From: Mike Adamakis Date: Tue Apr 28 11:04:30 PDT 1998 Subject: Re: GNU copyleft and vxWorks At 10:54 AM 4/27/98 PDT, you wrote: >Submitted-by mam@pluto.dspt.com Mon Apr 27 10:54:08 1998 >Submitted-by: "Mark Menge" > >I think I read somewhere that GNU tools are freeware with the copyleft >provision. I have run into bugs with the vxWorks gdb I wish I could just fix >on the spot. Has anyone ever asked vxWorks for the source code? > If you are using NT, there is a problem installing the GNU source from the Tornado disk. I don't know if this has been fixed yet. > TSR #: 70712 > 12/11/97 > > Hello Mike, > > The problem that you are experiencing is a known problem and has been > assigned an spr. Here is a summary of spr # 8900. > > *************** > * SPR #8900 * > *************** > > Synopsis: Setup fails when trying to install the GNU > source component. > =============================== TRANSACTION > =============================== > Jul 9 1997 11:59AM pingl > Setup fails when trying to install the GNU source > component. > =============================== TRANSACTION > =============================== > Jul 9 1997 12:03PM pingl > According to Peter, the problem happens when the setup program is trying > to copy a file, host/src/gnu/include/coff/aux.h to the host. It appears > that WindowsNT treats "aux.h" as some sort of device and tries to open it > as a device instead of a file and generates strange error. The error > message is "No disk space left. To continue, free up some disk space.". > The user has to select "cancel" to exit the setup program. > > Workaround: > Do not install GNU source. This can be done by click on the check box > for the item "GNU source" from the secondary setup window. > The user has to highlight the item "Tornado object > x and then > lick on the "details" button on the primary setup window to get into the > secondary setup window which lists the item "GNU source" among with > several other items. > > One interesting note, the problem is reproducable on host with hard drive which > is bigger than 2GB. For NT host with smaller hard drive, the file is ignored > but there is no error message generated. Tested TorxPPC, i960, 68k FCS CD. > Host has service pack 3 installed, equipped with a 4GB drive. > > > =============================== TRANSACTION > =============================== > Jul 10 1997 5:10PM pingl > Customer reported that the problem is reproducable on host with hard drive > smaller that 2gb. It seems that drive size is not a factor at all. > > -------------------------------------- EOF > ---------------------------------- > > Call back if you have anymore questions. > > Thank you very much, > > vinh > > ------------------------------- > Vinh Du > WRS Technical Support Engineer > vinh.du@wrs.com > cc:tsrlog@wrs.com > 1(800)-USA-4WRS > ------------------------------- --- Mike Adamakis Koam Engineering Systems 913 Catalina Blvd. San Diego, CA 92106 (619) 224-1736 (office) (619) 224-9795 (fax) adamakis@nosc.mil From getker@sentientnet.com Tue Apr 28 12:34:58 1998 From: Jim Getker Date: Tue Apr 28 12:35:05 PDT 1998 Subject: Power PC Eval Board Hi, We are starting a development effort using the 300Mhz Power PC 603e on a custom board running VxWorks. We would like to buy some evaluation boards to base our CPU core design on, and to start some performance benchmarks. Does anyone have a suggested vendor? The criteria are: 1) 300Mhz 603e 2) MPC 106 memory controller/PCI bridge, 66Mhz 64-bit system bus 3) Up to 256Mb of SDRAM, with access to the SDRAM from the PCI bus 4) Up to 1MB of level 2 cache 5) At least two PCI or PMC slots 6) >8MB of flash 7) 100 base T Ethernet 8) Time of day chip with BBRAM 9) Off the shelf VxWorks BSP This could be a VME based board, or a stand-alone mother board. If possible, we would like to get schematics. Thanks, Jim getker@sentientnet.com From clare@bis.kodak.COM Tue Apr 28 14:24:53 1998 From: clare@kodak.com (Bill Clare) Date: Tue Apr 28 14:25:00 PDT 1998 Subject: CheckDisk support within VxWorks 5.3.1 I have need of a program which provides the functionality of a DOS CheckDisk utility. Is anyone familiar with a such a utility for VxWorks? I'm running 5.3.1 on a Pentium platform. Thanks for any help you can provide with this problem. Bill Clare, Software Engineer, Eastman Kodak Company Email: clare@kodak.com Mail code: 2/5/EP 35426 Phone: (726)726-9419 US Mail: 901 Elmgrove Road Rochester NY 14653-5426 Fax: (716)726-0129 Any opinions expressed herein are mine and not those of Eastman Kodak Company. From rls@ti.l-3com.com Tue Apr 28 14:26:52 1998 From: Randy Silagi Date: Tue Apr 28 14:26:56 PDT 1998 Subject: Re: IntConnect the vxWorks Users Group Exploder wrote: > Submitted-by tkb@mclean.sparta.com Tue Apr 28 10:05:55 1998 > Submitted-by: Keith Buchanan > > the vxWorks Users Group Exploder wrote: > > > > Submitted-by froeber@BBN.COM Tue Apr 28 08:52:25 1998 > > > > When doing an intConnect(), it remembers all intConnects done since the > > > last reboot of VxWorks, and if several intConnets are done on the same > [snip] > The "chaining" of interrupts by WRS follows the convention of the > processor > involved. The 68k processes vectored interrupts in hardware. WRS fakes > the > vectored interrupts in families that do not support them such as i86 and > SPARC. In these families, chaining ISRs is a normal (albeit inferior) > practice. > > adios Something else to remeber about intConnect() on 68K's is that it has a memory leak. It you are calling intConnect() multiple times, for the same vector, you will lose 32 - 44 bytes each time. I don't remeber the exact number of bytes lost, but it is small. This was not an issue in 5.1, and 5.2. This memory leak is new for 5.3. -- +------------------------------------------------------------------+ | Randy Silagi E-Mail: rls@ti.L-3com.com | L3 Communications Phone: 619-674-5100, X4798 | Telemetry & Instrumentation Fax: 619-674-5145 | 15378 Avenue of Science http://www.ti.L-3com.com | San Diego, CA 92128-3407 +-------------------------------------------------------------------+ From DAVID.T.BENNETT@cpmx.saic.com Tue Apr 28 15:17:27 1998 From: "Bennett, David T." Date: Tue Apr 28 15:17:31 PDT 1998 Subject: RE: Job Opportunity In San Diego Thanks, See, You tonight?? Thanks -David Bennett Campus Point Backup Services CP G-2404 Email: david.t.bennett@cpmx.saic.com Web page: http://issaic.saic.com/computer/its/desktop/backup/ -----Original Message----- From: vxwexplo@lbl.gov [SMTP:vxwexplo@lbl.gov] Sent: Monday, April 27, 1998 5:19 PM To: vxworks_users@csg.lbl.gov Subject: Job Opportunity In San Diego Check out www.anteon.com and follow the CA employment page. I saw some PC Network Specialists job postings in Mission Valley. Might be worth looking into if you don't mind the commute. Carpool????? I got your resume and will keep my eyes open. Take care! GQ ____________________Forward Header_____________________ Subject: Job Opportunity In San Diego Author: vxwexplo@lbl.gov Date: 4/27/98 5:19 PM Submitted-by Andy_Wacaser@anteonwest.com Mon Apr 27 17:19:01 1998 Submitted-by: Andy_Wacaser@anteonwest.com Looking for a Software/System Engineer to design, implement and test system level diagnostics and executive functions in a real-time embedded system containing a mix of COTS and custom boards. Integrate new VMEbus COTS and custom boards into the existing system and develop the hardware and software diagnostic functions. Need a self-starter that can analyze the existing system and design the appropriate level of diagnostics and implement them. Requires a minimum of 5 years experience, including C, real-time OS familiarity, embedded microprocessors and cross-platform software development in a UNIX environment. ADA a plus. Ideal candidate would have VxWorks/Tornado experience on a 68xxx and Powere PC microprossor in a UNIX development environment. The position is with ANTEON Corp, a premiere engineering services company. Please send email replies, with attachjed (MS Word or ASCII text) or embedded resume to From ste@ply.wg.com Wed Apr 29 01:42:49 1998 From: Steve James Date: Wed Apr 29 01:42:53 PDT 1998 Subject: Re: Exchange Timeout Error in Tornado Shell This is a multi-part message in MIME format. --------------58F07B29E534540B2EB402C0 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit the vxWorks Users Group Exploder wrote: > Is there a way to change/increase the time-out value when loading an > object from > the Tornado Shell? We are experiencing Exchange Time-outs when we > load the > object (which is about 8 meg). We consistently experience this problem too (i86 target, PC host). We haven't got a fix but on the bright side, the load seems to succeed all the same -- it just looks like it hasn't! My theory is that the target server is periodically pinging the target but the data link is so full of data that the ping fails and you get the warning message. -- --Steve James, Senior Design Eng.--............................ --Wandel & Goltermann Ltd........--.+44 (0)1752 765367 (vmail). --Eurotech House, Burrington Way.--.+44 (0)1752 791101 (FAX)... --Plymouth, Devon. PL5 3LZ. U.K..--.+44 (0)1752 772773 (switcb) --------------58F07B29E534540B2EB402C0 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Steve James Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Steve James n: James;Steve org: Wandel & Goltermann Ltd., Plymouth email;internet: ste@ply.wg.com title: Senior Design Engineer x-mozilla-cpt: ;0 x-mozilla-html: TRUE end: vcard --------------58F07B29E534540B2EB402C0-- From daemon@csg.lbl.gov Wed Apr 29 04:00:34 1998 From: daemon@csg.lbl.gov Date: Wed Apr 29 04:00:38 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Apr 29 04:00:32 PDT 1998 Subject: logLib.c ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: logLib.c Date: Tue, 28 Apr 1998 17:40:20 -0400 From: "James A. Littlefield" Organization: The Internet Access Company, Inc. Message-ID: <35464CC4.C5CCF82@alum.mit.edu> I would like to customize the way the logMsg() task works. Can anyone provide a location for this source code or a public domain replacement with similar capabilities. Thanks Jim Littlefield --------------------------- End of New-News digest ********************** From era@escher.gti.ssr.upm.es Wed Apr 29 07:29:59 1998 From: era@escher.gti.ssr.upm.es (Enrique Rendon Angulo) Date: Wed Apr 29 07:30:15 PDT 1998 Subject: Re: Exchange Timeout Error in Tornado Shell In a Unix host there is way to increase this timeout and the size of memory used for interchange (??) by the protocol, here you have a typical call in our system: tgtsvr ra -C -V -n ra -Bt 40 -m 2500000 this call to launch a target server establishes a timeout of 40 seconds and a size of 2.5Mbytes. We needed these changes to be able to load a huge code file (8Mbytes). I hope that helps, Enrique Rendon ______________________________________________________________________ _________________ / __________ ___ / / Grupo de Tratamiento de Imágenes / / ____ / / ETS. Ingenieros de Telecomunicación / / __ / / / / / Universidad Politécnica de Madrid / /____/ / / / / / 28040 Madrid - SPAIN /______ / / / / / tel: +34.1.336.7353 / / fax: +34.1.336.7350 or 34.1.5439652 Enrique Rendón-Angulo mailto:era@gti.upm.es http://www.gti.ssr.upm.es/~era/ ______________________________________________________________________ From john.l.ahrens@boeing.com Wed Apr 29 09:47:17 1998 From: "John. L. Ahrens" Date: Wed Apr 29 09:47:21 PDT 1998 Subject: VxWorks: Have to restart ULIP to restart VxSim Every time I kill my VxSim session I have to restart ULIP on my Sparc/Solaris machine or I get the following error: Target Name: vxTarget Attaching network interface ul0... ulipInit failed, errno = 0x0 Bind failed VxWorks Copyright 1984-1996 Wind River Systems, Inc. CPU: SunOS 5.5.1 [sun4u] VxWorks: 5.3.1 BSP version: 1.0/1 Creation date: Apr 28 1998 WDB: Ready. If I run /etc/init.d/ulip start (as root) and restart vxsim0 from the VxSim button on the launcher, everything is okay. Any suggestions? -- I don't speak for my employer. | You can't have an impact Test Systems Research & Development | without expecting a collision. john.l.ahrens@boeing.com | From greg.brissey@nmr.varian.com Wed Apr 29 09:49:26 1998 From: greg.brissey@nmr.varian.com (Greg Brissey x6951) Date: Wed Apr 29 09:49:29 PDT 1998 Subject: Re: logLib.c vxworks Jim writes, > > Newsgroups: comp.os.vxworks > Subject: logLib.c > Date: Tue, 28 Apr 1998 17:40:20 -0400 > From: "James A. Littlefield" > Organization: The Internet Access Company, Inc. > Message-ID: <35464CC4.C5CCF82@alum.mit.edu> > > I would like to customize the way the logMsg() task works. Can anyone > provide a location for this source code or a public domain replacement > with similar capabilities. > > Thanks > Jim Littlefield I don't have the source for logLib.c but I created my own logging task with a set of logging functions that I use. You can also use this task to connect to the syslogd port of a Unix host to log messages directly on the Unix host. If you would to see how I accomplished this I be glad to send you some example code. There is the discription of the library I built /* DESCRIPTION This library contain the message logging facility. The usage of this facility is to prevent the typical "out of sequence" messages and task blocking due to the printing and preemptive scheduling interaction. This interaction typically results in tasks blocking that would of normally not done so. Resulting in erroneous diagnostic output and intertask behavior. Three classes of Messages 1. Informational Application Specific (i.e. I am doing this now, etc. ) 2. Diagnostic Messages for debugging, application specific 3. Errors: A. Application Errors B. System Call Errors Class 1. maybe be just printf(s) or they maybe wish to be logged Class 2. Present for debugging but gone in non-debugging version, are just fprintf(s). Clase 3. A. Should be logged B. Most Definitely should be logged. This Library provides facilities for Class 2 & 3 messages. Debugging messages use the DPRINT style macros to allow conditional compiling of print statment and also provides a level of verbosity in debug printing. Logging is provided via the Boot Hosts syslogd UNIX facility. The Error routines may log or not log based on calls to sysLogEnable() or sysLogDisable(). The messages are printed on console's stderr. Log messages are log and printed according the /etc/syslog.conf file and the syslog facility parameter. The vxWorks Target should be consider to be LOG_LOCAL7: For LOG_LOCAL7 modify /etc/syslog.conf to include local7.err;local7.info;local7.emerg;local7.debug /var/log/console local7.err;local7.info;local7.emerg;local7.debug /dev/console This tells syslogd to write your messages to the console as well as the logfile /var/log/vnmr. After modifing syslog.conf execute a "kill -HUP syslog's pid" (found in /etc/syslog.pid) This will result in syslogd reading the modified syslog.conf file. Note: if the logMsg() facility does not use a large enough queue, since if (i.e. messages are being lost. ). Then it's MessageQ size can be increased in usrConfig.c in vw/config/all . Usage: DPRINT(level,"This is a test, No args....\n"); DPRINT1(level,"This is a test, 1 args..%d..\n",val); DPRINT2(level,"This is a test, 2 args..%d.%s.\n",val,str); DPRINT3(level,"This is a test, 3 args..%d.%s.%d\n",val,str,val); ...... DPRINT5(level,........) or diagPrint(debugInfo, format_string, arg1, arg2, ....) Note: debugInfo expands to fileNline(__FILE__,__LINE__) if DEBUG is defined, otherwise it is NULL. OutPut: 0x326c58 (tRdbRun): 10:07:20 'tstlog.c' line: 57, This is a test, No args.... 0x326c58 (tRdbRun): 10:07:29 'tstlog.c' line: 58, This is a test, 1 args..1.. 0x326c58 (tRdbRun): 10:07:51 'tstlog.c' line: 59, This is a test, 2 args..1.2. 0x326c58 (tRdbRun): 10:08:47 'tstlog.c' line: 61, This is a test, 3 args..1.2.1 (the filename and line number are outputted only if DEBUG was defined during compilation) if (msgQDelete(1L) == ERROR) { errLogSysRet(LOGIT,debugInfo,"Oh OOOhh: "); } OutPut: Console's stdout 0x326c58 (tRdbRun): 10:09:13 'tstlog.c' line: 65, Oh OOOhh: S_smObjLib_NO_OBJECT_DESTROY Boot Hosts Console window via syslogd Jul 29 10:09:55 mv162 0x326c58 (tRdbRun): 10:09:55: 'tstlog.c' line: 70, Oh OOOhh: S_smObjLib_NO_OBJECT_DESTROY */ Note: My syslog examples are based on SunOS 4.1.3 thought I doubt if this facility has changed much for Solaris 2.X Greg Brissey greg.brissey@nmr.varian.com From sinnl@sd-star.com Wed Apr 29 11:21:45 1998 From: Larry Sinn Date: Wed Apr 29 11:21:49 PDT 1998 Subject: Re: MVME 2604, vxWorks and not booting the vxWorks Users Group Exploder wrote: > > Submitted-by John_W_Cosgrove@res.raytheon.com Wed Apr 8 11:48:43 1998 > Submitted-by: John_W_Cosgrove@res.raytheon.com > > Hi, Folks, > > Are there any known problems with the MVME 2604-2141 that would cause it > not to boot after Loading vxWorks over the ethernet. The problem is not a > hard failure but occurrs on all three systems I have setup with a varing > degree of repeatitivity. One systems boots 99.9% of the time, one boots > about 85% and the other about 66% on the time. This is annoying when you > are ready to try and sell off a mission critical system that may or may not > boot. > > The error manifests itself as either a dead stop after the vxWorks > "Starting at 0x100000" or a tRoot task program exception (located in strcpy > of vxWorks). This occurs after a "SYSRESET assertion" reset. No user code > has been executed at this point, only vxWorks startup code. > > My configuration is: > MVME 2604-2141 > VxWorks 5.3.1 & vxWorks BSP 1.1/4 w/EXTENDED_VME enabled > booting over the ethernet from an HP Computer using tftp > The two systems with the worst record are on private (just the HP and 2604) > lans. > > If anyone knows of any problems/fixes, I would greatly appreciate the > description (and solution, if avaiable). > > John Cosgrove > Raytheon > (401)842-4167 (desk) > (401)842-3511 (lab) > jwc_NOSPAM@ssd.ray.com > John: We have a MVME 2604-1141 that behaves similarly to yours. But we also have Motorola 2301 (603e 200MHz), 2302 (603e 200MHz) and 2305 (604r 300MHz) that work flawlessly as far as reboot is concerned. We are using SUN with BSP 1.1/4 no Extended VME. Larry. Larry Sinn Spectral Dynamics (408)474-1746 voice 1983 Concourse Drive (408)474-1780 fax San Jose, Ca. 95131-1708 sinnl@sd-star.com From daemon@csg.lbl.gov Thu Apr 30 04:04:10 1998 From: daemon@csg.lbl.gov Date: Thu Apr 30 04:04:14 PDT 1998 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Apr 30 04:04:08 PDT 1998 Subject: profiling available? Subject: Re: Asm microsoft tu gnu Subject: Re: Target Shell problems... ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: profiling available? Date: Wed, 29 Apr 1998 09:13:16 -0600 From: cotto@ro.com Organization: Deja News - The Leader in Internet Discussion Message-ID: <6i7chs$i7j$1@nnrp1.dejanews.com> Hi everyone, I am developing a real time application and looking for areas to cut time lost. It would be nice to determine where the program spends its time during execution and thought that VXWorks or the gnu debugger might provide some means to accomplish this. If anyone can help, I would appreciate it. I am using a BSP for the MVME2307. Chris Otto - -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/ Now offering spam-free web-based newsreading --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Asm microsoft tu gnu Date: Thu, 30 Apr 1998 09:08:34 +0200 From: Jean-Yves Thiriet Organization: CNET France Telecom Message-ID: <35482372.681456@cnet.francetelecom.fr> References: <35475823.E4B95076@cnet.francetelecom.fr> <354772dd.0@d2o201.telia.com> Because I think MASM doesn't create code for VxWorks. (The .o is not compatible, isn'it). arve sollie a icrit: > Why not assemble it with MASM ? > > Jean-Yves Thiriet wrote in message > <35475823.E4B95076@cnet.francetelecom.fr>... > >For our drivers, we only dispose of the source in microsoft asm, and of > >the .obj for QuickBasic or Visual C. > >What is the best solution (most quickly) to obtain a driver for VxWorks > >? > >Thanks. > > > > --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Target Shell problems... Date: Thu, 30 Apr 1998 10:31:56 +0200 From: grave Organization: I.P.N Orsay Message-ID: <354836FC.75FC@ipnsun5.in2p3.fr> References: <3547419C.A7E747B4@ti.com> Excuse me but i forgotten to explain that i worked on a mv2301 board. Depending on your board, the commenting of #DEFINE INCLUDE_SPY isn't necessary. It depends of the version. xavier grave --------------------------- End of New-News digest ********************** From frederic.rosin@matra-com.fr Thu Apr 30 06:00:33 1998 From: "Rosin, Frederic" Date: Thu Apr 30 06:00:39 PDT 1998 Subject: RE: VxWorks: Have to restart ULIP to restart VxSim This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------ =_NextPart_000_01BD7441.4C2B2280 Content-Type: text/plain Hello , If you hit Ctrl-\ in vxsim0 window, you will kill vxsim0 and close ulip properly. Then you should be able to re-run vxsim0. Good luck. ------ =_NextPart_000_01BD7441.4C2B2280 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhkOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAAzgcEAB4ADgABAB0ABAAnAQEggAMADgAAAM4HBAAe AA8ABwAXAAQAKAEBCYABACEAAABFRDFCRjE3OTFGRTBEMTExQUE2RDA4MDAyQjkwMDYzMQARBwEE gAEAMwAAAFJFOiBWeFdvcmtzOiBIYXZlIHRvIHJlc3RhcnQgVUxJUCB0byByZXN0YXJ0IFZ4U2lt AHQRAQ2ABAACAAAAAgACAAEDkAYAJAUAACUAAABAADkAgJoNFzh0vQEDADYAAAAAAAMAJgAAAAAA HgBwAAEAAAAvAAAAVnhXb3JrczogSGF2ZSB0byByZXN0YXJ0IFVMSVAgdG8gcmVzdGFydCBWeFNp bQAAAgFxAAEAAAAbAAAAAb1zs7rBWvLf/d91EdGDzQCAX9QusAAg35cyAAMALgAAAAAAAgEJEAEA AAAQAQAADAEAALUBAABMWkZ1uFYZzP8ACgEPAhUCpAPkBesCgwBQEwNUAgBjaArAc2V07jIGAAbD AoMyA8YHEwKDEjMTD2Y0D3poZWzRAyBEbGcCgzUDxQIACHBycRIic3Rlbf0CgH0KgAjPCdkCgAqB DbGBC2BuZzEwMzYK+xMS8gHQIEgWMW8gLEMKhQqFSWYgeQhgIARoaQVAQ3RybC2IXFwgC4AgdngA kAZtHHAD8G5kb3csdx4DA/AWQWsggh9FAHBkjCBjGNAR8CB1bAUgEiAXkG9wBJBseS6cIFQWIAOg HhJzaAhgWmwhoGIiAAGgbCIAdKMc0BlALXJ1HyYuHQyUR28EcCAKQGNrJZ0FGGEAKEADAPE/DAQA AB4AMUABAAAAKwAAAC9PPU1BVFJBQ09NL09VPVBNUi9DTj1SRUNJUElFTlRTL0NOPVJPU0lORgAA AwAaQAAAAAAeADBAAQAAACsAAAAvTz1NQVRSQUNPTS9PVT1QTVIvQ049UkVDSVBJRU5UUy9DTj1S T1NJTkYAAAMAGUAAAAAAAxAcgGII+yv1Ps4RsKoAqgA8c8YAAAAACAAAAAEAAAABAAAACwAXDAAA AAALAAYMAAAAAAsAAgwAAAAACwAFAAAAAAALADUAAAAAAAIBRwABAAAANAAAAGM9RlI7YT1BVExB UztwPU1BVFJBQ09NO2w9UFJJT1JJUzEtOTgwNDMwMTMwMTI5Wi05OABAAEgAgJoNFzh0vQECAfk/ AQAAAEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUFUUkFDT00vT1U9UE1SL0NO PVJFQ0lQSUVOVFMvQ049Uk9TSU5GAAAeAPg/AQAAABAAAABSb3NpbiwgRnJlZGVyaWMAHgA4QAEA AAArAAAAL089TUFUUkFDT00vT1U9UE1SL0NOPVJFQ0lQSUVOVFMvQ049Uk9TSU5GAAACAfs/AQAA AEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUFUUkFDT00vT1U9UE1SL0NOPVJF Q0lQSUVOVFMvQ049Uk9TSU5GAAAeAPo/AQAAABAAAABSb3NpbiwgRnJlZGVyaWMAHgA5QAEAAAAr AAAAL089TUFUUkFDT00vT1U9UE1SL0NOPVJFQ0lQSUVOVFMvQ049Uk9TSU5GAABAAAcwkPwHTEF0 vQFAAAgwgCIrTEF0vQEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAALwAAAFZ4V29ya3M6IEhh dmUgdG8gcmVzdGFydCBVTElQIHRvIHJlc3RhcnQgVnhTaW0AAAsAKQAAAAAACwAjAAAAAAADAAYQ peCrdwMABxBwAAAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAAZQAAAEhFTExPLElGWU9VSElUQ1RS TC1JTlZYU0lNMFdJTkRPVyxZT1VXSUxMS0lMTFZYU0lNMEFORENMT1NFVUxJUFBST1BFUkxZVEhF TllPVVNIT1VMREJFQUJMRVRPUkUtUlVOVlgAAAAAgzI= ------ =_NextPart_000_01BD7441.4C2B2280-- From abbottd@jlab.org Thu Apr 30 06:26:55 1998 From: David Abbott Date: Thu Apr 30 06:26:59 PDT 1998 Subject: Full Duplex on the MVME230X/MVME260X Hello vxWorks Folks, Thanks to all that replied to my posting concerning running the Motorola MVME230X/MVME260X network interface in Full-duplex mode. Some users expressed an interest in the results of my findings so I will give an update if what I have learned so far. Our problem was that the currently supported (1.1/4 BSP) dec21140 driver did not seem to negotiate the duplex properly when connected to our Cisco Catalyst 5000 switches. We had to force the Switch to 100Bit half-duplex for the MVME2306 boards work (They would boot with the switch in FD mode but the network performance was like molasses). Ideally one would like the Switch and the MV2300 to negotiate the best compatible connection. I at least wanted to be able to manually switch at boot time the duplex on the 2300 to match the switch (I do not need users logging in to my switches). The fix is that there is a new beta driver supported by Motorola but not Wind River that supports full-duplex mode. But more importantly it auto-negotiates both the speed and the duplex correctly. The MCG driver is now called dec21x4x.obj since the addition of dec21143 chip support. One can get the driver from their Mototrola SE or from me if you are interested. Below is the attached README with the new driver. I have initially tested this driver on a MVME2306 board connected to a Cisco 5000 series switch. The driver correctly negotiated both a full and half duplex connection with a fixed switch port, and for the case where the switch was "auto-configuring" it correctly configured to 100BT/FD. The perfomance of the driver in both modes seems roughly the same and is also about the same as the 1.1/4 BSP dec21140 driver (This is only a qualitative assesment). Dave David Abbott Jefferson Lab Data Acquisition Group EMAIL: abbottd@jlab.org Tel: (757) 269-7190 FAX: (757) 269-5800 --------------------------------------------------------------------- DEC21x4x Patch, 4/22/98 There is a new DEC21x4x driver for the PowerPlus Architecture family. This driver includes support for the dec21040, dec21140, and dec21143 chips as well as fixes a problem with the driver's cache usage. This driver still has the 100BaseT performance increases in BOTH directions, supports Full Duplex and includes additional enhancements. 1.This new driver requires the Makefile to be changed. All references to dec21140 MUST be changed to dec21x4x. 2.Additional performance increases are available by caching the DEC driver buffers. This is done by searching sysLib.c for: PHYS_MEM_DESC sysPhysMemDesc [] = and replacing the first two table entries with the following: { /* Vector Table and Interrupt Stack */ (void *) LOCAL_MEM_LOCAL_ADRS, (void *) LOCAL_MEM_LOCAL_ADRS, RAM_LOW_ADRS, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_MEM_COHERENCY, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE | VM_STATE_MEM_COHERENCY }, { /* Local DRAM - Must be second entry in sysPhysMemDesc for Auto Sizing */ (void *) RAM_LOW_ADRS, (void *) RAM_LOW_ADRS, LOCAL_MEM_SIZE - RAM_LOW_ADRS, VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_MEM_COHERENCY, VM_STATE_VALID | VM_STATE_WRITABLE | VM_STATE_CACHEABLE | VM_STATE_MEM_COHERENCY }, 3.To install this driver: a.Save your existing dec21140.obj file in a different directory. b.Extract the dec21x4x.obj file from the tar file. c.Put the new dec21x4x.obj file in the BSP directory (mv2604 & mv2603). d.Adjust the Makefile (change dec21140 to dec21x4x). e.Rebuild the bootrom and the kernel. f.Make sure you FLASH the new bootrom binary before using the new kernel. 4.The dec21x4x driver will auto-negotiate for the best speed that the link partner is capable. If the driver detects that the link partner (hub or switch) is Full Duplex capable, the driver will run in Full Duplex mode. This driver can also be forced to run in 100Mbit mode and/or Full Duplex by passing the flags DC_100_MB_FLAG and/or DC_FULLDUPLEX_FLAG in the DC_MODE argument passed into the dcattach routine. These flags are provided so that a reliable connection can be made to switches that are also auto-negotiable such as the SMC Tiger Switch 8. 5.The dec21x4x driver will support connecting the ethernet cable to the target "after" initialization. The driver will remain in a state of non-connection until the cable is plugged in. Once the cable is plugged in, the driver will use the port found until the target is rebooted. -------------------------------------------------------------------------- From ksamavedam@hns.com Thu Apr 30 07:14:21 1998 From: ksamavedam@hns.com (Krishna Samavedam) Date: Thu Apr 30 07:14:25 PDT 1998 Subject: Re :VxWorks: Have to restart ULIP to restart VxSim HI , I think U might have to check the vxsim0.nvram files after crash in which the configuration information. I have faced similar problem in HP-UX machines(with vxWorks 5.1) regards krishna > From john.l.ahrens@boeing.com Wed Apr 29 09:47:17 1998 > From: "John. L. Ahrens" > Date: Wed Apr 29 09:47:21 PDT 1998 > Subject: VxWorks: Have to restart ULIP to restart VxSim > > Every time I kill my VxSim session I have to restart ULIP on my > Sparc/Solaris machine or I get the following error: > > Target Name: vxTarget > Attaching network interface ul0... > ulipInit failed, errno = 0x0 > Bind failed > From patrick.keliher@wrs.com Thu Apr 30 09:44:30 1998 From: Patrick Keliher Date: Thu Apr 30 09:44:34 PDT 1998 Subject: Re: Re :VxWorks: Have to restart ULIP to restart VxSim Two quick things. Don't kill the VxSim window with -C or by using the mouse and exiting the window. Instead, use -\ (Control backslash). This should solve the problem. You might want to consider using PPP for VxSim instead of ULIP. It's much more standard, and I find it easier to configure. Your code should run identically. You'll still need to kill the session with -\. Hope these helped, Pat Patrick Keliher, PE MAILTO:patrick.keliher@wrs.com Senior Field Application Engineer Wind River Systems http://www.wrs.com Phone: (972)776-3555 4201 Spring Valley Road, Suite 1400 Fax: (972)776-3556 Dallas, TX 75244 Pager: (800)409-8107 Pager: MAILTO:4098107@skymail.com At 07:14 AM 4/30/98 PDT, Krishna wrote: >Submitted-by ksamavedam@hns.com Thu Apr 30 07:14:21 1998 >Submitted-by: ksamavedam@hns.com (Krishna Samavedam) > > > >HI , > I think U might have to check the vxsim0.nvram files after crash > in which the configuration information. I have faced similar > problem in HP-UX machines(with vxWorks 5.1) > >regards >krishna > >> From john.l.ahrens@boeing.com Wed Apr 29 09:47:17 1998 >> From: "John. L. Ahrens" >> Date: Wed Apr 29 09:47:21 PDT 1998 >> Subject: VxWorks: Have to restart ULIP to restart VxSim >> >> Every time I kill my VxSim session I have to restart ULIP on my >> Sparc/Solaris machine or I get the following error: >> >> Target Name: vxTarget >> Attaching network interface ul0... >> ulipInit failed, errno = 0x0 >> Bind failed >> From chip@Fiberlane.com Thu Apr 30 10:17:42 1998 From: Chip Roberson Date: Thu Apr 30 10:17:45 PDT 1998 Subject: VxWorks: Select on TCP socket in VxSim This is a cryptographically signed message in MIME format. --------------ms8F0E2EB07E05B89BF1FDB089 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello VxWorks users, I'm having a problem with a select() call and am looking for insight. I have a task that receives from a TCP socket and a pipe. I had the socket communications working by just pending on a read(). I then added the pipe and a select call. The select is waking up on the pipe but is not waking up for data in the socket. I know that the data is in the socket, the select just isn't returning. This is very basic operation and I've looked over it several times. Either there is something funny about sockets running on VxSim or I've missed something in my setup of the socket or select. Why would the select() not wake me up when there is data in the socket? Thanks, Chip -- Charles S. Roberson This message may contain two attachments: My Business vCard and My S/MIME Digital ID --------------ms8F0E2EB07E05B89BF1FDB089 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQzwYJKoZIhvcNAQcCoIIQwDCCELwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dz0wggqHMIIJ8KADAgECAhBSQxvVaEkHB30WtCO9WNr7MA0GCSqGSIb3DQEBBAUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA3MTcwMDAw MDBaFw05ODA3MTcyMzU5NTlaMIIBHzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MTMwMQYDVQQLEypEaWdpdGFsIElEIENs YXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxGzAZBgNVBAMTEkNoYXJsZXMgUyBSb2Jl cnNvbjEhMB8GCSqGSIb3DQEJARYSY2hpcEBmaWJlcmxhbmUuY29tMFwwDQYJKoZIhvcNAQEB BQADSwAwSAJBANromRBHimCh/jNky4zW4V0303OYhXGQ4HqR2n081+vQsimPqvQaMda7a79f 3pQXMzTQ75duir+rWrMiocf8d8kCAwEAAaOCB8Ewgge9MAkGA1UdEwQCMAAwggIfBgNVHQME ggIWMIICEjCCAg4wggIKBgtghkgBhvhFAQcBATCCAfkWggGnVGhpcyBjZXJ0aWZpY2F0ZSBp bmNvcnBvcmF0ZXMgYnkgcmVmZXJlbmNlLCBhbmQgaXRzIHVzZSBpcyBzdHJpY3RseSBzdWJq ZWN0IHRvLCB0aGUgVmVyaVNpZ24gQ2VydGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQg KENQUyksIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzsgYnkg RS1tYWlsIGF0IENQUy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5IG1haWwgYXQgVmVy aVNpZ24sIEluYy4sIDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMg VVNBIFRlbC4gKzEgKDQxNSkgOTYxLTg4MzAgQ29weXJpZ2h0IChjKSAxOTk2IFZlcmlTaWdu LCBJbmMuICBBbGwgUmlnaHRzIFJlc2VydmVkLiBDRVJUQUlOIFdBUlJBTlRJRVMgRElTQ0xB SU1FRCBhbmQgTElBQklMSVRZIExJTUlURUQuoA4GDGCGSAGG+EUBBwEBAaEOBgxghkgBhvhF AQcBAQIwLDAqFihodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgMBEG CWCGSAGG+EIBAQQEAwIHgDA2BglghkgBhvhCAQgEKRYnaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JlcG9zaXRvcnkvQ1BTMIIEhwYJYIZIAYb4QgENBIIEeBaCBHRDQVVUSU9OOiBUaGUg Q29tbW9uIE5hbWUgaW4gdGhpcyBDbGFzcyAxIERpZ2l0YWwgCklEIGlzIG5vdCBhdXRoZW50 aWNhdGVkIGJ5IFZlcmlTaWduLiBJdCBtYXkgYmUgdGhlCmhvbGRlcidzIHJlYWwgbmFtZSBv ciBhbiBhbGlhcy4gVmVyaVNpZ24gZG9lcyBhdXRoLQplbnRpY2F0ZSB0aGUgZS1tYWlsIGFk ZHJlc3Mgb2YgdGhlIGhvbGRlci4KClRoaXMgY2VydGlmaWNhdGUgaW5jb3Jwb3JhdGVzIGJ5 IHJlZmVyZW5jZSwgYW5kIAppdHMgdXNlIGlzIHN0cmljdGx5IHN1YmplY3QgdG8sIHRoZSBW ZXJpU2lnbiAKQ2VydGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQgKENQUyksIGF2YWls YWJsZQppbiB0aGUgVmVyaVNpZ24gcmVwb3NpdG9yeSBhdDogCmh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbTsgYnkgRS1tYWlsIGF0CkNQUy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5 IG1haWwgYXQgVmVyaVNpZ24sCkluYy4sIDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmll dywgQ0EgOTQwNDMgVVNBCgpDb3B5cmlnaHQgKGMpMTk5NiBWZXJpU2lnbiwgSW5jLiAgQWxs IFJpZ2h0cyAKUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIEFORCAK TElBQklMSVRZIExJTUlURUQuCgpXQVJOSU5HOiBUSEUgVVNFIE9GIFRISVMgQ0VSVElGSUNB VEUgSVMgU1RSSUNUTFkKU1VCSkVDVCBUTyBUSEUgVkVSSVNJR04gQ0VSVElGSUNBVElPTiBQ UkFDVElDRQpTVEFURU1FTlQuICBUSEUgSVNTVUlORyBBVVRIT1JJVFkgRElTQ0xBSU1TIENF UlRBSU4KSU1QTElFRCBBTkQgRVhQUkVTUyBXQVJSQU5USUVTLCBJTkNMVURJTkcgV0FSUkFO VElFUwpPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSClBV UlBPU0UsIEFORCBXSUxMIE5PVCBCRSBMSUFCTEUgRk9SIENPTlNFUVVFTlRJQUwsClBVTklU SVZFLCBBTkQgQ0VSVEFJTiBPVEhFUiBEQU1BR0VTLiBTRUUgVEhFIENQUwpGT1IgREVUQUlM Uy4KCkNvbnRlbnRzIG9mIHRoZSBWZXJpU2lnbiByZWdpc3RlcmVkCm5vbnZlcmlmaWVkU3Vi amVjdEF0dHJpYnV0ZXMgZXh0ZW5zaW9uIHZhbHVlIHNoYWxsIApub3QgYmUgY29uc2lkZXJl ZCBhcyBhY2N1cmF0ZSBpbmZvcm1hdGlvbiB2YWxpZGF0ZWQgCmJ5IHRoZSBJQS4wgYYGCmCG SAGG+EUBBgMEeBZ2ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVk MWIwNTlkYTc1YmM0YmM5NzAxNzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NjJmNGQz MTE0ODljYTBiYTQzZjRlNTk1NjU0MTAuBgpghkgBhvhFAQYHBCAWHjQ1YWY1MzQ4ZGMwYWY1 NGUwZDIzNDZjY2E3M2EzYjANBgkqhkiG9w0BAQQFAAOBgQByyIkSPagGt4vOuc1zBoubeanp b7oPtWasBpI6/cHOsANI8drxsxx267QIFzyIaIUw1bCbXk5GjcdsgoEEMRoI6RJTU5KoiQka 0COeAc2N6oIWW2jx3XJtLKkg7jfml/HGm9e7cL1QXzKaIZxo0/y5TQ0C+4OI0w/1i0owZHdr 9jCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoX DTk5MDYyNzIzNTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOO LPhvltcunXZLEbE2jVfJw/0cxrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5 912dFEObbpdFmIFH0S3L3bty10w/cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+ qQIDAQABozMwMTAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEE BAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6V mQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0il ZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs6SxQv6b5DduwpkowggIxMIIBmgIF AqQAAAEwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTk5MTIzMTIzNTk1OVowXzELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQVoQY h5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2 yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAFJzuppV 3Nw/gn2wkJhiKoJMdgBuJT3VwglwVwEMD3cfGKH7HGAOoHU7SSFB/qdcLUxCSdP/KNiM6p3+ yQfid4JTI95V885Ek/r6TL3KNvNbZrKeyPIMXl7UobQhCTPKO1n8ksI4/K3ZliTgLfqjKfUz aHhOtLyfaTXiqJiUczvEMYIBWjCCAVYCAQEwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJ bmRpdmlkdWFsIFN1YnNjcmliZXICEFJDG9VoSQcHfRa0I71Y2vswCQYFKw4DAhoFAKB9MBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDQzMDE3MTczOFow HgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUy80yzJiE SlS8VNznDP9mf+JogMEwDQYJKoZIhvcNAQEBBQAEQCptsm817O4vNzvAdodaRBvWVNFSre29 PYZtHdaCZxHBDqZe1oO016zSAY75YyvBRSOr89QxagBJU0hfz9nMp9o= --------------ms8F0E2EB07E05B89BF1FDB089-- From chip@Fiberlane.com Thu Apr 30 10:29:06 1998 From: Chip Roberson Date: Thu Apr 30 10:29:09 PDT 1998 Subject: VxWorks: Select problem resolved This is a cryptographically signed message in MIME format. --------------ms709D2B559EFF20AB27208D13 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nevermind. It figures that two minutes after I ask for help I get an idea as to what my problem might be. Basically it was a scoping problem on my part. Sorry for the wasted bandwidth. Chip -- Charles S. Roberson This message may contain two attachments: My Business vCard and My S/MIME Digital ID --------------ms709D2B559EFF20AB27208D13 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQzwYJKoZIhvcNAQcCoIIQwDCCELwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dz0wggqHMIIJ8KADAgECAhBSQxvVaEkHB30WtCO9WNr7MA0GCSqGSIb3DQEBBAUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMSBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA3MTcwMDAw MDBaFw05ODA3MTcyMzU5NTlaMIIBHzERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MTMwMQYDVQQLEypEaWdpdGFsIElEIENs YXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxGzAZBgNVBAMTEkNoYXJsZXMgUyBSb2Jl cnNvbjEhMB8GCSqGSIb3DQEJARYSY2hpcEBmaWJlcmxhbmUuY29tMFwwDQYJKoZIhvcNAQEB BQADSwAwSAJBANromRBHimCh/jNky4zW4V0303OYhXGQ4HqR2n081+vQsimPqvQaMda7a79f 3pQXMzTQ75duir+rWrMiocf8d8kCAwEAAaOCB8Ewgge9MAkGA1UdEwQCMAAwggIfBgNVHQME ggIWMIICEjCCAg4wggIKBgtghkgBhvhFAQcBATCCAfkWggGnVGhpcyBjZXJ0aWZpY2F0ZSBp bmNvcnBvcmF0ZXMgYnkgcmVmZXJlbmNlLCBhbmQgaXRzIHVzZSBpcyBzdHJpY3RseSBzdWJq ZWN0IHRvLCB0aGUgVmVyaVNpZ24gQ2VydGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQg KENQUyksIGF2YWlsYWJsZSBhdDogaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzsgYnkg RS1tYWlsIGF0IENQUy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5IG1haWwgYXQgVmVy aVNpZ24sIEluYy4sIDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmlldywgQ0EgOTQwNDMg VVNBIFRlbC4gKzEgKDQxNSkgOTYxLTg4MzAgQ29weXJpZ2h0IChjKSAxOTk2IFZlcmlTaWdu LCBJbmMuICBBbGwgUmlnaHRzIFJlc2VydmVkLiBDRVJUQUlOIFdBUlJBTlRJRVMgRElTQ0xB SU1FRCBhbmQgTElBQklMSVRZIExJTUlURUQuoA4GDGCGSAGG+EUBBwEBAaEOBgxghkgBhvhF AQcBAQIwLDAqFihodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9DUFMgMBEG CWCGSAGG+EIBAQQEAwIHgDA2BglghkgBhvhCAQgEKRYnaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL3JlcG9zaXRvcnkvQ1BTMIIEhwYJYIZIAYb4QgENBIIEeBaCBHRDQVVUSU9OOiBUaGUg Q29tbW9uIE5hbWUgaW4gdGhpcyBDbGFzcyAxIERpZ2l0YWwgCklEIGlzIG5vdCBhdXRoZW50 aWNhdGVkIGJ5IFZlcmlTaWduLiBJdCBtYXkgYmUgdGhlCmhvbGRlcidzIHJlYWwgbmFtZSBv ciBhbiBhbGlhcy4gVmVyaVNpZ24gZG9lcyBhdXRoLQplbnRpY2F0ZSB0aGUgZS1tYWlsIGFk ZHJlc3Mgb2YgdGhlIGhvbGRlci4KClRoaXMgY2VydGlmaWNhdGUgaW5jb3Jwb3JhdGVzIGJ5 IHJlZmVyZW5jZSwgYW5kIAppdHMgdXNlIGlzIHN0cmljdGx5IHN1YmplY3QgdG8sIHRoZSBW ZXJpU2lnbiAKQ2VydGlmaWNhdGlvbiBQcmFjdGljZSBTdGF0ZW1lbnQgKENQUyksIGF2YWls YWJsZQppbiB0aGUgVmVyaVNpZ24gcmVwb3NpdG9yeSBhdDogCmh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbTsgYnkgRS1tYWlsIGF0CkNQUy1yZXF1ZXN0c0B2ZXJpc2lnbi5jb207IG9yIGJ5 IG1haWwgYXQgVmVyaVNpZ24sCkluYy4sIDI1OTMgQ29hc3QgQXZlLiwgTW91bnRhaW4gVmll dywgQ0EgOTQwNDMgVVNBCgpDb3B5cmlnaHQgKGMpMTk5NiBWZXJpU2lnbiwgSW5jLiAgQWxs IFJpZ2h0cyAKUmVzZXJ2ZWQuIENFUlRBSU4gV0FSUkFOVElFUyBESVNDTEFJTUVEIEFORCAK TElBQklMSVRZIExJTUlURUQuCgpXQVJOSU5HOiBUSEUgVVNFIE9GIFRISVMgQ0VSVElGSUNB VEUgSVMgU1RSSUNUTFkKU1VCSkVDVCBUTyBUSEUgVkVSSVNJR04gQ0VSVElGSUNBVElPTiBQ UkFDVElDRQpTVEFURU1FTlQuICBUSEUgSVNTVUlORyBBVVRIT1JJVFkgRElTQ0xBSU1TIENF UlRBSU4KSU1QTElFRCBBTkQgRVhQUkVTUyBXQVJSQU5USUVTLCBJTkNMVURJTkcgV0FSUkFO VElFUwpPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSClBV UlBPU0UsIEFORCBXSUxMIE5PVCBCRSBMSUFCTEUgRk9SIENPTlNFUVVFTlRJQUwsClBVTklU SVZFLCBBTkQgQ0VSVEFJTiBPVEhFUiBEQU1BR0VTLiBTRUUgVEhFIENQUwpGT1IgREVUQUlM Uy4KCkNvbnRlbnRzIG9mIHRoZSBWZXJpU2lnbiByZWdpc3RlcmVkCm5vbnZlcmlmaWVkU3Vi amVjdEF0dHJpYnV0ZXMgZXh0ZW5zaW9uIHZhbHVlIHNoYWxsIApub3QgYmUgY29uc2lkZXJl ZCBhcyBhY2N1cmF0ZSBpbmZvcm1hdGlvbiB2YWxpZGF0ZWQgCmJ5IHRoZSBJQS4wgYYGCmCG SAGG+EUBBgMEeBZ2ZDQ2NTJiZDYzZjIwNDcwMjkyOTg3NjNjOWQyZjI3NTA2OWM3MzU5YmVk MWIwNTlkYTc1YmM0YmM5NzAxNzQ3ZGE1ZDNmMjE0MWJlYWRiMmJkMmU4OTIxZmE5NjJmNGQz MTE0ODljYTBiYTQzZjRlNTk1NjU0MTAuBgpghkgBhvhFAQYHBCAWHjQ1YWY1MzQ4ZGMwYWY1 NGUwZDIzNDZjY2E3M2EzYjANBgkqhkiG9w0BAQQFAAOBgQByyIkSPagGt4vOuc1zBoubeanp b7oPtWasBpI6/cHOsANI8drxsxx267QIFzyIaIUw1bCbXk5GjcdsgoEEMRoI6RJTU5KoiQka 0COeAc2N6oIWW2jx3XJtLKkg7jfml/HGm9e7cL1QXzKaIZxo0/y5TQ0C+4OI0w/1i0owZHdr 9jCCAnkwggHioAMCAQICEFIfNR3ycH4AK77KWYcE1TkwDQYJKoZIhvcNAQECBQAwXzELMAkG A1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1 YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk2MDYyNzAwMDAwMFoX DTk5MDYyNzIzNTk1OVowYjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAxIENBIC0gSW5kaXZpZHVhbCBTdWJz Y3JpYmVyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2FKbPTdAFDdjKI9BvqrQpkmOO LPhvltcunXZLEbE2jVfJw/0cxrr+Hgi6M8qV6r7jW80GqLd5HUQq7XPysVKDaBBwZJHXPmv5 912dFEObbpdFmIFH0S3L3bty10w/cariQPJUObwW7s987LrbP2wqsxaxhhKdrpM01bjV0Pc+ qQIDAQABozMwMTAPBgNVHRMECDAGAQH/AgEBMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEE BAMCAQYwDQYJKoZIhvcNAQECBQADgYEAwfr3AudXyhF1xpwM+it3T4dFFzvj0sHaD1g5jq6V mQOhqKE4/nmakxcLl4Y5x8poNGa7x4hF9sgMBe6+lyXv4NRu5H+ddlzOfboUoq4Ln/tnW0il ZyWvGWSI9nLYKSeqNxJqsSivJ4MYZWyN7UCeTcR4qIbs6SxQv6b5DduwpkowggIxMIIBmgIF AqQAAAEwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWdu LCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTk2MDEyOTAwMDAwMFoXDTk5MTIzMTIzNTk1OVowXzELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQDlGb9to1ZhLZlIcfZn3rmN67eehoAKkQ76OCWvRoiC5XOooJskXQ0fzGVuDLDQVoQY h5oGmxChc9+0WDlrbsH2FdWoqD+qEgaNMax/sDTXjzRniAnNFBHiTkVWaR94AoDa3EeRKbs2 yWNcxeDXLYd7obcysHswuiovMaruo2fa2wIDAQABMA0GCSqGSIb3DQEBAgUAA4GBAFJzuppV 3Nw/gn2wkJhiKoJMdgBuJT3VwglwVwEMD3cfGKH7HGAOoHU7SSFB/qdcLUxCSdP/KNiM6p3+ yQfid4JTI95V885Ek/r6TL3KNvNbZrKeyPIMXl7UobQhCTPKO1n8ksI4/K3ZliTgLfqjKfUz aHhOtLyfaTXiqJiUczvEMYIBWjCCAVYCAQEwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJ bmRpdmlkdWFsIFN1YnNjcmliZXICEFJDG9VoSQcHfRa0I71Y2vswCQYFKw4DAhoFAKB9MBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk4MDQzMDE3MjkwMlow HgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0DAgIBKDAjBgkqhkiG9w0BCQQxFgQUw3zxeDXf 66nFu3xTVCcf94fqO1IwDQYJKoZIhvcNAQEBBQAEQHSPVsHDDxjAKV3F5wD93Yzrp4LUfF4T 9TrnO0r27BdphuPLnS9sXimsRJdz21UpY/ta6CVm4Tlba5GRXtx3D+A= --------------ms709D2B559EFF20AB27208D13--