Date: Mon, 2 Sep 1996 14:54:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: erich@uruk.org Cc: rv@groa.uct.ac.za, smp@csn.net, terry@lambert.org, freebsd-smp@freebsd.org Subject: Re: SMP on Intel MG15 Message-ID: <199609022154.OAA03155@phaeton.artisoft.com> In-Reply-To: <199609022059.NAA18595@uruk.org> from "erich@uruk.org" at Sep 2, 96 01:59:04 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [referring to a comment by Terry Lambert claiming it's sort of a bummer > if the CPU startup sequence requires use of the warm reset vector] More special case code := ++bummer, in my book. Standards are *supposed* to reduce special case code by reducing the special cases, not by giving people leeway to implement whatever the heck they want. 8-(. > The implementation of the APIC in the Pentium is not really flexible enough > to handle more than 2 CPUs on startup. In particular, there is no boot-time > or software way that I know of to set the "secondary CPU" bit (which is > what determines if the CPU pays attention to the INIT IPI, I think). I > think it is a pin in the CPU socket. I think you can HALT everything, and do it one at a time with different "VV" values for the 000VV000h real mode start address as part of the STARTUP IPI with various VV's as vector. This would mean chopping the heck out of the first meg of memory, but it *is* possible to do (assuming the damn thing listens to the STARTUP IPI like it is supposed to for version 1.x or higher local APIC's). I envision something like: 000VV00h: ... ... HLT Where you then modify the actual code, and startup per CPU ID using the IPI method, to blow the bits. This would let you get to the INIT IPI method, as necessary (not that I like doing things that way, but it *is* conceptually possible to do it). > The Pentium Pro actually does determine it at boot-time, so no extra > hardware or change in startup scheme is required. Yes, it's a much nicer SMP processor, up to the stupid 5 bit limit Intel put on the thing, assuming a bogus arbitration scaling based on an antigue VM design. Silly to limit it to 32 processors, IMO. Nevertheless, the fact that it's "glueless" is a big win, and means that we are more likely to see additional sockets for processors on motherboards, especially with the main costs being in different artwork and BIOS changes (not a real production cost), and the additional socket(s) (a small real cost). You could even put them on a daughterboard that plugged into the main socket, if you could deal with the space and heat dissipation constraints. In any case, we will be seeing a lot more MP systems as a result. > It *does* follow the spec (at least the later one. The earlier spec > didn't really cover all the cases of the existing hardware. NOTE that > the "recommended CPU startup" code was greatly revised in the later > spec version). I would recommend only referring to the later version > of the spec. For the more advanced features like bus address range > entries in the MP config table, using version 1.1 of the spec will > produce bad results (for machines such as the the XXPRESS, with multiple > PCI buses, trying to run NT with the BIOS set to version 1.1 of the > spec will produce severe problems!). Yes, agreed. However, the older specification versions are important because of the existing hardware base. It's also an opportunity to divorce specification level from implementation level -- something that should be done to help out non-Intel SMP ports (the BeBox, for instance). > Changing the version of the MPS spec in the BIOS only refers to the > information placed in the BIOS tables, and perhaps assignment of > interrupts to I/O APICs. I don't think it has any relevance to the > operation of the hardware itself. I certainly know the startup hardware > isn't influenced by this entry. I think the later stuff starts up in "virtual wire mode" almost exclusively, actually. The main issue to deal with is building static MP data tables for use in the "default" cases. As you already sort of pointed out by inference, the 1.1 spec did not deal with the idea of more than 2 processors in its defaults, so it's likely that this would have to be dealt with some time soon anyway. > If it isn't too heathen to suggest it, look at the startup code that > is in the file "arch/i386/kernel/smp.c" in any Linux kernel version > 1.3.98 or beyond. I wrote it and tested it against a large list of > different kinds of 1.1 and 1.4 compatible hardware, and it works with > nearly all of them. 8-). > I'm still working on a "canonical" startup code sequence, and should > have it soon on my web site. This will be a cool thing, IMO. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609022154.OAA03155>