780/700 Documentation

Hi, All,
We have been working on the RS780/SB700 for about 2 weeks. Before we can
submit our code, we realized that it doesn't make sense if the
documentation is not available. We can get the datasheet as an AMD
engineer. How can the developer in Coreboot.org get? Do we need any
official procedure to make the document public?

Joe

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: generic cpu detection proposal

Holger Hesselbarth wrote:
> does inteltool support dumping msrs?

If it doesn't already, allow me to promote msrtool which does nothing
but decode MSRs. Please feel free to submit a patch with some
register definitions. So far there are target drivers supporting
Geode LX and CS5536 that you could use for reference.

Thanks!

//Peter

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: SB600 HDA can't find codec fix

Hi, Dan

I have tested your patch on my dbm690t (ALC882) and pistachio (ALC885) board. It really works. However, I
have a suggestion for you.

/* Read in Codec location (BAR + 0xe)[2..0]*/
	dword = readl(base + 0xe);
	dword &= 7;
	if (!dword)  
		goto no_codec;
The above phrase is not correct all the time, at lease to my pistachio board. It will give me the wrong msg "No codec!".

I would appreciate and ack the patch if you can modify it.

BTW, pci_locate_device is only used in early setup stage. So, you can remove it.

Best regards
Maggie li

-----Original Message-----
From: coreboot-bounces <at> coreboot.org [mailto:coreboot-bounces <at> coreboot.org] On Behalf Of Marc Jones
Sent: Thursday, January 29, 2009 1:10 PM
To: Dan Lykowski
Cc: Carl-Daniel Hailfinger; coreboot <at> coreboot.org
Subject: Re: [coreboot] SB600 HDA can't find codec fix

On Tue, Jan 27, 2009 at 11:07 AM, Dan Lykowski
<engineerguy3737 <at> yahoo.com> wrote:
> Diff was being silly and I wanted to get the patch posted before I left work
> for the day. I've cleaned up the patch and included it.

Re: [OpenBIOS] OpenBIOS SVN r416 breaks coreboot-v3

On 1/29/09, Mark Cave-Ayland <mark.cave-ayland <at> siriusit.co.uk> wrote:
> Myles Watson wrote:
>
>
> > Yes.  qemu 0.9.1 works with v2+OpenBIOS and v3+OpenBIOS, but the latest
> qemu
> > doesn't.  The latest qemu works with v2 or v3 +OpenBIOS r186, so it looks
> > like an interaction between OpenBIOS and qemu.
> >
> > HTH,
> > Myles
> >
>
>  Okay, I think I found out what is happening. With coreboot-v3 and OpenBIOS
> SVN then the base address for I/O devices is set to 0x400 which causes
> subsequent hardware to be mapped higher. The backtrace on the hw_error()
> line shows this:
>
>
>  Breakpoint 1, register_ioport_write (start=1296, length=1, size=1,
> func=0x42b105 <ne2000_asic_ioport_write>, opaque=0xc9abb8)
>     at /home/build/src/qemu/trunk/vl.c:392
>  392                 hw_error("register_ioport_write:
> invalid opaque: (start 0x%x, length 0x%x, address 0x%x)", start, length, i);
>  (gdb) print/x start
>  $1 = 0x510
>  (gdb) bt
>  #0  register_ioport_write (start=1296, length=1, size=1, func=0x42b105
> <ne2000_asic_ioport_write>, opaque=0xc9abb8)
>     at /home/build/src/qemu/trunk/vl.c:392

Re: SB600 HDA can't find codec fix

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: generic cpu detection proposal

On 01.02.2009, at 02:32, Peter Stuge <peter <at> stuge.se> wrote:

> Holger Hesselbarth wrote:
>> does inteltool support dumping msrs?
>
> If it doesn't already, allow me to promote msrtool which does nothing
> but decode MSRs. Please feel free to submit a patch with some
> register definitions. So far there are target drivers supporting
> Geode LX and CS5536 that you could use for reference.
>

Inteltool can dump the msrs but it will not parse the bit values the  
fine way msrtool does.

Maybe we should remove the intel focus from inteltool and merge the  
two utilities, call it systemtool or chipsettool instead? Stuff like  
dumping pmbase might be interesting for non-intel systems too, while  
intel systems could gain from a more detailed msr dumper...
Thoughts?

