HDTenEightyP/NetNews huggingface dataset:
From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: re:  gnu cc asm constraints
Date: Thu, 12 Nov 1992 08:00:31 -0500
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Phil Perillat writes:
>  I do have one more question though...
>  
>  We've got the the gnu tooKit for vxWorks 5.0.1 with mv167 boards and i've seen
>  and used the asm construct before. But i'm a little confused about the 
>  constraints (the things in quotes). 
>  
>  asm is explained starting on pg 31 of the gnu toolkit for vxworks (5.0.1)
>  It mentions constraints of
>  
>                 =,f,a digit,+,& 
>  
>  and then says the constraints use the same language used in the
>  machine description. So i went to the section on as in the same documentation
>  and it didn't say much about any architecture specific things..my next stop
>  was the  motorola programmer's ref manual and the mc68040 user's manual.
>  Well i found lots of definitions... d=data reg, d=double, d=displacement..
>  
>  so my question is where do i look for the definitions of the constraints like
>  
>      "dmi"???

When using the asm construct (actually __asm__ if you are using
gcc -traditional) I typically stick with the basic operand types.  The place
I go for the operand type definitions is the  m68k-opcode.h  file in the
as68 source code area (the GNU tool source code that came as part of the
vxworks release).  The thing I always find trickiest with asm is getting
the inputs and outputs coordinated for instructions that use the same
register as both an input and output (I found the CAS2 instruction with its
6 operands the toughest to use).  BTW, a useful trick is to use inline
functions in .h files with asm code in them.  The compiler then can optimize
the code through the function call.  As an example the code for the interrupt
lock/unlock functions (for 68K and ANSI compiler version) is:

        /*
        modification history
        --------------------
        55a,1sep92,fjr  force to level 7 for locking for more speed
        55a,20jun92,fjr set up separate ANSI and non ANSI versions
        55a,16jun92,fjr fix to make intLock/intUnlock inline asm for speed
        */
/* for definitions of these functions see normal function headers in
 * src/68k/intALib.s.
 */
IMPORT USHORT intLockMask;

extern __inline__
int intLock(void)
{
    int temp1, temp2;

    __asm__ ("movew sr,%0" : "=d" (temp1) : );
    temp2 = temp1;
#ifdef LEVEL_7_LOCKING
    /* save an instruction since we normally lock to level 7 */
    temp1 |= 0x0700;
#else    /* LEVEL_7_LOCKING */
    /* normal Vxworks case */
    temp1 &= 0xf8ff;
    temp1 |= intLockMask;
#endif   /* LEVEL_7_LOCKING */
    __asm__ ("movew %0, sr" : : "d" (temp1));
    return(temp2);
}
 
extern __inline__
void intUnlock(int oldSR)
{
    __asm__ ("movew %0, sr" : : "d" (oldSR));
}
 
Newsgroups: comp.os.vxworks
From: chris@wrs.com (Chris Ford)
Subject: initializing the DUSCC chip
Organization: Wind River Systems, Inc.
Date: Mon, 9 Nov 1992 20:16:44 GMT

hlg@matrix.com (Louis Gray) writes:
>You can solve your problem by adding the following lines of code to the 
>routine sysHwInit [code for disabling DUSCC timer interrupt]

WRS is aware of the incomplete DUSCC initialization bug (ref. SPR 1689)
and has fixed it for relevant VxWorks 5.1 board support packages.
The problem is not limited to the timer interrupts.  The code fragment below,
for sysHwInit() in sysLib.c, will thoroughly initialize one DUSCC chip.
The DUSCC base address and interrupt vector are board dependent.


