In D26428#588166, @1983-01-06_gmx.net wrote:

I don't consider UEFI to be basic at all, both are completely different. If you would refer to it as firmware, I would agree, but not to UEFI as BIOS.

Thanks for committing this, @scottph! I've been busy with a new job so haven't had time to work on FreeBSD recently.

@scottph has indicated he no longer has the time/interest in working on this, so I'll take over and work to get it committed.

In D24066#534662, @grehan wrote:

Is this with PcdPciDisableBusEnumeration = TRUE in UEFI ?

In D19976#515732, @mat wrote:

Has this been committed yet?

@scottph Are you still interested in working on this?

In D24066#533961, @scottph wrote:

Works great here.

• Change comments to C style.

@rgrimes Could you approve the latest patch, or provide comments on what should be changed please?

Upload the full patch.

• Change overflow error to a warning and truncate type 17 memory size.

In D24107#532656, @grehan wrote:

There is no need to error out on overflow here. The type17 isn't used by most o/s's for determining how much memory is available: there is e820, the EFI memory map, etc etc. Perhaps print an error in bhyve, buit there doesn't seem any point in erroring out.

• Rework type17 generation and error out on overflow.

• Revert bumping the SMBIOS version.

• Fixes based on review feedback.

In D24107#532393, @jhb wrote:

That is what the 0x7fff value is for when using extended btw, is to report the max possible size for legacy systems. I agree that we should use the non-extended size when it fits.

In D24107#532401, @rgrimes wrote:

In D24107#532391, @jhb wrote:

Rebecca is it ok with you if I go create a review to do the bcdrev fix?

In D24107#530787, @rgrimes wrote:

This calculation seems odd, I see later it is overwritten for large memory, cant we just continue to use extended all the time and leave this set at 0x7fff? Never mind, spec says not. Ok how about doing:

In D24107#530018, @grehan wrote:

You might want to see what happens with > 64GB (or maybe 128GB, can't recall the value). At some point additional tables are required for Windows.

In D24107#530018, @grehan wrote:

Remove unrelated changes.

In D23662#519935, @theraven wrote:

This looks fine, but please submit it as a GitHub PR so that it goes through CI (I can't imagine it failing).

Remove the print statement in the default handler.

In D23662#519454, @emaste wrote:

change should also go here: https://github.com/davidchisnall/dtc

Committed in https://svnweb.freebsd.org/ports?view=revision&revision=525460 .

@araujo Could you approve my latest changes please? I ran poudriere and put the successful results at:

In D23476#516471, @araujo wrote:

OK, as soon as the poudriere get the results, share it here.

In D23476#516466, @araujo wrote:

Did you test it using poudriere?

In D23476#516323, @mat wrote:

Fine by me.

Simplify change to just the PYTHON_CMD fix.

In D23486#516054, @araujo wrote:

How are you testing these changes that you didn't catch this problem before?

And I know there are several problems with the Makefile, which I've learned through my updates to the uefi-edk2-bhyve port. But I'd like to get this fix committed and then, once the changes to uefi-edk2-bhyve are committed I'll fix the issues with this port based on what I've learned.

Unfortunately this has broken the port for anyone without python 2.7 installed. Could somebody approve me to commit this fix please?
@araujo @mat ?

Thanks for the feedback, and sorry about all the mistakes!

• Fix some more issues from the review feedback.

• MAKE_ARGS should be earlier in the Makefile

• Fix variables ordering

@mat I've updated the Makefile to be similar to sysutils/uefi-edk2-qemu - which involved removing BASH_CMD (replacing it with just 'bash'), removing USE_GCC and some other changes. I'd appreciate feedback about whether these changes are better or worse!

• Move DEBUG_VARS, DEBUG_VARS_OFF and HTTP_BOOT_VARS to before OPTIONS

• Remove sysutils/uefi-edk2-bhyve-devel from sysutils/Makefile

• Update port Makefile to be similar in style to uefi-edk2-qemu

In D23466#515069, @araujo wrote:

If you will remove the port, why botter to update it and trigger hooks around to rebuild the package?

Focus here, if your intention is to remove the package: https://reviews.freebsd.org/D23476

• Update MOVED to show that uefi-edk2-bhyve-devel is now uefi-edk2-bhyve

Could a ports committer commit this for me, please?

Remove PORTREVISION.

Revert unrelated change to sysutils/uefi-edk2-bhyve port

Fixed in r356740 (https://svnweb.freebsd.org/base?view=revision&revision=356740).

In D22979#507973, @ryan_freqlabs.com wrote:

Thank you! :)

In D22979#504080, @ryan_freqlabs.com wrote:

@bcran Thanks! Would you mind committing this for me? I don't have the bit.