Date: Fri, 28 Dec 2001 19:36:47 -0500 From: Jake Burkholder <jake@locore.ca> To: Jamey Wood <Jamey.Wood@Sun.COM> Cc: freebsd-sparc@FreeBSD.ORG Subject: Re: compiling a sparc64 kernel? Message-ID: <20011228193647.A9752@locore.ca> In-Reply-To: <1874114671.1467118741@smi.sun.com>; from Jamey.Wood@Sun.COM on Thu, Dec 27, 2001 at 02:14:44PM -0800 References: <1874114671.1467118741@smi.sun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Apparently, On Thu, Dec 27, 2001 at 02:14:44PM -0800,
Jamey Wood said words to the effect of;
>
> > Hmm. I was hoping you'd get to a mount root prompt. My first
> > guess at
> > what's happening is that the timer chip in the ultra 1 is generating
> > interrupts which are not being handled properly by the kernel. So you
> > get an interrupt storm. You could try setting the pil to
> > something high
> > (say 14), on entry to the kernel in locore.s, which may get a
> > little further.
>
> Setting pil to 14 does get me all the way to a mountroot prompt:
Ok, cool. This is a stopgap at best, I mostly wanted to see what
was going on. Thomas would like you to try the patch he posted
as well, which may print a stray interrupt message. Revert the
above change first.
> CPU: unknown; please e-mail the following value together
> with the exact name of your processor to
> <freebsd-sparc@FreeBSD.org>.
> version register: <0x22001040000507>
:) We've got a fix for this as well.
> > Really we need a driver for the timer chip, which should be easy
> > to nab from netbsd.
>
> The netbsd driver appears to be in their arch/sparc64/sparc64/clock.c.
> I'm having a little trouble understanding the FreeBSD device probing
> semantics to take a stab at porting it... It looks like the probe
> should work by looking for "counter-timer" in the OFW?
Yes, that's the timer chip. What I think you should do is use
whatever means necessary to disable the timer early while the
kernel is still running on the openfirmware trap table. Right
around the tick_stop() in sparc64_init(). You'll need to find
the physical address of the timer's registers by traversing the
openfirmware device tree and fiddle them using stxa() with asi
ASI_PHYS_BYPASS_EC_WITH_EBIT. Look at how the nexus device does
it in nexus_probe() (sparc64/sparc64/nexus.c). The timerreg.h
header from netbsd seems to have definitions for the timer registers
(timerreg_4u). From what I've read in comments it seems that there
are 2, one of which is enabled by the firmware.
We'd also like to see the properties of the timer openfirmware
device node and of the sbus node itself. From the ok prompt do
"cd /" and then "ls" and then navigate through the devices using
"cd" until you find it, and then do ".properties".
>
> What I don't understand is where that probing should occur and where
> the device attach should occur? From what I can see, the counter-timer
> device_t currently gets passed to nexus_probe_nomatch where the "no
> driver attached" messages get printed to the console.
>
> I've experimented with trying to create a skeleton driver and
> registering it with:
>
> DRIVER_MODULE(timer, nexus, timer_driver, timer_devclass, 0, 0);
>
> This does get my skeleton's probe method get called, but it just gets
> passed the nexus0 device_t, and I'm not clear on how to get at the
> children (e.g. the "counter-timer"). I even tried to hack it by
> including bus_private.h and then walking its children with:
>
> TAILQ_FOREACH(child, &dev->children, link) {
> printf("CHILD: %s\n", DEVICENAME(child));
> }
>
> But appatantly there are no children, as no iterations occur.
>
> Can you point me in the right direction for how and where the probe
> should really be happening? Perhaps an example of how you guys attach
> the pci bus would explain it?
You mean you did this in the probe method itself? probe is supposed
to return (0) if the device is right or (ENXIO) if not. In attach
you will be passed the device_t of the device itself.
The code for the psycho upa to pci bridge is in sparc64/pci/psycho.c,
which attaches to the nexus (in cvs).
Jake
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-sparc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011228193647.A9752>