#define	DUSCC_BASE_ADRS	[board dependent]

    *DUSCC_GSR   = (char) 0xff;

    /* execute reset commands */

    *DUSCC_CCRA = DUSCC_CCR_TX_RESET_TX;
    *DUSCC_CCRB = DUSCC_CCR_TX_RESET_TX;
    *DUSCC_CCRA = DUSCC_CCR_RX_RESET_RX;
    *DUSCC_CCRB = DUSCC_CCR_RX_RESET_RX;
    *DUSCC_CCRA = DUSCC_CCR_CT_STOP;
    *DUSCC_CCRB = DUSCC_CCR_CT_STOP;
    *DUSCC_CCRA = DUSCC_CCR_DPLL_DISABLE_DPLL;
    *DUSCC_CCRB = DUSCC_CCR_DPLL_DISABLE_DPLL;

    /* initialize registers */

    *DUSCC_CMR1A = (char) 0x0;
    *DUSCC_CMR1B = (char) 0x0;
    *DUSCC_CMR2A = (char) 0x0;
    *DUSCC_CMR2B = (char) 0x0;
    *DUSCC_TPRA  = (char) 0x0;
    *DUSCC_TPRB  = (char) 0x0;
    *DUSCC_RPRA  = (char) 0x0;
    *DUSCC_RPRB  = (char) 0x0;
    *DUSCC_CTCRA = (char) 0x0;
    *DUSCC_CTCRB = (char) 0x0;
    *DUSCC_OMRA  = (char) 0x0;
    *DUSCC_OMRB  = (char) 0x0;
    *DUSCC_PCRA  = (char) 0x0;
    *DUSCC_PCRB  = (char) 0x0;
    *DUSCC_RSRA  = (char) 0xff;
    *DUSCC_RSRB  = (char) 0xff;
    *DUSCC_TRSRA = (char) 0xff;
    *DUSCC_TRSRB = (char) 0xff;
    *DUSCC_ICTSRA = DUSCC_ICTSR_CT_ZERO_COUNT;
    *DUSCC_ICTSRB = DUSCC_ICTSR_CT_ZERO_COUNT;
    *DUSCC_IERA  = (char) 0x0; 
    *DUSCC_IERB  = (char) 0x0; 

    *DUSCC_IVR  = [board dependent];	/* initialize vector register */

    /* enable a, enable b, modify vec w/stat, present vec to cpu */

    *DUSCC_ICR  = DUSCC_ICR_CHAN_B_MAST_INT_EN | DUSCC_ICR_CHAN_A_MAST_INT_EN |
	          DUSCC_ICR_VECT_INCLDS_STATUS | DUSCC_ICR_VECT_MODE_VECT;

Hope this helps,

-Chris Ford
 Engineer
 Wind River Systems
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Newsgroups: comp.os.vxworks
Subject: re: MVME167 timing
Date: Thu, 5 Nov 92 17:04:30 MST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


> > But no setting of the prescaler adjust??? Looking at 0xfff4004c also shows
> > the prescaler adjust set to zero??? paraphrasing the mv167 Programmers Ref
> > guide pg. 2-62...
> > 
> > If the prescaler is not correctly programmed, the bus timers do not generate
> > their specified values and the VMEbus reset time may be violated...
> >  
> > Have i missed something here ?????
> 
> I think Phil is completely correct.  
> What do other people think?  

For what its worth, I also think Phil and Fred are correct.

> Is this a fix that has already been tried out by anyone?

Not here. However, I am installing Fred's suggested parameters
this evening.


Jeff



Newsgroups: comp.os.vxworks
From: carl@wrs.com (Carl Chesbrough)
Subject: Re: MVME167 timing
Organization: Wind River Systems, Inc.
Date: Thu, 5 Nov 1992 23:39:49 GMT

Roeber <fjr@ssd.ray.com> writes:

>Hello,  Back in august, there was some discussion on initializing the timer
...deleted to save space...
>> 
>>     *VMECHIP2_TIMEOUTCR         = (TIMEOUTCR_VGTO_64US  |
>>                                    TIMEOUTCR_VATO_1MS   |
>>                                    TIMEOUTCR_LBTO_64US  |
>>                                    TIMEOUTCR_WDTO_16MS);
>> 
>the initialization line above should be:

