[patch][v2]:fam10 microcode

[Bao, Zheng]

Attached are the latest ucode patches for Family 10h:

9fh for RB/BL/DA Rev C; 
96h for DR Rev B.

Signed-off-by:

Zheng

[Tiago Marques]

Hi Zheng,

First, let me thank you personally for these patches.

I would like to ask you something, if one would like to port the Phenom II
(which I think is rev C cpus) how would the L3/memory controller run in an
AM2 board (clocks and voltages) and is it portable to MCP55 based
motherboards? Some manufacturers stated that some chipsets don't support AM3
CPUs for some reason.

Best regards

2009/3/25 Bao, Zheng
> Attached are the latest ucode patches for Family 10h:
>
> 9fh for RB/BL/DA Rev C;
> 96h for DR Rev B.
>
> Signed-off-by:
>
> Zheng

[Marc Jones]

2009/3/24 Bao, Zheng :
> Attached are the latest ucode patches for Family 10h:
>
> 9fh for RB/BL/DA Rev C;
> 96h for DR Rev B.
>
> Signed-off-by:

Acked-by: Marc Jones 
r4028

I will work up a patch for the fam10 mainboards to use these new
microcode files.

Marc

[Ward Vandewege]

Hey Marc et al,

I just received a h8dmr box with quad core CPUs (2372HE) and 32GB of ram. I
hacked up an h8dmr-fam10 patch which boots but still has tons of issues. Boot
log here:

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-c.cap

First problem is that it complains about not finding the microcode rev id. So
I found the message below - did you ever get around to doing this?

I also modified coreboot a little to print out the CPU version id (0x10042),
which is not yet listed in amd/amdfam10/raminit_amdmct.c.

A little further down in the log it seems I've got multiple cores talking at
once so that's something else I'll need to figure out.

It does actually get all the way to CBFS, but hangs after loadking the first
stage. There is also some slowness during/after ram detection.

Any hints on where I should look to fix those things would be welcome :)

Thanks,
Ward.

On Wed, Mar 25, 2009 at 09:49:42AM -0600, Marc Jones wrote:
> 2009/3/24 Bao, Zheng :
> > Attached are the latest ucode patches for Family 10h:
> >
> > 9fh for RB/BL/DA Rev C;
> > 96h for DR Rev B.
> >
> > Signed-off-by:
>
> Acked-by: Marc Jones 
> r4028
>
> I will work up a patch for the fam10 mainboards to use these new
> microcode files.
>
> Marc
>
> !DSPAM:49ca52c0315921804284693!

[Stefan Reinauer]

On 02.06.2009 17:57 Uhr, Ward Vandewege wrote:
> Hey Marc et al,
>
> I just received a h8dmr box with quad core CPUs (2372HE) and 32GB of ram. I
> hacked up an h8dmr-fam10 patch which boots but still has tons of issues. Boot
> log here:
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-c.cap
>
> First problem is that it complains about not finding the microcode rev id. So
> I found the message below - did you ever get around to doing this?

To play the advocatus diaboli, for Intel CPUs you can download the
latest microcode from their web page. Unfortunately, for AMD you need an
NDA signed to get them.

Best regards,

Stefan

[Marc Jones]

On Tue, Jun 2, 2009 at 9:57 AM, Ward Vandewege  wrote:
> Hey Marc et al,
>
> I just received a h8dmr box with quad core CPUs (2372HE) and 32GB of ram. I
> hacked up an h8dmr-fam10 patch which boots but still has tons of issues. Boot
> log here:
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-c.cap
>
> First problem is that it complains about not finding the microcode rev id. So
> I found the message below - did you ever get around to doing this?
>
> I also modified coreboot a little to print out the CPU version id (0x10042),
> which is not yet listed in amd/amdfam10/raminit_amdmct.c.

We added for one of the C2 parts. It should be easy enough to add the other one.
You will also need to change Options.lb for the C2 microcode.
Shanghai rev DA-C2: "mc_patch_0100009f.h"
> A little further down in the log it seems I've got multiple cores talking at
> once so that's something else I'll need to figure out.

Yes, that stuff should be fine.
> It does actually get all the way to CBFS, but hangs after loadking the first
> stage. There is also some slowness during/after ram detection.

There is slowness around the cache disable / mem copy.. I think that
someone posted a fix to the list at one point. It would require some
searching.
> Any hints on where I should look to fix those things would be welcome :)
>
> Thanks,
> Ward.
>
> On Wed, Mar 25, 2009 at 09:49:42AM -0600, Marc Jones wrote:
> > 2009/3/24 Bao, Zheng :
> > > Attached are the latest ucode patches for Family 10h:
> > >
> > > 9fh for RB/BL/DA Rev C;
> > > 96h for DR Rev B.
> > >
> > > Signed-off-by:
> >
> > Acked-by: Marc Jones 
> > r4028
> >
> > I will work up a patch for the fam10 mainboards to use these new
> > microcode files.
> >
> > Marc
> >
> > !DSPAM:49ca52c0315921804284693!

[Ward Vandewege]

On Tue, Jun 02, 2009 at 10:39:56AM -0600, Marc Jones wrote:
> We added for one of the C2 parts. It should be easy enough to add the other one.
> You will also need to change Options.lb for the C2 microcode.
> Shanghai rev DA-C2: "mc_patch_0100009f.h"

Great, I made those changes, and the microcode update happens now. It also
stopped complaining about the CPU version. Booting does not get very far
anymore though, so I must be doing something wrong:

------------------------------------------------------------------------------
coreboot-2.0.0-r4329M_h8dmr_Fallback Tue Jun  2 13:24:42 EDT 2009 starting...

BSP Family_Model: 00100f42
*sysinfo range: [000cc000,000cdfa0]
bsp_apicid = 00
cpu_init_detectedx = 00000000
microcode: equivalent rev id  = 0x1062, current patch id = 0x00000000
microcode: patch id to apply = 0x0100009f
microcode: updated to patch id = 0x0100009f  success

cpuSetAMDMSR  done
Enter amd_ht_init()
AMD_CB_EventNotify()
 event class: 05
 event: 1004
 data:  04  00  00  01
AMD_CB_EventNotify()
 event class: 05
 event: 2006
 data:  04  00  02  00
