[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Bin Meng
bmeng.cn at gmail.com
Fri Jan 9 06:23:02 CET 2015
Hi Simon,
On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 8 January 2015 at 18:34, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 7 January 2015 at 23:18, Bin Meng <bmeng.cn at gmail.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <sjg at 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 at 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
More information about the U-Boot
mailing list