From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Glass Date: Mon, 12 Jan 2015 17:11:29 -0800 Subject: [U-Boot] [PATCH 10/10] RFC: Test code for glacier PCI video support In-Reply-To: References: <1419906751-29776-1-git-send-email-sjg@chromium.org> <1419906751-29776-11-git-send-email-sjg@chromium.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Bin, On 10 January 2015 at 20:20, Bin Meng wrote: > Hi Simon, > > On Sun, Jan 11, 2015 at 11:42 AM, Simon Glass wrote: >> Hi Bin, >> >> On 10 January 2015 at 20:04, Bin Meng wrote: >>> Hi Simon, >>> >>> On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass wrote: >>>> Hi Bin, >>>> >>>> On 9 January 2015 at 20:52, Bin Meng wrote: >>>>> Hi Simon, >>>>> >>>>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass wrote: >>>>>> Hi Bin, >>>>>> >>>>>> On 8 January 2015 at 22:23, Bin Meng wrote: >>>>>>> Hi Simon, >>>>>>> >>>>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass wrote: >>>>>>>> Hi Bin, >>>>>>>> >>>>>>>> On 8 January 2015 at 18:34, Bin Meng wrote: >>>>>>>>> Hi Simon, >>>>>>>>> >>>>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass wrote: >>>>>>>>>> Hi Bin, >>>>>>>>>> >>>>>>>>>> On 7 January 2015 at 23:18, Bin Meng wrote: >>>>>>>>>>> Hi Simon, >>>>>>>>>>> >>>>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass 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 >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> 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