Hi Gerd,
I was curious to see what the "sercon" stuff would look like in
SeaVGABIOS instead of in SeaBIOS. So, I put together a quick
prototype. The code is also at:
https://github.com/KevinOConnor/seabios/tree/testing
This is just a proof-of-concept thing - I didn't implement any of the
useful features you have in your series. Specifically, it doesn't
unclutter the serial output, doesn't implement cp437 translations, and
doesn't handle multi-byte input. It does does have basic input,
…
[View More]output, and split-output handling though.
I'm not sure if this is better than a SeaBIOS implementation. I
suspect it will be easier to handle vga quirks this way. However,
handling exotic serial outputs (eg, mmio and usb based) would be
better suited in SeaBIOS.
Thoughts?
-Kevin
Kevin O'Connor (3):
sercon: Initial support for VGA emulation over serial port
sercon: Add basic keyboard input support
sercon: Support "split output" mode
Makefile | 2 +-
vgasrc/Kconfig | 6 +
vgasrc/sercon.c | 356 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
vgasrc/vgabios.c | 15 ++-
vgasrc/vgabios.h | 5 +
vgasrc/vgaentry.S | 7 ++
vgasrc/vgahw.h | 72 ++++++++++-
vgasrc/vgainit.c | 12 +-
vgasrc/vgautil.h | 24 ++++
9 files changed, 482 insertions(+), 17 deletions(-)
create mode 100644 vgasrc/sercon.c
--
2.5.5
[View Less]
On Sat Mar 18 02:04:38 CET 2017, Kevin O'Connor wrote:
>> Assume the GPU is VGA compatible when running in text-mode.
>> Advertise VGA modes using SeaVGABios' stdvga driver.
>> running in text mode, even when not advertised.
>>
>> Allows Windows 7 to boot in 640x480 and 16 colors mode using the
>> VgaSave driver.
>> Allows Windows 7 to show the loading bar splash screen.
>>
>> Known issues:
>> The palette seems wrong, as colors are …
[View More]swapped ( blue is red, ... ).
>
>What graphics hardware did you test this on?
>
>If stdvga_set_mode() works on the hardware, why not use stdvga
>seavgabios and get the rest of the vgabios functionality? (That is,
>why use cbvga seavgabios at all?)
I'm on Lenovo T500 (Intel Graphics Media Accelerator 4500MHD).
I'm going to do some tests using stdvga instead of cbvga.
Regards,
Patrick
[View Less]
A number of SCSI drivers currently only see luns #0 in their targets.
This may be a problem when drives have to be assigned bigger lun
numbers, e.g. because the storage controllers don't provide enough
target numbers to accomodate all drives.
(In particular, I'm about to submit a driver for Hyper-V VMBus SCSI
controller which is limited to 2 targets only).
This series adds generic SCSI lun enumeration (either via REPORT LUNS
command or sequentially trying every lun), and makes the respective
…
[View More]drivers use it.
Note that the series has only been minimally tested against a recent QEMU.
Roman Kagan (9):
blockcmd: accept only disks and CD-ROMs
blockcmd: generic SCSI luns enumeration
virtio-scsi: enumerate luns with REPORT LUNS
esp-scsi: enumerate luns with REPORT LUNS
usb-uas: enumerate luns with REPORT LUNS
pvscsi: fix the comment about lun enumeration
mpt-scsi: try to enumerate luns with REPORT LUNS
lsi-scsi: reset in case of a serious problem
lsi-scsi: try to enumerate luns with REPORT LUNS
src/hw/blockcmd.h | 4 +++
src/hw/blockcmd.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/hw/esp-scsi.c | 35 +++++++++++++------
src/hw/lsi-scsi.c | 39 +++++++++++++++------
src/hw/mpt-scsi.c | 40 ++++++++++++++--------
src/hw/pvscsi.c | 2 +-
src/hw/usb-uas.c | 45 +++++++++++++++---------
src/hw/virtio-scsi.c | 38 ++++++++++++++-------
8 files changed, 235 insertions(+), 64 deletions(-)
--
2.9.3
[View Less]
I use the qemu-2.7 and seabios-1.10.1 to start the windows 7 guest. And the xhci controller is passthroughed to
the guest. When the safe mode interface of the windows 7 appears, keyboard sometimes doesn't work and I can
not choose any mode.
I have referred to seabios code about xhci configuration and find that after initializing USB keyboard, the timer
ISR will check usb event periodically. Normally, the "xhci_process_events" function can process the keyboard events,
but now TRB_C bit of …
[View More]xhci controller has been unchanged and "xhci_process_events" function derectly return. So
keyboard didn't work. I want to know why TRB_C bit of xhci controller is always unchanged. Hope somebody can
help me.
Sorry for my poor English.
static void xhci_process_events(struct usb_xhci_s *xhci)
{
struct xhci_ring *evts = xhci->evts;
for (;;) {
/* check for event */
u32 nidx = evts->nidx;
u32 cs = evts->cs;
struct xhci_trb *etrb = evts->ring + nidx;
u32 control = etrb->control;
if ((control & TRB_C) != (cs ? 1 : 0))
return;//stop here
....
....}
[View Less]
Hi,
I recently installed Coreboot and SeaBIOS on my Thinkpad X230.
After sorting out a little problem with suspend/resume, I am quite happy
with it.
Now I would like to add a bootsplash image, but SeaBIOS seems unable to
find any vesa modes.
However, HDT (http://www.hdt-project.org) shows several modes, including
the native display resolution (1366x768x32) and the resolution of my
bootsplash.bmp (1024x768x32).
I am using the proprietary vesa bios blob extracted from the original
X230 …
[View More]BIOS and it seems to work fine, except for the bootsplash.
Thanks for any help,
Gert
[View Less]
I am working on an issue with SeaBIOS running in Bochs emulator. I found
I need to revert SeaBIOS patch d449a11, otherwise Bochs freezes. After
the further investigation, I narrowed down the problem to those lines:
File: src/fw/shadow.c
Function: __make_bios_writable_intel
48 // Write PAM settings back to pci config space
49 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]);
50 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]);
File: src/fw/shadow.c
…
[View More]Function: make_bios_readonly_intel
109 // Write PAM settings back to pci config space
110 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]);
111 pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]);
What has changed, comparing to the code before patch d449a11 is the
order of writes to PAM registers.
Before d449a11 the order was: 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f 0x59
After d449a11 the order is : 0x59 0x5a 0x5b 0x5c 0x5d 0x5e 0x5f
I believe also the 0x58 (DRAMT?) register is written after the patch
d449a11 and was not before.
I checked, and the registers values after write are exactly the same
in both cases (before/after patch). This lead me to think the order
of writes matters.
So I prepared the patch that restores the old order. I works well and
fixes the issue with Bochs. But there is still one think I cannot
explain and I hope I can find some help here. If you look on the patch
below, you will see I had to use different pci write functions in
__make_bios_writable_intel and make_bios_readonly_intel. The only
difference in those functions (I think) is the size of data that
is written at one call. Still It does not work for me when written
some other way. Again, I would appreciate if someone could explain
it to me or point me some documentation.
Just to summarize, I have two questions:
1. Why the order of pci writes makes a difference here?
2. Why the size of pci writes matters?
>From 953c133a6ade49e9148a0734ffefc0fb27c116fb Mon Sep 17 00:00:00 2001
From: Petr Berky <petr.berky(a)email.cz>
Date: Sun, 19 Mar 2017 10:14:49 +0100
Subject: [PATCH RFC] shadow: Change order of PCI writes
This change solves the problem with Bochs freeze
---
src/fw/shadow.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/src/fw/shadow.c b/src/fw/shadow.c
index c80b266..508af20 100644
--- a/src/fw/shadow.c
+++ b/src/fw/shadow.c
@@ -23,6 +23,7 @@
union pamdata_u {
u8 data8[8];
+ u16 data16[4];
u32 data32[2];
};
@@ -46,8 +47,9 @@ __make_bios_writable_intel(u16 bdf, u32 pam0)
pam[0] = 0x30;
// Write PAM settings back to pci config space
- pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]);
+ pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 2, pamdata.data16[1]);
pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]);
+ pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 1, pamdata.data8[1]);
if (!ram_present)
// Copy bios.
@@ -107,8 +109,11 @@ make_bios_readonly_intel(u16 bdf, u32 pam0)
pam[0] = 0x10;
// Write PAM settings back to pci config space
- pci_config_writel(bdf, ALIGN_DOWN(pam0, 4), pamdata.data32[0]);
- pci_config_writel(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data32[1]);
+ pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 2, pamdata.data16[1]);
+ pci_config_writew(bdf, ALIGN_DOWN(pam0, 4) + 4, pamdata.data16[2]);
+ pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 6, pamdata.data8[6]);
+ pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 7, pamdata.data8[7]);
+ pci_config_writeb(bdf, ALIGN_DOWN(pam0, 4) + 1, pamdata.data8[1]);
}
static int ShadowBDF = -1;
--
2.11.0
[View Less]
On Fri, 24 Mar 2017 20:51:56 -0400
Kevin O'Connor <kevin(a)koconnor.net> wrote:
> On Fri, Mar 24, 2017 at 05:27:19PM +0100, Patrick Rudolph wrote:
> > This series add several fixes to coreboot's framebuffer
> > implementation and it main purpose is to fix Microsoft's Windows as
> > supported OS.
> >
> > The series fixes the following issues:
> > * Windows shows no image in text-mode
> > * Windows NTLDR/bootmgr shows no image in VESA mode
> …
[View More]> * Windows shows no image in VESA mode
> > * Windows legacy Intel VGA driver requires VBT in VGA option ROM
> > * Clear screen broken due to INT 15h replaced by OS
> >
> > I was able to boot Windows with the following configurations:
> > * using VgaSave driver in text-mode with a
> > fixed display resolution of 640x480 at 4Bpp.
> > * using VgaSave driver in VESA mode and
> > set a display resolution up to 1600x1200 at 24Bpp.
> > * using VgaSave driver in Windows's "Safe Mode" in VESA mode and
> > set a display resolution up to 1600x1200 at 24Bpp.
> > * using the Intel VGA driver with up to the panel native
> > resolution of 1680x1050 at 24Bpp.
> >
> > Most likely other VESA compatible bootloaders and operating systems
> > will be fixed, too.
> >
> > Changes since v1:
>
> Thanks, but I didn't see a response to my comments on patches 1 and 2
> from the last series.
>
Sorry, I'll will fix the issues in patches 1 and 2.
> > * Add crash detection handler for INT 15h modifications.
>
> Can you explain how this works? If int1587 is disabled, why is it a
> priority to not clear the screen?
To prevent a crash on the next mode change. Windows will iterate over
modes and finaly end with mode 12, which isn't a compatible VESA mode.
>
> > * Copy Intel VBT to VGA option ROM if provided by ASLS
>
> As a high level comment, I think it would be great to have further
> support for Intel video in SeaVGABIOS, but I wonder if extending cbvga
> is the right approach. Seems like we could make an intel-seavgabios
> and it would be a better platfrom for future intel specific features
> (like auto-detecting the framebuffer and maybe even switching modes).
>
Having a seperate vga option rom would require additional
configuration overhead in coreboot. As for now autodetecting the
card at runtime seems to be prefereable.
I'm not planing to include any intel specific features.
> Cheers,
> -Kevin
[View Less]
This series add several fixes to coreboot's framebuffer implementation
and it main purpose is to fix Microsoft's Windows as supported OS.
The series fixes the following issues:
* Windows shows no image in text-mode
* Windows NTLDR/bootmgr shows no image in VESA mode
* Windows shows no image in VESA mode
* Windows legacy Intel VGA driver requires VBT in VGA option ROM
* Clear screen broken due to INT 15h replaced by OS
I was able to boot Windows with the following configurations:
* using …
[View More]VgaSave driver in text-mode with a
fixed display resolution of 640x480 at 4Bpp.
* using VgaSave driver in VESA mode and
set a display resolution up to 1600x1200 at 24Bpp.
* using VgaSave driver in Windows's "Safe Mode" in VESA mode and
set a display resolution up to 1600x1200 at 24Bpp.
* using the Intel VGA driver with up to the panel native
resolution of 1680x1050 at 24Bpp.
Most likely other VESA compatible bootloaders and operating systems
will be fixed, too.
Changes since v1:
* Add crash detection handler for INT 15h modifications.
* Disable VESA modes in cbvga_init
* Make memcpy_high method public
* Copy Intel VBT to VGA option ROM if provided by ASLS
Patrick Rudolph (8):
SeaVGABios/cbvga: Advertise correct pixel format
SeaVGABios/cbvga: Assume VGA compatible GPU in text-mode
SeaVGABIOS/vbe: Query driver for scanline pitch
SeaVGABios/cbvga: Use active mode to clear screen
SeaVGABios/cbvga: Advertise compatible VESA modes
SeaVGABios/vgafb: Make memcpy_high public
SeaVGABios/cbvga:: Add Intel VBT support
SeaVGABios/cbvga: Add crash detection handler
vgasrc/bochsvga.c | 5 +
vgasrc/bochsvga.h | 1 +
vgasrc/cbvga.c | 274 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
vgasrc/clext.c | 5 +
vgasrc/stdvga.c | 5 +
vgasrc/vbe.c | 2 +-
vgasrc/vgaentry.S | 2 +-
vgasrc/vgafb.c | 2 +-
vgasrc/vgafb.h | 2 +-
vgasrc/vgahw.h | 10 ++
vgasrc/vgautil.h | 3 +
11 files changed, 301 insertions(+), 10 deletions(-)
--
2.9.3
[View Less]