[coreboot] Integrated graphics controller on second bus?

Luc Verhaegen libv at skynet.be
Sun Jan 3 22:45:57 CET 2010


On Sun, Jan 03, 2010 at 10:15:33PM +0100, Rudolf Marek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I think I can help you. It looks to me that bit 7 at offset 0xe1 is not set as
> default anymore (otherwise the code never worked?). You would need to set it
> early so VGA gets visible in "enable" phase. The patch fixes that. Also I
> disabled the direct access FB because it was hardcoded. I forgotten what is for,
> maybe libv will know. It looks like the code sets VGA framebuffer size to 32MB
> (this is hardcoded elsewhere check the comments)
> 
> Please try the attached patch I think it could fix it.
> 
> Thanks,
> 
> Rudolf

> Index: northbridge.c
> ===================================================================
> --- northbridge.c	(revision 4978)
> +++ northbridge.c	(working copy)
> @@ -41,32 +41,32 @@
>  	pci_write_config16(dev, 0x80, 0x610f);
>  	pci_write_config32(dev, 0x88, 0x00000002);
>  	
> +	/* dont know if this is right ID fix it */
>  	fb_dev = dev_find_device(PCI_VENDOR_ID_VIA, 0x3122, 0);
>  	if (fb_dev) {

This is just a quick way of checking whether the unichrome was enabled 
at all, so yes, right id.

> -		/* Fixup GART and framebuffer addresses properly.
> -		 * First setup frame buffer properly.
> -		 */
> -		//fb = pci_read_config32(dev, 0x10);       /* Base addres of framebuffer */
> -		fb = 0xd0000000;
> -		printk_debug("Frame buffer at %8x\n",fb);
> -
> -		c = pci_read_config8(dev, 0xe1) & 0xf0;  /* size of vga */
> -		c |= fb>>28;  /* upper nibble of frame buffer address */
> -		c = 0xdd;
> -		pci_write_config8(dev, 0xe1, c);
> -		c = 0x81;                                /* enable framebuffer */
> -		pci_write_config8(dev, 0xe0, c);
> +		/* step 1 enable  */
> +		pci_write_config8(dev, 0xe1, 0x80);
> +		/* step 2 enable the VGA without the direct access framebuffer - TOPMEM-32MB must get reserved */
> +		pci_write_config8(dev, 0xe1, 0xd0);
>  		pci_write_config8(dev, 0xe2, 0x42);      /* 'cos award does */
>  	}
>  }
>  
>  static void nullfunc(){}
>  
> +static void vga_en(struct device *dev)
> +{
> +	/* enable VGA, so the bridges gets VGA_EN and resources are set */
> +	pci_write_config8(dev, 0xe1, 0x80);
> +}
> +
> +
>  static struct device_operations northbridge_operations = {
>  	.read_resources   = nullfunc,
>  	.set_resources    = pci_dev_set_resources,
>  	.enable_resources = pci_dev_enable_resources,
> -	.init             = northbridge_init
> +	.init             = northbridge_init,
> +	.enable           = vga_en,
>  };
>  
>  static const struct pci_driver northbridge_driver __pci_driver = {
> @@ -108,11 +108,15 @@
>  	msr_t clocks1,clocks2,instructions,setup;
>  
>  	printk_debug("VGA random fixup ...\n");
> +
> +
> +	// why it does not rely on std resource system? 
> +/*
>  	pci_write_config8(dev, 0x04, 0x07);
>  	pci_write_config8(dev, 0x0d, 0x20);
>  	pci_write_config32(dev,0x10,0xd8000008);
>  	pci_write_config32(dev,0x14,0xdc000000);
> -
> +*/

History.

>  	// set up performnce counters for debugging vga init sequence
>  	//setup.lo = 0x1c0; // count instructions
>  	//wrmsr(0x187,setup);
> @@ -254,6 +258,7 @@
>  					ramregs[i]);
>  		}
>  		printk_debug("I would set ram size to 0x%x Kbytes\n", (rambits)*16*1024);
> +//it looks like one set 32MB of VGA?
>  		tomk = rambits*16*1024 - 32768;
>  		/* Compute the top of Low memory */
>  		tolmk = pci_tolm >> 10;

Anything else than 32mb and it dies a horrible death later on when linux 
tries to use the disks.

Direct fb access allows any access to the framebuffer on the unichrome 
to be intercepted by the memory controller. Unichrome and memory 
controller are on the same die here, and since the unichrome uses part 
of main ram for its memory, any access to the unichrome memory would 
mean requests being made from the unichrome to the memory controller. 
Without direct fb access, a lot of on chip bandwidth is effectively 
thrown away sending fb accesses back and forth.

Luc Verhaegen.




More information about the coreboot mailing list