>     *VMECHIP2_TIMEOUTCR         = (TIMEOUTCR_ARBTO       |
>                                    TIMEOUTCR_VGTO_256US  |
>                                    TIMEOUTCR_VATO_1MS    |
>                                    TIMEOUTCR_LBTO_8US    |
>                                    TIMEOUTCR_WDTO_512MS  |
>                                    (256 - BCLK));
>This should make bus activity much more reliable (and also let people use
>the two timers in the VME chip for additional timing capabilities).  Note
>that I also am enabling arbitration timeout so that a card glitch can't hang
>the whole backplane. What do other people think?  Is this a fix that has
>already been tried out by anyone?    Fred

The new version of vxWorks (5.1) has the following initialization for this
register:

    *VMECHIP2_TIMEOUTCR         = (TIMEOUTCR_VGTO_256US |
                                   TIMEOUTCR_VATO_1MS   |
                                   TIMEOUTCR_LBTO_64US  |
                                   TIMEOUTCR_WDTO_16MS) |
                                   ((256 - BCLK) & 0xff);

5.1 will be in beta soon, if it is not already (talk to sales).  I will check
into the need for _ARBTO and a larget _WDTO_ value, and may change get
this change into the FCS (post-beta) release.

If anyone has arguments for/against the differences here please let me know.

Thanks,
-Carl C. Chesbrough
Wind River Systems, Inc.
1010 Atlantic Avenue
Alameda, California  94501
(510) 748-4100
carl@wrs.com
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Newsgroups: comp.os.vxworks
Subject: re: MVME167 and RealTime Clock
Date: 13 Nov 92 13:34:35 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Happy Friday the 13th,

In our discussions on setting up the Prescaler on the MV167
Fred Roeber writes:

->  I agree that it would be nice to set up the board so it works at any 
->  frequency. Paul is reading a value out of the battery backed RAM to do this.
->  I wonder why we couldn't just use the value set in the memory 
->  bus clock register (see MEMC_BCR register on pg 4-12 of the HW guide).
->  This register is set up by diagnostics so that the board functions correctly
->   It contains the integer clock speed value.  

I was unaware of the existence of the Bus Clock Register (MEMC_BCR).
That is why I read the battery backed RAM.

However, on closer examination of the MEMC_BCR, it turns out that
this register is initialized in the romInit.s file by
  ->  moveb   #MEMC_BCR_25MHZ,MEMC_BCR

Since this is hardcoded, MEMC_BCR will have the incorrect value 
for the 33MHZ board. Thus, we need to also initialize this register based on the
battery backed RAM. From reading the MVME-167 manual, the MEMC_BCR reg
controls the refresh timer. I would expect that initializing the MEMC_BCR
with MEMC_BCR_25MHZ on a 33 MHZ board will only result in the DRAMS
being refreshed more often than needed. But why loose performance by
refreshing when you don't need to. Since performance is generally
irrelevant during booting and assembly is not much fun, I plan to
only make the changes only in sysLib.c
Thus:

    strncpy ( oscFreq, (char*)0xfffc1f28, 4);  /* read clk speed from BBRAM */
    oscFreq[4] = NULL; /* terminate string */
 
    if (!strncmp(oscFreq, "33", 2))
    {
      *((unsigned char)MEMC_BCR) = 33; /* Set the DRAM Refresh Rate */
      *PCC2_PRESCALE        = -33;  
      *PCC2_PRESCALE_CLK_ADJ  = -33;
    }    
 
    else /* if (strncmp(oscFreq, "2500", 4))   */
    {
      *((unsigned char)MEMC_BCR) = 25; /* Set the DRAM Refresh Rate */
      *PCC2_PRESCALE        = -25;
      *PCC2_PRESCALE_CLK_ADJ  = -25;
    }    
 
As for the MEMC_RCR_SWAIT bit, from what I know, the comments by WRS
make no sense. It is my understanding from working with the 
board designers at Motorola, that the SWAIT bit need only be set
on boards containing rev 0 of the MEMC chip when using bus snooping. 
Thus, in my code where I set up the MMU I do the following:

    /* Check Rev of memc040 chip */
    /*  *MEMC_RCR |= MEMC_RCR_SWAIT;   Needed for errata when bus snooping */
    if(*MEMC_REVISION == 0x00) /* MEMC_REVISION can be read as a byte */
      *MEMC_RCR |= MEMC_RCR_SWAIT; /* |= works for 8 bit reg */

