[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Bin Meng
bmeng.cn at gmail.com
Sun Jan 11 05:20:08 CET 2015
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?
>>
>>>>
>>>>> 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
More information about the U-Boot
mailing list