[U-Boot] [PATCH 1/5] x86: qemu: Change default vesa mode to 1024x768x32

[U-Boot] [PATCH 1/5] x86: qemu: Change default vesa mode to 1024x768x32

[Bin Meng]

The default vesa mode was changed since commit 55b4e1b7d999
("x86: Change default FRAMEBUFFER_VESA_MODE of some boards") for
better VxWorks compatibility but with the changes QEMU video console
no longer works. This is because QEMU's vgabios implements the VESA
mode 8:8:8 as 24bpp without an alpha channel, which U-Boot's video
console driver currently does not support yet.

We need change to real 32bpp in order to make it work again. QEMU
vgabios implements the custom 32bpp VESA mode starting from 0x140
(320x200x32) to 0x147 (1600x1200x32). Set it to 0x144 (1024x768x32).

Fixes: 55b4e1b7d999 ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 configs/qemu-x86_64_defconfig | 3 ++-
 configs/qemu-x86_defconfig    | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig
index d2eb53f..51227f1 100644
--- a/configs/qemu-x86_64_defconfig
+++ b/configs/qemu-x86_64_defconfig
@@ -67,5 +67,6 @@ CONFIG_SPL_TIMER=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_FRAMEBUFFER_VESA_MODE_112=y
+CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
+CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig
index f489d52..7144e9c 100644
--- a/configs/qemu-x86_defconfig
+++ b/configs/qemu-x86_defconfig
@@ -47,5 +47,6 @@ CONFIG_SPI=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_KEYBOARD=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_FRAMEBUFFER_VESA_MODE_112=y
+CONFIG_FRAMEBUFFER_VESA_MODE_USER=y
+CONFIG_FRAMEBUFFER_VESA_MODE=0x144
 CONFIG_CONSOLE_SCROLL_LINES=5
-- 
2.7.4

[U-Boot] [PATCH 2/5] board_r: Do not initialize IDE when DM BLK is on

[Bin Meng]

With driver model philosophy, we should avoid explicitly calling
driver initialization routine during boot. This updates the ram
init sequence table to exclude the IDE initialization for DM BLK.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 common/board_r.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 6b29706..6949d4a 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -596,7 +596,7 @@ static int initr_pcmcia(void)
 }
 #endif
 
-#if defined(CONFIG_IDE)
+#if defined(CONFIG_IDE) && !defined(CONFIG_BLK)
 static int initr_ide(void)
 {
 	puts("IDE:   ");
@@ -826,7 +826,7 @@ static init_fnc_t init_sequence_r[] = {
 #if defined(CONFIG_CMD_PCMCIA) && !defined(CONFIG_IDE)
 	initr_pcmcia,
 #endif
-#if defined(CONFIG_IDE)
+#if defined(CONFIG_IDE) && !defined(CONFIG_BLK)
 	initr_ide,
 #endif
 #ifdef CONFIG_LAST_STAGE_INIT
-- 
2.7.4

[U-Boot] [PATCH 2/5] board_r: Do not initialize IDE when DM BLK is on

[Simon Glass]

On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> With driver model philosophy, we should avoid explicitly calling
> driver initialization routine during boot. This updates the ram
> init sequence table to exclude the IDE initialization for DM BLK.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  common/board_r.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/5] board_r: Do not initialize IDE when DM BLK is on

[Bin Meng]

On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>> With driver model philosophy, we should avoid explicitly calling
>> driver initialization routine during boot. This updates the ram
>> init sequence table to exclude the IDE initialization for DM BLK.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  common/board_r.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 3/5] efi: stub: Move the use_uart assignment immediately after exit_boot_services() call

[Bin Meng]

The use_uart assignment should follow immediately after the call to
exit_boot_services(), in case we want some debug output after that.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 lib/efi/efi_stub.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/efi/efi_stub.c b/lib/efi/efi_stub.c
index 262fc56..1b495ec 100644
--- a/lib/efi/efi_stub.c
+++ b/lib/efi/efi_stub.c
@@ -361,14 +361,14 @@ efi_status_t EFIAPI efi_main(efi_handle_t image,
 		}
 	}
 
