X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C762A7.60C4B12C@onstor-exch02.onstor.net>; Fri, 9 Mar 2007 17:02:22 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: PROM load image comand
Date: Fri, 9 Mar 2007 17:02:20 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B603@onstor-exch02.onstor.net>
In-Reply-To: <20070309153213.77f0636e@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PROM load image comand
Thread-Index: AcdioyrJGoykCgetRMKFVO+AchxMEwAA2HFw
From: "Warren Gale" <warren.gale@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>


Andy,
  Ok, I'm looking but it does not compute. (Sorry)
I can't find anything in the PROM code that has any mention of=20
"PMON Vectors".  Since I don't have any docs on PMON, (that I know of)
do you have some thing that tells me a bit more on this?

Looks like there are some jump tables, is this what it's like?
I'm willing to try anything. (At least once)=20
(I'm really just a diag guy..  single thread bit twiddling stuff)
Thanks,
Warren

-----Original Message-----
From: Andy Sharp=20
Sent: Friday, March 09, 2007 3:32 PM
To: Brian Stark
Cc: Warren Gale
Subject: Re: PROM load image comand

Here is header file from the kernel:

struct callvectors {
	int	(*open) (char*, int, int);
	int	(*close) (int);
	int	(*read) (int, void*, int);
	int	(*write) (int, void*, int);
	off_t	(*lseek) (int, off_t, int);
	int	(*printf) (const char*, ...);
	void	(*cacheflush) (void);
	char*	(*gets) (char*);
	union {
		int	(*smpfork) (unsigned long cp, char *sp);
		int	(*cpustart) (long, long, long, long);
	} _s;
	int	(*semlock) (int sem);
	void	(*semunlock) (int sem);
};


The printf function is the only one I really need, the others you could
just leave as NULL.  Of course, the cpustart function would be good to
play with.

Cheers,

a

On Fri, 9 Mar 2007 15:28:08 -0800 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Andy,
>=20
> I think Warren understands what you're looking for with the PMON call
> vectors since you guys have talked about it, but I don't know if he's
> scoped the work yet.  It really depends on how soon you need
> something.
>=20
>=20
> Brian
>=20
>=20
>=20
> > -----Original Message-----
> > From: Andy Sharp=20
> > Sent: Friday, March 09, 2007 3:17 PM
> > To: Brian Stark
> > Cc: Warren Gale
> > Subject: Re: PROM load image comand
> >=20
> > On Fri, 9 Mar 2007 15:09:49 -0800 "Brian Stark"
> > <brian.stark@onstor.com> wrote:
> >=20
> > Ditto...
> >=20
> > > See below...
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Andy Sharp
> > > > Sent: Friday, March 09, 2007 2:53 PM
> > > > To: Brian Stark
> > > > Cc: Warren Gale
> > > > Subject: Re: PROM load image comand
> > > >=20
> > > > On Fri, 9 Mar 2007 14:40:23 -0800 "Brian Stark"
> > > > <brian.stark@onstor.com> wrote:
> > > >=20
> > > > > Crap, those damn interrupts get me every time.  The 16552
> > > > interrupts
> > > > > are not hooked up to anything because all of the PMC
> > > > interrupts were
> > > > > already taken when the 16552 was added.  Same goes for the
> > > > Marvell GPP
> > > > > pins that could be wired up as interrupt inputs.
> > > >=20
> > > > So use the same int as the mpsc ports on the marvell. =20
> > > > Interrupt sharing is not a problem.  As long as they're "like"=20
> > > > interrupts.
> > >=20
> > >=20
> > > This may be feasible since the interrupts are tri-stated=20
> > when inactive=20
> > > (high).  I could wire up the 16552 interrupt directly to=20
> > the Marvell=20
> > > interrupt output that's used for the BSD mpsc port, which=20
> > looks to be=20
> > > CPU_INT0_L from the Marvell.  Then when this interrupt fires to
> > > the PMC, you'd have to go poll the Marvell cause register and
> > > then the 16552 port to see who generated it.  Is this cool?  If
> > > so,=20
> > I'll look=20
> > > to see what the rework looks like.
> > >=20
> > > Of course, this is only needed if you can't get polling to work.
> > > Software fixes for hardware mistakes are so much fun!
> >=20
> > I'll make you a deal: make me a PROM that gives me the=20
> > standard PMON call vectors and I'll make the polling thing=20
> > work.  Seriously.
> >=20
> > Cheers,
> >=20
> > a
> >=20
