AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.onstor.net
NSV:
SSH:
R:<jonathan.goldick@onstor.com>,<warren.gale@onstor.com>,<brian.stark@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	BB375AF679D4A34E9CA8DFA650E2B04E0AFF182B@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 21 Jul 2008 11:52:49 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Jonathan Goldick" <jonathan.goldick@onstor.com>
Cc: "Warren Gale" <warren.gale@onstor.com>, "Brian Stark"
 <brian.stark@onstor.com>
Subject: Re: need to get the cougar model information into the Linux kernel
 from Prom
Message-ID: <20080721115249.3a1d9a29@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0AFF182B@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E0AFF17A9@onstor-exch02.onstor.net>
	<20080721103732.14a6a9d9@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0AFF1825@onstor-exch02.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E0AFF182B@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

Let's have a confab on this.  I don't believe reading seep (i2c) should
be a problem.  If it is read at the userspace level can that be sent to
the FP at, say, daemon intialization time?

On Mon, 21 Jul 2008 11:36:08 -0700 "Jonathan Goldick"
<jonathan.goldick@onstor.com> wrote:

> 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?
> 
