@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.
Apr 21 2020
Apr 8 2020
Apr 6 2020
Apr 5 2020
@scottph Are you still interested in working on this?
Mar 31 2020
Mar 30 2020
- Change comments to C style.
@rgrimes Could you approve the latest patch, or provide comments on what should be changed please?
Mar 29 2020
Upload the full patch.
Mar 28 2020
- Change overflow error to a warning and truncate type 17 memory size.
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.
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.
Mar 27 2020
Mar 26 2020
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:
Mar 20 2020
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.
Mar 18 2020
Remove unrelated changes.
Mar 17 2020
Feb 20 2020
Feb 15 2020
This looks fine, but please submit it as a GitHub PR so that it goes through CI (I can't imagine it failing).
Feb 13 2020
Remove the print statement in the default handler.
Feb 8 2020
Feb 7 2020
Feb 6 2020
@araujo Could you approve my latest changes please? I ran poudriere and put the successful results at:
Feb 5 2020
Simplify change to just the PYTHON_CMD fix.
How are you testing these changes that you didn't catch this problem before?
Feb 4 2020
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.
Thanks for the feedback, and sorry about all the mistakes!
- Fix some more issues from the review feedback.
Feb 3 2020
- 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
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?
Feb 2 2020
Revert unrelated change to sysutils/uefi-edk2-bhyve port
Jan 17 2020
Jan 15 2020
Fixed in r356740 (https://svnweb.freebsd.org/base?view=revision&revision=356740).
Jan 14 2020
In D22979#507973, @ryan_freqlabs.com wrote:
Thank you! :)
Jan 6 2020
In D22979#504080, @ryan_freqlabs.com wrote:
@bcran Thanks! Would you mind committing this for me? I don't have the bit.