[U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support
Bin Meng
bmeng.cn at gmail.com
Sat Jan 10 04:52:35 CET 2015
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.
> 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.
> 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.
Regards,
Bin
More information about the U-Boot
mailing list