[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver

[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver

[Simon Glass]

This series introduces a generic VESA video driver and adjusts the generic
PCI ROM support to support it. It also fixes up some problems which
prevent this from working on PowerPC at present.

It is now possible to use VESA graphics:
- On PowerPC, using the x86 emulator
- On x86, using either the x86 emulator or native code execution

As it turns out, on the only platform I have tested (link), the x86
emulator is only slightly slower that native code execution (200ms
difference). Still, we may as well leave this feature in there.

VGA ROMs are a very old technology but they are still used by modern
platforms, including at least link and some Atom designs.


Simon Glass (10):
  bios_emulator: Fix an #ifdef typo in the header file
  x86: Correct endianness isues in pci_rom
  x86: Support ROMs on other archs
  bios_emulator: Don't display error when emulator terminates
  bios_emulator: Add some VESA interface debugging
  x86: pci: Don't stop when we get a vendor/device mismatch
  x86: Add a VESA video driver
  x86: Drop the x86_fb driver
  x86: Access the VGA ROM when needed
  RFC: Test code for glacier PCI video support

 arch/x86/include/asm/u-boot-x86.h            |   2 +
 drivers/bios_emulator/atibios.c              | 161 +++++++++++++++++++++++----
 drivers/bios_emulator/include/x86emu/debug.h |   2 +-
 drivers/bios_emulator/x86emu/ops.c           |   2 +-
 drivers/pci/pci_auto.c                       |  28 ++++-
 drivers/pci/pci_rom.c                        |  40 ++++---
 drivers/video/Makefile                       |   2 +-
 drivers/video/vesa_fb.c                      |  64 +++++++++++
 drivers/video/x86_fb.c                       |  38 -------
 include/configs/canyonlands.h                |  31 ++++++
 include/configs/chromebook_link.h            |   2 +-
 include/pci.h                                |   9 ++
 include/pci_rom.h                            |   1 -
 include/vbe.h                                |   9 +-
 14 files changed, 312 insertions(+), 79 deletions(-)
 create mode 100644 drivers/video/vesa_fb.c
 delete mode 100644 drivers/video/x86_fb.c

-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 01/10] bios_emulator: Fix an #ifdef typo in the header file

[Simon Glass]

This stops the debug mode from working properly.

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

 drivers/bios_emulator/include/x86emu/debug.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bios_emulator/include/x86emu/debug.h b/drivers/bios_emulator/include/x86emu/debug.h
index 304b2bf..4962a2a 100644
--- a/drivers/bios_emulator/include/x86emu/debug.h
+++ b/drivers/bios_emulator/include/x86emu/debug.h
@@ -102,7 +102,7 @@
 # define ERR_PRINTF(x)		printf(x)
 # define ERR_PRINTF2(x, y)	printf(x, y)
 
-#ifdef CONFIG_X86EMU_DEBUG103
+#ifdef CONFIG_X86EMU_DEBUG
 
 
 # define DECODE_PRINTF(x)	if (DEBUG_DECODE()) \
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 01/10] bios_emulator: Fix an #ifdef typo in the header file

[Bin Meng]

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> This stops the debug mode from working properly.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/bios_emulator/include/x86emu/debug.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bios_emulator/include/x86emu/debug.h b/drivers/bios_emulator/include/x86emu/debug.h
> index 304b2bf..4962a2a 100644
> --- a/drivers/bios_emulator/include/x86emu/debug.h
> +++ b/drivers/bios_emulator/include/x86emu/debug.h
> @@ -102,7 +102,7 @@
>  # define ERR_PRINTF(x)         printf(x)
>  # define ERR_PRINTF2(x, y)     printf(x, y)
>
> -#ifdef CONFIG_X86EMU_DEBUG103
> +#ifdef CONFIG_X86EMU_DEBUG
>
>
>  # define DECODE_PRINTF(x)      if (DEBUG_DECODE()) \
> --

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

[U-Boot] [PATCH 01/10] bios_emulator: Fix an #ifdef typo in the header file

[Simon Glass]

On 3 January 2015 at 22:10, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> > This stops the debug mode from working properly.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >  drivers/bios_emulator/include/x86emu/debug.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/bios_emulator/include/x86emu/debug.h b/drivers/bios_emulator/include/x86emu/debug.h
> > index 304b2bf..4962a2a 100644
> > --- a/drivers/bios_emulator/include/x86emu/debug.h
> > +++ b/drivers/bios_emulator/include/x86emu/debug.h
> > @@ -102,7 +102,7 @@
> >  # define ERR_PRINTF(x)         printf(x)
> >  # define ERR_PRINTF2(x, y)     printf(x, y)
> >
> > -#ifdef CONFIG_X86EMU_DEBUG103
> > +#ifdef CONFIG_X86EMU_DEBUG
> >
> >
> >  # define DECODE_PRINTF(x)      if (DEBUG_DECODE()) \
> > --
>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>

Applied to u-boot-x86.

[U-Boot] [PATCH 02/10] x86: Correct endianness isues in pci_rom

[Simon Glass]

This code is too x86-dependent at present. Correct it so that it can run on
big-endian machines.

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

 drivers/pci/pci_rom.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 7d25cc9..86f0e95 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -66,6 +66,7 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
 	struct pci_rom_header *rom_header;
 	struct pci_rom_data *rom_data;
 	u16 vendor, device;
+	u16 rom_vendor, rom_device;
 	u32 vendev;
 	u32 mapped_vendev;
 	u32 rom_address;
@@ -95,25 +96,27 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
 	rom_header = (struct pci_rom_header *)rom_address;
 
 	debug("PCI expansion ROM, signature %#04x, INIT size %#04x, data ptr %#04x\n",
-	      le32_to_cpu(rom_header->signature),
-	      rom_header->size * 512, le32_to_cpu(rom_header->data));
+	      le16_to_cpu(rom_header->signature),
+	      rom_header->size * 512, le16_to_cpu(rom_header->data));
 
-	if (le32_to_cpu(rom_header->signature) != PCI_ROM_HDR) {
+	if (le16_to_cpu(rom_header->signature) != PCI_ROM_HDR) {
 		printf("Incorrect expansion ROM header signature %04x\n",
-		       le32_to_cpu(rom_header->signature));
+		       le16_to_cpu(rom_header->signature));
 		return -EINVAL;
 	}
 
-	rom_data = (((void *)rom_header) + le32_to_cpu(rom_header->data));
+	rom_data = (((void *)rom_header) + le16_to_cpu(rom_header->data));
+	rom_vendor = le16_to_cpu(rom_data->vendor);
+	rom_device = le16_to_cpu(rom_data->device);
 
 	debug("PCI ROM image, vendor ID %04x, device ID %04x,\n",
-	      rom_data->vendor, rom_data->device);
+	      rom_vendor, rom_device);
 
 	/* If the device id is mapped, a mismatch is expected */
-	if ((vendor != rom_data->vendor || device != rom_data->device) &&
+	if ((vendor != rom_vendor || device != rom_device) &&
 	    (vendev == mapped_vendev)) {
 		printf("ID mismatch: vendor ID %04x, device ID %04x\n",
-		       rom_data->vendor, rom_data->device);
+		       rom_vendor, rom_device);
 		return -EPERM;
 	}
 
@@ -144,10 +147,10 @@ int pci_rom_load(uint16_t class, struct pci_rom_header *rom_header,
 							    image_size);
 
 		rom_data = (struct pci_rom_data *)((void *)rom_header +
-				le32_to_cpu(rom_header->data));
+				le16_to_cpu(rom_header->data));
 
-		image_size = le32_to_cpu(rom_data->ilen) * 512;
-	} while ((rom_data->type != 0) && (rom_data->indicator != 0));
+		image_size = le16_to_cpu(rom_data->ilen) * 512;
+	} while ((rom_data->type != 0) && (rom_data->indicator == 0));
 
 	if (rom_data->type != 0)
 		return -EACCES;
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 02/10] x86: Correct endianness isues in pci_rom

[Bin Meng]

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> This code is too x86-dependent at present. Correct it so that it can run on
> big-endian machines.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/pci/pci_rom.c | 25 ++++++++++++++-----------
>  1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> index 7d25cc9..86f0e95 100644
> --- a/drivers/pci/pci_rom.c
> +++ b/drivers/pci/pci_rom.c
> @@ -66,6 +66,7 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
>         struct pci_rom_header *rom_header;
>         struct pci_rom_data *rom_data;
>         u16 vendor, device;
> +       u16 rom_vendor, rom_device;
>         u32 vendev;
>         u32 mapped_vendev;
>         u32 rom_address;
> @@ -95,25 +96,27 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
>         rom_header = (struct pci_rom_header *)rom_address;
>
>         debug("PCI expansion ROM, signature %#04x, INIT size %#04x, data ptr %#04x\n",
> -             le32_to_cpu(rom_header->signature),
> -             rom_header->size * 512, le32_to_cpu(rom_header->data));
> +             le16_to_cpu(rom_header->signature),
> +             rom_header->size * 512, le16_to_cpu(rom_header->data));
>
> -       if (le32_to_cpu(rom_header->signature) != PCI_ROM_HDR) {
> +       if (le16_to_cpu(rom_header->signature) != PCI_ROM_HDR) {
>                 printf("Incorrect expansion ROM header signature %04x\n",
> -                      le32_to_cpu(rom_header->signature));
> +                      le16_to_cpu(rom_header->signature));
>                 return -EINVAL;
>         }
>
> -       rom_data = (((void *)rom_header) + le32_to_cpu(rom_header->data));
> +       rom_data = (((void *)rom_header) + le16_to_cpu(rom_header->data));
> +       rom_vendor = le16_to_cpu(rom_data->vendor);
> +       rom_device = le16_to_cpu(rom_data->device);
>
>         debug("PCI ROM image, vendor ID %04x, device ID %04x,\n",
> -             rom_data->vendor, rom_data->device);
> +             rom_vendor, rom_device);
>
>         /* If the device id is mapped, a mismatch is expected */
> -       if ((vendor != rom_data->vendor || device != rom_data->device) &&
> +       if ((vendor != rom_vendor || device != rom_device) &&
>             (vendev == mapped_vendev)) {
>                 printf("ID mismatch: vendor ID %04x, device ID %04x\n",
> -                      rom_data->vendor, rom_data->device);
> +                      rom_vendor, rom_device);
>                 return -EPERM;
>         }
>
> @@ -144,10 +147,10 @@ int pci_rom_load(uint16_t class, struct pci_rom_header *rom_header,
>                                                             image_size);
>
>                 rom_data = (struct pci_rom_data *)((void *)rom_header +
> -                               le32_to_cpu(rom_header->data));
> +                               le16_to_cpu(rom_header->data));
>
> -               image_size = le32_to_cpu(rom_data->ilen) * 512;
> -       } while ((rom_data->type != 0) && (rom_data->indicator != 0));
> +               image_size = le16_to_cpu(rom_data->ilen) * 512;
> +       } while ((rom_data->type != 0) && (rom_data->indicator == 0));
>
>         if (rom_data->type != 0)
>                 return -EACCES;
> --

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

[U-Boot] [PATCH 02/10] x86: Correct endianness isues in pci_rom

[Simon Glass]

On 3 January 2015 at 22:43, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>> This code is too x86-dependent at present. Correct it so that it can run on
>> big-endian machines.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  drivers/pci/pci_rom.c | 25 ++++++++++++++-----------
>>  1 file changed, 14 insertions(+), 11 deletions(-)

Applied to u-boot-x86.

[U-Boot] [PATCH 03/10] x86: Support ROMs on other archs

[Simon Glass]

We shouldn't assume that the VGA ROM can always be loaded at c0000. This
is only true on x86 machines.

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

 arch/x86/include/asm/u-boot-x86.h | 2 ++
 drivers/pci/pci_rom.c             | 6 ++++++
 include/pci_rom.h                 | 1 -
 3 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h
index 36145cb..b98afa8 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -70,4 +70,6 @@ uint64_t timer_get_tsc(void);
 
 void quick_ram_check(void);
 
