Am 31.05.2013 00:51, schrieb Amos Kong:
On Thu, May 30, 2013 at 10:30:21PM +0200, Stefan Priebe wrote:
Am 30.05.2013 15:13, schrieb Amos Kong:
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG
wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in
On Thu, May 30, 2013 at 7:34 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it
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 sounds a
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes.
load the boot firmware (SeaBIOS or OVMF or
something else -- not sure how to configure that),
The coreboot rom has
Am 31.05.2013 13:02, schrieb Amos Kong:
...
thanks for this great explanation. I've done what you sayd but it still
does not work.
Here is the output of the seabis debug log where you see the loop:
http://pastebin.com/raw.php?i=e53rdW2b
| found virtio-scsi at 0:5
| Searching bootorder
On 05/31/13 09:09, Jordan Justen wrote:
Why is updating the ACPI tables in seabios viewed as such a burden?
Either qemu does it, or seabios... (And, OVMF too, but I don't think
you guys are concerned with that. :)
I am :)
On the flip side, why is moving the ACPI tables to QEMU such an
- Original Message -
From: Kevin O'Connor ke...@koconnor.net
To: Dave Frodin dave.fro...@se-eng.com
Cc: seabios seabios@seabios.org
Sent: Thursday, May 30, 2013 7:45:13 PM
Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option
ROMs to one
On Thu, May 30,
Kevin O'Connor ke...@koconnor.net writes:
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote:
There were discussions on potentially introducing a middle component
to generate the tables. Coreboot was raised as a possibility, and
David thought it would be okay to use coreboot for
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module, and
On 05/31/13 10:13, Peter Stuge wrote:
ACPI bytes are obviously a function of QEMU configuration.
Precisely!
When we evaluate that (mathematical-sense) function in boot firmware, we
need to retrieve the function's arguments. Those arguments are bits of
QEMU configuration, as you say, and fw_cfg
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
On 05/31/13 03:09, Kevin O'Connor wrote:
On Thu, May 30, 2013 at 09:30:33AM +0200, Gerd Hoffmann wrote:
On 05/30/13 03:34, Kevin O'Connor wrote:
On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
Allow selecting DEBUG_IO for non-qemu configurations,
which is useful when running
On 05/31/13 15:04, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
:)
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable
On 05/31/13 16:08, David Woodhouse wrote:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork. It's modular, and the FAT
driver is just a
Laszlo Ersek ler...@redhat.com writes:
On 05/31/13 09:09, Jordan Justen wrote:
Due to licensing differences I can't just port code from SeaBIOS to
OVMF
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Rewriting BSD implementations of
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org
wrote:
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote:
Where is CorebootPkg available from?
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the
On Wed, 2013-05-29 at 21:12 -0400, Kevin O'Connor wrote:
I remain doubtful that QOM has all the info needed to generate the
BIOS tables. Does QOM describe how the 5th pci device uses global
interrupt 11 when using global interrupts, legacy interrupt 5 when not
using global interrupts, and
On 05/31/13 16:38, Anthony Liguori wrote:
It's either Open Source or it's not. It's currently not.
I disagree with this binary representation of Open Source or Not. If it
weren't (mostly) Open Source, how could we fork (most of) it as you're
suggesting (from the soapbox :))?
I have a hard
On 05/31/13 17:43, Anthony Liguori wrote:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 08:04 -0500, Anthony Liguori wrote:
soapbox
Fork OVMF, drop the fat module, and just add GPL code. It's an easily
solvable problem.
Heh. Actually it doesn't need to be a fork.
On 05/31/13 18:33, David Woodhouse wrote:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a sense
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2 usable, and yes, that's not Open
Source. So in a
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
The FAT module is required to make EDK2
Paolo Bonzini pbonz...@redhat.com writes:
Il 31/05/2013 19:06, Anthony Liguori ha scritto:
David Woodhouse dw...@infradead.org writes:
On Fri, 2013-05-31 at 10:43 -0500, Anthony Liguori wrote:
It's even more fundamental. OVMF as a whole (at least in it's usable
form) is not Open Source.
Applied. Thanks.
Regards,
Anthony Liguori
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
On Fri, May 31, 2013 at 7:38 AM, Anthony Liguori anth...@codemonkey.ws wrote:
In terms of creating a FAT module, the most likely source would seem to
be the kernel code and since that's GPL, I don't think it's terribly
avoidable to end up with a GPL'd uefi implementation.
Why would OpenBSD not
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws wrote:
As I think more about it, I think forking edk2 is inevitable. We need a
clean repo that doesn't include the proprietary binaries. I doubt
upstream edk2 is willing to remove the binaries.
No, probably not unless a
Jordan Justen jljus...@gmail.com writes:
On Fri, May 31, 2013 at 11:35 AM, Anthony Liguori anth...@codemonkey.ws
wrote:
As I think more about it, I think forking edk2 is inevitable. We need a
clean repo that doesn't include the proprietary binaries. I doubt
upstream edk2 is willing to
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kra...@redhat.com wrote:
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data
necessary for ACPI table building through the current (same) fw_cfg
bottleneck, build the tables,
Yes.
So, this is really about making
Am 31.05.2013 14:09, schrieb David Woodhouse:
On Thu, 2013-05-30 at 09:20 -0700, Jordan Justen wrote:
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org
wrote:
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
Is the license on this actually BSD as the License.txt indicates?
On Fri, May 31, 2013 at 08:32:16AM -0500, Dave Frodin wrote:
I see now, that's pretty slick. The problem I see with that approach is
that coreboot would need to add all of these files for a family14 mainboard.
[...]
And all of these files for a family15 mainboard
[...]
Since at build time we
On Fri, May 31, 2013 at 03:30:48PM +0200, Laszlo Ersek wrote:
On 05/31/13 03:09, Kevin O'Connor wrote:
Same problem - one can't reliably do an inb(0xe9) on real hardware
without risking mysterious failures.
This entire problem seems to exist only if someone runs a SeaBIOS binary
on real
On Fri, May 31, 2013 at 10:13:34AM +0200, Peter Stuge wrote:
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)
32 matches
Mail list logo
