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. > >> 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. > >> 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. 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. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