+#define PCI_VGA_RAM_IMAGE_START		0xc0000
+
 #endif	/* _U_BOOT_I386_H_ */
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 86f0e95..124b730 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -157,7 +157,13 @@ int pci_rom_load(uint16_t class, struct pci_rom_header *rom_header,
 
 	rom_size = rom_header->size * 512;
 
+#ifdef PCI_VGA_RAM_IMAGE_START
 	target = (void *)PCI_VGA_RAM_IMAGE_START;
+#else
+	target = (void *)malloc(rom_size);
+	if (!target)
+		return -ENOMEM;
+#endif
 	if (target != rom_header) {
 		ulong start = get_timer(0);
 
diff --git a/include/pci_rom.h b/include/pci_rom.h
index 8b2674c..4ba36eb 100644
--- a/include/pci_rom.h
+++ b/include/pci_rom.h
@@ -8,7 +8,6 @@
 #define _PCI_ROM_H
 
 #define PCI_ROM_HDR			0xaa55
-#define PCI_VGA_RAM_IMAGE_START		0xc0000
 
 struct pci_rom_header {
 	uint16_t signature;
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 03/10] x86: Support ROMs on other archs

[Bin Meng]

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> We shouldn't assume that the VGA ROM can always be loaded at c0000. This
> is only true on x86 machines.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  arch/x86/include/asm/u-boot-x86.h | 2 ++
>  drivers/pci/pci_rom.c             | 6 ++++++
>  include/pci_rom.h                 | 1 -
>  3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h
> index 36145cb..b98afa8 100644
> --- a/arch/x86/include/asm/u-boot-x86.h
> +++ b/arch/x86/include/asm/u-boot-x86.h
> @@ -70,4 +70,6 @@ uint64_t timer_get_tsc(void);
>
>  void quick_ram_check(void);
>
> +#define PCI_VGA_RAM_IMAGE_START                0xc0000
> +
>  #endif /* _U_BOOT_I386_H_ */
> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> index 86f0e95..124b730 100644
> --- a/drivers/pci/pci_rom.c
> +++ b/drivers/pci/pci_rom.c
> @@ -157,7 +157,13 @@ int pci_rom_load(uint16_t class, struct pci_rom_header *rom_header,
>
>         rom_size = rom_header->size * 512;
>
> +#ifdef PCI_VGA_RAM_IMAGE_START
>         target = (void *)PCI_VGA_RAM_IMAGE_START;
> +#else
> +       target = (void *)malloc(rom_size);
> +       if (!target)
> +               return -ENOMEM;
> +#endif
>         if (target != rom_header) {
>                 ulong start = get_timer(0);
>
> diff --git a/include/pci_rom.h b/include/pci_rom.h
> index 8b2674c..4ba36eb 100644
> --- a/include/pci_rom.h
> +++ b/include/pci_rom.h
> @@ -8,7 +8,6 @@
>  #define _PCI_ROM_H
>
>  #define PCI_ROM_HDR                    0xaa55
> -#define PCI_VGA_RAM_IMAGE_START                0xc0000
>
>  struct pci_rom_header {
>         uint16_t signature;
> --

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

[U-Boot] [PATCH 03/10] x86: Support ROMs on other archs

[Simon Glass]

On 3 January 2015 at 22:43, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>> We shouldn't assume that the VGA ROM can always be loaded at c0000. This
>> is only true on x86 machines.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  arch/x86/include/asm/u-boot-x86.h | 2 ++
>>  drivers/pci/pci_rom.c             | 6 ++++++
>>  include/pci_rom.h                 | 1 -
>>  3 files changed, 8 insertions(+), 1 deletion(-)

Applied to u-boot-x86.

[U-Boot] [PATCH 04/10] bios_emulator: Don't display error when emulator terminates

[Simon Glass]

As it turns out this is a normal condition, so suppress the error.

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

 drivers/bios_emulator/x86emu/ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bios_emulator/x86emu/ops.c b/drivers/bios_emulator/x86emu/ops.c
index 2bb5e2d..5752fee 100644
--- a/drivers/bios_emulator/x86emu/ops.c
+++ b/drivers/bios_emulator/x86emu/ops.c
@@ -179,7 +179,7 @@ void x86emuOp_illegal_op(
 {
     START_OF_INSTR();
     if (M.x86.R_SP != 0) {
-	ERR_PRINTF("ILLEGAL X86 OPCODE\n");
+	DB(printf("ILLEGAL X86 OPCODE\n"));
 	TRACE_REGS();
 	DB( printk("%04x:%04x: %02X ILLEGAL X86 OPCODE!\n",
 	    M.x86.R_CS, M.x86.R_IP-1,op1));
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 04/10] bios_emulator: Don't display error when emulator terminates

[Simon Glass]

On 29 December 2014 at 19:32, Simon Glass <sjg@chromium.org> wrote:
> As it turns out this is a normal condition, so suppress the error.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/bios_emulator/x86emu/ops.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Applied to u-boot-x86.

[U-Boot] [PATCH 05/10] bios_emulator: Add some VESA interface debugging

[Simon Glass]

Allow the supported modes to be listed when in debug mode.

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

 drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++++++++++++++-----
 include/vbe.h                   |   9 ++-
 2 files changed, 148 insertions(+), 22 deletions(-)

diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c
index 93b815c..7ea5fa6 100644
--- a/drivers/bios_emulator/atibios.c
+++ b/drivers/bios_emulator/atibios.c
@@ -62,40 +62,158 @@ static u32 saveBaseAddress14;
 static u32 saveBaseAddress18;
 static u32 saveBaseAddress20;
 
-static void atibios_set_vesa_mode(RMREGS *regs, int vesa_mode,
-				  struct vbe_mode_info *mode_info)
+/* Addres im memory of VBE region */
+const int vbe_offset = 0x2000;
+
+static const void *bios_ptr(const void *buf, BE_VGAInfo *vga_info,
+			    u32 x86_dword_ptr)
+{
+	u32 seg_ofs, flat;
+
+	seg_ofs = le32_to_cpu(x86_dword_ptr);
+	flat = ((seg_ofs & 0xffff0000) >> 12) | (seg_ofs & 0xffff);
+	if (flat >= 0xc0000)
+		return vga_info->BIOSImage + flat - 0xc0000;
+	else
+		return buf + (flat - vbe_offset);
+}
+
+static int atibios_debug_mode(BE_VGAInfo *vga_info, RMREGS *regs,
+			      int vesa_mode, struct vbe_mode_info *mode_info)
+{
+	void *buffer = (void *)(M.mem_base + vbe_offset);
+	u16 buffer_seg = (((unsigned long)vbe_offset) >> 4) & 0xff00;
+	u16 buffer_adr = ((unsigned long)vbe_offset) & 0xffff;
+	struct vesa_mode_info *vm;
+	struct vbe_info *info;
+	const u16 *modes_bios, *ptr;
+	u16 *modes;
+	int size;
+
+	debug("VBE: Getting information\n");
+	regs->e.eax = VESA_GET_INFO;
+	regs->e.esi = buffer_seg;
+	regs->e.edi = buffer_adr;
+	info = buffer;
+	memset(info, '\0', sizeof(*info));
+	strcpy(info->signature, "VBE2");
+	BE_int86(0x10, regs, regs);
+	if (regs->e.eax != 0x4f) {
+		debug("VESA_GET_INFO: error %x\n", regs->e.eax);
+		return -ENOSYS;
+	}
+	debug("version %x\n", le16_to_cpu(info->version));
+	debug("oem '%s'\n", (char *)bios_ptr(buffer, vga_info,
+					     info->oem_string_ptr));
+	debug("vendor '%s'\n", (char *)bios_ptr(buffer, vga_info,
+						info->vendor_name_ptr));
+	debug("product '%s'\n", (char *)bios_ptr(buffer, vga_info,
+						 info->product_name_ptr));
+	debug("rev '%s'\n", (char *)bios_ptr(buffer, vga_info,
+					     info->product_rev_ptr));
+	modes_bios = bios_ptr(buffer, vga_info, info->modes_ptr);
+	debug("Modes: ");
+	for (ptr = modes_bios; *ptr != 0xffff; ptr++)
+		debug("%x ", le16_to_cpu(*ptr));
+	debug("\nmemory %dMB\n", le16_to_cpu(info->total_memory) >> 4);
+	size = (ptr - modes_bios) * sizeof(u16) + 2;
+	modes = malloc(size);
+	if (!modes)
+		return -ENOMEM;
+	memcpy(modes, modes_bios, size);
+
+	regs->e.eax = VESA_GET_CUR_MODE;
+	BE_int86(0x10, regs, regs);
+	if (regs->e.eax != 0x4f) {
+		debug("VESA_GET_CUR_MODE: error %x\n", regs->e.eax);
+		return -ENOSYS;
+	}
+	debug("Current mode %x\n", regs->e.ebx);
+
+	for (ptr = modes; *ptr != 0xffff; ptr++) {
+		int mode = le16_to_cpu(*ptr);
+		bool linear_ok;
+		int attr;
+
+		break;
+		debug("Mode %x: ", mode);
+		memset(buffer, '\0', sizeof(struct vbe_mode_info));
+		regs->e.eax = VESA_GET_MODE_INFO;
+		regs->e.ebx = 0;
+		regs->e.ecx = mode;
+		regs->e.edx = 0;
+		regs->e.esi = buffer_seg;
+		regs->e.edi = buffer_adr;
+		BE_int86(0x10, regs, regs);
+		if (regs->e.eax != 0x4f) {
+			debug("VESA_GET_MODE_INFO: error %x\n", regs->e.eax);
+			continue;
+		}
+		memcpy(mode_info->mode_info_block, buffer,
+		       sizeof(struct vesa_mode_info));
+		mode_info->valid = true;
+		vm = &mode_info->vesa;
+		attr = le16_to_cpu(vm->mode_attributes);
+		linear_ok = attr & 0x80;
+		debug("res %d x %d, %d bpp, mm %d, (Linear %s, attr %02x)\n",
+		      le16_to_cpu(vm->x_resolution),
+		      le16_to_cpu(vm->y_resolution),
+		      vm->bits_per_pixel, vm->memory_model,
+		      linear_ok ? "OK" : "not available",
+		      attr);
+		debug("\tRGB pos=%d,%d,%d, size=%d,%d,%d\n",
+		      vm->red_mask_pos, vm->green_mask_pos, vm->blue_mask_pos,
+		      vm->red_mask_size, vm->green_mask_size,
+		      vm->blue_mask_size);
+	}
+
+	return 0;
+}
+
+static int atibios_set_vesa_mode(RMREGS *regs, int vesa_mode,
+				 struct vbe_mode_info *mode_info)
 {
+	void *buffer = (void *)(M.mem_base + vbe_offset);
+	u16 buffer_seg = (((unsigned long)vbe_offset) >> 4) & 0xff00;
+	u16 buffer_adr = ((unsigned long)vbe_offset) & 0xffff;
+	struct vesa_mode_info *vm;
+
 	debug("VBE: Setting VESA mode %#04x\n", vesa_mode);
-	/* request linear framebuffer mode */
-	vesa_mode |= (1 << 14);
-	/* request clearing of framebuffer */
-	vesa_mode &= ~(1 << 15);
 	regs->e.eax = VESA_SET_MODE;
 	regs->e.ebx = vesa_mode;
+	/* request linear framebuffer mode and don't clear display */
+	regs->e.ebx |= (1 << 14) | (1 << 15);
 	BE_int86(0x10, regs, regs);
+	if (regs->e.eax != 0x4f) {
+		debug("VESA_SET_MODE: error %x\n", regs->e.eax);
+		return -ENOSYS;
+	}
 
-	int offset = 0x2000;
-	void *buffer = (void *)(M.mem_base + offset);
-
-	u16 buffer_seg = (((unsigned long)offset) >> 4) & 0xff00;
-	u16 buffer_adr = ((unsigned long)offset) & 0xffff;
+	memset(buffer, '\0', sizeof(struct vbe_mode_info));
+	debug("VBE: Geting info for VESA mode %#04x\n", vesa_mode);
 	regs->e.eax = VESA_GET_MODE_INFO;
-	regs->e.ebx = 0;
 	regs->e.ecx = vesa_mode;
-	regs->e.edx = 0;
 	regs->e.esi = buffer_seg;
 	regs->e.edi = buffer_adr;
 	BE_int86(0x10, regs, regs);
+	if (regs->e.eax != 0x4f) {
+		debug("VESA_GET_MODE_INFO: error %x\n", regs->e.eax);
+		return -ENOSYS;
+	}
+
 	memcpy(mode_info->mode_info_block, buffer,
-	       sizeof(struct vbe_mode_info));
+		sizeof(struct vesa_mode_info));
 	mode_info->valid = true;
+	mode_info->video_mode = vesa_mode;
+	vm = &mode_info->vesa;
+	vm->x_resolution = le16_to_cpu(vm->x_resolution);
+	vm->y_resolution = le16_to_cpu(vm->y_resolution);
+	vm->bytes_per_scanline = le16_to_cpu(vm->bytes_per_scanline);
+	vm->phys_base_ptr = le32_to_cpu(vm->phys_base_ptr);
+	vm->mode_attributes = le16_to_cpu(vm->mode_attributes);
+	debug("VBE: Init complete\n");
 
-	vesa_mode |= (1 << 14);
-	/* request clearing of framebuffer */
-	vesa_mode &= ~(1 << 15);
-	regs->e.eax = VESA_SET_MODE;
-	regs->e.ebx = vesa_mode;
-	BE_int86(0x10, regs, regs);
+	return 0;
 }
 
 /****************************************************************************
@@ -132,6 +250,9 @@ static void PCI_doBIOSPOST(pci_dev_t pcidev, BE_VGAInfo *vga_info,
 	/*Cleanup and exit*/
 	BE_getVGA(vga_info);
 
+	/* Useful for debugging */
+	if (0)
+		atibios_debug_mode(vga_info, &regs, vesa_mode, mode_info);
 	if (vesa_mode != -1)
 		atibios_set_vesa_mode(&regs, vesa_mode, mode_info);
 }
diff --git a/include/vbe.h b/include/vbe.h
index d405691..c5deee9 100644
--- a/include/vbe.h
+++ b/include/vbe.h
@@ -35,10 +35,14 @@ struct __packed screen_info_input {
 struct __packed vbe_info {
 	char signature[4];
 	u16 version;
-	u8 *oem_string_ptr;
+	u32 oem_string_ptr;
 	u32 capabilities;
-	u16 video_mode_list[256];
+	u32 modes_ptr;
 	u16 total_memory;
+	u16 oem_version;
+	u32 vendor_name_ptr;
+	u32 product_name_ptr;
+	u32 product_rev_ptr;
 };
 
 struct __packed vesa_mode_info {
@@ -96,6 +100,7 @@ struct vbe_ddc_info {
 #define VESA_GET_INFO		0x4f00
 #define VESA_GET_MODE_INFO	0x4f01
 #define VESA_SET_MODE		0x4f02
+#define VESA_GET_CUR_MODE	0x4f03
 
 struct graphic_device;
 int vbe_get_video_info(struct graphic_device *gdev);
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 05/10] bios_emulator: Add some VESA interface debugging

[Simon Glass]

On 29 December 2014 at 19:32, Simon Glass <sjg@chromium.org> wrote:
> Allow the supported modes to be listed when in debug mode.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++++++++++++++-----
>  include/vbe.h                   |   9 ++-
>  2 files changed, 148 insertions(+), 22 deletions(-)

Applied to u-boot-x86.

[U-Boot] [PATCH 05/10] bios_emulator: Add some VESA interface debugging

[Heinrich Schuchardt]

On 12/30/14 3:32 AM, Simon Glass wrote:
> Allow the supported modes to be listed when in debug mode.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>   drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++++++++++++++-----
>   include/vbe.h                   |   9 ++-
>   2 files changed, 148 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c
> index 93b815c..7ea5fa6 100644
> --- a/drivers/bios_emulator/atibios.c
> +++ b/drivers/bios_emulator/atibios.c
> @@ -62,40 +62,158 @@ static u32 saveBaseAddress14;
>   static u32 saveBaseAddress18;
>   static u32 saveBaseAddress20;
>
> -static void atibios_set_vesa_mode(RMREGS *regs, int vesa_mode,
> -				  struct vbe_mode_info *mode_info)
> +/* Addres im memory of VBE region */
> +const int vbe_offset = 0x2000;
> +
> +static const void *bios_ptr(const void *buf, BE_VGAInfo *vga_info,
> +			    u32 x86_dword_ptr)
> +{
> +	u32 seg_ofs, flat;
> +
> +	seg_ofs = le32_to_cpu(x86_dword_ptr);
> +	flat = ((seg_ofs & 0xffff0000) >> 12) | (seg_ofs & 0xffff);
> +	if (flat >= 0xc0000)
> +		return vga_info->BIOSImage + flat - 0xc0000;
> +	else
> +		return buf + (flat - vbe_offset);
> +}
> +
> +static int atibios_debug_mode(BE_VGAInfo *vga_info, RMREGS *regs,
> +			      int vesa_mode, struct vbe_mode_info *mode_info)
> +{
> +	void *buffer = (void *)(M.mem_base + vbe_offset);
> +	u16 buffer_seg = (((unsigned long)vbe_offset) >> 4) & 0xff00;
> +	u16 buffer_adr = ((unsigned long)vbe_offset) & 0xffff;
> +	struct vesa_mode_info *vm;
> +	struct vbe_info *info;
> +	const u16 *modes_bios, *ptr;
> +	u16 *modes;
> +	int size;
> +
> +	debug("VBE: Getting information\n");
> +	regs->e.eax = VESA_GET_INFO;
> +	regs->e.esi = buffer_seg;
> +	regs->e.edi = buffer_adr;
> +	info = buffer;
> +	memset(info, '\0', sizeof(*info));
> +	strcpy(info->signature, "VBE2");
> +	BE_int86(0x10, regs, regs);
> +	if (regs->e.eax != 0x4f) {
> +		debug("VESA_GET_INFO: error %x\n", regs->e.eax);
> +		return -ENOSYS;
> +	}
> +	debug("version %x\n", le16_to_cpu(info->version));
> +	debug("oem '%s'\n", (char *)bios_ptr(buffer, vga_info,
> +					     info->oem_string_ptr));
> +	debug("vendor '%s'\n", (char *)bios_ptr(buffer, vga_info,
> +						info->vendor_name_ptr));
> +	debug("product '%s'\n", (char *)bios_ptr(buffer, vga_info,
> +						 info->product_name_ptr));
> +	debug("rev '%s'\n", (char *)bios_ptr(buffer, vga_info,
> +					     info->product_rev_ptr));
> +	modes_bios = bios_ptr(buffer, vga_info, info->modes_ptr);
> +	debug("Modes: ");
> +	for (ptr = modes_bios; *ptr != 0xffff; ptr++)
> +		debug("%x ", le16_to_cpu(*ptr));
> +	debug("\nmemory %dMB\n", le16_to_cpu(info->total_memory) >> 4);
> +	size = (ptr - modes_bios) * sizeof(u16) + 2;
> +	modes = malloc(size);
> +	if (!modes)
> +		return -ENOMEM;
> +	memcpy(modes, modes_bios, size);
> +
> +	regs->e.eax = VESA_GET_CUR_MODE;
> +	BE_int86(0x10, regs, regs);
> +	if (regs->e.eax != 0x4f) {
> +		debug("VESA_GET_CUR_MODE: error %x\n", regs->e.eax);
> +		return -ENOSYS;
> +	}
> +	debug("Current mode %x\n", regs->e.ebx);
> +
> +	for (ptr = modes; *ptr != 0xffff; ptr++) {
> +		int mode = le16_to_cpu(*ptr);
> +		bool linear_ok;
> +		int attr;
> +
> +		break;

There is a lot of dead code following. Has this break been left over
from debugging? Or should the whole loop be eliminated?

Best regards

Heinrich

> +		debug("Mode %x: ", mode);
> +		memset(buffer, '\0', sizeof(struct vbe_mode_info));
> +		regs->e.eax = VESA_GET_MODE_INFO;
> +		regs->e.ebx = 0;
> +		regs->e.ecx = mode;
> +		regs->e.edx = 0;
> +		regs->e.esi = buffer_seg;
> +		regs->e.edi = buffer_adr;
> +		BE_int86(0x10, regs, regs);
> +		if (regs->e.eax != 0x4f) {
> +			debug("VESA_GET_MODE_INFO: error %x\n", regs->e.eax);
> +			continue;
> +		}
> +		memcpy(mode_info->mode_info_block, buffer,
> +		       sizeof(struct vesa_mode_info));
> +		mode_info->valid = true;
> +		vm = &mode_info->vesa;
> +		attr = le16_to_cpu(vm->mode_attributes);
> +		linear_ok = attr & 0x80;
> +		debug("res %d x %d, %d bpp, mm %d, (Linear %s, attr %02x)\n",
> +		      le16_to_cpu(vm->x_resolution),
> +		      le16_to_cpu(vm->y_resolution),
> +		      vm->bits_per_pixel, vm->memory_model,
> +		      linear_ok ? "OK" : "not available",
> +		      attr);
> +		debug("\tRGB pos=%d,%d,%d, size=%d,%d,%d\n",
> +		      vm->red_mask_pos, vm->green_mask_pos, vm->blue_mask_pos,
> +		      vm->red_mask_size, vm->green_mask_size,
> +		      vm->blue_mask_size);
> +	}
> +
> +	return 0;
> +}
> +
> +static int atibios_set_vesa_mode(RMREGS *regs, int vesa_mode,
> +				 struct vbe_mode_info *mode_info)
>   {
> +	void *buffer = (void *)(M.mem_base + vbe_offset);
> +	u16 buffer_seg = (((unsigned long)vbe_offset) >> 4) & 0xff00;
> +	u16 buffer_adr = ((unsigned long)vbe_offset) & 0xffff;
> +	struct vesa_mode_info *vm;
> +
>   	debug("VBE: Setting VESA mode %#04x\n", vesa_mode);
> -	/* request linear framebuffer mode */
> -	vesa_mode |= (1 << 14);
> -	/* request clearing of framebuffer */
> -	vesa_mode &= ~(1 << 15);
>   	regs->e.eax = VESA_SET_MODE;
>   	regs->e.ebx = vesa_mode;
> +	/* request linear framebuffer mode and don't clear display */
> +	regs->e.ebx |= (1 << 14) | (1 << 15);
>   	BE_int86(0x10, regs, regs);
> +	if (regs->e.eax != 0x4f) {
> +		debug("VESA_SET_MODE: error %x\n", regs->e.eax);
> +		return -ENOSYS;
> +	}
>
> -	int offset = 0x2000;
> -	void *buffer = (void *)(M.mem_base + offset);
> -
> -	u16 buffer_seg = (((unsigned long)offset) >> 4) & 0xff00;
> -	u16 buffer_adr = ((unsigned long)offset) & 0xffff;
> +	memset(buffer, '\0', sizeof(struct vbe_mode_info));
> +	debug("VBE: Geting info for VESA mode %#04x\n", vesa_mode);
>   	regs->e.eax = VESA_GET_MODE_INFO;
> -	regs->e.ebx = 0;
>   	regs->e.ecx = vesa_mode;
> -	regs->e.edx = 0;
>   	regs->e.esi = buffer_seg;
>   	regs->e.edi = buffer_adr;
>   	BE_int86(0x10, regs, regs);
> +	if (regs->e.eax != 0x4f) {
> +		debug("VESA_GET_MODE_INFO: error %x\n", regs->e.eax);
> +		return -ENOSYS;
> +	}
> +
>   	memcpy(mode_info->mode_info_block, buffer,
> -	       sizeof(struct vbe_mode_info));
> +		sizeof(struct vesa_mode_info));
>   	mode_info->valid = true;
> +	mode_info->video_mode = vesa_mode;
> +	vm = &mode_info->vesa;
> +	vm->x_resolution = le16_to_cpu(vm->x_resolution);
> +	vm->y_resolution = le16_to_cpu(vm->y_resolution);
> +	vm->bytes_per_scanline = le16_to_cpu(vm->bytes_per_scanline);
> +	vm->phys_base_ptr = le32_to_cpu(vm->phys_base_ptr);
> +	vm->mode_attributes = le16_to_cpu(vm->mode_attributes);
> +	debug("VBE: Init complete\n");
>
> -	vesa_mode |= (1 << 14);
> -	/* request clearing of framebuffer */
> -	vesa_mode &= ~(1 << 15);
> -	regs->e.eax = VESA_SET_MODE;
> -	regs->e.ebx = vesa_mode;
> -	BE_int86(0x10, regs, regs);
> +	return 0;
>   }
>
>   /****************************************************************************
> @@ -132,6 +250,9 @@ static void PCI_doBIOSPOST(pci_dev_t pcidev, BE_VGAInfo *vga_info,
>   	/*Cleanup and exit*/
>   	BE_getVGA(vga_info);
>
> +	/* Useful for debugging */
> +	if (0)
> +		atibios_debug_mode(vga_info, &regs, vesa_mode, mode_info);
>   	if (vesa_mode != -1)
>   		atibios_set_vesa_mode(&regs, vesa_mode, mode_info);
>   }
> diff --git a/include/vbe.h b/include/vbe.h
> index d405691..c5deee9 100644
> --- a/include/vbe.h
> +++ b/include/vbe.h
> @@ -35,10 +35,14 @@ struct __packed screen_info_input {
>   struct __packed vbe_info {
>   	char signature[4];
>   	u16 version;
> -	u8 *oem_string_ptr;
> +	u32 oem_string_ptr;
>   	u32 capabilities;
> -	u16 video_mode_list[256];
> +	u32 modes_ptr;
>   	u16 total_memory;
> +	u16 oem_version;
> +	u32 vendor_name_ptr;
> +	u32 product_name_ptr;
> +	u32 product_rev_ptr;
>   };
>
>   struct __packed vesa_mode_info {
> @@ -96,6 +100,7 @@ struct vbe_ddc_info {
>   #define VESA_GET_INFO		0x4f00
>   #define VESA_GET_MODE_INFO	0x4f01
>   #define VESA_SET_MODE		0x4f02
> +#define VESA_GET_CUR_MODE	0x4f03
>
>   struct graphic_device;
>   int vbe_get_video_info(struct graphic_device *gdev);
>

[U-Boot] [PATCH 05/10] bios_emulator: Add some VESA interface debugging

[Simon Glass]

Hi Heinrich,

On Tue, 30 Jul 2019 at 14:52, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 12/30/14 3:32 AM, Simon Glass wrote:
> > Allow the supported modes to be listed when in debug mode.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> >   drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++++++++++++++-----
> >   include/vbe.h                   |   9 ++-
> >   2 files changed, 148 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/bios_emulator/atibios.c b/drivers/bios_emulator/atibios.c
> > index 93b815c..7ea5fa6 100644
> > --- a/drivers/bios_emulator/atibios.c
> > +++ b/drivers/bios_emulator/atibios.c
> > @@ -62,40 +62,158 @@ static u32 saveBaseAddress14;
> >   static u32 saveBaseAddress18;
> >   static u32 saveBaseAddress20;
> >
> > -static void atibios_set_vesa_mode(RMREGS *regs, int vesa_mode,
> > -                               struct vbe_mode_info *mode_info)
> > +/* Addres im memory of VBE region */
> > +const int vbe_offset = 0x2000;
> > +
> > +static const void *bios_ptr(const void *buf, BE_VGAInfo *vga_info,
> > +                         u32 x86_dword_ptr)
> > +{
> > +     u32 seg_ofs, flat;
> > +
> > +     seg_ofs = le32_to_cpu(x86_dword_ptr);
> > +     flat = ((seg_ofs & 0xffff0000) >> 12) | (seg_ofs & 0xffff);
> > +     if (flat >= 0xc0000)
> > +             return vga_info->BIOSImage + flat - 0xc0000;
> > +     else
> > +             return buf + (flat - vbe_offset);
> > +}
> > +
> > +static int atibios_debug_mode(BE_VGAInfo *vga_info, RMREGS *regs,
> > +                           int vesa_mode, struct vbe_mode_info *mode_info)
> > +{
> > +     void *buffer = (void *)(M.mem_base + vbe_offset);
> > +     u16 buffer_seg = (((unsigned long)vbe_offset) >> 4) & 0xff00;
> > +     u16 buffer_adr = ((unsigned long)vbe_offset) & 0xffff;
> > +     struct vesa_mode_info *vm;
> > +     struct vbe_info *info;
> > +     const u16 *modes_bios, *ptr;
> > +     u16 *modes;
> > +     int size;
> > +
> > +     debug("VBE: Getting information\n");
> > +     regs->e.eax = VESA_GET_INFO;
> > +     regs->e.esi = buffer_seg;
> > +     regs->e.edi = buffer_adr;
> > +     info = buffer;
> > +     memset(info, '\0', sizeof(*info));
> > +     strcpy(info->signature, "VBE2");
> > +     BE_int86(0x10, regs, regs);
> > +     if (regs->e.eax != 0x4f) {
> > +             debug("VESA_GET_INFO: error %x\n", regs->e.eax);
> > +             return -ENOSYS;
> > +     }
> > +     debug("version %x\n", le16_to_cpu(info->version));
> > +     debug("oem '%s'\n", (char *)bios_ptr(buffer, vga_info,
> > +                                          info->oem_string_ptr));
> > +     debug("vendor '%s'\n", (char *)bios_ptr(buffer, vga_info,
> > +                                             info->vendor_name_ptr));
> > +     debug("product '%s'\n", (char *)bios_ptr(buffer, vga_info,
> > +                                              info->product_name_ptr));
> > +     debug("rev '%s'\n", (char *)bios_ptr(buffer, vga_info,
> > +                                          info->product_rev_ptr));
> > +     modes_bios = bios_ptr(buffer, vga_info, info->modes_ptr);
> > +     debug("Modes: ");
> > +     for (ptr = modes_bios; *ptr != 0xffff; ptr++)
> > +             debug("%x ", le16_to_cpu(*ptr));
> > +     debug("\nmemory %dMB\n", le16_to_cpu(info->total_memory) >> 4);
> > +     size = (ptr - modes_bios) * sizeof(u16) + 2;
> > +     modes = malloc(size);
> > +     if (!modes)
> > +             return -ENOMEM;
> > +     memcpy(modes, modes_bios, size);
> > +
> > +     regs->e.eax = VESA_GET_CUR_MODE;
> > +     BE_int86(0x10, regs, regs);
> > +     if (regs->e.eax != 0x4f) {
> > +             debug("VESA_GET_CUR_MODE: error %x\n", regs->e.eax);
> > +             return -ENOSYS;
> > +     }
> > +     debug("Current mode %x\n", regs->e.ebx);
> > +
> > +     for (ptr = modes; *ptr != 0xffff; ptr++) {
> > +             int mode = le16_to_cpu(*ptr);
> > +             bool linear_ok;
> > +             int attr;
> > +
> > +             break;
>
> There is a lot of dead code following. Has this break been left over
> from debugging? Or should the whole loop be eliminated?

Yes the break should be removed. This is debug code for printing out the modes.

Regards,
Simon

[U-Boot] [PATCH 06/10] x86: pci: Don't stop when we get a vendor/device mismatch

[Simon Glass]

These are quite common and we may as well press on and not be so picky.

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

 drivers/pci/pci_rom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index 124b730..a16e99f 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -117,7 +117,7 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
 	    (vendev == mapped_vendev)) {
 		printf("ID mismatch: vendor ID %04x, device ID %04x\n",
 		       rom_vendor, rom_device);
-		return -EPERM;
+		/* Continue anyway */
 	}
 
 	debug("PCI ROM image, Class Code %04x%02x, Code Type %02x\n",
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 06/10] x86: pci: Don't stop when we get a vendor/device mismatch

[Bin Meng]

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> These are quite common and we may as well press on and not be so picky.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/pci/pci_rom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> index 124b730..a16e99f 100644
> --- a/drivers/pci/pci_rom.c
> +++ b/drivers/pci/pci_rom.c
> @@ -117,7 +117,7 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
>             (vendev == mapped_vendev)) {
>                 printf("ID mismatch: vendor ID %04x, device ID %04x\n",
>                        rom_vendor, rom_device);
> -               return -EPERM;
> +               /* Continue anyway */
>         }
>
>         debug("PCI ROM image, Class Code %04x%02x, Code Type %02x\n",
> --

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

[U-Boot] [PATCH 06/10] x86: pci: Don't stop when we get a vendor/device mismatch

[Simon Glass]

On 3 January 2015 at 22:51, Bin Meng <bmeng.cn@gmail.com> wrote:
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>> These are quite common and we may as well press on and not be so picky.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  drivers/pci/pci_rom.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-x86.

[U-Boot] [PATCH 07/10] x86: Add a VESA video driver

[Simon Glass]

Add a driver intended to cope with any VESA-compatible x86 graphics
adapter. It will not support ROMs which use OpenFirmware (Forth) since
there is no support for that in U-Boot. This means that MAC OS cards
will not work.

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

 drivers/video/Makefile  |  1 +
 drivers/video/vesa_fb.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 65 insertions(+)
 create mode 100644 drivers/video/vesa_fb.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 975d136..91c954f 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
 obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
+obj-$(CONFIG_VIDEO_VESA) += vesa_fb.o
 obj-$(CONFIG_VIDEO_X86) += x86_fb.o
 obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
diff --git a/drivers/video/vesa_fb.c b/drivers/video/vesa_fb.c
new file mode 100644
index 0000000..3dacafd
--- /dev/null
+++ b/drivers/video/vesa_fb.c
@@ -0,0 +1,64 @@
+/*
+ *
+ * Vesa frame buffer driver for x86
+ *
+ * Copyright (C) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <pci_rom.h>
+#include <video_fb.h>
+#include <vbe.h>
+
+/*
+ * The Graphic Device
+ */
+GraphicDevice ctfb;
+
+/* Devices to allow - only the last one works fully */
+struct pci_device_id vesa_video_ids[] = {
+	{ .vendor = 0x102b, .device = 0x0525 },
+	{ .vendor = 0x1002, .device = 0x5159 },
+	{ .vendor = 0x1002, .device = 0x4752 },
+	{ .vendor = 0x1002, .device = 0x5452 },
+	{},
+};
+
+void *video_hw_init(void)
+{
+	GraphicDevice *gdev = &ctfb;
+	int bits_per_pixel;
+	pci_dev_t dev;
+	int ret;
+
+	printf("Video: ");
+	if (vbe_get_video_info(gdev)) {
+		/* TODO: Should we look these up by class? */
+		dev = pci_find_devices(vesa_video_ids, 0);
+		if (dev == -1) {
+			printf("no card detected\n");
+			return NULL;
+		}
+		printf("bdf %x\n", dev);
+		ret = pci_run_vga_bios(dev, NULL, true);
+		if (ret) {
+			printf("failed to run video BIOS: %d\n", ret);
+			return NULL;
+		}
+	}
+
+	if (vbe_get_video_info(gdev)) {
+		printf("No video mode configured\n");
+		return NULL;
+	}
+
+	bits_per_pixel = gdev->gdfBytesPP * 8;
+	sprintf(gdev->modeIdent, "%dx%dx%d", gdev->winSizeX, gdev->winSizeY,
+		bits_per_pixel);
+	printf("%s\n", gdev->modeIdent);
+	debug("Framex buffer at %x\n", gdev->pciBase);
+
+	return (void *)gdev;
+}
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 07/10] x86: Add a VESA video driver

[Simon Glass]

On 29 December 2014 at 19:32, Simon Glass <sjg@chromium.org> wrote:
> Add a driver intended to cope with any VESA-compatible x86 graphics
> adapter. It will not support ROMs which use OpenFirmware (Forth) since
> there is no support for that in U-Boot. This means that MAC OS cards
> will not work.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/video/Makefile  |  1 +
>  drivers/video/vesa_fb.c | 64 +++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 65 insertions(+)
>  create mode 100644 drivers/video/vesa_fb.c

Rebased and added Kconfig info which was required to make this build
as expected.

Applied to u-boot-x86.

[U-Boot] [PATCH 08/10] x86: Drop the x86_fb driver

[Simon Glass]

Now that we have a full VESA driver we may as well use that. We need to
support the VESA layer being set up by early start-up code or by
running a VGA ROM.

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

 drivers/video/Makefile            |  1 -
 drivers/video/x86_fb.c            | 38 --------------------------------------
 include/configs/chromebook_link.h |  2 +-
 3 files changed, 1 insertion(+), 40 deletions(-)
 delete mode 100644 drivers/video/x86_fb.c

diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 91c954f..4da82b4 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -47,7 +47,6 @@ obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o
 obj-$(CONFIG_VIDEO_TEGRA) += tegra.o
 obj-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
 obj-$(CONFIG_VIDEO_VESA) += vesa_fb.o
-obj-$(CONFIG_VIDEO_X86) += x86_fb.o
 obj-$(CONFIG_FORMIKE) += formike.o
 obj-$(CONFIG_AM335X_LCD) += am335x-fb.o
 obj-$(CONFIG_VIDEO_PARADE) += parade.o
diff --git a/drivers/video/x86_fb.c b/drivers/video/x86_fb.c
deleted file mode 100644
index 6641033..0000000
--- a/drivers/video/x86_fb.c
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- *
- * Vesa frame buffer driver for x86
- *
- * Copyright (C) 2014 Google, Inc
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-#include <common.h>
-#include <video_fb.h>
-#include <vbe.h>
-#include "videomodes.h"
-
-/*
- * The Graphic Device
- */
-GraphicDevice ctfb;
-
-void *video_hw_init(void)
-{
-	GraphicDevice *gdev = &ctfb;
-	int bits_per_pixel;
-
-	printf("Video: ");
-	if (vbe_get_video_info(gdev)) {
-		printf("No video mode configured\n");
-		return NULL;
-	}
-
-	bits_per_pixel = gdev->gdfBytesPP * 8;
-	sprintf(gdev->modeIdent, "%dx%dx%d", gdev->winSizeX, gdev->winSizeY,
-		bits_per_pixel);
-	printf("%s\n", gdev->modeIdent);
-	debug("Frame buffer at %x\n", gdev->frameAdrs);
-
-	return (void *)gdev;
-}
diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h
index 8930210..1a53483 100644
--- a/include/configs/chromebook_link.h
+++ b/include/configs/chromebook_link.h
@@ -41,7 +41,7 @@
 
 #define CONFIG_X86_OPTION_ROM_FILE		pci8086,0166.bin
 #define CONFIG_X86_OPTION_ROM_ADDR		0xfff90000
-#define CONFIG_VIDEO_X86
+#define CONFIG_VIDEO_VESA
 
 #define CONFIG_PCI_MEM_BUS	0xe0000000
 #define CONFIG_PCI_MEM_PHYS	CONFIG_PCI_MEM_BUS
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 08/10] x86: Drop the x86_fb driver

[Simon Glass]

On 29 December 2014 at 19:32, Simon Glass <sjg@chromium.org> wrote:
> Now that we have a full VESA driver we may as well use that. We need to
> support the VESA layer being set up by early start-up code or by
> running a VGA ROM.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/video/Makefile            |  1 -
>  drivers/video/x86_fb.c            | 38 --------------------------------------
>  include/configs/chromebook_link.h |  2 +-
>  3 files changed, 1 insertion(+), 40 deletions(-)
>  delete mode 100644 drivers/video/x86_fb.c

Dropped the header file change and moved it to Kconfig, where this now
resides since Bin's series was applied first.

Applied to u-boot-x86.

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Simon Glass]

Add code to the generic pci_rom file to access the VGA ROM in PCI space
when needed.

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

 drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
 drivers/pci/pci_rom.c  |  7 ++++++-
 include/pci.h          |  9 +++++++++
 3 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 44470fa..61bf6b4 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -11,7 +11,7 @@
  */
 
 #include <common.h>
-
+#include <errno.h>
 #include <pci.h>
 
 #undef DEBUG
@@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
 	pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
 }
 
+int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
+{
+	pci_addr_t bar_value;
+	pci_size_t bar_size;
+	u32 bar_response;
+	u16 cmdstat = 0;
+
+	pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
+	pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
+	if (!bar_response)
+		return -ENOENT;
+
+	bar_size = -(bar_response & ~1);
+	DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
+	if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {
+		pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
+					    bar_value);
+	}
+	DEBUGF("\n");
+	pci_hose_read_config_word(hose, dev, PCI_COMMAND, &cmdstat);
+	cmdstat |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
+	pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
+
+	return 0;
+}
+
 void pciauto_prescan_setup_bridge(struct pci_controller *hose,
 					 pci_dev_t dev, int sub_bus)
 {
diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
index a16e99f..eb76591 100644
--- a/drivers/pci/pci_rom.c
+++ b/drivers/pci/pci_rom.c
@@ -81,7 +81,12 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
 #ifdef CONFIG_X86_OPTION_ROM_ADDR
 	rom_address = CONFIG_X86_OPTION_ROM_ADDR;
 #else
-	pci_write_config_dword(dev, PCI_ROM_ADDRESS, (u32)PCI_ROM_ADDRESS_MASK);
+
+	if (pciauto_setup_rom(pci_bus_to_hose(PCI_BUS(dev)), dev)) {
+		debug("Cannot find option ROM\n");
+		return -ENOENT;
+	}
+
 	pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_address);
 	if (rom_address == 0x00000000 || rom_address == 0xffffffff) {
 		debug("%s: rom_address=%x\n", __func__, rom_address);
diff --git a/include/pci.h b/include/pci.h
index 216f448..f135ba8 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -701,5 +701,14 @@ void pci_write_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum,
  * */
 u32 pci_read_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum);
 
+/**
+ * pciauto_setup_rom() - Set up access to a device ROM
+ *
+ * @hose:	PCI hose to use
+ * @dev:	PCI device to adjust
+ * @return 0 if done, -ve on error
+ */
+int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev);
+
 #endif /* __ASSEMBLY__ */
 #endif /* _PCI_H */
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Bin Meng]

Hi Simon,

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> Add code to the generic pci_rom file to access the VGA ROM in PCI space
> when needed.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
>  drivers/pci/pci_rom.c  |  7 ++++++-
>  include/pci.h          |  9 +++++++++
>  3 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
> index 44470fa..61bf6b4 100644
> --- a/drivers/pci/pci_auto.c
> +++ b/drivers/pci/pci_auto.c
> @@ -11,7 +11,7 @@
>   */
>
>  #include <common.h>
> -
> +#include <errno.h>
>  #include <pci.h>
>
>  #undef DEBUG
> @@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
>         pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
>  }
>
> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
> +{
> +       pci_addr_t bar_value;
> +       pci_size_t bar_size;
> +       u32 bar_response;
> +       u16 cmdstat = 0;
> +
> +       pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
> +       pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
> +       if (!bar_response)
> +               return -ENOENT;
> +
> +       bar_size = -(bar_response & ~1);
> +       DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
> +       if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {

Should we assume pci roms are always mapped using the pci_mem region?
If not, maybe we can add another parameter 'region_type' to
pciauto_setup_rom()?

> +               pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
> +                                           bar_value);
> +       }
> +       DEBUGF("\n");
> +       pci_hose_read_config_word(hose, dev, PCI_COMMAND, &cmdstat);
> +       cmdstat |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
> +       pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
> +
> +       return 0;
> +}
> +
>  void pciauto_prescan_setup_bridge(struct pci_controller *hose,
>                                          pci_dev_t dev, int sub_bus)
>  {
> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
> index a16e99f..eb76591 100644
> --- a/drivers/pci/pci_rom.c
> +++ b/drivers/pci/pci_rom.c
> @@ -81,7 +81,12 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
>  #ifdef CONFIG_X86_OPTION_ROM_ADDR
>         rom_address = CONFIG_X86_OPTION_ROM_ADDR;
>  #else
> -       pci_write_config_dword(dev, PCI_ROM_ADDRESS, (u32)PCI_ROM_ADDRESS_MASK);
> +
> +       if (pciauto_setup_rom(pci_bus_to_hose(PCI_BUS(dev)), dev)) {
> +               debug("Cannot find option ROM\n");
> +               return -ENOENT;
> +       }
> +
>         pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_address);
>         if (rom_address == 0x00000000 || rom_address == 0xffffffff) {
>                 debug("%s: rom_address=%x\n", __func__, rom_address);
> diff --git a/include/pci.h b/include/pci.h
> index 216f448..f135ba8 100644
> --- a/include/pci.h
> +++ b/include/pci.h
> @@ -701,5 +701,14 @@ void pci_write_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum,
>   * */
>  u32 pci_read_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum);
>
> +/**
> + * pciauto_setup_rom() - Set up access to a device ROM
> + *
> + * @hose:      PCI hose to use
> + * @dev:       PCI device to adjust
> + * @return 0 if done, -ve on error
> + */
> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev);
> +
>  #endif /* __ASSEMBLY__ */
>  #endif /* _PCI_H */
> --

