X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C76297.DD2B52B8@onstor-exch02.onstor.net>; Fri, 9 Mar 2007 15:11:19 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: prom 'diskload' command doesn't do what i want
Date: Fri, 9 Mar 2007 15:11:18 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B4CF@onstor-exch02.onstor.net>
In-Reply-To: <20070309112920.0663e9da@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: prom 'diskload' command doesn't do what i want
Thread-Index: AcdigTx/EgkKPwmvSEyet2chY0BSOAAFp3Fg
References: <20070309105933.56b604a8@ripper.onstor.net><BB375AF679D4A34E9CA8DFA650E2B04E02C1B3AA@onstor-exch02.onstor.net> <20070309112920.0663e9da@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>

Andy,

We didn't have room on the board to accommodate a socket for the PMC =
part because it required mounting holes.  Same goes for LA coverage on =
the memory.  That was one of the compromises we had to make early on to =
get everything to fit.  As is usually the case, debugability is the =
first thing to go when things don't fit.  I don't know if debugability =
is a word, but you know what I mean.

Agree that you can deal with the cache issue, but to have complete =
visibility, the best approach is to run uncached.  I think the other =
runtimes have a #define that could be changed to do this, but then =
again, you're talking to a hardware guy about software.  Not sure if =
this would be the case with the OS.


Brian
=20

> -----Original Message-----
> From: Andy Sharp=20
> Sent: Friday, March 09, 2007 11:29 AM
> To: Brian Stark
> Cc: Warren Gale
> Subject: Re: prom 'diskload' command doesn't do what i want
>=20
> Hi Brian,
>=20
>=20
> So you don't have a board where you can socket the PMC=20
> processor with an LA thingie?  I can make the OS load and run=20
> in KSEG1 or 2 or whatever the uncached segment is to make it=20
> load the instructions every time, but even if I can't, I've=20
> dealt with the cache issue before.  I just have to look at=20
> what is on the LA and figure out what instructions were in=20
> that cache line, and what data areas it is fetching cache=20
> lines from, and deduce from that what it "must" be up to. The=20
> other thing is that if it is taking a interrupt or something=20
> similary weird, I would know about that, whereas now I'm just=20
> too blind.
>=20
> I think I figured out last night that it's going off into the=20
> weeds quite early on, and the idea that it's getting a=20
> certain way into the boot process [of the kernel] and then=20
> having a problem was just a mirage.
>=20
>=20
> On Fri, 9 Mar 2007 11:18:30 -0800 "Brian Stark"
> <brian.stark@onstor.com> wrote:
>=20
> > Andy,
> >=20
> > Here's the syntax of the command:
> >=20
> > diskload -a <load_address> /dev/<wd0a,wd1a>/<image_name>
> >=20
> > load_address is typically '83000000' for bsd, which may be=20
> the default=20
> > address.  wd0a is the leftmost CF, wd1a is the rightmost.
> > The <image_name> must be located in the / directory of the=20
> CF. Here's=20
> > an example from my filer:
> >=20
> > SSC-PROM> diskload -a 83000000 /dev/wd0a/bsd
> > Loading file /dev/wd0a/bsd at 83000000...
> > SOCKET A: CIS info: TOSHIBA THNCF512MDG , , ,
> > disk model: TOSHIBA THNCF512MDG                     =C7
> > disk geometry: cylinders=3D993 heads=3D16 sectors=3D63=20
> 0x83000000:0x12e980,=20
> > Zero 0x8312e980:0x2438c0, start at 0x83000080
> > usage: diskload
> >=20
> > This is essentially what autoload does for each of the=20
> runtime images. =20
> > It knows the load_address based on the runtime image that's being=20
> > loaded and gets the primary CF info from the boot_dev environment=20
> > variable.
> >=20
> > As for breakpoints, not sure if the support was ever finished for=20
> > this.  Warren can look into this.
> >=20
> > As for the logic analyzer support, I can help you out here,=20
> but there=20
> > are a few caveats.  First, we don't have good debug coverage on the=20
> > local PMC memory because you can't put analyzer coverage onto=20
> > high-speed interfaces without affecting signal integrity.  Second,=20
> > since instructions are cached and typically don't miss, you=20
> won't see=20
> > instruction execution on an external bus.
> >=20
> > To get around this, we would need to do the following --=20
> first, build=20
> > a special version of Linux that uses Marvell memory since the SysAD=20
> > link between the PMC and Marvell does have logic analyzer coverage.
> > Second, make all instruction fetches uncached so that we=20
> can observe=20
> > what's going on with the analyzer.  Not sure how easy or=20
> feasible this=20
> > is with the OS, but we've done this with the other embedded=20
> runtimes.
> >=20
> > As for the JTAG coverage, the PMC has no good tools=20
> available like the=20
> > 1250.  Unfortunately, that won't be an option for us.
> >=20
> >=20
> > Brian
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Andy Sharp
> > > Sent: Friday, March 09, 2007 11:00 AM
> > > To: Warren Gale
> > > Cc: Brian Stark
> > > Subject: prom 'diskload' command doesn't do what i want
> > >=20
> > > Hi Warren,
> > >=20
> > > Soooo, I discovered the 'diskload' command, but it=20
> doesn't seem to=20
> > > like me.  When I give it a file name, it seems to try and do=20
> > > something, but then says this:
> > >=20
> > > SSC-PROM> diskload vmlinux.bobcat
> > > Loading file vmlinux.bobcat...
> > > SOCKET B: CIS info: , ,
> > > open err: vmlinux.bobcat
> > > usage: diskload
> > > SSC-PROM>
> > >=20
> > > Am I using the command wrong?  Do I need a special file=20
> spec syntax?
> > >=20
> > > I tried to use the breakpoint command of the PROM but it said it=20
> > > isn't available or something like that.  Is it possible=20
> to build a=20
> > > version of the PROM with that enabled?
> > >=20
> > > Do you guys have an LA up there our a JTAG setup or=20
> something?  I'm=20
> > > really struggling to figure out where Linux is jumping the tracks.
> > >=20
> > > a
> > >=20
>=20