Anybody else agree?


        Paul R. Bade
        Johns Hopkins University / Applied Physics Lab
        (301)-953-5000 x8681
        prb@aplexus.jhuapl.edu
From: els@icf.hrb.com (Eric L. Schott)
Newsgroups: comp.os.vxworks
Subject: Re: VMEbus slot number (not strictly VxWorks)
Date: 11 Nov 92 14:50:52 EST
Distribution: comp.os.vxworks
Organization: HRB Systems, Inc.

In article <1992Nov10.163644.18883@alcatel.ch>, ross@srxvb303.alcatel.ch (David Ross) writes:
>  
> We're using VxWorks with Heurikon HK80/V960 VMEbus boards, and 
> we want to get rid of the boot parameters required for each 
> node. We can see a way to do this, by adding RARP code to 
> the boot ROM backplane driver (yes, quite a bit of work), but 
> the one boot parameter we can't see how to deal with is the 
> "processor number". This is required so that processor 0 can 
> export some of its local RAM to one of the VME address
> spaces so that the other boards can use it for the backplane 
> comms, and also so that the other boards can access their
> own structures in the shared memory (using processor number as 
> an index). 
>  
> So, is there any way a VMEbus board can determine which slot it
> is in? I'm not too optimistic as the VMEbus specification doesn't 
> provide any "geographical address" signals, but I thought that 
> somebody may have dealt with this before.

The slot 0 board must be system controller.  Typically this is also
processor 0.  Some boards have a register which indicates if the
CPU is the system controller.

One board I have used has a parallel printer port which goes out the
P2 connecter.  We were able to uniquely identify cards by tying the
pins either high or low.

Yes, the entire concept of NVRAM boot parameters is a pain.  This is
especially true when cards need to be swapped.  Even RARP has problems
here in that the database on the host CPU needs changed when cards move.
The best approach we have found is to use this printer port to uniquely
identify each card.  This id is broadcast on the network.  A daemon
running on the host the responds with an ethernet packet which has
the entire boot string.  Then cards can be swapped without changing
any databases.

-- 

Eric L. Schott,    HRB Systems, Inc.    814/238-4311     els@icf.hrb.com
  "As we acquire more knowledge, things do not become more comprehensible
   but more mysterious."                  Albert Schweitzer, "Paris Notes"
Newsgroups: comp.os.vxworks
From: wybo@adi.com (Dave Wybo)
Subject: available targets for vxworks
Organization: Applied Dynamics
Distribution: na
Date: Wed, 11 Nov 1992 16:00:37 GMT

In an analysis of real-time kernels, one aspect sometimes overlooked is the
breadth of hardware in a certain class, that the given kernel is capable of
running on and/or supported for.

I am interested in the variety of VMEbus based processor boards which are
supported by vxworks.  Having followed this newsgroup for a while, I have a
pretty good feel that some of the more common flavors are supported, such as
M68xxx based VME boards from a wide variety of vendors.

Does anyone have any info about other processor boards, such as the HP-RT,
MC88110, R4400, etc?  Anyone have a feel for how long it takes Wind River to
bring a port of vxworks for a new hardware architecture to market?

Does one necessarily need a full Wind River "blessing" of a new processor board
in order to get the kernel up and running? i.e. if I have brand xyz 68xxx
based processor, how much work can I expect to have to do in order to get a
basic port done?  (basic meaning just something running, with maybe a console
port supported for debugging)

What is the recommended debugging environment for vxworks?

Just how easy is it to take a program that runs on a un*x box, and convert it
to run under vxworks?

My impression is that there are many happy, or at least satisfied customers
out there.  Any gotcha's?  Any environments where vxworks is just plain
inappropriate?

If I have a single task solution, can I turn off context switching so that I
keep the o.s. out of the way of my real-time task? (other than clock interrupts
of course)

I am somewhat familiar with pSOS+ and the ability to run a task in supervisor
(privileged) mode if I so desire.  Is the same true for vxworks?

Are all of these FAQ's?  If so, sorry...