Regards,
Bin

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Simon Glass]

Hi Bin,

On 3 January 2015 at 22:54, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>> Add code to the generic pci_rom file to access the VGA ROM in PCI space
>> when needed.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
>>  drivers/pci/pci_rom.c  |  7 ++++++-
>>  include/pci.h          |  9 +++++++++
>>  3 files changed, 42 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
>> index 44470fa..61bf6b4 100644
>> --- a/drivers/pci/pci_auto.c
>> +++ b/drivers/pci/pci_auto.c
>> @@ -11,7 +11,7 @@
>>   */
>>
>>  #include <common.h>
>> -
>> +#include <errno.h>
>>  #include <pci.h>
>>
>>  #undef DEBUG
>> @@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
>>         pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
>>  }
>>
>> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
>> +{
>> +       pci_addr_t bar_value;
>> +       pci_size_t bar_size;
>> +       u32 bar_response;
>> +       u16 cmdstat = 0;
>> +
>> +       pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
>> +       pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
>> +       if (!bar_response)
>> +               return -ENOENT;
>> +
>> +       bar_size = -(bar_response & ~1);
>> +       DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
>> +       if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {
>
> Should we assume pci roms are always mapped using the pci_mem region?
> If not, maybe we can add another parameter 'region_type' to
> pciauto_setup_rom()?

I'm not sure - do you think we should support the cacheable area too?
Would that help?

>
>> +               pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS,
>> +                                           bar_value);
>> +       }
>> +       DEBUGF("\n");
>> +       pci_hose_read_config_word(hose, dev, PCI_COMMAND, &cmdstat);
>> +       cmdstat |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
>> +       pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
>> +
>> +       return 0;
>> +}
>> +
>>  void pciauto_prescan_setup_bridge(struct pci_controller *hose,
>>                                          pci_dev_t dev, int sub_bus)
>>  {
>> diff --git a/drivers/pci/pci_rom.c b/drivers/pci/pci_rom.c
>> index a16e99f..eb76591 100644
>> --- a/drivers/pci/pci_rom.c
>> +++ b/drivers/pci/pci_rom.c
>> @@ -81,7 +81,12 @@ static int pci_rom_probe(pci_dev_t dev, uint class,
>>  #ifdef CONFIG_X86_OPTION_ROM_ADDR
>>         rom_address = CONFIG_X86_OPTION_ROM_ADDR;
>>  #else
>> -       pci_write_config_dword(dev, PCI_ROM_ADDRESS, (u32)PCI_ROM_ADDRESS_MASK);
>> +
>> +       if (pciauto_setup_rom(pci_bus_to_hose(PCI_BUS(dev)), dev)) {
>> +               debug("Cannot find option ROM\n");
>> +               return -ENOENT;
>> +       }
>> +
>>         pci_read_config_dword(dev, PCI_ROM_ADDRESS, &rom_address);
>>         if (rom_address == 0x00000000 || rom_address == 0xffffffff) {
>>                 debug("%s: rom_address=%x\n", __func__, rom_address);
>> diff --git a/include/pci.h b/include/pci.h
>> index 216f448..f135ba8 100644
>> --- a/include/pci.h
>> +++ b/include/pci.h
>> @@ -701,5 +701,14 @@ void pci_write_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum,
>>   * */
>>  u32 pci_read_bar32(struct pci_controller *hose, pci_dev_t dev, int barnum);
>>
>> +/**
>> + * pciauto_setup_rom() - Set up access to a device ROM
>> + *
>> + * @hose:      PCI hose to use
>> + * @dev:       PCI device to adjust
>> + * @return 0 if done, -ve on error
>> + */
>> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev);
>> +
>>  #endif /* __ASSEMBLY__ */
>>  #endif /* _PCI_H */

Regards,
Simon

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Bin Meng]

Hi Simon,

On Mon, Jan 5, 2015 at 9:45 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 3 January 2015 at 22:54, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Add code to the generic pci_rom file to access the VGA ROM in PCI space
>>> when needed.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> ---
>>>
>>>  drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
>>>  drivers/pci/pci_rom.c  |  7 ++++++-
>>>  include/pci.h          |  9 +++++++++
>>>  3 files changed, 42 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
>>> index 44470fa..61bf6b4 100644
>>> --- a/drivers/pci/pci_auto.c
>>> +++ b/drivers/pci/pci_auto.c
>>> @@ -11,7 +11,7 @@
>>>   */
>>>
>>>  #include <common.h>
>>> -
>>> +#include <errno.h>
>>>  #include <pci.h>
>>>
>>>  #undef DEBUG
>>> @@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
>>>         pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
>>>  }
>>>
>>> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
>>> +{
>>> +       pci_addr_t bar_value;
>>> +       pci_size_t bar_size;
>>> +       u32 bar_response;
>>> +       u16 cmdstat = 0;
>>> +
>>> +       pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);

