Re: [SeaBIOS] [PATCH 3/3] ahci: alloc structs in high memory, simplify realloc
Hi, > Ideally, one wouldn't allocate in "high" ram and then go on to free > it. (Memory fragmentation due to malloc/free could chew up some guest > ram.) So, I'm not sure this is an improvement. So, we can keep the realloc but move tmp -> high instead of tmp -> low. cheers, Gerd >From c1519be64be516b6605ed5790ff193c034ff8c1d Mon Sep 17 00:00:00 2001 From: Gerd Hoffmann Date: Tue, 26 Nov 2013 14:10:25 +0100 Subject: [PATCH] ahci: alloc structs in high memory With ahci running in 32bit mode we can also allocate the (ahci private) data structures in high memory. This reduces the real mode memory footprint as we only need to move struct ahci_port_s (which contains struct drive_s) to fseg in case the port probe was successful. Signed-off-by: Gerd Hoffmann --- src/hw/ahci.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/hw/ahci.c b/src/hw/ahci.c index 5984c1c..687cc7d 100644 --- a/src/hw/ahci.c +++ b/src/hw/ahci.c @@ -403,9 +403,9 @@ static struct ahci_port_s* ahci_port_realloc(struct ahci_port_s *port) free(port->list); free(port->fis); free(port->cmd); -port->list = memalign_low(1024, 1024); -port->fis = memalign_low(256, 256); -port->cmd = memalign_low(256, 256); +port->list = memalign_high(1024, 1024); +port->fis = memalign_high(256, 256); +port->cmd = memalign_high(256, 256); ahci_port_writel(port->ctrl, port->pnr, PORT_LST_ADDR, (u32)port->list); ahci_port_writel(port->ctrl, port->pnr, PORT_FIS_ADDR, (u32)port->fis); -- 1.8.3.1 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH 1/6] pci: don't reorder entries when moving to 64bit list
On Di, 2013-11-26 at 22:03 -0500, Kevin O'Connor wrote:
> On Tue, Nov 26, 2013 at 01:24:09PM +0100, Gerd Hoffmann wrote:
> > Otherwise the 64bit bars are not mapped in largest
> > first order, thereby messing up the alignment.
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > src/fw/pciinit.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/fw/pciinit.c b/src/fw/pciinit.c
> > index 34279a4..84bb65b 100644
> > --- a/src/fw/pciinit.c
> > +++ b/src/fw/pciinit.c
> > @@ -574,14 +574,19 @@ static u64 pci_region_sum(struct pci_region *r)
> > static void pci_region_migrate_64bit_entries(struct pci_region *from,
> > struct pci_region *to)
> > {
> > -struct hlist_node *n, **last = &to->list.first;
> > +struct hlist_node *n, *last = NULL;
> > struct pci_region_entry *entry;
> > hlist_for_each_entry_safe(entry, n, &from->list, node) {
> > if (!entry->is64)
> > continue;
> > // Move from source list to destination list.
> > hlist_del(&entry->node);
> > -hlist_add(&entry->node, last);
> > +if (hlist_empty(&to->list)) {
> > +hlist_add_head(&entry->node, &to->list);
> > +} else {
> > +hlist_add_after(&entry->node, last);
> > +}
> > +last = &entry->node;
>
> This could be done by just adding: last = &entry->node.next;
Ok, I'll do it this way.
cheers,
Gerd
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.
This provides basic debug output on the Quark system, assuming that
*something* (i.e. coreboot or UEFI) has set it up in advance for us.
Signed-off-by: David Woodhouse
---
I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code,
and making that generic enough to handle I/O access *or* MMIO access
depending on what's present... but in fact that's probably overkill.
This isn't really limited to Quark; it would work with any 16550 device
wired up as MMIO32. But we can expand it as required, I think. No point
in starting off with the same functionality as the 5000-odd lines of the
Linux kernel's 8250_pci.c.
What do I need to do if called in 32-bit segmented mode? I'm guessing
that's not going to work right now...
src/Kconfig | 5 +
src/fw/csm.c | 2 ++
src/output.c | 64
3 files changed, 71 insertions(+)
diff --git a/src/Kconfig b/src/Kconfig
index a42ab2d..bdc2602 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -472,6 +472,11 @@ menu "Debugging"
Set to zero to disable debugging.
+config DEBUG_QUARK_UART
+depends on DEBUG_LEVEL != 0
+bool "Debug to Quark UART #1"
+default n
+
config DEBUG_SERIAL
depends on DEBUG_LEVEL != 0
bool "Serial port debugging"
diff --git a/src/fw/csm.c b/src/fw/csm.c
index dfb0d12..afd7ffe 100644
--- a/src/fw/csm.c
+++ b/src/fw/csm.c
@@ -280,6 +280,8 @@ handle_csm(struct bregs *regs)
if (!CONFIG_CSM)
return;
+debug_serial_preinit();
+
dprintf(3, "handle_csm regs %p AX=%04x\n", regs, regs->ax);
pic_irqmask_write(PICMask);
diff --git a/src/output.c b/src/output.c
index b47625f..a90d350 100644
--- a/src/output.c
+++ b/src/output.c
@@ -17,6 +17,8 @@
#include "stacks.h" // call16_int
#include "string.h" // memset
#include "util.h" // ScreenAndDebug
+#include "hw/pci_regs.h" // PCI_VENDOR_ID, PCI_BASE_ADDRESS_0
+#include "hw/pci.h" // pci_config_readl
struct putcinfo {
void (*func)(struct putcinfo *info, char c);
@@ -31,9 +33,59 @@ struct putcinfo {
u16 DebugOutputPort VARFSEG = 0x402;
+static volatile u32 *quark_uart_addr = 0;
+
+extern void _cfunc32flat_quark_uart_preinit(void);
+extern void _cfunc32flat_quark_uart_putc(void);
+extern void _cfunc32flat_quark_uart_flush(void);
+
+void quark_uart_preinit(void)
+{
+// debug port is bus 0, device 0x14, function 5.
+u16 uart_bdf = pci_to_bdf(0, 0x14, 5);
+
+// If it isn't a Quark UART...
+if (pci_config_readl(uart_bdf, PCI_VENDOR_ID) != 0x09368086)
+return;
+
+u32 bar0 = pci_config_readl(uart_bdf, PCI_BASE_ADDRESS_0);
+if (!(bar0 & 0xf))
+quark_uart_addr = (void *)bar0;
+}
+
+void quark_uart_putc(char c)
+{
+if (!quark_uart_addr)
+return;
+
+int timeout = DEBUG_TIMEOUT;
+while ((quark_uart_addr[SEROFF_LSR] & 0x20) != 0x20)
+if (!timeout--)
+// Ran out of time.
+return;
+quark_uart_addr[SEROFF_DATA] = c;
+}
+
+void quark_uart_flush(void)
+{
+if (!quark_uart_addr)
+return;
+int timeout = DEBUG_TIMEOUT;
+while ((quark_uart_addr[SEROFF_LSR] & 0x60) != 0x60)
+if (!timeout--)
+// Ran out of time.
+return;
+}
+
void
debug_serial_preinit(void)
{
+if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_preinit, 0, 0);
+ else
+ quark_uart_preinit();
+}
if (!CONFIG_DEBUG_SERIAL)
return;
// setup for serial logging: 8N1
@@ -54,6 +106,12 @@ debug_serial_preinit(void)
static void
debug_serial(char c)
{
+if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_putc, c, 0);
+ else
+ quark_uart_putc(c);
+}
if (!CONFIG_DEBUG_SERIAL)
return;
int timeout = DEBUG_TIMEOUT;
@@ -68,6 +126,12 @@ debug_serial(char c)
static void
debug_serial_flush(void)
{
+if (CONFIG_DEBUG_QUARK_UART) {
+ if (MODE16)
+ call32(_cfunc32flat_quark_uart_flush, 0, 0);
+ else
+ quark_uart_flush();
+}
if (!CONFIG_DEBUG_SERIAL)
return;
int timeout = DEBUG_TIMEOUT;
--
1.8.3.1
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH v2] i386: Add _PXM ACPI method to CPU objects
On Wed, Nov 27, 2013 at 04:58:51PM +0100, Paolo Bonzini wrote: > Il 27/11/2013 16:53, Igor Mammedov ha scritto: > > Patch looks good, > > Please add patch to update hw/i386/ssdt-proc.hex.generated for hosts > > without iasl > > for completness > > Also please rename PXM to CPXM or CPPX for consistency. I posted an updated version of the patch on the list, also here: http://patchwork.ozlabs.org/patch/294636/ thanks, - Vasilis ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] i386: Add _PXM ACPI method to CPU objects
On Wed, 27 Nov 2013 19:38:44 +0100
Vasilis Liaskovitis wrote:
> This patch adds a _PXM method to ACPI CPU objects for the pc machine. The _PXM
> value is derived from the passed in guest info, same way as CPU SRAT entries.
>
> Currently, CPU SRAT entries are only enabled for cpus that are already present
> in the system. The SRAT entries for hotpluggable processors are disabled
> (flags
> bit 0 set to 0 in hw/i385/acpi-build.c:build_srat). Section 5.2.16.1 of ACPI
> spec mentions "If the Local APIC ID of a dynamically added processor is not
> present in the SRAT, a _PXM object must exist for the processor’s device or
> one
> of its ancestors in the ACPI Namespace." Since SRAT entries are not available
> for the hot-pluggable processors, a _PXM method must exist for them.
> Otherwise,
> the CPU is hot-added in the wrong NUMA node (default node 0).
>
> Even if CPU SRAT entries are enabled, _PXM method is what the linux kernel
> consults on hot-add time. Section 17.2.1 of ACPI spec mentions " OSPM will
> consume the SRAT only at boot time. OSPM should use _PXM for any devices that
> are hot-added into the system after boot up." To be more precise if SRAT
> information is available to the guest kernel, it is used. However, parsed
> SRAT
> info is reset and lost after hot-remove operations, see kernel commit
> c4c60524.
> This means that on a hot-unplug / hot-replug scenario, and without a _PXM
> method, the kernel may put a CPU on different nodes because SRAT info has been
> reset by a previous hot-remove operation.
>
> The above hot-remove/hot-add scenario has been tested on master, plus cpu-del
> patches from:
> https://lists.gnu.org/archive/html/qemu-devel/2013-10/msg01085.html
> With the curret _PXM patch, hot-added CPUs are always placed into the correct
> NUMA node, regardless of kernel behaviour.
>
> v1->v2:
>Make method return a DWORD integer
>Tested on qemu master + cpu-del patches
> v2->v3:
>Add changed hw/i386/sdt-proc.hex.generated file
>Change PXM constant name to CPXM
>
> Signed-off-by: Vasilis Liaskovitis
> Reviewed-by: Thilo Fromm
>
> ---
> hw/i386/acpi-build.c|5
> hw/i386/ssdt-proc.dsl |5
> hw/i386/ssdt-proc.hex.generated | 57
> ---
> 3 files changed, 51 insertions(+), 16 deletions(-)
>
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index b48c930..387a869 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -605,6 +605,7 @@ static inline char acpi_get_hex(uint32_t val)
> #define ACPI_PROC_OFFSET_CPUHEX (*ssdt_proc_name - *ssdt_proc_start + 2)
> #define ACPI_PROC_OFFSET_CPUID1 (*ssdt_proc_name - *ssdt_proc_start + 4)
> #define ACPI_PROC_OFFSET_CPUID2 (*ssdt_proc_id - *ssdt_proc_start)
> +#define ACPI_PROC_OFFSET_CPUPXM (*ssdt_proc_pxm - *ssdt_proc_start)
> #define ACPI_PROC_SIZEOF (*ssdt_proc_end - *ssdt_proc_start)
> #define ACPI_PROC_AML (ssdp_proc_aml + *ssdt_proc_start)
>
> @@ -726,6 +727,10 @@ build_ssdt(GArray *table_data, GArray *linker,
> proc[ACPI_PROC_OFFSET_CPUHEX+1] = acpi_get_hex(i);
> proc[ACPI_PROC_OFFSET_CPUID1] = i;
> proc[ACPI_PROC_OFFSET_CPUID2] = i;
> +proc[ACPI_PROC_OFFSET_CPUPXM] = guest_info->node_cpu[i];
> +proc[ACPI_PROC_OFFSET_CPUPXM + 1] = 0;
> +proc[ACPI_PROC_OFFSET_CPUPXM + 2] = 0;
> +proc[ACPI_PROC_OFFSET_CPUPXM + 3] = 0;
> }
>
> /* build this code:
> diff --git a/hw/i386/ssdt-proc.dsl b/hw/i386/ssdt-proc.dsl
> index 8229bfd..52b44e3 100644
> --- a/hw/i386/ssdt-proc.dsl
> +++ b/hw/i386/ssdt-proc.dsl
> @@ -47,6 +47,8 @@ DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC",
> "BXSSDT", 0x1)
> * also updating the C code.
> */
> Name(_HID, "ACPI0007")
> +ACPI_EXTRACT_NAME_DWORD_CONST ssdt_proc_pxm
> +Name(CPXM, 0x)
> External(CPMA, MethodObj)
> External(CPST, MethodObj)
> External(CPEJ, MethodObj)
> @@ -59,5 +61,8 @@ DefinitionBlock ("ssdt-proc.aml", "SSDT", 0x01, "BXPC",
> "BXSSDT", 0x1)
> Method(_EJ0, 1, NotSerialized) {
> CPEJ(ID, Arg0)
> }
> +Method(_PXM, 0) {
> +Return (CPXM)
> +}
> }
> }
> diff --git a/hw/i386/ssdt-proc.hex.generated b/hw/i386/ssdt-proc.hex.generated
> index bb9920d..8497866 100644
> --- a/hw/i386/ssdt-proc.hex.generated
> +++ b/hw/i386/ssdt-proc.hex.generated
> @@ -1,17 +1,26 @@
> +static unsigned char ssdt_proc_end[] = {
> +0x8e
> +};
> static unsigned char ssdt_proc_name[] = {
> 0x28
> };
> +static unsigned char ssdt_proc_pxm[] = {
> +0x4e
> +};
> +static unsigned char ssdt_proc_id[] = {
> +0x38
> +};
> static unsigned char ssdp_proc_aml[] = {
> 0x53,
> 0x53,
> 0x44,
> 0x54,
> -0x78,
> +0x8e,
> 0x0,
> 0x0,
> 0x0,
> 0x1,
> -0xb8,
> +0x19,
> 0x42,
> 0x58,
> 0x50,
> @@ -34,21 +43,21 @@ static unsigned char ssdp_proc_aml[] = {
> 0x4e,
> 0x54,
>
[SeaBIOS] seabios release planning
Hi, qemu 1.7 is almost out of the door. I want update seabios early in the 1.8 devel cycle. Time to do resume the release planning since we've scratched the idea to do a last-minute bios update for 1.7. I'd like to see a seabios release from the master branch in december. Ideally we'll put a prerelease into qemu before the final release so we get some testing. We could either explicitly tag a release candidate or just grab a snapshot for that. Commit pending patches, enter seabios freeze, prepare seabios update for qemu can be done next week I think. Then have 2-3 weeks freeze period, tag final release before xmas. In case something doesn't go as planned early january. Pending patches: * my ahci and pci patches sent this week. * anything else? How we wanna call the baby? 1.7.4? 1.8.0? cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] seavgabios resolutions, win8
I tried switching from plex/bochs vgabios to seavgabios,
and made this switch for qemu-1.7 package in debian, at
least to see how it goes.
And almost immediately got a complain that with new qemu
(which uses seavgabios not vgabios), windows VMs don't
support 1920x1080 resolutions anymore.
Almost immediately we cooked a patch which restored the
mode(s) in question, here it is:
--- a/vgasrc/bochsvga.c
+++ b/vgasrc/bochsvga.c
@@ -89,6 +89,9 @@
{ 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
{ 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
+{ 0x18d, { MM_DIRECT, 1920, 1080, 16, 8, 16, SEG_GRAPH } },
+{ 0x18e, { MM_DIRECT, 1920, 1080, 24, 8, 16, SEG_GRAPH } },
+{ 0x18f, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
};
static int is_bochsvga_mode(struct vgamode_s *vmode_g)
Should something like this be applied?
Of the same theme, there's a wishlist bugreport against vgabios in
Debian, to add a few more resolutions, http://bugs.debian.org/669114 --
it adds 2048x1536 resolution, which is also missing in seavgabios.
Also, vgabios 0.7 provided a few more resolutions, like 1280x768 and
1280x720.
I'm not sure I understand how list of modes is maintained/used in
seavgabios. The above patch at least allows one of the very common
modes to be selected in windows clients.
And while at it, there's another bugreport against vgabios package in
Debian, see http://bugs.debian.org/685097 . It looks like windows8
isn't happy with vgabios-provided modes and does not let to change
resolution at all, sticking at 1024x768. That bugreport points to
a patchset, http://lists.xen.org/archives/html/xen-devel/2012-05/msg00260.html
(this is just one patch from it), which has been applied to xen copy
of vgabios to solve exactly this issue with win8, and reportedly it
works there. It looks like something similar should be done in
seavgabios too, since with it, win8 guest is also stuck at the same
resolution.
Thanks,
/mjt
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] seavgabios resolutions, win8
Hi,
> +{ 0x18d, { MM_DIRECT, 1920, 1080, 16, 8, 16, SEG_GRAPH } },
> +{ 0x18e, { MM_DIRECT, 1920, 1080, 24, 8, 16, SEG_GRAPH } },
> +{ 0x18f, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> I'm not sure I understand how list of modes is maintained/used in
> seavgabios. The above patch at least allows one of the very common
> modes to be selected in windows clients.
Just get-send-email a proper patch to the seabios list.
> And while at it, there's another bugreport against vgabios package in
> Debian, see http://bugs.debian.org/685097 . It looks like windows8
> isn't happy with vgabios-provided modes and does not let to change
> resolution at all, sticking at 1024x768. That bugreport points to
> a patchset, http://lists.xen.org/archives/html/xen-devel/2012-05/msg00260.html
> (this is just one patch from it), which has been applied to xen copy
> of vgabios to solve exactly this issue with win8, and reportedly it
> works there. It looks like something similar should be done in
> seavgabios too, since with it, win8 guest is also stuck at the same
> resolution.
Hmm, last time I tried resolution switching in win8 worked just fine
with seavgabios. Can you double-check?
cheers,
Gerd
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] seavgabios resolutions, win8
29.11.2013 19:23, Gerd Hoffmann wrote:
> Hi,
>
>> +{ 0x18d, { MM_DIRECT, 1920, 1080, 16, 8, 16, SEG_GRAPH } },
>> +{ 0x18e, { MM_DIRECT, 1920, 1080, 24, 8, 16, SEG_GRAPH } },
>> +{ 0x18f, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
>
>> I'm not sure I understand how list of modes is maintained/used in
>> seavgabios. The above patch at least allows one of the very common
>> modes to be selected in windows clients.
>
> Just get-send-email a proper patch to the seabios list.
It isn't about patch submission. It is about _writing_ the patch, --
I mentioned that there are a few other modes which are requested by
users, and also - which I didn't mention - I don't know which mode
identifiers to use, -- does it matter which IDs to use? In the above
example, added modes are 0x18[def], does it matter?
>> And while at it, there's another bugreport against vgabios package in
>> Debian, see http://bugs.debian.org/685097 . It looks like windows8
>> isn't happy with vgabios-provided modes and does not let to change
>> resolution at all, sticking at 1024x768. That bugreport points to
>> a patchset,
>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00260.html
>> (this is just one patch from it), which has been applied to xen copy
>> of vgabios to solve exactly this issue with win8, and reportedly it
>> works there. It looks like something similar should be done in
>> seavgabios too, since with it, win8 guest is also stuck at the same
>> resolution.
>
> Hmm, last time I tried resolution switching in win8 worked just fine
> with seavgabios. Can you double-check?
I just installed a fresh win8 VM, and it is indeed stuck with 1024x768,
with the "screen resolution" combo-box grayed out in the appropriate
control panel screen, -- there's no way to choose any other resolution.
However I'm not sure whenever this is because of some (vga)bios issue
or because of the lack of my windows8 activation (I activated it in
qemu-1.1 and it works fine there, but it immediately becomes "not
activated" with any later version of qemu, despite the usage of
-M pc-1.1) -- reportedly, win8 has some restrictions in display area
when not activated, but I don't know details. I'd expect it to block
the "themes/personalization" part, not screen resolution part...
I'll try to get hold of win8.1, maybe there things are a bit different...
Thanks,
/mjt
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] seavgabios resolutions, win8
29.11.2013 19:59, Michael Tokarev wrote: [] >>> And while at it, there's another bugreport against vgabios package in >>> Debian, see http://bugs.debian.org/685097 . It looks like windows8 >>> isn't happy with vgabios-provided modes and does not let to change >>> resolution at all, sticking at 1024x768. That bugreport points to >>> a patchset, >>> http://lists.xen.org/archives/html/xen-devel/2012-05/msg00260.html >>> (this is just one patch from it), which has been applied to xen copy >>> of vgabios to solve exactly this issue with win8, and reportedly it >>> works there. It looks like something similar should be done in >>> seavgabios too, since with it, win8 guest is also stuck at the same >>> resolution. >> >> Hmm, last time I tried resolution switching in win8 worked just fine >> with seavgabios. Can you double-check? > > I just installed a fresh win8 VM, and it is indeed stuck with 1024x768, > with the "screen resolution" combo-box grayed out in the appropriate > control panel screen, -- there's no way to choose any other resolution. It was a false alarm really. I'm sorry for this. After numerous experiments with different vga bioses, I had a leftover file named vgabios-stdvga.bin in the current directory. It was some version of plex/bochs vgabios. And that one didn't work. When I actually removed it and tried with seavgabios, it worked correctly and it lets me to change resolutions. It doesn't have 1920x1024 resolution still, but it is a significantly better behavour. So the win8 part of my question goes away :) Thanks, /mjt ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.
On Fri, Nov 29, 2013 at 02:02:02PM +, David Woodhouse wrote: > This provides basic debug output on the Quark system, assuming that > *something* (i.e. coreboot or UEFI) has set it up in advance for us. > > Signed-off-by: David Woodhouse > --- > I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code, > and making that generic enough to handle I/O access *or* MMIO access > depending on what's present... but in fact that's probably overkill. > > This isn't really limited to Quark; it would work with any 16550 device > wired up as MMIO32. But we can expand it as required, I think. No point > in starting off with the same functionality as the 5000-odd lines of the > Linux kernel's 8250_pci.c. > > What do I need to do if called in 32-bit segmented mode? I'm guessing > that's not going to work right now... Do you need debug output from 16bit mode or 32bit segmented mode? The post and boot phases are all 32bit code so typical boot time debugging shouldn't be impacted. Gerd's cbmem debugging code uses this approach. Using call32() in 16bit mode is always risky because it trashes the "hidden" segment registers. I think we need to move the low-level serial code out of output.c. I'll put together a patch that does that. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.
On Fri, 2013-11-29 at 11:40 -0500, Kevin O'Connor wrote: > On Fri, Nov 29, 2013 at 02:02:02PM +, David Woodhouse wrote: > > This provides basic debug output on the Quark system, assuming that > > *something* (i.e. coreboot or UEFI) has set it up in advance for us. > > > > Signed-off-by: David Woodhouse > > --- > > I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code, > > and making that generic enough to handle I/O access *or* MMIO access > > depending on what's present... but in fact that's probably overkill. > > > > This isn't really limited to Quark; it would work with any 16550 device > > wired up as MMIO32. But we can expand it as required, I think. No point > > in starting off with the same functionality as the 5000-odd lines of the > > Linux kernel's 8250_pci.c. > > > > What do I need to do if called in 32-bit segmented mode? I'm guessing > > that's not going to work right now... > > Do you need debug output from 16bit mode or 32bit segmented mode? The > post and boot phases are all 32bit code so typical boot time debugging > shouldn't be impacted. Gerd's cbmem debugging code uses this > approach. I can live with that. Perhaps I should make it work in 16-bit mode but *only* if the appropriate BAR has been put in a memory hole below 1MiB. Now I've got the Quark running... has anyone ever looked at sdhci support... ? :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] Move low-level hardware writing from output.c to new file hw/serialio.c.
Avoid hardware specific code in output.c. This will reduce the amount
of change needed to output.c as support for more serial hardware is
added.
This patch also renames some functions to improve the naming scheme.
Signed-off-by: Kevin O'Connor
---
Makefile | 2 +-
src/boot.c| 4 +--
src/fw/coreboot.c | 2 +-
src/fw/xen.c | 1 +
src/hw/serialio.c | 89 +++
src/hw/serialio.h | 8 +
src/optionroms.c | 2 +-
src/output.c | 101 --
src/output.h | 3 +-
src/post.c| 2 +-
src/resume.c | 2 +-
src/util.h| 2 +-
12 files changed, 137 insertions(+), 81 deletions(-)
create mode 100644 src/hw/serialio.c
diff --git a/Makefile b/Makefile
index 855fdf4..3aefbe6 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ IASL:=iasl
SRCBOTH=misc.c stacks.c output.c string.c x86.c block.c cdrom.c mouse.c kbd.c \
serial.c clock.c resume.c pnpbios.c vgahooks.c pcibios.c apm.c \
fw/smp.c \
-hw/pci.c hw/timer.c hw/rtc.c hw/dma.c hw/pic.c hw/ps2port.c \
+hw/pci.c hw/timer.c hw/rtc.c hw/dma.c hw/pic.c hw/ps2port.c hw/serialio.c \
hw/usb.c hw/usb-uhci.c hw/usb-ohci.c hw/usb-ehci.c hw/usb-xhci.c \
hw/usb-hid.c hw/usb-msc.c hw/usb-uas.c \
hw/blockcmd.c hw/floppy.c hw/ata.c hw/ramdisk.c \
diff --git a/src/boot.c b/src/boot.c
index b14ced9..1c74d57 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -743,7 +743,7 @@ int BootSequence VARLOW = -1;
void VISIBLE32FLAT
handle_18(void)
{
-debug_serial_preinit();
+debug_preinit();
debug_enter(NULL, DEBUG_HDL_18);
int seq = BootSequence + 1;
BootSequence = seq;
@@ -754,7 +754,7 @@ handle_18(void)
void VISIBLE32FLAT
handle_19(void)
{
-debug_serial_preinit();
+debug_preinit();
debug_enter(NULL, DEBUG_HDL_19);
BootSequence = 0;
do_boot(0);
diff --git a/src/fw/coreboot.c b/src/fw/coreboot.c
index 70a99a0..5b7e77a 100644
--- a/src/fw/coreboot.c
+++ b/src/fw/coreboot.c
@@ -202,7 +202,7 @@ fail:
return;
}
-void debug_cbmem(char c)
+void coreboot_debug_putc(char c)
{
if (!CONFIG_DEBUG_COREBOOT)
return;
diff --git a/src/fw/xen.c b/src/fw/xen.c
index 9b00030..d5f5ed3 100644
--- a/src/fw/xen.c
+++ b/src/fw/xen.c
@@ -5,6 +5,7 @@
// This file may be distributed under the terms of the GNU LGPLv3 license.
#include "config.h"
+#include "hw/serialio.h" // DebugOutputPort
#include "malloc.h" // memalign_high
#include "memmap.h" // add_e820
#include "output.h" // dprintf
diff --git a/src/hw/serialio.c b/src/hw/serialio.c
new file mode 100644
index 000..6486fc0
--- /dev/null
+++ b/src/hw/serialio.c
@@ -0,0 +1,89 @@
+// Low-level serial (and serial-like) device access.
+//
+// Copyright (C) 2008-1013 Kevin O'Connor
+//
+// This file may be distributed under the terms of the GNU LGPLv3 license.
+
+#include "config.h" // CONFIG_DEBUG_SERIAL
+#include "fw/paravirt.h" // RunningOnQEMU
+#include "output.h" // dprintf
+#include "serialio.h" // serial_debug_preinit
+#include "x86.h" // outb
+
+
+/
+ * Serial port debug output
+ /
+
+#define DEBUG_TIMEOUT 10
+
+// Setup the debug serial port for output.
+void
+serial_debug_preinit(void)
+{
+if (!CONFIG_DEBUG_SERIAL)
+return;
+// setup for serial logging: 8N1
+u8 oldparam, newparam = 0x03;
+oldparam = inb(CONFIG_DEBUG_SERIAL_PORT+SEROFF_LCR);
+outb(newparam, CONFIG_DEBUG_SERIAL_PORT+SEROFF_LCR);
+// Disable irqs
+u8 oldier, newier = 0;
+oldier = inb(CONFIG_DEBUG_SERIAL_PORT+SEROFF_IER);
+outb(newier, CONFIG_DEBUG_SERIAL_PORT+SEROFF_IER);
+
+if (oldparam != newparam || oldier != newier)
+dprintf(1, "Changing serial settings was %x/%x now %x/%x\n"
+, oldparam, oldier, newparam, newier);
+}
+
+// Write a character to the serial port.
+static void
+serial_debug(char c)
+{
+if (!CONFIG_DEBUG_SERIAL)
+return;
+int timeout = DEBUG_TIMEOUT;
+while ((inb(CONFIG_DEBUG_SERIAL_PORT+SEROFF_LSR) & 0x20) != 0x20)
+if (!timeout--)
+// Ran out of time.
+return;
+outb(c, CONFIG_DEBUG_SERIAL_PORT+SEROFF_DATA);
+}
+
+void
+serial_debug_putc(char c)
+{
+if (c == '\n')
+serial_debug('\r');
+serial_debug(c);
+}
+
+// Make sure all serial port writes have been completely sent.
+void
+serial_debug_flush(void)
+{
+if (!CONFIG_DEBUG_SERIAL)
+return;
+int timeout = DEBUG_TIMEOUT;
+while ((inb(CONFIG_DEBUG_SERIAL_PORT+SEROFF_LSR) & 0x60) != 0x60)
+if (!timeout--)
+// Ran out of time.
+return;
+}
+
+
+/
+ * QEMU debug port
+ /
+
+u16 DebugOutputPort VARFSEG = 0x402;
+
Re: [SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.
On Fri, Nov 29, 2013 at 04:59:32PM +, David Woodhouse wrote: > On Fri, 2013-11-29 at 11:40 -0500, Kevin O'Connor wrote: > > On Fri, Nov 29, 2013 at 02:02:02PM +, David Woodhouse wrote: > > > This provides basic debug output on the Quark system, assuming that > > > *something* (i.e. coreboot or UEFI) has set it up in advance for us. > > > > > > Signed-off-by: David Woodhouse > > > --- > > > I looked briefly at making this part of the CONFIG_DEBUG_SERIAL code, > > > and making that generic enough to handle I/O access *or* MMIO access > > > depending on what's present... but in fact that's probably overkill. > > > > > > This isn't really limited to Quark; it would work with any 16550 device > > > wired up as MMIO32. But we can expand it as required, I think. No point > > > in starting off with the same functionality as the 5000-odd lines of the > > > Linux kernel's 8250_pci.c. > > > > > > What do I need to do if called in 32-bit segmented mode? I'm guessing > > > that's not going to work right now... > > > > Do you need debug output from 16bit mode or 32bit segmented mode? The > > post and boot phases are all 32bit code so typical boot time debugging > > shouldn't be impacted. Gerd's cbmem debugging code uses this > > approach. > > I can live with that. Perhaps I should make it work in 16-bit mode but > *only* if the appropriate BAR has been put in a memory hole below 1MiB. That should be okay, but would it ever actually be mapped below 1Meg? Where would it be mapped to: 0xa-0xc? BTW, how does this "Quark" support compare with the PCI Oxford serial code that Google has been maintaining? http://git.chromium.org/gitweb/?p=chromiumos/third_party/seabios.git;a=commit;h=9b39499125f22627aaeddabfde787c50d51c -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [RFC PATCH] Add support for Intel Quark UART.
On Fri, 2013-11-29 at 12:44 -0500, Kevin O'Connor wrote: > > That should be okay, but would it ever actually be mapped below 1Meg? > Where would it be mapped to: 0xa-0xc? Somewhere down there. Or 0xc even. There's no video here. > BTW, how does this "Quark" support compare with the PCI Oxford serial > code that Google has been maintaining? > http://git.chromium.org/gitweb/?p=chromiumos/third_party/seabios.git;a=commit;h=9b39499125f22627aaeddabfde787c50d51c Hm, close. Mine is mmio32 not mmio8. So IER is at 0x4 in the BAR, IIR at 0x8 etc. And I need to specify the PCI B/D/F because I really need to use the one at :14:5 not the other port at :14.1. But those are easy enough to solve. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] seabios release planning
On Fri, Nov 29, 2013 at 04:13:35PM +0100, Gerd Hoffmann wrote: > Hi, > > qemu 1.7 is almost out of the door. I want update seabios early in the > 1.8 devel cycle. Time to do resume the release planning since we've > scratched the idea to do a last-minute bios update for 1.7. > > I'd like to see a seabios release from the master branch in december. > Ideally we'll put a prerelease into qemu before the final release so we > get some testing. We could either explicitly tag a release candidate or > just grab a snapshot for that. > > Commit pending patches, enter seabios freeze, prepare seabios update for > qemu can be done next week I think. Then have 2-3 weeks freeze period, > tag final release before xmas. In case something doesn't go as planned > early january. So that would look like a SeaBIOS feature freeze on Dec 6th and target release date of Dec 20th. Works for me. > Pending patches: > * my ahci and pci patches sent this week. > * anything else? > > How we wanna call the baby? 1.7.4? 1.8.0? I'd say v1.7.4. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] seavgabios resolutions, win8
On Fri, Nov 29, 2013 at 07:59:25PM +0400, Michael Tokarev wrote:
> 29.11.2013 19:23, Gerd Hoffmann wrote:
> > Hi,
> >
> >> +{ 0x18d, { MM_DIRECT, 1920, 1080, 16, 8, 16, SEG_GRAPH } },
> >> +{ 0x18e, { MM_DIRECT, 1920, 1080, 24, 8, 16, SEG_GRAPH } },
> >> +{ 0x18f, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> >
> >> I'm not sure I understand how list of modes is maintained/used in
> >> seavgabios. The above patch at least allows one of the very common
> >> modes to be selected in windows clients.
> >
> > Just get-send-email a proper patch to the seabios list.
>
> It isn't about patch submission. It is about _writing_ the patch, --
> I mentioned that there are a few other modes which are requested by
> users, and also - which I didn't mention - I don't know which mode
> identifiers to use, -- does it matter which IDs to use? In the above
> example, added modes are 0x18[def], does it matter?
SeaVGABIOS started as a port of the "lgpl vgabios" code from
assembler/bcc to gcc. What likely happened is that patches were made
to the original "lgpl vgabios" code after the port started. So, we
just need to patch SeaVGABIOS with whatever has been recently added to
"lgpl vgabios".
The choice of mode ids, generally speaking, doesn't matter. It's good
form to match the ids chosen in "lgpl vgabios" though.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] seavgabios resolutions, win8
On Fri, Nov 29, 2013 at 06:58:59PM +0400, Michael Tokarev wrote: > I tried switching from plex/bochs vgabios to seavgabios, > and made this switch for qemu-1.7 package in debian, at > least to see how it goes. > > And almost immediately got a complain that with new qemu > (which uses seavgabios not vgabios), windows VMs don't > support 1920x1080 resolutions anymore. Where do you get your "lgpl vgabios" from? The standard QEMU repo ( git://git.qemu.org/vgabios.git ) doesn't have these modes either. > And while at it, there's another bugreport against vgabios package in > Debian, see http://bugs.debian.org/685097 . It looks like windows8 > isn't happy with vgabios-provided modes and does not let to change > resolution at all, sticking at 1024x768. That bugreport points to > a patchset, http://lists.xen.org/archives/html/xen-devel/2012-05/msg00260.html The logic in the patch in the link above is already in SeaVGABIOS. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] seavgabios resolutions, win8
29.11.2013 22:57, Kevin O'Connor wrote: > On Fri, Nov 29, 2013 at 06:58:59PM +0400, Michael Tokarev wrote: >> I tried switching from plex/bochs vgabios to seavgabios, >> and made this switch for qemu-1.7 package in debian, at >> least to see how it goes. >> >> And almost immediately got a complain that with new qemu >> (which uses seavgabios not vgabios), windows VMs don't >> support 1920x1080 resolutions anymore. > > Where do you get your "lgpl vgabios" from? The standard QEMU repo ( > git://git.qemu.org/vgabios.git ) doesn't have these modes either. http://cvs.savannah.gnu.org/viewvc/vgabios/vbetables-gen.c?revision=1.6&root=vgabios&view=markup It is the "upstream" vgabios repository (v. 0.7a). Modes 0x19[012]. qemu version is based on upstream version 0.6c. The original complain comes from one of debian users, and in debian we always used upstream version. The patch which added some of these modes: http://cvs.savannah.gnu.org/viewvc/vgabios/vbetables-gen.c?root=vgabios&r1=1.5&r2=1.6 I'm preparing a patch to add remaining bits from there. Thanks, /mjt ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH] vgasrc: add HDTV resolutions (1280x768, 1280x720, 1920x1080)
The same set were added to vgabios at version 0.7a.
Signed-off-by: Michael Tokarev
---
vgasrc/bochsvga.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/vgasrc/bochsvga.c b/vgasrc/bochsvga.c
index b0ba1ec..3c070c6 100644
--- a/vgasrc/bochsvga.c
+++ b/vgasrc/bochsvga.c
@@ -68,6 +68,9 @@ static struct bochsvga_mode
{ 0x14a, { MM_DIRECT, 1152, 864, 16, 8, 16, SEG_GRAPH } },
{ 0x14b, { MM_DIRECT, 1152, 864, 24, 8, 16, SEG_GRAPH } },
{ 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
+{ 0x175, { MM_DIRECT, 1280, 768, 16, 8, 16, SEG_GRAPH } },
+{ 0x176, { MM_DIRECT, 1280, 768, 24, 8, 16, SEG_GRAPH } },
+{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
{ 0x178, { MM_DIRECT, 1280, 800, 16, 8, 16, SEG_GRAPH } },
{ 0x179, { MM_DIRECT, 1280, 800, 24, 8, 16, SEG_GRAPH } },
{ 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
@@ -89,6 +92,14 @@ static struct bochsvga_mode
{ 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
{ 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
{ 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
+{ 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
+{ 0x18d, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } },
+{ 0x18e, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
+{ 0x18f, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
+{ 0x190, { MM_DIRECT, 1920, 1080, 16 8, 16, SEG_GRAPH } },
+{ 0x191, { MM_DIRECT, 1920, 1080, 24 8, 16, SEG_GRAPH } },
+{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
+
};
static int is_bochsvga_mode(struct vgamode_s *vmode_g)
--
1.7.10.4
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgasrc: add HDTV resolutions (1280x768, 1280x720, 1920x1080)
On Fri, Nov 29, 2013 at 11:12:32PM +0400, Michael Tokarev wrote:
> The same set were added to vgabios at version 0.7a.
Thanks. See below.
> --- a/vgasrc/bochsvga.c
> +++ b/vgasrc/bochsvga.c
> @@ -68,6 +68,9 @@ static struct bochsvga_mode
> { 0x14a, { MM_DIRECT, 1152, 864, 16, 8, 16, SEG_GRAPH } },
> { 0x14b, { MM_DIRECT, 1152, 864, 24, 8, 16, SEG_GRAPH } },
> { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
> +{ 0x175, { MM_DIRECT, 1280, 768, 16, 8, 16, SEG_GRAPH } },
> +{ 0x176, { MM_DIRECT, 1280, 768, 24, 8, 16, SEG_GRAPH } },
> +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
> { 0x178, { MM_DIRECT, 1280, 800, 16, 8, 16, SEG_GRAPH } },
> { 0x179, { MM_DIRECT, 1280, 800, 24, 8, 16, SEG_GRAPH } },
> { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
> @@ -89,6 +92,14 @@ static struct bochsvga_mode
> { 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
> { 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
> { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> +{ 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
> +{ 0x18d, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } },
> +{ 0x18e, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> +{ 0x18f, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
Something's not right here (two 0x18d, 0x18f has 16bit bpp).
> +{ 0x190, { MM_DIRECT, 1920, 1080, 16 8, 16, SEG_GRAPH } },
> +{ 0x191, { MM_DIRECT, 1920, 1080, 24 8, 16, SEG_GRAPH } },
> +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> +
Extra blank line.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] vgasrc: add HDTV resolutions (1280x768, 1280x720, 1920x1080)
1920 × 1200 is a pretty common resolution.
On computers, not on TVs.
Also, now there is UHD TV resolutions. The 4K resolutions.
Like 3840 × 2160 and 4096 × 2160.
On Sat, Nov 30, 2013 at 12:18 AM, Kevin O'Connor wrote:
> On Fri, Nov 29, 2013 at 11:12:32PM +0400, Michael Tokarev wrote:
> > The same set were added to vgabios at version 0.7a.
>
> Thanks. See below.
>
> > --- a/vgasrc/bochsvga.c
> > +++ b/vgasrc/bochsvga.c
> > @@ -68,6 +68,9 @@ static struct bochsvga_mode
> > { 0x14a, { MM_DIRECT, 1152, 864, 16, 8, 16, SEG_GRAPH } },
> > { 0x14b, { MM_DIRECT, 1152, 864, 24, 8, 16, SEG_GRAPH } },
> > { 0x14c, { MM_DIRECT, 1152, 864, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x175, { MM_DIRECT, 1280, 768, 16, 8, 16, SEG_GRAPH } },
> > +{ 0x176, { MM_DIRECT, 1280, 768, 24, 8, 16, SEG_GRAPH } },
> > +{ 0x177, { MM_DIRECT, 1280, 768, 32, 8, 16, SEG_GRAPH } },
> > { 0x178, { MM_DIRECT, 1280, 800, 16, 8, 16, SEG_GRAPH } },
> > { 0x179, { MM_DIRECT, 1280, 800, 24, 8, 16, SEG_GRAPH } },
> > { 0x17a, { MM_DIRECT, 1280, 800, 32, 8, 16, SEG_GRAPH } },
> > @@ -89,6 +92,14 @@ static struct bochsvga_mode
> > { 0x18a, { MM_DIRECT, 2560, 1600, 16, 8, 16, SEG_GRAPH } },
> > { 0x18b, { MM_DIRECT, 2560, 1600, 24, 8, 16, SEG_GRAPH } },
> > { 0x18c, { MM_DIRECT, 2560, 1600, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x18d, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
> > +{ 0x18d, { MM_DIRECT, 1280, 720, 24, 8, 16, SEG_GRAPH } },
> > +{ 0x18e, { MM_DIRECT, 1280, 720, 32, 8, 16, SEG_GRAPH } },
> > +{ 0x18f, { MM_DIRECT, 1280, 720, 16, 8, 16, SEG_GRAPH } },
>
> Something's not right here (two 0x18d, 0x18f has 16bit bpp).
>
> > +{ 0x190, { MM_DIRECT, 1920, 1080, 16 8, 16, SEG_GRAPH } },
> > +{ 0x191, { MM_DIRECT, 1920, 1080, 24 8, 16, SEG_GRAPH } },
> > +{ 0x192, { MM_DIRECT, 1920, 1080, 32, 8, 16, SEG_GRAPH } },
> > +
>
> Extra blank line.
>
> -Kevin
>
> ___
> SeaBIOS mailing list
> SeaBIOS@seabios.org
> http://www.seabios.org/mailman/listinfo/seabios
>
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