+	/* The EFI UART won't work now, switch to a debug one */
+	use_uart = true;
+
 	map.version = version;
 	map.desc_size = desc_size;
 	add_entry_addr(priv, EFIET_MEMORY_MAP, &map, sizeof(map), desc, size);
 	add_entry_addr(priv, EFIET_END, NULL, 0, 0, 0);
 
-	/* The EFI UART won't work now, switch to a debug one */
-	use_uart = true;
-
 	memcpy((void *)CONFIG_SYS_TEXT_BASE, _binary_u_boot_bin_start,
 	       (ulong)_binary_u_boot_bin_end -
 	       (ulong)_binary_u_boot_bin_start);
-- 
2.7.4

[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Bin Meng]

The generic efi payload currently does not enumerate the PCI bus,
which means peripherals on the PCI bus are not discovered by their
drivers. This uses board_early_init_r() to do the PCI enumeration.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 board/efi/efi-x86_payload/Kconfig   |  1 +
 board/efi/efi-x86_payload/Makefile  |  2 +-
 board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++
 3 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 board/efi/efi-x86_payload/payload.c

diff --git a/board/efi/efi-x86_payload/Kconfig b/board/efi/efi-x86_payload/Kconfig
index b6e57b9..08dd0c2 100644
--- a/board/efi/efi-x86_payload/Kconfig
+++ b/board/efi/efi-x86_payload/Kconfig
@@ -17,6 +17,7 @@ config SYS_TEXT_BASE
 
 config BOARD_SPECIFIC_OPTIONS # dummy
 	def_bool y
+	select BOARD_EARLY_INIT_R
 	imply SYS_NS16550
 	imply SCSI
 	imply SCSI_AHCI
diff --git a/board/efi/efi-x86_payload/Makefile b/board/efi/efi-x86_payload/Makefile
index 6982340..00ef695 100644
--- a/board/efi/efi-x86_payload/Makefile
+++ b/board/efi/efi-x86_payload/Makefile
@@ -2,4 +2,4 @@
 #
 # Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
 
-obj-y	+= start.o
+obj-y	+= start.o payload.o
diff --git a/board/efi/efi-x86_payload/payload.c b/board/efi/efi-x86_payload/payload.c
new file mode 100644
index 0000000..4eeb49a
--- /dev/null
+++ b/board/efi/efi-x86_payload/payload.c
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <usb.h>
+
+int board_early_init_r(void)
+{
+	/*
+	 * Make sure PCI bus is enumerated so that peripherals on the PCI bus
+	 * can be discovered by their drivers
+	 */
+	pci_init();
+
+	return 0;
+}
-- 
2.7.4

[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Simon Glass]

Hi Bin,

On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> The generic efi payload currently does not enumerate the PCI bus,
> which means peripherals on the PCI bus are not discovered by their
> drivers. This uses board_early_init_r() to do the PCI enumeration.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  board/efi/efi-x86_payload/Kconfig   |  1 +
>  board/efi/efi-x86_payload/Makefile  |  2 +-
>  board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++
>  3 files changed, 20 insertions(+), 1 deletion(-)
>  create mode 100644 board/efi/efi-x86_payload/payload.c

I would like to consider adding a mechanism to indicate that a uclass
should be inited (and its devices probed) on startup. This would be
used for things which provide essential peripherals, which otherwise
would not be visible in the initial driver-model bind process.

I am not sure whether this should be:

- a flag in the uclass
- a flag in the BOARD driver (assuming we have a BOARD uclass soon)
- a function call into DM
- something else

But I think it is justified in the case of PCI, since some systems
cannot find all their devices without scanning it.

What do you think?

Regards,
Simon

[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Bin Meng]

Hi Simon,