I think it is better for people to understand if not writing -2.

>>> +       pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
>>> +       if (!bar_response)
>>> +               return -ENOENT;
>>> +
>>> +       bar_size = -(bar_response & ~1);
>>> +       DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
>>> +       if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {
>>
>> Should we assume pci roms are always mapped using the pci_mem region?
>> If not, maybe we can add another parameter 'region_type' to
>> pciauto_setup_rom()?
>
> I'm not sure - do you think we should support the cacheable area too?
> Would that help?
>

I'm not sure either. I thought you might know more than me as so far I
see pci rom is used for vga, ahci, pxe roms, and storage media for mac
addresses on some ethernet cards. They all belong to pci_mem regions.
Let's do it pci_mem and revisit it in the future if we see something
different.

[snip]

Regards,
Bin

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Simon Glass]

Hi Bin,

On 5 January 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Jan 5, 2015 at 9:45 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 3 January 2015 at 22:54, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Add code to the generic pci_rom file to access the VGA ROM in PCI space
>>>> when needed.
>>>>
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>> ---
>>>>
>>>>  drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
>>>>  drivers/pci/pci_rom.c  |  7 ++++++-
>>>>  include/pci.h          |  9 +++++++++
>>>>  3 files changed, 42 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
>>>> index 44470fa..61bf6b4 100644
>>>> --- a/drivers/pci/pci_auto.c
>>>> +++ b/drivers/pci/pci_auto.c
>>>> @@ -11,7 +11,7 @@
>>>>   */
>>>>
>>>>  #include <common.h>
>>>> -
>>>> +#include <errno.h>
>>>>  #include <pci.h>
>>>>
>>>>  #undef DEBUG
>>>> @@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
>>>>         pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
>>>>  }
>>>>
>>>> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
>>>> +{
>>>> +       pci_addr_t bar_value;
>>>> +       pci_size_t bar_size;
>>>> +       u32 bar_response;
>>>> +       u16 cmdstat = 0;
>>>> +
>>>> +       pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
>
> I think it is better for people to understand if not writing -2.

What should we use instead?

>
>>>> +       pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
>>>> +       if (!bar_response)
>>>> +               return -ENOENT;
>>>> +
>>>> +       bar_size = -(bar_response & ~1);
>>>> +       DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
>>>> +       if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {
>>>
>>> Should we assume pci roms are always mapped using the pci_mem region?
>>> If not, maybe we can add another parameter 'region_type' to
>>> pciauto_setup_rom()?
>>
>> I'm not sure - do you think we should support the cacheable area too?
>> Would that help?
>>
>
> I'm not sure either. I thought you might know more than me as so far I
> see pci rom is used for vga, ahci, pxe roms, and storage media for mac
> addresses on some ethernet cards. They all belong to pci_mem regions.
> Let's do it pci_mem and revisit it in the future if we see something
> different.

OK.

Regards,
Simon

[U-Boot] [PATCH 09/10] x86: Access the VGA ROM when needed

[Bin Meng]

Hi Simon,

On Thu, Jan 15, 2015 at 3:36 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 5 January 2015 at 06:49, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Mon, Jan 5, 2015 at 9:45 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 3 January 2015 at 22:54, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Add code to the generic pci_rom file to access the VGA ROM in PCI space
>>>>> when needed.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>> ---
>>>>>
>>>>>  drivers/pci/pci_auto.c | 28 +++++++++++++++++++++++++++-
>>>>>  drivers/pci/pci_rom.c  |  7 ++++++-
>>>>>  include/pci.h          |  9 +++++++++
>>>>>  3 files changed, 42 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
>>>>> index 44470fa..61bf6b4 100644
>>>>> --- a/drivers/pci/pci_auto.c
>>>>> +++ b/drivers/pci/pci_auto.c
>>>>> @@ -11,7 +11,7 @@
>>>>>   */
>>>>>
>>>>>  #include <common.h>
>>>>> -
>>>>> +#include <errno.h>
>>>>>  #include <pci.h>
>>>>>
>>>>>  #undef DEBUG
>>>>> @@ -191,6 +191,32 @@ void pciauto_setup_device(struct pci_controller *hose,
>>>>>         pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
>>>>>  }
>>>>>
>>>>> +int pciauto_setup_rom(struct pci_controller *hose, pci_dev_t dev)
>>>>> +{
>>>>> +       pci_addr_t bar_value;
>>>>> +       pci_size_t bar_size;
>>>>> +       u32 bar_response;
>>>>> +       u16 cmdstat = 0;
>>>>> +
>>>>> +       pci_hose_write_config_dword(hose, dev, PCI_ROM_ADDRESS, -2);
>>
>> I think it is better for people to understand if not writing -2.
>
> What should we use instead?

0xfffffffe

>>
>>>>> +       pci_hose_read_config_dword(hose, dev, PCI_ROM_ADDRESS, &bar_response);
>>>>> +       if (!bar_response)
>>>>> +               return -ENOENT;
>>>>> +
>>>>> +       bar_size = -(bar_response & ~1);
>>>>> +       DEBUGF("PCI Autoconfig: ROM, size=%#x, ", bar_size);
>>>>> +       if (pciauto_region_allocate(hose->pci_mem, bar_size, &bar_value) == 0) {
>>>>
>>>> Should we assume pci roms are always mapped using the pci_mem region?
>>>> If not, maybe we can add another parameter 'region_type' to
>>>> pciauto_setup_rom()?
>>>
>>> I'm not sure - do you think we should support the cacheable area too?
>>> Would that help?
>>>
>>
>> I'm not sure either. I thought you might know more than me as so far I
>> see pci rom is used for vga, ahci, pxe roms, and storage media for mac
>> addresses on some ethernet cards. They all belong to pci_mem regions.
>> Let's do it pci_mem and revisit it in the future if we see something
>> different.
>
> OK.
>

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

NOT TO APPLY

This shows how to enable video for the glacier board, as an example of the
emulator working on a VESA-compliant graphics card.

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

 include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
index 7a1499d..c55e076 100644
--- a/include/configs/canyonlands.h
+++ b/include/configs/canyonlands.h
@@ -133,6 +133,9 @@
 #define CONFIG_SYS_NOR_CS		0	/* NOR chip connected to CSx */
 #define CONFIG_SYS_NAND_CS		3	/* NAND chip connected to CSx */
 
+#define CONFIG_CONSOLE_MUX
+#define CONFIG_SYS_CONSOLE_IS_IN_ENV
+
 /*-----------------------------------------------------------------------
  * FLASH related
  *----------------------------------------------------------------------*/
@@ -359,6 +362,15 @@
 	"ramdisk_addr=fc200000\0"					\
 	"pciconfighost=1\0"						\
 	"pcie_mode=RP:RP\0"						\
+	"eth1addr=00:01:ec:00:f4:9d\0" \
+	"eth2addr=00:01:ec:00:f4:9e\0" \
+	"eth3addr=00:01:ec:00:f4:9f\0" \
+	"ethact=ppc_4xx_eth0\0" \
+	"ethaddr=00:01:ec:00:f4:9c\0" \
+	"stderr=serial\0" \
+	"stdin=serial\0" \
+	"stdout=serial,vga\0" \
+	"autoload=n\0" \
 	""
 #else /* defined(CONFIG_ARCHES) */
 #define CONFIG_EXTRA_ENV_SETTINGS					\
@@ -675,4 +687,23 @@
 }
 #endif
 
+#define CONFIG_VIDEO
+
+#ifdef CONFIG_VIDEO
+#define CONFIG_BIOSEMU			/* x86 bios emulator for vga bios */
+#define CONFIG_VIDEO_VESA
+#define VIDEO_IO_OFFSET			0xd8000000
+#define CONFIG_SYS_ISA_IO_BASE_ADDRESS		VIDEO_IO_OFFSET
+#define CONFIG_VIDEO_SW_CURSOR
+#define CONFIG_VIDEO_LOGO
+#define CONFIG_CFB_CONSOLE
+#define CONFIG_SPLASH_SCREEN
+#define CONFIG_VGA_AS_SINGLE_DEVICE
+#define CONFIG_CMD_BMP
+#endif
+
+#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
+#define CONFIG_FRAMEBUFFER_VESA_MODE	0x114
+#define CONFIG_CMD_TFTPPUT
+
 #endif	/* __CONFIG_H */
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> NOT TO APPLY
>
> This shows how to enable video for the glacier board, as an example of the
> emulator working on a VESA-compliant graphics card.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>

Did you test a PCIe video card on chromebook_link? Looks like there
are things we still need to do to support VGA rom on x86. In the
bridge control (offset 0x3e) register of the PCI bridge, there is a
VGA enable bit which currently U-Boot does not configure. I believe
this will stop video card from working. However, so far I even cannot
read the content of the VGA rom (all returns 0xFF) after I manually
enabled this VGA enable bit. Do you know what may cause this?

[snip]

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
> NOT TO APPLY
>
> This shows how to enable video for the glacier board, as an example of the
> emulator working on a VESA-compliant graphics card.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
>
> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
> index 7a1499d..c55e076 100644
> --- a/include/configs/canyonlands.h
> +++ b/include/configs/canyonlands.h
> @@ -133,6 +133,9 @@
>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>
> +#define CONFIG_CONSOLE_MUX
> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
> +
>  /*-----------------------------------------------------------------------
>   * FLASH related
>   *----------------------------------------------------------------------*/
> @@ -359,6 +362,15 @@
>         "ramdisk_addr=fc200000\0"                                       \
>         "pciconfighost=1\0"                                             \
>         "pcie_mode=RP:RP\0"                                             \
> +       "eth1addr=00:01:ec:00:f4:9d\0" \
> +       "eth2addr=00:01:ec:00:f4:9e\0" \
> +       "eth3addr=00:01:ec:00:f4:9f\0" \
> +       "ethact=ppc_4xx_eth0\0" \
> +       "ethaddr=00:01:ec:00:f4:9c\0" \
> +       "stderr=serial\0" \
> +       "stdin=serial\0" \
> +       "stdout=serial,vga\0" \
> +       "autoload=n\0" \
>         ""
>  #else /* defined(CONFIG_ARCHES) */
>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
> @@ -675,4 +687,23 @@
>  }
>  #endif
>
> +#define CONFIG_VIDEO
> +
> +#ifdef CONFIG_VIDEO
> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
> +#define CONFIG_VIDEO_VESA
> +#define VIDEO_IO_OFFSET                        0xd8000000
> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
> +#define CONFIG_VIDEO_SW_CURSOR
> +#define CONFIG_VIDEO_LOGO
> +#define CONFIG_CFB_CONSOLE
> +#define CONFIG_SPLASH_SCREEN
> +#define CONFIG_VGA_AS_SINGLE_DEVICE
> +#define CONFIG_CMD_BMP
> +#endif
> +
> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
> +#define CONFIG_CMD_TFTPPUT
> +
>  #endif /* __CONFIG_H */
> --

Could you also post the codes that actually run the vga bios on ppc
target? I may find another non-x86 board to test.

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>> NOT TO APPLY
>>
>> This shows how to enable video for the glacier board, as an example of the
>> emulator working on a VESA-compliant graphics card.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>  1 file changed, 31 insertions(+)
>>
>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>> index 7a1499d..c55e076 100644
>> --- a/include/configs/canyonlands.h
>> +++ b/include/configs/canyonlands.h
>> @@ -133,6 +133,9 @@
>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>
>> +#define CONFIG_CONSOLE_MUX
>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>> +
>>  /*-----------------------------------------------------------------------
>>   * FLASH related
>>   *----------------------------------------------------------------------*/
>> @@ -359,6 +362,15 @@
>>         "ramdisk_addr=fc200000\0"                                       \
>>         "pciconfighost=1\0"                                             \
>>         "pcie_mode=RP:RP\0"                                             \
>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>> +       "ethact=ppc_4xx_eth0\0" \
>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>> +       "stderr=serial\0" \
>> +       "stdin=serial\0" \
>> +       "stdout=serial,vga\0" \
>> +       "autoload=n\0" \
>>         ""
>>  #else /* defined(CONFIG_ARCHES) */
>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>> @@ -675,4 +687,23 @@
>>  }
>>  #endif
>>
>> +#define CONFIG_VIDEO
>> +
>> +#ifdef CONFIG_VIDEO
>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>> +#define CONFIG_VIDEO_VESA
>> +#define VIDEO_IO_OFFSET                        0xd8000000
>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>> +#define CONFIG_VIDEO_SW_CURSOR
>> +#define CONFIG_VIDEO_LOGO
>> +#define CONFIG_CFB_CONSOLE
>> +#define CONFIG_SPLASH_SCREEN
>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>> +#define CONFIG_CMD_BMP
>> +#endif
>> +
>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>> +#define CONFIG_CMD_TFTPPUT
>> +
>>  #endif /* __CONFIG_H */
>> --
>
> Could you also post the codes that actually run the vga bios on ppc
> target? I may find another non-x86 board to test.

It is all there - I am using the existing support. If you see
pci_run_vga_bios() it calls biosemu_run() in the emulation case.

Re your other question I was looking for the VGA enable bit, as I
remembered it from years ago. It doesn't seem to be needed for that
platforms I have tested. But if it is generally needed we should add
it.

For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
called. I wonder if you haven't enabled the ROM BAR? I initially got
the same result as you.

Regards,
Simon

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>> NOT TO APPLY
>>>
>>> This shows how to enable video for the glacier board, as an example of the
>>> emulator working on a VESA-compliant graphics card.
>>>
>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>> ---
>>>
>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>  1 file changed, 31 insertions(+)
>>>
>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>> index 7a1499d..c55e076 100644
>>> --- a/include/configs/canyonlands.h
>>> +++ b/include/configs/canyonlands.h
>>> @@ -133,6 +133,9 @@
>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>
>>> +#define CONFIG_CONSOLE_MUX
>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>> +
>>>  /*-----------------------------------------------------------------------
>>>   * FLASH related
>>>   *----------------------------------------------------------------------*/
>>> @@ -359,6 +362,15 @@
>>>         "ramdisk_addr=fc200000\0"                                       \
>>>         "pciconfighost=1\0"                                             \
>>>         "pcie_mode=RP:RP\0"                                             \
>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>> +       "ethact=ppc_4xx_eth0\0" \
>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>> +       "stderr=serial\0" \
>>> +       "stdin=serial\0" \
>>> +       "stdout=serial,vga\0" \
>>> +       "autoload=n\0" \
>>>         ""
>>>  #else /* defined(CONFIG_ARCHES) */
>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>> @@ -675,4 +687,23 @@
>>>  }
>>>  #endif
>>>
>>> +#define CONFIG_VIDEO
>>> +
>>> +#ifdef CONFIG_VIDEO
>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>> +#define CONFIG_VIDEO_VESA
>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>> +#define CONFIG_VIDEO_SW_CURSOR
>>> +#define CONFIG_VIDEO_LOGO
>>> +#define CONFIG_CFB_CONSOLE
>>> +#define CONFIG_SPLASH_SCREEN
>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>> +#define CONFIG_CMD_BMP
>>> +#endif
>>> +
>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>> +#define CONFIG_CMD_TFTPPUT
>>> +
>>>  #endif /* __CONFIG_H */
>>> --
>>
>> Could you also post the codes that actually run the vga bios on ppc
>> target? I may find another non-x86 board to test.
>
> It is all there - I am using the existing support. If you see
> pci_run_vga_bios() it calls biosemu_run() in the emulation case.

