X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C762A0.09A6FF91@onstor-exch02.onstor.net>; Fri, 9 Mar 2007 16:09:49 -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 16:09:49 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B576@onstor-exch02.onstor.net>
In-Reply-To: <20070309145306.2c57fe0e@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: PROM load image comand
Thread-Index: AcdinbOVdXSTGsRwR+OyksI4CNaf+gAAGMMg
References: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B4BC@onstor-exch02.onstor.net><20070309141540.7b395cb2@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E02C1B51F@onstor-exch02.onstor.net> <20070309145306.2c57fe0e@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>

See below...


> -----Original Message-----
> From: Andy Sharp=20
> 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=20
> interrupts=20
> > are not hooked up to anything because all of the PMC=20
> interrupts were=20
> > already taken when the 16552 was added.  Same goes for the=20
> Marvell GPP=20
> > 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=20
> "like" interrupts.


This may be feasible since the interrupts are tri-stated when inactive
(high).  I could wire up the 16552 interrupt directly to the Marvell
interrupt output that's used for the BSD mpsc port, which looks to be
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, I'll look to see what
the rework looks like.

Of course, this is only needed if you can't get polling to work.
Software fixes for hardware mistakes are so much fun!
=20



> > Can you poll the UART to see if characters have been=20
> received?  Maybe=20
> > this would work until the Marvell UART is going.
> >=20
> > A word of caution on the RTC.  Because of the way the Marvell part=20
> > addresses devices on its device bus, the RTC is addressed on=20
> > double-word boundaries:
> >=20
> > CPU address		RTC reg
> > 1f00.0000		0
> > 1f00.0008		1
> > 1f00.0010		2
> > 1f00.0018		3
> > ...
> >=20
> > So, you gotta do byte reads to double-word addresses.  I know this=20
> > ain't ideal, but blame the Marvell part.
>=20
> Oh crap, I hope that doesn't mean a custom driver.  You know=20
> how I am about writing code.
>=20
> I probably can write a quick hack of an early console driver=20
> that does some horribly patheticly simple output routine, and=20
> screw even doing an input routine.  But first I will see if=20
> the standard driver is smart enough to just figure out that=20
> no specified interrupt means that it has to poll.  The=20
> regular driver might do that, but the early console driver=20
> might not be that versatile.  It might require a polling=20
> thread, and the kernel isn't sufficiently started enough to=20
> handle threads and scheduling and such.  But you never know.
>=20
> Thanks,
>=20
> a
>=20
