From: kingman@austin.ibm.com (John Kingman) Subject: Item #332: OFWG Minutes 03/06/96 (second day) Date: Thu, 4 Apr 1996 17:59:14 -0600 (CST) P1275 Open Firmware Working Group Proposal -- Proposal #332 Ver Title: Minutes of Open Firmware Subcommittee meeting 3/6/96. Author: John A. Kingman Date: April 4, 1996 Ed/Tech: Editorial Synopsis: Minutes for 3/6/96 meeting held at Apple-Cupertino. Proposal: Hello, Here are the minutes for the second day of the 1275 OFWG meetings held at Apple-Cupertino on 3/6/96. Attendees: Mitch Bradley FirmWorks/President 415-961-1302 wmb@firmworks.com Chairman Open Firmware Working Group John Kingman IBM Risc System/6000 512-838-1546 kingman@austin.ibm.com Secretary Open Firmware Working Group Chris M Bellman Adaptec, Inc. 408-945-8600 cbellman@corp.adpatec.com Ron Hochsprung Apple/Sys. Arch. 408-974-2661 ron@apple.com Tuyen Tran BusLogic 408-492-9090 Satoru Mamiya FirePower Systems 415-462-3009 mamiya@Firepower.com Bob Coffin IBM 512-838-8240 coffin@vnet.ibm.com John Dickol IBM 512-838-6005 dickol@vnet.ibm.com John Hall Sun Microsystems 415-786-6927 John.Hall@eng.sun.com Matt Hill Sun Microsystems 415-786-5321 Matt.Hill@eng.sun.com - Review Agenda Proposed agenda was reviewed and approved unanimously. - Review Minutes (#325) - Add Bob Coffin to attendee's list - Approved unanimously, with amendment 7-0-0 - Open AI Review: 1 Ron H. to create proposal on recognizing Forth and FCode image formats. Status: Done (#322). 2 Parallel Port Read Method. (Mike S) Status: clarify to say 1284 standard mode 7 Ron H. to prepare proposal for Code Page selection. Status: No progress - Agenda: 1) Review Recommended Practices a) Generic Names - new proposal #324 - p8 l50 add "representing the subsystem vendor and device ids, if present, otherwise" at "representing" Make updates and create new version. (AI #1) b) Forth source and FCode image support - new proposal #322 - discussion clarifying definition of line end and a change to p3 l22 change "is then assumed to" to "must" Make updates and create v1.1 (AI #2) 2) Review PowerPC Processor Binding Revision 1.9 DRAFT - p7, l50: translation is not disabled. Change defintion to what Section 4.2.1 says (consistent). Strike words "with translation disabled". - p11, l22-23: Add wording: The Client also has to guarantee that other processors do not generate translation exception interrupts for the duration of the call. {Editor's discretion for wording} - p11, l45-46: Change wording: Hence this binding defines 'callback' services that the cliet provides for use by OF. - p14, l43: "cpu-state" - This is not 'static', or does it indicate the state at which OF was when it was started. Propose delete property because information is available elsewhere. Discuss in CHRP meeting. Move to be stricken from document; proposal from Mitch Bradley. Voted to remove: 8-0-0. - p17, change "device-type" to "device_type"; do a global check and fix all. - Proposal #312 -- Refers to material which was removed from the PPC processor binding, to be put in the platform bindings. Mitch Bradley: moved to freeze PReP, add to CHRP only For PReP; voted to reject 8-0-0. RESOLUTION: Freeze PReP for additional requirements. Tie PReP binding to PPC binding 1.8; voted to accept 8-0-0. Add to CHRP binding. - Proposal #313 -- rejected 8-0-0. PowerPC Architecture will clarify that only 3 pages will be reserved for implementation specific area. Clarification to PPC binding: p10, l20; Add following 'used for interrupt vectors': 'and implementation specific areas'. - Proposal #317 -- Proposed changes: p10, l3: DISCUSSION: real-mode: True False virt-base: don't care meaningful(-1 or explicit) real-base: meaningful dc(-1 or explicit) Is this independent of virt-base? Replace entire paragraph: "If the client program has specific requirements for physical memory or address space usage, it may establish requirements for OF's physical and/or virtual address space usage by means of its program header. When OF loads the client program, it inspects the program header, and if its current usage of physical memory or virtual address space conflicts with that specified in the program header, OF shall set the real-base, real-size, virt-base, and virt-size to the configuration variables as specified in the header and restart itself. real-base, virt-base, real-size and virt-size may be specified as -1, in which case the firmware is permitted to choose appropriate values for the variables specified as -1." p10, l7: Replace paragraph beginning at l7; "If the values of the real-size and/or virt-size config vars do not provide sufficient memory and/or virtual address space for the firmware's own use, then the firmware shall not attempt to load a client program and the condition should be reported to the user. The possibility of not being able to comply with limitiations on firmware's size should be tested as the firmware is coming up in order to handle the possibility that a user established an unworkable limitation on the size." Add second sentence of proposal. p11, l24-27: Client programs are not required to assume responsibility for physical memory management. Put at beginning of paragraph. State in both pos and neg context. p18: split Table 1 into sections: real-mode and virt-mode; change "preserved by client interface" to "client interface shall preserve"; add definition for preserved - same value when returing; indicate that the msr, segment registers & sprg registers shall not be modified by the client interface in virtual mode; indicate that the msr, segment registers & sprg registers shall be preserved by the client interface in real mode; remove '%' signs in this section. p19, Table 2: Change "Others" to "Other user mode registers". p19, l8-15: replace the 3rd and 4th sentences with the definition of load-base. Add the proposed sentence to the end of the paragraph. p20, l43; call BM; consistent with each other is OK. p22, l30; Segment Register's sentence, don't add. p22, l52-54: Move lines to behind 12. Move to make changes as amended above with p20 l43 clarifed tomorrow and update binding to Revision 1.10 DRAFT. Passed unanimously (6-0-0) (AI #3) clarifications for p20: at Ln 40: After the first sentence add: "The I cache shall be consistent with the D cache for all memory areas occupied by the client program." after Ln 43: Add: "All processors in a SMP system shall have the same consistent view of all memory areas (for data references). No more than one processor shall have a modified copy of the same data area in its cache when the client program is called. Note: If firmware makes cachable M=0 data references from different processors on a SMP system, it may have to perform additional cache management to meet this requirement." 3) Device Support Extensions - p.11, l.44, Clarify that size shouldn't include any area of NVRAM that is not available. Size should not include any areas set aside for manufacturer specific purposes other than those areas whose format is defined by the platform architecture specifcations. - p.12, l.44-49 ("differential") Is 'shall' necessary? If present, the node does it, if not, you don't know. multi-path issue: make a script for multiple hosts, multi-headed case make one controller "it" and point the other(s) at it via phandle ... presence of this property ... e.g. several might be connected to the same scsi ... "shared-bus-master": value is phandle (encode-int) of the package that is the canonical master of the shared bus. "For a given bus type there is an algorithm for determining which device among a set of devices sharing control of that bus is the 'distinguished' one. This distinguished device is known as the 'canonical master'. What's special for the distinguished master is we want to initiate an ID at the right numerical boundary." A proposal is to be submitted. (AI #4) - What "chording" is to be supported? A proposal is to be submitted. (AI #5) - "sound" vs "audio" - change Generic Names to "sound" based on the fact that DSE uses sound. - "SICSI" should be "SCSI" New DSE draft to be produced with these amendments. (AI #6) 4) ISA Binding - p8, l30 "physical" - p8, l10 "since" - p10, l33, change "adaptor" to "adapter" - p11, l39, change "id" to "ID" - p11, l49-50, fix child = ISA bridge, parent = PCI Bus - p12, l18, delete "24-bit address" and add "Since ISA devices are restricted to 24-bit addressing, the memory must be within an area which can be reached by a 24-bit address on the ISA Bus. - p13, l18-23, delete serial and move it to unit address of reg property. Make the name generic, if it is appropriate. "isa" should be in plain font. More detail on aaa,bbb (encoded as whatever) aaa = upper case ascii characters (as decoded from compressed ascii, etc.) trailing blanks eliminated. bbb = lower case ascii hex, leading zeros eliminated . - p13, l25-37, 2 cases. Text repr: "pnp,aaa,bbbb,ssss..." - p13, l38+ (interrupts) indicate that "type" is the type being used . use "shall" . fix "one liner" . array = an arbitrary number of irq, type pairs - p14, l7-15 (compatible) start with pnpvvv,dddd (no serial no) followed by logical device id, followed by any number of compatible ids. - p14, l45-52 (connectors) change to slot-names - p14, l53 delete interrupt-choices - p15, l18 delete dma-choices Moved to produce 0.2 Draft with these amendments. 6-0-0 (AI #7) New Action Items 1 - Update Generic Names Recommended Practice (Bob Coffin) 2 - Update and create v1.1 Forth and FCode Recommended Practice (Ron Hochsprung) 3 - Produce PPC Processor v1.10 draft (John Kingman) 4 - Make "shared-bus-master" proposal (Bob Coffin) 5 - Make "chording" proposal (Ron Hochsprung) 6 - Produce new Device Support Extensions draft (Bob Coffin) 7 - Produce 0.2 Draft of ISA binding (Bob Coffin) 8 - Propose that debug facilities not be supported in real-mode. (Mitch Bradley) [ P1275 Item #332 -- Received: Thu Apr 4 15:57:59 PST 1996 ]