miriac® MPX-LS1088A
Multicore networking processor for high-performance communication
Module with advanced, high-performance data path and network peripheral interfaces
- 8 Arm® Cortex®-A53 64-bit cores at up to 1.6 GHz core frequency
- Up to 8 GB 64-bit DDR4 ECC RAM at 2100 MTps
- Temperature sensor
- All on board supply voltages are monitored by a separate µ-controller
- Control of on-board voltages and the reset logic offer a wide spectrum of custom functionality, even low-level safety functions
New cost effective MPX-2 System on Module form factor, connecting to a standard edge connector (MXM3.0 socket). Includes NXP® QorIQ® LS1088A CPU: 8 Arm® Cortex®-A53 64-bit cores at up to 1.6 GHz core frequency.
- Block diagrams
- Features
- Order Info
- miriac® MPX-LS1088A
- CRX05
- incl. BSP and accessories
- miriac® MPX-LS1088A
- CRX06-TSN
- incl. BSP and accessories
- Downloads
- FAQ
- Related Products
Architecture: | Arm® Cortex®-A53 |
Processor: | NXP® QorIQ® LS1088A CPU: 8-Arm® Cortex®-A53 64-bit cores at up to 1.6 GHz core frequency |
DRAM: | Up to 8 GB 32-bit DDR4 ECC RAM at 2100 MT/s |
Flash: | Up to 2 GB SLC NAND Flash & up to 64 MB QuadSPI Flash |
Flash Card: | SDHC |
Boot Flash: | QSPI, SD/MMC, NAND Flash |
eMMC: | 8-bit |
EEPROM: | Yes |
10GbE: | 2x XFI |
RGMII: | 2x |
SGMII: | 8x 1 Gbps, 2x 2.5 Gbps |
QSGMII: | 2x 5Gbs |
TSN / IEEE 1588: | Yes |
SerDes lanes: | 8x SerDes lanes at 10 Gbps |
USB 3.0: | 3x (Host / Client / OTG) |
PCIe: | 3x PCIe Gen3 (x4lane support) |
SATA: | 1x Gen3 |
FlexSPI: | 1x |
UART: | 2x DUART |
I2C: | 2x |
GPIOs: | Yes |
JTAG Debug Interface: | Yes |
Security: | Security Engine (SEC) SFP, CSU |
Power Supply Voltage: | Single 5 to 12 V DC input supply voltage range |
Typical Power Consumption: | 8.5 W |
Power Management: | Yes |
RTC: | Epson RX-8803LC |
Temperature: | 0 °C to 70 °C |
Optional Extended Temperature: | -40 °C to +85 °C |
Dimensions: | 62 mm x 82 mm |
Connector Type: | MPX-2 for MXM3.0 socket |
Software Support: | ▪ Linux ▪ VxWorks (on request) ▪ Others (on request) |
Additional: | ▪ Compatible variants available with QorIQ® LS1023A, LS1043A, LS1046A, LS1048A, ▪ Temperature sensor ▪ Dev Kit available for immediate start, includes power supply, cables. Linux on SD card |
Name | Code | Description | Status |
---|---|---|---|
miriac® MPX-LS1088A | 855606 | 8 Arm® Cortex®-A53, 1.6 GHz, 4 GB DDR4 w ECC, 16 MB NOR Flash, 512 MB Flash, 0 °C to 70 °C, w SEC | active |
Development Kit basic for miriac® MPX-LS1088A | 8559 | active | |
Development Kit pro for miriac® MPX-LS1088A | 8559 | active |
miriac-MPX-LS1088A
Q: We do not get Secure Boot working
A: Please verify which version of the processor you have since U-Boot outputs the System Version Register (SVR) which identifies the processor (including revision level). The SVR is contained in the line after the U-Boot version and starts with "SoC:" See attached screenshot. There are Versions of the SoMs which are assembled with LS1043A processors which do not have a Security Engine (SEC) and the SEC is needed for Secure Boot
Q: Inside LS10xx there is an engine that offloads the main CPU regarding the packet forwarding-routing between the MAC interfaces. Where can I get the microcode for this engine?
A: What you are referring to is the FMan microcode firmware. There are various versions of this depending on end-application. See FMan_uCode_README. Customer can download firmware from https://github.com/NXP/qoriq-fm-ucode
Q: Is there software available which will exercise the various CPU interfaces? Something like benchmarking or burn-in test software. The purpose is we want to measure the SOM power consumption while the CPU is being exercised.
A: There is a 10mOhm shunt on the base-board CRX-05 for this purpose. We use the StressAppTest software. Sources can be found here: https://github.com/stressapptest/stressapptest
Q: I have a question about security fuse programming. It looks like the SOM ST2 header will be used for this purpose. My understanding is that 1.8V needs to be supplied to the PROG-SFP pin during programming. Is the 1.8V supply from ST2 pin 1 sufficient to provide this programming power? In other words can we simply use a mating cable which loops ST2 pin 1 to pin2 for programming?
A: Yes, you can simply loop ST2 pin1 to pin2 for programming. However, note that you must first boot the board normally and then apply the 1.8V to program the fuses. Meaning that you cannot put a jumper over those 2 pins and then power the board on.
Q: How can we adapt the Reset Configuration Word (RCW) to our base board?
A: Check out the sources https://source.codeaurora.org/external/qoriq/qoriq-components/rcw with the following commit number:
bd6675518e6cb22f731c53407cc0631aa240f49f -> LSDK-20.12
after that, apply the MicroSys patches. The patches can be found under our Yocto meta layer directory “meta-microsys-layerscape/recipes-bsp/rcw/rcw“. After that you can adopt the RCW : e.g. rcw/mpxls1043/nand/MPX-LS1043A2_C1600_D1600_P400_3358_NAND.rcw In the rcw/mpxls1043/ls1043a.rcwi file you will find all the reset configuration pins that can be set.
Q: I have a question regarding the 1.8V GPIOs. We currently use the following GPIOs GPIO4, GPIO5, GPIO6, GPIO7, GPIO8. What mechanism can I use to access them in Linux?
A: On the Command line you can...
Q: We are trying to bring up the SPI interface. Enabling SPI in the device tree results in the following error messages:
[ 3.155114] fsl-dspi 2100000.dspi: can‘t get bus-num
[ 3.160085] fsl-dspi: probe of 2100000.dspi failed with error -22
We have verified that RCW[SPI_EXT]=000 and RCW[SPI_BASE]=00. What are we missing?
A: Basically you need an entry in your Device Tree...
Q: We are using MicroSys LS1046 CPU board, and we built our own baseboard, now we have a problem with ethernet.We are using only one Marvell 88E1512 PHY which has RGMII interface, the PHY address was set to 5’h0, but your CRX05 Baseboard has 4 88E1512 PHYs, 1 PHY in RGMII, and it is PHY address is 5’h03, so our Ethernet doesn’t work.
My question:
1) How can we set the our 88E1512 PHY address to 5’h03 to match your software, ( as I downloaded the latest 88E1512 Datasheet, Marvell says this PHY address can only be 5’h0 or 5’h1, how did you set your RGMII PHY address to 5‘h3)
2) Or What SW code needs to be changed to tell the SW(Unoot/Linux) to use RGMII PHY at address 5’h3 to make it work, we tried to change your hardcoded PHY address mapping to 5’h0 (in uboot\git\include\configs \mpxls1046.h), but it still doesn’t work
A: First, a general comment. Whenever you design...
Q: I am in the process of bringing up my SOM carrier board and I have a question. My design has two Ethernet PHYs (88E1512) connected to each of the SOM’s RGMII interfaces (block diagram attached), but neither RGMII interface is able to establish a link. U-boot is reporting that the LS1046A MAC #9 and #6 have been assigned to these ports (shown below). But your documentation shows that only MAC #3 and #4 supports RGMII. How do I change my MAC assignment to #3 and #4?
A: The network setup for U-Boot on MPXLS1046 is done in eth.c in boards/microsys/mpxls1046 located in the U-Boot source tree. In this file there is a function called board_eth_init(). This function does the network setup for U-Boot. There you have to tell U-Boot which network interfaces are enabled or disabled and how the PHYs are connected to the interfaces. Please review this function and adjust everything according to your carrier.
Q: We have the need to change the thermal shutdown limit to 95° C. May I ask for instructions on how to do that?
A: Linux command "sensors" can be used to show temp. temp1 is the TMP451 Sensor chip and temp2 measures the temperature at the substrate of the LS1046A.
root@mpxls1046:/sys/class/i2c-adapter/i2c-0/0-004c/hwmon/hwmon0# sensors lm90-i2c-0-4c
Adapter: 2180000.i2c
temp1: +60.0 C (low = +0.0 C, high = +85.0 C) (crit = +85.0 C, hyst = +75.0 C)
temp2: +63.5 C (low = +0.0 C, high = +85.0 C) (crit = +108.0 C, hyst = +98.0 C)
Q: I want to read or write internal phy registers under Linux with phytool utility but it’s not running. It returns to me the following message
# phytool read eth0/0/5
error: phy_read (-22)
These regiters are accessible under uboot. What’s happening ? How you read or write these registers under Linux ?
A: Don’t include phytool in the standard rootfs but you can download it to the target, build it and run it.
# unzip phytool-master.zip
# cd phytool-master
# make all
# ./phytool read fm1-mac3/3/2
Q: Just reaching out to you to see if you could offer up some help to our software guys. We are working on our encryption throughput and having troubles determining whether we are making use of all 4 cores in this processor or just one. Would you have any assistance you could offer on this topic? Is there a way for us to see which cores we are making use of?
A: For CPU utilisation you can use the linux command mpstat.
For example:
# mpstat -P ALL 1
NXP documentation “QORIQ-SDK-2.0-IC-REV0.pdf”, chapter 9.7 describes how to set up the encryption engine: https://www.nxp.com/docs/en/supporting-information/QORIQ-SDK-2.0-IC-REV0.pdf
Q: I have a question for the RGMII bus on the LS1046. The only requirement I've found for the PCB layout is https://community.nxp.com/thread/447516
but is the part that is routed on the SOM already matched in length or should the trace length on our main board be compensated for this ?
A: You will find all required timings in the NXP documentation QorIQ LS1046A, LS1026A Data Sheet, Rev. 0, 02/2017 or later revisions. Chapter 3.10.6.2 RGMII AC timing specifications says “Data to clock input skew at transceiver” shall be 1.0<x<2.6ns and notes that at least 1.5ns shall be applied. We have no such delay implemented on the SOM but this needs to be done on the base board. (Receiver)
In order to avoid ~30cm of trace length (with the possibility for adjustments) most PHY’s have implemented a pad delay register for adjustment.
e.g. Marvell 88E1512 provides:
„Four RGMII timing modes including integrated delays – This eliminates the need for adding trace delays on the PCB“.
Please check if the PHY you use provides for such compensation
Q: In our environment, we need solutions that are available over a very long period of time (up to 15 years). How long are your modules available?
A: Using NXP CPUs on our SoMs we are able to provide an availability of 15 years from the time of the launch of the CPU. With LTB and long-time stocking we are even able to extend this period.