Resend: [PATCH] add h8dmr fam10 target

[Ward Vandewege]

Ping - can I get an ack please? I've got a machine running this port for
almost 2 months now, so it's at least somewhat useable. The outstanding
issues below are not related to this port as such.

Thanks,
Ward.

---------------------------------

See attached.

There are a number of outstanding issues:

* we don't have the mc_patch_01000086.h CPU ucode file yet which is
referenced in a comment in src/mainboard/supermicro/h8dmr_fam10/Options.lb.
AMD has not released it yet. This is not a problem specific to this port.

* I'm seeing toolchain issues. I can't get this tree to compile correctly with
gcc 4.3 (32 bit) - there is an optimization issue where certain parts of the
CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
disappears. This is probably not a problem related to this port specifically.

* setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the boot
shortly after the warm reset triggered by the MCP55 code. I think this too
might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).

* during startup, the CPU cores talk through each other on serial for a
while. Again, not an issue specific to this port.

* to avoid very slow LZMA decompression I use this port with LZMA compression
disabled in CBFS. I'm not sure what's causing this particular slowness.

Thanks,
Ward.

[Peter Stuge]

Ward Vandewege wrote:
> Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912
> fam10 and h8dmr k8 targets.
>
> Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with
> this, and to Arne for doing the s2912 fam10 port.
>
> Build and boot tested.
>
> Signed-off-by: Ward Vandewege

Acked-by: Peter Stuge

[Ward Vandewege]

On Tue, Sep 22, 2009 at 03:29:05PM +0200, Peter Stuge wrote:
> Ward Vandewege wrote:
> > Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912
> > fam10 and h8dmr k8 targets.
> >
> > Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with
> > this, and to Arne for doing the s2912 fam10 port.
> >
> > Build and boot tested.
> >
> > Signed-off-by: Ward Vandewege
>
> Acked-by: Peter Stuge

r4693.

Thanks,
Ward.

[Marc Jones]

On Wed, Sep 30, 2009 at 8:48 AM, Ward Vandewege  wrote:
> On Tue, Sep 22, 2009 at 03:29:05PM +0200, Peter Stuge wrote:
> > Ward Vandewege wrote:
> > > Add supermicro h8dmr fam10 target. This is largely a mashup of the tyan s2912
> > > fam10 and h8dmr k8 targets.
> > >
> > > Many, many thanks to Marc, Myles, Patrick and Stepan for all their help with
> > > this, and to Arne for doing the s2912 fam10 port.
> > >
> > > Build and boot tested.
> > >
> > > Signed-off-by: Ward Vandewege
> >
> > Acked-by: Peter Stuge
>
> r4693.
>
> Thanks,
> Ward.

Kudos for this port and check-in! Great to see Fam10 support expanding.

Marc

[ron minnich]

On Tue, Sep 22, 2009 at 6:17 AM, Ward Vandewege  wrote:
> Ping - can I get an ack please? I've got a machine running this port for
> almost 2 months now, so it's at least somewhat useable. The outstanding
> issues below are not related to this port as such.
>
> Thanks,
> Ward.
>
> See attached.
>
> There are a number of outstanding issues:
> we don't have the mc_patch_01000086.h CPU ucode file yet which is
>
> referenced in a comment in src/mainboard/supermicro/h8dmr_fam10/Options.lb.
> AMD has not released it yet. This is not a problem specific to this port.
> I'm seeing toolchain issues. I can't get this tree to compile correctly with
>
> gcc 4.3 (32 bit) - there is an optimization issue where certain parts of the
> CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
> disappears. This is probably not a problem related to this port specifically.

I don't think it's toolchain, with this description. This sounds more
like a cache issue.
> setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the boot
>
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).

There ought to be a warning in the target .config to this effect, else
others will be confused.
> during startup, the CPU cores talk through each other on serial for a
>
> while. Again, not an issue specific to this port.

Geez, I thought all the discussion had fixed that :-)
> to avoid very slow LZMA decompression I use this port with LZMA compression
>
> disabled in CBFS. I'm not sure what's causing this particular slowness.

This and the other problem sure sound like a few weird possibilities.
What do the MTRRs look like once booted? Is there any chance you are
somehow running on a core that is not set up correctly (this used to
really happen sometimes).

I think this description of problems with the port ought to be in the
target file in a README.

ron

[ron minnich]

On Tue, Sep 22, 2009 at 6:42 AM, ron minnich  wrote:
> I think this description of problems with the port ought to be in the
> target file in a README.

^^directory, sorry

ron

[Ward Vandewege]

On Tue, Sep 22, 2009 at 06:43:10AM -0700, ron minnich wrote:
> On Tue, Sep 22, 2009 at 6:42 AM, ron minnich  wrote:
> > I think this description of problems with the port ought to be in the
> > target file in a README.
>
> ^^directory, sorry

I have done so. I need to do some more testing on this hardware, but it's in
production so that's a little hard right now. I'm going to work on a
supermicro h8dme fam10 port now, which is a very similar board, so hopefully
I'll be able to try the suggestions in this thread on that.

Thanks!
Ward.

> Ping - can I get an ack please? I've got a machine running this port for
> almost 2 months now, so it's at least somewhat useable. The outstanding
> issues below are not related to this port as such.
>
> Thanks,
> Ward.
>
> See attached.
>
> There are a number of outstanding issues:
> we don't have the mc_patch_01000086.h CPU ucode file yet which is
>
> referenced in a comment in
> src/mainboard/supermicro/h8dmr_fam10/Options.lb.
> AMD has not released it yet. This is not a problem specific to this port.
> I'm seeing toolchain issues. I can't get this tree to compile correctly
>
> with
> gcc 4.3 (32 bit) - there is an optimization issue where certain parts of
> the
> CBFS code execute very slowly. With gcc 3.4 (32 bit) that slowness
> disappears. This is probably not a problem related to this port
> specifically.
> setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the
>
> boot
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).
> during startup, the CPU cores talk through each other on serial for a
>
> while. Again, not an issue specific to this port.
> to avoid very slow LZMA decompression I use this port with LZMA
>
> compression
> disabled in CBFS. I'm not sure what's causing this particular slowness.

Try enabling CONFIG_XIP_ROM_BASE.
It solved the same problem for me in my board.
> Thanks,
> Ward.
>
> DISCLAIMER: This e-mail and any attachment (s) is for authorised use by
> the
> intended recipient (s) only. It may contain proprietary material,
> confidential
> information and/or be subject to the legal privilege of iWave Systems
> Technologies Private Limited. If you have received this message in error,
> please notify the originator immediately. If you are not the intended
> recipient, you are notified that you are strictly prohibited from
> retaining,
> using, copying, alerting or disclosing the content of this message. Thank
> you
> for your co-operation.

------------------------------------------------------------------------------- 
DISCLAIMER: This e-mail and any attachment (s) is for authorised use by the
intended recipient (s) only. It may contain proprietary material, confidential
information and/or be subject to the legal privilege of iWave Systems
Technologies Private Limited. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from retaining,
using, copying, alerting or disclosing the content of this message. Thank you
for your co-operation. 
------------------------------------------------------------------------------

[Myles Watson]

> setting CONFIG_DEFAULT_CONSOLE_LOGLEVEL lower than 8 simply hangs the
>
> boot
> shortly after the warm reset triggered by the MCP55 code. I think this too
> might be a toolchain problem (but I see it on gcc 3.4 as well as 4.3).

Could it be a side effect of one of the writes, or a race condition?

Thanks,
Myles