Hi Simon, On Sun, Jan 11, 2015 at 11:42 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 10 January 2015 at 20:04, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Simon, >> >> On Sun, Jan 11, 2015 at 12:08 AM, Simon Glass <s...@chromium.org> wrote: >>> Hi Bin, >>> >>> On 9 January 2015 at 20:52, Bin Meng <bmeng...@gmail.com> wrote: >>>> Hi Simon, >>>> >>>> On Sat, Jan 10, 2015 at 3:02 AM, Simon Glass <s...@chromium.org> wrote: >>>>> Hi Bin, >>>>> >>>>> On 8 January 2015 at 22:23, Bin Meng <bmeng...@gmail.com> wrote: >>>>>> Hi Simon, >>>>>> >>>>>> On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass <s...@chromium.org> wrote: >>>>>>> Hi Bin, >>>>>>> >>>>>>> On 8 January 2015 at 18:34, Bin Meng <bmeng...@gmail.com> wrote: >>>>>>>> Hi Simon, >>>>>>>> >>>>>>>> On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass <s...@chromium.org> wrote: >>>>>>>>> Hi Bin, >>>>>>>>> >>>>>>>>> On 7 January 2015 at 23:18, Bin Meng <bmeng...@gmail.com> wrote: >>>>>>>>>> Hi Simon, >>>>>>>>>> >>>>>>>>>> On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass <s...@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 <s...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot