From owner-freebsd-current@freebsd.org Wed Jun 17 20:11:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4C29D33411F for ; Wed, 17 Jun 2020 20:11:50 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49nGS46b2Nz4QtH for ; Wed, 17 Jun 2020 20:11:48 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 05HKBSYZ087133; Wed, 17 Jun 2020 13:11:28 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05HKBS4q087132; Wed, 17 Jun 2020 13:11:28 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006172011.05HKBS4q087132@gndrsh.dnsmgr.net> Subject: Re: CTF: UEFI HTTP boot support In-Reply-To: <890A1C97-31A1-46F9-BE9B-340F6039DD45@bsdio.com> To: Rebecca Cran Date: Wed, 17 Jun 2020 13:11:28 -0700 (PDT) CC: Warner Losh , "Rodney W. Grimes" , Miguel C , FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49nGS46b2Nz4QtH X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd-rwg@gndrsh.dnsmgr.net has no SPF policy when checking 69.59.192.140) smtp.mailfrom=freebsd-rwg@gndrsh.dnsmgr.net X-Spamd-Result: default: False [1.44 / 15.00]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.26)[0.265]; NEURAL_HAM_LONG(-0.02)[-0.020]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.29)[0.294]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_CC(0.00)[bsdimp.com,gndrsh.dnsmgr.net,gmail.com,freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Wed, 17 Jun 2020 20:11:50 -0000 > > > On Jun 17, 2020, at 12:12 PM, Warner Losh wrote: > > > > I missed the start of this thread, so maybe I'm missing a key detail. However, I thought UEFI didn't have a RAM-disk, per se, but that we could load memory areas and pass that into the kernel using freebsd-only methods. But UEFI is a bit weird, so maybe it will generate a virtual cdrom... > > See https://uefi.org/sites/default/files/resources/FINAL%20Pres4%20UEFI%20HTTP%20Boot.pdf > > ? RAM Disk Standard > > ? UEFI 2.5 defined RAM Disk device path nodes > - Standard access to a RAM Disk in UEFI > - Supports Virtual Disk and Virtual CD (ISO image) in persistent or > volatile memory? Does freeBSD have any way to access these "Virtual Disk" or Virtual CD images once we leave the world of the loader? I believe we do not, as these are BIOS/UEFI devices that require calls into the UEFI code, which, IIRC is gone once we exit the loader and start the kernel proper, or shortly there after. As far as I know these devices well not be found by the FreeBSD cam layer ATA or AHCI drivers as they do not present an actual PCI device to find. > Rebecca Cran -- Rod Grimes rgrimes@freebsd.org