Exit amd_ht_init()
cpuSetAMDPCI 00 done
cpuSetAMDPCI 01
------------------------------------------------------------------------------

It hangs right there. This started happening when I added

case 0x10042:
    ret = AMD_RB_C2;
    break;

to the switch statement in mctGetLogicalCPUID
(northbridge/amd/amdfam10/raminit_amdmct.c), telling coreboot about this CPU
version.

If I remove that part again, the system reboots endlessly (this is with the
microcode update now working, and the change in Options.lb that you
suggested):

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-j.cap

Thoughts?

Thanks,
Ward.

[Marc Jones]

On Tue, Jun 2, 2009 at 11:35 AM, Ward Vandewege  wrote:
> On Tue, Jun 02, 2009 at 10:39:56AM -0600, Marc Jones wrote:
> > We added for one of the C2 parts. It should be easy enough to add the other one.
> > You will also need to change Options.lb for the C2 microcode.
> > Shanghai rev DA-C2: "mc_patch_0100009f.h"
>
> Great, I made those changes, and the microcode update happens now. It also
> stopped complaining about the CPU version. Booting does not get very far
> anymore though, so I must be doing something wrong:
>
> coreboot-2.0.0-r4329M_h8dmr_Fallback Tue Jun  2 13:24:42 EDT 2009 starting...
>
> BSP Family_Model: 00100f42
> *sysinfo range: [000cc000,000cdfa0]
> bsp_apicid = 00
> cpu_init_detectedx = 00000000
> microcode: equivalent rev id  = 0x1062, current patch id = 0x00000000
> microcode: patch id to apply = 0x0100009f
> microcode: updated to patch id = 0x0100009f  success
>
> cpuSetAMDMSR  done
> Enter amd_ht_init()
> AMD_CB_EventNotify()
>  event class: 05
>  event: 1004
>  data:  04  00  00  01
> AMD_CB_EventNotify()
>  event class: 05
>  event: 2006
>  data:  04  00  02  00
> Exit amd_ht_init()
> cpuSetAMDPCI 00 done
> cpuSetAMDPCI 01
>
> It hangs right there. This started happening when I added
>
> case 0x10042:
>    ret = AMD_RB_C2;
>    break;
>
> to the switch statement in mctGetLogicalCPUID
> (northbridge/amd/amdfam10/raminit_amdmct.c), telling coreboot about this CPU
> version.
>
> If I remove that part again, the system reboots endlessly (this is with the
> microcode update now working, and the change in Options.lb that you
> suggested):
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-j.cap
>
> Thoughts?

You are the first to try this on a real system. Nothing is jumping out
at me in the code. If you can put in some debug checks around there it
will be helpful to figure out.

Marc

[Ward Vandewege]

On Tue, Jun 02, 2009 at 02:27:58PM -0600, Marc Jones wrote:
> You are the first to try this on a real system. Nothing is jumping out
> at me in the code. If you can put in some debug checks around there it
> will be helpful to figure out.

Sure. I've sprinkled some debug code and traced the hang to this bit of code
in cpu/amd/model_10xxx/init_cpus.c, void AMD_SetHtPhyRegister:

/* Now get the current phy register data
     * LinkPhyDone = 0, LinkPhyWrite = 0 is a read
     */
    phyReg |= fam10_htphy_default[entry].htreg;
    pci_write_config32(NODE_PCI(node, 4), phyBase, phyReg);

do {
      val = pci_read_config32(NODE_PCI(node, 4), phyBase);
    } while (!(val & HTPHY_IS_COMPLETE_MASK));

That's an infinite loop on the second CPU, apparently.

I've uploaded the boot log with debug output, as well as my modified
init_cpus.c file with all the debug printing:

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-n.cap

http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-n.c

Thanks,
Ward.

[Marc Jones]

On Tue, Jun 2, 2009 at 3:02 PM, Ward Vandewege  wrote:
> On Tue, Jun 02, 2009 at 02:27:58PM -0600, Marc Jones wrote:
> > You are the first to try this on a real system. Nothing is jumping out
> > at me in the code. If you can put in some debug checks around there it
> > will be helpful to figure out.
>
> Sure. I've sprinkled some debug code and traced the hang to this bit of code
> in cpu/amd/model_10xxx/init_cpus.c, void AMD_SetHtPhyRegister:
>
> /* Now get the current phy register data
>     * LinkPhyDone = 0, LinkPhyWrite = 0 is a read
>     */
>    phyReg |= fam10_htphy_default[entry].htreg;
>    pci_write_config32(NODE_PCI(node, 4), phyBase, phyReg);
>
> do {
>      val = pci_read_config32(NODE_PCI(node, 4), phyBase);
>    } while (!(val & HTPHY_IS_COMPLETE_MASK));
>
> That's an infinite loop on the second CPU, apparently.

It looks like the errata for C2 are needed with the microcode update.
There are several new ones: Revision Guide for AMD Family 10h
Processors. http://developer.amd.com/documentation/guides/Pages/default.aspx

Errata 327 seems like it might be the issue since it is in the same
registers. I'll look and see where the best place for making the
change. I should have some free time this afternoon.

Marc

[Christian Leber]

On Tuesday 02 June 2009 22:27:58 Marc Jones wrote:

Hi Marc
> You are the first to try this on a real system.

I also just tried it, it does not work (but fails a little bit later than 
Ward), log attached.
The System is a tyan s2912_fam10 with the very same CPUs (00100f42).
Without microcode patch we can boot the system, given that a HTX card is in 
the system. Without HTX card coreboot will fail.

Christian

[Marc Jones]

On Wed, Jun 3, 2009 at 9:01 AM, Christian Leber
 wrote:
> On Tuesday 02 June 2009 22:27:58 Marc Jones wrote:
>
> Hi Marc
> > You are the first to try this on a real system.
>
> I also just tried it, it does not work (but fails a little bit later than
> Ward), log attached.
> The System is a tyan s2912_fam10 with the very same CPUs (00100f42).
> Without microcode patch we can boot the system, given that a HTX card is in
> the system. Without HTX card coreboot will fail.

Thanks for testing. It helps to have a few different cases to narrow
down the problems. My guess is that the HTX card forces the HT link
speed to a lower speed and that allows it to work.

Marc

[Christian Leber]

On Wednesday 03 June 2009 17:49:27 Marc Jones wrote:

