Re: netbsd-5.1 cpu probe/attach for 11/7xx?
Johnny Billquist
>
>> First question is what config file you use to build your kernel?
>
> I used both "GENERIC" and a stripped down 7xx only config I made.
>
> You are right, the GENERIC does have "cpu* at mainbus0"; that was my
> mistake - I didn't originally have it my custom config.
Ok. Good. One thing cleared.
> But, even if that is there, the match in cpu_mainbus_attach will fail.
>
>> Second: How do you know that they are not called?
>
> I added printf and booted the kernel.
You do know that aprintf_normal will not print anything, right? It will
only place stuff where you can see it with dmesg, unless you set some
boot flags for a more verbose booting.
>> However, I've run NetBSD-current about 5 months ago on a 8650, and the
>> ka86_attach_cpu() function was called there, which is absolutely
>> through the same mechanism as for the 11/780.
>> So I find it a bit surprising that you claim that it is not called.
> I think the ka86 follows a different path because of NMI.
NMI? Like in nmi_mainbus? No, the 86x0 machines don't have that. The
86x0 machines have a mainbus called Abus, on to which one or more SBI
(same as on 11/780) are attached, and then things carry on from there.
The Abus code is something I corrected after I think NetBSD 5 was cut,
so if you play with NetBSD 5, you'll actually have the code consider the
SBI of the machine to be the mainbus, exactly like for the 11/780,
except that you will not ever find the memory on the SBI on an 86x0.
NMI is not involved in an 86x0. It don't have anything as fancy as
VAXBI, or XMI. The 86x0 are old machines, with plenty of Unibuses... :-)
>> In fact, I can't even find any cpu probe function for the VAX-11/780.
>
> semantics, sorry. I would claim the "cpu_attach_cpu" function is a probe
> function.
Ok. For me, a probe function is used to tell if a device is there or
not, and if it is there, then the attach function is called for it.
But that might also be just me using some strange nomenclature.
>> I'm still not convinced it isn't working.
>
> ok. I have special versions of simh which claim to be an 11/730, and
> 11/750 and an 11/780 and when I put
> printf's in the "cpu_attach_cpu" functions for each they don't print.
>
> after I fix the match function, they do.
That do sound weird. I might need to set things up to test this. *Sigh* :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Brad Parker
>>
>> I'm proposing a simple fix to make that code (which once worked) work
>> again.
>
> Ok. I had to check things through a little more to refresh my memory.
> Yes, there is a cpu_attach function for all cpus. But as far as I can
> tell, it is also called for all CPUs.
yes, good. But that function is never called on a 7xx. Those lines of
code never execute, which is the point
of my original bug report. cpu_mainbus_attach is only called if the
config is set up correctly.
If you build 5.1 and run it on a 7xx you'll find that cpu probe
functions are never called because of two
reasons (outlined in my original email).
> It's done in autoconf.c at line 186:
>
> if (dep_call->cpu_attach_cpu != NULL)
> (*dep_call->cpu_attach_cpu)(self);
that code never executes on an 11/7xx. I propose to fix that.
> Sos it's not really called through the normal autoconf paths using the
> config file.
well, yes and no. In fact, it is, as that code will not get executed
unless you "fix" the
config file and the cpu match code (see my original email).
> True. locore sets up the CPU information. autoconf then calls the
> actual attach function. Not through some probing, but directly, as the
> CPU is already known to exist, and we already know which type.
Sort of true, but that cpu_attach_cpu code is only called if the config
is set up correctly.
So yes, not as the result of probing, but not directly.
build for a 780 and try it on simh and you'll see.
I'd rather talk about the proper fix, to be honest.
-brad
Johnny Billquist
> Johnny Billquist wrote:
>> Older VAXen don't really have a CPU attach function. There can only be
>> one CPU, and it is implicitly already attached.
> I don't think that is how the code is working; at least in the abstract.
> There are cpu attach routines for
> all the 7xx cpu's, but none of them are being called. At the very least
> they print a small amount of information
> which is interestng to see -
>
> I'm proposing a simple fix to make that code (which once worked) work
> again.
Ok. I had to check things through a little more to refresh my memory.
Yes, there is a cpu_attach function for all cpus. But as far as I can
tell, it is also called for all CPUs.
It's done in autoconf.c at line 186:
if (dep_call->cpu_attach_cpu != NULL)
(*dep_call->cpu_attach_cpu)(self);
Not that this attach function do much. On a 11/780, it prints some CPU
information, and enables the FPA if it exists (but that is a pretty good
thing to do :) ).
Sos it's not really called through the normal autoconf paths using the
config file.
>> The system starts by trying to figure out what general type of system
>> it is (checking the SID), and then just start initializing pmap, and
>> all other stuff from there.
>>
>> Check locore.c, which have the initial CPU type setup code.
> Yes, thanks. I'm pretty familiar with locore.c and how it id's the cpu.
>
> I also might argue that the 11/730 cpu is directly connected to the unibus.
Well, the 11/730 also have a Unibus map, and the memory does not sit on
the Unibus. And the Unibus exists within a specific memory range in the
CPU addressing. Other addresses goes to other places. So I'd definitely
say no - the CPU does not sit directly on the Unibus.
(Heck, the Unibus can only address 256Kbyte, that would be rather severe...)
> So the practical question is - fix the broken cpu probe code? other
> architectures have similar
> cpu probe code, even in UP cases where the bus structure is simple. It
> seems to make sense to
> fix it, or if not, remove it. The code in locore.c simply id's the cpu,
> it does not do any cpu specific
> work or print anything helpful.
True. locore sets up the CPU information. autoconf then calls the actual
attach function. Not through some probing, but directly, as the CPU is
already known to exist, and we already know which type.
Johnny
Brad Parker
> Older VAXen don't really have a CPU attach function. There can only be
> one CPU, and it is implicitly already attached.
I don't think that is how the code is working; at least in the
abstract. There are cpu attach routines for
all the 7xx cpu's, but none of them are being called. At the very least
they print a small amount of information
which is interestng to see -
I'm proposing a simple fix to make that code (which once worked) work again.
>
> The system starts by trying to figure out what general type of system
> it is (checking the SID), and then just start initializing pmap, and
> all other stuff from there.
>
> Check locore.c, which have the initial CPU type setup code.
Yes, thanks. I'm pretty familiar with locore.c and how it id's the cpu.
I also might argue that the 11/730 cpu is directly connected to the unibus.
So the practical question is - fix the broken cpu probe code? other
architectures have similar
cpu probe code, even in UP cases where the bus structure is simple. It
seems to make sense to
fix it, or if not, remove it. The code in locore.c simply id's the cpu,
it does not do any cpu specific
work or print anything helpful.
-brad