From sac-owner Wed Sep 6 14:32:11 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k86LWBEO014527 for ; Wed, 6 Sep 2006 14:32:11 -0700 (PDT) Received: (from noaccess@localhost) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) id k86LWBn04127 for one-pager-not-2b-used-directly; Wed, 6 Sep 2006 14:32:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k86LW9w04102; Wed, 6 Sep 2006 14:32:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J5600K0NX5KCK00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Sep 2006 14:32:08 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J5600HRFX5IIZ50@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Sep 2006 14:32:06 -0700 (PDT) Received: from smack.eng.sun.com (smack.SFBay.Sun.COM [129.146.226.114]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k86LW5CP009285; Wed, 06 Sep 2006 14:32:05 -0700 (PDT) Received: from smack (localhost [127.0.0.1]) by smack.eng.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k86LW5gX770790; Wed, 06 Sep 2006 14:32:05 -0700 (PDT) Date: Wed, 06 Sep 2006 14:32:05 -0700 From: Jan Setje-Eilers Subject: [/]new-boot sparc To: one-pager@Sun.Com Cc: nb-sparc@Sun.Com Message-id: <200609062132.k86LW5gX770790@smack.eng.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 8239 Template Version: @(#)onepager.txt 1.29 04/11/15 SMI This information is Copyright 2006 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: new-boot sparc 1.2. Name of Document Author/Supplier: Jan Setje-Eilers 1.3. Date of This Document: 14 August 2006 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Diann.Olden@Sun.COM (acting Barry Cooks replacement) 1.4.4. The name of your business unit: Operating Platforms Group 1.5. Email Aliases: 1.5.1. Responsible Manager: Peter Luk 1.5.2. Responsible Engineer: Jan Setje-Eilers 1.5.3. Marketing Manager: Jeffrey McMeekin 1.5.4. Interest List: nb-sparc@sun.com 2. Project Summary 2.1. Project Description: The Solaris OS bootstrap process is redesigned for simplicity and flexibility. The immediate goals of this second phase are: Ramdisk miniroot support on the SPARC platform to enable ITU style platform support. Bring the architecture of SPARC boot more in line with post-new-boot x86, paving the way for zfs root on SPARC. 2.2. Risks and Assumptions: This offers a new mechanism for delivering software out sync with the existing (update) releases. While this is principally an advantage, it can also be abused. The assumption is that ITUs will be created from bits that have been integrated into the relevant -current and -patch gates. 3. Business Summary 3.1. Problem Area: A new platform can not be released until we can also supply an OS that supports it. At the moment that means getting mostly working p_mumble units, getting the software working, getting it into Solaris.current, letting it soak and then putting it into Solaris.latest_release.current_update and then waiting for that update to ship. This creates two problems: 1) The platform is ready to go, but the update won't ship. We either hold the platform (this is poor as we'd like to ship it and make money) or end up paying in form of extra "hardware releases". 2) The platform or platform software is not quite done when the update is scheduled to ship. In this case we either slip the update release, depriving other customers of its virtues, or we end up shipping a half baked update forcing the platform to slip the next update release. 3.2. Market/Requester: Niagara/Rock Software Engineering zfs root/boot 3.3. Business Justification: Having to align update releases, spin "just one more" update for a retired release in order to release a new platform is costing both OPG and SSG time, money and nerves. The ITU support portion of this project aims to get us out of this situation. 3.4. Competitive Analysis: In the Microsoft/x86 world ITU style platform support has been in use for over 10 years. 3.5. Opportunity Window/Exposure: ASAP. 3.6. How will you know when you are done?: SSG can install Solaris on their hardware by supplying Solaris drivers at install time without creating a new Solaris release. ZFS boot/root works and can be delivered on SPARC. 4. Technical Description: 4.1. Details: This is in fact identical to what was stated in the x86 new-boot 1-pager. We actually implemented what was stated and now intend to bring this architecture to SPARC: The new boot architecture is based on the Solaris WAN boot process. When a system powers on, the firmware loads the boot block, which pulls in a boot loader. The boot loader pulls in a rootfs archive and place it in a ramdisk. The bootloader then loads and executes a secondary loader, which assembles core kernel modules from the ramdisk and transfers the control to the Solaris kernel. The kernel probes I/O devices and mounts the root filesystem. This secondary is contained within the (dboot) merged unix/krtld object. The key design points of the new architectures are - Clean separation between the boot loader and OS kernel The bootloader becomes a replaceable component which can evolve independently of Solaris kernel. - Dissociation of boot loader from the root filesystem Boot loader does not need to understand the Solaris root file system. It allows any root file system to be the Solaris root without changing the boot code. - Unification of disk boot and network boot Booting from disk, LAN, and WAN will be identical from Solaris perspective. The kernel always initializes from in-memory text and data regardless of where they are loaded from. - Ease of install time updates When booting Solaris miniroot from an Install CD, the root device will be ramdisk (instead of the CD-ROM drive). The drive is then freed up for user to supply additional software. The major components of the project are listed below. The Boot Loader The boot loader is responsible for loading the Solaris rootfs archive from the media to memory. It must be able to talk to the device (disk meadia or network interface) where the archive resides. It does not need to probe out all devices, that's the responsibility of Solaris kernel. On sparc platforms, the OBP still functions as the bootloader. The dboot kernel. This is a merge of unix and the post new-boot krtld which can read the ramdisk directly. The Root Filesystem Archive For the Install CD or net install image, the rootfs archive will be a equivalent of the current miniroot, packaged as a ramdisk image. Once a system is installed, a custom rootfs archive will be created for the system and boot environment. The archive is a subset of files required for kernel startup, up to the point when root filesystem and root devices can be configured. The rootfs archive is placed on a device in a format which can be read by the boot loader. Both the boot device and boot filesystem can be different from the Solaris root device and file system. The ability to keep the rootfs archive compatible with respect to the system configuration will be key to the success of the new architecture. Install, upgrade, and jumpstart The Solaris install/upgrade code must be updated to lay down new boot code on disk. Some of the code changes may needed to be patched in older releases to support Live Upgrade. Furthermore, other Solaris deployment schemes, such as jumpstart and flash archives, need to be updated and verified under the new boot architecture. 4.2. Bug/RFE Number(s): TBD 4.3. In Scope: See above. 4.4. Out of Scope: An optional deliverable is to collapse wanboot and net(install)boot into a single architecture. While this is additional work, it would vastly reduce the current wanboot maintenance burden 4.5. Interfaces: TBD 4.6. Doc Impact: This project (unlike new-boot x86) aims to be mostly a non-user-visible change, so impact should be minimal. Man pages: boot(1M), bootadm(1M) 4.7. Admin/Config Impact: bootadm exposed on SPARC. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: TBD 4.11. Security Impact: None/TBD 4.12. Dependencies: TBD 5. Reference Documents: http://boot.eng 6. Resources and Schedule: 6.1. Projected Availability: TBD 6.2. Cost of Effort: TBD 6.3. Cost of Capital Resources: TBD 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: OsNet and Install 6.4.3. Type of CPT Review and Approval expected: Standard 6.4.4. Project Boundary Conditions: TBD 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: TBD 6.4.7. Target RTI Date/Release: Solaris 11 and Solaris 10 Update 6.4.8. Target Code Design Review Date: TBD 6.4.9. Update approval addition: TBD 6.5. ARC review type: Standard 7. Prototype Availability: 7.1. Prototype Availability: Q4CY06 7.2. Prototype Cost: 6 staff months