In D20765#449872, @greg_unrelenting.technology wrote:

I'm going through my list of reviews and noticed this one. Does it need more work, or can it be committed?

@yuripv Are you still planning to commit this?

I committed a temporary fix to increase the size to 100MB on x64 in r349471.

I just tried booting with this patch applied and with EDK2 firmware built from master yesterday, and I still don't see any output - both with devicetree and acpi.

• Only bump EFI_STAGING_SIZE for x64

• Added error handling around realloc.

• Fixed a couple more issues

• loader: add HTTP support using UEFI
• Updates per review feedback.

I realized one issue: we should perhaps add a configuration option such as LOADER_EFIHTTP_SUPPORT to let people disable this.

In D20562#447282, @emaste wrote:

In D20562#445261, @andrew wrote:

Is there a way to build the efi fs this without root? I build images in a Jenkins instance to test FreeBSD/arm64 on various simulators and would prefer to not need to give the Jenkins user sudo access.

Removed tmpl.xz files and updated ObsoleteFiles.inc and OptionalObsoleteFiles.inc

In D19869#432543, @mat wrote:

Approved with the changes requested.

Could you explain what problem this is solving, please? I don't think I've had a problem with loader.efi finding the FreeBSD installation to boot from.

• MAKE_ARGS should be =, not += .

• Remove duplicated and unneeded lines.

• Merge branch 'master' of https://github.com/freebsd/freebsd
• Fix UEFI image generation: make_esp_file needs a filename, not a directory.

Could people review this again for the changes I've made, please?

• Change the install-boot.sh option to -u to cause it to run efibootmgr etc.

In D19992#429688, @imp wrote:

It's a persistent communication mechanism that can be used to configure behavior in the boot loader that might otherwise be controlled via UEFI variables.

In D19992#429679, @imp wrote:

I've also started to create a 'fallback loader' path to try to hash out a good design. I'm thinking that a good design might be to have loader.efi read in \efi\freebsd\loader.env and parse it like the command line with foo=bar variables. This would let us say uefi_rootdev=HD(3,GPT,0f91d7c6-2de5-11e8-b5f1-3cfdfe9d5250,0x619430,0x600000) and have that become / for the new system. The only downside to this is that we have to encode the size and offset of the partition into the device path which doesn't play well with the auto resize code, though we could hack that to update this env :)

• Revert unrelated change

• Make changes learned from feedback on D19875 from @mat .

• Fix portlint errors

In D19869#428001, @manu wrote:

There is a lots of portlint error :
FATAL: Makefile: extra item "FLAVORS" placed in the MAINTAINER section.
FATAL: Makefile: extra item "x86_64_PKGNAMESUFFIX" placed in the MAINTAINER section.
FATAL: Makefile: extra item "i386_PKGNAMESUFFIX" placed in the MAINTAINER section.
WARN: Makefile: COMMENT is set externally to this port's Makefile, but this port is not configured as a slave port.
FATAL: Makefile: extra item "MAINTAINER" placed in the LICENSE section.
FATAL: Makefile: extra item "COMMENT" placed in the LICENSE section.
WARN: Makefile: "LICENSE" has to appear earlier.
WARN: Makefile: "ONLY_FOR_ARCHS" has to appear earlier.
WARN: Makefile: "BUILD_DEPENDS" has to appear earlier.
WARN: Makefile: "USES" has to appear earlier.
5 fatal errors and 5 warnings found.

• Add support for building i386 as a FLAVOR
• Install files to share/uefi-edk2-qemu instead of uefi-firmware

In D19869#427632, @bcran wrote:

In D19869#426787, @jhb wrote:

In this case though it isn't the host arch (ARCH) but a target architecture for the binary blob. That does seem like something flavors would handle, but slave ports also work. I thought part of the point of flavors was to make it easier to not have slave ports by encapsulating all the slave ports in a single port.

From what I can see, FLAVORS would work great for the two architectures OVMF runs on, X64 and IA32, but it doesn't work in the situation that someone wants to run X64 OVMF on qemu on their physical ARM64 machine. For that I think I need to figure out the set of cross-tools (aarch64 -> x64) that are needed and add them to the main Makefile.
I've made some progress on that: a BaseTools fix is now upstream (on master), and next will probably be creating a gcc-x64 port to cross-compile OvmfPkg.

In D19869#426787, @jhb wrote:

In this case though it isn't the host arch (ARCH) but a target architecture for the binary blob. That does seem like something flavors would handle, but slave ports also work. I thought part of the point of flavors was to make it easier to not have slave ports by encapsulating all the slave ports in a single port.

• Add port to sysutils Makefile and split PLIST_FILES over two lines.

In D19869#426769, @manu wrote:

As for the installed file I don't know which is better between :
${LOCALBASE}/share/uefi-firmware-${ARCH} and ${LOCALBASE}/share/uefi-firmware/<filename>-${ARCH}
But uefi-firmware seems vague no ? maybe ${LOCALBASE}/share/uefi-edk2-qemu/ ?