patch: first steps to VSA support in v3

[ron minnich]

These are incomplete and will continue to evolve, but I want to see if
I can get it working at all.

attached.

ron

[Marc Jones]

ron minnich wrote:
> These are incomplete and will continue to evolve, but I want to see if
> I can get it working at all.
>
> attached.
>
> ron
> vm86.c: make some assembly symbols .globl so that vmssetup.c can use them. 
> Add two ops to pci21 support that were define in vsmsetup.c in v2.
> I am pretty sure that the 66 is 66 Mhz, as in PCI bus clock; anyone know? 
> the second is probably 500, as in 500 Mhz, as in CPU clock. The values
> don't actually matter all that much, AFAIK.

...
> case 0xBEA7:
> *eax = 66;
> break;
> case 0xBEA4:
> *eax = 500;
> break;
>
> }
> return res;
> }

Ron,
Here is the documentation to go with the two int15 calls.

I15GetCpuSpeed
in:
AX = BEA4
BX = 4E53

out:
Retrieves CPU speed in AX

I15GetPCISpeed
in:
AX = BEA7
BX = 4E53

out:
Get PCI Bus Speed in AX

BUT, I don't think that you need them. VSA should default to reasonable 
settings without the in15 calls. I need to test it in v2 this afternoon. 
If VSA does require them I would rather change VSA. There is no reason 
it can't get the pci speed and cpu speed from the MSRs. Either way, i 
don't think you need to add it to v3.

Marc

[ron minnich]

On Jan 23, 2008 11:06 AM, Marc Jones  wrote:
> BUT, I don't think that you need them. VSA should default to reasonable
> settings without the in15 calls. I need to test it in v2 this afternoon.
> If VSA does require them I would rather change VSA. There is no reason
> it can't get the pci speed and cpu speed from the MSRs. Either way, i
> don't think you need to add it to v3.

patch now has those two un-needed functions removed. Can you verify
that vsa will do the right thing? I think I had to put these in as the
calls were being made.

thanks

ron

[Marc Jones]

ron minnich wrote:
> On Jan 23, 2008 11:06 AM, Marc Jones  wrote:
> > BUT, I don't think that you need them. VSA should default to reasonable
> > settings without the in15 calls. I need to test it in v2 this afternoon.
> > If VSA does require them I would rather change VSA. There is no reason
> > it can't get the pci speed and cpu speed from the MSRs. Either way, i
> > don't think you need to add it to v3.
>
> patch now has those two un-needed functions removed. Can you verify
> that vsa will do the right thing? I think I had to put these in as the
> calls were being made.
>
> thanks
>
> ron

Ron,
I didn't get to test this today but I will first thing in the AM.
Marc

[ron minnich]

On Jan 23, 2008 5:09 PM, Marc Jones  wrote:
> I didn't get to test this today but I will first thing in the AM.

OK, the code I sent won't run, the only test I have done so far is compiole.
rn

[Carl-Daniel Hailfinger]

On 23.01.2008 20:19, ron minnich wrote:
> On Jan 23, 2008 11:06 AM, Marc Jones  wrote:
> > BUT, I don't think that you need them. VSA should default to reasonable
> > settings without the in15 calls. I need to test it in v2 this afternoon.
> > If VSA does require them I would rather change VSA. There is no reason
> > it can't get the pci speed and cpu speed from the MSRs. Either way, i
> > don't think you need to add it to v3.
>
> patch now has those two un-needed functions removed. Can you verify
> that vsa will do the right thing? I think I had to put these in as the
> calls were being made.

