From owner-freebsd-current@freebsd.org Thu Sep 21 03:51:32 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEF09E100AE for ; Thu, 21 Sep 2017 03:51:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9D36067151 for ; Thu, 21 Sep 2017 03:51:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9C48FE100AD; Thu, 21 Sep 2017 03:51:32 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B993E100AC for ; Thu, 21 Sep 2017 03:51:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from bat.yew.relay.mailchannels.net (bat.yew.relay.mailchannels.net [23.83.220.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B5D46714C for ; Thu, 21 Sep 2017 03:51:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C279612A612 for ; Thu, 21 Sep 2017 03:35:21 +0000 (UTC) Received: from outbound1a.eu.mailhop.org (unknown [100.96.147.57]) (Authenticated sender: duocircle) by relay.mailchannels.net (Postfix) with ESMTPA id 2051F12A622 for ; Thu, 21 Sep 2017 03:35:20 +0000 (UTC) X-Sender-Id: _forwarded-from|73.78.92.27 Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [172.20.107.195]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Thu, 21 Sep 2017 03:35:21 +0000 X-MC-Relay: Junk X-MailChannels-SenderId: _forwarded-from|73.78.92.27 X-MailChannels-Auth-Id: duocircle X-Absorbed-Obese: 4193011f75005457_1505964921590_325726657 X-MC-Loop-Signature: 1505964921590:80548277 X-MC-Ingress-Time: 1505964921589 X-MHO-User: e13cd544-9e7d-11e7-a893-25625093991c X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e13cd544-9e7d-11e7-a893-25625093991c; Thu, 21 Sep 2017 03:35:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v8L3ZDX5014106; Wed, 20 Sep 2017 21:35:13 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1505964913.73082.65.camel@freebsd.org> Subject: Re: Pre-filled RAM disk. From: Ian Lepore To: Jon Brawn Cc: FreeBSD Current , Warner Losh Date: Wed, 20 Sep 2017 21:35:13 -0600 In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 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: Thu, 21 Sep 2017 03:51:32 -0000 On Wed, 2017-09-20 at 21:23 -0600, Warner Losh wrote: > On Wed, Sep 20, 2017 at 9:16 PM, Warner Losh wrote: >=20 > >=20 > >=20 > >=20 > > On Wed, Sep 20, 2017 at 8:50 PM, Jon Brawn wrote: > >=20 > > >=20 > > > Wotcha! > > >=20 > > > I work for Arm for my sins, and in my spare time I=A2ve been > > > playing with > > > FreeBSD. In my day job I work with the CPU core validation team, > > > and one of > > > the things we do is take the hardware design of a new core and > > > run it on a > > > machine called an emulator. This emulator isn=A2t the same thing as > > > QEMU, nor > > > is it just an FPGA, it=A2s something in the middle - you compile > > > the hardware > > > design and download it to the emulator, and it can then run > > > programs on > > > your design at about 1MHz. Which is lovely. Our main bread and > > > butter is to > > > take such a design and get it to boot Arm Linux, a very cut down > > > version, > > > and then run some tests hosted in the Linux environment. These > > > tests would > > > typically thrash the snot out of some particular aspect of the > > > architecture, such as memory sharing amongst multiple processor > > > cores. Now, > > > we would like to use other operating systems that behave > > > differently to > > > Linux, there are some obvious candidates that I=A2m not going to > > > talk about > > > for legal reasons, but one that was suggested was using FreeBSD > > > under > > > emulation. > > >=20 > > > So, what is needed is someway of telling the operating system > > > that it is > > > going to use a ram disk for its root filesystem, and that the ram > > > disk is > > > going to be at a fixed physical address in the memory map. That > > > way we can > > > pre-load root from a file in the emulation environment. In the > > > Linux > > > environment we would package the kernel, it=A2s DRB and the root > > > filesystem > > > memory image inside a light-weight bootloader wrapper, load that > > > at the > > > right offset into the emulator=A2s memory map, and twang the > > > virtual reset > > > line of the emulated processor. There=A2s some magic jiggery pokery > > > to get > > > console output from what the OS thinks is an AMBA UART, but > > > that=A2s about > > > size of it. > > >=20 > > > So, what does FreeBSD have to offer in the way of ramdisk > > > functionality? > > >=20 > > Yes. > >=20 > > See MD_ROOT and friends. > >=20 > The MFS_IMAGE kernel option has replaced this. >=20 > Warner And the documentation (such as it is) for MFS_IMAGE is in the md(4) manpage. =A0In a nutshell, it's a mechanism that lets you compile an existing filesystem image directly into the kernel and it is mounted as a memory filesystem at boot time. =A0Hopefully being contained within the kernel will make the problem of loading it at a fixed physical address go away for you. -- Ian