Hi Marc
> > Without HTX card coreboot will fail.
>
> Thanks for testing. It helps to have a few different cases to narrow
> down the problems. My guess is that the HTX card forces the HT link
> speed to a lower speed and that allows it to work.

No, with HTX card the link between the Opterons is running with HT3 at 2200 
Mhz, that is not the problem.

We repeated the test just to be sure, it is really the microcode patch that 
makes it fail like in the log of my last mail in this thread.

Christian

[Marc Jones]

On Thu, Jun 4, 2009 at 7:18 AM, Christian Leber
 wrote:
> On Wednesday 03 June 2009 17:49:27 Marc Jones wrote:
>
> Hi Marc
> > > Without HTX card coreboot will fail.
> >
> > Thanks for testing. It helps to have a few different cases to narrow
> > down the problems. My guess is that the HTX card forces the HT link
> > speed to a lower speed and that allows it to work.
>
> No, with HTX card the link between the Opterons is running with HT3 at 2200
> Mhz, that is not the problem.
>
> We repeated the test just to be sure, it is really the microcode patch that
> makes it fail like in the log of my last mail in this thread.

Thanks, As Myles pointed out, my comment didn't make sense. Putting it
the errata is the next step.

Marc

[Christian Leber]

On Thursday 04 June 2009 18:08:59 Marc Jones wrote:

Hi Marc
> Thanks, As Myles pointed out, my comment didn't make sense. Putting it
> the errata is the next step.

I attached a log without htx card, the port80 shows 0x35.

Probably the 42 is in the end not exactly the same like the 62.

Christian

[Marc Jones]

On Thu, Jun 4, 2009 at 4:31 PM, Christian Leber
 wrote:
> On Thursday 04 June 2009 18:08:59 Marc Jones wrote:
>
> Hi Marc
> > Thanks, As Myles pointed out, my comment didn't make sense. Putting it
> > the errata is the next step.
>
> I attached a log without htx card, the port80 shows 0x35.
>
> Probably the 42 is in the end not exactly the same like the 62.

I think it should just be a package difference. It looks like you hit
the same thing as Ward without the HTX card. Not sure why that changes
things.

Marc

[Christian Leber]

On Friday 05 June 2009 01:04:56 Marc Jones wrote:

Hi Marc
> I think it should just be a package difference. It looks like you hit
> the same thing as Ward without the HTX card. Not sure why that changes
> things.

Either some CPU register is set wrong or it is interpreted wrong, because a 
link is found that is neither C(oherent) nor NC.

It tries to set then PHY options and waits afterwards forever for the 
completion.

I attached 2 logs (with and without htx card) and a .c file that spills out 
that stuff.

@Ward: probably you could try with this init_cpu.c this to see if on you box 
the same is happening.

Christian

[Marc Jones]

On Fri, Jun 5, 2009 at 9:49 AM, Christian Leber
 wrote:
> On Friday 05 June 2009 01:04:56 Marc Jones wrote:
>
> Hi Marc
> > I think it should just be a package difference. It looks like you hit
> > the same thing as Ward without the HTX card. Not sure why that changes
> > things.
>
> Either some CPU register is set wrong or it is interpreted wrong, because a
> link is found that is neither C(oherent) nor NC.
>
> It tries to set then PHY options and waits afterwards forever for the
> completion.
>
> I attached 2 logs (with and without htx card) and a .c file that spills out
> that stuff.
>
> @Ward: probably you could try with this init_cpu.c this to see if on you box
> the same is happening.

Thanks Christian. I'm trying to figure out why the HTX card changes
things ( and remember how this works...). The INIT hang looks like
errata 344/354, maybe.

Marc

[Marc Jones]

Patch for errata 327, 344, 346, 354. Three of those are HT errata so I
hope that fixes the issue.

Signed-off-by: Marc Jones

[Ward Vandewege]

On Fri, Jun 05, 2009 at 04:00:57PM -0600, Marc Jones wrote:
> Patch for errata 327, 344, 346, 354. Three of those are HT errata so I
> hope that fixes the issue.

Hmm, it doesn't yet. It still hangs in the same place, but it does a lot more
iterations of that loop so I guess it gets further. Improvement, I guess?

See

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-p.cap

for the old output, and

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-q.cap

for the output with your patch. Still using the much-more-verbose

http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-n.c

Thanks!
Ward.

[Marc Jones]

On Fri, Jun 5, 2009 at 6:50 PM, Ward Vandewege wrote:
> On Fri, Jun 05, 2009 at 04:00:57PM -0600, Marc Jones wrote:
> > Patch for errata 327, 344, 346, 354. Three of those are HT errata so I
> > hope that fixes the issue.
>
> Hmm, it doesn't yet. It still hangs in the same place, but it does a lot more
> iterations of that loop so I guess it gets further. Improvement, I guess?
>
> See
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-p.cap
>
> for the old output, and
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-q.cap
>
> for the output with your patch. Still using the much-more-verbose
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-n.c

Ah, Maybe we were looking right at it.... Bit 10 520a and 530a is
reserved in the C2.
Updated the patch. Please try again.

Marc

[Ward Vandewege]

On Fri, Jun 05, 2009 at 11:49:02PM -0600, Marc Jones wrote:
> On Fri, Jun 5, 2009 at 6:50 PM, Ward Vandewege wrote:
> > On Fri, Jun 05, 2009 at 04:00:57PM -0600, Marc Jones wrote:
> > > Patch for errata 327, 344, 346, 354. Three of those are HT errata so I
> > > hope that fixes the issue.
> >
> > Hmm, it doesn't yet. It still hangs in the same place, but it does a lot more
> > iterations of that loop so I guess it gets further. Improvement, I guess?
> >
> > See
> >
> > http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-p.cap
> >
> > for the old output, and
> >
> > http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-q.cap
> >
> > for the output with your patch. Still using the much-more-verbose
> >
> > http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-n.c
>
> Ah, Maybe we were looking right at it.... Bit 10 520a and 530a is
> reserved in the C2.
> Updated the patch. Please try again.

Still no dice - small differences in output though:

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-w.cap

Thanks,
Ward.

[Marc Jones]

