From owner-freebsd-current@freebsd.org Mon Sep 17 18:17:38 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B7F310A3758 for ; Mon, 17 Sep 2018 18:17:38 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03FF385E8F for ; Mon, 17 Sep 2018 18:17:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id p129-v6so12202445ite.3 for ; Mon, 17 Sep 2018 11:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=F6qEWEwg5E5Eq7VqQwyW2Rwh40kr+oNNb0iAedBRXcg=; b=KTLrcnjedoioyb13JfAyRmx4a4jO5LwKKcRsqmLxmNGQe+F9Bngay7yibQiFcx2GeO 5vONUIKQRYWlNX/+SyMa7OdDHKJQf2agXf8yspZzuhA0ycg5e5ACdXJ9H8qNwmbZsMmV 2f7W6/GKFXKp7reEOuxC3YUjT8CZkku+0RMugfYyM20FUwlzSDXd00vdWGV1UshP2KES 97LFkEPk8pqVILlmOCY0HSq4bPkCUifRjBhnWRVSm336qOTYI7/jEbYizar/RiNNVfmH I738xf2XogOj+MAQ1r1kofHjqu23REvdwIV2hSusTenn2y909w3MckGYLldyslBwVieN cFAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F6qEWEwg5E5Eq7VqQwyW2Rwh40kr+oNNb0iAedBRXcg=; b=cGoC6u86c0nQ9wsRSjwSPqmaXs7By6SSCe3z1BqF0+URQHWeGJzUSpUc5zY7iJM5kI hr2JEqSe/F7xjwGYSuH6rWK9zJJ2V70XnSIolrqQpT6bCZtbtNIAj3sVlHY4n92YPXMo iFpQYSOLzO4dFbpESXyVO/JBBV/9Xhn0qx1pAJQeZ/dZaER+OWtVBKzEmI0pzJCmIaaL hMkNPmubH5psb1m3HhnYWK3R9I2sLPaws5CJFY5BEvWwL1sYg+KNN2FsxgYjlYj8Laxh vzlXaU0JhuGpa+A7gUhVPGeeOAws3SybH59aV5W4lqoDOKAITcqSbI6gQxh45YWvknTP j4Aw== X-Gm-Message-State: APzg51Asp04CfLFgkluYMUtR38dQUmARsw1dBVa6MZNnThD2k9ZOO/hu 8I4U1FppsAVt7XYI8bHjYVy1tUZwRy5aZ/RuoVGYHObs X-Google-Smtp-Source: ANB0VdbkFYX/pjdKvY3t3HpoIvjnLMIP8/9Q+J3pZbUx/qYVK08QbetzmetucZN2fbWAo/BPBCaJXBFrLFhilVbU2n8= X-Received: by 2002:a24:9197:: with SMTP id i145-v6mr12816836ite.39.1537208257142; Mon, 17 Sep 2018 11:17:37 -0700 (PDT) MIME-Version: 1.0 References: <1dbeee10-857e-7fb2-dac2-1047353739ba@bluestop.org> <3ce6e6cb-a608-2969-09d4-201df07df586@bluestop.org> In-Reply-To: <3ce6e6cb-a608-2969-09d4-201df07df586@bluestop.org> From: Warner Losh Date: Mon, 17 Sep 2018 12:17:25 -0600 Message-ID: Subject: Re: FreeBSD EFI projects To: rebecca@bluestop.org Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.27 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2018 18:17:38 -0000 On Sun, Sep 16, 2018 at 11:29 PM Rebecca Cran wrote: > On 9/16/18 9:32 PM, Warner Losh wrote: > > > > > What did you have in mind working on? I have a few things that are in > > various stages of completeness around this issue that I've not had > > time to polish off for the tree. Some I'd like to, but some may > > benefit from a fresh perspective. Also, there's a fair number of > > hidden bugs in the stuff committed around finding the whole path > > sometimes and the like. > > > One thing I've started working on is switching the ESP to use FAT32 > everywhere except the ISO images (due to the limitation in the El Torito > format not supporting sufficiently large regions). The specifications > from EFI 1.10 onward have been clear that only FAT32 is supported for > the ESP (but that FAT12 and FAT16 must be supported for removable > devices), and I've read that some systems do enforce that. Unfortunately > that does mean the ESP must be a minimum of 33MB, but I think it's > worthwhile for increased compatibility. > I think this is a good change. We've seen issues with the tiny systems and FAT12 format, so we've switched to FAT16. But even with that, we're seeing some issues, so using FAT32 is great. > Related to that, I've also been working on removing the FAT filesystem > templates that are currently checked into svn, instead generating them > during the release stage. > I'd like to simply remove them entirely. They serve no useful purpose if we have an installer / script that can newfs + copy files. they were originally done so that we didn't have to change geom too much and could just DD something to a partition, which matched well the GPT boot code case. I've had some interest on #bsdmips about booting a 64-bit FreeBSD on old > Apple systems that use 32-bit EFI: it sounds like it should be possible, > and is something I'd like to try and get working. > That should be possible, but there's a number of issue dealing with the 32-bit EFI not having a direct map that we can use to generate the mapping tables we need for the loader early in our boot. It's why we can't call the EFI runtime on armv7, for example. > I'd also really like to help move the changes to mount an existing ESP > during installation instead of clobbering it towards being committed, if > possible. > Another very worthwhile project. > Another thing I'd like to work on is trying to catch corner cases like > in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210244 where > calling GetMemoryMap causes the memory map to become fragmented. I'd > also like to try and improve diagnostics, for example at the moment if > the system doesn't have enough memory to run the loader it silently > exits instead of displaying an error message. > That would be awesome. When things work today, they work. When they don't, it an be quite opaque to figure out, absent help from kib :). > And I would also be interested in taking a look at any projects you've > not completed yet, to see if I can help in any way. > Items on my list are: (1) Retiring boot1.efi entirely before 13.0. It was originally designed to be a small, never changing blob we'd toss into an ESP and have all the smarts in loader.efi. However, to support GELI encryption, ZFS, and other things, it's had to grow an increasingly frustrating amount of functionality. Better to just use loader.efi. This does, however, require that we solve the problem of updating loader.efi on installworld / freebsd-update times, even on systems with non-standard setups. Moving to a 'standard' setup for EFI would be a good first step, as well as having a script to do this both for when the ESP is mounted in a non-standard place, as well as for when it's not mounted. (2) Create a /dev/efi/boot for the drive/partition that we booted off of. This will allow us to have a standard fstab which is more resilient to oddities. NanoBSD could use this for it's ping-pong setup. I have some very basic code here, but it's more the stubs to add this to geom, and not so much on finding this information. Might be nice to also have a /dev/efi/esp to identify the ESP we booted off of as well to cope with systems that may have multiple potential ESP locations (at work we have this sort of setup for redundancy). (3) Add network interfaces to things that we know how to generate EFI DEVICE PATH entries for. I have some preliminary code that tries to match up the ifnet entries with a MAC DEVICE_PATH that I'd hoped to use to add netbooting support to efibootmgr. (4) Final integration of efibootmgr into the installer so we can generally install things robustly. Sadly, this has issues with some BIOSes not honoring BootOrder. I have no code, but have been working with nathanw@ on this. (5) For those systems that do honor BootOrder, having nextboot implemented using EFI variables would be sweet. I have vague ideas on this only. Warner