[U-Boot] [PATCH 00/11] x86: Improve U-Boot as the coreboot payload support

This series adds some improvment to the existing coreboot support, like >=4GiB memory support, correct E820 table report, don't bother configure system tables in Kconfig and support booting Linux kernel with a working graphics console.
Tested on Intel Bayley Bay, U-Boot loaded by coreboot as a payload.
Bin Meng (11): x86: doc: Update coreboot payload entry point address x86: coreboot: Increase memrange entry number to 32 x86: coreboot: Correctly report E820 types x86: Remove calculate_relocation_address() x86: coreboot: Allow >=4GiB memory bank size x86: kconfig: Hide "System tables" for EFI x86: kconfig: Hide "System tables" for coreboot x86: Only include cbfs command for coreboot x86: Enable CONFIG_PCI_CONFIG_HOST_BRIDGE for all boards video: coreboot: Save VESA mode for future use x86: Set up video framebuffer for coreboot before loading kernel
arch/x86/Kconfig | 4 +-- arch/x86/cpu/coreboot/sdram.c | 33 ++++++++++-------- arch/x86/include/asm/arch-coreboot/sysinfo.h | 9 ++--- arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/lib/init_helpers.c | 51 +--------------------------- doc/README.x86 | 6 ++-- drivers/pci/pci_rom.c | 4 +-- drivers/video/coreboot_fb.c | 24 +++++++++++++ include/configs/bayleybay.h | 1 - include/configs/crownbay.h | 1 - include/configs/minnowmax.h | 1 - include/configs/qemu-x86.h | 1 - include/configs/x86-common.h | 3 ++ include/vbe.h | 2 ++ 14 files changed, 56 insertions(+), 86 deletions(-)

With recent EFI support, the entry point address of coreboot payload was changed. Now we update the address to use _x86boot_start, which is the same one for EFI.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
doc/README.x86 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/README.x86 b/doc/README.x86 index af2459c..3f5ed8f 100644 --- a/doc/README.x86 +++ b/doc/README.x86 @@ -235,10 +235,10 @@ this capability yet. The command is as follows:
# in the coreboot root directory $ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \ - -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110015 + -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110000
-Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE and 0x1110015 matches the -symbol address of _start (in arch/x86/cpu/start.S). +Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE, which is the symbol address +of _x86boot_start (in arch/x86/cpu/start.S).
If you want to use ELF as the coreboot payload, change U-Boot configuration to use CONFIG_OF_EMBED instead of CONFIG_OF_SEPARATE.

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
With recent EFI support, the entry point address of coreboot payload was changed. Now we update the address to use _x86boot_start, which is the same one for EFI.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Thanks, I had the same patch locally.
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
With recent EFI support, the entry point address of coreboot payload was changed. Now we update the address to use _x86boot_start, which is the same one for EFI.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
doc/README.x86 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
Thanks, I had the same patch locally.
Acked-by: Simon Glass sjg@chromium.org
I'm applying this for the current release as it is a fix.
Applied to u-boot-x86, thanks!

