AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20071015105446.27ef3ec8@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	BB375AF679D4A34E9CA8DFA650E2B04E05FEAD4C@onstor-exch02.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 15 Oct 2007 10:55:04 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: "Brian Stark" <brian.stark@onstor.com>
Subject: Re: Cougar board
Message-ID: <20071015105504.35ec8040@ripper.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E05FEAD4C@onstor-exch02.onstor.net>
References: <BB375AF679D4A34E9CA8DFA650E2B04E05FEACA7@onstor-exch02.onstor.net>
	<20071015104004.4bdabb81@ripper.onstor.net>
	<BB375AF679D4A34E9CA8DFA650E2B04E05FEAD4C@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 Mon, 15 Oct 2007 10:43:45 -0700 "Brian Stark"
<brian.stark@onstor.com> wrote:

> Yes, we'll be doing a prom upgrade, although it probably doesn't have
> anything you really want.  I also have to add a few wires to bring the
> system up to the latest and greatest level, and then I want to run a
> functional diags script to check the whole board out.  
> 
> I might have to swap your board with another so that this board can
> have the PHY rework done on the TXRX.  I'll know more about this
> later, but whatever the case, you'll have a system back today.
> 
> By the way, did you find anything out with the 64-bit kernel on the
> SWARM board?  We're still struggling with the cksseg stuff.

Sigh, there never seems to be enough time to finish my status report.

Anyway, on the SWARM board, I cannot get a 64 bit kernel to boot past
the phase where the TLB handler functions are generated.  I spent
yesterday and Friday porting our stuff to work on a recent commit to
the kernel with changes to the cache handling code that some thought
might fix our paging problem, but it didn't.

I also spent a day or so last week trying to get our clock sources
hooked up.  They don't work right on either bobcat or cougar.  I
started with the bobcat because I thought I knew more about it, but I
got nowhere: the RTC doesn't seem to increment or be settable, so
obviously the driver is not functional.  Somehow the WD part of the
driver manages to work, but not the rest.  The RTC driver class in the
kernel has changed considerably since 2.6.12 or whenever the driver
code I'm working with was originally written, so there is a bit of work
there for me to do.

I would appreciate some of your time to educate me on the RTC situation
on cougar.  Interrupts, addresses and so forth.  And how you are
intending to use them.  I understand that there is one built into the
SoC and we add one of our own as well?  Is that correct?

It looks like I'm going to have to figure out the paging problem
myself, which means that's what I'll be doing most of this week and
maybe next week.  Then I will have time to look at the module
loading/cksseg problem.

Cheers,

a
