• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 700 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ARM errata options applicable to AM335x processors

Gokul cg
Intellectual 420 points

Hi,

I am using ti-sdk-am335x-evm-07.00.00.00 and it comes along with linux-3.12.10-ti2013.12.01.  When i am going to compile linux , there are few options unchecked options in "make menuconfig window" ,which is applicable to ARM processors . Can anyone reply whether following errata needs to be checked when we compile for TI am335x sitara processors ?

./ -> System Type->

  │ │                               [ ] ARM errata: Stale prediction on replaced interworking branch (NEW)                               │ │  
  │ │                               [ ] ARM errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID (NEW)                │ │  
  │ │                               [ ] ARM errata: possible faulty MMU translations following an ASID switch (NEW)                      │ │  
  │ │                               [ ] ARM errata: A data cache maintenance operation which aborts, might lead to deadlock (NEW)        │ │  
  │ │                               [ ] ARM errata: incorrect instructions may be executed from loop buffer (NEW) 

Thanks and regards

Gokul CG [gokul.g@kalkitech.in]

  • 0
    TI__Guru**** 393215 points

    Hi,

    I have asked the SW team to look at this.

  • 0
    TI__Guru**** 161600 points

    Hi,

    When searching for info about those erratas, I came accross the following info:

    ARM errata: Stale prediction on replaced interworking branch (NEW) - This option enables the workaround for the 430973 Cortex-A8 (r1p0..r1p2) erratum

    ARM errata: TLBIASIDIS and TLBIMVAIS operations can broadcast a faulty ASID (NEW) - On versions of the Cortex-A9 prior to r2p0

    ARM errata: possible faulty MMU translations following an ASID switch (NEW) - This option enables the workaround for the 754322 Cortex-A9 (r2p*, r3p*) erratum

    ARM errata: A data cache maintenance operation which aborts, might lead to deadlock (NEW) - This option enables the workaround for the 775420 Cortex-A9 (r2p2, r2p6,r2p8,r2p10,r3p0) erratum

    ARM errata: incorrect instructions may be executed from loop buffer (NEW)  - This option enables the workaround for the erratum 773022 affecting Cortex-A15 (r0p4)s

    As you can see from the descriptions, these erratas do not seem to impact AM335x SoCs.

    I've used the default menuconfig on my AM335x boards, and haven't encountered a problem so far.

    Best Regards,

    Yordan

  • 0 in reply to Yordan Kovachev
    Mastermind 8040 points

    For completeness, the ARM errata which are relevant to the AM335x are:

    [468413] "Incorrect L2 cache eviction can occur when L2 is configured as an inner cache and configured to use 'write allocate'." (Irrelevant, there's no reason why you'd configure L2 as inner cache)

    [628216] "A performance counter overflow event may be lost (including associated interrupt)" (Poll the counters at least once per 231 cycles to keep track of them if you care.)

    [728018] "Cleaning or invalidating cache by MVA to a region marked non-cacheable, device, or strongly ordered may result in stale data or processor deadlock." (This is probably the most serious one, and requires cleaning cache before unmapping a cacheable memory region or changing its type to non-cacheable.")

    [687067] "When 'BTB invalidate' operations are enabled (not default, not recommended), the 'BTB invalidate by MVA' operation actually writes data from an uninitialized debug register into the BTB." (This is only an issue because secure ROM inexplicably enables BTB invalidates. I recommend disabling them via a secure monitor call.)

    [693270] "Taking a debug watchpoint is incorrectly prioritized over a precise data abort occurring simultaneously on the same data access." (This is only a concern for debuggers.)

    [715847] "If the integer-to-float conversion VCVT.f32.u32 is performed on the input value 0xFFFFFF01 with the FPSCR configured with Default-NaN and Flush-to-zero enabled (both recommended) and rounding mode RP (round up), it will produce the result 0x00000000 instead of the correct result 0x4f800000." (No workaround, floating point code will have to avoid this combination of settings.)