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

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

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);

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

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

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

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

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

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

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

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...

Regards, Simon

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...

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

Good luck :-)

Regards, Simon