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