From Greg.J.Marshall@lmco.com  Wed Apr  1 06:15:55 1998
From: Greg J Marshall <Greg.J.Marshall@lmco.com>
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" <kkauper@draper.com>
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 <chris_calley@dlcc.com>
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." <joew@wreck.wtc.gov>
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" <gzhang@utstar.com>
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 <ihw@rtp.co.uk>
Date: Wed Apr  1 23:30:29 PST 1998
Subject: Re: cc386 -g puzzle
Greg Zhang <gzhang@utstar.com> 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 <harald.grundner@ri.dasa.de>
Date: Thu Apr  2 00:33:21 PST 1998
Subject: Re:
>Submitted-by: Greg J Marshall <Greg.J.Marshall@lmco.com>
>
>     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<ted@biosys.net>
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 <rwent@ti.com>
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 <bmcgonig@mariners.com>
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 <bmcgonig@mariners.com>
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" <bobperry@bellatlantic.net>
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 <cgrames@mdc.com>
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 <vxwexplo@lbl.gov> 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)" <LegoasMarcoA@space.honeywell.com>
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 <shoutchen@SYSTRAN.com>
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 <jford@bara.gb.nrao.edu>
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 <ste@ply.wg.com>
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 <rwent@ti.com>
> 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: -[<key>]
    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" <nguyend2@ttc.com>
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" <jaa@mclean.sparta.com>
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" <RadaJA@corning.com>
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 <bmcgonig@mariners.com>
>
>
> 	(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" <jjl@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" <bawilson@llnl.gov>
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 <Greg.J.Marshall@lmco.com>
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" <mmcquade@aa.net>
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 <rmapes@pacbell.net>
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 <pascal@wrs.com>
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" <nguyend2@ttc.com>
>
>
>      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) <timeout in sec>
Pascal
From MSchrape@atomika.com  Mon Apr  6 02:04:16 1998
From: Martin Schrape <MSchrape@atomika.com>
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
<chris@wallaby.mtc.ti.com> incomplete.  See:
<ftp://ftp.atd.ucar.edu/pub/vxworks/vx/vxTcl8.0-diff>.
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,
<Matt.Berney@Tek.Com>
Joe VanAndel, National Center for Atmospheric Research, <vanandel@ucar.edu>
Vincent Chen, Real-Time Innovations, Inc., <vince@rti.com >
Chris Frank, Texas Instruments, <c-frank@ti.com> or <chris@wallaby.mtc.ti.com>
John Maline, Texas Instruments, <jmaline@ti.com>
Johan Kovacs, Sun Microsystems, <Johan.Kovacs@France.Sun.COM> /* 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" <jaa@mclean.sparta.com>
>
>
>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" <msaunders@taz.dera.gov.uk>
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" <mmcquade@aa.net>
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 <vxwexplo@lbl.gov>
To: vxworks_users@csg.lbl.gov <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" <bawilson@llnl.gov>
>
>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 <ddas@india.hp.com>
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" <jtmark@most.fw.hac.com>
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 <froeber@bbn.com>
Date: Tue Apr  7 08:32:48 PDT 1998
Subject: Re: symbol table
Jimmie T Marks <jtmark@most.fw.hac.com> 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 <Brent.Carlson@hia.nrc.ca>
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 <mcneils@applique.dh.trw.com>
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 <vxWorks.h>
#include <symLib.h>
#include <sysSymTbl.h>
#include <time.h>
#include <errno.h>
#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" <mea@mclean.sparta.com>
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 <vxWorks.h>
#include <drv/hdisk/ideDrv.h>
#include <dosFsLib.h>
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 <bmcgonig@mariners.com>
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 <jhou@ee.eng.ohio-state.edu>
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 <bpringle@teklogix.com>
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 <wheat@wg.com>
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 <cgrames@mdc.com>
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 <johill@lanl.gov>
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" <Kenneth.Lin@Australia.Boeing.com>
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 <ihw@rtp.co.uk>
Date: Thu Apr  9 00:45:43 PDT 1998
Subject: Zip drive support
Charlie Grames <cgrames@mdc.com> 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 <devType> and <removable> 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" <jyoo@stisierra.com>
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)" <larry.dalessandro@ae.ge.com>
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 <Rick.Rorex@vmic.com>
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 <Greg.J.Marshall@lmco.com>
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)" <larry.dalessandro@ae.ge.com>
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 <froeber@bbn.com>
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" <John.Ahrens@PSS.Boeing.com>
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,
<color><param>0000,0000,8080</param>
<bold><bigger>Ron Aguilar
</bigger></bold>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</color>
From carl@themis.com  Thu Apr  9 15:23:48 1998
From: "Carl C. Chesbrough" <carl@themis.com>
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" <don.blake@lmco.com>
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" <John.Ahrens@PSS.Boeing.com>
>>
>> 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" <meier3@llnl.gov>
Organization: Lawrence Livermore National Laboratory
Message-ID: <6gg1ju$jfo$1@lll-winken.llnl.gov>
References: <6gbptt$9cu$1@lll-winken.llnl.gov> <antispam-ya02408000R0704982231290001@news.orbitworld.net>
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" <jeffrey.mathes@gsc.gte.com>
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" <JohnEdwards@oscsystems.com>
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:	OpenGroups  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, cant 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 <wheat@wg.com>
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 Antbck, 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" <simon@cgltech.com>
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 <mcarr@NOSPAMredstonecom.com> 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 <rwa2@ti.com>
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" <john@finley.com>
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" <ptp@mclean.sparta.com>
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" <John.Ahrens@PSS.Boeing.com>
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" <John.Ahrens@PSS.Boeing.com>
> >>
> >> 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 <Robert.J.Bollhorst@lmco.com>
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" <hwa-jin@mylex.com>
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 <cruz_nojunk@xyplex.com>
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" <Huang.Wu@nrc.ca>
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" <Les.Ziobronowicz.leszek@nt.com>
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 <mailto:ziobrolx@nt.com>  )
------ =_NextPart_001_01BD68A5.B419B79E
Content-type: text/html
Content-transfer-encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.0.1460.9">
<TITLE>RE: comp.os.vxworks newsdigest</TITLE>
</HEAD>
<BODY>
<BR>
<P><FONT SIZE=3D2 FACE=3D"Arial">Hi there,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Please remove me from vxworks user =
group, thanks</FONT>
</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">Les Ziobronowicz (</FONT> <A =
HREF=3D"mailto:ziobrolx@nt.com"><U><FONT COLOR=3D"#0000FF" SIZE=3D2 =
FACE=3D"Arial">ziobrolx@nt.com</FONT></U></A><FONT SIZE=3D2 =
FACE=3D"Arial"> )</FONT>
</P>
</BODY>
</HTML>
------ =_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 <jbt@mclean.sparta.com>
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" <ptp@mclean.sparta.com>
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" <jtmark@most.fw.hac.com>
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 <cgrames@mdc.com>
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 <vxwexplo@lbl.gov> 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:
<snip>
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 <mfischer@qualcomm.com>
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 <froeber@bbn.com>
Date: Thu Apr 16 19:00:19 PDT 1998
Subject: Re: Starting up from target shell -Reply
On Thu, 16 Apr 1998, Charlie Grames <cgrames@mdc.com> 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 <kb+@andrew.cmu.edu>
Organization: Doctoral student, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA
Message-ID: <MpBfsuu00iWP0=4Y00@andrew.cmu.edu>
References: <B0A7ED2BEF95D111BFAD00805F9A00C516D9A3@huckleberry.etcconnect.com>
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 <OR> 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 <cgrames@mdc.com>
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 <Susan.J.Henry@lmco.com>
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 <t_wmoles@qualcomm.com>
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 <Susan.J.Henry@lmco.com>
>
>
>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 <chris@raf.atd.ucar.edu>
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 <mc4922@mclink.it>
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: <ErJrt5.2En@oce.nl>
References: <01bd6712$a1cc1260$4921b00a@system2>
Sender: news@oce.nl (The Daily News @ nntp01.oce.nl)
In article <01bd6712$a1cc1260$4921b00a@system2>, "thierry" <thierry@ilogix.com> 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 <yzur@qualcomm.com>
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" <jellis@hughes.net>
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?
<color><param>0000,0000,8080</param>
<bold><bigger>Ron Aguilar
</bigger></bold>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</color>
From tkb@mclean.sparta.com  Mon Apr 20 10:24:09 1998
From: Thomas Keith Buchanan <tkb@mclean.sparta.com>
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 <<tkb@mclean.sparta.com>
>
>> 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?
<color><param>0000,0000,8080</param>
<bold><bigger>Ron Aguilar
</bigger></bold>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</color>
From gpbeedu@net.com  Mon Apr 20 13:09:25 1998
From: Guru Prasad Beedu <gpbeedu@net.com>
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 <Bob.Ferrara@digital.com>
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 <espin@idiom.com>
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 <wheat@wg.com>
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 <taher@teil.soft.net>
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 <mirie@telegate.co.il>
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 <wheat@wg.com>
>
> 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" <jbhawth@aptec.com>
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 <caprio@research.moore.com>
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 <froeber@bbn.com>
Date: Tue Apr 21 18:26:29 PDT 1998
Subject: Re: turning off listening to redirects
On Mon, 20 Apr 1998, Lee Wheat <wheat@wg.com> 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 <ashoka@teil.soft.net>
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 <Thomas.Arand@oen.siemens.de>
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" <jbhawth@aptec.com>
>=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 <doug.litke@wj.com>
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 <frank@info-age.net>
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 <stevens@ims.fhg.de>
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" <pat.shaw@canada.cdev.com>
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 <cbriles@lanl.gov>
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" <bawilson@llnl.gov>
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/<path to installation dir> -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 <cgrames@mdc.com>
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 <caprio@research.moore.com>
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 <bpringle@teklogix.com>
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" <tony.mayes@epid.eurotherm.co.uk>
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 <larry@dogwood.com>
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 <roddy.pratt@oxtel.com>
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 <kb+@andrew.cmu.edu>
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 <shoutchen@SYSTRAN.com>
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 <cbriles@lanl.gov>
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" <blohm@vs.dasa.de>
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 <shoutchen@SYSTRAN.com>
>
> 	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" <tony.mayes@epid.eurotherm.co.uk>
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" <mea@mclean.sparta.com>
Date: Fri Apr 24 04:58:40 PDT 1998
Subject: RE: mmu on 162
> Submitted-by: Carolyn Briles <cbriles@lanl.gov>
>
> 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 *) <your flash phys address>,
    (void *) <your flash virtual address -- on 162 it's probably the same as
phys>,
    <size of flash>,
    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 <abbottd@jlab.org>
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 <caprio@research.moore.com>
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 <mikem@sdlabs.com>
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 <jford@bara.gb.nrao.edu>
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 <mikem@sdlabs.com>
>
> 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 <caprio@research.moore.com>
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 <froeber@bbn.com>
Date: Fri Apr 24 13:05:19 PDT 1998
Subject: RE: mmu on 162
Carolyn Briles <cbriles@lanl.gov> 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 <caprio@research.moore.com>
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 <mike@CastleNetworks.com>
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) : <enet address goes here: mask >
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 <chris@raf.atd.ucar.edu>
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 <bob@seaweed.com>
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" <bennett@VirtualPrototypes.CA>
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 <pchien@mweb.co.za> 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" <mea@mclean.sparta.com>
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 <roghol@lin.foa.se>
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 <ihw@rtp.co.uk>
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)" <larry.dalessandro@ae.ge.com>
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 <sinnl@sd-star.com>
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 <sinnl@sd-star.com>
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" <mam@pluto.dspt.com>
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 <froeber@bbn.com>
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 <andy_wacaser@anteonwest.com>
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" <blohm@vs.dasa.de>
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" <mam@pluto.dspt.com>
>
> 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" <han2326@shinbiro.com>
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 <mcarr@nospamredstonecom.com>
Organization: UltraNet Communications, Inc.   http://www.ultranet.com/
Message-ID: <ug1iz4x53.fsf@NOSPAMredstonecom.com>
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" <jrwills@fallschurch.esys.com>
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 <costello@million-monkeys.com>
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 <grave@ipnsun5.in2p3.fr> 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 <ste@ply.wg.com>
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 <cruz_nojunk@xyplex.com>
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 <froeber@bbn.com>
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 <tkb@mclean.sparta.com>
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 <adamakis@nosc.mil>
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" <mam@pluto.dspt.com>
>
>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
> <Host>x<Target> 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 <getker@sentientnet.com>
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 <rls@ti.l-3com.com>
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 <tkb@mclean.sparta.com>
>
> 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." <DAVID.T.BENNETT@cpmx.saic.com>
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 <andy_wacaser@anteonwest.com>
From ste@ply.wg.com  Wed Apr 29 01:42:49 1998
From: Steve James <ste@ply.wg.com>
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" <jal@alum.mit.edu>
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 Imgenes
      / /  ____   / /		ETS. Ingenieros de Telecomunicacin
     / /  __  /  / /    / /	Universidad Politcnica de Madrid
    / /____/ /  / /    / /	28040 Madrid - SPAIN
   /______  /  / /    / /	tel: +34.1.336.7353
         / /			fax: +34.1.336.7350 or 34.1.5439652
   Enrique Rendn-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" <john.l.ahrens@boeing.com>
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" <jal@alum.mit.edu>
> 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 <sinnl@sd-star.com>
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 <jeanyves.thiriet@cnet.francetelecom.fr>
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 <grave@ipnsun5.in2p3.fr>
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" <frederic.rosin@matra-com.fr>
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 <abbottd@jlab.org>
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" <john.l.ahrens@boeing.com>
> 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 <patrick.keliher@wrs.com>
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 <ctrl>-C or by using the mouse and exiting
the window. Instead, use <ctrl>-\ (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 <ctrl>-\.
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" <john.l.ahrens@boeing.com>
>> 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 <chip@Fiberlane.com>
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 <Chip@Fiberlane.com>
This message may contain two attachments:
My Business vCard <http://www.imc.org/pdi/vcardoverview.html> and
My S/MIME Digital ID <http://www.verisign.com/products/individual/index.html>
--------------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 <chip@Fiberlane.com>
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 <Chip@Fiberlane.com>
This message may contain two attachments:
My Business vCard <http://www.imc.org/pdi/vcardoverview.html> and
My S/MIME Digital ID <http://www.verisign.com/products/individual/index.html>
--------------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--