ac100 team mailing list archive

[Marc Dietrich <marvin24@xxxxxx>]

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 
you.

> >> > 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.

Marc