P5020 QorIQ Communications Processor Product Brief, Rev. 1
Features
Freescale Semiconductor24
supported which calculates Galois field (GF) based parity calculation for (where MULT = 1 performs
simple XOR) up to 16 sources. A variant supports calculation of two GF multiplies for use in calculating
XOR and RAID 6 Parity simultaneously without reading the input data twice. This command calculates
two GF multiplications across the sources and writes them to two destinations. The GF primitive
polynomial is programmable and thus supports common polynomials such as 0x11D and 0x14D.
In addition to classic storage acceleration, the RAID5/6 Engine provides some additional helpful functions
including the ability to fill or check a region based on a 128-bit value, incrementing value or using a LSFR
algorithm. A compare function is provided that compares two regions of memory and reports the result to
a result queue.
The RAID5/6 Engine supports ANSI T10 Data Protection Information and is capable of checking, adding,
removing and updating the Data Integrity Fields (DIF). All Reference and Application Tags seen during
an operation may be set to an initial value or that value can be incremented as blocks are processed by the
engine. Reference Tag, Application Tag can be configurable disabled/enabled from DIF function on per
command basis. It also supports IP checksum-based guard generation and checking (RFC 793), in addition
to the T10 CRC based guard.
3.10 Avoiding Resource Contentions Using
the QorIQ Trust Architecture
Consolidation of discrete CPUs into a single, multicore SoC and potential repartitioning of legacy software
on those cores introduces many opportunities for unintended resource contentions to arise, but the QorIQ
Trust Architecture can reduce the risk of these issues.
3.10.1 QorIQ Trust Architecture Benefits
A system may exhibit erratic behavior if the multiple CPUs do not effectively partition and share system
resources. While it can be challenging to prevent unintended resource contention, stopping malicious
software is much more difficult. Device consolidation combined with a trend toward embedded systems
becoming more open (or more likely to run third-party or open-source software on at least one of the cores)
creates opportunities for malicious code to enter a system.
The P5020 offers a new level of hardware partitioning support, allowing system developers to ensure
software running on any CPU only accesses the resources (memory, peripherals, etc.) that it is explicitly
authorized to access. This may not seem like a challenge in an SMP environment, because the OS performs
resource allocation for the applications running on it. However, it is a very difficult problem to overcome
in AMP environments where there may be multiple instances of the same OS, or even different OSes
running on the various CPU cores. Even OS protections in an SMP system may be insufficient in the
presence of malicious software.
3.10.2 e5500 Core MMU and Embedded Hypervisor
The P5020’s first line of defense against unintended interactions amongst the multiple CPUs/OSes is each
core’s MMU, which are configured to determine which addresses in the global address map the CPU is
able to read or write. If a particular resource (such as a portion of memory, peripheral device, and so on)
is dedicated to a single CPU, that CPU’s MMU is configured to allow access to those addresses (on