Sorry I mean the complete canyonlands codes which calls
pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
by chromebook_link. And do you think the int15_handler() required by
the biosemu needs to be common?

> Re your other question I was looking for the VGA enable bit, as I
> remembered it from years ago. It doesn't seem to be needed for that
> platforms I have tested. But if it is generally needed we should add
> it.

Which platform do you use? I doubt the VGA enable bit only affects x86
as it opens the A0000 and I/O address decoding which is only
applicable on x86.

> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
> called. I wonder if you haven't enabled the ROM BAR? I initially got
> the same result as you.

Yes, I called pciauto_setup_rom() in my codes. I also verified the
expansion ROM address register has bit0 set to 1 which means enabled.

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> NOT TO APPLY
>>>>
>>>> This shows how to enable video for the glacier board, as an example of the
>>>> emulator working on a VESA-compliant graphics card.
>>>>
>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>> ---
>>>>
>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>  1 file changed, 31 insertions(+)
>>>>
>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>> index 7a1499d..c55e076 100644
>>>> --- a/include/configs/canyonlands.h
>>>> +++ b/include/configs/canyonlands.h
>>>> @@ -133,6 +133,9 @@
>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>
>>>> +#define CONFIG_CONSOLE_MUX
>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>> +
>>>>  /*-----------------------------------------------------------------------
>>>>   * FLASH related
>>>>   *----------------------------------------------------------------------*/
>>>> @@ -359,6 +362,15 @@
>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>         "pciconfighost=1\0"                                             \
>>>>         "pcie_mode=RP:RP\0"                                             \
>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>> +       "stderr=serial\0" \
>>>> +       "stdin=serial\0" \
>>>> +       "stdout=serial,vga\0" \
>>>> +       "autoload=n\0" \
>>>>         ""
>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>> @@ -675,4 +687,23 @@
>>>>  }
>>>>  #endif
>>>>
>>>> +#define CONFIG_VIDEO
>>>> +
>>>> +#ifdef CONFIG_VIDEO
>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>> +#define CONFIG_VIDEO_VESA
>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>> +#define CONFIG_VIDEO_LOGO
>>>> +#define CONFIG_CFB_CONSOLE
>>>> +#define CONFIG_SPLASH_SCREEN
>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>> +#define CONFIG_CMD_BMP
>>>> +#endif
>>>> +
>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>> +#define CONFIG_CMD_TFTPPUT
>>>> +
>>>>  #endif /* __CONFIG_H */
>>>> --
>>>
>>> Could you also post the codes that actually run the vga bios on ppc
>>> target? I may find another non-x86 board to test.
>>
>> It is all there - I am using the existing support. If you see
>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>
> Sorry I mean the complete canyonlands codes which calls
> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
> by chromebook_link. And do you think the int15_handler() required by
> the biosemu needs to be common?

This series is at u-boot-x86/vesa.

You can see the call from the vesa video driver, vesa_fb.c.

Re int15_handler(), yes I think it should be, but so far I haven't needed it.

I think the ROM access code can be made more common, but I left that
task for now.

>
>> Re your other question I was looking for the VGA enable bit, as I
>> remembered it from years ago. It doesn't seem to be needed for that
>> platforms I have tested. But if it is generally needed we should add
>> it.
>
> Which platform do you use? I doubt the VGA enable bit only affects x86
> as it opens the A0000 and I/O address decoding which is only
> applicable on x86.

I'm only using glacier and link so far. I suspect there might be
something wrong as only one of my video cards works fully on glacier -
another once gives a snowy picture.

>
>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>> the same result as you.
>
> Yes, I called pciauto_setup_rom() in my codes. I also verified the
> expansion ROM address register has bit0 set to 1 which means enabled.

And you still can't see the ROM? Does the BAR give the correct ROM
size? Do you enable memory access in the command register?

Regards,
Simon

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> NOT TO APPLY
>>>>>
>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>> emulator working on a VESA-compliant graphics card.
>>>>>
>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>> ---
>>>>>
>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>  1 file changed, 31 insertions(+)
>>>>>
>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>> index 7a1499d..c55e076 100644
>>>>> --- a/include/configs/canyonlands.h
>>>>> +++ b/include/configs/canyonlands.h
>>>>> @@ -133,6 +133,9 @@
>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>
>>>>> +#define CONFIG_CONSOLE_MUX
>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>> +
>>>>>  /*-----------------------------------------------------------------------
>>>>>   * FLASH related
>>>>>   *----------------------------------------------------------------------*/
>>>>> @@ -359,6 +362,15 @@
>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>         "pciconfighost=1\0"                                             \
>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>> +       "stderr=serial\0" \
>>>>> +       "stdin=serial\0" \
>>>>> +       "stdout=serial,vga\0" \
>>>>> +       "autoload=n\0" \
>>>>>         ""
>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>> @@ -675,4 +687,23 @@
>>>>>  }
>>>>>  #endif
>>>>>
>>>>> +#define CONFIG_VIDEO
>>>>> +
>>>>> +#ifdef CONFIG_VIDEO
>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>> +#define CONFIG_VIDEO_VESA
>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>> +#define CONFIG_VIDEO_LOGO
>>>>> +#define CONFIG_CFB_CONSOLE
>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>> +#define CONFIG_CMD_BMP
>>>>> +#endif
>>>>> +
>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>> +
>>>>>  #endif /* __CONFIG_H */
>>>>> --
>>>>
>>>> Could you also post the codes that actually run the vga bios on ppc
>>>> target? I may find another non-x86 board to test.
>>>
>>> It is all there - I am using the existing support. If you see
>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>
>> Sorry I mean the complete canyonlands codes which calls
>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>> by chromebook_link. And do you think the int15_handler() required by
>> the biosemu needs to be common?
>
> This series is at u-boot-x86/vesa.
>
> You can see the call from the vesa video driver, vesa_fb.c.

Ah, I see. I can have a try on a non-x86 board.

> Re int15_handler(), yes I think it should be, but so far I haven't needed it.

So what does int15_hander() normally do? I see the vesa_fb.c provided
NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
does not pass NULL.

> I think the ROM access code can be made more common, but I left that
> task for now.
>
>>
>>> Re your other question I was looking for the VGA enable bit, as I
>>> remembered it from years ago. It doesn't seem to be needed for that
>>> platforms I have tested. But if it is generally needed we should add
>>> it.
>>
>> Which platform do you use? I doubt the VGA enable bit only affects x86
>> as it opens the A0000 and I/O address decoding which is only
>> applicable on x86.
>
> I'm only using glacier and link so far. I suspect there might be
> something wrong as only one of my video cards works fully on glacier -
> another once gives a snowy picture.

