AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20070925112535.7629010c@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:onstor-exch02.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@onstor-exch02.onstor.net/INBOX	0	BB375AF679D4A34E9CA8DFA650E2B04E05B4680F@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Tue, 25 Sep 2007 11:25:45 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: CF accesses in PROM
Message-ID: <20070925112545.2fec8235@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E05B4680F@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05A25BE9@onstor-exch02.onstor.net>
	<20070923111859.4207ba6f@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E05A25C6B@onstor-exch02.onstor.net>
	<20070923231155.5ac105d0@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E05B4618E@onstor-exch02.onstor.net>
	<20070925104905.616d2597@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E05B4680F@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

OK, it eventually loaded, apparently it takes like an hour.

But it crashed and burned pretty good when it ran:

SSC-PROM> g                          
RUN        
This kernel optimized for ONStor Cougar board without CFE
Determined physical RAM map:
 memory: 0000000010000000 @ 0000000000000000 (usable)
 memory: 0000000010000000 @ 0000000080000000 (usable)
Built 1 zonelists.  Total pages: 581760
Kernel command line: console=duart0,57600n8 root=/dev/nfs nfsroot=10.0.0.42:/var/nfsroot/cougar,v3,tcp ip=10.1.1.121:10.0.0.42:10.1.1.1:255.255.255.0:couglette:eth0:none -s
Primary instruction cache 32kB, 4-way, linesize 32 bytes.
Primary data cache 32kB, 4-way, linesize 32 bytes.
Synthesized TLB refill handler (42 instructions).
Synthesized TLB load handler fastpath (53 instructions).
Synthesized TLB store handler fastpath (48 instructions).
Synthesized TLB modify handler fastpath (47 instructions).
PID hash table entries: 4096 (order: 12, 32768 bytes)
Using 1.000 MHz high precision timer.
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Memory: 433408k/524288k available (2100k kernel code, 90764k reserved, 656k data, 104k init, 0k highmem)
Mount-cache hash table entries: 256
Checking for the multiply/shift bug... no.
Checking for the daddi bug... no.
Checking for the daddiu bug... no.
NET: Registered protocol family 16
registering PCI controller with io_map_base unset
board earlyinitsb1250_cpuinitsb1250_dram_initdecompresscache flushcache invalidatecache flush DcoherentDONESBDMUARTDCMPCREGDBGI top

I don't know what the last line is about, various symbol data mushed
together.  Could be some bug of mine.  I'll try the other cougar.



