On 5/3/21 5:14 AM, Christian Stærk wrote:
>
> It occurred to me that I could try using ahci-hd instead of
> virtio-blk, so I am trying that now to see if it makes a difference.
You might also want to try nvme, since it's higher performance than ahci-hd.
--
=254257
That is a bug!
Yes, it is. Sorry, I'll commit the fix later today.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
&qu
the uefi-edk2-bhyve directory - then, run
'script bhyve_build_log.txt make' to log all the output to the file
'bhyve_build_log.txt'?
And then upload the contents somewhere, for example https://pastebin.com/ .
--
Rebecca Cran
_
On 2/23/21 7:49 AM, The Doctor wrote:
On Mon, Feb 22, 2021 at 11:30:24PM -0700, Rebecca Cran wrote:
Do you have anything in /etc/make.conf that could be affecting the build?
DEFAULT_VERSIONS+=linux=c7_64
DEFAULT_VERSIONS+=ruby=2.7
DEFAULT_VERSIONS+=python=3.8
DEFAULT_VERSIONS+=pytho3=3.8
On 2/22/2021 9:21 PM, Rebecca Cran wrote:
On 2/22/2021 8:43 AM, The Doctor wrote:
Same result and now looking to reinstall gcc48
in the csm version!
I just installed a fresh copy of FreeBSD 12.2 and ran 'make' in
/usr/ports/sysutils/uefi-edk2-bhyve and it completed without any err
On 2/22/2021 8:43 AM, The Doctor wrote:
Same result and now looking to reinstall gcc48
in the csm version!
I just installed a fresh copy of FreeBSD 12.2 and ran 'make' in
/usr/ports/sysutils/uefi-edk2-bhyve and it completed without any errors.
I'm trying using synth next.
that somehow resolved it for me.
>
> -Dustin
>
>> On Mon, Feb 22, 2021 at 12:08 AM The Doctor via freebsd-virtualization
>> wrote:
>>
>>> On Sun, Feb 21, 2021 at 09:38:29PM -0700, Rebecca Cran wrote:
>>> On 2/18/2021 6:22 PM, The Doctor via freebsd-por
t version of GCC?
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
On 2/15/21 8:17 AM, The Doctor wrote:
Would this work with Python3 and gcc9+ ?
Yes, it should work with python 3.x and all modern gcc versions.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman
Both testing of the BhyveX64 firmware and review feedback on the port
changes would be welcome. There's an upstream [edited: edk2-stable202102
tag coming up soon, and I'd like to fix any issues in time for that.
--
Rebecca Cran
___
freebsd
On 2/14/21 10:09 PM, Peter Grehan wrote:
You likely need a '-w' option to ignore unimplemented MSRs.
Thanks, that seems to have fixed it - I can't believe it was that simple!
--
Rebecca Cran
___
freebsd-virtualization@freebsd.o
tbridge -s 31:0,lpc -c 1 -m 8G -l
bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd -l com1,stdio -s
3:0,ahci-hd,bhyve-windows-10-20h2.img -s
29,fbuf,tcp=0.0.0.0:5900,w=1024,h=768,wait -s
7,ahci-cd,en_windows_10_business_editions_version_20h2_updated_jan_2021_x64_dvd_533a330d.iso
guest
On 12/28/20 7:21 PM, Jason Tubnor wrote:
On Sun, 27 Dec 2020 at 04:14, MR <mailto:m...@freebsd.org>> wrote:
Zitat von Rebecca Cran mailto:rebe...@bsdio.com>>:
> On 12/6/20 4:45 PM, Michael wrote:
BTW:
I just saw a new image:
https://people.freebs
On 12/6/20 4:45 PM, Michael wrote:
Hi
Am 7. Dezember 2020 00:00:31 MEZ schrieb Rebecca Cran :
Oh, I seem to recall a problem around that flash detection code in the
past. Which version of FreeBSD are you running?
12 Stable
Thanks. Does the problem still happen if you use BHYVE_CODE.fd
Oh, I seem to recall a problem around that flash detection code in the
past. Which version of FreeBSD are you running?
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd
in FreeBSD Ports - comms/tio)
you can connect to the device before it's active.
If you don't see any output and you're using the RELEASE firmware I
provided, could you try again with the DEBUG version?
--
Rebecca Cran
___
freebsd-v
Sorry for confusing things. BHYVE_CODE.fd is for when support for
BHYVE_VARS.fd is added. For now, there's no support for that so you can
just use BHYVE.fd which is the combined file.
--
Rebecca Cran
On 11/25/20 4:21 AM, MR wrote:
Hi Rebecca,
thanks for providing the binaries!
I&
On 11/22/20 8:14 PM, Rebecca Cran wrote:
I'd like to get some more testing of the new UEFI EDK2 port before I
hopefully commit it next week.
I've uploaded pre-built firmware images to
https://people.freebsd.org/~bcran/bhyve/BhyveX64-20201122/ .
--
Re
e port
changes would be welcome. There's an upstream edk2-stable202011 tag
coming up soon, and I'd like to fix any issues in time for that.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org
yve . It's
getting rather outdated though and I need to spend some time updating it.
Also, I'm really hoping we can agree to drop the requirement that the
port needs CSM support, in which case I can update uefi-edk2-bhyve to
use the TianoCore version
dce9-11ea-b840-0cc47ad8c988"
smbios.system.version="1.0"
I was thinking about this recently. I wonder if we should report the
version as the underlying FreeBSD host version? Or some combination of
that and the git hash etc.?
--
Rebecca Cran
___
│
│ 0xfffcd3e3
(bad)
│
│ 0xfffcd3e4
(bad)
│
│ 0xfffcd3e5 (bad)
Should this work?
C to "cc", which
uses the system's clang compiler, which can't compile the assembly code.
I don't know if we might want to either hard-code CC to "gcc" for now,
or have users create a 'cc' symlinks in BaseTools/Bin/FreeBSD-amd64 ?
--
Rebecca Cran
__
I was wondering, has anyone done any work on supporting debugging UEFI
code under Bhyve? If not, I can take a look at adapting DebugPkg
(https://code.bluestop.org/w/tianocore/debugging-with-gdb/).
--
Rebecca Cran
___
freebsd-virtualization
the BIOS version and release date that
are shown in the BIOS section of the SMBIOS data.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send a
n is supported
UEFI is supported
BIOS Revision: 5.13
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail t
On 3/29/19 2:08 PM, Rebecca Cran via freebsd-virtualization wrote:
I ran the SCT 2.6 against the updated Bhyve firmware and uploaded the
results to https://bluestop.org/files/Summary.log .
I'm not sure how the failures compare with either the current firmware
or OVMF though, so I'
:
Vendor: EFI Development Kit II / OVMF
BiosVersion: 0.0.0
BiosReleaseDate: 02/06/2015
Whereas, we have:
Vendor: BHYVE
BiosVersion: 1.00
BiosReleaseDate: 03/14/2014
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing
On 3/29/19 12:29 PM, Rebecca Cran via freebsd-virtualization wrote:
On 3/25/19 3:59 PM, D Scott Phillips wrote:
Yep, makes sense to me. For either of these changes we would want to get
test converage on basically all functionality, so might as well take
both changes at once.
One thing I
v1.00 released 3/14/2014. It would be nice if we could update that.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virt
Windows, and probably running
the SCT and FWTS.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-uns
On 3/22/19 4:29 PM, Rebecca Cran via freebsd-virtualization wrote:
On 3/22/19 2:25 PM, D Scott Phillips wrote:
Hmm, I guess it might be some diference in the code generation between
gcc 4.8 and gcc 5.
I've just tested switching from gcc 4.8 to 8.3.0 and everything seems
to work fine -
On 3/22/19 2:25 PM, D Scott Phillips wrote:
Hmm, I guess it might be some diference in the code generation between
gcc 4.8 and gcc 5.
I've just tested switching from gcc 4.8 to 8.3.0 and everything seems to
work fine - both build and runtime - so I think it may be more
productive to upgrade
copy: error: the input file
'/home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_GCC48/X64/OvmfPkg/AmdSevDxe/AmdSevDxe/DEBUG/AmdSevDxe.dll'
has no sections
make: *** [GNUmakefile:383:
/home/bcran/workspace/bhyveedk2/Build/OvmfX64/RELEASE_G
l runs
fine. And that’s complicated by the fact that the DEBUG build generates a
triple fault even with gcc 4.8.
—
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualizat
t (but using an installation of
gcc 4.8) works great for me, though I ran into problems with the DEBUG
build and the GCC48 toolset.
--
Rebecca Cran
___
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-vi
enable the kernel to
be fetched via http.
—
Rebecca Cran
On Mar 21, 2019, 6:46 PM -0600, D Scott Phillips ,
wrote:
> Hi freebsd-virtualization,
>
> Recently I wanted to be able to do UEFI HTTP Boot in bhyve, so I've
> rebased the bhyve firmware up to the latest upstream tag,
&g
On Saturday, 17 November 2018 09:29:34 MST Subbsd wrote:
> Thus, perhaps the root of this problem should be sought in
> uefi-edk2-bhyve the package. Latest CBSD release (12.0.1) fixed this
> problem by disabling serial console. However, CBSD uses an alternative
> boot method for bhyve ( uefi-edk2
On Wednesday, 14 November 2018 19:56:56 MST Warner Losh wrote:
> What is the ConOut evifar look like? We set serial when the UEFI env says
> to do so.
Booting with:
sudo bhyve -A -P -c 2 -H -m 4G -s 0:0,hostbridge -s 31:0,lpc -s 2,ahci-
cd,FreeBSD-12.0-BETA4-amd64-disc1.iso -s
29,fbuf,tcp=0.0.
On November 14, 2018 at 2:18:04 PM, Subbsd
(sub...@gmail.com(mailto:sub...@gmail.com)) wrote:
>
> My current host: FreeBSD 13.0-CURRENT r340319 and the problem is
> still present.
Rod was asking about the guest OS version, not the host though.
__
On Tuesday, 13 November 2018 18:57:25 MST Kyle Evans wrote:
> However, because loader-land is funny in a not-ha-ha kind of way, can
> you try replacing loader.efi on your guest VM with the Forth-flavored
> version to rule that out or narrow it down, please?
That didn't help.
As probably expected,
On November 13, 2018 at 8:36:34 AM, Rodney W. Grimes
(freebsd-...@pdx.rh.cn85.dnsmgr.net) wrote:
Since you are using uefi and specifying a graphics console with tcp=,wait
your vm is waiting for a vnc connection to port 5900 to display the
console.
But I connect to VNC, see the loader and
I'm just getting started using bhyve (on a 13-CURRENT host from Oct 28), and
for the work I'm doing need to use UEFI. However, I'm finding that when booting
FreeBSD 12.0-BETA4 the screen goes blank as FreeBSD takes over the console
after the loader is finished.
The command I'm running is:
sudo
nking
that you have to do the software GIC on this platform.
On a similar note, the SoftIron OverDrive 1000
(https://softiron.com/development-tools/overdrive-1000/) might be
suitable? It uses an A57 in an Opteron A1100 SoC. At $600 it's
relatively affordable for a complete system.
ork/uefi-edk2-0.1/Build/BhyveX64/RELEASE_GCC48/X64/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe'
make[1]: *** [GNUmakefile:872:
/construction/xports/sysutils/uefi-edk2-bhyve/work/uefi-edk2-0.1/Build/BhyveX64/RELEASE_GCC48/X64/IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe/DEBUG/D
Could you give us some more information, such as what went wrong, and any error
messages?
Rebecca
Sent from my phone
> On May 19, 2018, at 8:25 PM, Rajil Saraswat wrote:
>
> Hello,
>
> Has anybody managed to run Ubuntu 18.04 under bhyve?
>
> I was unable to get it working with churchers vm
On 12/27/2017 10:15 AM, Alan Somers wrote:
I fear that you may be out of luck. Windows deliberately frustrates this
use case by profiling its hardware at installation time and at every boot
thereafter. If the hardware changes too much, then Windows demands a new
license fee. Moving from physi
47 matches
Mail list logo