Some comments about the code:
> This is a first cut at the implementation of VSM support. What has do be done, long term, 
> is to remove almost all of the vsmsetup.c file and use functions in the vm86.c file.
>
> The barrier to achieving that goal is the specialized nature of the vga bios support
> code vs. the vsm bios support code. There are a few issues to resolve but what I'd like
> to do is get VSA working first, then work out how to merge the rest of the code.
>
> I have already done some merging at this point.
>
> vsmsetup.c: Add this file from v2. Fix copyright and includes. 
> Remove almost all assembly code in favor of code in vm86.c
>
> vm86.c: make some assembly symbols .globl so that vmssetup.c can use them.
>
> Signed-off-by: Ronald G. Minnich
> Index: northbridge/amd/geodelx/vsmsetup.c
>
> --- northbridge/amd/geodelx/vsmsetup.c	(revision 0)
> +++ northbridge/amd/geodelx/vsmsetup.c	(revision 0)
> @@ -0,0 +1,302 @@
> +/*
> Erik Arjan Hendriks

Missing "copyright"?
> Copyright (C) 2000 Scyld.
> Copyright (C) 2000 Scyld Computing Corporation
> Copyright (C) 2001 University of California.  LA-CC Number 01-67.

Is LA-CC "Los Alamos Computer Code"?
> Copyright (C) 2005 [e-mail]
> Copyright (C) 2007 coresystems GmbH
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2 of the License, or
> (at your option) any later version.
> This program is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU General Public License for more details.
> You should have received a copy of the GNU General Public License
> along with this program; if not, write to the Free Software
> Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
> */
>
> [...]
> +void do_vsmbios(void *bios)
> +{
> struct device *dev;
> unsigned long busdevfn;
> unsigned int rom = 0;
> unsigned char *buf;
> unsigned int size = SMM_SIZE * 1024;
> int i;
> unsigned long ilen, olen;
> printk(BIOS_ERR, "do_vsmbios\n");
> /* clear vsm bios data area */
> for (i = 0x400; i < 0x500; i++) {
> *(volatile unsigned char *)i = 0;
> }
> rom = (unsigned long) bios;
> buf = (unsigned char *)VSA2_BUFFER;
> // FIXME
> //olen = unrv2b((u8 *) rom, buf, &ilen);

How exactly is the VSA going to end up in VSA2_BUFFER if you don't
copy/uncompress it there?
> printk(BIOS_DEBUG, "buf ilen %d olen%d\n", ilen, olen);
> printk(BIOS_DEBUG, "buf %p *buf %d buf[256k] %d\n",
>      buf, buf[0], buf[SMM_SIZE * 1024]);
> printk(BIOS_DEBUG, "buf[0x20] signature is %x:%x:%x:%x\n",
>      buf[0x20], buf[0x21], buf[0x22], buf[0x23]);
> /* check for post code at start of vsainit.bin. If you don't see it,
>   don't bother. */
> if ((buf[0x20] != 0xb0) || (buf[0x21] != 0x10) ||
>    (buf[0x22] != 0xe6) || (buf[0x23] != 0x80)) {
> printk(BIOS_ERR, "do_vsmbios: no vsainit.bin signature, skipping!\n");
> return;
> }
> /* ecx gets smm, edx gets sysm */
> printk(BIOS_ERR, "Call real_mode_switch_call_vsm\n");
> real_mode_switch_call_vsm(MSR_GLIU0_SMM, MSR_GLIU0_SYSMEM);
> /* restart timer 1 */
> outb(0x56, 0x43);
> outb(0x12, 0x41);
> // check that VSA is running OK
> if (VSA_vrRead(SIGNATURE) == VSA2_SIGNATURE)
> printk(BIOS_DEBUG, "do_vsmbios: VSA2 VR signature verified\n");
> else
> printk(BIOS_ERR, 
>        "do_vsmbios: VSA2 VR signature not valid, install failed!\n");
>
> +}

Rest looks good so far from a first glance.

Regards,
Carl-Daniel

[David H. Barr]

On Jan 24, 2008 12:06 PM, Carl-Daniel Hailfinger
 wrote:
> On 23.01.2008 20:19, ron minnich wrote:
> > On Jan 23, 2008 11:06 AM, Marc Jones  wrote:
> > Copyright (C) 2000 Scyld.
> > Copyright (C) 2000 Scyld Computing Corporation
> > Copyright (C) 2001 University of California.  LA-CC Number 01-67.
>
> Is LA-CC "Los Alamos Computer Code"?