On Tue, 25 Sep 2007 11:06:22 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Try another Cougar that has an older PROM with no CF support yet.  You
> still need to hit 'b' with this board:
> 
> SSC 10.1.1.100 2015
> Power 10.1.1.102 port .a3
> 
> We were having some networking issues earlier today, so maybe that's
> what you were seeing.  Let me know how it looks.
> 
> 
> Brian
> 
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Tuesday, September 25, 2007 10:49 AM
> > To: Brian Stark
> > Subject: Re: CF accesses in PROM
> > 
> > Hmm. I may not have to hit 'b' anymore, but I can't load a 
> > kernel either.  The load command just keeps spinning its 
> > spinner and never completes.  Also, I don't notice any 
> > appreciable network I/O to the tftp server either.  It might 
> > just be a few bytes per second, but not the previous 100KB/s or so.
> > 
> > 
> > On Mon, 24 Sep 2007 11:08:32 -0700 "Brian Stark"
> > <brian.stark@onstor.com> wrote:
> > 
> > > Andy,
> > > 
> > > Your system is back up and is powered on.  I had a temporary
> > > mental lapse last night and upgraded the Cougar board with a
> > > Bobcat PROM image. Oops.
> > > 
> > > By the way, you don't have to hit 'b' anymore to boot the 
> > system.  It 
> > > automatically comes up to a prompt.
> > > 
> > > 
> > > Brian
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Andy Sharp
> > > > Sent: Sunday, September 23, 2007 11:12 PM
> > > > To: Brian Stark
> > > > Subject: Re: CF accesses in PROM
> > > > 
> > > > That's OK, I'll wait until tomorrow.
> > > > 
> > > > On Sun, 23 Sep 2007 21:06:03 -0700 "Brian Stark"
> > > > <brian.stark@onstor.com> wrote:
> > > > 
> > > > > If you want to use a system tonight, you can use mine:
> > > > > 
> > > > > SSC 10.1.1.100 2001
> > > > > Power 10.1.1.141 port .a3
> > > > > 
> > > > > 
> > > > >  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Andy Sharp
> > > > > > Sent: Sunday, September 23, 2007 11:19 AM
> > > > > > To: Brian Stark
> > > > > > Cc: dl-Cougar
> > > > > > Subject: Re: CF accesses in PROM
> > > > > > 
> > > > > > On Sun, 23 Sep 2007 11:15:55 -0700 "Brian Stark"
> > > > > > <brian.stark@onstor.com> wrote:
> > > > > > 
> > > > > > > Just wanted to let you know that we now have CF
> > > > accesses working
> > > > > > > in PROM. This confirms that the hardware path to and from
> > > > > > flash is ok and
> > > > > > > also incorporates all the address changes we had to make
> > > > > > > to support the CF from a SiByte.
> > > > > > >  
> > > > > > > We tried getting the CF to be configured as memory instead
> > > > > > of i/o, but
> > > > > > > we hit some roadblocks with this.  For now, we are
> > > > > > supporting the same
> > > > > > > scheme that we've used before on Bobcat when accessing CF,
> > > > > > which is a
> > > > > > > mixture of i/o and memory accesses.  Here's the address
> > > > > > > map
> > > > > > that we're
> > > > > > > using on PCI in PROM:
> > > > > > >  
> > > > > > >  
> > > > > > > Physical Address	 Size	 Function
> > > > > > > Notes 0000.0400	 256	 CF Controller I/O
> > > > > > > socket A Accessed at base of 0xdc000000; set in ExCA i/o
> > > > > > > 0 0000.0800	 256	 CF Controller I/O socket B
> > > > > > > Accessed at base of 0xdc000000; set in ExCA i/o 0	
> > > > > > > 0001.0000	 64KB	 CF Controller I/O ExCA
> > > > > > > Accessed at base of 0xdc000000; uses base/index
> > > > > > > scheme 0080.0000	 64KB	 CF Controller Memory
> > > > > > > Socket memory accesses (set in ExCA memory 0); accessed at
> > > > > > > base of 0xf8.0000.0000 0081.0000	 64KB	 CF
> > > > > > > Controller Socket A / ExCA base	 Socket A memory
> > > > > > > accesses; ExCA mapped at 0x800 offset; accessed at base of
> > > > > > > 0xf8.0000.0000 0082.0000	 64KB	 CF
> > > > > > > Controller Socket B / ExCA base	 Socket B memory
> > > > > > > accesses; ExCA mapped at 0x800 offset; accessed at base of
> > > > > > > 0xf8.0000.0000 1a00.0000	 16MB	 TXRX Shared
> > > > > > > Memory	 TXRX accesses this locally at
> > > > > > > 0x9000.0000 1b00.0000	 16MB	 FP Shared
> > > > > > > Memory	 FP accesses this locally at
> > > > > > > 0x9000.0000 1f40.0000	 64KB	 BM
> > > > > > > FPGA 6000.0000	 16MB	 SSC Shared
> > > > > > > Memory	 SSC accesses this locally at
> > > > > > > 0x8300.0000 
> > > > > > >  
> > > > > > > Andy, let Linux take over and do whatever it likes.  We
> > > > know that
> > > > > > > accesses to all the above paths work.
> > > > > > >  
> > > > > > >  
> > > > > > > Brian
> > > > > > >  
> > > > > > 
> > > > > > OK.  I assume you are going to add these changes to my PROM 
> > > > > > today?
> > > > > > 
> > > > > > Cheers,
> > > > > > 
> > > > > > a
> > > > > > 
> > > > 
> > 
