Older versions of gcc may not inline on_extra_stack() and thus cause a
link error when compiling in 32bit segmented mode. Test for MODE16
explicitly in stack_hop_back() to prevent the problem.
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/stacks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/stacks.c b/src/stacks.c
index 6f40cbe..0c033d1 100644
--- a/src/stacks.c
+++ b/src/stacks.c
@@ -430,7 +430,7 @@ stack_hop_back(u32 eax, u32 edx, void *func)
{
if (!MODESEGMENT)
return call16_back(eax, edx, func);
- if (!on_extra_stack())
+ if (!MODE16 || !on_extra_stack())
return ((u32 (*)(u32, u32))func)(eax, edx);
ASSERT16();
u16 bkup_ss;
--
1.9.3
Hello,
I'm looking for a fix in http://code.coreboot.org/p/seabios/source/tree/master/scripts/layoutrom.py file. Apparently the fix is already in the master, but it's hard for me to use directly from master. Currently all existing tags are old and doesn't reflect latest layoutrom.py changes.
Can you please create a new tag from master so that I can use it in my project? I'm trying to compile seabios code with Intel compiler, but it keep failing because of layoutrom.py file __func__ check.
Thanks,
Sunil Pandey
This is a resend of two previous patches that improve the text
emulation of the "coreboot native vga" SeaVGABIOS support. The main
difference in this version is that the support requires both a compile
time define (CONFIG_VGA_EMULATE_TEXT) as well as runtime enablement.
The net effect of this is that the code wont try to blink the cursor
if a bootloader explicitly switches into graphics mode.
This is also available at:
https://github.com/KevinOConnor/seabios/tree/testing
-Kevin
Kevin O'Connor (2):
vgabios: Support emulating text mode attributes while in graphics mode
vgabios: Add software cursor capability
vgasrc/Kconfig | 6 ++++
vgasrc/cbvga.c | 10 +++++--
vgasrc/vbe.c | 5 ++--
vgasrc/vgabios.c | 13 ++++++--
vgasrc/vgabios.h | 14 ++++++++-
vgasrc/vgaentry.S | 30 +++++++++++++++++++
vgasrc/vgafb.c | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
vgasrc/vgainit.c | 34 +++++++++++++++++++++
8 files changed, 188 insertions(+), 13 deletions(-)
--
1.9.3
On Sun, Jun 22, 2014 at 05:54:17PM +0200, Idwer Vollering wrote:
> > So, this looks different from Matt's report. What appears to be
> > happening in the above is that the device shows up originally as a
> > high speed device (see "[High]" above). However, when the set_address
> > command is sent to it, it appears that the device effectively
> > disconnects and then reconnects as a super speed device (see "change
> > port #2" and "change port #4" above - port 2==port 4 - see ("offset 1"
> > / "offset 3" above)).
> >
> > You can try increasing the xchi_event_wait timeout which fixes Matt's
> > issue, but I think we tried this on your hardware before with no luck.
>
> Indeed, changing 1000 to 5000 or USB_TIME_COMMAND in
> src/hw/usb-xhci.c:501 didn't matter.
Can you retry with the patch series I just posted? It's also at:
https://github.com/KevinOConnor/seabios/tree/testing
It may help with this device.
-Kevin
Some newer cards have the I/O bar at BAR 0, so we need to check
that, too, if we cannot get an address for BAR 2.
Without this patch the new 'megasas-gen2' emulation in qemu
is not detected.
Signed-off-by: Hannes Reinecke <hare(a)suse.de>
---
src/megasas.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/megasas.c b/src/megasas.c
index f4eeba0..167fc32 100644
--- a/src/megasas.c
+++ b/src/megasas.c
@@ -353,6 +353,10 @@ init_megasas(struct pci_device *pci)
u32 iobase = pci_config_readl(pci->bdf, PCI_BASE_ADDRESS_2)
& PCI_BASE_ADDRESS_IO_MASK;
+ if (!iobase)
+ iobase = pci_config_readl(pci->bdf, PCI_BASE_ADDRESS_0)
+ & PCI_BASE_ADDRESS_IO_MASK;
+
dprintf(1, "found MegaRAID SAS at %02x:%02x.%x, io @ %x\n",
pci_bdf_to_bus(bdf), pci_bdf_to_dev(bdf),
pci_bdf_to_fn(bdf), iobase);
--
1.8.4.5
Hi,
> so i wonder where in source code of seabios calculate PCI BAR address?
src/fw/pciinit.c initializes all pci devices and assigns addresses to
the bars. bars are sorted by size for best packing, so the addresses
they end up depends on the size and also which other devices are
present.
> and also, i wonder why qemu's vga pci bar address is different from
> virtualbox's vga pci bar address though
> both of devices are classified as same 'vga' device(class id number :
> 0x30)
There is no need for it to have a fixed address.
> (in Virtualbox, VGA PIC BAR ADDRESS always starts from e0000000 and it
> is VBE standard)
I doubt it is VBE standard.
cheers,
Gerd
Hi SeaBios!!
I'm qemu user and i want to modify qemu vga device to start BAR Address
from 0xE0000000
As you know, Qemu uses SEABIOS as system bios
but when i look into Qemu Debug console, right using command "info pci"
then it just shows value for PCI BAR address : 0xf0000000
and it seems that VGA PCI BAR address change by the size of VGA RAM(VRAM)
size
(if VRAM is 128MB, BAR address = 0xf0000000, if it is 256MB, BAR address =
0xe0000000)
It seems during booting time seabios calculate VGA PCI BAR address as
0xf000000 when its VRAM size is 128MB.
so i wonder where in source code of seabios calculate PCI BAR address?
and also, i wonder why qemu's vga pci bar address is different from
virtualbox's vga pci bar address though
both of devices are classified as same 'vga' device(class id number : 0x30)
(in Virtualbox, VGA PIC BAR ADDRESS always starts from e0000000 and it is
VBE standard)
The full 66 bytes of the EDD 3.x buffer were already filled, but the
size field wasn't updated so that we would return that only the first 30
bytes of it are valid (like for 2.x). Fix the size field.
Signed-off-by: Kevin Wolf <kwolf(a)redhat.com>
---
src/block.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/block.c b/src/block.c
index 7892be5..46afca0 100644
--- a/src/block.c
+++ b/src/block.c
@@ -339,6 +339,7 @@ fill_generic_edd(u16 seg, struct int13dpt_s *param_far, struct drive_s *drive_gf
return DISK_RET_SUCCESS;
// EDD 3.x
+ SET_FARVAR(seg, param_far->size, 66);
SET_FARVAR(seg, param_far->key, 0xbedd);
SET_FARVAR(seg, param_far->dpi_length, t13 ? 44 : 36);
SET_FARVAR(seg, param_far->reserved1, 0);
--
1.8.3.1