So VGA enable bit is unset on Link as well? That's interesting. When
you mentioned two cards, did you insert them simultaneously? I believe
only one card will work due to only one card will respond VGA cycles.

>>
>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>> the same result as you.
>>
>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>> expansion ROM address register has bit0 set to 1 which means enabled.
>
> And you still can't see the ROM? Does the BAR give the correct ROM
> size? Do you enable memory access in the command register?

I confirm the BAR gave the correct size and memory access in the
command register is turned on (this is by U-Boot's pci enumeration
process), but it still cannot. And finally I just figured it out the
root cause. It turns out we cannot simply add an API
pciauto_setup_rom() like this. It needs to setup the bridge's
mem_base/mem_limit register pair in order to have the bridge claim the
outbound memory window. That means calling pciauto_setup_rom()
separately from pci_run_vga_rom() will not work as it does not touch
the bridge registers. But I am wondering, why does it work on your
glacier and link board? Is that because the pci controller on glacier
and link ignore the values of mem_base/mem_limit? I don't believe it
is the case since mem_base/mem_limit behavior is defined in PCI spec.
Or this register pair on glacier and link is set up to a larger value
which happened to cover the ROM space?

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> NOT TO APPLY
>>>>>>
>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>
>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>> ---
>>>>>>
>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>  1 file changed, 31 insertions(+)
>>>>>>
>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>> index 7a1499d..c55e076 100644
>>>>>> --- a/include/configs/canyonlands.h
>>>>>> +++ b/include/configs/canyonlands.h
>>>>>> @@ -133,6 +133,9 @@
>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>
>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>> +
>>>>>>  /*-----------------------------------------------------------------------
>>>>>>   * FLASH related
>>>>>>   *----------------------------------------------------------------------*/
>>>>>> @@ -359,6 +362,15 @@
>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>> +       "stderr=serial\0" \
>>>>>> +       "stdin=serial\0" \
>>>>>> +       "stdout=serial,vga\0" \
>>>>>> +       "autoload=n\0" \
>>>>>>         ""
>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>> @@ -675,4 +687,23 @@
>>>>>>  }
>>>>>>  #endif
>>>>>>
>>>>>> +#define CONFIG_VIDEO
>>>>>> +
>>>>>> +#ifdef CONFIG_VIDEO
>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>> +#define CONFIG_CMD_BMP
>>>>>> +#endif
>>>>>> +
>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>> +
>>>>>>  #endif /* __CONFIG_H */
>>>>>> --
>>>>>
>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>> target? I may find another non-x86 board to test.
>>>>
>>>> It is all there - I am using the existing support. If you see
>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>
>>> Sorry I mean the complete canyonlands codes which calls
>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>> by chromebook_link. And do you think the int15_handler() required by
>>> the biosemu needs to be common?
>>
>> This series is at u-boot-x86/vesa.
>>
>> You can see the call from the vesa video driver, vesa_fb.c.
>
> Ah, I see. I can have a try on a non-x86 board.
>
>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>
> So what does int15_hander() normally do? I see the vesa_fb.c provided
> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
> does not pass NULL.

See the existing int15_handler() in that file. It allows selection of
output device and scaling. I doubt it matters for most boards.

>
>> I think the ROM access code can be made more common, but I left that
>> task for now.
>>
>>>
>>>> Re your other question I was looking for the VGA enable bit, as I
>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>> platforms I have tested. But if it is generally needed we should add
>>>> it.
>>>
>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>> as it opens the A0000 and I/O address decoding which is only
>>> applicable on x86.
>>
>> I'm only using glacier and link so far. I suspect there might be
>> something wrong as only one of my video cards works fully on glacier -
>> another once gives a snowy picture.
>
> So VGA enable bit is unset on Link as well? That's interesting. When
> you mentioned two cards, did you insert them simultaneously? I believe
> only one card will work due to only one card will respond VGA cycles.

No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().

I only used one card at a time.

>
>>>
>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>> the same result as you.
>>>
>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>
>> And you still can't see the ROM? Does the BAR give the correct ROM
>> size? Do you enable memory access in the command register?
>
> I confirm the BAR gave the correct size and memory access in the
> command register is turned on (this is by U-Boot's pci enumeration
> process), but it still cannot. And finally I just figured it out the
> root cause. It turns out we cannot simply add an API
> pciauto_setup_rom() like this. It needs to setup the bridge's
> mem_base/mem_limit register pair in order to have the bridge claim the
> outbound memory window. That means calling pciauto_setup_rom()
> separately from pci_run_vga_rom() will not work as it does not touch
> the bridge registers. But I am wondering, why does it work on your
> glacier and link board? Is that because the pci controller on glacier
> and link ignore the values of mem_base/mem_limit? I don't believe it
> is the case since mem_base/mem_limit behavior is defined in PCI spec.
> Or this register pair on glacier and link is set up to a larger value
> which happened to cover the ROM space?

It did not work originally, but I was keen to separate the ROM enable
from the rest of the PCI scan, because if we have a lot of ROMs we
don't want to use up lots of memory space for them. Perhaps it isn't
worth worrying about. I had problems along the lines of what you
describe, but then the problems cleared up - I'm not quite sure
exactly what happened. Yes it seems wrong to not set up the bridge
property.

There is also the VGA I/O registers which we currently emulate, but
could perhaps pass through to the card.

So do you have it working now?

Regards,
Simon

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> NOT TO APPLY
>>>>>>>
>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>
>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>> ---
>>>>>>>
>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>
>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>> index 7a1499d..c55e076 100644
>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>
>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>> +
>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>   * FLASH related
>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>> +       "stderr=serial\0" \
>>>>>>> +       "stdin=serial\0" \
>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>> +       "autoload=n\0" \
>>>>>>>         ""
>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>  }
>>>>>>>  #endif
>>>>>>>
>>>>>>> +#define CONFIG_VIDEO
>>>>>>> +
>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>> +#endif
>>>>>>> +
>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>> +
>>>>>>>  #endif /* __CONFIG_H */
>>>>>>> --
>>>>>>
>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>> target? I may find another non-x86 board to test.
>>>>>
>>>>> It is all there - I am using the existing support. If you see
>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>
>>>> Sorry I mean the complete canyonlands codes which calls
>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>> by chromebook_link. And do you think the int15_handler() required by
>>>> the biosemu needs to be common?
>>>
>>> This series is at u-boot-x86/vesa.
>>>
>>> You can see the call from the vesa video driver, vesa_fb.c.
>>
>> Ah, I see. I can have a try on a non-x86 board.
>>
>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>
>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>> does not pass NULL.
>
> See the existing int15_handler() in that file. It allows selection of
> output device and scaling. I doubt it matters for most boards.

OK, so looks we should not make this int15_handler() common.

>>
>>> I think the ROM access code can be made more common, but I left that
>>> task for now.
>>>
>>>>
>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>> platforms I have tested. But if it is generally needed we should add
>>>>> it.
>>>>
>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>> as it opens the A0000 and I/O address decoding which is only
>>>> applicable on x86.
>>>
>>> I'm only using glacier and link so far. I suspect there might be
>>> something wrong as only one of my video cards works fully on glacier -
>>> another once gives a snowy picture.
>>
>> So VGA enable bit is unset on Link as well? That's interesting. When
>> you mentioned two cards, did you insert them simultaneously? I believe
>> only one card will work due to only one card will respond VGA cycles.
>
> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().

I don't see where does this bd82x6x_pci_bus_enable_resources() get called.

> I only used one card at a time.
>
>>
>>>>
>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>> the same result as you.
>>>>
>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>
>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>> size? Do you enable memory access in the command register?
>>
>> I confirm the BAR gave the correct size and memory access in the
>> command register is turned on (this is by U-Boot's pci enumeration
>> process), but it still cannot. And finally I just figured it out the
>> root cause. It turns out we cannot simply add an API
>> pciauto_setup_rom() like this. It needs to setup the bridge's
>> mem_base/mem_limit register pair in order to have the bridge claim the
>> outbound memory window. That means calling pciauto_setup_rom()
>> separately from pci_run_vga_rom() will not work as it does not touch
>> the bridge registers. But I am wondering, why does it work on your
>> glacier and link board? Is that because the pci controller on glacier
>> and link ignore the values of mem_base/mem_limit? I don't believe it
>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>> Or this register pair on glacier and link is set up to a larger value
>> which happened to cover the ROM space?
>
> It did not work originally, but I was keen to separate the ROM enable
> from the rest of the PCI scan, because if we have a lot of ROMs we
> don't want to use up lots of memory space for them. Perhaps it isn't
> worth worrying about. I had problems along the lines of what you
> describe, but then the problems cleared up - I'm not quite sure
> exactly what happened. Yes it seems wrong to not set up the bridge
> property.

Would you rework this pci rom support? Maybe in the PCI driver model
series, that we use a device tree property (something like
'enable-rom' with a vendor id/device id pair to tell the enueration
process that when it hit a vendor id/device id that mathes the dts it
should enable the ROM and the enumeration process will automatically
set up the mem_base/mem_limit for the bridge device automatically.

> There is also the VGA I/O registers which we currently emulate, but
> could perhaps pass through to the card.

What do you mean by 'VGA I/O reigsters are emulated'?

> So do you have it working now?
>

It is still not working on my Crown Bay board. The card's VGA rom does
not execute properly. It hangs in the execution in both native mode
and biosemu mode. Looks like we may still have an issue in the real
mode stub, or the biosemu codes. Note this same video card works
correctly with the AMI commercial BIOS.

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 9 January 2015 at 20:52, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> NOT TO APPLY
>>>>>>>>
>>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>>
>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>>> index 7a1499d..c55e076 100644
>>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>>
>>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>>> +
>>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>>   * FLASH related
>>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>>> +       "stderr=serial\0" \
>>>>>>>> +       "stdin=serial\0" \
>>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>>> +       "autoload=n\0" \
>>>>>>>>         ""
>>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>>  }
>>>>>>>>  #endif
>>>>>>>>
>>>>>>>> +#define CONFIG_VIDEO
>>>>>>>> +
>>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>>> +
>>>>>>>>  #endif /* __CONFIG_H */
>>>>>>>> --
>>>>>>>
>>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>>> target? I may find another non-x86 board to test.
>>>>>>
>>>>>> It is all there - I am using the existing support. If you see
>>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>>
>>>>> Sorry I mean the complete canyonlands codes which calls
>>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>>> by chromebook_link. And do you think the int15_handler() required by
>>>>> the biosemu needs to be common?
>>>>
>>>> This series is at u-boot-x86/vesa.
>>>>
>>>> You can see the call from the vesa video driver, vesa_fb.c.
>>>
>>> Ah, I see. I can have a try on a non-x86 board.
>>>
>>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>>
>>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>>> does not pass NULL.
>>
>> See the existing int15_handler() in that file. It allows selection of
>> output device and scaling. I doubt it matters for most boards.
>
> OK, so looks we should not make this int15_handler() common.
>
>>>
>>>> I think the ROM access code can be made more common, but I left that
>>>> task for now.
>>>>
>>>>>
>>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>>> platforms I have tested. But if it is generally needed we should add
>>>>>> it.
>>>>>
>>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>>> as it opens the A0000 and I/O address decoding which is only
>>>>> applicable on x86.
>>>>
>>>> I'm only using glacier and link so far. I suspect there might be
>>>> something wrong as only one of my video cards works fully on glacier -
>>>> another once gives a snowy picture.
>>>
>>> So VGA enable bit is unset on Link as well? That's interesting. When
>>> you mentioned two cards, did you insert them simultaneously? I believe
>>> only one card will work due to only one card will respond VGA cycles.
>>
>> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().
>
> I don't see where does this bd82x6x_pci_bus_enable_resources() get called.

Actually neither do I, looks like an oversight.

>
>> I only used one card at a time.
>>
>>>
>>>>>
>>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>>> the same result as you.
>>>>>
>>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>>
>>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>>> size? Do you enable memory access in the command register?
>>>
>>> I confirm the BAR gave the correct size and memory access in the
>>> command register is turned on (this is by U-Boot's pci enumeration
>>> process), but it still cannot. And finally I just figured it out the
>>> root cause. It turns out we cannot simply add an API
>>> pciauto_setup_rom() like this. It needs to setup the bridge's
>>> mem_base/mem_limit register pair in order to have the bridge claim the
>>> outbound memory window. That means calling pciauto_setup_rom()
>>> separately from pci_run_vga_rom() will not work as it does not touch
>>> the bridge registers. But I am wondering, why does it work on your
>>> glacier and link board? Is that because the pci controller on glacier
>>> and link ignore the values of mem_base/mem_limit? I don't believe it
>>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>>> Or this register pair on glacier and link is set up to a larger value
>>> which happened to cover the ROM space?
>>
>> It did not work originally, but I was keen to separate the ROM enable
>> from the rest of the PCI scan, because if we have a lot of ROMs we
>> don't want to use up lots of memory space for them. Perhaps it isn't
>> worth worrying about. I had problems along the lines of what you
>> describe, but then the problems cleared up - I'm not quite sure
>> exactly what happened. Yes it seems wrong to not set up the bridge
>> property.
>
> Would you rework this pci rom support? Maybe in the PCI driver model
> series, that we use a device tree property (something like
> 'enable-rom' with a vendor id/device id pair to tell the enueration
> process that when it hit a vendor id/device id that mathes the dts it
> should enable the ROM and the enumeration process will automatically
> set up the mem_base/mem_limit for the bridge device automatically.

OK let's address that when I get back to it.

>
>> There is also the VGA I/O registers which we currently emulate, but
>> could perhaps pass through to the card.
>
> What do you mean by 'VGA I/O reigsters are emulated'?
>
>> So do you have it working now?
>>
>
> It is still not working on my Crown Bay board. The card's VGA rom does
> not execute properly. It hangs in the execution in both native mode
> and biosemu mode. Looks like we may still have an issue in the real
> mode stub, or the biosemu codes. Note this same video card works
> correctly with the AMI commercial BIOS.

I do have an updated BIOS emulator - there are some bugs in the
current one. I'll see if I can post a (huge) patch. That might not be
it though.

Some cards hang for ages waiting for a timer, and we don't emulate
that properly.

Regards,
Simon

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 9 January 2015 at 20:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> NOT TO APPLY
>>>>>>>>>
>>>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>>>
>>>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>>>> index 7a1499d..c55e076 100644
>>>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>>>
>>>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>>>> +
>>>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>>>   * FLASH related
>>>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>>>> +       "stderr=serial\0" \
>>>>>>>>> +       "stdin=serial\0" \
>>>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>>>> +       "autoload=n\0" \
>>>>>>>>>         ""
>>>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>>>  }
>>>>>>>>>  #endif
>>>>>>>>>
>>>>>>>>> +#define CONFIG_VIDEO
>>>>>>>>> +
>>>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>>>> +#endif
>>>>>>>>> +
>>>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>>>> +
>>>>>>>>>  #endif /* __CONFIG_H */
>>>>>>>>> --
>>>>>>>>
>>>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>>>> target? I may find another non-x86 board to test.
>>>>>>>
>>>>>>> It is all there - I am using the existing support. If you see
>>>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>>>
>>>>>> Sorry I mean the complete canyonlands codes which calls
>>>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>>>> by chromebook_link. And do you think the int15_handler() required by
>>>>>> the biosemu needs to be common?
>>>>>
>>>>> This series is at u-boot-x86/vesa.
>>>>>
>>>>> You can see the call from the vesa video driver, vesa_fb.c.
>>>>
>>>> Ah, I see. I can have a try on a non-x86 board.
>>>>
>>>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>>>
>>>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>>>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>>>> does not pass NULL.
>>>
>>> See the existing int15_handler() in that file. It allows selection of
>>> output device and scaling. I doubt it matters for most boards.
>>
>> OK, so looks we should not make this int15_handler() common.
>>
>>>>
>>>>> I think the ROM access code can be made more common, but I left that
>>>>> task for now.
>>>>>
>>>>>>
>>>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>>>> platforms I have tested. But if it is generally needed we should add
>>>>>>> it.
>>>>>>
>>>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>>>> as it opens the A0000 and I/O address decoding which is only
>>>>>> applicable on x86.
>>>>>
>>>>> I'm only using glacier and link so far. I suspect there might be
>>>>> something wrong as only one of my video cards works fully on glacier -
>>>>> another once gives a snowy picture.
>>>>
>>>> So VGA enable bit is unset on Link as well? That's interesting. When
>>>> you mentioned two cards, did you insert them simultaneously? I believe
>>>> only one card will work due to only one card will respond VGA cycles.
>>>
>>> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().
>>
>> I don't see where does this bd82x6x_pci_bus_enable_resources() get called.
>
> Actually neither do I, looks like an oversight.

