From: Valentine <vbarshak@ru•mvista.com>
To: Mikhail Zolotaryov <lebon@lebon•org.ua>
Cc: linuxppc-dev@lists•ozlabs.org, Mike Nuss <mike@terascala•com>
Subject: Re: Regression detecting memory size on PPC440EPx
Date: Mon, 05 Oct 2009 19:44:53 +0400 [thread overview]
Message-ID: <4ACA1475.1000101@ru.mvista.com> (raw)
In-Reply-To: <4ACA1300.6040105@lebon.org.ua>
AFAIK, u-boot just writes pre-defined values to the memory controller
registers. It doesn't do any chiptype/memsize detection. These values
are set for Sequoia and may not suite your board. So you probably need
to adjust the u-boot to make linux detect the memory size correctly.
Thanks,
Val.
Mikhail Zolotaryov wrote:
> 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
>>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists•ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
next prev parent reply other threads:[~2009-10-05 16:03 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
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 [this message]
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=4ACA1475.1000101@ru.mvista.com \
--to=vbarshak@ru$(echo .)mvista.com \
--cc=lebon@lebon$(echo .)org.ua \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=mike@terascala$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox