linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Peter Ryser <peter.ryser@xilinx.com>
To: Andrei Konovalov <akonovalov@ru.mvista.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: [PATCH] Fix for TLB errata on early Xilinx Virtex-II Pro silicon
Date: Thu, 18 Aug 2005 07:34:17 -0700	[thread overview]
Message-ID: <43049C69.1060801@xilinx.com> (raw)
In-Reply-To: <43046011.60504@ru.mvista.com>

None of the ML300 will need this workaround as the core voltage is 
slightly higher than recommended in the data sheet of Virtex-II Pro. An 
increased core voltage is one way to fix the TLB problem in early parts 
but it is not the right way as it can have a negative impact on other 
V2P features.

Since the ML300 configuration is used as the base for other boards the 
patch is still useful. However, all Virtex-II Pro FPGAs that are 
shipping today are based on newer core versions and do not show the TLB 
problem.

- Peter


Andrei Konovalov wrote:

> Grant Likely wrote:
>
>> Early versions of the Xilinx Virtex-II Pro have a TLB errata where
>> only even numbered TLB entries work correctly.  Occurs on chips where
>> PVR == 0x20010820 || 0x20010860
>>
>> See Record #14052, solution #12 in the Xilinx answers database
>> http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14052
>>
>> This patch adds a config option to use only even TLB entries on the 
>> V2Pro
>> It also makes a trivial change to the Kconfig so that Xilinx options 
>> depend
>> on VIRTEX_II_PRO instead of XILINX_ML300
>>
>> Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
>> ---
>>
>>  arch/ppc/kernel/head_4xx.S     |   11 +++++++++++
>>  arch/ppc/platforms/4xx/Kconfig |   28 ++++++++++++++++++++++------
>>  2 files changed, 33 insertions(+), 6 deletions(-)
>>
>> 322a82cd190a777e4ebe728cad2a2a3759039260
>> diff --git a/arch/ppc/kernel/head_4xx.S b/arch/ppc/kernel/head_4xx.S
>> --- a/arch/ppc/kernel/head_4xx.S
>> +++ b/arch/ppc/kernel/head_4xx.S
>> @@ -769,7 +769,11 @@ finish_tlb_load:
>>         /* load the next available TLB index.
>>         */
>>         lwz     r9, tlb_4xx_index@l(0)
>> +#if defined(CONFIG_VIRTEX_II_PRO_TLB_FIX)
>> +       addi    r9, r9, 2
>> +#else
>>         addi    r9, r9, 1
>> +#endif
>>         andi.   r9, r9, (PPC4XX_TLB_SIZE-1)
>>         stw     r9, tlb_4xx_index@l(0)
>
>
> I would also fix the comment in this file
> (it has nothing to do with the TLB fix but...):
>
> @@ -915,10 +919,10 @@ initial_mmu:
>     mtspr    SPRN_PID,r0
>     sync
>
> -    /* Configure and load two entries into TLB slots 62 and 63.
> -     * In case we are pinning TLBs, these are reserved in by the
> +    /* Configure and load an entry into TLB slot 63.
> +     * In case we are pinning TLBs, it is reserved in by the
>      * other TLB functions.  If not reserving, then it doesn't
> -     * matter where they are loaded.
> +     * matter where it is loaded.
>      */
>     clrrwi    r4,r4,10        /* Mask off the real page number */
>     ori    r4,r4,(TLB_WR | TLB_EX)    /* Set the write and execute 
> bits */
>
>> @@ -926,7 +930,14 @@ initial_mmu:
>>         clrrwi  r3,r3,10                /* Mask off the effective 
>> page number */        ori     r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
>>
>> +#if defined(CONFIG_VIRTEX_II_PRO_TLB_FIX)
>> +       /* Odd numbered TLB slots are broken on Xilinx V2Pro processors
>> +        * where PVR = 20010820 | 20010860
>> +        */
>> +        li      r0,62                    /* TLB slot 62 */
>> +#else
>>          li      r0,63                    /* TLB slot 63 */
>> +#endif
>>
>>         tlbwe   r4,r0,TLB_DATA          /* Load the data portion of 
>> the entry */        tlbwe   r3,r0,TLB_TAG           /* Load the tag 
>> portion of the entry */
>> diff --git a/arch/ppc/platforms/4xx/Kconfig 
>> b/arch/ppc/platforms/4xx/Kconfig
>> --- a/arch/ppc/platforms/4xx/Kconfig
>> +++ b/arch/ppc/platforms/4xx/Kconfig
>> @@ -161,11 +161,6 @@ config IBM_OCP
>>         depends on ASH || BAMBOO || BUBINGA || CPCI405 || EBONY || 
>> EP405 || LUAN || OCOTEA || REDWOOD_5 || REDWOOD_6 || SYCAMORE || WALNUT
>>         default y
>>
>> -config XILINX_OCP
>> -       bool
>> -       depends on XILINX_ML300
>> -       default y
>> -
>>  config IBM_EMAC4
>>         bool
>>         depends on 440GX || 440SP
>> @@ -201,6 +196,27 @@ config VIRTEX_II_PRO
>>         depends on XILINX_ML300
>>         default y
>>
>> +config VIRTEX_II_PRO_TLB_FIX
>> +       bool "Virtex-II Pro TLB bugfix"
>> +       depends on VIRTEX_II_PRO
>> +       default n
>> +       help
>> +         Early versions of the Xilinx Virtex-II Pro have a TLB 
>> errata where
>> +         only even numbered TLB entries work correctly.  Say Y here if
>> +         PVR == 0x20010820 || 0x20010860, or if your board crashes 
>> early
>> +         after enabling the MMU
>> +
>> +         See Record #14052, solution #12 in the Xilinx answers database
>> +         
>> http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=14052
>> +
>> +         It is safe to say Y here, but there is a performance impact.
>> +         Say N if unsure.
>> +
>> +config XILINX_OCP
>> +       bool
>> +       depends on VIRTEX_II_PRO
>> +       default y
>> +
>>  config STB03xxx
>>         bool
>>         depends on REDWOOD_5 || REDWOOD_6
>> @@ -208,7 +224,7 @@ config STB03xxx
>>
>>  config EMBEDDEDBOOT
>>         bool
>> -       depends on EP405 || XILINX_ML300
>> +       depends on EP405 || VIRTEX_II_PRO
>>         default y
>>
>>  config IBM_OPENBIOS
>
>
> I would drop the last chunk.
> I agree that VIRTEX_II_PRO_TLB_FIX and XILINX_OCP should depend on the
> chip (VIRTEX_II_PRO), but using EMBEDDEDBOOT or, say, U-Boot is at least
> board specific. Well, even the same board can use different bootloaders,
> but tying together EMBEDDEDBOOT and VIRTEX_II_PRO is even worse IMO.
>
> Otherwise the patch looks OK.
>
> These changes to head_4xx.S were tested OK on ML300:
> in both cases (odd numbered TLB slots used or not) there were no 
> problems.
> (For some unknown reason my ML300 doesn't need this workaround though
> 'cat /proc/cpuinfo' gets "revision        : 8.32 (pvr 2001 0820)")
>
> Thanks,
> Andrei
>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>

  reply	other threads:[~2005-08-18 14:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-17 20:05 [PATCH] Fix for TLB errata on early Xilinx Virtex-II Pro silicon Grant Likely
2005-08-18 10:16 ` Andrei Konovalov
2005-08-18 14:34   ` Peter Ryser [this message]
2005-08-18 15:03 ` Matt Porter
  -- strict thread matches above, loose matches on Subject: below --
2005-08-18 19:04 Grant Likely

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=43049C69.1060801@xilinx.com \
    --to=peter.ryser@xilinx.com \
    --cc=akonovalov@ru.mvista.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).