AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20080722115344.3b82a3e4@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<jonathan.goldick@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	BB375AF679D4A34E9CA8DFA650E2B04E0AFF1D99@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 22 Jul 2008 11:54:22 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>
Subject: Re: Please respond
Message-ID: <20080722115422.0aaba05b@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0AFF1D99@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0AFF1D18@onstor-exch02.onstor.net>
	<20080722113833.346dfc10@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0AFF1D99@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=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue, 22 Jul 2008 11:50:13 -0700 "Jonathan Goldick"
<jonathan.goldick@onstor.com> wrote:

> Is there any header file that is currently included by linux, eee, and
> Prom?
> 
> I need an example so we don't get screwed up build dependencies.

That one you mentioned that is actually duplicated (and different?) is
the only one that's close.  If you want to use that one, be my guest.

> -----Original Message-----
> From: Andy Sharp 
> Sent: Tuesday, July 22, 2008 11:39 AM
> To: Jonathan Goldick
> Subject: Re: Please respond
> 
> Can EEE and PROM use
> linux/kernel/linux-mips-2.6/drivers/ssc-mgmt-bus/models.h
> ?  If so, then let's put it there.
> 
> On Tue, 22 Jul 2008 11:01:38 -0700 "Jonathan Goldick"
> <jonathan.goldick@onstor.com> wrote:
> 
> > I still need a location for these definitions that is shared between
> > EEE, Linux, and PROM.  Can you please answer this ASAP.  
> > 
> > 
> > 
> > -----Original Message-----
> > From: Jonathan Goldick 
> > Sent: Tuesday, July 22, 2008 9:07 AM
> > To: Brian Stark; Warren Gale; Andy Sharp
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > Good catch.
> > 
> > 
> > -----Original Message-----
> > From: Brian Stark 
> > Sent: Monday, July 21, 2008 11:12 PM
> > To: Jonathan Goldick; Warren Gale; Andy Sharp
> > Subject: Re: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > The 35xx models are 10, not 20.  This indicates 1 blade instead of
> > 2...
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Jonathan Goldick
> > To: Warren Gale; Brian Stark; Andy Sharp
> > Sent: Mon Jul 21 20:00:59 2008
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > If there are more specific text strings, I will use them.  
> > If you are using "ONS-SYS-6720"  then send me that.  Basically I
> > want to use symbols from a common header file.  If you want to use a
> > different string and symbol name, please feel free to do so.
> > 
> > #define COUGAR_MODEL_3520 "ONS-SYS-3520"
> > #define COUGAR_MODEL_3720 "ONS-SYS-3720"
> > #define COUGAR_MODEL_6520 "ONS-SYS-6520"
> > #define COUGAR_MODEL_6720 "ONS-SYS-6720"
> > #define COUGAR_MODEL_6920 "ONS-SYS-6920"
> > 
> > -----Original Message-----
> > From: Warren Gale 
> > Sent: Monday, July 21, 2008 7:26 PM
> > To: Jonathan Goldick; Brian Stark; Andy Sharp
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > So that I'm clear on this, when I read seepPCB_t model_num,
> > and I get "ONS-SYS-6720",  you want me to send the string
> > "ONS-SYS-6700" in as an arg to linux ??  right?
> > 
> > 
> > 
> > -----Original Message-----
> > From: Jonathan Goldick 
> > Sent: Monday, July 21, 2008 3:22 PM
> > To: Warren Gale; Brian Stark; Andy Sharp
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > Let's get all of the model strings in a header file that is shared
> > for PROM and nfx-tree.
> > 
> > These are the symbols I will be using.
> > 
> > #define COUGAR_MODEL_3500 "ONS-SYS-3500"
> > #define COUGAR_MODEL_3700 "ONS-SYS-3700"
> > #define COUGAR_MODEL_6500 "ONS-SYS-6500"
> > #define COUGAR_MODEL_6700 "ONS-SYS-6700"
> > #define COUGAR_MODEL_6900 "ONS-SYS-6900"
> > 
> > 
> > -----Original Message-----
> > From: Warren Gale 
> > Sent: Monday, July 21, 2008 2:42 PM
> > To: Jonathan Goldick; Brian Stark; Andy Sharp
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > 
> > I'll get started on the PROM work.
> > 
> > Problem with the expected strings:
> > ICT is programming the "seepPCB_t"   "model_num" with
> > the following:
> >   "ONS-SYS-6520"
> >   "ONS-SYS-6720"
> >   "ONS-SYS-6920"
> > 
> > Don't know about the "35xx" or "37xx"
> > 
> > Warren
> > 
> > 
> > -----Original Message-----
> > From: Jonathan Goldick 
> > Sent: Monday, July 21, 2008 1:22 PM
> > To: Brian Stark; Warren Gale; Andy Sharp
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > Agreed.
> > 
> > So, we need to nail down the prom work and let everyone know that
> > there will be a 1.8 prom.  
> > 
> > Just to be clear, I expect that we will be using the following
> > strings:
> > 
> > ONS-SYS-6500 -- 8GB memory, 3 FP cores
> > ONS-SYS-6700 -- 8GB memory, 4 FP cores
> > ONS-SYS-6900 -- 12 or 16GB memory, 4 FP cores
> > ONS-SYS-3500 -- 8GB memory, 3 FP cores
> > ONS-SYS-3700 -- 8GB memory, 4 FP cores
> > 
> > I also expect the strings above to be written to the seepPCB_t
> > structure sub-field 
> > 	uchar8	model_num[SEEP_PCB_MODEL_LEN]; 	// 16
> > 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Brian Stark 
> > Sent: Monday, July 21, 2008 12:08 PM
> > To: Jonathan Goldick; Warren Gale; Andy Sharp
> > Subject: Re: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > Better do it up front.  We are definitely selling the 6520 and need
> > to distinguish from the 6720...
> > 
> > 
> > 
> > ----- Original Message -----
> > From: Jonathan Goldick
> > To: Warren Gale; Andy Sharp
> > Cc: Brian Stark
> > Sent: Mon Jul 21 11:36:08 2008
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > I was trying to avoid a prom upgrade but I need to get the number of
> > cores we want to enabled to the EEE layer somehow at boot.  I have
> > no particular preferences, I want this to be the minimum effort so
> > that we can really sell the variants we just announced.
> > 
> > 
> > 
> > FYI: I do not believe that we can just have a model string without
> > disabling a core and handle this in a future software release
> > because customers will scream if a software upgrade makes the
> > machine slower and the number of cores decrease.  We either need to
> > do this right up front or not sell the 6520.
> > 
> > 
> > 
> > -----Original Message-----
> > From: Warren Gale 
> > Sent: Monday, July 21, 2008 11:31 AM
> > To: Andy Sharp; Jonathan Goldick
> > Cc: Brian Stark
> > Subject: RE: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > If you want the PROM to pass it in, that's Ok with me.
> > This would require a PROM upgrade for all systems. 
> > 
> > PROM "read seep" are I2C functions to get the data, so it's not
> > just a simple read memory to get the info.
> > 
> > PROM does pass in a string that I believe is not used "ip-none".
> > Do you want the kernel guessing?
> > 
> > 
> > Here is what is passed in:
> > 
> > <<<<< screen dump from my cougar >>>>>>>>>
> > 
> > env[0] = 0xffffffff80b8fe48:.cpuclock=4894967296.
> > env[1] = 0xffffffff80b8fe98:.memsize=512.
> > env[2] = 0xffffffff80b8fee8:.osloadoptions=mAt.
> > env[3] = 0xffffffff80b8ff38:.boot=cold.
> > env[4] = 0xffffffff80b8ff88:.busclock=600.
> > env[5] = 0xffffffff80b8ffd8:.ipaddr=10.1.1.109.
> > env[6] = 0xffffffff80b90028:.netmask=255.255.0.0.
> > env[7] = 0xffffffff80b90078:.macaddr0=.00:07:34:10:14:00.
> > env[8] = 0xffffffff80b900c8:.macaddr1=.00:07:34:10:14:01.
> > env[9] = 0xffffffff80b90118:.bootdev=/dev/sdb1.
> >  Load options and params for [g]
> >   Address 0xffffffff82000000 argc = 5
> >    argv [0] = g
> >    argv [1] = root=/dev/sdb1
> >    argv [2] = ip=none
> >    argv [3] = rootdelay=1
> >    argv [4] = NULL
> > 
> > 
> > Warren
> > 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Monday, July 21, 2008 10:38 AM
> > To: Jonathan Goldick
> > Cc: Warren Gale; Brian Stark
> > Subject: Re: need to get the cougar model information into the Linux
> > kernel from Prom
> > 
> > On Mon, 21 Jul 2008 10:17:56 -0700 "Jonathan Goldick"
> > <jonathan.goldick@onstor.com> wrote:
> > 
> > > 	 <<Cougar configurations>> 
> > > 
> > > I have done the work on the EEE layer but need to get cpu count
> > > (based on model information in the SSC SEEP)  into the Linux
> > > kernel since I'm piggy-backing the information on the mgmt bus
> > > initialization (Mgmtbus_softc.ring_config ) rather than create an
> > > entirely new method of getting the SEEP information from the SSC
> > > to the EEE.  By putting this new information into the same region
> > > of memory as the mgmt bus information the code is pretty simple
> > > and can be tested quickly.
> > > 
> > > Now that you have context, I need to get the information from the
> > > SSC SEEP into the Mgmtbus_softc.ring_config data structure.  I
> > > have the option of trying to read the SEEP from kernel space or
> > > much better have the PROM hand it off the to kernel at init time
> > > as it does with other pieces of information.
> > > 
> > > Any suggestions on how we could get this done quickly and easily?
> > 
> > Not without changing the PROM and the kernel ~:^)
> > 
> > Changing just the kernel to read the seep should be trivial, unless
> > there is some uber-trick involved.  It is just reading memory
> > addresses, no?  Or perhaps some simple setup and then read memory
> > addresses?  I could stick it in the cougar platform code pretty
> > easily, or the management bus driver init routine as well.  Or, if
> > the PROM already sets one of the boot variables differently, the
> > kernel could just "guess" from that, since the numbers will be
> > fixed?
> > 
> > Warren?
> > 
