AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090109171348.6f70f74c@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:exch1.onstor.net
NSV:
SSH:
R:<larry.scheer@onstor.com>,<brian.stark@onstor.com>,<rendell.fong@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	2779531E7C760D4491C96305019FEEB51762F6E108@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 9 Jan 2009 17:15:10 -0800
From: Andrew Sharp <andy.sharp@onstor.com>
To: Larry Scheer <larry.scheer@onstor.com>
Cc: Brian Stark <brian.stark@onstor.com>, Rendell Fong
 <rendell.fong@onstor.com>
Subject: Re: please review 31461
Message-ID: <20090109171510.1390b3ac@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB51762F6E108@exch1.onstor.net>
References: <20090109105143.4334be2c@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB51762F6E108@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 Fri, 9 Jan 2009 15:21:59 -0800 Larry Scheer
<larry.scheer@onstor.com> wrote:

> My comments about the Makefiles are below. I trust you will get Bill
> or someone who knows the prom code to review your C code changes. A
> quick scan of it looked good to me. But I don't know what the prom
> code should be doing when or where or to whom.

Thanks, that's just what I wanted.  I will have to wait for vacationing
Rendell, but no big deal there.

> Just an observation, Bill was going through hell trying to get the
> prom to boot something other than vmlinux.bin. I seem to remember
> being able to boot a bsd/linux kernel on a bobcat by specifying load
> -a 82000000 /dev/wd0a/filename. I hope that capability exist with
> your changes.

Bill's problems were due to

TED00026011 	can't load kernel from second CF card (sdb1) 

Which is partially fixed by this because I fixed the bare (no
arguments) diskload command to observe the setting of the boot_dev
environment variable which it should have from the get-go.  It works to
load the kernel from sdb1 under those circumstances, however I have no
reason to think that the use case outlined in that bug is now suddenly
working.

> linux/Makefile
> 
>      looks good
> 
> linux/rootfs/Makefile
> 
>      While you have this file open do you mind bumping the copyright
>      year to 2009?  Just asking...
> 
>      Looks OK
> 
> linux/rootfs/etc/init.d/rcS
> 
>      looks good
> 
> linux/tools/Makefile
> 
>      >>add linux/tools/Makefile
> 
>      Need an addition/change to the $(LINKS): rule.
> 
>      Need to use the '-f' flag with ln -s to remove the existing
>      destination file or add the following abover the cd $(@D)
>         @[ -h $@ ] && rm -rf $@ || true
> 
>      I have seen the -f flag to ln not work or produce a Make error
>      on some systems.  You can add it and see if the build ever fails.
> 
>      Using the test for the link and rm has the funny || true business
>      because make might produce an error because the status result
>      of [ -h $@ ] && <cmd> is 1 if the link doesn't exist so the ||
>      true appeases make.
> 
> linux/tools/load_vmlinux.c
> 
>      >>add linux/tools/load_vmlinux.c
> 
> nfx-tree/linux.mk
> 
>      looks good
> 
> -----Original Message-----
> From: Andy Sharp 
> Sent: Friday, January 09, 2009 10:52 AM
> To: Brian Stark
> Cc: Rendell Fong; Larry Scheer
> Subject: please review 31461
> 
> Change 31461 by andys@ripper on 2008/12/12 17:18:34 *pending*
> 
> 	Change the default image loading algorithm from the PROM
> loading all the images at a snail's pace, to loading just the Linux
> 	kernel on the SSC, and then the TXRX and FP images are loaded
> by new userspace Linux program at 5x the speed.  Results in sub 1
> 	minute boot times on production builds.  User space load
> program is compatible with old proms and will not try to load an
> already loaded image.
> 
> 	This only affects the "autoload" behavior on the SSC.  The old
> 	behavior is still available via the new command
> "old_autoload".
> 
> 	The image loading program does not do TFTP image loading;
> 	however, this hardly matters, as a developer can have a remote
> 	directory NFS mounted and have the boot image loaded that way.
> 	In other words, TFTP isn't needed.
> 
> 	Other general PROM fixing goodness:
> 
> 	Fix annoyance where bare "diskload" command loaded the kernel
> 	from the first compact flash regardless of what the boot_dev
> 	environment variable was set to.
> 
> 	Fix annoyance where the diskload command required you to also
> 	specify the load address if you wanted to specify the file
> name to load.  Load address should be able to use a default just like
> 	everything else in this world.
> 
> 	Remove a tiny bit of the massive amount of dead code.
> 
> 	Makefiles by Larry.
> 
> 	reviewed by
> 
> Affected files ...
> 
> ... //depot/dev/linux/Makefile#1 edit
> ... //depot/dev/linux/rootfs/Makefile#41 edit
> ... //depot/dev/linux/rootfs/etc/init.d/rcS#9 edit
> ... //depot/dev/linux/tools/Makefile#1 add
> ... //depot/dev/linux/tools/load_vmlinux.c#1 add
> ... //depot/dev/nfx-tree/linux.mk#4 edit
> ... //depot/dev/prom/cg/code/prom-decompress/makerom.c#3 edit
> ... //depot/dev/prom/cg/code/prom-pmon/cmdtable.c#13 edit
> ... //depot/dev/prom/cg/code/prom-pmon/main.c#13 edit
> ... //depot/dev/prom/cg/code/sm-chassis/cm-api.c#1 edit
> ... //depot/dev/prom/cg/code/sm-loader/load-auto.c#6 edit
> ... //depot/dev/prom/cg/code/sm-loader/load-cougar-diag-util.c#12 edit
> ... //depot/dev/prom/cg/code/sm-loader/load-cougar.c#11 edit
> ... //depot/dev/prom/cg/code/sm-loader/load-cougar.h#2 edit
> ... //depot/dev/prom/cg/code/sm-pmondisk/Makefile#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/dinode.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/dir.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/disk.c#2 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/disk.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/diskio.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/diskio.h#2 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/disklabel.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/dkbad.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/exec_elf.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/filesystem.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/fs.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/i82365reg.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/lseek.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/mips_disklabel.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/open.c#2 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/pcmcia.c#2 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/pcmciareg.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/pcmciavar.h#2 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/pmondisk.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/queue.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/read.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/ufs.c#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/ufs.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmondisk/wdcreg.h#1 delete
> ... //depot/dev/prom/cg/code/sm-pmonext2fs/disk.c#3 edit
> ... //depot/dev/prom/cg/code/sm-ui/cli.c#1 edit
> 