-- 
--
Dave Wybo  Applied Dynamics, 3800 Stone School Road, Ann Arbor, MI 48108
(313) 973-1300  Internet: wybo@adi.com  uucp: (sharkey|heifetz)!amara!wybo
--
Newsgroups: comp.os.vxworks
From: ross@srxvb303.alcatel.ch (David Ross)
Subject: VMEbus slot number (not strictly VxWorks)
Summary: How can a board determine its slot number?
Organization: Alcatel STR Switzerland
Distribution: comp.os.vxworks
Date: Tue, 10 Nov 1992 16:36:44 GMT

I know this is not a question directly applicable to this group, 
but comp.vmebus hasn't been formed yet ... 
 
We're using VxWorks with Heurikon HK80/V960 VMEbus boards, and 
we want to get rid of the boot parameters required for each 
node. We can see a way to do this, by adding RARP code to 
the boot ROM backplane driver (yes, quite a bit of work), but 
the one boot parameter we can't see how to deal with is the 
"processor number". This is required so that processor 0 can 
export some of its local RAM to one of the VME address
spaces so that the other boards can use it for the backplane 
comms, and also so that the other boards can access their
own structures in the shared memory (using processor number as 
an index). 
 
So, is there any way a VMEbus board can determine which slot it
is in? I'm not too optimistic as the VMEbus specification doesn't 
provide any "geographical address" signals, but I thought that 
somebody may have dealt with this before.
 
As an aside, it seems a bit funny that the VMEbus doesn't provide
a geographical address. Is there any reason for this omission?
 
 
------------------------------ mov -(pc),-(pc) ----------------------------.--
David Ross (ross@alcatel.ch)                                           _--_|\
On loan to:  Alcatel STR, Zurich, CH.                                 /      \
Phone:       +41 52 61 33 44                                          *_.--._/
Fax:         +41 52 61 32 82                                                v
------------------------------------------------------------------------------

Newsgroups: comp.os.vxworks
From: hlg@matrix.com (Louis Gray)
Subject: Re: Problem with large bss segment
Date: Thu, 5 Nov 1992 14:56:38 GMT
Organization: Matrix Corporation



> I've run into a really odd situation in linking my application with vxWorks:
> It appears that if the BSS segment of the resulting image exceeds a
> certain size (around 160K), the system never initializes completely
> and either "hangs" or eventually gets an uninitialized interrupt and
> reboots.

-Henning

You can solve your problem by adding the following lines of code to the 
routine sysHwInit in sysLib.s

 
    /* The following DUSCC configuration code clears any pending
     * timer interrupts.  If this not done, a timer interrupt will
     * cause continuous rebooting if the initialization is taking
     * too long. (for instance extra large BSS allocations.)
     */
			  
    /* Disable zero-detect interrupt from DUSCC timers. */
      
    *DUSCC_CTCRA = *DUSCC_CTCRA & 0x7f;
    *DUSCC_CTCRB = *DUSCC_CTCRB & 0x7f;

    /* Reset pending DUSCC timer interrupts. */

    *DUSCC_ICTSRA = *DUSCC_ICTSRA | (UINT8) DUSCC_ICTSR_CT_ZERO_COUNT;
    *DUSCC_ICTSRB = *DUSCC_ICTSRB | (UINT8) DUSCC_ICTSR_CT_ZERO_COUNT;
						      

the lines should go at about line 260, right before the line reading:

    /* initialize vector register */


The problem you are having is caused by an unexpected clock interrupt.  Here
is what is happening:

	Most UART/TIMER chips automatically disable the timer when you
	initialize the chip.  The DUSCC doesn't do this.

	VxWorks starts the timer for use by the boot ROMs, but does not
	disable it before jumping into the real code

	The real vxWorks masks interrupts and starts it's initialization,
	eventually unmasking interrupts somewhere in kernelInit.

	Meanwhile the clock has been counting down for another tick.  With
	a small BSS, kernelInit was able to finish its work and get things
	set up for a clock interrupt.  Your larger BSS gave the DUSCC time
	to generate another interrupt.

	The code above disables the timer and handles any potential pending
	interrupts while they are still masked.