On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>> The generic efi payload currently does not enumerate the PCI bus,
>> which means peripherals on the PCI bus are not discovered by their
>> drivers. This uses board_early_init_r() to do the PCI enumeration.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  board/efi/efi-x86_payload/Kconfig   |  1 +
>>  board/efi/efi-x86_payload/Makefile  |  2 +-
>>  board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++
>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>  create mode 100644 board/efi/efi-x86_payload/payload.c
>
> I would like to consider adding a mechanism to indicate that a uclass
> should be inited (and its devices probed) on startup. This would be
> used for things which provide essential peripherals, which otherwise
> would not be visible in the initial driver-model bind process.
>

Good to know!

> I am not sure whether this should be:
>
> - a flag in the uclass

Only adding a flag to the uclass driver seems not working. On some
systems like x86 UCLASS_PCI may be init at boot up, but on other
systems this might not be the case. So we need find a place to tell DM
to init the uclass driver if the uclass driver has the flag, but
where?

> - a flag in the BOARD driver (assuming we have a BOARD uclass soon)

The concept of BOARD driver sounds interesting. So does the BOARD
uclass driver intend to replace various config options like
CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R,
CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the
init order with other components in board_f.c and board_r.c?

> - a function call into DM

Like uclass_first_device()?

> - something else
>
> But I think it is justified in the case of PCI, since some systems
> cannot find all their devices without scanning it.
>

Yes, this makes sense for PCI on x86.

> What do you think?
>

Regards,
Bin

[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Simon Glass]

Hi Bin,

On 21 June 2018 at 05:19, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> The generic efi payload currently does not enumerate the PCI bus,
>>> which means peripherals on the PCI bus are not discovered by their
>>> drivers. This uses board_early_init_r() to do the PCI enumeration.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  board/efi/efi-x86_payload/Kconfig   |  1 +
>>>  board/efi/efi-x86_payload/Makefile  |  2 +-
>>>  board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++
>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>  create mode 100644 board/efi/efi-x86_payload/payload.c
>>
>> I would like to consider adding a mechanism to indicate that a uclass
>> should be inited (and its devices probed) on startup. This would be
>> used for things which provide essential peripherals, which otherwise
>> would not be visible in the initial driver-model bind process.
>>
>
> Good to know!
>
>> I am not sure whether this should be:
>>
>> - a flag in the uclass
>
> Only adding a flag to the uclass driver seems not working. On some
> systems like x86 UCLASS_PCI may be init at boot up, but on other
> systems this might not be the case. So we need find a place to tell DM
> to init the uclass driver if the uclass driver has the flag, but
> where?

Yes I figured. Let's drop this idea.

>
>> - a flag in the BOARD driver (assuming we have a BOARD uclass soon)
>
> The concept of BOARD driver sounds interesting. So does the BOARD
> uclass driver intend to replace various config options like
> CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R,
> CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the
> init order with other components in board_f.c and board_r.c?

That's a separate issue, but we could certainly ensure that after all
devices are bound, we probe things like PCI, which would bind its
devices.

>
>> - a function call into DM
>
> Like uclass_first_device()?

That's what we have today. I was more thinking of something that tells
DM (at the start) which uclasses should be probed. E.g.

uclass_set_auto_probe(UCLASS_PCI, true);

>
>> - something else
>>
>> But I think it is justified in the case of PCI, since some systems
>> cannot find all their devices without scanning it.
>>
>
> Yes, this makes sense for PCI on x86.

Anyway the patch is fine, but if you want to try something like the
above, please go ahead.

Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
Simon

[U-Boot] [PATCH 4/5] x86: efi-x86_payload: Enumerate PCI bus during early boot

[Bin Meng]

