Stefan Roese wrote:
> On Thursday 27 March 2008, Larry Johnson wrote:
>> Yes, we normally use ECC modules in our testing. I've been looking at a
>> patch for "initdram()" Denali SPD, but I've been waiting to see how your
>> "CFG_MEM_TOP_HIDE" patch would turn out.
>>
>> As things stand now, can I
On Thursday 27 March 2008, Larry Johnson wrote:
> Yes, we normally use ECC modules in our testing. I've been looking at a
> patch for "initdram()" Denali SPD, but I've been waiting to see how your
> "CFG_MEM_TOP_HIDE" patch would turn out.
>
> As things stand now, can I assume that boards using th
Stefan Roese wrote:
> [...]
>
> BTW: Can you test your board with ECC modules? We need to change the ECC code
> in the Denali SPD routines to not touch the last 256 bytes here too. Best
> would be if you could provide a patch for this. :)
>
> Thanks.
>
> Best regards,
> Stefan
Yes, we normall
Hi Larry,
On Thursday 20 March 2008, Larry Johnson wrote:
> Having multiple implementations of the 440EXp SDRAM setup code is, in
> itself, less than ideal. One alternative is to have a 440EPX board with
> on-board SDRAM chips fake an array of SPD bytes describing the chips,
> and pass it to the
Stefan Roese wrote:
> Hi Wolfgang,
>
> On Thursday 20 March 2008, Wolfgang Denk wrote:
>>> This patch adds this workaround for the following 440EPx boards:
>>> sequoia, lwmon5. Others should probably follow this example.
>> OK, the default configs for Sequoia doesn't use shared log buffer, and
>>
On Thursday 20 March 2008, Dave Littell wrote:
> This may not be the "better, more generic solution", but I just added a
> CONFIG_CHIP_11_ERRATA option and code in lib_ppc/board.c to trim off
> only 256 bytes before the optional log buffer is carved out.
OK. I'll submit a similar patch in a short
On Thursday 20 March 2008, Wolfgang Denk wrote:
> At the cost of an #ifdef, this could be added to the memory
> reservation code in "lib_ppc/board.c", i. e. somewhere after
>
> ...
> 427 * Reserve memory at end of RAM for (top down in that order):
> 428 * - kernel log buffer
>
On Mar 20, 2008, at 6:16 AM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>
>> I don't like this either. But I have not come up with a "generic"
>> solution
>> till now. It's not so easy since the 440EPx SDRAM setup code is
>> sometimes
>> common (cpu/ppc4xx/denali_spd_ddr
Stefan Roese wrote:
> Hi Wolfgang,
>
> On Thursday 20 March 2008, Wolfgang Denk wrote:
>>> This patch adds this workaround for the following 440EPx boards:
>>> sequoia, lwmon5. Others should probably follow this example.
>> OK, the default configs for Sequoia doesn't use shared log buffer, and
>>
In message <[EMAIL PROTECTED]> you wrote:
>
> I don't like this either. But I have not come up with a "generic" solution
> till now. It's not so easy since the 440EPx SDRAM setup code is sometimes
> common (cpu/ppc4xx/denali_spd_ddr2.c) and sometimes board specific. And it
> gets even more comp
Hi Wolfgang,
On Thursday 20 March 2008, Wolfgang Denk wrote:
> > This patch adds this workaround for the following 440EPx boards:
> > sequoia, lwmon5. Others should probably follow this example.
>
> OK, the default configs for Sequoia doesn't use shared log buffer, and
> the lwmon5 uses CONFIG_ALT
Hello Stefan,
in message <[EMAIL PROTECTED]> you wrote:
> Since 440EPx/GRx has problems with accessing the last 256 bytes of SDRAM via
> the Denali DDR/DDR2 controller, we set CONFIG_PRAM to 1 and reserve 1kByte
> of protected RAM. This way this memory will not get "touched" by U-Boot. And
> by pa
Since 440EPx/GRx has problems with accessing the last 256 bytes of SDRAM via
the Denali DDR/DDR2 controller, we set CONFIG_PRAM to 1 and reserve 1kByte
of protected RAM. This way this memory will not get "touched" by U-Boot. And
by passing "mem=${mem}" to the Linux kernel, Linux will not use this a
13 matches
Mail list logo