I hope this helps!
-- 
- HL -

===============================================================================

Newsgroups: comp.os.vxworks
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Subject: Interesting ld68k behavior
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Date: Fri, 6 Nov 1992 13:40:47 GMT



I just thought I'd share an observation I've made recently while
placing vxWorks and application code into ROM.

I'm using the rom compression feature, so most of my code gets
crunched into a handy data array. The last step before compression is
to ld68k everything one last time, specifying usrInit() as the entry
point and RAM_TEXT_HIGH_ADDRESS (typically 0x90000) as the start of
the text segment. Then, when the system starts up, romStart()
uncompresses the whole mess, starting at RAM_TEXT_HIGH_ADDRESS, and
then proceeds to jump to the entry point with the call
((FUNCPTR)RAM_TEXT_HIGH_ADRS) (startType);

So far so good, it looks like everything is going according to plan.
My assumption - from looking at how things are done - was that
specifying -e _usrInit and -T 90000 results in usrInit() being placed
at the start of the text segment, since that is the routine we want to
execute when we jump to RAM_TEXT_HIGH_ADDRESS. Sounds reasonable.

But imagine my surprise when I added some custom routines at the top
of usrConfig.c (one might argue over the political correctness of
doing so...), and usrInit no longer ended up at RAM_TEXT_HIGH_ADDRESS.
Instead, whatever routine appeared first in usrConfig.c got that
privilege and was subsequently called by romStart. 
The obvious solution was to simply rearrange the order of the routines
usrConfig.c so that usrInit() comes first.

But I have to wonder: Is this the way things ought to be? Am I just
missing something fundamental here? Or could it be that somehow the
notion of "entry point" becomes unclear when loading a module by
uncompressing from one part of memory into another?

I'd be interested in your comments.

-Henning

 
--
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
------------------------------------------------------------------------------
                  It can be difficult to wreck a nice beach.
From: thor@surt.atd.ucar.edu (Richard E. Neitzel)
Subject: Re: mv147 vs mv167 arithmetic times
Organization: National Center for Atmospheric Research
Date: Mon, 9 Nov 1992 18:47:00 GMT

 In article <9211091639.AA00221@naic.edu>, phil@naic.edu (Phil Perillat Rm 407 X286) writes:
....
|> Looking at the table you can see that i've just got bad luck. 
|> The double to int and float to int are the real losers on the 68040. They
|> run about 5 times faster on a 68030. If you can stay with regular floating
|> point operations (read regular as supported!) the 68040 should be 2 to 10
|> times faster than the 68030...
....
|> ps. If any one has a neat (fast) way of going double to int, i'm just
|> like ross perot (all ears).

Well, there are two ways to get the conversion to run faster. You could call irint(). This
calls the 040 math library. If you are using gcc you could use the following function:

static __inline__ int fastround(double d)
{
    register int i;
    register int cm;
    register int im;

    asm volatile ("fmove%.l fpcr,%0" : "=dm" (cm) : );

    im = cm & 0xff00;

    asm volatile ("fmove%.l %0,fpcr" : : "dmi" (im));

    asm volatile ("fmove%.l %1,%0" : "=d" (i) : "f" (d));

    asm volatile ("fmove%.l %0,fpcr" : : "dmi" (cm));

    return(i);
}

...
    i = fastround(d);
...

Tests on our 25 Mhz 040 show the following results:

i = (int)d;		54 microseconds.
i = irint(d);		 3 microseconds.
i = fastround(d);	 1 microsecond.

If you are always going to round to the nearest, you could set up fpcr and then fastround
would be just 'asm volatile ("fmove%.l %1,%0" : "=d" (i) : "f" (d));'.

It's a good idea to check your compiler's output to see how sin, etc. are being done. You
don't want it to inline the 68881/2 opcodes, since they must be trapped & then passed to the
math library. 

-- 
Richard Neitzel thor@thor.atd.ucar.edu          Torren med sitt skjegg
National Center For Atmospheric Research        lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000	                Gjo'i med sitt shinn
303-497-2057                                    jagar borni inn.