All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikhail Zolotaryov <lebon@lebon.org.ua>
To: Mike Nuss <mike@terascala.com>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Regression detecting memory size on PPC440EPx
Date: Mon, 05 Oct 2009 18:38:40 +0300	[thread overview]
Message-ID: <4ACA1300.6040105@lebon.org.ua> (raw)
In-Reply-To: <2C7DE72B9BD00F44BAECA5B0CBB873955CADF2@hermes.terascala.com>

Hi Mike,

Address width calculation is based on the DDR-controller configuration 
set by the bootloader. It would be helpful for further discussion if you 
could send DDR0_00..DDR0_44 register values and memory configuration 
used (no of banks, bank size, I/O width) to check calculations. Thanks.

P.S. Sequoia board also has DDR2 SDRAM from Micron.

Best regards,
Mikhail Zolotaryov


Mike Nuss wrote:
> There was a fix a while back called "Correct memory size calculation for
> Denali based boards" that corrected the data width detection in the 4xx
> bootwrapper.
>
> This seems to have had the unintended consequence of exposing another
> bug in the same code.  I have a board very similar to Sequoia, except
> that it uses a DDR2 DIMM module.  It uses a single 256MB DIMM.  After
> upgrading to the latest kernel, which includes the previously mentioned
> fix, U-Boot works fine, but the kernel detects 512MB instead, and of
> course, the kernel panics.
>
> The error seems to be in the calculation of row bits.  U-Boot's SPD
> detection says that the DIMM uses 13 bits, but I added some printf()s to
> the bootwrapper, and it is setting row to 14 instead.  I'm not too clear
> on how this code works; it calculates the row bits by subtracting the
> row from max_row, and maybe max_row is wrong?
>
> It looks like the data width bug canceled out this bug before, since
> these values end up changing the memory size by a factor of 2 (in
> opposite directions).
>
> Could someone with a better understanding of this code take a look?
>
> Thanks,
> Mike
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>   

  reply	other threads:[~2009-10-05 15:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 14:57 Regression detecting memory size on PPC440EPx Mike Nuss
2009-10-05 15:38 ` Mikhail Zolotaryov [this message]
2009-10-05 15:44   ` Mike Nuss
2009-10-05 16:05     ` Mikhail Zolotaryov
2009-10-05 16:23       ` Mike Nuss
2009-10-05 15:44   ` Valentine
2009-10-05 15:49     ` Mike Nuss
2009-10-09  8:19       ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACA1300.6040105@lebon.org.ua \
    --to=lebon@lebon.org.ua \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mike@terascala.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.