Stefan

>
> Thanks!
>
> //Peter
>
> --
> coreboot mailing list: coreboot <at> coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[PATCH] Add the AML code generator for runtime code generation

Hello,

Following patch adds dynamic ACPI AML code generator which can be used to
generate run-time ACPI ASL code like this:

Name (XXX, 0xXX)

Or:

    Scope (\_SB.PCI0)
    {
 Name (BUSN, Package (0x04)
{
    0x11111111,
    0x22222222,
    0x33333333,
    0x44444444
})

Moreover it demonstrates its use on Asus M2V-MX SE where the SSDT table is
generated by new function k8acpi_write_vars (technically similar to
update_ssdt). But lot of nicer ;)

The ACPI binary code generator will be also useful for P-states generation,
without ugly run-time patching of DSDT.

The old SSDT of K8 will be removed and rest of boards converted in next patch.

Tested on that board. It generates same table as the static SSDT patched by
amdk8_acpi. Windows still boots too ;)

Signed-off-by: Rudolf Marek <r.marek <at> assembler.cz>

Rudolf

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[PATCH] Cleanup/remove update_ssdt

Hello,

Following patch converts the run-time SSDT patching via update_ssdt funtion to
new AML code generator. Compile-tested on all changed targets. I think it should
work because it works for Asus M2V-MX SE.

Signed-off-by: Rudolf Marek <r.marek <at> assembler.cz>

Perhaps also some private SSDTs of each MB could be also somehow converted. Its
quite complicated and I dont own any board to test, so lets just convert the
generic stuff.

Rudolf

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: generic cpu detection proposal

Stefan Reinauer wrote:
> Inteltool can dump the msrs but it will not parse the bit values
> the fine way msrtool does.

Ok. Maybe you can send a patch to add those MSRs to msrtool Holger?

Have a look at http://stuge.se/mt.cs5536_pic_divil3.patch for one way
to note references in the source files.

> Maybe we should remove the intel focus from inteltool and merge the
> two utilities, call it systemtool or chipsettool instead? Stuff
> like dumping pmbase might be interesting for non-intel systems too,
> while intel systems could gain from a more detailed msr dumper...
> Thoughts?

I've had thoughts in that direction too. TODO mentions handling PCI
and port IO registers as well, ie. turn the tool into a more generic
register decoder. I kind of like that idea. On the other hand then it
will very clearly start competing with prettyprint[1] that the Google
guys showed us. It looks like a somewhat fat implementation though,
which I'm not thrilled about. But they have a nifty user interface,
FUSE is a fun twist. I don't know.

We were discussing GeodeLink routing on IRC the other day, and how
it would be nice to e.g. create a bus graph by piecing together
values from various registers, but I'm not sure that kind of
complexity should go into msrtool. Or maybe it should? But a generic
user interface will be a bit tricky.. msrtool is already option
intense.

//Peter

[1] http://code.google.com/p/prettyprint/

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [PATCH] Add the AML code generator for runtime code generation

Rudolf Marek wrote:
> Following patch adds dynamic ACPI AML code generator which can be
> used to generate run-time ACPI ASL code like this:
> 
> Name (XXX, 0xXX)
> 
> Or:
> 
>     Scope (\_SB.PCI0)
>     {
>  Name (BUSN, Package (0x04)
> {
>     0x11111111,
>     0x22222222,
>     0x33333333,
>     0x44444444
> })
> 
> Moreover it demonstrates its use on Asus M2V-MX SE where the SSDT table is
> generated by new function k8acpi_write_vars (technically similar to
> update_ssdt). But lot of nicer ;)
> 
> The ACPI binary code generator will be also useful for P-states generation,
> without ugly run-time patching of DSDT.
> 
> The old SSDT of K8 will be removed and rest of boards converted in next patch.
> 
> Tested on that board. It generates same table as the static SSDT patched by
> amdk8_acpi. Windows still boots too ;)
> 
> Signed-off-by: Rudolf Marek <r.marek <at> assembler.cz>

Acked-by: Peter Stuge <peter <at> stuge.se>

--
coreboot mailing list: coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot