AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090423174734.7f8e5327@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<rendell.fong@onstor.com>,<Bill.Fisher@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB52AC8BC1D4D@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Thu, 23 Apr 2009 17:47:57 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Rendell Fong <rendell.fong@onstor.com>
Cc: Bill Fisher <Bill.Fisher@onstor.com>
Subject: Re: Getting FP loaded/idleing with Linux on TXRX
Message-ID: <20090423174757.599a1f26@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB52AC8BC1D4D@exch1.onstor.net>
References: <49F10557.8080401@onstor.com>
	<2779531E7C760D4491C96305019FEEB52AC8BC1D4D@exch1.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=US-ASCII
Content-Transfer-Encoding: 7bit

All images are loaded by the load_vmlinux program on the ssc or the
prom on the SSC.

The individual prom on each node starts that node running.  After that,
it's a horse race...

So I don't see any good reason to disable starting the other cores on
the FP.  Some other things might need to be disabled...

The shared memory area I know nothing about, and WKA is a mystery
pseudonym for me.  If the FP tries to write to memory that the TUXRX can
see, then it will almost certainly cause TUXRX to have fits.

If we need to set aside some chunk of memory on the tuxrx, then just
let me know how big and if there's a preference on where, otherwise
I'll just take it off the top, which is the easiest.  Minus "the hole"
of course.



On Thu, 23 Apr 2009 17:40:02 -0700 Rendell Fong
<rendell.fong@onstor.com> wrote:

> I managed to create a hacked up FP image that only starts FP0 and does minimal initialization enough to allow it to get to the FP console prompt.  Since the eee communication isn't working and wka hasn't been adjusted appropriately, I've skipped initialization of any code that needs to send msgs and sync with apps running in other cores. 
> 
> It was enough to allow me to test the "crashdump panic" on both fp and tuxrx.  I suppose as more components become operational, it can be added back into the startup.  Is this what you are looking for?
> 
> My workaround code changes are in sm-test/test.c, sm-eee/eee-init.c and sm-eee/eee-platform.c. (~rendellf/dev/nfx-tree/code workspace directory)
> 
> Rendell
> 
> 
> > -----Original Message-----
> > From: Bill Fisher
> > Sent: Thursday, April 23, 2009 5:19 PM
> > To: Andy Sharp
> > Cc: Bill Fisher; Rendell Fong; Maxim Kozlovsky
> > Subject: Re: Getting FP loaded/idleing with Linux on TXRX
> > 
> > Andy Sharp wrote:
> > > Not sure what you're asking.  There's nothing extra to be done on the
> > > tuxrx side to get FP image loaded.  In fact that will happen now unless
> > > you have it commented out like we all do because the FP code is mucking
> > > about in shared memory in a way that bothers Linux and makes it crash.
> > > As you know.
> > >
> > > So what's the question again?
> > >
> > >
> > 	Does it need the Shared memory area allocated AND the WKA set
> > 	correctly and what else? There are lots of calls
> > 	in the initialization code to things that don't exist
> > 	under a linux kernel. The crash dump code, the setup
> > 	for halting the processor's, etc.
> > 
> > 	I don't think it as easy as just loading it, after allocating
> > 	a shared memory region.
> 