Increase lib_sysinfo memrange entry number to 32 to sync with coreboot. This allows a complete E820 table to be reported to the kernel, as on some platforms (eg: Bayley Bay) having only 16 entires does not cover all the memory ranges.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/include/asm/arch-coreboot/sysinfo.h | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/x86/include/asm/arch-coreboot/sysinfo.h b/arch/x86/include/asm/arch-coreboot/sysinfo.h index 832c50a..2d57245 100644 --- a/arch/x86/include/asm/arch-coreboot/sysinfo.h +++ b/arch/x86/include/asm/arch-coreboot/sysinfo.h @@ -9,15 +9,12 @@ #ifndef _COREBOOT_SYSINFO_H #define _COREBOOT_SYSINFO_H
-#include <common.h> -#include <linux/compiler.h> -#include <libfdt.h> #include <asm/arch/tables.h>
-/* Allow a maximum of 16 memory range definitions. */ -#define SYSINFO_MAX_MEM_RANGES 16 +/* Maximum number of memory range definitions */ +#define SYSINFO_MAX_MEM_RANGES 32 /* Allow a maximum of 8 GPIOs */ -#define SYSINFO_MAX_GPIOS 8 +#define SYSINFO_MAX_GPIOS 8
struct sysinfo_t { int n_memranges;

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Increase lib_sysinfo memrange entry number to 32 to sync with coreboot. This allows a complete E820 table to be reported to the kernel, as on some platforms (eg: Bayley Bay) having only 16 entires does not cover all the memory ranges.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/arch-coreboot/sysinfo.h | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Increase lib_sysinfo memrange entry number to 32 to sync with coreboot. This allows a complete E820 table to be reported to the kernel, as on some platforms (eg: Bayley Bay) having only 16 entires does not cover all the memory ranges.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/include/asm/arch-coreboot/sysinfo.h | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

coreboot has some extensions (type 6 & 16) to the E820 types. When we detect this, mark it as E820_RESERVED.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/coreboot/sdram.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c index 9c3ab81..2722886 100644 --- a/arch/x86/cpu/coreboot/sdram.c +++ b/arch/x86/cpu/coreboot/sdram.c @@ -22,9 +22,10 @@ DECLARE_GLOBAL_DATA_PTR;
unsigned install_e820_map(unsigned max_entries, struct e820entry *entries) { + unsigned num_entries; int i;
- unsigned num_entries = min((unsigned)lib_sysinfo.n_memranges, max_entries); + num_entries = min((unsigned)lib_sysinfo.n_memranges, max_entries); if (num_entries < lib_sysinfo.n_memranges) { printf("Warning: Limiting e820 map to %d entries.\n", num_entries); @@ -34,8 +35,18 @@ unsigned install_e820_map(unsigned max_entries, struct e820entry *entries)
entries[i].addr = memrange->base; entries[i].size = memrange->size; - entries[i].type = memrange->type; + + /* + * coreboot has some extensions (type 6 & 16) to the E820 types. + * When we detect this, mark it as E820_RESERVED. + */ + if (memrange->type == CB_MEM_VENDOR_RSVD || + memrange->type == CB_MEM_TABLE) + entries[i].type = E820_RESERVED; + else + entries[i].type = memrange->type; } + return num_entries; }

Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
coreboot has some extensions (type 6 & 16) to the E820 types. When we detect this, mark it as E820_RESERVED.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
I wonder what the kernel does when it sees the coreboot values?
Regards, Simon

Hi Simon,
On Mon, Aug 17, 2015 at 5:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
coreboot has some extensions (type 6 & 16) to the E820 types. When we detect this, mark it as E820_RESERVED.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
I wonder what the kernel does when it sees the coreboot values?
I noticed this by checking kernel dmesg, where the log prints the E820 ranges as well as types. For type 6 & 16, kernel does not understand that and it just prints the typer number. I believe kernel will ignore these.
Regards, Bin

On 16 August 2015 at 19:22, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Aug 17, 2015 at 5:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
coreboot has some extensions (type 6 & 16) to the E820 types. When we detect this, mark it as E820_RESERVED.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
I wonder what the kernel does when it sees the coreboot values?
I noticed this by checking kernel dmesg, where the log prints the E820 ranges as well as types. For type 6 & 16, kernel does not understand that and it just prints the typer number. I believe kernel will ignore these.
Regards, Bin
Applied to u-boot-x86, thanks!

Now that we have generic routine to calculate relocation address, remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/coreboot/sdram.c | 9 +------ arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/lib/init_helpers.c | 51 +------------------------------------ 3 files changed, 2 insertions(+), 60 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c index 2722886..ae5c893 100644 --- a/arch/x86/cpu/coreboot/sdram.c +++ b/arch/x86/cpu/coreboot/sdram.c @@ -7,14 +7,7 @@ */
#include <common.h> -#include <malloc.h> #include <asm/e820.h> -#include <asm/u-boot-x86.h> -#include <asm/global_data.h> -#include <asm/init_helpers.h> -#include <asm/processor.h> -#include <asm/sections.h> -#include <asm/zimage.h> #include <asm/arch/sysinfo.h> #include <asm/arch/tables.h>
@@ -109,7 +102,7 @@ int dram_init(void) if (ram_size == 0) return -1;
- return calculate_relocation_address(); + return 0; }
void dram_init_banksize(void) diff --git a/arch/x86/include/asm/init_helpers.h b/arch/x86/include/asm/init_helpers.h index 8cbe08e..c689a63 100644 --- a/arch/x86/include/asm/init_helpers.h +++ b/arch/x86/include/asm/init_helpers.h @@ -8,8 +8,6 @@ #ifndef _INIT_HELPERS_H_ #define _INIT_HELPERS_H_
-int calculate_relocation_address(void); - int init_cache_f_r(void); int init_bd_struct_r(void); int init_func_spi(void); diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c index 4fd47fc..82fd5c3 100644 --- a/arch/x86/lib/init_helpers.c +++ b/arch/x86/lib/init_helpers.c @@ -4,12 +4,10 @@ * * SPDX-License-Identifier: GPL-2.0+ */ + #include <common.h> -#include <fdtdec.h> -#include <spi.h> #include <asm/errno.h> #include <asm/mtrr.h> -#include <asm/sections.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -19,53 +17,6 @@ __weak ulong board_get_usable_ram_top(ulong total_size) return gd->ram_size; }
-int calculate_relocation_address(void) -{ - const ulong uboot_size = (uintptr_t)&__bss_end - - (uintptr_t)&__text_start; - ulong total_size; - ulong dest_addr; - ulong fdt_size = 0; - -#if defined(CONFIG_OF_SEPARATE) && defined(CONFIG_OF_CONTROL) - if (gd->fdt_blob) - fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32); -#endif - total_size = ALIGN(uboot_size, 1 << 12) + CONFIG_SYS_MALLOC_LEN + - CONFIG_SYS_STACK_SIZE + fdt_size; - - dest_addr = board_get_usable_ram_top(total_size); - /* - * NOTE: All destination address are rounded down to 16-byte - * boundary to satisfy various worst-case alignment - * requirements - */ - dest_addr &= ~15; - -#if defined(CONFIG_OF_SEPARATE) && defined(CONFIG_OF_CONTROL) - /* - * If the device tree is sitting immediate above our image then we - * must relocate it. If it is embedded in the data section, then it - * will be relocated with other data. - */ - if (gd->fdt_blob) { - dest_addr -= fdt_size; - gd->new_fdt = (void *)dest_addr; - dest_addr &= ~15; - } -#endif - /* U-Boot is below the FDT */ - dest_addr -= uboot_size; - dest_addr &= ~((1 << 12) - 1); - gd->relocaddr = dest_addr; - gd->reloc_off = dest_addr - (uintptr_t)&__text_start; - - /* Stack is at the bottom, so it can grow down */ - gd->start_addr_sp = dest_addr - CONFIG_SYS_MALLOC_LEN; - - return 0; -} - int init_cache_f_r(void) { #if defined(CONFIG_X86_RESET_VECTOR) & !defined(CONFIG_HAVE_FSP)

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have generic routine to calculate relocation address, remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 9 +------ arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/lib/init_helpers.c | 51 +------------------------------------ 3 files changed, 2 insertions(+), 60 deletions(-)
Great!
Acked-by: Simon Glass sjg@chromium.org]

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Now that we have generic routine to calculate relocation address, remove the x86 specific one which is now only used by coreboot.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 9 +------ arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/lib/init_helpers.c | 51 +------------------------------------ 3 files changed, 2 insertions(+), 60 deletions(-)
Great!
Acked-by: Simon Glass sjg@chromium.org]
Applied to u-boot-x86, thanks!