On Sat, Jun 6, 2009 at 6:56 AM, Ward Vandewege wrote:
> On Fri, Jun 05, 2009 at 11:49:02PM -0600, Marc Jones wrote:
> > On Fri, Jun 5, 2009 at 6:50 PM, Ward Vandewege wrote:
> > > On Fri, Jun 05, 2009 at 04:00:57PM -0600, Marc Jones wrote:
> > > > Patch for errata 327, 344, 346, 354. Three of those are HT errata so I
> > > > hope that fixes the issue.
> > >
> > > Hmm, it doesn't yet. It still hangs in the same place, but it does a lot more
> > > iterations of that loop so I guess it gets further. Improvement, I guess?
> > >
> > > See
> > >
> > > http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-p.cap
> > >
> > > for the old output, and
> > >
> > > http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-q.cap
> > >
> > > for the output with your patch. Still using the much-more-verbose
> > >
> > > http://ward.vandewege.net/coreboot/h8dmr/fam10/init_cpus-n.c
> >
> > Ah, Maybe we were looking right at it.... Bit 10 520a and 530a is
> > reserved in the C2.
> > Updated the patch. Please try again.
>
> Still no dice - small differences in output though:
>
> http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-w.cap

That sucks. The difference is in the table entry number of the skipped
entry I added. I am worried that something needs to change in the HT
init that we don't know about. I'll look some more this afternoon.

Marc

[Marc Jones]

I have update the errata a little more. I don't see anything in the HT
init that would cause the issue. It may be a setting that we have to
find by checking against the vendor BIOS.

There are new tables in the BKDG, 2.6.4.2.4.1 and .2 for buffer setup
that might have something to do with the problem. *shrug*

Marc

[Ward Vandewege]

On Tue, Jun 09, 2009 at 01:07:39PM -0600, Marc Jones wrote:
> I have update the errata a little more. I don't see anything in the HT
> init that would cause the issue. It may be a setting that we have to
> find by checking against the vendor BIOS.
>
> There are new tables in the BKDG, 2.6.4.2.4.1 and .2 for buffer setup
> that might have something to do with the problem. *shrug*

Hmm, this patch still didn't fix the problem for me. As per IRC, I did some
dumping of lspci (etc) data from the proprietary bios:

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-fam10-proprietary-index...

and I added the pci dump lines you suggested. Here's a dump with them right
before the loop where cpu 1 gets stuck:

http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-ad.cap

Sorry, that last file is a bit large (1.4MB).

Now, just a sanity check: these CPUs are

Quad-Core AMD Opteron(tm) Processor 2372 HE stepping 02

So adding this line

0x100f42, 0x1062,

to get_equivalent_processor_rev_id in
src/cpu/amd/model_10xxx/update_microcode.c, and pointing AMD_UCODE_PATCH_FILE
to mc_patch_0100009f.h in src/mainboard/supermicro/h8dmr_fam10/Options.lb is
definitely correct?

Thanks,
Ward.

[Ward Vandewege]

On Tue, Jun 09, 2009 at 01:07:39PM -0600, Marc Jones wrote:
> I have update the errata a little more. I don't see anything in the HT
> init that would cause the issue. It may be a setting that we have to
> find by checking against the vendor BIOS.
>
> There are new tables in the BKDG, 2.6.4.2.4.1 and .2 for buffer setup
> that might have something to do with the problem. *shrug*

Acked-by: Ward Vandewege

Thanks!
Ward.

[Marc Jones]

On Tue, Jun 16, 2009 at 5:37 PM, Ward Vandewege wrote:
> On Tue, Jun 09, 2009 at 01:07:39PM -0600, Marc Jones wrote:
> > I have update the errata a little more. I don't see anything in the HT
> > init that would cause the issue. It may be a setting that we have to
> > find by checking against the vendor BIOS.
> >
> > There are new tables in the BKDG, 2.6.4.2.4.1 and .2 for buffer setup
> > that might have something to do with the problem. *shrug*
>
> Acked-by: Ward Vandewege

Thanks Ward.

r4359

Marc

Does the fam10 code work now?

[Bao, Zheng]

Hi,
Now I am trying the coreboot for family 10. But I found that the
linkOptimization()->selectOptimalWidthAndFrequency() in h2finit.c can
not set the "Optimized" width and frequency, because the
AMD_CB_Cpu2RCBLimits is NULL in amd_ht_init() in ht_wrapper.c. This
causes the HT bus Configuration can not be done. According to the
comment in mct_d.c, the requirement of mctSutoInitMCT_D() can not be
met.

Does it mean currently the family 10 code can not work at all?

Zheng

Does the fam10 code work now?

[Marc Jones]

Hi Zheng,

On Wed, Jun 17, 2009 at 9:00 PM, Bao, Zheng wrote:
> Hi,
> Now I am trying the coreboot for family 10. But I found that the
> linkOptimization()->selectOptimalWidthAndFrequency() in h2finit.c can
> not set the "Optimized" width and frequency, because the
> AMD_CB_Cpu2RCBLimits is NULL in amd_ht_init() in ht_wrapper.c. This
> causes the HT bus Configuration can not be done. According to the
> comment in mct_d.c, the requirement of mctSutoInitMCT_D() can not be
> met.
>
> Does it mean currently the family 10 code can not work at all?

There are several people that have working (at varying levels) of
Fam10 systems. So, most stuff does work. We knocked out a few bugs
this week that should help more people get their configurations
running.

The AMD_CB_Cpu2RCBLimits is NULL because coreboot doesn't limit the HT
frequency. The limit would be an upper limit not lower, since HT all
start at 200MHz.

The requirement in mctAutoInitMCT_D is that HT init be done and that
includes the reset. coreboot should fail in the HT init phase if it
can't be initialized and you wouldn't get to mctAutoInitMCT_D.

Marc

Does the fam10 code work now?

[Bao, Zheng]

1. The processor I work on is Socket AM2r2. Is it supported?
2. The board I work on is Fam10(AM2r2)+RS780+SB700, somehow like
dbm690t. what is the configuration in Option.lb. HT_CHAIN_UNITID_BASE?
HT_CHAIN_END_UNITID_BASE? I am still confused about these settings.
3. If the HT can not be configured to HT3 mode, can the MCT be set at
high speed?

Zheng

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Friday, June 19, 2009 12:15 AM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: Does the fam10 code work now?

Hi Zheng,

