On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote:
Using qemu 1.4.0:
# qemu -hda test.raw -m 512 -cdrom
Hi,
Probably works, but never appeared in a separate release:
commit 3588185b8396eb97fd9efd41c2b97775465f67c4
Author: Gerd Hoffmann kra...@redhat.com
Date: Mon Jan 21 09:17:16 2013 +0100
seabios: update to 1.7.2 release
Built with gcc (GCC) 4.4.7 20120313 (Red
Hi,
Would qemu consider using those blobs rather than different developers
using their distro toolchain to build up a random commit ID. I say
random only because often qemu releases ship with a non-release
seabios.
It happened (well, the snapshot thing). But that isn't our preferred
On 03/07/13 09:43, Aurelien Jarno wrote:
I did a git bisect to find the commit fixing the issue. Then, as I was
not believing the result, I tried the following sequence a dozen of
times (for some unknown reasons the FreeBSD install CD doesn't exhibit
the issue, so I used the Debian
07.03.2013 15:56, Gerd Hoffmann wrote:
Just a note, or an alternative opinion, so to say. In Debian, we have
a social contract which, among other things, ensures that the binaries
you, as a user, get, comes with source which you can modify on the
system you installed. This requires, for
On Thu, Mar 07, 2013 at 01:16:54PM +0100, Laszlo Ersek wrote:
On 03/07/13 09:43, Aurelien Jarno wrote:
I did a git bisect to find the commit fixing the issue. Then, as I was
not believing the result, I tried the following sequence a dozen of
times (for some unknown reasons the FreeBSD
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
That change is definitely just build related - I don't see how it
could impact the final SeaBIOS binary. How did you conclude that this
commit is what fixes the
On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge pe...@stuge.se wrote:
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
On 7 March 2013 14:12, Doug Goldstein car...@gentoo.org wrote:
On Wed, Mar 6, 2013 at 7:58 PM, Peter Stuge pe...@stuge.se wrote:
For coreboot we recommend to build a vanilla toolchain using known
good versions. We also have a script to do that. (The script is at
util/crossgcc/buildgcc in the
On 03/07/13 03:43, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
On Thu, Mar 07, 2013 at 12:12:08AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 08:21:11AM +, Dietmar Maurer wrote:
[snip]
Maybe I am doing something wrong or there is a bug
On 03/07/13 08:57, Kevin O'Connor wrote:
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
That change is definitely just build related - I don't see how it
could impact the final SeaBIOS binary. How did you
On 7 March 2013 19:56, Gerd Hoffmann kra...@redhat.com wrote:
We don't even ship any upstream blobs in the debian qemu _source_
package: we repack upstream qemu.tar.gz by removing these blobs.
That's a bit over the top for my taste as the release tarballs include
both source and blobs.
Hi,
In general having blobs in our allegedly source tarball is pretty
ugly. Either it's a source release or it isn't. We can do a
release-of-blobs tarball too if we want, but it doesn't need
to be in the source tarball
This is easily doable, just an update to scripts/make-release to spew
On 7 March 2013 23:56, Gerd Hoffmann kra...@redhat.com wrote:
Peter Maydell wrote:
In general having blobs in our allegedly source tarball is pretty
ugly. Either it's a source release or it isn't. We can do a
release-of-blobs tarball too if we want, but it doesn't need
to be in the source
Il 07/03/2013 15:00, Don Slutz ha scritto:
Turns out that this is not the normal kind of issue. Newer seabios
works, older does not:
good * 88cb66e (HEAD, tag: rel-1.7.2.1, origin/1.7.2-stable,
1.7.2-stable) seabios: Add a dummy PCI slot to irq mapping funct
good * 985a9d3 seabios q35:
On Thu, Mar 07, 2013 at 08:57:06AM -0500, Kevin O'Connor wrote:
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
That change is definitely just build related - I don't see how it
could impact the final SeaBIOS
On Fri, Mar 08, 2013 at 12:03:15AM +0800, Peter Maydell wrote:
On 7 March 2013 23:56, Gerd Hoffmann kra...@redhat.com wrote:
Peter Maydell wrote:
In general having blobs in our allegedly source tarball is pretty
ugly. Either it's a source release or it isn't. We can do a
release-of-blobs
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 test
In general having blobs in our allegedly source tarball is pretty ugly.
Either it's a
source release or it isn't. We can do a release-of-blobs tarball too if we
want,
but it doesn't need to be in the source tarball and it doesn't need to be in
git
either IMHO.
I think it is very
On Thu, Mar 07, 2013 at 04:59:43PM +0800, WANG Siyuan wrote:
Hi,
I am trying to boot a hard disk image using coreboot and seabios on
SimNow Simulator.
The system stops at seabios stage.
PORT_CMD_START fails in function ahci_port_setup (seabios/src/ahci.c),
Then I traced into function
Thank you,
1) It is time out, the log is:
AHCI/0: probing
AHCI/0: link up
AHCI/0: send cmd ...
WARNING - Timeout at ahci_command:158!
AHCI/0: send cmd ...
WARNING - Timeout at ahci_command:158!
in line 158(src/ahci.c) is warn_timeout();
2) If ahci is disabled, the simulator can not find hard
On Thu, Mar 07, 2013 at 09:43:04AM +0100, Aurelien Jarno wrote:
On Wed, Mar 06, 2013 at 07:53:51PM -0500, Kevin O'Connor wrote:
That change is definitely just build related - I don't see how it
could impact the final SeaBIOS binary. How did you conclude that this
commit is what fixes the
According to this piece of code in src/ahci.c, seabios fails to set
DMA or PIO on ahci. PORT_IRQ_STAT is 0.
end = calc_future_tsc(AHCI_REQUEST_TIMEOUT);
do {
for (;;) {
intbits = ahci_port_readl(ctrl, pnr, PORT_IRQ_STAT);
//dprintf(1, intbits == 0x%x\n,
Il 07/03/2013 21:24, David Woodhouse ha scritto:
On Thu, 2013-03-07 at 16:56 +0100, Gerd Hoffmann wrote:
and it doesn't need to be in git either IMHO.
That one is a bit more tricky. The big advantage git has here is that
the update of a blob is not different from other updates. It is just
Il 07/03/2013 17:21, Aurelien Jarno ha scritto:
On the QEMU side, we should definitely have an autotest system trying to
boot a few guests (and if possible with some !linux) to detect such
issues. That's not something easy to do, maybe that could be a good
GSoC project?
There is virt-test
25 matches
Mail list logo
