ac100 team mailing list archive
Mailing list archive
Re: Stability Under Load
On Friday 19 August 2011 17:07:52 Gordan Bobic wrote:
> On Fri, 19 Aug 2011 16:26:37 +0200, Marc Dietrich <marvin24@xxxxxx>
> > On Friday 19 August 2011 16:10:43 Gordan Bobic wrote:
> >> On Fri, 19 Aug 2011 15:55:57 +0200, Marc Dietrich <marvin24@xxxxxx>
> >> > Am Freitag 19 August 2011, 11:18:31 schrieb Gordan Bobic:
> >> Well, my plan was to up the timings in
> >> arch/arm/mach-tegra/board-paz00-memory.c. Can you confirm whether
> >> the values there are in units of clock cycles? Or is it ns? Also which
> >> line corresponds to CAS? I can see RAS, RC, RCD, RRD, RFC, but can't see
> >> a value for CAS, which is, at least in theory, the most imporant one.
> > AFAIK, they are in cycles, but as I said, these values are not used
> > now (see the ifdef 0 at the end of the file). The reason is that I don't
> > have the values for 166 MHz on Micron and the Hynix tables caused
> > instabilities. So they are just there as a "reminder". But of course, you
> > can remove the ifdef and try yourself.
> Ah, OK. I missed that. Are the registers for setting the timings
> write-only? If not, it should be possible to dump out the default
> timings, should it not? They may not be correct, but it would at last
> give a good starting value for adjusting.
you can have a dump of the bcd using the bcd_dump (from the cbootimage tool from
chromos). These are the timings the bootloader programs.
> As for timings at 166 MHz vs. 333 MHz, most RAM chips I have seen have
> the spec sheet listing the timings in ns, so as the clock speed goes
> down, the cycle timings proportionately decrease (fewer cycles to wait
> at lower clock speed). So 166MHz timings _should_ be half the 333MHz
> timings (rounding up).
I don't know much about RAM and timings, so you may be right that they are based
on ns. I havn't found any useful info from the chip datasheets regarding timings
at different clock rates though.
> >> > [...]
> >> > It could also be related to power supply. What we do is modifing the
> >> > voltage supplies for serveral power sources. I had the feeling, that
> >> > Toshiba undervoltaged some CPU supplies in order to save energy (compared
> >> > to other boards). So I increased SM1 from 1V to 1.2V which may have been
> >> > wrong.
> >> How did you do this?
> > check board-paz00-power.c
> Just looking now. Are you referring to the REGULATOR_INIT macro and
> specifically the line that defines a struct with:
> REGULATOR_INIT(sm1, 725, 1200, true)?
> Are you saying that the default value as provided by Toshiba was
> REGULATOR_INIT(sm1, 725, 1000, true)?
correct. Please understand that these values are just best guesses on what the
Toshiba code does. In fact, kernel 2.6.38 has nothing to do with the original
code base because it's a total rewrite. You may check arch/arm/mach-
tegra/odm_kit/adaptations/pmu/tps6586x/nvodm_pmu_tps6586x.c for reference.
> Have you experienced significant instability with it set to 1000mV? Or
> was this change based on observation what other boards do? I'm wondering
> if the 20% increase in voltage (44% increase in thermal load!) might
> actually push things outside the thermal limits of cooling and thus be
> responsible for contributing to the instability.
No, neither produced problems here, but I haven't make the same stress tests as
> >> > It would be nice if you could test a .32 based kernel and see if
> >> > it also happens there. Also you could try your new model.
> >> I haven't tried 2.6.32 because I couldn't find one at the time, but
> >> I tried the old 2.6.29 and 2.6.38, and the instability on my old
> >> AC100 was the same. Haven't tried it on the new one yet. Do you think
> >> 2.6.32 could be behaving differently to both of those? If so, why? Where
> >> can I get the Tegra-patched 2.6.32 kernel?
> > gitorious.org/ac100? (on the front page)
> I'll try it, but I'm curious to know why you think 2.6.32 might be
> better in this sense than 2.6.29 and 2.6.38.
ah, you tried 2.6.29. I think that's also ok, but 2.6.32 is a bit newer. They
share most of the ac100 specific code, but there my be differences.