On Wed, Jun 17, 2009 at 9:00 PM, Bao, Zheng wrote:
> Hi,
> Now I am trying the coreboot for family 10. But I found that the
> linkOptimization()->selectOptimalWidthAndFrequency() in h2finit.c can
> not set the "Optimized" width and frequency, because the
> AMD_CB_Cpu2RCBLimits is NULL in amd_ht_init() in ht_wrapper.c. This
> causes the HT bus Configuration can not be done. According to the
> comment in mct_d.c, the requirement of mctSutoInitMCT_D() can not be
> met.
>
> Does it mean currently the family 10 code can not work at all?

There are several people that have working (at varying levels) of
Fam10 systems. So, most stuff does work. We knocked out a few bugs
this week that should help more people get their configurations
running.

The AMD_CB_Cpu2RCBLimits is NULL because coreboot doesn't limit the HT
frequency. The limit would be an upper limit not lower, since HT all
start at 200MHz.

The requirement in mctAutoInitMCT_D is that HT init be done and that
includes the reset. coreboot should fail in the HT init phase if it
can't be initialized and you wouldn't get to mctAutoInitMCT_D.

Marc

Does the fam10 code work now?

[Marc Jones]

On Thu, Jun 18, 2009 at 9:07 PM, Bao, Zheng wrote:
> The processor I work on is Socket AM2r2. Is it supported?

I only used socket F. You might need to to make some adjustments for AM2.
> The board I work on is Fam10(AM2r2)+RS780+SB700, somehow like
>
> dbm690t. what is the configuration in Option.lb. HT_CHAIN_UNITID_BASE?
> HT_CHAIN_END_UNITID_BASE? I am still confused about these settings.

It depends on the chipset and board configuration. You should be able
to set that the same as the dbm690T.
> If the HT can not be configured to HT3 mode, can the MCT be set at
>
> high speed?

I think it should work at HT1 speeds. I don't know how closely they
are really connected. The HT just needs to be setup before memory. Is
there more than one CPU? Can the 780 do HT3?

Marc

Does the fam10 code work now? Patches for discuss.

[Bao, Zheng]

amd_fam10_ht_sb_only.diff:
I am not sure about this patch. Not sure to add signed-off-by line.
Don't ack it before review it and say something.

My board is Fam10 + 1 HT SouthBridge. It is close to dbm690t. So I
set HT_CHAIN_UNITID_BASE as 0 and HT_CHAIN_END_UNITID_BASE as 1, even
though I don't know well what they actually are. Base on currently fam10
code, I have skip some code, otherwise the HT link can not be set up
correctly. It is pretty like a workaround and my board can work in
1.8GHz (HT3). Doesn't the code in repository cover the mode of
one HT processor + 1 HT SB device?

Index: src/northbridge/amd/amdht/h3finit.c
===================================================================
--- src/northbridge/amd/amdht/h3finit.c	(revision 503)
+++ src/northbridge/amd/amdht/h3finit.c	(working copy)
@@ -1104,6 +1104,7 @@
    			AmdPCIRead(currentPtr, &temp);
    		} while (!IS_HT_SLAVE_CAPABILITY(temp));

+#if (HT_CHAIN_UNITID_BASE != 0)
    		AmdPCIReadBits(currentPtr, 25, 21, &unitIDcnt);
    		if ((unitIDcnt + currentBUID > 31) || ((secBus
== 0) && (unitIDcnt + currentBUID > 24)))
    		{
@@ -1145,7 +1146,7 @@
    			STOP_HERE;
    			break;
    		}
-
+#endif
    		AmdPCIReadBits(currentPtr, 26, 26, &temp);
    		pDat->PortList[pDat->TotalLinks*2+1].Link =
(u8)temp;
    		pDat->PortList[pDat->TotalLinks*2+1].Pointer =
currentPtr;
@@ -1156,6 +1157,11 @@
    		depth++;
    		pDat->TotalLinks++;
    		currentBUID += unitIDcnt;
