[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Bin Meng
bmeng.cn at gmail.com
Sun Jan 11 04:04:54 CET 2015
Hi Simon,
On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <sjg at chromium.org> wrote:
> 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.
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
More information about the U-Boot
mailing list