On Fri, Jun 22, 2018 at 3:45 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 21 June 2018 at 05:19, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> The generic efi payload currently does not enumerate the PCI bus,
>>>> which means peripherals on the PCI bus are not discovered by their
>>>> drivers. This uses board_early_init_r() to do the PCI enumeration.
>>>>
>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>>> ---
>>>>
>>>>  board/efi/efi-x86_payload/Kconfig   |  1 +
>>>>  board/efi/efi-x86_payload/Makefile  |  2 +-
>>>>  board/efi/efi-x86_payload/payload.c | 18 ++++++++++++++++++
>>>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>>>  create mode 100644 board/efi/efi-x86_payload/payload.c
>>>
>>> I would like to consider adding a mechanism to indicate that a uclass
>>> should be inited (and its devices probed) on startup. This would be
>>> used for things which provide essential peripherals, which otherwise
>>> would not be visible in the initial driver-model bind process.
>>>
>>
>> Good to know!
>>
>>> I am not sure whether this should be:
>>>
>>> - a flag in the uclass
>>
>> Only adding a flag to the uclass driver seems not working. On some
>> systems like x86 UCLASS_PCI may be init at boot up, but on other
>> systems this might not be the case. So we need find a place to tell DM
>> to init the uclass driver if the uclass driver has the flag, but
>> where?
>
> Yes I figured. Let's drop this idea.
>
>>
>>> - a flag in the BOARD driver (assuming we have a BOARD uclass soon)
>>
>> The concept of BOARD driver sounds interesting. So does the BOARD
>> uclass driver intend to replace various config options like
>> CONFIG_BOARD_EARLY_INIT_F, CONFIG_BOARD_EARLY_INIT_R,
>> CONFIG_BOARD_LATE_INIT, etc? If we do that, how do we guarantee the
>> init order with other components in board_f.c and board_r.c?
>
> That's a separate issue, but we could certainly ensure that after all
> devices are bound, we probe things like PCI, which would bind its
> devices.
>
>>
>>> - a function call into DM
>>
>> Like uclass_first_device()?
>
> That's what we have today. I was more thinking of something that tells
> DM (at the start) which uclasses should be probed. E.g.
>
> uclass_set_auto_probe(UCLASS_PCI, true);
>
>>
>>> - something else
>>>
>>> But I think it is justified in the case of PCI, since some systems
>>> cannot find all their devices without scanning it.
>>>
>>
>> Yes, this makes sense for PCI on x86.
>
> Anyway the patch is fine, but if you want to try something like the
> above, please go ahead.
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 5/5] x86: efi-x86_payload: Enable usb keyboard during boot

[Bin Meng]

For boards that don't route serial port pins out, it's quite common
to attach a USB keyboard as the input device, along with a monitor.
However USB is not automatically started in the generic efi payload
codes. This uses a payload specific last_stage_init() to start the
USB bus, so that a USB keyboard can be used on the U-Boot shell.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 arch/x86/cpu/cpu.c                | 2 +-
 arch/x86/cpu/efi/payload.c        | 9 +++++++++
 include/configs/efi-x86_payload.h | 2 +-
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index db36553..6aefa12 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -193,7 +193,7 @@ void show_boot_progress(int val)
 	outb(val, POST_PORT);
 }
 
-#ifndef CONFIG_SYS_COREBOOT
+#if !defined(CONFIG_SYS_COREBOOT) && !defined(CONFIG_EFI_STUB)
 /*
  * Implement a weak default function for boards that optionally
  * need to clean up the system before jumping to the kernel.
diff --git a/arch/x86/cpu/efi/payload.c b/arch/x86/cpu/efi/payload.c
index 9fd9f57..e3f0f82 100644
--- a/arch/x86/cpu/efi/payload.c
+++ b/arch/x86/cpu/efi/payload.c
@@ -7,6 +7,7 @@
 #include <common.h>
 #include <efi.h>
 #include <errno.h>
+#include <usb.h>
 #include <asm/post.h>
 
 DECLARE_GLOBAL_DATA_PTR;
@@ -160,3 +161,11 @@ int reserve_arch(void)
 
 	return 0;
 }
+
+int last_stage_init(void)
+{
+	/* start usb so that usb keyboard can be used as input device */
+	usb_init();
+
+	return 0;
+}
diff --git a/include/configs/efi-x86_payload.h b/include/configs/efi-x86_payload.h
index 9c62fd2..1cf5c03 100644
--- a/include/configs/efi-x86_payload.h
+++ b/include/configs/efi-x86_payload.h
@@ -14,7 +14,7 @@
 
 #define CONFIG_SYS_MONITOR_LEN		(1 << 20)
 