+#if HT_CHAIN_UNITID_BASE == 0
+			STOP_HERE;
+			break;
+#endif
+
    	}
    	if (pDat->HtBlock->AMD_CB_EventNotify)
    	{

******************************************************************
amd_fam10_mct_am2_rough.diff:
The original code was pretty weird. It definitely can not
be build correctly. This patch is only about building error.

The mctardk4 seems to be for AM2. Based on the code and this
patch, the memory seems to work but is unstable and unbearably
slow. I need to dig it more.

Since I am confused about this, it is not a signed-off-by patch.

Index: src/northbridge/amd/amdmct/mct/mctardk4.c
===================================================================
--- src/northbridge/amd/amdmct/mct/mctardk4.c	(revision 503)
+++ src/northbridge/amd/amdmct/mct/mctardk4.c	(working copy)
@@ -25,7 +25,7 @@

void mctGet_PS_Cfg_D(struct MCTStatStruc *pMCTstat,
    		 struct DCTStatStruc *pDCTstat, u32 dct)
-
+{
    print_tx("dct: ", dct);
    print_tx("Speed: ", pDCTstat->Speed);

@@ -66,42 +66,43 @@
  */

static const u8 Table_ATC_ODC_D_Bx[] = {
-	1, 0xFF, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   12, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   16, 0x00, 0x2F, 0x00, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   20, 0x00, 0x2F, 0x38, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   24, 0x00, 0x2F, 0x37, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   32, 0x00, 0x2F, 0x34, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   12, 0x20, 0x22, 0x20, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   16, 0x20, 0x22, 0x30, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   20, 0x20, 0x22, 0x2C, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   24, 0x20, 0x22, 0x2A, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   32, 0x20, 0x22, 0x2B, 0x0, 0x22, 0x13, 0x11, 0x0
-	4, 0xFF, 0x20, 0x25, 0x20, 0x0, 0x22, 0x33, 0x11, 0x0
-	5, 0xFF, 0x20, 0x20, 0x2F, 0x0, 0x22, 0x32, 0x11, 0x0
-	0FFh
+	1, 0xFF, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   12, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   16, 0x00, 0x2F, 0x00, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   20, 0x00, 0x2F, 0x38, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   24, 0x00, 0x2F, 0x37, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   32, 0x00, 0x2F, 0x34, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   12, 0x20, 0x22, 0x20, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   16, 0x20, 0x22, 0x30, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   20, 0x20, 0x22, 0x2C, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   24, 0x20, 0x22, 0x2A, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   32, 0x20, 0x22, 0x2B, 0x0, 0x22, 0x13, 0x11, 0x0,
+	4, 0xFF, 0x20, 0x25, 0x20, 0x0, 0x22, 0x33, 0x11, 0x0,
+	5, 0xFF, 0x20, 0x20, 0x2F, 0x0, 0x22, 0x32, 0x11, 0x0,
+	0xFF
+};

static const u8 Table_ATC_ODC_D_Ax[] = {
-	1, 0xFF, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   12, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   16, 0x00, 0x2F, 0x00, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   20, 0x00, 0x2F, 0x38, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   24, 0x00, 0x2F, 0x37, 0x0, 0x22, 0x13, 0x11, 0x0
-	2,   32, 0x00, 0x2F, 0x34, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   12, 0x20, 0x22, 0x20, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   16, 0x20, 0x22, 0x30, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   20, 0x20, 0x22, 0x2C, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   24, 0x20, 0x22, 0x2A, 0x0, 0x22, 0x13, 0x11, 0x0
-	3,   32, 0x20, 0x22, 0x2B, 0x0, 0x22, 0x13, 0x11, 0x0
-	4, 0xFF, 0x20, 0x25, 0x20, 0x0, 0x22, 0x33, 0x11, 0x0
-	5, 0xFF, 0x20, 0x20, 0x2F, 0x0, 0x22, 0x32, 0x11, 0x0
+	1, 0xFF, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   12, 0x00, 0x2F, 0x2F, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   16, 0x00, 0x2F, 0x00, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   20, 0x00, 0x2F, 0x38, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   24, 0x00, 0x2F, 0x37, 0x0, 0x22, 0x13, 0x11, 0x0,
+	2,   32, 0x00, 0x2F, 0x34, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   12, 0x20, 0x22, 0x20, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   16, 0x20, 0x22, 0x30, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   20, 0x20, 0x22, 0x2C, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   24, 0x20, 0x22, 0x2A, 0x0, 0x22, 0x13, 0x11, 0x0,
+	3,   32, 0x20, 0x22, 0x2B, 0x0, 0x22, 0x13, 0x11, 0x0,
+	4, 0xFF, 0x20, 0x25, 0x20, 0x0, 0x22, 0x33, 0x11, 0x0,
+	5, 0xFF, 0x20, 0x20, 0x2F, 0x0, 0x22, 0x32, 0x11, 0x0,
    0xFF
 };

static void Get_ChannelPS_Cfg0_D( u8 MAAdimms, u8 Speed, u8 MAAload,
    			u8 DATAAload, u32 *AddrTmgCTL, u32
*ODC_CTL,
-				u32 *CMDmode);
+				u32 *CMDmode)
 {
    u8 *p;

@@ -168,5 +169,5 @@
    	}
    	p+=10;
    } while (0xFF == *p);
-
+	}
 }

************************************************************

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Friday, June 19, 2009 12:17 PM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: Does the fam10 code work now?

On Thu, Jun 18, 2009 at 9:07 PM, Bao, Zheng wrote:
> The processor I work on is Socket AM2r2. Is it supported?

I only used socket F. You might need to to make some adjustments for
AM2.
> The board I work on is Fam10(AM2r2)+RS780+SB700, somehow like
>
> dbm690t. what is the configuration in Option.lb. HT_CHAIN_UNITID_BASE?
> HT_CHAIN_END_UNITID_BASE? I am still confused about these settings.

It depends on the chipset and board configuration. You should be able
to set that the same as the dbm690T.
> If the HT can not be configured to HT3 mode, can the MCT be set at
>
> high speed?

I think it should work at HT1 speeds. I don't know how closely they
are really connected. The HT just needs to be setup before memory. Is
there more than one CPU? Can the 780 do HT3?

Marc

Does the fam10 code work now? Patches for discuss.

[Myles Watson]

On Thu, Jun 25, 2009 at 2:46 AM, Bao, Zheng  wrote:
> amd_fam10_ht_sb_only.diff:
> I am not sure about this patch. Not sure to add signed-off-by line.
> Don't ack it before review it and say something.
>
> My board is Fam10 + 1 HT SouthBridge. It is close to dbm690t. So I
> set HT_CHAIN_UNITID_BASE as 0 and HT_CHAIN_END_UNITID_BASE as 1, even
> though I don't know well what they actually are.

HT_CHAIN_UNITID_BASE and HT_CHAIN_END_UNITID_BASE change the way the chain
is enumerated.

When HT devices are reset, their UNITID == 0  UNITID is very much like a pci
device number.  It is how the device claims configuration cycles.  All
devices implemented by a chip are offset by the unitid.

That means you can only send configuration cycles to the first device on the
chain.  After you check that device, if it has another HT link, you set the
unitid to something larger than 0 (say 0x20) and then you can access the
next device in the chain at unitid 0.

HT_CHAIN_END_UNITID_BASE is the unitid for the end of the chain.

For more information you'll have to read the code, because it seems to me
that these values get used for multiple purposes.

Base on currently fam10
> code, I have skip some code, otherwise the HT link can not be set up
> correctly. It is pretty like a workaround and my board can work in
> 1.8GHz (HT3). Doesn't the code in repository cover the mode of
> one HT processor + 1 HT SB device?

It does, as long as all the defines are correct.

To find out what the factory BIOS uses, you can look at lspci.

Thanks,
Myles

Does the fam10 code work now? Patches for discuss.

[Marc Jones]

On Thu, Jun 25, 2009 at 2:46 AM, Bao, Zheng wrote:
> amd_fam10_ht_sb_only.diff:
> I am not sure about this patch. Not sure to add signed-off-by line.
> Don't ack it before review it and say something.
>
> My board is Fam10 + 1 HT SouthBridge. It is close to dbm690t. So I
> set HT_CHAIN_UNITID_BASE as 0 and HT_CHAIN_END_UNITID_BASE as 1, even
> though I don't know well what they actually are. Base on currently fam10
> code, I have skip some code, otherwise the HT link can not be set up
> correctly. It is pretty like a workaround and my board can work in
> 1.8GHz (HT3). Doesn't the code in repository cover the mode of
> one HT processor + 1 HT SB device?

I assume that you are getting a failure since you skipped a section
and commented out a halt on error. What do you get for
AMD_CB_EventNotify?

You can get more information about bus numbering in the HTIOlink spec
and the device spec should have any requirements for bus numbering.
http://www.hypertransport.org/docs/tech/HTC20051222-0046-0008-Final-4-21-06....

But, I assume that the device will work like the 690, so the setting
should be ok but compare with the vendor bios.
> amd_fam10_mct_am2_rough.diff:
> The original code was pretty weird. It definitely can not
> be build correctly. This patch is only about building error.
>
> The mctardk4 seems to be for AM2. Based on the code and this
> patch, the memory seems to work but is unstable and unbearably
> slow. I need to dig it more.
>
> Since I am confused about this, it is not a signed-off-by patch.

AM2 was never built, just ported for reference. There wasn't a product
at the time. I dontt know if the Bx table will work for Cx.  You will
need to work with Tim and the BIOS group to get the settings.

You might need to add a fam10 version of the socket similar to the
socket f in /src/cpu/amd.

Marc

Does the fam10 code work now? Patches for discuss.

[Bao, Zheng]

About the MCT, the memory seems to work. But it takes coreboot nearly
one minute to "Uncompressing image to RAM.". I suddenly found words
above.
"*** Yes, the copy/decompress is taking a while, FIXME!"
It is printed in serengeti_cheetah_fam10/cache_as_ram_auto.c
Does it mean it is not just my problem? Do you know about it?

Zheng

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Friday, June 26, 2009 5:52 AM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: Does the fam10 code work now? Patches for discuss.

On Thu, Jun 25, 2009 at 2:46 AM, Bao, Zheng wrote:
> amd_fam10_ht_sb_only.diff:
> I am not sure about this patch. Not sure to add signed-off-by line.
> Don't ack it before review it and say something.
>
> My board is Fam10 + 1 HT SouthBridge. It is close to dbm690t. So I
> set HT_CHAIN_UNITID_BASE as 0 and HT_CHAIN_END_UNITID_BASE as 1, even
> though I don't know well what they actually are. Base on currently

fam10
> code, I have skip some code, otherwise the HT link can not be set up
> correctly. It is pretty like a workaround and my board can work in
> 1.8GHz (HT3). Doesn't the code in repository cover the mode of
> one HT processor + 1 HT SB device?

I assume that you are getting a failure since you skipped a section
and commented out a halt on error. What do you get for
AMD_CB_EventNotify?

You can get more information about bus numbering in the HTIOlink spec
and the device spec should have any requirements for bus numbering.
http://www.hypertransport.org/docs/tech/HTC20051222-0046-0008-Final-4-21
-06.pdf

But, I assume that the device will work like the 690, so the setting
should be ok but compare with the vendor bios.
> amd_fam10_mct_am2_rough.diff:
> The original code was pretty weird. It definitely can not
> be build correctly. This patch is only about building error.
>
> The mctardk4 seems to be for AM2. Based on the code and this
> patch, the memory seems to work but is unstable and unbearably
> slow. I need to dig it more.
>
> Since I am confused about this, it is not a signed-off-by patch.

AM2 was never built, just ported for reference. There wasn't a product
at the time. I dontt know if the Bx table will work for Cx.  You will
need to work with Tim and the BIOS group to get the settings.

You might need to add a fam10 version of the socket similar to the
socket f in /src/cpu/amd.

Marc

Does the fam10 code work now? Patches for discuss.

[Marc Jones]

On Thu, Jun 25, 2009 at 9:01 PM, Bao, Zheng wrote:
> About the MCT, the memory seems to work. But it takes coreboot nearly
> one minute to "Uncompressing image to RAM.". I suddenly found words
> above.
> "*** Yes, the copy/decompress is taking a while, FIXME!"
> It is printed in serengeti_cheetah_fam10/cache_as_ram_auto.c
> Does it mean it is not just my problem? Do you know about it?

Zheng,

Yes, that is not just your problem. There is a problem with XIP and
the decompression code that needs to be fixed. There was a patch
posted a while ago that hasn't been merged. I will try to look at it
next week.

Marc

Does the fam10 code work now? Patches for discuss.

[Bao, Zheng]

Can you tell me which is the patch or send it to me?

If I set CONFIG_COMPRESS to 1, the copy is fast. But if the code jumps
to RAM, the system will reboot. Is it also caused by same reason? Why
doesn't dbm690t have that problem?

Zheng

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Friday, June 26, 2009 10:59 PM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: [coreboot] Does the fam10 code work now? Patches for
discuss.

On Thu, Jun 25, 2009 at 9:01 PM, Bao, Zheng wrote:
> About the MCT, the memory seems to work. But it takes coreboot nearly
> one minute to "Uncompressing image to RAM.". I suddenly found words
> above.
> "*** Yes, the copy/decompress is taking a while, FIXME!"
> It is printed in serengeti_cheetah_fam10/cache_as_ram_auto.c
> Does it mean it is not just my problem? Do you know about it?

Zheng,

Yes, that is not just your problem. There is a problem with XIP and
the decompression code that needs to be fixed. There was a patch
posted a while ago that hasn't been merged. I will try to look at it
next week.

Marc

Does the fam10 code work now? Patches for discuss.

[Marc Jones]

On Sun, Jun 28, 2009 at 8:52 PM, Bao, Zheng wrote:
> Can you tell me which is the patch or send it to me?
>
> If I set CONFIG_COMPRESS to 1, the copy is fast. But if the code jumps
> to RAM, the system will reboot. Is it also caused by same reason? Why
> doesn't dbm690t have that problem?

I don't know about the reset. i think that the K8 does have the same
issue but the amount of code copied is much less. The fam10 code is
much larger.

The thread you want to look at is this one:
http://www.coreboot.org/pipermail/coreboot/2008-October/040885.html

I think that a better solution is to fix up the disable car and copy
code to cache the rom.  For example adding

set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK);

to set_init_ram_access() would address the issue. Maybe you can try that.

Marc

Does the fam10 code work now? Patches for discuss.

[Bao, Zheng]

The reset is caused by the fact that the memcpy doesn't work.

The patch works, while the way you told me doesn't. Maybe XIP_ROM_BASE
is the reason.

Zheng

-----Original Message-----
From: Marc Jones [mailto:[e-mail]] 
Sent: Tuesday, June 30, 2009 2:34 AM
To: Bao, Zheng
Cc: [e-mail]
Subject: Re: [coreboot] Does the fam10 code work now? Patches for
discuss.

On Sun, Jun 28, 2009 at 8:52 PM, Bao, Zheng wrote:
> Can you tell me which is the patch or send it to me?
>
> If I set CONFIG_COMPRESS to 1, the copy is fast. But if the code jumps
> to RAM, the system will reboot. Is it also caused by same reason? Why
> doesn't dbm690t have that problem?

I don't know about the reset. i think that the K8 does have the same
issue but the amount of code copied is much less. The fam10 code is
much larger.

The thread you want to look at is this one:
http://www.coreboot.org/pipermail/coreboot/2008-October/040885.html

I think that a better solution is to fix up the disable car and copy
code to cache the rom.  For example adding

set_var_mtrr(1, XIP_ROM_BASE, XIP_ROM_SIZE, MTRR_TYPE_WRBACK);

to set_init_ram_access() would address the issue. Maybe you can try
that.

Marc

Does the fam10 code work now? Patches for discuss.

[Marc Jones]

On Mon, Jun 29, 2009 at 8:56 PM, Bao, Zheng wrote:
> The reset is caused by the fact that the memcpy doesn't work.
>
> The patch works, while the way you told me doesn't. Maybe XIP_ROM_BASE
> is the reason.

That could be it. I think that maybe caching the entire ROM space
would be ideal. Use 4GB-ROM_SIZE instead of XIP sizes.

Marc

Does the fam10 code work now? Patches for discuss.

[Carl-Daniel Hailfinger]

On 30.06.2009 18:59, Marc Jones wrote:
> On Mon, Jun 29, 2009 at 8:56 PM, Bao, Zheng wrote:
> > The reset is caused by the fact that the memcpy doesn't work.
> >
> > The patch works, while the way you told me doesn't. Maybe XIP_ROM_BASE
> > is the reason.
>
> That could be it. I think that maybe caching the entire ROM space
> would be ideal. Use 4GB-ROM_SIZE instead of XIP sizes.

This may explode due to cache aliasing and cache size limitations. If
you really want to cache as much ROM as possible, please determine max
cache size at runtime to avoid CAR eviction.
AFAIK the formula is XIPsizemax=L2size-CARsize.

Regards,
Carl-Daniel

Patches long forgotten

[Peter Stuge]

Bao, Zheng wrote:
> Can you tell me which is the patch or send it to me?

This is why we need patchwork. Patrick, do you think you'll have a
chance to set it up or should I have a go?

//Peter

Patches long forgotten

[Joseph Smith]

On Thu, 2 Jul 2009 01:05:20 +0200, Peter Stuge  wrote:
> Bao, Zheng wrote:
> > Can you tell me which is the patch or send it to me?
>
> This is why we need patchwork. Patrick, do you think you'll have a
> chance to set it up or should I have a go?

YES, much agreed!

[Ward Vandewege]

On Fri, Jun 05, 2009 at 12:31:29AM +0200, Christian Leber wrote:
> On Thursday 04 June 2009 18:08:59 Marc Jones wrote:
>
> Hi Marc
> > Thanks, As Myles pointed out, my comment didn't make sense. Putting it
> > the errata is the next step.
>
> I attached a log without htx card, the port80 shows 0x35.

Same here.

And my log is exactly the same.

Thanks,
Ward.

[Ward Vandewege]

On Tue, Jun 02, 2009 at 10:39:56AM -0600, Marc Jones wrote:
> On Tue, Jun 2, 2009 at 9:57 AM, Ward Vandewege  wrote:
> > Hey Marc et al,
> >
> > I just received a h8dmr box with quad core CPUs (2372HE) and 32GB of ram. I
> > hacked up an h8dmr-fam10 patch which boots but still has tons of issues. Boot
> > log here:
> >
> > http://ward.vandewege.net/coreboot/h8dmr/fam10/h8dmr-c.cap
> >
> > First problem is that it complains about not finding the microcode rev id. So
> > I found the message below - did you ever get around to doing this?
> >
> > I also modified coreboot a little to print out the CPU version id (0x10042),
> > which is not yet listed in amd/amdfam10/raminit_amdmct.c.
>
> We added for one of the C2 parts. It should be easy enough to add the other one.
> You will also need to change Options.lb for the C2 microcode.
> Shanghai rev DA-C2: "mc_patch_0100009f.h"
> > A little further down in the log it seems I've got multiple cores talking at
> > once so that's something else I'll need to figure out.
>
> Yes, that stuff should be fine.

s/fine/fixed/ you mean?
> > It does actually get all the way to CBFS, but hangs after loadking the first
> > stage. There is also some slowness during/after ram detection.
>
> There is slowness around the cache disable / mem copy.. I think that
> someone posted a fix to the list at one point. It would require some
> searching.

This one?

http://www.coreboot.org/pipermail/coreboot/2008-October/040885.html

Peter actually acked it, but it was never committed. That piece of the code
has changed greatly in the past couple months though - the patch does not
commit anymore.

Thanks,
Ward.

[Marc Jones]

On Fri, Jun 5, 2009 at 7:36 PM, Ward Vandewege wrote:
> On Tue, Jun 02, 2009 at 10:39:56AM -0600, Marc Jones wrote:
> > On Tue, Jun 2, 2009 at 9:57 AM, Ward Vandewege  wrote:
> > > A little further down in the log it seems I've got multiple cores talking at
> > > once so that's something else I'll need to figure out.
> >
> > Yes, that stuff should be fine.
>
> s/fine/fixed/ you mean?

Not sure what I meant. It is hard to put a spinlock on the serial port
when you are XIP and CAR. So it may look bad but you can figure it out
if you need to....
> > > It does actually get all the way to CBFS, but hangs after loadking the first
> > > stage. There is also some slowness during/after ram detection.
> >
> > There is slowness around the cache disable / mem copy.. I think that
> > someone posted a fix to the list at one point. It would require some
> > searching.
>
> This one?
>
> http://www.coreboot.org/pipermail/coreboot/2008-October/040885.html
>
> Peter actually acked it, but it was never committed. That piece of the code
> has changed greatly in the past couple months though - the patch does not
> commit anymore.

Yes, that is it. It would be good to bring it up to date. I might have
some time next week if no one else wants to do it.

Marc