X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7627F.B8D67233@onstor-exch02.onstor.net>; Fri, 9 Mar 2007 12:18:30 -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 12:18:30 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B3AA@onstor-exch02.onstor.net>
In-Reply-To: <20070309105933.56b604a8@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: prom 'diskload' command doesn't do what i want
Thread-Index: AcdifROoi19iq6GDRU+NwfCePnvqzgAABdOg
References: <20070309105933.56b604a8@ripper.onstor.net>
From: "Brian Stark" <brian.stark@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Warren Gale" <warren.gale@onstor.com>

Andy,

Here's the syntax of the command:

diskload -a <load_address> /dev/<wd0a,wd1a>/<image_name>

load_address is typically '83000000' for bsd, which may be the default =
address.  wd0a is the leftmost CF, wd1a is the rightmost.  The =
<image_name> must be located in the / directory of the CF.
=20
Here's an example from my filer:

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
0x83000000:0x12e980, Zero 0x8312e980:0x2438c0, start at 0x83000080
usage: diskload

This is essentially what autoload does for each of the runtime images.  =
It knows the load_address based on the runtime image that's being loaded =
and gets the primary CF info from the boot_dev environment variable.

As for breakpoints, not sure if the support was ever finished for this.  =
Warren can look into this.

As for the logic analyzer support, I can help you out here, but there =
are a few caveats.  First, we don't have good debug coverage on the =
local PMC memory because you can't put analyzer coverage onto high-speed =
interfaces without affecting signal integrity.  Second, since =
instructions are cached and typically don't miss, you won't see =
instruction execution on an external bus.

To get around this, we would need to do the following -- first, build a =
special version of Linux that uses Marvell memory since the SysAD link =
between the PMC and Marvell does have logic analyzer coverage.  Second, =
make all instruction fetches uncached so that we can observe what's =
going on with the analyzer.  Not sure how easy or feasible this is with =
the OS, but we've done this with the other embedded runtimes.

As for the JTAG coverage, the PMC has no good tools available like the =
1250.  Unfortunately, that won't be an option for us.


Brian



> -----Original Message-----
> From: Andy Sharp=20
> 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 doesn't=20
> seem to like me.  When I give it a file name, it seems to try=20
> and do 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 spec syntax?
>=20
> I tried to use the breakpoint command of the PROM but it said=20
> it isn't available or something like that.  Is it possible to=20
> build a 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 really struggling to figure out where Linux=20
> is jumping the tracks.
>=20
> a
>=20
