Hi Ivan,
On 03.04.2018 20:03, Ivan Ivanov wrote:
> I have noticed that both coreboot and seabios are using the very old
> versions of LZMA SDK.
True. I introduced the lzma code in coreboot (back when it was called
LinuxBIOS) when we were working on OLPC XO-1 support.
> If we will upgrade our LZMA libraries from the
> outdated-by-12-years 4.42 to the current version 18.04 , speed and
> compression ratio should improve and maybe a few bugs will be fixed.
Do you have any numbers for this? An improved compression ratio and
improved speed would be nice indeed, but how does the size of the
decompression code change? If the decompression code grows more than the
size reduction from better compression, it would be a net loss. A
significantly reduced decompression speed would also be a problem.
Decompression speed would have to be measured both for stream
decompression (i.e. the decompressor gets the compressed data in
single-byte or multibyte chunks) as well as full-size decompression
(i.e. the decompressor can access all compressed data at once). We also
have to make sure that stream decompression still works after the change.
> Do you think it should be done, or you are OK with using such an
> outdated version?
A size benefit for the resulting image is a good reason to switch.
Regards,
Carl-Daniel
Hi folks,
So, here is the current state of the seabios update for the upcoming
qemu 3.0 release. This time it is a bit more than just the usual
"update submodule and binaries".
seabios 1.11.2 is not released yet. The plan is to cherry-pick the
changes needed to support the new qemu 3.0 display devices
(bochs-display and ramfb) into the 1.11-stable branch for the 1.11.2
release. Current state is here:
https://git.kraxel.org/cgit/seabios/log/?h=1.11-stable-testing
Changes in this patch series:
- seabios submodule update (to the testing branch).
- new vgabios configs for bochs-display and ramfb.
- update the bios config to enables ide dma (for qnx).
- drop (old) vgabios submodule and build rules.
- seabios binary update.
- make bochs-display and ramfb load the new vgabios roms.
Git branch for this series is here:
https://git.kraxel.org/cgit/qemu/log/?h=seabios-1.11.2
cheers,
Gerd
Gerd Hoffmann (7):
seabios: update submodule to 1.11.2-testing
seabios: add vga configs for bochs-display and ramfb
seabios: enable ide dma
vgabios: remove submodule and build rules.
seabios: update binaries
bochs-display: enable vgabios
ramfb: enable vgabios
hw/display/bochs-display.c | 1 +
hw/display/ramfb.c | 1 +
.gitmodules | 3 ---
pc-bios/bios-256k.bin | Bin 262144 -> 262144 bytes
pc-bios/bios.bin | Bin 131072 -> 131072 bytes
pc-bios/vgabios-cirrus.bin | Bin 38400 -> 38400 bytes
pc-bios/vgabios-qxl.bin | Bin 38912 -> 38912 bytes
pc-bios/vgabios-stdvga.bin | Bin 38912 -> 38912 bytes
pc-bios/vgabios-virtio.bin | Bin 38912 -> 38912 bytes
pc-bios/vgabios-vmware.bin | Bin 38912 -> 38912 bytes
pc-bios/vgabios.bin | Bin 38400 -> 38400 bytes
roms/Makefile | 20 +++-----------------
roms/config.seabios-128k | 1 +
roms/config.seabios-256k | 1 +
roms/config.vga-bochs-display | 3 +++
roms/config.vga-ramfb | 3 +++
roms/seabios | 2 +-
roms/vgabios | 1 -
18 files changed, 14 insertions(+), 22 deletions(-)
create mode 100644 roms/config.vga-bochs-display
create mode 100644 roms/config.vga-ramfb
delete mode 160000 roms/vgabios
--
2.9.3
Hello,
Recently my qemu with gpu passthrough setup quit working.
I think it is seabios related.
i have turned on debugging for seabios.
Here is the output from seabios from a successful windows 10 boot using
an emulated vga adapter:
https://pastebin.com/f3DCqTbc
Here is the output when using my nvidia gtx 880m 8gb gaming card:
https://pastebin.com/GpWKZadh
when seabios runs the option rom for nvidia it just halts.
i have never debuged seabios before so i dont know what would normally
show up at this point.
i.e. is this normal or is something wrong.
during the vga boot all 8 cpus go to 100% for a short time then drop.
during the failed boot with nvidia 1 cpu goes to 100% and stays there
forever. i have let it run all night at times.
i am seeking to figure out if i have a seabios issue.
i am running linux mint 18.3 and the repo copy of seabios is 1.8.2.
i have booted this 100's of times and never had an issue before.
thanks
Hi folks,
I ran into this problem while building Xen. unfortunately, I have
trouble building the same files with seabios git, and have even more
limited ability to test the changes.
Apparently ACPI says that the OEM Table Id must be length 8. Some of the
tables in seabios use longer. newer iASL rejects this and fails to
build the code. Most likely things handle it as if it was truncated, but
perhaps it overran to the next field.
I've used this diff, for your consideration.
diff --git a/src/fw/ssdt-misc.dsl b/src/fw/ssdt-misc.dsl
index acc850e..d1d2c9e 100644
--- a/src/fw/ssdt-misc.dsl
+++ b/src/fw/ssdt-misc.dsl
@@ -1,6 +1,6 @@
ACPI_EXTRACT_ALL_CODE ssdp_misc_aml
-DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSUSP", 0x1)
+DefinitionBlock ("ssdt-misc.aml", "SSDT", 0x01, "BXPC", "BXSSDTSU", 0x1)
{
/****************************************************************
diff --git a/src/fw/ssdt-pcihp.dsl b/src/fw/ssdt-pcihp.dsl
index cb24c11..518a5eb 100644
--- a/src/fw/ssdt-pcihp.dsl
+++ b/src/fw/ssdt-pcihp.dsl
@@ -1,6 +1,6 @@
ACPI_EXTRACT_ALL_CODE ssdp_pcihp_aml
-DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1)
+DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPC", 0x1)
{
/****************************************************************
On Mon, 2018-06-04 at 09:31 -0400, Kevin O'Connor wrote:
> On Mon, Jun 04, 2018 at 09:29:17AM +0200, Gerd Hoffmann wrote:
> > Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
> > ---
> > vgasrc/cbvga.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c
> > index 3f16bee10c..f6ebe71242 100644
> > --- a/vgasrc/cbvga.c
> > +++ b/vgasrc/cbvga.c
> > @@ -192,8 +192,16 @@ int
> > cbvga_set_mode(struct vgamode_s *vmode_g, int flags)
> > {
> > u8 emul = vmode_g == &CBemulinfo || GET_GLOBAL(CBmode) == 0x03;
> > + /*
> > + * The extra_stack flag is false when running in windows x86
> > + * emulator, to avoid stack switching triggering bugs. Using the
> > + * same flag here to skip screen clearing, because the windows
> > + * emulator seems to have problems to handle the int 1587 call
> > + * too, and GO_MEMSET uses that.
> > + */
> > + u8 extra_stack = GET_BDA_EXT(flags) & BF_EXTRA_STACK;
> > MASK_BDA_EXT(flags, BF_EMULATE_TEXT, emul ? BF_EMULATE_TEXT : 0);
> > - if (!(flags & MF_NOCLEARMEM)) {
> > + if (!(flags & MF_NOCLEARMEM) && extra_stack) {
>
> FYI, extra_stack will only be true if CONFIG_VGA_ALLOCATE_EXTRA_STACK
> is set, but I guess that's okay.
>
> Thanks, the series looks good to me.
> -Kevin
This commit breaks SeaBIOS' menu when used with coreboot's native
graphic init in text mode. Payloads are not affacted (tested NTLDR and
coreinfo).
Everything works fine with native graphic init in high resolution
framebuffer mode. I've got no debug log at hand, but I'll investigate
asap.
Tested on Lenovo T500 using libgfxinit with latest coreboot master.
Regards,
Patrick
>
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org
> https://mail.coreboot.org/mailman/listinfo/seabios
On Fri, 2018-06-22 at 10:14 -0400, Kevin O'Connor wrote:
> On Fri, Jun 22, 2018 at 08:42:50AM +0200, Gerd Hoffmann wrote:
> > On Wed, Jun 20, 2018 at 08:00:28PM +0200, Patrick Rudolph wrote:
> > > This commit breaks SeaBIOS' menu when used with coreboot's native
> > > graphic init in text mode. Payloads are not affacted (tested NTLDR and
> > > coreinfo).
> > > Everything works fine with native graphic init in high resolution
> > > framebuffer mode. I've got no debug log at hand, but I'll investigate
> > > asap.
> > > Tested on Lenovo T500 using libgfxinit with latest coreboot master.
> >
> > Hmm, no clue what could cause this. But clearing the memory is only
> > problematic for the framebuffer case, so maybe the patch below helps?
> >
> > diff --git a/vgasrc/cbvga.c b/vgasrc/cbvga.c
> > index f6ebe71242..a48f4dc885 100644
> > --- a/vgasrc/cbvga.c
> > +++ b/vgasrc/cbvga.c
> > @@ -201,18 +201,20 @@ cbvga_set_mode(struct vgamode_s *vmode_g, int flags)
> > */
> > u8 extra_stack = GET_BDA_EXT(flags) & BF_EXTRA_STACK;
> > MASK_BDA_EXT(flags, BF_EMULATE_TEXT, emul ? BF_EMULATE_TEXT : 0);
> > - if (!(flags & MF_NOCLEARMEM) && extra_stack) {
> > + if (!(flags & MF_NOCLEARMEM)) {
> > if (GET_GLOBAL(CBmodeinfo.memmodel) == MM_TEXT) {
> > memset16_far(SEG_CTEXT, (void*)0, 0x0720, 80*25*2);
> > return 0;
> > }
> > - struct gfx_op op;
> > - init_gfx_op(&op, &CBmodeinfo);
> > - op.x = op.y = 0;
> > - op.xlen = GET_GLOBAL(CBmodeinfo.width);
> > - op.ylen = GET_GLOBAL(CBmodeinfo.height);
> > - op.op = GO_MEMSET;
> > - handle_gfx_op(&op);
> > + if (extra_stack) {
>
> I'm also not sure on the cause, but I think it should be safe to
> change this to:
>
> if (extra_stack || flags & MF_LEGACY) {
>
Seems to be the correct solution, as BF_EXTRA_STACK is set after
cbvga_set_mode and thus extra_stack is 0 on first cbvga_set_mode call.
> because if this is a legacy call then it should be safe to write to
> highmem even if the last call was a vesa modeset.
>
> -Kevin
Hi,
Second version of the ramfb series. Turned out the previous version
didn't work at all, appearently I've tested by accident with an older
rom version which had a copy of the fw_cfg code instead of linking
paravirt.o. Making the linked paravirt.o work turned out to be
difficuilt due to dependencies on stuff like threads which isn't present
in the vgabios builds. So I'm back to the version with the (stripped
down) copy of the fw_cfg code ...
Gerd Hoffmann (3):
pmm: use tmp zone on oom
vgasrc: add allocate_pmm()
qemu: add qemu ramfb support
Makefile | 2 +-
vgasrc/vgahw.h | 28 +++++-----
vgasrc/vgautil.h | 4 ++
src/pmm.c | 13 +++++
vgasrc/ramfb.c | 163 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
vgasrc/vgainit.c | 48 ++++++++++------
vgasrc/Kconfig | 7 +++
7 files changed, 235 insertions(+), 30 deletions(-)
create mode 100644 vgasrc/ramfb.c
--
2.9.3
