From markk@pongo73.West.Sun.COM Thu May 26 10:59:39 1994 Date: Thu, 26 May 1994 10:59:30 -0700 From: markk@pongo73.West.Sun.COM (Mark K.) To: psarc@Eng Subject: PSARC 1994/188 PPC kernel port Cc: prasad@pongo73.West.Sun.COM, abe@pongo73.West.Sun.COM Content-Length: 2639 I have spoken to the team about the material for this case and we now have a reasonable idea of what PSARC might want to hear about and how it can be organized for presentation and review. I am sending this out to PSARC so that you can have an opportunity to tell me if this breakdown seems unreasonable. If noone tells me this seems unreasonable, I will schedule the discussions in this way. VM implementation 30 minutes this is mostly a straight forward port, but there are a few performance related issues (shared with fusion). The major changes will come in a separate case, but the base port is probably worth discussing. Kernel module linking 30 minutes there is an architectural limitation in the PPC of 32Mb for relative addressing and this complicates the loading of relocatable modules. Console design 30 minutes rather than port an existing inferior design they have chosen to go with the new (not yet approved) 1993/408 console design. Promif support 15 minutes the dust hasn't yet settled on the PPC PROM services, so they propose an interrim implementation that is very similar to the x86 version. PCI 5 minutes it isn't available yet so they propose an interrim stubbing. Platform Specific Module support 15 minutes this is a relatively straight forward port of the mechanisms approved in 1993/042, but some discussion of the PPC version might be desired because of its potential KBI implications. Obvious porting changes 30 minutes (we won't use it all) the vast majority of everything they are doing appears to be making obvious changes to the obvious places ... ISA and bus architecture dependent implementations of standard interfaces, fixing obvious bugs, adding obvious cases to existing platform dependent tests ... team will present a list of every module for which such changes are being made, a brief summary of what the nature of the changes was, and (where applicable) the names of the MTV OS folks with whom these changes have been discussed. Issues not discussed 15 minutes there are a few areas where significant changes are envisioned, and these will be presented in separate cases (changes to HAT layer, boot architecture, auto-configuration, ...). There will be a brief presentation/discussion of what the issues are and when the cases should be expected. I suggested that there was no need to discuss any device driver port or new device driver unless it was a new class of device, it supported new interfaces, or it was implemented in a manner unlike existing device drivers. From shannon@datsun Tue May 31 16:35:05 1994 Date: Tue, 31 May 1994 16:34:37 -0700 From: shannon@datsun (Bill Shannon) To: markk@pongo73.West.Sun.COM Subject: Re: PSARC 1994/188 PPC kernel port Cc: psarc@malachite Content-Length: 655 It seems that most of what you're planning to present is really design review level detail. I'd suggest holding a design review first, and then only presenting to PSARC the architectural issues that come out of such a review, and provide the design review details as background information. I think it's a waste of our time to review all the "obvious porting changes", and especially the bug fixes. What we really need to know is in what areas PPC hardware differences impose new requirements on the machine independent parts of the system, and in what areas the existing machine-specific support architecture and interfaces were not adequate for PPC. From markk@pongo73.West.Sun.COM Tue May 31 17:04:24 1994 Date: Tue, 31 May 1994 17:04:05 -0700 From: markk@pongo73.West.Sun.COM (Mark K.) To: markk@pongo73.West.Sun.COM, Bill.Shannon@Eng Subject: Re: PSARC 1994/188 PPC kernel port Cc: psarc@malachite.Eng.Sun.COM, prasad@pongo73.West.Sun.COM Content-Length: 2522 > From Bill.Shannon@Eng Tue May 31 16:35 PDT 1994 > > It seems that most of what you're planning to present is really > design review level detail. I'd suggest holding a design review > first, and then only presenting to PSARC the architectural issues > that come out of such a review, and provide the design review > details as background information. The Team has been performing design reviews and has prepared a list describing (in some detail) the changes in every area and file. The information about what issues might exist in what areas is already available (and was briefly summarized in my note). I guess I misread the mind of the ARC on this matter. I got a very clear message that PSARC was pissed about how little exposure there was of x86 design issues up-front, and assumed (based on those bad experiences) that it would be well to err in the direction of over-exposure on the PPC port. If you think they should only present areas where there are new requirements or where existing machine-specific interfaces are inadequate we can significantly reduce the amount of time needed for discussion ... ===== STUFF TO BE REVIEWED ========= Kernel module linking 30 minutes REVIEW REQUIRED, because existing mechanisms are inadequate. Console design 30 minutes REVIEW REQUIREMENT UNCLEAR. Technical design is entirely covered by 1993/408, but that project is not yet approved. PSARC probably want's to hear about the nature of the dependencies and the contingency plans for what to do if 1993/408 doesn't get approved. ===== STUFF NOT TO BE REVIEWED ====== VM implementation 30 minutes NO REVIEW REQUIRED, since the only significant architectural change will be reviewed under its own case (shared with fusion project). Promif support 15 minutes NO REVIEW REQUIRED. The short term implementation will be very much like the x86. PCI 5 minutes NO REVIEW REQUIRED. They will use the right thing when it becomes available and do without until then. Platform Specific Module support 15 minutes NO REVIEW REQUIRED. This is an implementation of the interfaces already approved in 1993/042. Obvious porting changes 30 minutes (we won't use it all) NO REVIEW REQUIRED. This all qualifies for self-approval, and the changes are being coordinated with the responsible MTV code owners. Issues not discussed 15 minutes NO REVIEW REQUIRED. This was not a proposal but a heads-up for other proposals. From shannon@datsun Tue May 31 17:31:30 1994 Date: Tue, 31 May 1994 17:30:22 -0700 From: shannon@datsun (Bill Shannon) To: markk@pongo73.West.Sun.COM Subject: Re: PSARC 1994/188 PPC kernel port Cc: prasad@pongo73.West.Sun.COM, psarc@malachite.Eng.Sun.COM Content-Length: 2892 The Team has been performing design reviews and has prepared a list describing (in some detail) the changes in every area and file. The information about what issues might exist in what areas is already available (and was briefly summarized in my note). I guess I wasn't clear. I was talking about design reviews *outside* the team. I guess I misread the mind of the ARC on this matter. I got a very clear message that PSARC was pissed about how little exposure there was of x86 design issues up-front, and assumed (based on those bad experiences) that it would be well to err in the direction of over-exposure on the PPC port. I'm trying to correct the impression that PSARC does design reviews, and I'm trying to correct the impression that PSARC wants to know every little detail. The x86 stuff was lacking in both design reviews (outside the team) and architecture review. If you think they should only present areas where there are new requirements or where existing machine-specific interfaces are inadequate we can significantly reduce the amount of time needed for discussion ... That was my goal. My impression of the Fusion review is that that's what's happening in that case. ===== STUFF TO BE REVIEWED ========= Kernel module linking 30 minutes REVIEW REQUIRED, because existing mechanisms are inadequate. Right. Console design 30 minutes REVIEW REQUIREMENT UNCLEAR. Technical design is entirely covered by 1993/408, but that project is not yet approved. PSARC probably want's to hear about the nature of the dependencies and the contingency plans for what to do if 1993/408 doesn't get approved. No. I think we should be happy to simply record a dependency on this other project. Perhaps the SC will require a backup plan, but I'm not sure why we should. ===== STUFF NOT TO BE REVIEWED ====== VM implementation 30 minutes NO REVIEW REQUIRED, since the only significant architectural change will be reviewed under its own case (shared with fusion project). Ok. Promif support 15 minutes NO REVIEW REQUIRED. The short term implementation will be very much like the x86. I guess it depends on your definition of "very much". PCI 5 minutes NO REVIEW REQUIRED. They will use the right thing when it becomes available and do without until then. Ok. Platform Specific Module support 15 minutes NO REVIEW REQUIRED. This is an implementation of the interfaces already approved in 1993/042. Ok. Obvious porting changes 30 minutes (we won't use it all) NO REVIEW REQUIRED. This all qualifies for self-approval, and the changes are being coordinated with the responsible MTV code owners. Ok. Issues not discussed 15 minutes NO REVIEW REQUIRED. This was not a proposal but a heads-up for other proposals. Ok. From jek3@jurassic Wed Jun 1 00:18:22 1994 Date: Wed, 1 Jun 1994 00:22:06 +0800 From: jek3@jurassic (Joseph Kowalski) To: markk@pongo73.West.Sun.COM, shannon@datsun Cc: prasad@pongo73.West.Sun.COM, psarc@malachite.Eng.Sun.COM Subject: Re: PSARC 1994/188 PPC kernel port Content-Length: 1479 I guess I disagree with some of these: > Promif support 15 minutes > > NO REVIEW REQUIRED. The short term implementation > will be very much like the x86. > > I guess it depends on your definition of "very much". Which of the three x86 promif libraries are we talking about here? Maybe this is code review, but I don't believe that x86 sets a valid precedent in this matter. The x86 style of promif was never reviewed. For that matter, neither was the sparc version, but it was the grandfathered precedent. > Platform Specific Module support 15 minutes > > NO REVIEW REQUIRED. This is an implementation of > the interfaces already approved in 1993/042. > > Ok. I don't buy this one either. The minimal nature of this was predicated on the known, existing x86 market and "what vendors already expect". I see no reason to belive any of this applies to PPC. The apple vs. IBM PCC are so different that the KBI (much less 1993/042) couldn't deal with it (a little matter of byte sex). I'd need to look further, but I don't believe the mesh between the routines defined in 042 and the PPC "virtual machine" is very good. I believe this needs to be reviewed for appropriateness. General comment: I believe including anything which is on {sparc|x86} and not on {x86|sparc} should be reviewed for inclusion. - jek3 From prasad@pongo.West.Sun.COM Wed Jun 1 11:10:38 1994 Date: Wed, 1 Jun 1994 11:10:32 +0800 From: prasad@pongo.West.Sun.COM (Prasad Singamsetty) To: markk@pongo73.West.Sun.COM, Bill.Shannon@Eng, jek3@jurassic.Eng.Sun.COM Subject: Re: PSARC 1994/188 PPC kernel port Cc: prasad@pongo73.West.Sun.COM, psarc@malachite.Eng.Sun.COM, stevez@pongo.West.Sun.COM, billt@pongo.West.Sun.COM Content-Length: 2871 > From jek3@jurassic.Eng.Sun.COM Wed Jun 1 00:18 PDT 1994 > > I guess I disagree with some of these: > > > Promif support 15 minutes > > > > NO REVIEW REQUIRED. The short term implementation > > will be very much like the x86. > > > > I guess it depends on your definition of "very much". > > Which of the three x86 promif libraries are we talking about here? > Maybe this is code review, but I don't believe that x86 sets a valid > precedent in this matter. The x86 style of promif was never reviewed. > For that matter, neither was the sparc version, but it was the grandfathered > precedent. > I was referring to uts/i86/promif directory. This was used as an interim solution because of the follwing reasons: 1) OpenBoot Firmware interface is not available (at least until Jan.'95). Whice means the current boot interface is a short term solution for the current hw supported. 2) I think there is no PSARC approved promif interface to use for PPC. 3) Since the current booting system for PPC is based on x86 we simply used x86 version of promif for PPC. So this interface would have to change when OpenBoot is available on the PPC hw. > > Platform Specific Module support 15 minutes > > > > NO REVIEW REQUIRED. This is an implementation of > > the interfaces already approved in 1993/042. > > > > Ok. > > I don't buy this one either. The minimal nature of this was predicated > on the known, existing x86 market and "what vendors already expect". I > see no reason to belive any of this applies to PPC. The apple vs. IBM > PCC are so different that the KBI (much less 1993/042) couldn't deal with > it (a little matter of byte sex). I'd need to look further, but I don't > believe the mesh between the routines defined in 042 and the PPC "virtual > machine" is very good. I believe this needs to be reviewed for appropriateness. > I agree that this may not be the best suitable interface for PPC. But, we did this for the following reasons: 1) We still don't know enough about MP hw for PPC or other platforms that we are going to support. 2) The interrupt control system on PPC (on the current UP system) is very similar to x86. 3) It was practical to start the porting from x86 sources and we didn't need to change this to make it work on the current PPC hw. We had a choice of either undoing this or use it until we know more about other platforms and MP systems. We chose to use it for the short term. 4) Since this interface was a PSARC approved interface for x86 we chose to use it until we have more information to design a new interface. I think this interface is also a short term solution. --prasad From jek3@jurassic Wed Jun 1 12:29:14 1994 Date: Wed, 1 Jun 1994 12:33:03 +0800 From: jek3@jurassic (Joseph Kowalski) To: markk@pongo73.West.Sun.COM, Bill.Shannon@Eng, jek3@jurassic.Eng.Sun.COM, prasad@pongo.West.Sun.COM Subject: Re: PSARC 1994/188 PPC kernel port Cc: prasad@pongo73.West.Sun.COM, psarc@malachite.Eng.Sun.COM, stevez@pongo.West.Sun.COM, billt@pongo.West.Sun.COM Content-Length: 4048 > From prasad@pongo.West.Sun.COM Wed Jun 1 11:14 PDT 1994 > > > From jek3@jurassic.Eng.Sun.COM Wed Jun 1 00:18 PDT 1994 > > > > I guess I disagree with some of these: > > > > > Promif support 15 minutes > > > > > > NO REVIEW REQUIRED. The short term implementation > > > will be very much like the x86. > > > > > > I guess it depends on your definition of "very much". > > > > Which of the three x86 promif libraries are we talking about here? > > Maybe this is code review, but I don't believe that x86 sets a valid > > precedent in this matter. The x86 style of promif was never reviewed. > > For that matter, neither was the sparc version, but it was the grandfathered > > precedent. > > > I was referring to uts/i86/promif directory. This was used as an > interim solution because of the follwing reasons: > > 1) OpenBoot Firmware interface is not available (at least > until Jan.'95). Whice means the current boot interface > is a short term solution for the current hw supported. > 2) I think there is no PSARC approved promif interface to > use for PPC. > 3) Since the current booting system for PPC is based on x86 > we simply used x86 version of promif for PPC. > > So this interface would have to change when OpenBoot is available > on the PPC hw. If I understand this, you have an interum solution you want to generate (for the weird proms) to transition to another implementation. Seems worthy of ARC review to me. > > > Platform Specific Module support 15 minutes > > > > > > NO REVIEW REQUIRED. This is an implementation of > > > the interfaces already approved in 1993/042. > > > > > > Ok. > > > > I don't buy this one either. The minimal nature of this was predicated > > on the known, existing x86 market and "what vendors already expect". I > > see no reason to belive any of this applies to PPC. The apple vs. IBM > > PCC are so different that the KBI (much less 1993/042) couldn't deal with > > it (a little matter of byte sex). I'd need to look further, but I don't > > believe the mesh between the routines defined in 042 and the PPC "virtual > > machine" is very good. I believe this needs to be reviewed for appropriateness. > > > I agree that this may not be the best suitable interface for PPC. But, > we did this for the following reasons: > > 1) We still don't know enough about MP hw for PPC or other > platforms that we are going to support. > 2) The interrupt control system on PPC (on the current UP > system) is very similar to x86. > 3) It was practical to start the porting from x86 sources and > we didn't need to change this to make it work on the current > PPC hw. We had a choice of either undoing this or use it > until we know more about other platforms and MP systems. > We chose to use it for the short term. > 4) Since this interface was a PSARC approved interface for x86 > we chose to use it until we have more information to > design a new interface. > > I think this interface is also a short term solution. Solution to what? I'm personally not willing to expand the x86 approval to a wider approval without discussion. Please understand that I'm just requesting ARC review in these areas because the answer is far from obvious to me. (OK, I'm really skeptical of the promif stuff, but convince me I'm wrong.) I brought up the negative points I did as a devil's advocate. They are the questions I believe need to be answered. They are also exactly the type of thing which caused the friction with x86; the "why did you do that?" issue came up far more often than the "why did you do that, that particular way?" issue. Also, a lot of these answers have the "because it was something we had" flavor to them. Wasn't that the biggest issue which caused friction between x86 and sparc? Do we want to do that again. > --prasad - jek3 From c.@political Wed Jun 22 16:59:06 1994 Date: Wed, 22 Jun 1994 16:59:35 +0800 From: c.@political (Steve C.) To: psarc@sac Subject: PSARC/1994/188 (PPC) and _init() Cc: abe@pongo73.West.Sun.COM, billt@pongo.West.Sun.COM, jre@political, prasad@pongo73.West.Sun.COM, stevez@pongo.West.Sun.COM, tpm@political Content-Length: 519 I was wrong. Both WDD and the _init(9e) man page say (or at least imply) that _init(), _fini(), _info() are global functions, not static. In fact, the 5.3 man page says: NOTES Even though the identifiers _fini(), _info(), and _init() appear to be declared as globals, their scope is restricted by the kernel to the module that they are defined in. So I have no problem with the fix to bug 1136237, which is to bring buggy drivers into compliance with the DDI (at least in this respect). --Steve From markk@pongo73.West.Sun.COM Tue Jul 12 09:19:29 1994 Date: Tue, 12 Jul 1994 09:18:51 -0700 From: markk@pongo73.West.Sun.COM (Mark K.) To: psarc@Eng Subject: PSARC 1994/188 PPC Kernel Cc: prasad@pongo73.West.Sun.COM, billt@pongo73.West.Sun.COM, abe@pongo73.West.Sun.COM Content-Type: X-sun-attachment Content-Length: 20295 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 13 After the end of the PPC reviews the plan was: (1) for Prasad to write up a detailed proposal for the solution of the 32MB relative call problem. (2) for me to write up a draft opinion (3) to try to approve the opinion via E-mail or in PSARC business, without another review meeting. Prasad has drafted his detailed proposal, and it is enclosed. I have written a draft opinion, and it is enclosed. ---------- X-Sun-Data-Type: default X-Sun-Data-Name: kobj.proposal X-Sun-Charset: us-ascii X-Sun-Content-Lines: 192 Proposal for implementing solution #2 for 32M short call limitation on PPC: --------------------------------------------------------------------------- The proposed solution is to use a seperate kernel segment (say E_kvseg) which is close to the base kernel in the virtual address space and use this segment for allocating text/data sections (but not bss) of kernel modules. The generic kernel segment, kvseg, is split into two segments (kvseg and E_kvseg) as in the map below: ^ ^ | | ~ ~ : : 0xEF000000 -|-----------------------|- SYSLIMIT : : | Sysmap | SYSPTSIZE (128 M) : (kvseg segment) : | | 0xE7001000 -|-----------------------| | not used (4k) | 0xE7000000 |-----------------------|- SYSBASE : : ~ ~ : : |-----------------------|- econtig | | | vm structures | | (page structures | | page hash | | memseg structures) | | | |-----------------------|- end : : | kernel | : : 0xE2000000 |-----------------------|- KERNELSTART/E_SYSLIMIT : : | E_kvseg | | (for kernel module | (32M-4K) | text/data sections) | : : 0xE0001000 -|-----------------------|- E_SYSBASE | user copy red zone | (4K) | (invalid) | 0xE0000000 -|-----------------------|- KERNELBASE : : ~ ~ : : Note: The names E_* are used in some other SPARC platforms for Ethernet purposes but here we can use it as Extended. The same name is chosen to minimize changes to libkvm (which already knows these names). The new segment also uses seg_kmem segment driver. A simple allocator is used to allocate memory from the new segment. Kernel files that require changes: ---------------------------------- usr/src/uts/common/os/kobj.c Changes are ifdef under ppc to call a different allocator when allocating memory for text/data sections (allocated as a single buffer). usr/src/uts/ppc/sys/pte.h Added E_Sysmap[] declaration (similar to Sysmap[]). usr/src/uts/ppc/vm/mach_ppcmmu.c Minor changes to hat_kern_setup() to update E_Sysmap[] during the startup. usr/src/uts/ppc/vm/seg_kmem.c Added the new allocator functions: lokmem_zalloc() Same inteface as kmem_alloc() lokmem_free() Same interface as kmem_free() lokmem_init() Equivalent to kmem_init() lokmem_gc() Equivalent to kmem_gc() Allocator allocates memory from the high end (i.e from E_SYSLIMIT down) and this eliminates the need for adjusting the size of the segment based on the base kernel size (i.e KERNELSTART to econtig). usr/src/uts/ppc/vm/seg_kmem.h Added declarations for E_kvseg segment. usr/src/uts/prep/conf/Mapfile Changed KERNELSTART (start address for unix module). usr/src/uts/prep/ml/genassym.c Added symbol offset definitions for E_SYSBASE and E_SYSLIMIT. usr/src/uts/prep/ml/locore.s Added definitons for E_Sysbase and E_Syslimit similar to Sysbase and Syslimit. usr/src/uts/prep/os/startup.c Changes to startup() and related functions to setup E_kvseg segment. And some minor changes in setting up vm initialization. usr/src/uts/prep/sys/machparam.h Added definitons for E_SYSBASE/E_SYSLIMIT. Additional changes to user commands/libraries: --------------------------------------------- libkvm is the only library that depends on Sysmap[] and it already knows about the E_Sysmap[] so I don't expect any changes here. No other libraries or commands would require changes. STATUS: ------ Prototype implementation of this scheme is completed and tested. And libkvm support is being tested. Diff output on the common files: -------------------------------- *** kobj.c. Wed Jun 29 11:22:48 1994 --- kobj.c Wed Jun 29 11:26:05 1994 *************** *** 2,8 **** * Copyright (c) 1991-1994, Sun Microsystems, Inc. */ ! #pragma ident "@(#)kobj.c 1.40 94/04/05 SMI" /* * This provides three functions to the rest of the kernel: --- 2,8 ---- * Copyright (c) 1991-1994, Sun Microsystems, Inc. */ ! #pragma ident "%Z%%M% %I% %E% SMI" /* * This provides three functions to the rest of the kernel: *************** *** 124,129 **** --- 124,151 ---- int load_base_aout _((struct module *)); #endif + #if defined(ppc) + static void * + kobj_text_zalloc(size_t size, int flag) + { + extern void *lokmem_zalloc(); + + kobj_stat.nalloc_calls++; + kobj_stat.nalloc += size; + return (lokmem_zalloc(size, flag)); + } + + static void + kobj_text_free(void *address, size_t size) + { + extern void lokmem_free(); + + lokmem_free(address, size); + kobj_stat.nfree_calls++; + kobj_stat.nfree += size; + } + #endif + void * kobj_zalloc(size_t size, int flag) { *************** *** 405,411 **** --- 427,437 ---- else kobj_free(mp->symspace, mp->symsize); if (mp->space) + #if defined(ppc) + kobj_text_free(mp->space, mp->space_size); + #else kobj_free(mp->space, mp->space_size); + #endif if (mp->symhdr) kobj_free(mp->symhdr, mp->hdr.e_shentsize); if (mp->shdrs) *************** *** 462,469 **** --- 488,505 ---- return (-1); mp->space_size = bits_ptr; + #if defined(ppc) + mp->space = kobj_text_zalloc(mp->space_size, KM_SLEEP); + #else mp->space = kobj_zalloc(mp->space_size, KM_SLEEP); + #endif bits_ptr = (unsigned int)mp->space; + + if (bits_ptr <= 0) { + modprintf("memory allocation for the module %s failed\n", + file->_name); + return (bits_ptr); + } /* now loop though sections assigning addresses and loading the data */ for (secnum = 1; secnum < mp->hdr.e_shnum; secnum++) { ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: opinion.out X-Sun-Charset: us-ascii X-Sun-Content-Lines: 349 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Power PC Kernel Port Submitted by: Prasad Singamsetty File: psarc/1994/188/opinion.ms Date: July ??th, 1994 Committee: Mark K., Steve C., Bruce D., Yousef K., Joseph Kowalski, Terrence M., Bill Shannon, Glenn Skinner, Scott Wilson 1. Summary The Power PC (PPC) is a new instruction set architecture that has the potential to challenge the Intel x86 architecture's market share. The basic Instruction Set Architecture is described by the Power PC Architecture, and there are currently two chips in the PPC family. The 601 is designed for more powerful (potentially MP) systems. The 603 is designed for notebook computers. There is a PReP specification that provides a high level functional specification for Power PC platforms, but it is too general to be useful for an implementation. The only major PPC platform available at this time is the IBM Refer- ence Implementation. The primary goal of the Power PC kernel port is to extend the Solaris kernel to be able to support the 601- and 603- based IBM Reference Implementation platforms for the Power PC. A secondary goal is the creation of a framework for supporting other Power PC platforms. It should be noted that even the architecture for the IBM reference implementations is still in a state of flux. Many important details (like MP architecture and BIOS interface specifications) are still not fully defined. Because PPC platform specifications are still in such a fluid state, it should be assumed that additional PPC platform support pro- jects will have to be created to support the real product platforms when they become available. It should also be noted that this project represents only part of the work required in order to fully support Solaris on the PPC. The other basic PPC projects are: psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 2 - 1993/685 Power PC ABI 1993/196 Power PC Header files 1993/197 Power PC Commands 2. Decision & Precedence Information The project is accepted, subject to the changes enumerated in Appendix A. The classification of the change introduced by this project is micro. 3. Opinion Most of the discussion focused on how reasonable it is for the PCFS implementation to have hard coded knowledge of media types and disk partitioning data structures. The con- clusion was that the existing PCFS implementation is not an architecturally good one, but that it would be unreasonable to force the project team to fix all of the problems at this time. ________________________________________________________________ | Interfaces Exported | |__________________|__________________________|________________| |Interface | Classification | Comments | |__________________|__________________________|________________| |PROMIF functions | Project Private/Obsolete| | |console interfaces| Project Private | until 1993/408| |E_kvseg | Project Private | | |__________________|__________________________|________________| Although numerous changes are being made to the Solaris Ker- nel in order to accomplish the Power PC port, the majority of these changes are obvious ones with no architectural con- tent (e.g. device drivers and ISA specific implementations of platform dependent functions). These received little discussion. The majority of the discussion focused on a half-dozen issues. 3.1. MP Support There is not currently a standard or reference implementa- tion for PPC based MP machines. The team proposes not to include any MP work in this project. They will, however, not do anything to preclude MP support and will ensure that all new code is written to be appropriately MP-safe/hot. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 3 - 3.2. PROMIF support The PReP spec calls for Open Firmware PROM/BIOS, but does not define any interfaces to it. The IBM reference imple- mentation does not yet provide or define these services. Since these services are not yet available, the initial ker- nel port (this project) will not attempt to provide an interface to them. As an interrim solution, the team will use the existing (x86-based) NOP non-implementations to stub out these func- tions. It is expected, however, that when the PPC PROM functionality is defined, a new project will be created to use those services to more fully implement the corresponding functions. In particular, it is not expected that the stub implementations will be shipped with the product's FCS. It should be noted, however, that there may be PPC platforms that do not provide the Open Firmware support. If such machines exist, and Solaris is to support them, it may be necessary to retain the stub versions of the PROMIF func- tions and provide other implementations for needed boot-time functionality. 3.3. dependency on 1993/408 The PPC reference implementation uses keyboard and display controllers that are very similar to those on the x86, and so it makes sense to base the PPC drivers on the x86 ver- sions. The x86 keyboard and display architecture, however, is currently in a major state of flux (1993/408). The team was forced to choose between basing the PPC port on an implementation that was becoming obsolete or an implemen- tation that was not yet available. They chose the latter, and have been working very closely with the console redesign team. The committee agreed that this was a reasonable approach, and noted that the PPC kernel project does not actually depend on the completion and integration of 1993/408. Until 1993/408 integrates, the PPC kernel can use its own copies of the necessary code (in platform specific directories). The major concern was the fire drill that would result in the source tree when this project checked new console code in (in platform dependent directories) and then the console redesign team checked a slightly different version into com- mon directories. The committee recommended that an effort be made to accellerate the check-in of the portions of the new console implementation that the PPC port needed in order to avoid this confusion. If such an accelerated check-in is not possible, the team is psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 4 - authorized to check their versions of this code in (as plat- form specific code), but they must assume the responsibility for all necessary changes when the common code from 1993/408 is put back. 3.4. RAM disk driver One of the PROM services that is not yet defined/implemented in the IBM reference platform is general disk I/O. Without this service, it is very difficult to load a kernel into memory. To get around this problem, the team has defined an extremely large boot block ... one that contains an entire UFS file system with all of the files that need to be loaded in order to build a viable kernel. The PROM boot code reads the entire image into memory, and the Solaris bootstrap then treats that image as a RAMdisk, from which the necessary modules are loaded. This requires a minor change to the RAM disk driver. In other systems, the RAM disk driver allocates (a pre-defined size) and initializes the memory for the RAM disk when it is opened. On the Power PC, the memory for the RAM disk has already been allocated and initialized, and the size is a parameter passed in a global structure. The team indicated that this was only a short term porting aid and would not be part of any real product. 3.5. 32MB short call limitation The PPC ISA has an efficient relative short call that is limited to a range of plus/minus 32Mb. Calls within the main kernel, and within dynamically loaded modules easily fit within this range, but calls between the main kernel and dynmically loaded modules may not. This is not a problem on Sparc or X86 because the standard call instructions on those ISAs have a much wider range. In the short term, the team has limited Sysmap to 16M and set SYSBASE (the base for dynamically loaded modules) to KERNELBASE+16M ... thus restricting the core kernel and all of its data structures to 16Mb. Ultimately, however, this limitation may prove to be unreasonably restrictive and a better solution must be found. Two alternatives were pro- posed: 1. use PLTs for linking kernel modules. 2. use a separate segment within the kernel address space for dynamically loadable modules and keep them within 32Mb of the core kernel. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 5 - The first option requires complex changes to kobj and imposes a performance hit on the function calls that go through the PLTs (e.g. every call to mutex_enter). The second option requires the creation of a new segment and a new set of allocation routines to manage the space in that segment. The second option is also more restrictive (in that it requires the core kernel and the text+data of all dynamically loaded modules to fit within 32Mb). It was the concensus of the committee that we probably want to do option 2 promptly and move to option 1 later (if and when the 32Mb limitation becomes pressing). It was noted however, that modules must be compiled for either direct or PLT calls, and so switching models later will necessitate recompiles of all dynamically loadable modules. Option 2 requires changes to common code, and those changes must be reviewed by the ON owners ... but this is not an architectural issue. A more detailed description of how this will be implemented can be found in the supplementary materials directory for this case (PSARC/1994/188/materials/kobj.proposal). 3.6. Platform Specific Module Interface Although all of the PPC platforms have not yet been defined, the team anticipates considerable diversity among them and wants to provide a general framework for platform specific modules. Due to similarities with x86 interrupt controllers ane MMUs, the team proposed to use the x86 MP Platform Specific Module interface and implementation (1993/622) as a starting point for the PPC implementation. The motivation behind 1993/622 was MP support, and MP sup- port is not an issue in this project, but the team argued that most of the functions in that framework are not MP specific and that many of the implementations are already very close to what is needed on the PPC. The committee expressed concern that there was a significant overlap between these functions and KBI phase 2, and that it seemed inappropriate to sanction a different interface to solve the same problems a little bit sooner. It was also observed that the need for a general framework for PSMs was only hypothetical, since Solaris is not expected to run on other PPC platforms in the next twelve months. The committee suggested that the PPC kernel team work with the KBI team to ensure that the KBI would adequately answer x86, x86mp, and PPC needs for Platform Specific Modules. If extensions are required, these should be made as part of KBI-2 or some new project. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 6 - 4. Minority Opinion(s) None. 5. Advisory Information 5.1. dependency on 1993/408 The decision to use the new console architecture (1993/408) in this project is a reasonable one, but the committee is concerned that this project proposes to deliver its code before 1993/408. The PPC team should negotiate with the new console team to see if the putback of the code that the PPC project requires can be accelerated. If this is not possible, and the PPC team is authorized to put their version of the console sup- port back into a platform dependent directory. Later, when the console team does their putback, the PPC team must han- dle the resync and reconciliation work that is required in order to use the new code from the console team. 5.2. stubbed PROMIF implementation The decision to use the existing x86 code to stub out the PROMIF functions is an appropriate one at this time. When proper PROMIF specifications and implementations become available, it is expected that the NOP implementation will be replaced with a more complete one. It is expected that this will happen prior to FCS. 6. Appendices 6.1. Appendix A: Technical Changes Required The proposed platform specific module interface overlaps with interfaces that are to be addressed by the KBI and it seems inappropriate to create a conflicting standard for these functions. The platform specific module support framework must be removed into a separate project, in which x86, PPC and KBI concerns will all be reconciled. 6.2. Appendix B: Technical Changes Advised None. 6.3. Appendix C: Reference Material 1. PSARC/1994/188/materials/kobj.proposal psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 7 - 2. PowerPC 601 User's Manual, Motorola 3. PowerPC Processor Architecture (Books I-III), IBM 4. PowerPC Reference Platform Specification (PReP) psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. From h.@nidhogg Thu Jul 14 11:59:15 1994 Date: Thu, 14 Jul 1994 09:21:56 +0800 From: h.@nidhogg (Bob H.) To: psarc@Eng, markk@pongo73.West.Sun.COM Subject: Re: PSARC 1994/188 PPC Kernel Cc: prasad@pongo73.West.Sun.COM, billt@pongo73.West.Sun.COM, abe@pongo73.West.Sun.COM Content-Length: 0 It was the concensus of the committee that we probably want to do option 2 promptly and move to option 1 later (if and when the 32Mb limitation becomes pressing). It was noted however, that modules must be compiled for either direct or PLT calls, and so switching models later will necessitate recompiles of all dynamically loadable modules. This is not what I heard. Yeah, do option 1 now and hope to never have to do something like option 2. But, I thought that we would compile direct, but then have to deal with the extra level of indirection somehow. I don't know what a PLT really is, so I can't really propose a solution. At the very least, the "call" instruction could call to some dynamically generated loader code that reissued the call using PLT's. Yeah, it is slow and ugly, but it gets us out of the 32M box. I view a solution that someday may require recompile of dynamically loaded modules unacceptable. I beleive that we are establishing part of the ABI for loadable modules in this case. We should make our call and stick with it. -- Bob From prasad@pongo.West.Sun.COM Fri Jul 15 18:28:16 1994 Date: Fri, 15 Jul 1994 18:28:11 +0800 From: prasad@pongo.West.Sun.COM (Prasad Singamsetty) To: Robert.H.@Eng Subject: Re: PSARC 1994/188 PPC Kernel Cc: psarc@Eng, prasad@pongo.West.Sun.COM, billt@pongo.West.Sun.COM, abe@pongo.West.Sun.COM, markk@pongo.West.Sun.COM, stevez@pongo.West.Sun.COM Content-Length: 3811 > It was the concensus of the committee that we probably want > to do option 2 promptly and move to option 1 later (if and > when the 32Mb limitation becomes pressing). It was noted > however, that modules must be compiled for either direct or > PLT calls, and so switching models later will necessitate > recompiles of all dynamically loadable modules. > > This is not what I heard. Yeah, do option 1 now and hope to never > have to do something like option 2. But, I thought that we would compile > direct, but then have to deal with the extra level of indirection somehow. > I don't know what a PLT really is, so I can't really propose a solution. > At the very least, the "call" instruction could call to some > dynamically generated loader code that reissued the call > using PLT's. Yeah, it is slow and ugly, but it gets us out > of the 32M box. > First, I think it was a general opinion that 32M limitation would work fine for some time (may be few years?) until we have kernels that require more than 32M (which means more than 32M of physical memory), but we need to come up with some long term solution that would eliminate the 32M limitation. And we only need to implement the short term solution with 32M limitation now and plan for longer term solution that eliminates this limitation. The proposed PLT (Procedure Linkage Table) solution is same as what is done with the dynamically linked user programs and shared libraries. This requires modules built with PLT entries so that the runtime linker could redirect the external references and it would use the PLT entries to glue that stuff. Implementation of this requires changes to kernel run time linker and building modules differently to generate space for PLTs. So, the question now is if we only do solution #2 and later on if we hit the 32M limitation then will there be any binary compatibility issue to implement the long calls. I think we have a different scheme that doesn't use the PLT mechanism but can fix the 32M limitation without loosing the binary compatibility. #3. Long call support without using the PLT mechanism: ------------------------------------------------------ The basic problem is to replace the short call instruction with an indirect function call. The short call is one instruction and the long call using the function pointer requires 4 instructions. e.g short call bl external_label long call li %r0, external_label@h oris %r0, %r0, external_label@l mtctr %r0 bctr Conversion from short call to long call /* short call instruction modified as */ bl local_label ... ... /* * code fragment added to the module for * redirecting the call. */ local_label: li %r0, external_label@h oris %r0, %r0, external_label@l mtctr %r0 bctr To implement this code conversion we need to allocate additional code space within the module needed for all the local functions (i.e local_label's: one for each function call that needs conversion). This requires the kernel run time linker (kobj/krtld) to figure out the additional space needed for converting short calls that have external references and allocate this along with the space for the module from the regular kernel segment (i.e kvseg). And then it needs to fix the code in the module and generate the code sequences to call the external functions as in the above example. This scheme would require some significant changes to kobj/krtld but this would eliminate rebuilding any kernel binaries that would not fit within 32M when linked with the kernel. This scheme is just a proposed solution without having any details of the design to implement it or the effort involved in modifying the kobj/krtld. -- prasad From h.@nidhogg Mon Jul 18 08:38:38 1994 Date: Mon, 18 Jul 1994 08:38:40 +0800 From: h.@nidhogg (Bob H.) To: Robert.H.@Eng, prasad@pongo.West.Sun.COM Subject: Re: PSARC 1994/188 PPC Kernel Cc: psarc@Eng, billt@pongo.West.Sun.COM, abe@pongo.West.Sun.COM, markk@pongo.West.Sun.COM, stevez@pongo.West.Sun.COM Content-Length: 2443 > > > First, I think it was a general opinion that 32M limitation would > work fine for some time (may be few years?) until we have kernels that > require more than 32M (which means more than 32M of physical memory), > but we need to come up with some long term solution that would > eliminate the 32M limitation. And we only need to implement the > short term solution with 32M limitation now and plan for longer > term solution that eliminates this limitation. > Agreed. We need to do #2 now, but have a *plan* of what we could do to keep binary compatibility. I think that the point is that binary compatibility is required. The plan can be just a proof of concept. I just don't want to get stuck in the 32M box or have to break binary compatibility. Nor do I want much work done now. > > So, the question now is if we only do solution #2 and later on if we > hit the 32M limitation then will there be any binary compatibility > issue to implement the long calls. I think we have a different scheme > that doesn't use the PLT mechanism but can fix the 32M limitation > without loosing the binary compatibility. > > #3. Long call support without using the PLT mechanism: > ------------------------------------------------------ > > The basic problem is to replace the short call instruction with > an indirect function call. The short call is one instruction and > the long call using the function pointer requires 4 instructions. > I can't read your assembly language, but I think that this is what I was trying to suggest. (Just to be clear: your suggestion is just the right level: it shows we could keep binary compatibility and still break out of the 32M box, and your suggestion is not part of the case in that we are not approving this and we don't expect it implemented at this time.) My point is that the opinion says: > It was the concensus of the committee that we probably want > to do option 2 promptly and move to option 1 later (if and > when the 32Mb limitation becomes pressing). It was noted > however, that modules must be compiled for either direct or > PLT calls, and so switching models later will necessitate > recompiles of all dynamically loadable modules. > I don't want any indication in the opinion that we agree to recompiling dynamically loadable modules in the future. I think I agree with the project team, but just have a problem with the opinion. From markk@pongo73.West.Sun.COM Mon Jul 18 08:58:52 1994 Date: Mon, 18 Jul 1994 08:58:14 -0700 From: markk@pongo73.West.Sun.COM (Mark K.) To: Robert.H.@Eng, prasad@pongo.West.Sun.COM Subject: Re: PSARC 1994/188 PPC Kernel Cc: psarc@Eng, billt@pongo.West.Sun.COM, abe@pongo.West.Sun.COM, markk@pongo.West.Sun.COM, stevez@pongo.West.Sun.COM Content-Length: 620 > From Robert.H.@Eng Mon Jul 18 08:38 PDT 1994 > I think I agree with the project team, but just have a problem > with the opinion. I recognized that hole when I read your response. The updated opinion text now reads: It was the concensus of the committee that we probably want to do option 2 promptly and move to option 1 later (if and when the 32Mb limitation becomes pressing). The team offered an existance proof that it would be possible to go to a PLT-based calling scheme later without necessitating recompiles or re-links of any existing dynamically loadable object modules. From shannon@datsun Tue Jul 19 15:00:21 1994 Date: Tue, 19 Jul 1994 15:00:14 -0700 From: shannon@datsun (Bill Shannon) To: markk@pongo73.West.Sun.COM, psarc@Eng Subject: Re: PSARC 1994/188 PPC Kernel Cc: abe@pongo73.West.Sun.COM, billt@pongo73.West.Sun.COM, prasad@pongo73.West.Sun.COM Content-Length: 4009 Committee: Mark K., Steve C., Bruce D., Yousef K., Joseph Kowalski, Terrence M., Bill Shannon, Glenn Skinner, Scott Wilson I don't believe I attended any of the reviews, so I shouldn't be in the list. Scott is not a full member of PSARC and so shouldn't be in the list. 1993/685 Power PC ABI I'm surprised this project doesn't depend on the ABI project. Doesn't this kernel export many of the ABI interfaces? Most of the discussion focused on how reasonable it is for the PCFS implementation to have hard coded knowledge of media types and disk partitioning data structures. The con- clusion was that the existing PCFS implementation is not an architecturally good one, but that it would be unreasonable to force the project team to fix all of the problems at this time. Really? That's what you spent all your time talking about? Why? ________________________________________________________________ | Interfaces Exported | |__________________|__________________________|________________| |Interface | Classification | Comments | |__________________|__________________________|________________| |PROMIF functions | Project Private/Obsolete| | |console interfaces| Project Private | until 1993/408| |E_kvseg | Project Private | | |__________________|__________________________|________________| There's got to be lots of other interfaces, such as the ABI traps, the system call traps, etc. As an interrim solution, the team will use the existing (x86-based) NOP non-implementations to stub out these func- tions. It is expected, however, that when the PPC PROM functionality is defined, a new project will be created to use those services to more fully implement the corresponding functions. In particular, it is not expected that the stub implementations will be shipped with the product's FCS. But by approving this project you're saying it's ok to ship them, even if you expect that not to happen. Is that what you intend? I would've expected a dependency on the other project. The committee agreed that this was a reasonable approach, and noted that the PPC kernel project does not actually depend on the completion and integration of 1993/408. Until 1993/408 integrates, the PPC kernel can use its own copies of the necessary code (in platform specific directories). Doesn't this violate psarc/1991/061? 3.4. RAM disk driver One of the PROM services that is not yet defined/implemented in the IBM reference platform is general disk I/O. Without this service, it is very difficult to load a kernel into memory. To get around this problem, the team has defined an extremely large boot block ... one that contains an entire UFS file system with all of the files that need to be loaded in order to build a viable kernel. The PROM boot code reads the entire image into memory, and the Solaris bootstrap then treats that image as a RAMdisk, from which the necessary modules are loaded. This requires a minor change to the RAM disk driver. In other systems, the RAM disk driver allocates (a pre-defined size) and initializes the memory for the RAM disk when it is opened. On the Power PC, the memory for the RAM disk has already been allocated and initialized, and the size is a parameter passed in a global structure. The team indicated that this was only a short term porting aid and would not be part of any real product. Again, by approving this project, PSARC is saying it's ok to ship it as is. Is that what you intend? Option 2 requires changes to common code, and those changes must be reviewed by the ON owners ... but this is not an architectural issue. Right. Maybe this comment belongs in the Advisory Information section? From markk@sagredo.West.Sun.COM Tue Jul 19 15:47:15 1994 Date: Tue, 19 Jul 1994 15:47:06 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@Eng, Bill.Shannon@Eng Subject: Re: PSARC 1994/188 PPC Kernel Cc: abe@pongo73.West.Sun.COM, billt@pongo73.West.Sun.COM, prasad@pongo73.West.Sun.COM Content-Length: 3618 > From Bill.Shannon@Eng Tue Jul 19 15:00 PDT 1994 > > I don't believe I attended any of the reviews, so I shouldn't be > in the list. fixed > Scott is not a full member of PSARC and so shouldn't be in the list. fixed > 1993/685 Power PC ABI > > I'm surprised this project doesn't depend on the ABI project. > Doesn't this kernel export many of the ABI interfaces? This project only covers the enumerated issues. The PPC ABI project (presumably) includes the binary system call, trap and signal interfaces. Clearly, the PPC as a whole depends on the ABI, but I'm not sure the stuff described in this project does. > Most of the discussion focused on how reasonable it is for > the PCFS implementation ... > Really? That's what you spent all your time talking about? Why? I appologize. This was an artifact of creating this opinion by starting with another one. > There's got to be lots of other interfaces, such as the ABI traps, > the system call traps, etc. Which should be called out in the ABI project. No? > As an interrim solution, the team will use the existing > (x86-based) NOP non-implementations to stub out these func- > tions. It is expected, however, that when the PPC PROM > functionality is defined, a new project will be created to > use those services to more fully implement the corresponding > functions. In particular, it is not expected that the stub > implementations will be shipped with the product's FCS. > > But by approving this project you're saying it's ok to ship them, > even if you expect that not to happen. Is that what you intend? > I would've expected a dependency on the other project. At this moment, the other project cannot be done because neither the hardware nor the interface exists. Perhaps we should have an advisory to the SC that the ARC has approved this as an interrim step and that we strongly recommend that this be replaced with a real PROM interface prior to FCS. I don't expect a problem here, since the team agrees that this is not what they want to ship. > The committee agreed that this was a reasonable approach, > and noted that the PPC kernel project does not actually > depend on the completion and integration of 1993/408. Until > 1993/408 integrates, the PPC kernel can use its own copies > of the necessary code (in platform specific directories). > > Doesn't this violate psarc/1991/061? It does, but only for a short time ... and when 1993/408 shows up with its common code, the team is required to discard their private copies. Here again, I think the team and the ARC want the same thing, so I don't see a problem. > 3.4. RAM disk driver > The team indicated that this was only a short term porting > aid and would not be part of any real product. > > Again, by approving this project, PSARC is saying it's ok to ship > it as is. Is that what you intend? The team does not want to ship this, and given reasonable BIOS ROMs they won't. If, however, they are required to ship a product before the ROMs become available, they would have little choice but to ship this (because otherwise there is no booting). In that case, however, the kluge would still be consolidation private and would still be considered to be obsolete. I have added it to the exported interface table as "project private/obsolete" > Option 2 requires changes to common code, and those changes > must be reviewed by the ON owners ... but this is not an > architectural issue. > > Right. Maybe this comment belongs in the Advisory Information section? done From shannon@datsun Tue Jul 19 15:57:15 1994 Date: Tue, 19 Jul 1994 15:54:53 -0700 From: shannon@datsun (Bill Shannon) To: markk@sagredo.West.Sun.COM, psarc@Eng Subject: Re: PSARC 1994/188 PPC Kernel Cc: abe@pongo73.West.Sun.COM, billt@pongo73.West.Sun.COM, prasad@pongo73.West.Sun.COM Content-Length: 2909 > 1993/685 Power PC ABI > > I'm surprised this project doesn't depend on the ABI project. > Doesn't this kernel export many of the ABI interfaces? This project only covers the enumerated issues. The PPC ABI project (presumably) includes the binary system call, trap and signal interfaces. Clearly, the PPC as a whole depends on the ABI, but I'm not sure the stuff described in this project does. I'm not sure how you can *deliver* this project without also delivering those interfaces. Or, if you find a way to deliver this project without delivering any of these interfaces, I don't understand what good it is. What good is a kernel with *no* system call interface? If it's not delivering the ABI interface, it must be delivering some other interface, right? I thought the ABI project was to produce the *spec*. I expected this project to be the implementation of the spec. > As an interrim solution, the team will use the existing > (x86-based) NOP non-implementations to stub out these func- > tions. It is expected, however, that when the PPC PROM > functionality is defined, a new project will be created to > use those services to more fully implement the corresponding > functions. In particular, it is not expected that the stub > implementations will be shipped with the product's FCS. > > But by approving this project you're saying it's ok to ship them, > even if you expect that not to happen. Is that what you intend? > I would've expected a dependency on the other project. At this moment, the other project cannot be done because neither the hardware nor the interface exists. Perhaps we should have an advisory to the SC that the ARC has approved this as an interrim step and that we strongly recommend that this be replaced with a real PROM interface prior to FCS. I don't expect a problem here, since the team agrees that this is not what they want to ship. Things change. You've said it's ok that they ship this. Is that what you intend? If you intend that it *must* be replaced before shipping, you should say that. The opinion should reflect the ARC's *intent*, not its bet. > The committee agreed that this was a reasonable approach, > and noted that the PPC kernel project does not actually > depend on the completion and integration of 1993/408. Until > 1993/408 integrates, the PPC kernel can use its own copies > of the necessary code (in platform specific directories). > > Doesn't this violate psarc/1991/061? It does, but only for a short time ... and when 1993/408 shows up with its common code, the team is required to discard their private copies. Here again, I think the team and the ARC want the same thing, so I don't see a problem. See above. Also, it would be good to explicitly mention the short term exception you're granting to violate psarc/1991/061. From markk@sagredo.West.Sun.COM Tue Jul 19 18:13:07 1994 Date: Tue, 19 Jul 1994 18:12:57 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@Eng, Bill.Shannon@Eng Subject: Re: PSARC 1994/188 PPC Kernel Cc: abe@sagredo.West.Sun.COM, billt@sagredo.West.Sun.COM, prasad@sagredo.West.Sun.COM, stevez@sagredo.West.Sun.COM Content-Length: 2772 > From Bill.Shannon@Eng Tue Jul 19 15:57 PDT 1994 > > I'm surprised this project doesn't depend on the ABI project. > > Doesn't this kernel export many of the ABI interfaces? > > This project only covers the enumerated issues. The > PPC ABI project (presumably) includes the binary system > call, trap and signal interfaces. Clearly, the PPC > as a whole depends on the ABI, but I'm not sure the > stuff described in this project does. > > I'm not sure how you can *deliver* this project without also delivering > those interfaces. Or, if you find a way to deliver this project without > delivering any of these interfaces, I don't understand what good it is. > What good is a kernel with *no* system call interface? If it's not > delivering the ABI interface, it must be delivering some other interface, > right? I spoke to Abe and Steve about this. The ABI project is not delivering any code so the system call numbers, system call linkage conventions, and trap/signal conventions are indeed part of this project. The team believes that there were no "issues" in this stuff, but they do indeed constitute interfaces and should be presented for review and approval. I will ask Prasad to provide documentation for the system call, trap and signal interfaces and have added them to the interface table (as Consolidation Private). We should probably delay the vote on this project until those specs are available, so that people can have an opportunity to decide whether or not they contain "no issues". As to dependency of this project on the ABI. There certainly are parts of the kernel that implement ABI requirements (like the memory layout, page size, the initial register/stack state of a process, and the mapping from hardware exceptions to signals), so the dependency of this project on the ABI does indeed need to be called out. I have made this change to the opinion. > Things change. You've said it's ok that they ship this. Is that what > you intend? If you intend that it *must* be replaced before shipping, > you should say that. The opinion should reflect the ARC's *intent*, > not its bet. If it is not possible to use the real BIOS (like because it doesn't become available soon enough) then it should certainly be acceptable for the project to ship with the NOP implementation ... since (a) the alternative is not to ship at all (b) the interfaces in question are project private I do not think that it "must" be replaced ... but it is strongly encouraged that it be replaced, and the team agrees. I think the "expectation" expressed in the opinion conveys the right message. > See above. Also, it would be good to explicitly mention the short term > exception you're granting to violate psarc/1991/061. done From jek3@jurassic Wed Jul 20 12:19:37 1994 Date: Wed, 20 Jul 1994 12:23:54 +0800 From: jek3@jurassic (Joseph Kowalski) To: psarc@Eng, Bill.Shannon@Eng, markk@sagredo.West.Sun.COM Subject: Re: PSARC 1994/188 PPC Kernel Cc: abe@sagredo.West.Sun.COM, billt@sagredo.West.Sun.COM, prasad@sagredo.West.Sun.COM, stevez@sagredo.West.Sun.COM Content-Length: 1350 > From markk@sagredo.West.Sun.COM Tue Jul 19 18:19 PDT 1994 > > If it is not possible to use the real BIOS (like because it doesn't become > available soon enough) then it should certainly be acceptable for the > project to ship with the NOP implementation ... since > > (a) the alternative is not to ship at all > (b) the interfaces in question are project private > > I do not think that it "must" be replaced ... but it is strongly > encouraged that it be replaced, and the team agrees. I think the > "expectation" expressed in the opinion conveys the right message. I've been staying out of this because Bill has been doing such a good job.... 8^) However, on this point I must disagree. I don't want to set ourselves up to support a small number of machines with the NOP implementation because things were shipped and commitments were made. I'd much rather see a hard statement made that shipping to this interface is only acceptable for something like "early access with signed disclaimers". If several months down the road we see a problem with PROM/BIOS implementations, we can do the ARC work to ammend this descision. Maybe the opinion should "Just say NO" and we can ammend it even for early access. I really don't want to buy ourselves bigger support issues if we can avoid it, particularly when PROMS are involved. - jek3 From markk@sagredo.West.Sun.COM Wed Jul 20 16:20:02 1994 Date: Wed, 20 Jul 1994 16:19:52 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@Eng Subject: PSARC 1994/188 Power PC Kernel, Opinion for Review Content-Length: 15505 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Power PC Kernel Port Submitted by: Prasad Singamsetty File: psarc/1994/188/opinion.ms Date: July 20th, 1994 Committee: Mark K., Steve C., Bruce D., Robert H., Yousef K., Joseph Kowal- ski, Terrence M., Glenn Skinner. 1. Summary The Power PC (PPC) is a new instruction set architecture that has the potential to challenge the Intel x86 architecture's market share. The basic Instruction Set Architecture is described by the Power PC Architecture [2,3], and there are currently two chips in the PPC family. The 601 is designed for more powerful (potentially MP) sys- tems. The 603 is designed for notebook computers. There is a PReP specification [4] that provides a high level functional specification for Power PC platforms, but it is too general to be useful for an implementation. The only major PPC platform available at this time is the IBM Refer- ence Implementation. The primary goal of the Power PC kernel port is to extend the Solaris kernel to be able to support the 601- and 603- based IBM Reference Implementation platforms for the Power PC. A secondary goal is the creation of a framework for supporting other Power PC platforms. It should be noted that even the architecture for the IBM reference implementations is still in a state of flux. Many important details (like MP architecture and BIOS interface specifications) are still not fully defined. Because PPC platform specifications are still in such a fluid state, it should be assumed that additional PPC platform support pro- jects will have to be created to support the real product platforms when they become available. 2. Decision & Precedence Information The project is accepted, subject to the changes enumerated in Appendix A. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 2 - The classification of the change introduced by this project is micro. It should also be noted that this project represents only part of the work required in order to fully support Solaris on the PPC. The other basic PPC projects are: 1993/685 Power PC ABI 1994/196 Power PC Header files 1994/197 Power PC Commands There are several aspects of the PPC Kernel that are depen- dent on the PPC ABI specification: The virtual address space layout seen by user processes. The page size seen by user processes. The mapping of hardware exceptions into signals types. The initial state of a newly forked process (registers, stack frame, uxiliary vector). Because of these dependencies, this project is dependent on the approval of 1993/685 (PPC ABI). 3. Opinion ____________________________________________________________________ | Interfaces Exported | |______________________|__________________________|________________| |Interface | Classification | Comments | |______________________|__________________________|________________| |PROMIF functions | Project Private/Obsolete| | |console interfaces | Project Private | until 1993/408| |E_kvseg | Project Private | | |RAMdisk extensions | Project Private/Obsolete| | |System call numbers[5]| Consolidation Private | | |System call linkage[5]| Consolidation Private | | |Signal/Trap linkage[5]| Consolidation Private | | |______________________|__________________________|________________| Although numerous changes are being made to the Solaris Ker- nel in order to accomplish the Power PC port, the majority of these changes are obvious ones with no architectural con- tent (e.g. device drivers and ISA specific implementations of platform dependent functions). These received little discussion. The majority of the discussion focused on a half-dozen issues. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 3 - 3.1. MP Support There is not currently a standard or reference implementa- tion for PPC based MP machines. The team proposes not to include any MP work in this project. They will, however, not do anything to preclude MP support and will ensure that all new code is written to be appropriately MP-safe/hot. The committee agreed with this proposal, but expects to see a new project created to add support for PPC MP platforms at a later date. 3.2. PROMIF Support The PReP spec calls for Open Firmware PROM/BIOS, but does not define any interfaces to it. The IBM reference imple- mentation does not yet provide or define these services. Since these services are not yet available, the initial ker- nel port (this project) will not attempt to provide an interface to them. As an interrim solution, the team will use the existing (x86-based) NOP non-implementations to stub out these func- tions. It is expected, however, that when the PPC PROM functionality is defined, a new project will be created to use those services to more fully implement the corresponding functions. In particular, it is not expected that the stub implementations will be shipped with the product's FCS. It should be noted, however, that there may be PPC platforms that do not provide the Open Firmware support. If such machines exist, and Solaris is to support them, it may be necessary to retain the stub versions of the PROMIF func- tions and provide other implementations for needed boot-time functionality. The committee agreed with this approach and approves the stubbed PROMIF support for put-back, but not for FCS ship- ment. 3.3. Dependency on 1993/408 The PPC reference implementation uses keyboard and display controllers that are very similar to those on the x86, and so it makes sense to base the PPC drivers on the x86 ver- sions. The x86 keyboard and display architecture, however, is currently in a major state of flux (1993/408). The team was forced to choose between basing the PPC port on an implementation that was becoming obsolete or an implemen- tation that was not yet available. They chose the latter, and have been working very closely with the console redesign team. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 4 - The committee agreed that this was a reasonable approach, and noted that the PPC kernel project does not actually depend on the completion and integration of 1993/408. Until 1993/408 integrates, the PPC kernel can use its own copies of the necessary code (in platform specific directories). The major concern was the fire drill that would result in the source tree when this project checked new console code in (in platform dependent directories) and then the console redesign team checked a slightly different version into com- mon directories. The committee recommended that an effort be made to accelerate the check-in of the portions of the new console implementation that the PPC port needed in order to avoid this confusion. If such an accelerated check-in is not possible, the team is authorized to check their versions of this code in (as plat- form specific code), but they must assume the responsibility for all necessary changes when the common code from 1993/408 is put back. Allowing the PPC project to check in a potentially redundant copy of common code into a platform specific directory is a violation of 1991/061. It will only be permitted for a very brief period of time, and the team will be required to com- ply with 1991/061 after 1993/408 integrates. 3.4. RAM Disk Driver One of the PROM services that is not yet defined or imple- mented in the IBM reference platform is general disk I/O. Without this service, it is very difficult to load a kernel into memory. To get around this problem, the team has defined an extremely large boot block, one that contains an entire ufs file system with all of the files that need to be loaded in order to build a viable kernel. The PROM boot code reads the entire image into memory, and the Solaris bootstrap then treats that image as a ram-disk, from which the necessary modules are loaded. This requires a minor change to the ram-disk driver. In other systems, the ram-disk driver allocates (a pre-defined size) and initializes the memory for the ram-disk when it is opened. On the Power PC, the memory for the ram-disk has already been allocated and initialized, and the size is a parameter passed in a global structure. The team indicated that this was only a short term porting aid and would not be part of any real product. The commit- tee had no objection to this. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 5 - 3.5. 32MB Short Call Limitation The PPC ISA has an efficient relative short call that is limited to a range of plus/minus 32Mb. Calls within the main kernel, and within dynamically loaded modules easily fit within this range, but calls between the main kernel and dynamically loaded modules may not. This is not a problem on Sparc or X86 because the standard call instructions on those ISAs have a much wider range. In the short term, the team has limited Sysmap to 16M and set SYSBASE (the base for dynamically loaded modules) to KERNELBASE+16M ... thus restricting the core kernel and all of its data structures to 16Mb. Ultimately, however, this limitation may prove to be unreasonably restrictive and a better solution must be found. Two alternatives were pro- posed: 1. use Procedure Linkage Tables (PLTs) for linking kernel modules. 2. use a separate segment within the kernel address space for dynamically loadable modules and keep them within 32Mb of the core kernel. The first option requires complex changes to kobj and imposes a performance hit on the function calls that go through the PLTs (e.g. every call to mutex_enter). The second option requires the creation of a new segment and a new set of allocation routines to manage the space in that segment. The second option is also more restrictive (in that it requires the core kernel and the text+data of all dynamically loaded modules to fit within 32Mb). It was the consensus of the committee that we probably want to do option 2 promptly and move to option 1 later (if and when the 32Mb limitation becomes pressing). The committee expressed concern that a more general solution in the future should not necessitate recompilation or re-linking of exist- ing dynamically loadable object modules. The team offered an "existence proof" design to show that binary compatibil- ity could be maintained, and the committee was satisfied. Option 2 requires changes to common code, and those changes must be reviewed by the ON owners, but this is not an archi- tectural issue. A more detailed description of how this will be implemented can be found in the supplementary materials directory for this case (PSARC/1994/188/materials/kobj.proposal[1]). 3.6. Platform Specific Module Interface Although all of the PPC platforms have not yet been defined, psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 6 - the team anticipates considerable diversity among them and wants to provide a general framework for platform specific modules. Due to similarities with x86 interrupt controllers and MMUs, the team proposed to use the x86 MP Platform Specific Module interface and implementation (1993/622) as a starting point for the PPC implementation. The motivation behind 1993/622 was MP support, and MP sup- port is not an issue in this project, but the team argued that most of the functions in that framework are not MP specific and that many of the implementations are already very close to what is needed on the PPC. The committee expressed concern that there was a significant overlap between these functions and KBI phase 2, and that it seemed inappropriate to sanction a different interface to solve the same problems a little bit sooner. It was also observed that the need for a general framework for PSMs was only hypothetical, since Solaris is not expected to run on other PPC platforms in the next twelve months. The committee suggested that the PPC kernel team work with the KBI team to ensure that the KBI would adequately answer x86, x86mp, and PPC needs for Platform Specific Modules. If extensions are required, these should be made as part of KBI-2 or some new project. 4. Minority Opinion(s) None. 5. Advisory Information 5.1. Dependency on 1993/408 The decision to use the new console architecture (1993/408) in this project is a reasonable one, but the committee is concerned that this project proposes to deliver its code before 1993/408. The PPC team should negotiate with the new console team to see if the put-back of the code that the PPC project requires can be accelerated. If this is not possible the PPC team is authorized to put their version of the console support back into a platform dependent directory. Later, when the console team does their put-back, the PPC team must handle the resync and reconciliation work that is required in order to use the new code from the console team. 5.2. Stubbed PROMIF Implementation The decision to use the existing x86 code to stub out the PROMIF functions is an appropriate one at this time. When psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 7 - proper PROMIF specifications and implementations become available, it is expected that the NOP implementation will be replaced with a more complete one. It is expected that this will happen prior to FCS. If this cannot be done prior to FCS the team must return to PSARC for another approval. 5.3. Work-around for 32Mb Call Limitation The common module changes required to implement the new seg- ment and ensure that dynamically loadable modules and the kernel proper are all kept within a 32Mb range should be reviewed by the appropriate ON code owners prior to put- back. 6. Appendices 6.1. Appendix A: Technical Changes Required The proposed platform specific module interface overlaps with interfaces that are to be addressed by the KBI and it seems inappropriate to create a conflicting standard for these functions. The platform specific module support framework must be removed into a separate project, in which x86, PPC and KBI concerns will all be reconciled. 6.2. Appendix B: Technical Changes Advised None. 6.3. Appendix C: Reference Material 1. PSARC/1994/188/materials/kobj.proposal 2. PowerPC 601 User's Manual, Motorola 3. PowerPC Processor Architecture (Books I-III), IBM 4. PowerPC Reference Platform Specification (PReP) 5 PSARC/1994/188/materials/???TBD??? psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. From markk@sagredo.West.Sun.COM Fri Jul 22 17:48:51 1994 Date: Fri, 22 Jul 1994 17:48:41 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@Eng Subject: PSARC 1994/188 PPC kernel Content-Length: 2061 Glenn expressed concerns with the opinion's wording on the stubbing of the PROMIF functions. Based on those concerns, I have made the following change to the opinion proper: < The committee agreed with this approach and approves the < stubbed PROMIF support for put-back, but not for FCS ship- < ment. --- > The committee felt that code maintainability, product sup- > portability, and our ability to run on multiple PPC plat- > forms would be compromised if the FCS product did not > include support for Open Boot Prom functionality. The > approval of this project for shipment is dependent on the > completion of another (not yet submitted) project to provide > Open Boot Firmware support (and if necessary a solution for > legacy non-OBP systems). The acceptability of the stubbing as an interim solution was then moved into the advisory section: < 5.2. Stubbed PROMIF Implementation < < The decision to use the existing x86 code to stub out the < PROMIF functions is an appropriate one at this time. When < proper PROMIF specifications and implementations become < available, it is expected that the NOP implementation will < be replaced with a more complete one. It is expected that < this will happen prior to FCS. If this cannot be done prior < to FCS the team must return to PSARC for another approval. --- > 5.2. Stubbed PROMIF Implementation > > Because there are not yet any PPC machines with Open Boot > Firmware, the interim decision to use the existing x86 code > to stub out the PROMIF functions is an appropriate one (and > necessary in order to proceed with the other aspects of the > PPC port). This is not, however, acceptable for final ship- > ment. > > When proper PROMIF specifications and implementations become > available, a new project must be created to replace the stub > implementation with a more complete exploitation of the Open > Boot Firmware. If this proves infeasible, the team must > return to PSARC for approval of a different PROMIF support > strategy. From markk@sagredo.West.Sun.COM Thu Jul 28 09:26:58 1994 Date: Thu, 28 Jul 1994 09:26:46 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: psarc@Eng Subject: PSARC 1994/188 (PPC Kernel) Cc: prasad@sagredo.West.Sun.COM, billt@sagredo.West.Sun.COM, abe@sagredo.West.Sun.COM Content-Type: X-sun-attachment Content-Length: 9235 ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 7 The team has submitted the requested specifications for system call numbers and the linkage conventions associated with system calls, and signal delivery from the kernel to user mode. The opinion has been updated to reflect the names of the two files. I am also enclosing them here for your review. ---------- X-Sun-Data-Type: default X-Sun-Data-Name: abi.specs X-Sun-Charset: us-ascii X-Sun-Content-Lines: 202 PowerPC KERNEL PROJECT (1994/188) ================================= This document describes the interfaces implemented for system calls, traps and signals. Signals: ------- The signal codes are same as Sparc/X86 implementation. A copy of the uts/ppc/sys/machsig.h is attached. The semantics of implementation for calling the user signal handler is similar to Sparc. The user signal handler 'hdlr' is called as: hdlr(int signo, siginfo_t *sip, ucontext_t *uc) The arguments are passed in registers according to the normal linkage conventions: r3 = signal number r4 = siginfo pointer or NULL if no siginfo is available r5 = ucontext pointer LR = -1 (invalid return pc in Link Register) 0(sp) = old stack pointer The signal frame created on the user stack looks like: ^ ^ HIGH ADDR (bottom) | | : : |-----------------------| <== old sp | | | ucontext structure | size1 = sizeof(ucontext_t) | | |-----------------------| <== r5 | | | siginfo structure | size2 = sizeof(siginfo_t) or 0 | if it is available | | | |-----------------------| <== r4 (NULL if no siginfo) | | | MINFRAME | size3 = MINFRAME | | |-----------------------| <== sp (SA(old_sp-(size1+size2+size3))) | | | | v v LOW ADDR (top) System calls: ------------ The list of system calls supported, the system call numbers and the semantics of the implementation for PPC is same as on Sparc. Note: The system call entry table in the kernel is defined in the common file 'common/os/sysent.c' which has no changes for PPC. Syscall instruction: The 'sc' (system-call) instruction is used for trapping into the kernel. Syscall arguments: Since the max numbers of arguments to a system call is limited to 8 (MAXSYSARGS is defined in common/sys/lwp.h) all the arguments to the system call are already in the volatile registers (r3 - r10). The system call number is passed in the volatile register r0. Return value(s); The return value(s) from the system call are passed in r3 and r4 as in Sparc (%o0 and %o1). Error return: The error code is returned in r3. The summary overflow bit (CR0_SO) in the condition register CR0 indicates error return. Restartable system calls: (e.g. fcntl, getmsg, getpmsg, ioctl, etc.) For restartable system calls we need to save the first argument because upon return from the system call r3 is clobbered. For this, the system call stub in the library copies r3 into r10 and restores it before restarting the system call. The volatile register r10 is used because none of the restartable system calls have more than 5 arguments (i.e only r3-r7 are used). If the restartable system call has more than 7 arguments then the system call stub in the library need to create a stack frame for saving the first argument. The list of all the restartable system calls: Name # args ================================ fcntl() 2+ getmsg() 4 getpmsg() 5 ioctl() 2+ lwp_mutex_lock()1 poll() 3 pread() 4 putmsg() 4 putpmsg() 5 pwrite() 4 read() 3 readv() 3 lwp_sema_wait() 1 wait() 1 waitid() 4 write() 3 writev() 3 Note: The list of restartable system calls are same as on Sparc/X86. Fast system calls: ----------------- This is a private interface between the libraries and the kernel. The current list of fast system calls implemented for PPC: fast syscall#s -------------- SC_GETLWPFPU 1 To find out if FPU context is setup for the lwp. This is used in the threads library. There are no arguments to this system call. It returns the value of the pcb_flags (from the kernel lwp structure) in r3. SC_GETHRTIME 2 Same as on Sparc/x86. SC_GETHRESTIME 3 Same as on Sparc/x86. SC_GETHRVTIME 4 Same as on Sparc/x86. Fast system call instruction: The regular system call instruction 'sc' is used with the system call number as -1 in r0 and fast system call number in r3. The system call interrupt handler in the kernel checks for the fast system calls. For invalid fast system calls the kernel returns ENOSYS error. Exceptions/Traps: ---------------- Only the breakpoint traps and floating point exceptions are discussed here. Other exceptions/traps are within the kernel and their interface is not exported outside the kernel. Breakpoint traps: On PowerPC the trap instruction tw/twi (similar to trap instruction 't' on Sparc) can be used to generate program exceptions. For Solaris port to PPC we are using 'tw 31,0,0' (i.e trap unconditional) instruction for breakpoint traps. The kernel trap handler for 'program check exception' decodes the trap instruction and it currently recognizes only the breakpoint instruction. For other tw/twi instructions the kernel generates SIGILL signal. Note: On PowerPC hw breakpoints are supported thru the implementation specific HID registers (implemented differently on different CPU architectures) and these are currently not supported in Solaris for PPC. The signal code SIGTRAP and fault code TRAP_BKPT is generated for breakpoint traps. Floating point exceptions: On PowerPC a 'program check exception' is generated when a floating instruction causes an enabled exception. The PowerPC ABI specifies the initial value of FPSCR (Floating Point Status and Control Register) which enables floating point exceptions. The following are the signal codes for different floating enabled exceptions. FPE_FLTOVF For floating point overflow exception. FPE_FLTUND For floating point underflow exception. FPE_FLTDIV For floating point zero divide exception. FPE_FLTRES For floating point inexact result exception. FPE_FLTINV For other floating point exceptions. The signal number SIGFPE is generated for any of the floating enabled exceptions. Other interesting traps/exceptions: Alignment trap: The kernel generates SIGBUS signal with a fault code of FLTACCESS. Text/Data faults: The signal codes and fault codes are similar to Sparc/X86. Illegal instruction trap (thru 'program check exception'): The signal code (SIGILL) and fault code (ILL_ILLOPC) are same as on Sparc/X86. Privileged instruction trap (thru 'prgoram check exception'): The signal code (SIGILL) and fault code (ILL_PRVOPC) are same as on Sparc/X86. Single Step trap ('trace trap' on PowerPC, 'run mode trap' on 601): The signal code (SIGTRAP) and fault code (TRAP_TRACE) are same as on Sparc/X86. ---------- << attachment deleted >> From markk@sagredo.West.Sun.COM Tue Aug 2 08:08:10 1994 Date: Tue, 2 Aug 1994 08:07:55 -0700 From: markk@sagredo.West.Sun.COM (Mark K.) To: sac-review@sac.Eng.Sun.COM Subject: PSARC 1994/188 (Power PC Kernel) Cc: prasad@sagredo.West.Sun.COM, abe@sagredo.West.Sun.COM Content-Length: 16199 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: Power PC Kernel Port Submitted by: Prasad Singamsetty File: psarc/1994/188/opinion.ms Date: July 20th, 1994 Committee: Mark K., Steve C., Bruce D., Robert H., Yousef K., Joseph Kowal- ski, Terrence M., Glenn Skinner. 1. Summary The Power PC (PPC) is a new instruction set architecture that has the potential to challenge the Intel x86 architecture's market share. The basic Instruction Set Architecture is described by the Power PC Architecture [2,3], and there are currently two chips in the PPC family. The 601 is designed for more powerful (potentially MP) sys- tems. The 603 is designed for notebook computers. There is a PReP specification [4] that provides a high level functional specification for Power PC platforms, but it is too general to be useful for an implementation. The only major PPC platform available at this time is the IBM Refer- ence Implementation. The primary goal of the Power PC kernel port is to extend the Solaris kernel to be able to support the 601- and 603- based IBM Reference Implementation platforms for the Power PC. A secondary goal is the creation of a framework for supporting other Power PC platforms. It should be noted that even the architecture for the IBM reference implementations is still in a state of flux. Many important details (like MP architecture and BIOS interface specifications) are still not fully defined. Because PPC platform specifications are still in such a fluid state, it should be assumed that additional PPC platform support pro- jects will have to be created to support the real product platforms when they become available. 2. Decision & Precedence Information The project is accepted, subject to the changes enumerated in Appendix A. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 2 - The classification of the change introduced by this project is micro. It should also be noted that this project represents only part of the work required in order to fully support Solaris on the PPC. The other basic PPC projects are: 1993/685 Power PC ABI 1994/196 Power PC Header files 1994/197 Power PC Commands There are several aspects of the PPC Kernel that are depen- dent on the PPC ABI specification: The virtual address space layout seen by user processes. The page size seen by user processes. The mapping of hardware exceptions into signals types. The initial state of a newly forked process (registers, stack frame, auxiliary vector). Because of these dependencies, this project is dependent on the approval of 1993/685 (PPC ABI). 3. Opinion ______________________________________________________________________ | Interfaces Exported | |________________________|__________________________|________________| |Interface | Classification | Comments | |________________________|__________________________|________________| |PROMIF functions | Project Private/Obsolete| | |console interfaces | Project Private | until 1993/408| |E_kvseg | Project Private | | |RAMdisk extensions | Project Private/Obsolete| | |System call numbers[5] | Consolidation Private | | |System call linkage[5] | Consolidation Private | | |Signal/Trap linkage[5,6]| Consolidation Private | | |________________________|__________________________|________________| Although numerous changes are being made to the Solaris Ker- nel in order to accomplish the Power PC port, the majority of these changes are obvious ones with no architectural con- tent (e.g. device drivers and ISA specific implementations of platform dependent functions). These received little discussion. The majority of the discussion focused on a half-dozen issues. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 3 - 3.1. MP Support There is not currently a standard or reference implementa- tion for PPC based MP machines. The team proposes not to include any MP work in this project. They will, however, not do anything to preclude MP support and will ensure that all new code is written to be appropriately MP-safe/hot. The committee agreed with this proposal, but expects to see a new project created to add support for PPC MP platforms at a later date. 3.2. PROMIF Support The PReP spec calls for Open Firmware PROM/BIOS, but does not define any interfaces to it. The IBM reference imple- mentation does not yet provide or define these services. Since these services are not yet available, the initial ker- nel port (this project) will not attempt to provide an interface to them. As an interim solution, the team will use the existing (x86-based) NOP non-implementations to stub out these func- tions. It is expected, however, that when the PPC PROM functionality is defined, a new project will be created to use those services to more fully implement the corresponding functions. In particular, it is not expected that the stub implementations will be shipped with the product's FCS. It should be noted, however, that there may be PPC platforms that do not provide the Open Firmware support. If such machines exist, and Solaris is to support them, it may be necessary to retain the stub versions of the PROMIF func- tions and provide other implementations for needed boot-time functionality. The committee felt that code maintainability, product sup- portability, and our ability to run on multiple PPC plat- forms would be compromised if the FCS product did not include support for Open Boot Prom functionality. The approval of this project for shipment is dependent on the completion of another (not yet submitted) project to provide Open Boot Firmware support (and if necessary a solution for legacy non-OBP systems). 3.3. Dependency on 1993/408 The PPC reference implementation uses keyboard and display controllers that are very similar to those on the x86, and so it makes sense to base the PPC drivers on the x86 ver- sions. The x86 keyboard and display architecture, however, is currently in a major state of flux (1993/408). The team was forced to choose between basing the PPC port on psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 4 - an implementation that was becoming obsolete or an implemen- tation that was not yet available. They chose the latter, and have been working very closely with the console redesign team. The committee agreed that this was a reasonable approach, and noted that the PPC kernel project does not actually depend on the completion and integration of 1993/408. Until 1993/408 integrates, the PPC kernel can use its own copies of the necessary code (in platform specific directories). The major concern was the fire drill that would result in the source tree when this project checked new console code in (in platform dependent directories) and then the console redesign team checked a slightly different version into com- mon directories. The committee recommended that an effort be made to accelerate the check-in of the portions of the new console implementation that the PPC port needed in order to avoid this confusion. If such an accelerated check-in is not possible, the team is authorized to check their versions of this code in (as plat- form specific code), but they must assume the responsibility for all necessary changes when the common code from 1993/408 is put back. Allowing the PPC project to check in a potentially redundant copy of common code into a platform specific directory is a violation of 1991/061. It will only be permitted for a very brief period of time, and the team will be required to com- ply with 1991/061 after 1993/408 integrates. 3.4. RAM Disk Driver One of the PROM services that is not yet defined or imple- mented in the IBM reference platform is general disk I/O. Without this service, it is very difficult to load a kernel into memory. To get around this problem, the team has defined an extremely large boot block, one that contains an entire ufs file system with all of the files that need to be loaded in order to build a viable kernel. The PROM boot code reads the entire image into memory, and the Solaris bootstrap then treats that image as a ram-disk, from which the necessary modules are loaded. This requires a minor change to the ram-disk driver. In other systems, the ram-disk driver allocates (a pre-defined size) and initializes the memory for the ram-disk when it is opened. On the Power PC, the memory for the ram-disk has already been allocated and initialized, and the size is a parameter passed in a global structure. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 5 - The team indicated that this was only a short term porting aid and would not be part of any real product. The commit- tee had no objection to this. 3.5. 32MB Short Call Limitation The PPC ISA has an efficient relative short call that is limited to a range of plus/minus 32Mb. Calls within the main kernel, and within dynamically loaded modules easily fit within this range, but calls between the main kernel and dynamically loaded modules may not. This is not a problem on Sparc or X86 because the standard call instructions on those ISAs have a much wider range. In the short term, the team has limited Sysmap to 16M and set SYSBASE (the base for dynamically loaded modules) to KERNELBASE+16M ... thus restricting the core kernel and all of its data structures to 16Mb. Ultimately, however, this limitation may prove to be unreasonably restrictive and a better solution must be found. Two alternatives were pro- posed: 1. use Procedure Linkage Tables (PLTs) for linking kernel modules. 2. use a separate segment within the kernel address space for dynamically loadable modules and keep them within 32Mb of the core kernel. The first option requires complex changes to kobj and imposes a performance hit on the function calls that go through the PLTs (e.g. every call to mutex_enter). The second option requires the creation of a new segment and a new set of allocation routines to manage the space in that segment. The second option is also more restrictive (in that it requires the core kernel and the text+data of all dynamically loaded modules to fit within 32Mb). It was the consensus of the committee that we probably want to do option 2 promptly and move to option 1 later (if and when the 32Mb limitation becomes pressing). The committee expressed concern that a more general solution in the future should not necessitate recompilation or re-linking of exist- ing dynamically loadable object modules. The team offered an "existence proof" design to show that binary compatibil- ity could be maintained, and the committee was satisfied. Option 2 requires changes to common code, and those changes must be reviewed by the ON owners, but this is not an archi- tectural issue. A more detailed description of how this will be implemented can be found in the supplementary materials directory for this case (PSARC/1994/188/materials/kobj.proposal[1]). psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 6 - 3.6. Platform Specific Module Interface Although all of the PPC platforms have not yet been defined, the team anticipates considerable diversity among them and wants to provide a general framework for platform specific modules. Due to similarities with x86 interrupt controllers and MMUs, the team proposed to use the x86 MP Platform Specific Module interface and implementation (1993/622) as a starting point for the PPC implementation. The motivation behind 1993/622 was MP support, and MP sup- port is not an issue in this project, but the team argued that most of the functions in that framework are not MP specific and that many of the implementations are already very close to what is needed on the PPC. The committee expressed concern that there was a significant overlap between these functions and KBI phase 2, and that it seemed inappropriate to sanction a different interface to solve the same problems a little bit sooner. It was also observed that the need for a general framework for PSMs was only hypothetical, since Solaris is not expected to run on other PPC platforms in the next twelve months. The committee suggested that the PPC kernel team work with the KBI team to ensure that the KBI would adequately answer x86, x86mp, and PPC needs for Platform Specific Modules. If extensions are required, these should be made as part of KBI-2 or some new project. 4. Minority Opinion(s) None. 5. Advisory Information 5.1. Dependency on 1993/408 The decision to use the new console architecture (1993/408) in this project is a reasonable one, but the committee is concerned that this project proposes to deliver its code before 1993/408. The PPC team should negotiate with the new console team to see if the put-back of the code that the PPC project requires can be accelerated. If this is not possible the PPC team is authorized to put their version of the console support back into a platform dependent directory. Later, when the console team does their put-back, the PPC team must handle the resync and reconciliation work that is required in order to use the new code from the console team. psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 7 - 5.2. Stubbed PROMIF Implementation Because there are not yet any PPC machines with Open Boot Firmware, the interim decision to use the existing x86 code to stub out the PROMIF functions is an appropriate one (and necessary in order to proceed with the other aspects of the PPC port). This is not, however, acceptable for final ship- ment. When proper PROMIF specifications and implementations become available, a new project must be created to replace the stub implementation with a more complete exploitation of the Open Boot Firmware. If this proves infeasible, the team must return to PSARC for approval of a different PROMIF support strategy. 5.3. Work-around for 32Mb Call Limitation The common module changes required to implement the new seg- ment and ensure that dynamically loadable modules and the kernel proper are all kept within a 32Mb range should be reviewed by the appropriate ON code owners prior to put- back. 6. Appendices 6.1. Appendix A: Technical Changes Required The proposed platform specific module interface overlaps with interfaces that are to be addressed by the KBI and it seems inappropriate to create a conflicting standard for these functions. The platform specific module support framework must be removed into a separate project, in which x86, PPC and KBI concerns will all be reconciled. 6.2. Appendix B: Technical Changes Advised None. 6.3. Appendix C: Reference Material 1. PSARC/1994/188/materials/kobj.proposal 2. PowerPC 601 User's Manual, Motorola 3. PowerPC Processor Architecture (Books I-III), IBM 4. PowerPC Reference Platform Specification (PReP) 5 PSARC/1994/188/materials/abi.specs psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. - 8 - 6 PSARC/1994/188/materials/machsig.h psarc/1994/188 Copyright 1994 Sun Microsystems, Inc. From roland.mainz@nrubsig.org Wed May 6 19:54:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n472sd2C008114 for ; Wed, 6 May 2009 19:54:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n472sXGC029298; Thu, 7 May 2009 03:54:38 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KJ900E0J6QXUH00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KJ900BSP6QX2670@nwk-avmta-2.sfbay.sun.com>; Wed, 06 May 2009 19:54:33 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n472lgI1023995; Thu, 07 May 2009 02:54:32 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-1721496; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-524814; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-09.arcor-online.net ([151.189.21.49] [151.189.21.49]) by relay1i.sun.com with ESMTP id BT-MMP-5769081; Thu, 07 May 2009 02:54:32 +0000 (Z) Received: from mail-in-10-z2.arcor-online.net (mail-in-10-z2.arcor-online.net [151.189.8.27]) by mx.arcor.de (Postfix) with ESMTP id E20561AF2FA; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from mail-in-11.arcor-online.net (mail-in-11.arcor-online.net [151.189.21.51]) by mail-in-10-z2.arcor-online.net (Postfix) with ESMTP id CA18723D2B5; Thu, 07 May 2009 04:16:49 +0200 (CEST) Received: from jupiterb48.nrubsig.org (dslb-094-219-212-156.pools.arcor-ip.net [94.219.212.156]) by mail-in-11.arcor-online.net (Postfix) with ESMTPS id 27B9EE38FE; Thu, 07 May 2009 04:16:48 +0200 (CEST) Received: from nrubsig.org (localhost [127.0.0.1]) by jupiterb48.nrubsig.org (8.13.8+Sun/8.13.8) with ESMTP id n472GkrR002190; Thu, 07 May 2009 04:16:47 +0200 (CEST) Date: Thu, 07 May 2009 04:16:46 +0200 From: Roland Mainz Subject: Requesting ARC cases 1993/685, 1994/188, 1994/196, 1994/197, 1994/302, 1995/077, 1995/082, 1995/153 Sender: gisburn@jupiterb48.nrubsig.org To: opensolaris-arc@opensolaris.org Cc: Bonnie Corwin , "PSARC-EXT@sun.com" , emerging-platforms-discuss@opensolaris.org Message-id: <4A02448E.1AC9B6BA@nrubsig.org> MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.11 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DKIM: Sendmail DKIM Filter v2.8.2 mail-in-11.arcor-online.net 27B9EE38FE X-Antispam: No, score=0.0/5.0, scanned in 0.057sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ x_sac_archived: PSARC/1993/685 Status: RO Content-Length: 704 hi! ---- I'd like to request to open the following ARC cases for publish access: PSARC 1993/685 PowerPC_ABI PSARC 1994/188 Solaris Kernel for PowerPC PSARC 1994/196 PowerPC Header Files PSARC 1994/197 PowerPC Commands PSARC 1994/302 PowerPC_Booting PSARC 1995/077 processor_info(2) binding for PowerPC and future ISAs PSARC 1995/082 PowerPC sysconfig parameters PSARC 1995/153 PPC installboot We need this materials as template for a set of ARC casess to specify support for a new architecture/hardware platform... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz@nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)