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

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(+)

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

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

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

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

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

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

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

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

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