Ah, that's really interesting. So that means on the Link board the VGA
enable bit (on Ivybridge PCH chipset) does not matter but the VGA card
does work.

>>
>>> I only used one card at a time.
>>>
>>>>
>>>>>>
>>>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>>>> the same result as you.
>>>>>>
>>>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>>>
>>>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>>>> size? Do you enable memory access in the command register?
>>>>
>>>> I confirm the BAR gave the correct size and memory access in the
>>>> command register is turned on (this is by U-Boot's pci enumeration
>>>> process), but it still cannot. And finally I just figured it out the
>>>> root cause. It turns out we cannot simply add an API
>>>> pciauto_setup_rom() like this. It needs to setup the bridge's
>>>> mem_base/mem_limit register pair in order to have the bridge claim the
>>>> outbound memory window. That means calling pciauto_setup_rom()
>>>> separately from pci_run_vga_rom() will not work as it does not touch
>>>> the bridge registers. But I am wondering, why does it work on your
>>>> glacier and link board? Is that because the pci controller on glacier
>>>> and link ignore the values of mem_base/mem_limit? I don't believe it
>>>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>>>> Or this register pair on glacier and link is set up to a larger value
>>>> which happened to cover the ROM space?
>>>
>>> It did not work originally, but I was keen to separate the ROM enable
>>> from the rest of the PCI scan, because if we have a lot of ROMs we
>>> don't want to use up lots of memory space for them. Perhaps it isn't
>>> worth worrying about. I had problems along the lines of what you
>>> describe, but then the problems cleared up - I'm not quite sure
>>> exactly what happened. Yes it seems wrong to not set up the bridge
>>> property.
>>
>> Would you rework this pci rom support? Maybe in the PCI driver model
>> series, that we use a device tree property (something like
>> 'enable-rom' with a vendor id/device id pair to tell the enueration
>> process that when it hit a vendor id/device id that mathes the dts it
>> should enable the ROM and the enumeration process will automatically
>> set up the mem_base/mem_limit for the bridge device automatically.
>
> OK let's address that when I get back to it.
>

Sounds good. I know Freescale PCI/PCIe controller has a separate
register (not in configuration space) which controls the outbound
window base/size which covers the memory-mapped registers and ROM
space. If you get a card directly connected to the host controller,
current way in your patch series will work. This is due to the
controller ignores the mem_base/mem_limit settings and I would call
this an implementation specific behavior. However as for as I see most
standard bridge chipsets (like PLX series bridges) implement this
correctly per the PCI spec. And I believe Intel's chipset also
implements this per spec. That's why I see this does not work on
Tunnel Creek. I suspect on canyonlands board the PCI host controller
has something similar to the Freescale one and your video card is
directly connected to the host controller so that you can get it work.
But what I don't understand is you get it work on Link which is an x86
board.

>>
>>> There is also the VGA I/O registers which we currently emulate, but
>>> could perhaps pass through to the card.
>>
>> What do you mean by 'VGA I/O reigsters are emulated'?
>>

So I am still wondering what is the emulation you talked about?

>>> So do you have it working now?
>>>
>>
>> It is still not working on my Crown Bay board. The card's VGA rom does
>> not execute properly. It hangs in the execution in both native mode
>> and biosemu mode. Looks like we may still have an issue in the real
>> mode stub, or the biosemu codes. Note this same video card works
>> correctly with the AMI commercial BIOS.
>
> I do have an updated BIOS emulator - there are some bugs in the
> current one. I'll see if I can post a (huge) patch. That might not be
> it though.
>
> Some cards hang for ages waiting for a timer, and we don't emulate
> that properly.
>

Could you elaborate more on this timer issue? Looks it affects both
native and emulation modes. I will see if I can get a fix. Right now I
don't have a clue and am stuck. I have to find another video card to
test this series.

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 10 January 2015 at 20:04, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 9 January 2015 at 20:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> NOT TO APPLY
>>>>>>>>>>
>>>>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>>>>> index 7a1499d..c55e076 100644
>>>>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>>>>
>>>>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>>>>> +
>>>>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>>>>   * FLASH related
>>>>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>>>>> +       "stderr=serial\0" \
>>>>>>>>>> +       "stdin=serial\0" \
>>>>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>>>>> +       "autoload=n\0" \
>>>>>>>>>>         ""
>>>>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>>>>  }
>>>>>>>>>>  #endif
>>>>>>>>>>
>>>>>>>>>> +#define CONFIG_VIDEO
>>>>>>>>>> +
>>>>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>>>>> +#endif
>>>>>>>>>> +
>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>>>>> +
>>>>>>>>>>  #endif /* __CONFIG_H */
>>>>>>>>>> --
>>>>>>>>>
>>>>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>>>>> target? I may find another non-x86 board to test.
>>>>>>>>
>>>>>>>> It is all there - I am using the existing support. If you see
>>>>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>>>>
>>>>>>> Sorry I mean the complete canyonlands codes which calls
>>>>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>>>>> by chromebook_link. And do you think the int15_handler() required by
>>>>>>> the biosemu needs to be common?
>>>>>>
>>>>>> This series is at u-boot-x86/vesa.
>>>>>>
>>>>>> You can see the call from the vesa video driver, vesa_fb.c.
>>>>>
>>>>> Ah, I see. I can have a try on a non-x86 board.
>>>>>
>>>>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>>>>
>>>>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>>>>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>>>>> does not pass NULL.
>>>>
>>>> See the existing int15_handler() in that file. It allows selection of
>>>> output device and scaling. I doubt it matters for most boards.
>>>
>>> OK, so looks we should not make this int15_handler() common.
>>>
>>>>>
>>>>>> I think the ROM access code can be made more common, but I left that
>>>>>> task for now.
>>>>>>
>>>>>>>
>>>>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>>>>> platforms I have tested. But if it is generally needed we should add
>>>>>>>> it.
>>>>>>>
>>>>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>>>>> as it opens the A0000 and I/O address decoding which is only
>>>>>>> applicable on x86.
>>>>>>
>>>>>> I'm only using glacier and link so far. I suspect there might be
>>>>>> something wrong as only one of my video cards works fully on glacier -
>>>>>> another once gives a snowy picture.
>>>>>
>>>>> So VGA enable bit is unset on Link as well? That's interesting. When
>>>>> you mentioned two cards, did you insert them simultaneously? I believe
>>>>> only one card will work due to only one card will respond VGA cycles.
>>>>
>>>> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().
>>>
>>> I don't see where does this bd82x6x_pci_bus_enable_resources() get called.
>>
>> Actually neither do I, looks like an oversight.
>
> Ah, that's really interesting. So that means on the Link board the VGA
> enable bit (on Ivybridge PCH chipset) does not matter but the VGA card
> does work.

Well one point is that we don't have the frame buffer at 0xa0000. I'm
not sure we care what is there.

>
>>>
>>>> I only used one card at a time.
>>>>
>>>>>
>>>>>>>
>>>>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>>>>> the same result as you.
>>>>>>>
>>>>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>>>>
>>>>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>>>>> size? Do you enable memory access in the command register?
>>>>>
>>>>> I confirm the BAR gave the correct size and memory access in the
>>>>> command register is turned on (this is by U-Boot's pci enumeration
>>>>> process), but it still cannot. And finally I just figured it out the
>>>>> root cause. It turns out we cannot simply add an API
>>>>> pciauto_setup_rom() like this. It needs to setup the bridge's
>>>>> mem_base/mem_limit register pair in order to have the bridge claim the
>>>>> outbound memory window. That means calling pciauto_setup_rom()
>>>>> separately from pci_run_vga_rom() will not work as it does not touch
>>>>> the bridge registers. But I am wondering, why does it work on your
>>>>> glacier and link board? Is that because the pci controller on glacier
>>>>> and link ignore the values of mem_base/mem_limit? I don't believe it
>>>>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>>>>> Or this register pair on glacier and link is set up to a larger value
>>>>> which happened to cover the ROM space?
>>>>
>>>> It did not work originally, but I was keen to separate the ROM enable
>>>> from the rest of the PCI scan, because if we have a lot of ROMs we
>>>> don't want to use up lots of memory space for them. Perhaps it isn't
>>>> worth worrying about. I had problems along the lines of what you
>>>> describe, but then the problems cleared up - I'm not quite sure
>>>> exactly what happened. Yes it seems wrong to not set up the bridge
>>>> property.
>>>
>>> Would you rework this pci rom support? Maybe in the PCI driver model
>>> series, that we use a device tree property (something like
>>> 'enable-rom' with a vendor id/device id pair to tell the enueration
>>> process that when it hit a vendor id/device id that mathes the dts it
>>> should enable the ROM and the enumeration process will automatically
>>> set up the mem_base/mem_limit for the bridge device automatically.
>>
>> OK let's address that when I get back to it.
>>
>
> Sounds good. I know Freescale PCI/PCIe controller has a separate
> register (not in configuration space) which controls the outbound
> window base/size which covers the memory-mapped registers and ROM
> space. If you get a card directly connected to the host controller,
> current way in your patch series will work. This is due to the
> controller ignores the mem_base/mem_limit settings and I would call
> this an implementation specific behavior. However as for as I see most
> standard bridge chipsets (like PLX series bridges) implement this
> correctly per the PCI spec. And I believe Intel's chipset also
> implements this per spec. That's why I see this does not work on
> Tunnel Creek. I suspect on canyonlands board the PCI host controller
> has something similar to the Freescale one and your video card is
> directly connected to the host controller so that you can get it work.
> But what I don't understand is you get it work on Link which is an x86
> board.

Well if we don't access VGA registers and don't access (<1MB) VGA
memory then perhaps it doesn't matter?

>
>>>
>>>> There is also the VGA I/O registers which we currently emulate, but
>>>> could perhaps pass through to the card.
>>>
>>> What do you mean by 'VGA I/O reigsters are emulated'?
>>>
>
> So I am still wondering what is the emulation you talked about?

See VGA_inpb() for example.

>
>>>> So do you have it working now?
>>>>
>>>
>>> It is still not working on my Crown Bay board. The card's VGA rom does
>>> not execute properly. It hangs in the execution in both native mode
>>> and biosemu mode. Looks like we may still have an issue in the real
>>> mode stub, or the biosemu codes. Note this same video card works
>>> correctly with the AMI commercial BIOS.
>>
>> I do have an updated BIOS emulator - there are some bugs in the
>> current one. I'll see if I can post a (huge) patch. That might not be
>> it though.
>>
>> Some cards hang for ages waiting for a timer, and we don't emulate
>> that properly.
>>
>
> Could you elaborate more on this timer issue? Looks it affects both
> native and emulation modes. I will see if I can get a fix. Right now I
> don't have a clue and am stuck. I have to find another video card to
> test this series.

It should not affect native execution because the timer is correctly
set up in that case and does not need emulating.

There might be something else that the card needs to work.

In my case I tried several cards. This is the only one that worked perfectly:

http://www.amazon.com/gp/product/B003S746S4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

Regards,
Simon

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Bin Meng]

Hi Simon,

On Sun, Jan 11, 2015 at 11:42 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 10 January 2015 at 20:04, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Simon,
>>
>> On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <sjg@chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 9 January 2015 at 20:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>> Hi Bin,
>>>>>
>>>>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>> Hi Bin,
>>>>>>>
>>>>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>> Hi Simon,
>>>>>>>>
>>>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>> Hi Bin,
>>>>>>>>>
>>>>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>> Hi Simon,
>>>>>>>>>>
>>>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>> NOT TO APPLY
>>>>>>>>>>>
>>>>>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>>>>>> index 7a1499d..c55e076 100644
>>>>>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>>>>>
>>>>>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>>>>>> +
>>>>>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>>>>>   * FLASH related
>>>>>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>>>>>> +       "stderr=serial\0" \
>>>>>>>>>>> +       "stdin=serial\0" \
>>>>>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>>>>>> +       "autoload=n\0" \
>>>>>>>>>>>         ""
>>>>>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>>>>>  }
>>>>>>>>>>>  #endif
>>>>>>>>>>>
>>>>>>>>>>> +#define CONFIG_VIDEO
>>>>>>>>>>> +
>>>>>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>>>>>> +#endif
>>>>>>>>>>> +
>>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>>>>>> +
>>>>>>>>>>>  #endif /* __CONFIG_H */
>>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>>>>>> target? I may find another non-x86 board to test.
>>>>>>>>>
>>>>>>>>> It is all there - I am using the existing support. If you see
>>>>>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>>>>>
>>>>>>>> Sorry I mean the complete canyonlands codes which calls
>>>>>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>>>>>> by chromebook_link. And do you think the int15_handler() required by
>>>>>>>> the biosemu needs to be common?
>>>>>>>
>>>>>>> This series is at u-boot-x86/vesa.
>>>>>>>
>>>>>>> You can see the call from the vesa video driver, vesa_fb.c.
>>>>>>
>>>>>> Ah, I see. I can have a try on a non-x86 board.
>>>>>>
>>>>>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>>>>>
>>>>>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>>>>>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>>>>>> does not pass NULL.
>>>>>
>>>>> See the existing int15_handler() in that file. It allows selection of
>>>>> output device and scaling. I doubt it matters for most boards.
>>>>
>>>> OK, so looks we should not make this int15_handler() common.
>>>>
>>>>>>
>>>>>>> I think the ROM access code can be made more common, but I left that
>>>>>>> task for now.
>>>>>>>
>>>>>>>>
>>>>>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>>>>>> platforms I have tested. But if it is generally needed we should add
>>>>>>>>> it.
>>>>>>>>
>>>>>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>>>>>> as it opens the A0000 and I/O address decoding which is only
>>>>>>>> applicable on x86.
>>>>>>>
>>>>>>> I'm only using glacier and link so far. I suspect there might be
>>>>>>> something wrong as only one of my video cards works fully on glacier -
>>>>>>> another once gives a snowy picture.
>>>>>>
>>>>>> So VGA enable bit is unset on Link as well? That's interesting. When
>>>>>> you mentioned two cards, did you insert them simultaneously? I believe
>>>>>> only one card will work due to only one card will respond VGA cycles.
>>>>>
>>>>> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().
>>>>
>>>> I don't see where does this bd82x6x_pci_bus_enable_resources() get called.
>>>
>>> Actually neither do I, looks like an oversight.
>>
>> Ah, that's really interesting. So that means on the Link board the VGA
>> enable bit (on Ivybridge PCH chipset) does not matter but the VGA card
>> does work.
>
> Well one point is that we don't have the frame buffer at 0xa0000. I'm
> not sure we care what is there.

Is the frame buffer address at 0xa0000 in the native mode?

