From mboxrd@z Thu Jan 1 00:00:00 1970 From: ng0 Subject: Re: omvf firmware Date: Thu, 15 Mar 2018 20:29:37 +0000 Message-ID: <20180315202937.dtnuqfkh6h34nzcy@abyayala> References: <20180315194815.GA1080@macbook41> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:42539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewZVF-0005Qv-LK for guix-devel@gnu.org; Thu, 15 Mar 2018 16:29:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewZVC-00039j-HD for guix-devel@gnu.org; Thu, 15 Mar 2018 16:29:33 -0400 Received: from aibo.runbox.com ([91.220.196.211]:38264) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ewZVC-00038k-8H for guix-devel@gnu.org; Thu, 15 Mar 2018 16:29:30 -0400 Content-Disposition: inline In-Reply-To: <20180315194815.GA1080@macbook41> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Efraim Flashner Cc: guix-devel@gnu.org Efraim Flashner transcribed 2.0K bytes: > I succesfully built ovmf firmware for aarch64 on my aarch64 board. > Currently it builds for x86_64 and i686 on %intel platforms only. I > think it's best to create a make-ovmf-firmware procedure to build the > firmware for x86_64/i686/aarch64/armhf, but there's not a clear > cross-grade path from our current x86_64 & i686 package to x86_64 or > i686. > > The two other options I've thought of are adding aarch64 and armhf > support to our current package, which would balloon the native-inputs > with cross compilers, or leave the current package and add 1 or 2 new > pacakges, but then I feel like that's almost back to my original intent > of creating a procedure and 4 packages. > > Suggestions? Comments? I don't know omvf. Does it involve kernel space modules? I've started experimenting with a path to a generalized kernel-module support (which needs the "source" we currently throw away of the kernel, etc). Or what this firmware like? > -- > Efraim Flashner אפרים פלשנר > GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 > Confidentiality cannot be guaranteed on emails sent or received unencrypted -- A88C8ADD129828D7EAC02E52E22F9BBFEE348588 https://n0.is