Hi Bin,
On 8 January 2015 at 22:23, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Fri, Jan 9, 2015 at 11:35 AM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 8 January 2015 at 18:34, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Thu, Jan 8, 2015 at 11:06 PM, Simon Glass sjg@chromium.org wrote:
Hi Bin,
On 7 January 2015 at 23:18, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Dec 30, 2014 at 10:32 AM, Simon Glass sjg@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@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.
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 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.
There is also the VGA I/O registers which we currently emulate, but could perhaps pass through to the card.
So do you have it working now?
Regards, Simon