Gerd Hoffmann wrote:
> +++ b/src/optionroms.c
> @@ -193,6 +193,11 @@ run_file_roms(const char *prefix, int isvga, u64
> *sources)
> file = romfile_findprefix(prefix, file);
> if (!file)
> break;
> +if (strcmp(file->name, "vgaroms/sgabios.bin") == 0 &&
> +
Gerd Hoffmann wrote:
> * Initializing all pci devices (placing bars in address space and
>programming them) can probably be skipped and left to the linux
>kernel to handle.
When the coreboot project started out, in 1999, that turned out not
to be the case. I don't know if the situation ha
Anthony Liguori wrote:
> However, with PCs, the ACPI tables are generated by/included in the
> firmware. There's no question about that.
I think the key point is that the firmware is developed and delivered
by the hardware vendor, and not by an independent source.
The firmware is intimately tied
Gerd Hoffmann wrote:
> > and pass down the
> > tables to the firmware (through a now unspecified interface -- perhaps
> > the tables could even be installed at this point).
>
> As far I know coreboot can add more stuff such as acpi tables to cbfs at
> runtime and seabios able to access cbfs too an
Kevin O'Connor wrote:
> one possible way forward would be to split the current SeaBIOS rom
> into two roms: "qvmloader" and "seabios". The "qvmloader" would do
> the qemu specific platform init (pci init, smm init, mtrr init, bios
> tables) and then load and run the regular seabios rom.
qvmloader
Kevin O'Connor wrote:
> I don't believe that dictating one "true compiler" or one "true
> blob" is necessary or desirable.
Sure. The point isn't to have only one correct way, but to have
reliable results in the common case.
A reference toolchain and a reference blob both help accomplish
that, but
Aurelien Jarno wrote:
> > > We probably want update the build process to build the blobs by default
> >
> > Earlier in this thread it's been stated that this often produces
> > subtly broken blobs...
>
> Would it be possible to have a testsuite to validate such blobs.
The coreboot project has a
Laszlo Ersek wrote:
> Going out on a limb, I suspect qemu commit 5f876756 instead.
..
> I think the gcc version Anthony was using miscompiled SeaBIOS
Yeah, it is very common. Lots of distributions patch their
toolchains such that they don't compile firmware code correctly.
Firmware isn't a common
Paolo Bonzini wrote:
> > That is: perhaps it's a *SeaBIOS* bug that suspend/resume doesn't
> > work if the PAM configuration is reset?
>
> Yeah, it sounded a bit weird when I wrote that commit message.
> This could be the case. How does it work on Coreboot?
Yes all hardware except RAM in self-r
Hi list!
I have an XP guest originally from qemu-kvm-0.15 which I use for
a smart card application by passing a full-speed USB CCID card
reader from the host per subject, on an x86_64 host with kvm.
Avi's qemu-kvm.git at old tag v0.15.1 with -machine pc works fine.
qemu.git master commit 6034fe7
Luiz Capitulino wrote:
> Using latest seabios makes it go away, didn't try re-building
> 1.6.3.1 though.
Try it, if your toolchain is not broken it should work.
//Peter
Jan Kiszka wrote:
> Well, the Linux kernel can also be built with practically any distro
> out there.
Yeah. Maybe that gets tested more than building coreboot and SeaBIOS,
and so problems are discovered by those who introduce them.
> Having a need for a separate toolchain for building x86 on x86
Jan Kiszka wrote:
> > Then I noticed, that if I rebuild the BIOS, from the exact same revision
> > 1.6.3.1 revision that is committed in 'seabios' submodule in QEMU, then
> > it works fine. So AFAICT, it is not the Seabios source code at fault,
> > but rather the binary build we have commited to GI
Gleb Natapov wrote:
> BBS specification is broken since it doesn't provide a way for
> discovered boot method (BCV) to be linked back to a device it will
> boot from. Nothing we can do to fix this except moving to EFI (an
> hope the problem is fixed there).
There is that option, or there could be
François Revol wrote:
> > usbip
I don't know how good this is.
For another implementation of USB-over-IP you could look at Sun's
work with the SunRay thin clients. I believe some of it may be in
the OpenUSB codebase. (They forked libusb to make it work the way
they wanted.) I don't know how good
Peter Stuge wrote:
> Specifying boot device using PCI BDF is a great example of using
> common structured data. That BDF exists both in machine and firmware
> data models.
Gleb Natapov wrote:
> Bus numbers are assigned by a guest. Qemu knows nothing about them,
> so it specify
Gleb Natapov wrote:
> There is no way for qemu to know about BCVs or BEVs
This is very much the key point.
In order to have command line control over the boot process, the
machine and the firmware must agree on things.
I see two options:
1. QEMU works very very hard to provide a machine that wi
Avi Kivity wrote:
> In general, ACPI code can work with memory or device registers that have
> been initialized by the BIOS and depend on them. It's possible to write
> ACPI code that depends on preceding BIOS code.
It's also possible to write C code that makes extensive use of goto. :)
To be
My background is that of a strong coreboot proponent.
Gleb Natapov wrote:
> So why not go further? In theory qemu needs seabios only for legacy bios
> functionality. Qemu is perfectly capable of configuring HW to OS usable
> state by itself, so we can have coreboot functionality completely inside
19 matches
Mail list logo
