[U-Boot] [PATCH 1/5] x86: qemu: Change default vesa mode to 1024x768x32
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
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
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
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!
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);
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; +}
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
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
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
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!
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"
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
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!
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
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!
participants (2)
-
Bin Meng -
Simon Glass