>>
>>>>
>>>>> I only used one card at a time.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>>>>>> the same result as you.
>>>>>>>>
>>>>>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>>>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>>>>>
>>>>>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>>>>>> size? Do you enable memory access in the command register?
>>>>>>
>>>>>> I confirm the BAR gave the correct size and memory access in the
>>>>>> command register is turned on (this is by U-Boot's pci enumeration
>>>>>> process), but it still cannot. And finally I just figured it out the
>>>>>> root cause. It turns out we cannot simply add an API
>>>>>> pciauto_setup_rom() like this. It needs to setup the bridge's
>>>>>> mem_base/mem_limit register pair in order to have the bridge claim the
>>>>>> outbound memory window. That means calling pciauto_setup_rom()
>>>>>> separately from pci_run_vga_rom() will not work as it does not touch
>>>>>> the bridge registers. But I am wondering, why does it work on your
>>>>>> glacier and link board? Is that because the pci controller on glacier
>>>>>> and link ignore the values of mem_base/mem_limit? I don't believe it
>>>>>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>>>>>> Or this register pair on glacier and link is set up to a larger value
>>>>>> which happened to cover the ROM space?
>>>>>
>>>>> It did not work originally, but I was keen to separate the ROM enable
>>>>> from the rest of the PCI scan, because if we have a lot of ROMs we
>>>>> don't want to use up lots of memory space for them. Perhaps it isn't
>>>>> worth worrying about. I had problems along the lines of what you
>>>>> describe, but then the problems cleared up - I'm not quite sure
>>>>> exactly what happened. Yes it seems wrong to not set up the bridge
>>>>> property.
>>>>
>>>> Would you rework this pci rom support? Maybe in the PCI driver model
>>>> series, that we use a device tree property (something like
>>>> 'enable-rom' with a vendor id/device id pair to tell the enueration
>>>> process that when it hit a vendor id/device id that mathes the dts it
>>>> should enable the ROM and the enumeration process will automatically
>>>> set up the mem_base/mem_limit for the bridge device automatically.
>>>
>>> OK let's address that when I get back to it.
>>>
>>
>> Sounds good. I know Freescale PCI/PCIe controller has a separate
>> register (not in configuration space) which controls the outbound
>> window base/size which covers the memory-mapped registers and ROM
>> space. If you get a card directly connected to the host controller,
>> current way in your patch series will work. This is due to the
>> controller ignores the mem_base/mem_limit settings and I would call
>> this an implementation specific behavior. However as for as I see most
>> standard bridge chipsets (like PLX series bridges) implement this
>> correctly per the PCI spec. And I believe Intel's chipset also
>> implements this per spec. That's why I see this does not work on
>> Tunnel Creek. I suspect on canyonlands board the PCI host controller
>> has something similar to the Freescale one and your video card is
>> directly connected to the host controller so that you can get it work.
>> But what I don't understand is you get it work on Link which is an x86
>> board.
>
> Well if we don't access VGA registers and don't access (<1MB) VGA
> memory then perhaps it doesn't matter?

No, what I described above (mem_base/mem_limit) is about PCI ROMs. I
am curious that how you can access to the PCI ROM on Canyonlands and
Link and I suspect Canyonlands may have something similar to
Freescale's implementation and your video card is directly connected
to the host controller (no bridge chipset between them). But I still
don't understnad the Link since it is x86 and Intel chipset.

>>
>>>>
>>>>> There is also the VGA I/O registers which we currently emulate, but
>>>>> could perhaps pass through to the card.
>>>>
>>>> What do you mean by 'VGA I/O reigsters are emulated'?
>>>>
>>
>> So I am still wondering what is the emulation you talked about?
>
> See VGA_inpb() for example.

Thanks. I see this is for biosemu mode. What about native mode?

>>
>>>>> So do you have it working now?
>>>>>
>>>>
>>>> It is still not working on my Crown Bay board. The card's VGA rom does
>>>> not execute properly. It hangs in the execution in both native mode
>>>> and biosemu mode. Looks like we may still have an issue in the real
>>>> mode stub, or the biosemu codes. Note this same video card works
>>>> correctly with the AMI commercial BIOS.
>>>
>>> I do have an updated BIOS emulator - there are some bugs in the
>>> current one. I'll see if I can post a (huge) patch. That might not be
>>> it though.
>>>
>>> Some cards hang for ages waiting for a timer, and we don't emulate
>>> that properly.
>>>
>>
>> Could you elaborate more on this timer issue? Looks it affects both
>> native and emulation modes. I will see if I can get a fix. Right now I
>> don't have a clue and am stuck. I have to find another video card to
>> test this series.
>
> It should not affect native execution because the timer is correctly
> set up in that case and does not need emulating.
>
> There might be something else that the card needs to work.
>
> In my case I tried several cards. This is the only one that worked perfectly:
>
> http://www.amazon.com/gp/product/B003S746S4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
>

Thanks for the info. I will try to find another card to test.

Regards,
Bin

[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support

[Simon Glass]

Hi Bin,

On 10 January 2015 at 20:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Sun, Jan 11, 2015 at 11:42 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 10 January 2015 at 20:04, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Hi Simon,
>>>
>>> On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <sjg@chromium.org> wrote:
>>>> Hi Bin,
>>>>
>>>> On 9 January 2015 at 20:52, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>> Hi Simon,
>>>>>
>>>>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>> Hi Bin,
>>>>>>
>>>>>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>> Hi Simon,
>>>>>>>
>>>>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>> Hi Bin,
>>>>>>>>
>>>>>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>> Hi Simon,
>>>>>>>>>
>>>>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>> Hi Bin,
>>>>>>>>>>
>>>>>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>>>>>> Hi Simon,
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg@chromium.org> wrote:
>>>>>>>>>>>> NOT TO APPLY
>>>>>>>>>>>>
>>>>>>>>>>>> This shows how to enable video for the glacier board, as an example of the
>>>>>>>>>>>> emulator working on a VESA-compliant graphics card.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>>  include/configs/canyonlands.h | 31 +++++++++++++++++++++++++++++++
>>>>>>>>>>>>  1 file changed, 31 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
>>>>>>>>>>>> index 7a1499d..c55e076 100644
>>>>>>>>>>>> --- a/include/configs/canyonlands.h
>>>>>>>>>>>> +++ b/include/configs/canyonlands.h
>>>>>>>>>>>> @@ -133,6 +133,9 @@
>>>>>>>>>>>>  #define CONFIG_SYS_NOR_CS              0       /* NOR chip connected to CSx */
>>>>>>>>>>>>  #define CONFIG_SYS_NAND_CS             3       /* NAND chip connected to CSx */
>>>>>>>>>>>>
>>>>>>>>>>>> +#define CONFIG_CONSOLE_MUX
>>>>>>>>>>>> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV
>>>>>>>>>>>> +
>>>>>>>>>>>>  /*-----------------------------------------------------------------------
>>>>>>>>>>>>   * FLASH related
>>>>>>>>>>>>   *----------------------------------------------------------------------*/
>>>>>>>>>>>> @@ -359,6 +362,15 @@
>>>>>>>>>>>>         "ramdisk_addr=fc200000\0"                                       \
>>>>>>>>>>>>         "pciconfighost=1\0"                                             \
>>>>>>>>>>>>         "pcie_mode=RP:RP\0"                                             \
>>>>>>>>>>>> +       "eth1addr=00:01:ec:00:f4:9d\0" \
>>>>>>>>>>>> +       "eth2addr=00:01:ec:00:f4:9e\0" \
>>>>>>>>>>>> +       "eth3addr=00:01:ec:00:f4:9f\0" \
>>>>>>>>>>>> +       "ethact=ppc_4xx_eth0\0" \
>>>>>>>>>>>> +       "ethaddr=00:01:ec:00:f4:9c\0" \
>>>>>>>>>>>> +       "stderr=serial\0" \
>>>>>>>>>>>> +       "stdin=serial\0" \
>>>>>>>>>>>> +       "stdout=serial,vga\0" \
>>>>>>>>>>>> +       "autoload=n\0" \
>>>>>>>>>>>>         ""
>>>>>>>>>>>>  #else /* defined(CONFIG_ARCHES) */
>>>>>>>>>>>>  #define CONFIG_EXTRA_ENV_SETTINGS                                      \
>>>>>>>>>>>> @@ -675,4 +687,23 @@
>>>>>>>>>>>>  }
>>>>>>>>>>>>  #endif
>>>>>>>>>>>>
>>>>>>>>>>>> +#define CONFIG_VIDEO
>>>>>>>>>>>> +
>>>>>>>>>>>> +#ifdef CONFIG_VIDEO
>>>>>>>>>>>> +#define CONFIG_BIOSEMU                 /* x86 bios emulator for vga bios */
>>>>>>>>>>>> +#define CONFIG_VIDEO_VESA
>>>>>>>>>>>> +#define VIDEO_IO_OFFSET                        0xd8000000
>>>>>>>>>>>> +#define CONFIG_SYS_ISA_IO_BASE_ADDRESS         VIDEO_IO_OFFSET
>>>>>>>>>>>> +#define CONFIG_VIDEO_SW_CURSOR
>>>>>>>>>>>> +#define CONFIG_VIDEO_LOGO
>>>>>>>>>>>> +#define CONFIG_CFB_CONSOLE
>>>>>>>>>>>> +#define CONFIG_SPLASH_SCREEN
>>>>>>>>>>>> +#define CONFIG_VGA_AS_SINGLE_DEVICE
>>>>>>>>>>>> +#define CONFIG_CMD_BMP
>>>>>>>>>>>> +#endif
>>>>>>>>>>>> +
>>>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_SET_VESA_MODE
>>>>>>>>>>>> +#define CONFIG_FRAMEBUFFER_VESA_MODE   0x114
>>>>>>>>>>>> +#define CONFIG_CMD_TFTPPUT
>>>>>>>>>>>> +
>>>>>>>>>>>>  #endif /* __CONFIG_H */
>>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>> Could you also post the codes that actually run the vga bios on ppc
>>>>>>>>>>> target? I may find another non-x86 board to test.
>>>>>>>>>>
>>>>>>>>>> It is all there - I am using the existing support. If you see
>>>>>>>>>> pci_run_vga_bios() it calls biosemu_run() in the emulation case.
>>>>>>>>>
>>>>>>>>> Sorry I mean the complete canyonlands codes which calls
>>>>>>>>> pci_run_vga_bios(). I see currently pci_run_vga_bios() is only called
>>>>>>>>> by chromebook_link. And do you think the int15_handler() required by
>>>>>>>>> the biosemu needs to be common?
>>>>>>>>
>>>>>>>> This series is at u-boot-x86/vesa.
>>>>>>>>
>>>>>>>> You can see the call from the vesa video driver, vesa_fb.c.
>>>>>>>
>>>>>>> Ah, I see. I can have a try on a non-x86 board.
>>>>>>>
>>>>>>>> Re int15_handler(), yes I think it should be, but so far I haven't needed it.
>>>>>>>
>>>>>>> So what does int15_hander() normally do? I see the vesa_fb.c provided
>>>>>>> NULL for int15_handler, but the call in arch/x86/cpu/ivybridge/gma.c
>>>>>>> does not pass NULL.
>>>>>>
>>>>>> See the existing int15_handler() in that file. It allows selection of
>>>>>> output device and scaling. I doubt it matters for most boards.
>>>>>
>>>>> OK, so looks we should not make this int15_handler() common.
>>>>>
>>>>>>>
>>>>>>>> I think the ROM access code can be made more common, but I left that
>>>>>>>> task for now.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Re your other question I was looking for the VGA enable bit, as I
>>>>>>>>>> remembered it from years ago. It doesn't seem to be needed for that
>>>>>>>>>> platforms I have tested. But if it is generally needed we should add
>>>>>>>>>> it.
>>>>>>>>>
>>>>>>>>> Which platform do you use? I doubt the VGA enable bit only affects x86
>>>>>>>>> as it opens the A0000 and I/O address decoding which is only
>>>>>>>>> applicable on x86.
>>>>>>>>
>>>>>>>> I'm only using glacier and link so far. I suspect there might be
>>>>>>>> something wrong as only one of my video cards works fully on glacier -
>>>>>>>> another once gives a snowy picture.
>>>>>>>
>>>>>>> So VGA enable bit is unset on Link as well? That's interesting. When
>>>>>>> you mentioned two cards, did you insert them simultaneously? I believe
>>>>>>> only one card will work due to only one card will respond VGA cycles.
>>>>>>
>>>>>> No it's set on Link I believe - see bd82x6x_pci_bus_enable_resources().
>>>>>
>>>>> I don't see where does this bd82x6x_pci_bus_enable_resources() get called.
>>>>
>>>> Actually neither do I, looks like an oversight.
>>>
>>> Ah, that's really interesting. So that means on the Link board the VGA
>>> enable bit (on Ivybridge PCH chipset) does not matter but the VGA card
>>> does work.
>>
>> Well one point is that we don't have the frame buffer at 0xa0000. I'm
>> not sure we care what is there.
>
> Is the frame buffer address at 0xa0000 in the native mode?

My understanding is that it is at 0xd0000000 in native mode.

>
>>>
>>>>>
>>>>>> I only used one card at a time.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>>> For the ROM, pci_rom_load() works for me, after pciauto_setup_rom() is
>>>>>>>>>> called. I wonder if you haven't enabled the ROM BAR? I initially got
>>>>>>>>>> the same result as you.
>>>>>>>>>
>>>>>>>>> Yes, I called pciauto_setup_rom() in my codes. I also verified the
>>>>>>>>> expansion ROM address register has bit0 set to 1 which means enabled.
>>>>>>>>
>>>>>>>> And you still can't see the ROM? Does the BAR give the correct ROM
>>>>>>>> size? Do you enable memory access in the command register?
>>>>>>>
>>>>>>> I confirm the BAR gave the correct size and memory access in the
>>>>>>> command register is turned on (this is by U-Boot's pci enumeration
>>>>>>> process), but it still cannot. And finally I just figured it out the
>>>>>>> root cause. It turns out we cannot simply add an API
>>>>>>> pciauto_setup_rom() like this. It needs to setup the bridge's
>>>>>>> mem_base/mem_limit register pair in order to have the bridge claim the
>>>>>>> outbound memory window. That means calling pciauto_setup_rom()
>>>>>>> separately from pci_run_vga_rom() will not work as it does not touch
>>>>>>> the bridge registers. But I am wondering, why does it work on your
>>>>>>> glacier and link board? Is that because the pci controller on glacier
>>>>>>> and link ignore the values of mem_base/mem_limit? I don't believe it
>>>>>>> is the case since mem_base/mem_limit behavior is defined in PCI spec.
>>>>>>> Or this register pair on glacier and link is set up to a larger value
>>>>>>> which happened to cover the ROM space?
>>>>>>
>>>>>> It did not work originally, but I was keen to separate the ROM enable
>>>>>> from the rest of the PCI scan, because if we have a lot of ROMs we
>>>>>> don't want to use up lots of memory space for them. Perhaps it isn't
>>>>>> worth worrying about. I had problems along the lines of what you
>>>>>> describe, but then the problems cleared up - I'm not quite sure
>>>>>> exactly what happened. Yes it seems wrong to not set up the bridge
>>>>>> property.
>>>>>
>>>>> Would you rework this pci rom support? Maybe in the PCI driver model
>>>>> series, that we use a device tree property (something like
>>>>> 'enable-rom' with a vendor id/device id pair to tell the enueration
>>>>> process that when it hit a vendor id/device id that mathes the dts it
>>>>> should enable the ROM and the enumeration process will automatically
>>>>> set up the mem_base/mem_limit for the bridge device automatically.
>>>>
>>>> OK let's address that when I get back to it.
>>>>
>>>
>>> Sounds good. I know Freescale PCI/PCIe controller has a separate
>>> register (not in configuration space) which controls the outbound
>>> window base/size which covers the memory-mapped registers and ROM
>>> space. If you get a card directly connected to the host controller,
>>> current way in your patch series will work. This is due to the
>>> controller ignores the mem_base/mem_limit settings and I would call
>>> this an implementation specific behavior. However as for as I see most
>>> standard bridge chipsets (like PLX series bridges) implement this
>>> correctly per the PCI spec. And I believe Intel's chipset also
>>> implements this per spec. That's why I see this does not work on
>>> Tunnel Creek. I suspect on canyonlands board the PCI host controller
>>> has something similar to the Freescale one and your video card is
>>> directly connected to the host controller so that you can get it work.
>>> But what I don't understand is you get it work on Link which is an x86
>>> board.
>>
>> Well if we don't access VGA registers and don't access (<1MB) VGA
>> memory then perhaps it doesn't matter?
>
> No, what I described above (mem_base/mem_limit) is about PCI ROMs. I
> am curious that how you can access to the PCI ROM on Canyonlands and
> Link and I suspect Canyonlands may have something similar to
> Freescale's implementation and your video card is directly connected
> to the host controller (no bridge chipset between them). But I still
> don't understnad the Link since it is x86 and Intel chipset.

On link we get the ROM from the main ROM rather than the video card.
That is controlled by CONFIG_X86_OPTION_ROM_ADDR.

>
>>>
>>>>>
>>>>>> There is also the VGA I/O registers which we currently emulate, but
>>>>>> could perhaps pass through to the card.
>>>>>
>>>>> What do you mean by 'VGA I/O reigsters are emulated'?
>>>>>
>>>
>>> So I am still wondering what is the emulation you talked about?
>>
>> See VGA_inpb() for example.
>
> Thanks. I see this is for biosemu mode. What about native mode?

In that case we can emulate VGA but we don't need to, so we don't. I
think I did try it out and it didn't seem to make any difference.

>
>>>
>>>>>> So do you have it working now?
>>>>>>
>>>>>
>>>>> It is still not working on my Crown Bay board. The card's VGA rom does
>>>>> not execute properly. It hangs in the execution in both native mode
>>>>> and biosemu mode. Looks like we may still have an issue in the real
>>>>> mode stub, or the biosemu codes. Note this same video card works
>>>>> correctly with the AMI commercial BIOS.
>>>>
>>>> I do have an updated BIOS emulator - there are some bugs in the
>>>> current one. I'll see if I can post a (huge) patch. That might not be
>>>> it though.
>>>>
>>>> Some cards hang for ages waiting for a timer, and we don't emulate
>>>> that properly.
>>>>
>>>
>>> Could you elaborate more on this timer issue? Looks it affects both
>>> native and emulation modes. I will see if I can get a fix. Right now I
>>> don't have a clue and am stuck. I have to find another video card to
>>> test this series.
>>
>> It should not affect native execution because the timer is correctly
>> set up in that case and does not need emulating.
>>
>> There might be something else that the card needs to work.
>>
>> In my case I tried several cards. This is the only one that worked perfectly:
>>
>> http://www.amazon.com/gp/product/B003S746S4/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1
>>
>
> Thanks for the info. I will try to find another card to test.

Good luck :-)

Regards,
Simon