[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Simon Glass
sjg at chromium.org
Sat Jan 10 17:08:09 CET 2015
Hi Bin,
On 9 January 2015 at 20:52, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Simon,
>
> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Bin,
>>
>> On 8 January 2015 at 22:23, Bin Meng <bmeng.cn at gmail.com> wrote:
>>> 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.
>>
>> 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
More information about the U-Boot
mailing list