-#define CONFIG_STD_DEVICES_SETTINGS	"stdin=serial,i8042-kbd\0" \
+#define CONFIG_STD_DEVICES_SETTINGS	"stdin=serial,i8042-kbd,usbkbd\0" \
 					"stdout=serial,vidconsole\0" \
 					"stderr=serial,vidconsole\0"
 
-- 
2.7.4

[U-Boot] [PATCH 5/5] x86: efi-x86_payload: Enable usb keyboard during boot

[Simon Glass]

On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> For boards that don't route serial port pins out, it's quite common
> to attach a USB keyboard as the input device, along with a monitor.
> However USB is not automatically started in the generic efi payload
> codes. This uses a payload specific last_stage_init() to start the
> USB bus, so that a USB keyboard can be used on the U-Boot shell.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  arch/x86/cpu/cpu.c                | 2 +-
>  arch/x86/cpu/efi/payload.c        | 9 +++++++++
>  include/configs/efi-x86_payload.h | 2 +-
>  3 files changed, 11 insertions(+), 2 deletions(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 5/5] x86: efi-x86_payload: Enable usb keyboard during boot

[Bin Meng]

On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>> For boards that don't route serial port pins out, it's quite common
>> to attach a USB keyboard as the input device, along with a monitor.
>> However USB is not automatically started in the generic efi payload
>> codes. This uses a payload specific last_stage_init() to start the
>> USB bus, so that a USB keyboard can be used on the U-Boot shell.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  arch/x86/cpu/cpu.c                | 2 +-
>>  arch/x86/cpu/efi/payload.c        | 9 +++++++++
>>  include/configs/efi-x86_payload.h | 2 +-
>>  3 files changed, 11 insertions(+), 2 deletions(-)
>>
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!

[U-Boot] [PATCH 1/5] x86: qemu: Change default vesa mode to 1024x768x32

[Simon Glass]

On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
> The default vesa mode was changed since commit 55b4e1b7d999
> ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards") for
> better VxWorks compatibility but with the changes QEMU video console
> no longer works. This is because QEMU's vgabios implements the VESA
> mode 8:8:8 as 24bpp without an alpha channel, which U-Boot's video
> console driver currently does not support yet.
>
> We need change to real 32bpp in order to make it work again. QEMU
> vgabios implements the custom 32bpp VESA mode starting from 0x140
> (320x200x32) to 0x147 (1600x1200x32). Set it to 0x144 (1024x768x32).
>
> Fixes: 55b4e1b7d999 ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards")
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  configs/qemu-x86_64_defconfig | 3 ++-
>  configs/qemu-x86_defconfig    | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 1/5] x86: qemu: Change default vesa mode to 1024x768x32

[Bin Meng]

On Thu, Jun 21, 2018 at 1:51 AM, Simon Glass <sjg@chromium.org> wrote:
> On 17 June 2018 at 06:57, Bin Meng <bmeng.cn@gmail.com> wrote:
>> The default vesa mode was changed since commit 55b4e1b7d999
>> ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards") for
>> better VxWorks compatibility but with the changes QEMU video console
>> no longer works. This is because QEMU's vgabios implements the VESA
>> mode 8:8:8 as 24bpp without an alpha channel, which U-Boot's video
>> console driver currently does not support yet.
>>
>> We need change to real 32bpp in order to make it work again. QEMU
>> vgabios implements the custom 32bpp VESA mode starting from 0x140
>> (320x200x32) to 0x147 (1600x1200x32). Set it to 0x144 (1024x768x32).
>>
>> Fixes: 55b4e1b7d999 ("x86: Change default FRAMEBUFFER_VESA_MODE of some boards")
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  configs/qemu-x86_64_defconfig | 3 ++-
>>  configs/qemu-x86_defconfig    | 3 ++-
>>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

applied to u-boot-x86, thanks!