Los Alamos Control and Compliance Number, see also:
http://supply.lanl.gov/property/customs/eximguide/default.shtml

HTH,
-dhbarr.

[ron minnich]

On Jan 24, 2008 10:06 AM, Carl-Daniel Hailfinger
 wrote:
===================================================================
> > --- northbridge/amd/geodelx/vsmsetup.c        (revision 0)
> > +++ northbridge/amd/geodelx/vsmsetup.c        (revision 0)
> > @@ -0,0 +1,302 @@
> > +/*
> > Erik Arjan Hendriks
>
> Missing "copyright"?

I will fix this.
> > Copyright (C) 2000 Scyld.
> > Copyright (C) 2000 Scyld Computing Corporation
> > Copyright (C) 2001 University of California.  LA-CC Number 01-67.
>
> Is LA-CC "Los Alamos Computer Code"?

It actually depends on who you ask, but we have to leave that in there :-)
> > buf = (unsigned char *)VSA2_BUFFER;
> > // FIXME
> > //olen = unrv2b((u8 *) rom, buf, &ilen);
>
> How exactly is the VSA going to end up in VSA2_BUFFER if you don't
> copy/uncompress it there?

This code won't run yet. I am doing this initial commit as I don't
want to have another hard drive failure and lose it ... there is more
work to be done.

This code moves the lx state from 'not working' to 'not working', so I
don't mind it too much.
> Rest looks good so far from a first glance.

Good to hear. I would like to commit this because I am paranoid about
losing bits ... but I can try to fix that uncompress thing above.

thanks

ron

[Carl-Daniel Hailfinger]

On 24.01.2008 20:05, ron minnich wrote:
> On Jan 24, 2008 10:06 AM, Carl-Daniel Hailfinger
>  wrote:
> > > --- northbridge/amd/geodelx/vsmsetup.c        (revision 0)
> > > +++ northbridge/amd/geodelx/vsmsetup.c        (revision 0)
> > > @@ -0,0 +1,302 @@
> > > +/*
> > > Erik Arjan Hendriks
> >
> > Missing "copyright"?
>
> I will fix this.
> > > Copyright (C) 2000 Scyld.
> > > Copyright (C) 2000 Scyld Computing Corporation
> > > Copyright (C) 2001 University of California.  LA-CC Number 01-67.
> >
> > Is LA-CC "Los Alamos Computer Code"?
>
> It actually depends on who you ask, but we have to leave that in there :-)

I have no problem leaving it in there, I was just suggesting to add an
explanation of the acronym to the header.
> > > buf = (unsigned char *)VSA2_BUFFER;
> > > // FIXME
> > > //olen = unrv2b((u8 *) rom, buf, &ilen);
> >
> > How exactly is the VSA going to end up in VSA2_BUFFER if you don't
> > copy/uncompress it there?
>
> This code won't run yet. I am doing this initial commit as I don't
> want to have another hard drive failure and lose it ... there is more
> work to be done.

Yes.
> This code moves the lx state from 'not working' to 'not working', so I
> don't mind it too much.

At least the new state is closer to working.
> > Rest looks good so far from a first glance.
>
> Good to hear. I would like to commit this because I am paranoid about
> losing bits ... but I can try to fix that uncompress thing above.

With the fixes: Go ahead and commit.
Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

[Marc Jones]

Carl-Daniel Hailfinger wrote:
> On 24.01.2008 20:05, ron minnich wrote:
> > On Jan 24, 2008 10:06 AM, Carl-Daniel Hailfinger
> >  wrote:
>
> With the fixes: Go ahead and commit.
> Acked-by: Carl-Daniel Hailfinger
>
> Regards,
> Carl-Daniel

I agree, commit it. I think that VSA will need to change to stop doing 
the int15 that I had you remove. We also need to look closely at the 
other int calls in there. I'm working on it today for v2 and that should 
help v3. Patches to come soonish.
Marc

[ron minnich]

Many thanks for the comments!
Committed revision 560.

Marc, do I need to put those two interrupt support cases back, then? I
just deleted them :-)

Let me know when the VSA is available that won't call them.
ron