Some platforms may have >=4GiB memory, so we need make U-Boot report such configuration correctly when booting as the coreboot payload.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/cpu/coreboot/sdram.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/coreboot/sdram.c b/arch/x86/cpu/coreboot/sdram.c index ae5c893..32f595d 100644 --- a/arch/x86/cpu/coreboot/sdram.c +++ b/arch/x86/cpu/coreboot/sdram.c @@ -94,10 +94,10 @@ int dram_init(void) struct memrange *memrange = &lib_sysinfo.memrange[i]; unsigned long long end = memrange->base + memrange->size;
- if (memrange->type == CB_MEM_RAM && end > ram_size && - memrange->base < (1ULL << 32)) - ram_size = end; + if (memrange->type == CB_MEM_RAM && end > ram_size) + ram_size += memrange->size; } + gd->ram_size = ram_size; if (ram_size == 0) return -1; @@ -113,8 +113,7 @@ void dram_init_banksize(void) for (i = 0, j = 0; i < lib_sysinfo.n_memranges; i++) { struct memrange *memrange = &lib_sysinfo.memrange[i];
- if (memrange->type == CB_MEM_RAM && - memrange->base < (1ULL << 32)) { + if (memrange->type == CB_MEM_RAM) { gd->bd->bi_dram[j].start = memrange->base; gd->bd->bi_dram[j].size = memrange->size; j++;

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Some platforms may have >=4GiB memory, so we need make U-Boot report such configuration correctly when booting as the coreboot payload.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
This looks safe to me.
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Some platforms may have >=4GiB memory, so we need make U-Boot report such configuration correctly when booting as the coreboot payload.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/cpu/coreboot/sdram.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
This looks safe to me.
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

Instead of hiding each menu entries under "System tables" for EFI, hide the main menu completely.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 01ed760..b600beb 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -307,10 +307,10 @@ config VGA_BIOS_ADDR 0x90000 from the beginning of a 1MB flash device.
menu "System tables" + depends on !EFI
config GENERATE_PIRQ_TABLE bool "Generate a PIRQ table" - depends on !EFI default n help Generate a PIRQ routing table for this board. The PIRQ routing table @@ -321,7 +321,6 @@ config GENERATE_PIRQ_TABLE
config GENERATE_SFI_TABLE bool "Generate a SFI (Simple Firmware Interface) table" - depends on !EFI help The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system @@ -336,7 +335,6 @@ config GENERATE_SFI_TABLE
config GENERATE_MP_TABLE bool "Generate an MP (Multi-Processor) table" - depends on !EFI default n help Generate an MP (Multi-Processor) table for this board. The MP table

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Instead of hiding each menu entries under "System tables" for EFI, hide the main menu completely.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Instead of hiding each menu entries under "System tables" for EFI, hide the main menu completely.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

When booting as a coreboot payload, we don't need write any configuration tables as coreboot does that for us.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index b600beb..065bbe4 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -307,7 +307,7 @@ config VGA_BIOS_ADDR 0x90000 from the beginning of a 1MB flash device.
menu "System tables" - depends on !EFI + depends on !EFI && !SYS_COREBOOT
config GENERATE_PIRQ_TABLE bool "Generate a PIRQ table"

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When booting as a coreboot payload, we don't need write any configuration tables as coreboot does that for us.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When booting as a coreboot payload, we don't need write any configuration tables as coreboot does that for us.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
arch/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

When running U-Boot bare-metal, the cbfs command is useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/configs/x86-common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 349b06c..3d07cc0 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -87,7 +87,9 @@ #define CONFIG_ISO_PARTITION /* Experimental */
#define CONFIG_CMD_PART +#ifdef CONFIG_SYS_COREBOOT #define CONFIG_CMD_CBFS +#endif #define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE #define CONFIG_PARTITION_UUIDS

Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When running U-Boot bare-metal, the cbfs command is useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/configs/x86-common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 349b06c..3d07cc0 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -87,7 +87,9 @@ #define CONFIG_ISO_PARTITION /* Experimental */
#define CONFIG_CMD_PART +#ifdef CONFIG_SYS_COREBOOT #define CONFIG_CMD_CBFS +#endif #define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE
#define CONFIG_PARTITION_UUIDS
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
We should move that to Kconfig. Have you tried Masahiro's moveconfig script?
Regards, Simon

Hi Simon,
On Mon, Aug 17, 2015 at 5:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When running U-Boot bare-metal, the cbfs command is useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/configs/x86-common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 349b06c..3d07cc0 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -87,7 +87,9 @@ #define CONFIG_ISO_PARTITION /* Experimental */
#define CONFIG_CMD_PART +#ifdef CONFIG_SYS_COREBOOT #define CONFIG_CMD_CBFS +#endif #define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE
#define CONFIG_PARTITION_UUIDS
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
We should move that to Kconfig. Have you tried Masahiro's moveconfig script?
I haven't got a chance to try moveconfig scripts, but I will try some time. I believe there are lots of work to get all config.h defines converted to Kconfig options first, and some day we will achieve this :)
Regards, Bin

On 16 August 2015 at 19:25, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Mon, Aug 17, 2015 at 5:27 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When running U-Boot bare-metal, the cbfs command is useless.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/configs/x86-common.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 349b06c..3d07cc0 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -87,7 +87,9 @@ #define CONFIG_ISO_PARTITION /* Experimental */
#define CONFIG_CMD_PART +#ifdef CONFIG_SYS_COREBOOT #define CONFIG_CMD_CBFS +#endif #define CONFIG_CMD_EXT4 #define CONFIG_CMD_EXT4_WRITE
#define CONFIG_PARTITION_UUIDS
1.8.2.1
Acked-by: Simon Glass sjg@chromium.org
We should move that to Kconfig. Have you tried Masahiro's moveconfig script?
I haven't got a chance to try moveconfig scripts, but I will try some time. I believe there are lots of work to get all config.h defines converted to Kconfig options first, and some day we will achieve this :)
Regards, Bin
Applied to u-boot-x86, thanks!

It looks that x86 chipset always contains a host bridge at pci b.d.f 0.0.0, so enable this for all boards.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
include/configs/bayleybay.h | 1 - include/configs/crownbay.h | 1 - include/configs/minnowmax.h | 1 - include/configs/qemu-x86.h | 1 - include/configs/x86-common.h | 1 + 5 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/include/configs/bayleybay.h b/include/configs/bayleybay.h index c590f56..eae94df 100644 --- a/include/configs/bayleybay.h +++ b/include/configs/bayleybay.h @@ -16,7 +16,6 @@ #define CONFIG_SYS_MONITOR_LEN (1 << 20) #define CONFIG_ARCH_MISC_INIT
-#define CONFIG_PCI_CONFIG_HOST_BRIDGE #define CONFIG_SYS_EARLY_PCI_INIT #define CONFIG_PCI_PNP #define CONFIG_E1000 diff --git a/include/configs/crownbay.h b/include/configs/crownbay.h index 1ea320b..e87bd54 100644 --- a/include/configs/crownbay.h +++ b/include/configs/crownbay.h @@ -31,7 +31,6 @@ #define CONFIG_PCI_IO_PHYS CONFIG_PCI_IO_BUS #define CONFIG_PCI_IO_SIZE 0xe000
-#define CONFIG_PCI_CONFIG_HOST_BRIDGE #define CONFIG_SYS_EARLY_PCI_INIT #define CONFIG_PCI_PNP #define CONFIG_E1000 diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h index 64fa676..38879da 100644 --- a/include/configs/minnowmax.h +++ b/include/configs/minnowmax.h @@ -18,7 +18,6 @@
#define CONFIG_SMSC_LPC47M
-#define CONFIG_PCI_CONFIG_HOST_BRIDGE #define CONFIG_SYS_EARLY_PCI_INIT #define CONFIG_PCI_PNP #define CONFIG_RTL8169 diff --git a/include/configs/qemu-x86.h b/include/configs/qemu-x86.h index c25e331..e589425 100644 --- a/include/configs/qemu-x86.h +++ b/include/configs/qemu-x86.h @@ -28,7 +28,6 @@ #define CONFIG_PCI_IO_PHYS CONFIG_PCI_IO_BUS #define CONFIG_PCI_IO_SIZE 0xe000
-#define CONFIG_PCI_CONFIG_HOST_BRIDGE #define CONFIG_PCI_PNP #define CONFIG_E1000
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h index 3d07cc0..217312e 100644 --- a/include/configs/x86-common.h +++ b/include/configs/x86-common.h @@ -192,6 +192,7 @@ * PCI configuration */ #define CONFIG_PCI +#define CONFIG_PCI_CONFIG_HOST_BRIDGE
/*----------------------------------------------------------------------- * USB configuration

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
It looks that x86 chipset always contains a host bridge at pci b.d.f 0.0.0, so enable this for all boards.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/configs/bayleybay.h | 1 - include/configs/crownbay.h | 1 - include/configs/minnowmax.h | 1 - include/configs/qemu-x86.h | 1 - include/configs/x86-common.h | 1 + 5 files changed, 1 insertion(+), 4 deletions(-)
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
It looks that x86 chipset always contains a host bridge at pci b.d.f 0.0.0, so enable this for all boards.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
include/configs/bayleybay.h | 1 - include/configs/crownbay.h | 1 - include/configs/minnowmax.h | 1 - include/configs/qemu-x86.h | 1 - include/configs/x86-common.h | 1 + 5 files changed, 1 insertion(+), 4 deletions(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

When booting as a coreboot payload, the framebuffer details are passed from coreboot via configuration tables. We save these information into vesa_mode_info structure for future use.
Signed-off-by: Bin Meng bmeng.cn@gmail.com ---
drivers/pci/pci_rom.c | 2 +- drivers/video/coreboot_fb.c | 24 ++++++++++++++++++++++++ include/vbe.h | 2 ++ 3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c index 26db3ca..b9a3990 100644 --- a/drivers/pci/pci_rom.c +++ b/drivers/pci/pci_rom.c @@ -187,7 +187,7 @@ int pci_rom_load(struct pci_rom_header *rom_header, return 0; }
-static struct vbe_mode_info mode_info; +struct vbe_mode_info mode_info;
int vbe_get_video_info(struct graphic_device *gdev) { diff --git a/drivers/video/coreboot_fb.c b/drivers/video/coreboot_fb.c index 56c35c1..4790ef1 100644 --- a/drivers/video/coreboot_fb.c +++ b/drivers/video/coreboot_fb.c @@ -9,6 +9,7 @@ #include <common.h> #include <asm/arch/tables.h> #include <asm/arch/sysinfo.h> +#include <vbe.h> #include <video_fb.h> #include "videomodes.h"
@@ -17,6 +18,26 @@ */ GraphicDevice ctfb;
+static void save_vesa_mode(void) +{ + struct vesa_mode_info *vesa = &mode_info.vesa; + struct cb_framebuffer *fb = lib_sysinfo.framebuffer; + + vesa->x_resolution = fb->x_resolution; + vesa->y_resolution = fb->y_resolution; + vesa->bits_per_pixel = fb->bits_per_pixel; + vesa->bytes_per_scanline = fb->bytes_per_line; + vesa->phys_base_ptr = fb->physical_address; + vesa->red_mask_size = fb->red_mask_size; + vesa->red_mask_pos = fb->red_mask_pos; + vesa->green_mask_size = fb->green_mask_size; + vesa->green_mask_pos = fb->green_mask_pos; + vesa->blue_mask_size = fb->blue_mask_size; + vesa->blue_mask_pos = fb->blue_mask_pos; + vesa->reserved_mask_size = fb->reserved_mask_size; + vesa->reserved_mask_pos = fb->reserved_mask_pos; +} + static int parse_coreboot_table_fb(GraphicDevice *gdev) { struct cb_framebuffer *fb = lib_sysinfo.framebuffer; @@ -81,5 +102,8 @@ void *video_hw_init(void) memset((void *)gdev->pciBase, 0, gdev->winSizeX * gdev->winSizeY * gdev->gdfBytesPP);
+ /* Initialize vesa_mode_info structure */ + save_vesa_mode(); + return (void *)gdev; } diff --git a/include/vbe.h b/include/vbe.h index 1a86db8..164ccae 100644 --- a/include/vbe.h +++ b/include/vbe.h @@ -102,6 +102,8 @@ struct vbe_ddc_info { #define VESA_SET_MODE 0x4f02 #define VESA_GET_CUR_MODE 0x4f03
+extern struct vbe_mode_info mode_info; + struct graphic_device; int vbe_get_video_info(struct graphic_device *gdev);

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When booting as a coreboot payload, the framebuffer details are passed from coreboot via configuration tables. We save these information into vesa_mode_info structure for future use.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci_rom.c | 2 +- drivers/video/coreboot_fb.c | 24 ++++++++++++++++++++++++ include/vbe.h | 2 ++ 3 files changed, 27 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
When booting as a coreboot payload, the framebuffer details are passed from coreboot via configuration tables. We save these information into vesa_mode_info structure for future use.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci_rom.c | 2 +- drivers/video/coreboot_fb.c | 24 ++++++++++++++++++++++++ include/vbe.h | 2 ++ 3 files changed, 27 insertions(+), 1 deletion(-)
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

Currenlty we only set up video framebuffer when VIDEO_VESA driver is used. With coreboot, VIDEO_COREBOOT driver is used instead. Since we already saved VESA mode in the VIDEO_COREBOOT driver, now we can also set up video framebuffer for coreboot before loading Linux kernel.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
---
drivers/pci/pci_rom.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c index b9a3990..d244543 100644 --- a/drivers/pci/pci_rom.c +++ b/drivers/pci/pci_rom.c @@ -232,7 +232,6 @@ int vbe_get_video_info(struct graphic_device *gdev)
void setup_video(struct screen_info *screen_info) { -#ifdef CONFIG_FRAMEBUFFER_SET_VESA_MODE struct vesa_mode_info *vesa = &mode_info.vesa;
/* Sanity test on VESA parameters */ @@ -258,7 +257,6 @@ void setup_video(struct screen_info *screen_info) screen_info->blue_pos = vesa->blue_mask_pos; screen_info->rsvd_size = vesa->reserved_mask_size; screen_info->rsvd_pos = vesa->reserved_mask_pos; -#endif }
int pci_run_vga_bios(pci_dev_t dev, int (*int15_handler)(void), int exec_method)

On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Currenlty we only set up video framebuffer when VIDEO_VESA driver is used. With coreboot, VIDEO_COREBOOT driver is used instead. Since we already saved VESA mode in the VIDEO_COREBOOT driver, now we can also set up video framebuffer for coreboot before loading Linux kernel.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci_rom.c | 2 -- 1 file changed, 2 deletions(-)
Nice.
Acked-by: Simon Glass sjg@chromium.org

On 16 August 2015 at 15:27, Simon Glass sjg@chromium.org wrote:
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
Currenlty we only set up video framebuffer when VIDEO_VESA driver is used. With coreboot, VIDEO_COREBOOT driver is used instead. Since we already saved VESA mode in the VIDEO_COREBOOT driver, now we can also set up video framebuffer for coreboot before loading Linux kernel.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
drivers/pci/pci_rom.c | 2 -- 1 file changed, 2 deletions(-)
Nice.
Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot-x86, thanks!

Hi,
On 13 August 2015 at 01:29, Bin Meng bmeng.cn@gmail.com wrote:
This series adds some improvment to the existing coreboot support, like >=4GiB memory support, correct E820 table report, don't bother configure system tables in Kconfig and support booting Linux kernel with a working graphics console.
Tested on Intel Bayley Bay, U-Boot loaded by coreboot as a payload.
Bin Meng (11): x86: doc: Update coreboot payload entry point address x86: coreboot: Increase memrange entry number to 32 x86: coreboot: Correctly report E820 types x86: Remove calculate_relocation_address() x86: coreboot: Allow >=4GiB memory bank size x86: kconfig: Hide "System tables" for EFI x86: kconfig: Hide "System tables" for coreboot x86: Only include cbfs command for coreboot x86: Enable CONFIG_PCI_CONFIG_HOST_BRIDGE for all boards video: coreboot: Save VESA mode for future use x86: Set up video framebuffer for coreboot before loading kernel
arch/x86/Kconfig | 4 +-- arch/x86/cpu/coreboot/sdram.c | 33 ++++++++++-------- arch/x86/include/asm/arch-coreboot/sysinfo.h | 9 ++--- arch/x86/include/asm/init_helpers.h | 2 -- arch/x86/lib/init_helpers.c | 51 +--------------------------- doc/README.x86 | 6 ++-- drivers/pci/pci_rom.c | 4 +-- drivers/video/coreboot_fb.c | 24 +++++++++++++ include/configs/bayleybay.h | 1 - include/configs/crownbay.h | 1 - include/configs/minnowmax.h | 1 - include/configs/qemu-x86.h | 1 - include/configs/x86-common.h | 3 ++ include/vbe.h | 2 ++ 14 files changed, 56 insertions(+), 86 deletions(-)
I'm going to pick this for this release as it adds fixes for booting as a coreboot payload.
Regards, Simon
participants (2)
-
Bin Meng
-
Simon Glass