AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090713145130.4a38f649@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<brian.stark@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	102AB4F33EBBDB4C91915B145C8E9FB31377A26A41@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 13 Jul 2009 14:52:37 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Brian Stark <brian.stark@onstor.com>
Subject: Re: please review 32863
Message-ID: <20090713145237.58e42860@ripper.onstor.net>
In-Reply-To: <102AB4F33EBBDB4C91915B145C8E9FB31377A26A41@exch1.onstor.net>
References: <20090713112541.61691454@ripper.onstor.net>
	<102AB4F33EBBDB4C91915B145C8E9FB31377A26A05@exch1.onstor.net>
	<20090713135033.48afc188@ripper.onstor.net>
	<102AB4F33EBBDB4C91915B145C8E9FB31377A26A41@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

On Mon, 13 Jul 2009 14:41:24 -0700 Brian Stark <brian.stark@onstor.com>
wrote:

> OK, I've made the changes that you suggested, so take a look again.
> Also, see below for some comments...
> 
> 
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Monday, July 13, 2009 1:51 PM
> To: Brian Stark
> Subject: Re: please review 32863
> 
> On Mon, 13 Jul 2009 11:51:08 -0700 Brian Stark
> <brian.stark@onstor.com> wrote:
> 
> > I already made the changes to use the "user" autoload variable and
> > put them into a pending changelist that I have for a few other
> > things.  Can you just review changelist 32740?  I've tested these
> > changes and know that it will work in the Ops mfg flow.
> > 
> > 
> > 
> > Change 32740 by brians@brians on 2009/06/24 15:32:44 *pending*
> > 
> >         Remove memory speed limitation in changelist 31667.  Add TLB
> > and diag memory test support for 2GB modules.  Change autoload
> > variable to (off on user) where 'on' maintains the serial
> > autoloading from the SSC and 'user' loads the FP and TXRX using a
> > Linux userspace program.
> > 
> >         Reviewed by
> > 
> > Affected files ...
> > 
> > ... //depot/dev/prom/cg/code/prom-pmon/memtst.c#12 edit
> > ... //depot/dev/prom/cg/code/prom-sibyte-init/bcm1480_draminit.c#6
> > edit ... //depot/dev/prom/cg/code/sm-loader/load-auto.c#9 edit
> > ... //depot/dev/prom/cg/code/sm-sb1480/tlb.c#8 edit
> > ... //depot/dev/prom/cg/code/sm-seep/env.c#7 edit
> 
> 
> = Change 32740 by brians@brians on 2009/06/24 15:32:44 *pending*
> = 
> = 	Remove memory speed limitation in changelist 31667.  Add
> TLB and diag memory test support for 2GB modules.  Change autoload
> variable to (off on user) where 'on' maintains the serial autoloading
> from the SSC and 'user' loads the FP and TXRX using a Linux userspace
> program. = = 	Reviewed by = 
> 
> 
> Wrap your comment (instead of one long line) and trailing whitespace
> ~:^)
> 
> 
> Blame this on p4v.

A poor workman....

Simple:

$ p4 change 32740

<put cursor on line where comment starts>

type "!!fmt" followed by return.  no, don't type the quotes.

write buffer out and exit ("ZZ")

problem solved!

I leave the problem of fixing the trailing whitespace to the user as an
exercise.


> prom/cg/code/prom-pmon/memtst.c
> 
>      line 1252,1338 comments, please: what are these magic numbers?
>      are they related to the magic numbers on the previous line?
>      one hates to have to guess...
> 
> Added comments.
> 
> 
>      line 1358 fix comments; maybe even add a comment around 1374
>      about what the 0x100000000 means...
> 
> Added comments.  Come on, it's not like I wrote these comments.
> These were there from previous contributors who shall remain nameless.

My bad.  The correct convention in situations like this is to say
"Could I impose upon you to ..." because -nobody- likes to get blamed
for someone else's bad code/comments/style, etc.

> 
> prom/cg/code/prom-sibyte-init/bcm1480_draminit.c
> 
>      line 194 do we really need 3 different macros that all evaluate
>      to exactly the same thing?
> 
> Yes, we need the MC0 and MC1 macros that I added.  This gives the
> flexibility of having different settings per memory controller.  We
> could remove the DEFAULT macro if you think that's necessary.

Your choice.

>      line 1300 delete #if 0 block
> 
> Done
> 
>      line 1305 uh, really?  since these macros are the same, can't we
>      just do
> 
>      mc->drvcfg = V_MC_DRVCONFIG_CLASS_DEFAULT |
> M_BCM1480_MC_DQS_DIFF;
> 
> No, I want to keep the flexibility of having different settings per
> MC as noted above.  That's not how it is now, but it could be in the
> future.
> 
> 
>      line 2145 what use is the #ifdef AGILE_HARDWARE ?
> 
> None really.  I guess this is a relic of wrapping CFE memory
> controller init into our PROM.  Since we're not building for
> CFE-based boards anymore, I can remove this #ifdef.
> 
> 
> 
> 
> prom/cg/code/sm-loader/load-auto.c
> 
>      looks good
> 
> prom/cg/code/sm-sb1480/tlb.c
> 
>      line 188, 303  will it really be both greater than 3 and less
>      than 4?  shouldn't that be <= 4?
> 
> Sure, that's fine.  
> 
>      block starting at 192, looks whacky to me, sending to rendell
>      for confirmation
> 
> OK, let me know if Rendell says anything on this.  Like you guys even
> know what a TLB is.

Hmm, maybe Rendell has.


> prom/cg/code/sm-seep/env.c
> 
>      ok
> 
> 
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Monday, July 13, 2009 11:26 AM
> > To: Brian Stark
> > Subject: please review 32863
> > 
> > Hi Brian,
> > 
> > In these changes you can see the default value is set to "user" but
> > I'm not totally sure about that one.  I don't know what default
> > value means in the sense that is this was is programmed into the
> > variable by ops, or is that independent of the so-called "default
> > value"?
> > 
> > I'm having trouble with perforce right now, or I'd queue up all the
> > change lists that need to be integrated from dev to rel402 and get
> > the ball rolling on getting those approved by Ed.
> > 
> > 
> > 
> > Change 32863 by andys@ripper on 2009/07/13 10:17:52 *pending*
> > 
> > 	Change the third value of autoload PROM env variable to
> > 	"user" instead of "old", and switch the logic to mean the
> > old "prom-all-the-way" image loading method will be invoked when
> > the variable is set to "on" and the new user-space loading method
> > 	will be invoked when the variable is set to "user".
> > 
> > 	This gives us independence from any particular run-time
> > version so PROMs can be upgraded w/o also having to upgrade the
> > runtime, and vice versa.
> > 
> > 	Reviewed by
> > 
> > Affected files ...
> > 
> > ... //depot/dev/prom/cg/code/sm-loader/load-auto.c#9 edit
> > ... //depot/dev/prom/cg/code/sm-seep/env.c#7 edit
> > 
