omvf firmware

omvf firmware

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 915 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?

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: omvf firmware

[ng0]

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   <efraim@flashner.co.il>   אפרים פלשנר
> 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

Re: omvf firmware

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]

On Thu, Mar 15, 2018 at 08:29:37PM +0000, ng0 wrote:
> 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?
> 

to quote Debian:
Open Virtual Machine Firmware is a build of EDK II for 64-bit x86 virtual
machines. It includes full support for UEFI, including Secure Boot, allowing
use of UEFI in place of a traditional BIOS in your VM.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]