AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070309112838.36c437c8@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<brian.stark@onstor.com>,<warren.gale@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E02C1B3AA@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Mar 2007 11:29:20 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>
Subject: Re: prom 'diskload' command doesn't do what i want
Message-ID: <20070309112920.0663e9da@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E02C1B3AA@onstor-exch02.onstor.net>
References: <20070309105933.56b604a8@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E02C1B3AA@onstor-exch02.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Brian,


So you don't have a board where you can socket the PMC processor with
an LA thingie?  I can make the OS load and run in KSEG1 or 2 or
whatever the uncached segment is to make it load the instructions every
time, but even if I can't, I've dealt with the cache issue before.  I
just have to look at what is on the LA and figure out what instructions
were in that cache line, and what data areas it is fetching cache lines
from, and deduce from that what it "must" be up to. The other thing is
that if it is taking a interrupt or something similary weird, I would
know about that, whereas now I'm just too blind.

I think I figured out last night that it's going off into the weeds
quite early on, and the idea that it's getting a certain way into the
boot process [of the kernel] and then having a problem was just a
mirage.


On Fri, 9 Mar 2007 11:18:30 -0800 "Brian Stark"
<brian.stark@onstor.com> wrote:

> 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 the
> default address.  wd0a is the leftmost CF, wd1a is the rightmost.
> The <image_name> must be located in the / directory of the CF. Here's
> 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                     =C3=87
> disk geometry: cylinders=3D993 heads=3D16 sectors=3D63
> 0x83000000:0x12e980, Zero 0x8312e980:0x2438c0, start at 0x83000080
> usage: diskload
>=20
> 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.
>=20
> As for breakpoints, not sure if the support was ever finished for
> this.  Warren can look into this.
>=20
> 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.
>=20
> 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.
>=20
> As for the JTAG coverage, the PMC has no good tools available like
> the 1250.  Unfortunately, that won't be an option for us.
>=20
>=20
> Brian
>=20
>=20
>=20
> > -----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
