When customer’s ethernet PCS could not link up, this article will give a guide how to debug it step by step based on the T1024. Many ethernet is configured by the SerDes, so how to confirm the link error is caused by the SerDes or the PCS itself. This article will give some clues. Serdes Lane&pins First check which SerDes lane the you are using, please confirm the SerDes land in the QorIQ T1024 Reference Manual. Such as configuration below, the user case set the SRDS_PRCTL_S1=0x05B in the RCW[128:136], the application will utilize the SGMII.m1 and SGMII.m2. This article will consider SGMII.m1 as an user case, now the SGMII will in the Frame Manager, MAC1. Check the SerDes Lane Assignments to confirm the Lane of the SerDes, for the SGMII.m1, the specific lane pins name would be SD1_TX3P/N and SD1_RX3P/N. it could be recognized as Lane 3. MAC number is not related to the Serdes lane number, should confirm the specific table to get the pins. Any hardware test with this ethernet should related the pins, see the component pin number below. You could test the eye diagram of RX pins of this Lane to confirm if the frequency is correct. if you set this Lane to SGMII 1.25G, you could confirm the speed is set correctly by the eye diagram. Eye diagram above, just show the speed of the SerDes. That is very important when loopback correctly, but could to connect to other device. How to confirm the SerDes link up Please find the Lane register in the QorIQ T1024 Reference Manual. In this user case it’s Lane 3, so should read out the Lane 3 registers to confirm if the SerDes Lane 3 work well. Such as below: # Lane 3 md.l 0xFFE0EA8C0 1 - aa611080 # LN3GCR0 md.l 0xFFE0EA8C4 1 - 101c4019 # LN3GCR1 md.l 0xFFE0EA8CC 1 - 00002800 # LN3SSCR0 md.l 0xFFE0EA8D0 1 - 0f0fc01f # LN3RECR0 md.l 0xFFE0EA8D4 1 - 0f0f0fa8 # LN3RECR1 md.l 0xFFE0EA8D8 1 - 00003006 # LN3TECR0 md.l 0xFFE0EA8E0 1 - 39000400 # LN3TTLCR0 md.l 0xFFE0EA8E4 1 - 00000000 # LN3TTLCR1 md.l 0xFFE0EA8F4 1 - 00000000 # LN3TCSR1 md.l 0xFFE0EA8FC 1 - 04000000 # LN3TCSR3   SerDes_LNnTCSR3 is an important debug test register, the CDR_LCK is to check if the CDR locked or not. CDR_LCK=0 means a valid bit stream is not detected. As a test, you could put the lane in loopback mode LN2TCSR3[LPBK_EN]=01. The CDR should lock in digital loopback mode (internal loopback). If not, there could be an issue with the device itself. So, if you could set the LPBK-EN to “01” Loopback Mode, it will set the SerDes’s own TX and RX signals in Loopback Mode to exclude external signals, then check the CDR_LCK again, if it’s 1, then SerDes itself works well. Anyway, CDR_LCK should always be set. In the “md.l 0xFFE0EA8FC 1 - 04000000 # LN3TCSR3”, the CDR_LCK=0, suspect the SerDes level issue. The normal status should be: => md fe0ea8fc 1 fe0ea8fc: 08000000 How to confirm the PCS link up The MAC and PHY registers should get the details from the T1024DPAArm, QorIQ T1024 Data Path Acceleration Architecture (DPAA) Reference Manual Find the offset address in the DPAARM. For the SGMII MAC address should be offset+0x1000. Follow the 6.5.4 MDIO Ethernet Management Interface usage in the T1024DPAARM to read the MDIO registers. In this application, SGMII1, MAC1, you could find the MAC1 address would be FM1_mEMAC1: 4E_0000, so FM1_mEMAC1 MDIO registers would be 4E_1000h. In the user case, the protocol is SGMII, should follow the 6.5.4.3 Clause 22 Read Flow in the T1024DPAARM. 6.5.4.3 Clause 22 Read Flow 1) Wait for MDIO_CFG[BSY] = 0. 2) Write MDIO_CTL with proper PHY_ADDR and REGISTER_ADDR and with bit 16 set. 3) Wait for MDIO_CFG[BSY] = 0. 4) If the addressed PHY did not respond then MDIO_CFG[MDIO_RD_ER] is set. Otherwise read MDIO_DATA value. In this user case, should read the MDIO_SGMII_SR, you could find the register definition in the QorIQ T1024 Reference Manual, 30.5.5 1000Base-KX PCS MDIO Memory Map/Register Definition The key bits would below: Here the user case result: When you read MDIO_SGMII_SR, please use manual input that can meet the delay time requirement. If you could not input manually, please follow the flow, " Wait for MDIO_CFG[BSY] = 0" before read MDIO_DATA value. Read SGMII1 MDIO Registers === Serdes Test 1 === 0xFFE0EA8FC value: 0x08000000 Dump PCS0 Registers 0xFFE4E1030-0xFFE4E103C: 0x40001408 0x00000000 0x00001340 0x00001340 Select 0x8002 ,devmem 0xFFE4E1034 32 0x8002 Read: 0x00000083 Select 0x8003 ,devmem 0xFFE4E1034 32 0x8003 Read: 0x0000E400 Select 0x8001 ,devmem 0xFFE4E1034 32 0x8001 Serdes0 Status: 0x00000029 Select 0x8001 devmem 0xFFE4E1034 32 0x8001 Serdes0 Status: 0x0000002D Select 0x8001, devmem 0xFFE4E1034 32 0x8001 Serdes0 Status: 0x0000002D The first time, it’s not link, LINK_STAT is 0(0x00000029), and then it’s turn to 1(0x0000002D). Now the PCS link up and the HW loopback checking is completely.

Issue description. The CodeWarrior ®  TAP enables target system debugging via a standard debug port (usually JTAG) while connected to a developer's workstation via Ethernet or USB. This the hardware debug tool(JTAG debug tool) to debug the DN MPU. You could find the tool from below link https://www.nxp.com/design/design-center/development-boards-and-designs/CW_TAP To debug the Layerscape MPU, should select CWH-CTP-BASE-HE and CWH-CTP-CTX10-YE In fact, the CWH-CTP-CTX10-YE will adapt the different signal definition, one connector will be insert to the CWH-CTP-BASE-HE, and another one(totally 10 pins) will be used to debug the Layerscape MPU. You could find the definition of the JTAG connector(CWH-CTP-CTX10-YE, 10pins) on the Layerscape board. Pin 10 (SRST)is the signal of this documents to should add workaround.     In the CodeWarrior TAP Probe User Guide, the SRST(SRST_B) is Open-drain. So the voltage of this signal should be decided by the pull-up voltage connect to it. See the schematics part below, pin 10 (JTAG_RST_B) should be 1.8V, but in fact it’s not.   The test signal will be exceed 1.8V to about 2.6V.   If you connect this pin directly to the Layerscape MPU, it will violate the SPEC of the VIN. Workaround. Workaround for the user would be to use an external circuit (level shifter/limiter) for the affected signal(s). level-shifter/limiter CWTAP <=> probe tip <=> (level-shifter/limiter) <=> target Please refer to FRWYLS1046A-PA,  use the AND gate 74AUP1G11GW similar components which the Overvoltage tolerant inputs to 3.6 V.     Logic Device Customer could also refer to LS1046ARDB CPLD LCMXO1200C-3FTN256C and LX2160ARDB CPLD EPM2210F256C5N, even the CPLD IO Voltage is 1.8V, no issue with 2.6V input on 1.8V IO ports.    

Follow these steps to update the Linux kernel image and device tree on the eMMC card. NOTE: Below steps are valid for both LX2160ARDB Rev 1.0 and Rev 2.0 revisions. Compiling Linux kernel images and device tree   On Linux host, clone the repository with Linux kernel image and device tree: $git clone https://source.codeaurora.org/external/qoriq/qoriq-components/linux $ cd Linux $ git checkout -b <new branch> <start point> For example, $ git checkout -b LSDK-20.04-V5.4 LSDK-20.04-V5.4 where LSDK-20.04-V5.4 refers to a tag in the format LSDK-<LSDK version>- V<kernel version> $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfig lsdk.config If you want to make changes to the device tree, open and edit arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts  You can make changes in the Linux kernel source code also if required. $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- The binary kernel image Image and compressed kernel image Image.gz are in arch/arm64/boot/. The device tree blob fsl-lx2160a-rdb.dtb is in arch/arm64/boot/dts/freescale/. Copying the compiled kernel images and device tree to the eMMC card   Step1: Copy the kernel images and device tree from Linux host machine Ensure the eMMC card available on the reference board. Check DIP switch settings for the desired boot type. Power on the board and let the board boot to LSDK distro prompt. In case LSDK image is not deployed on the storage device on the board, execute the following command under U-Boot prompt to boot the board to TinyDistro. For FlexSPI NOR boot: => run xspi_bootcmd For SD/eMMC boot: => run sd_bootcmd Log in to LSDK distro as root/root or TinyDistro as “root”. Bring up a network interface with Linux host. Dynamic IP address assignment: # udhcpc -i <port name in Tiny/LSDKDistro> Static IP address assignment: # ifconfig <port name in Tiny/LSDKDistro> <IP address> netmask <netmask address> up For example: # ifconfig enp1s0 192.168.2.120 netmask 255.255.255.0 up  Copy the Kernel, Kernel.gz images and device tree blob fsl-lx2160a-rdb.dtb from host machine. # mkdir <destination folder> # scp <user>@<ipaddress>:<file path>/<filename> <destination folder> For example: # mkdir /kernelfiles # scp user1@192.168.2.1:/tftpboot/Image.gz /kernelfiles   Step2: Copy the kernel image and device tree to the eMMC card sudo fdisk -l to list the disks that are accessible on board. Mount the eMMC card partition that contains Linux kernel images and device tree. NOTE: Use the command cat /proc/partitions to see the list of devices, their partitions along with their sizes to make sure that the correct device and partition name have been chosen. The eMMC storage drive in the Linux PC is detected as /dev/sdX, where X is a letter such as a, b, c. Make sure to choose the correct device name, because data on this device will be replaced. If your Linux host machine supports read/write eMMC card directly without an extra eMMC card reader device, the device name of eMMC card is typically mmcblk1. In general, the Linux kernel images and device tree are stored in the second partition of the eMMC device (mmcblk1p2). For detail on storage layout on SD/eMMC/USB/SATA for LSDK images deployment, refer to section "LSDK memory layout and Userland" in Layerscape Software Development Kit User Guide. # sudo mkdir <mount_folder> # sudo mount /dev/sdX <mount_folder>  For example: # sudo mkdir /carddata # sudo mount /dev/mmcblk1p2 /carddata Replace Image, Image.gz, and fsl-lx2160a-rdb.dtb on the eMMC card with the new files copied in <destination folder> in the steps above. # sudo cp <destination folder>/Image <destination folder>/Image.gz <destination folder>/fsl-lx2160a-rdb.dtb <mount_location> For example: # sudo cp /kernelfiles/Image /kernelfiles/Image.gz /kernelfiles/fsl-lx2160a-rdb.dtb /carddata Unmount the card. for example: # sudo umount /dev/mmc1blk1p2 Reboot the board. At U-Boot prompt, run the following command to boot the board to LSDK distro using eMMC card. => run bootcmd_mmc1 If U-Boot does not find LSDK on the eMMC card, it will boot TinyDistro from lsdk_linux_arm64_ tiny.itb stored on the eMMC card.    

LS1043ARDB version updated because we replaced the Nand Flash with different page size one as the old one is obsolete. Version update information FA version Nand flash program by CodeWarrior Nand Flash firmware bring up files Boot Mode setting

In the LS1028ARDB, SPI is not enable, some customers need to enable this interface to debug their device and some customer maybe enable this device but the SPI sequence would be some uncertain error which will delay their plan. In this documents, will introduce how to enable the SPI3 on the LS1028ARDB, and use a SPI tools in the LSDK to help customer debug their SPI device in the initial stages of debugging.

The CodeWarrior tool – QCVS SerDes tool allows you to configure the SerDes block and provides you a GUI application to validate the SerDes configuration.  QCVS SERDES supports LX2 but except Serdes#1 Lane H, customer can use the guide below for Tx pattern generation. 

SECURE BOOT Secure Boot introduction Build secure boot ATF image Generate secure boot CSF headers for Linux tiny itb image Deploy secure boot images on the target board Blow OTPMK fuse in u-boot and through CodeWarrior CCS Write SRK hash keys to the mirror registers through CCS Secure boot Trouble Shooting  Fuse Provisioning Fuse Provisioning Utility Introduction Input File for Fuse Provisioning Tool Build Fuse Provisioning Firmware Image with flex-builder and Deploy the Firmware Image Build and Deploy Fuse Provisioning Image Manually Validate Fuse Provisioning Secure Debug Program DCVR and DRVR fuses to activate secure debug Unlock JTAG debug port after locking it through CCS commands Unlock JTAG debug port after locking it through CW IDE  

PPS (Pulses Per Second) signal applies to most network controllers of Layerscape, including DPAA1 platforms. PPS signal is output through 1588 timer pulse out pin. The QorIQ PTP driver configured fixed interval period pulse (FIPER) generator as PPS signal in default. This document describes how to create dts file to customize configuration on the 1588 timer such as selecting other reference clock source, and configuring nominal clock period, FIPERs period, and output clock period to generate the required PPS signal.

How to use the gadget CDC to configure the Layerscape board USB as the serial device to communicate the board by the Serial port. In this file, a setting example has been applied on the LS1028ARDB USB2.

Compile kernel in the ls-5.15.71-2.2.0_distro In the LLDPUG_RevL5.15.71-2.2.0, it seems when do some reconfiguration in the kernel, rootfs should be repack to finish the change. Here will generate kernel without repack the roofts in the Linux host machine just compile the kernel.

The SerDes tool is a part of the QorIQ Configuration and Validation Suite (QCVS) product. This document will illustrate how to use the tools to validate the SerDes on the LS1046ARDB SerDes1 Lane1(Lane C) without Oscilloscope and BERT(Bit Error Ratio Tester). It validate the LS1046ARDB SerDes1 Lane1 with digital loopback, external loopback and external mode.

Basic Concept of Secure boot on LS1028A Platform Build secure boot ATF image Generate secure boot CSF headers for Linux tiny itb image Deploy secure boot images on the target board Blow OTPMK fuse in u-boot and through CodeWarrior CCS Write SRK hash keys to the mirror registers through CCS Secure boot Trouble Shooting  

The attached patch adds error detection for A53 and A57 cores. Hardware error injection is supported on A53. Software error injection is supported on both. For hardware error injection on A53 to work, proper access to L2ACTLR_EL1, CPUACTLR_EL1 needs to be granted by EL3 firmware. This is done by making an SMC call in the driver. Failure to enable access disables hardware error injection. For error interrupt to work, another SMC call enables access to L2ECTLR_EL1. Failure to enable access disables interrupt for error reporting. CPU Memory Error Syndrome and L2 Memory Error Syndrome registers can be used for checking L1 and L2 memory errors. However, only A53 supports double-bit error injection to L1 and L2 memory. This driver uses the hardware error injection when available, but also provides a way to inject errors by software. Both A53 and A57 supports interrupt when multibit errors happen. To use hardware error injection and the interrupt, proper access needs to be granted in ACTLR_EL3 (and/or ACTLR_EL2) register by EL3 firmware SMC call. Correctable errors do not trigger such interrupt. This driver uses dynamic polling internal to check for errors. The more errors detected, the more frequently it polls. Combining with interrupt, this driver can detect correctable and uncorrectable errors. However, if the uncorrectable errors cause system abort exception, this driver is not able to report errors in time.

How to use UART2 instead of UART1 on LS1043ARDB/LS1046ARDB.   1. Compile PBL binary from RCW source file 2. Compile U-Boot binary 3. Compile TF-A binaries (bl2_.pbl and fip.bin) 4. Program TF-A binaries on specific boot mode     1-COMPILE PBL BINARY FROM RCW SOURCE FILE   You have to create a new directory to compile the binaries that you need to create a TF-A binary You need to compile the rcw_<boot_mode>.bin binary to build the bl2_<boot_mode>.pbl binary.   Clone the rcw repository and compile the PBL binary.   1. $ git clone https://github.com/nxp-qoriq/rcw 2. $ cd rcw 3. $ cd ls1043ardb 4. $ make   Inside the directory called “RR_FQPP_1455” you can see some binaries with the next nomenclature: rcw_<freq>.bin Where “freq” is the frequency in MHz of the processor, the values of the frequency are 1200MHz, 1400MHz, 1500MHz, and 1600MHz   2-COMPILE U-BOOT BINARY You need to compile the u-boot.bin binary to build the fip.bin binary. Clone the U-boot repository and compile the U-Boot binary for TF-A   1. $ git clone https://github.com/nxp-qoriq/u-boot 2. $ cd u-boot 3. $ git checkout -b LSDK-21.08 LSDK-21.08 4. $ export ARCH=arm64 5. $ export CROSS_COMPILE=aarch64-linux-gnu- 6. $ make distclean 7. $ nano configs/ls1043ardb_tfa_defconfig 7.1 change the bootargs "console=ttyS0,115200" for "console=ttyS1,115200" 7.2 add "CONFIG_CONS_INDEX=2 7. $ make ls1043ardb_tfa_defconfig 8. $ make   3 Compile TF-A binaries (bl2_.pbl and fip.bin) 1. $ git clone https://github.com/nxp-qoriq/atf 2. $ cd atf 3. $ git checkout -b LSDK-21.08 LSDK-21.08 4. $ export ARCH=arm64 5. $ export CROSS_COMPILE=aarch64-linux-gnu- 6. $ nano plat/nxp/common/include/default/ch_3_2/soc_default_base_addr.h 6.1 Change the line "#define NXP_UART_ADDR 0x021C0000" for "#define NXP_UART_ADDR 0x021D0000" 6.2 Change the line "#define NXP_UART1_ADDR 0x021D0000" for "#define NXP_UART_ADDR 0x021C0000" 7. $ nano plat/nxp/common/include/default/ch_2/soc_default_base_addr.h 7.1 Change the line "#define NXP_UART_ADDR 0x021C0500" for "#define NXP_UART_ADDR 0x021C0600" 7.2 Change the line "#define NXP_UART1_ADDR 0x021C0600" for "#define NXP_UART_ADDR 0x021C0500"   The compiled BL2 binaries, bl2.bin and bl2_<boot mode>.pbl are available at atf/build/ls1043ardb/release/. NOTE: For any update in the BL2 source code or RCW binary, the bl2_<boot mode>.pbl binary needs to be recompiled   3.1 HOW TO COMPILE BL2 BINARY To compile the BL2 binary without OPTEE: make PLAT=<platform> bl2 BOOT_MODE=<boot_mode> pbl RCW=<path_to_rcw_binary>/<rcw_binary_for_specific_boot_mode> To LS1043ARDB for SD boot: make PLAT=ls1043ardb bl2 BOOT_MODE=sd pbl RCW=<path_to_rcw_binary>/<rcw_freq.bin> To LS1043ARDB for NOR boot: make PLAT=ls1043ardb bl2 BOOT_MODE=nor pbl RCW=<path_to_rcw_binary>/<rcw_freq.bin> To LS1043ARDB for NAND boot: make PLAT=ls1043ardb bl2 BOOT_MODE=nand pbl RCW=<path_to_rcw_binary>/<rcw_freq.bin>   3.2 HOW TO COMPILE FIP BINARY   To compile the FIP binary without OPTEE and trusted board boot: $make PLAT=<platform> fip BL33=<path_to_u-boot_binary>/u-boot.bin   For LS1043ARDB: $make PLAT=ls1043ardb fip BL33=<path_to_u-boot_binary>/u-boot.bin   The compiled BL31 and FIP binaries ( bl31.bin, fip.bin ) are available at atf/build/ls1043ardb/release/. For any update in the BL31, BL32, or BL33 binaries, the fip.bin binary needs to be recompiled.   4 Program TF-A binaries on specific boot mode For that step you can use a tftp server, but it is easier with a USB formatted on FAT32.   You have to put the files “ bl2_<boot_mode>.pbl” and “fip.bin” in the usb and follow the steps to your boot mode.   4.1 Program TF-A binaries on IFC NOR flash For LS1043A, the steps to program TF-A binaries on IFC NOR flash are as follows:   1. Boot the board from the default bank. 2. Under U-boot prompt: => usb start 3. Flash bl2_nor.pbl: => fatload usb 0:1 $load_addr bl2_nor.pbl a. Alternate bank: => protect off 64000000 +$filesize && erase 64000000 +$filesize && cp.b $load_addr 64000000 $filesize b. Current bank: => protect off 60000000 +$filesize && erase 60000000 +$filesize && cp.b $load_addr 60000000 $filesize 4. Flash fip.bin: => fatload usb 0:1 $load_addr fip.bin a. Alternate bank: => protect off 64100000 +$filesize && erase 64100000 +$filesize && cp.b $load_addr 64100000 $filesize b. Current bank: => protect off 60100000 +$filesize && erase 60100000 +$filesize && cp.b $load_addr 60100000 $filesize 5. Reset your board: a. Alternate bank: cpld reset altbank b. Current bank: cpld reset   4.2 Program TF-A binaries on NAND flash   1. Boot the board from the default bank. 2. Under U-boot prompt: => usb start 3. Flash bl2_nand.pbl to NAND flash: => fatload usb 0:1 $load_addr bl2_nand.pbl => nand erase 0x0 $filesize;nand write $load_addr 0x0 $filesize; 4. Flash fip_uboot.bin to NAND flash: => fatload usb 0:1 $load_addr fip.bin => nand erase 0x100000 $filesize;nand write $load_addr 0x100000 $filesize; 5. Reset your board: => cpld reset nand   4.3 Program TF-A binaries on SD card   To program TF-A binaries on an SD card, follow these steps:   1. Boot the board from the default bank. 2. Under U-boot prompt: => usb start 3. Flash bl2_sd.pbl to SD card: => fatload usb 0:1 $load_addr bl2_sd.pbl => mmc write $ load_addr 8 A1 4. Flash fip.bin to SD card: => fatload usb 0:1 $load_addr bl2_sd.pbl => mmc write $load_addr 800 A1 5. Reset your board: => cpld reset sd Now the console should be out from UART2 port of the board.  

On the LS1046ARDB, there are 2 1G SGMII with PHY, but sometimes customer want to get PHY-less connection to evaluate the performance, so they may have to change the non-fixed link properties into fixed-link by reconfiguration the SW configuration. In this document, it will give details of configuring the LS1046ARDB to support the fixed-link requirement with LSDK2108 focus on the DTS and Linux kernel. The ethernet MAC in this document is FM1 mEMAC6: 1AE_A000h. Because there is no PHY-less connection on board. We only provide the status when the MAC has been configured.

When customer only has SD/eMMC on the customer board, when they don’t have CWTAP in hand, how do they boot the customer board(bare board) after the board come back from the factory for the first time. This document describes the steps how to use the CMSIS-DAP in this situation as a reference for user.

CMSIS-DAP is a useful tool and exists in some NXP reference boards, but how to use it. This document describes the steps how to use the CMSIS-DAP in the LS1034ARDB as a reference for user.

On the LX2160ARDB, there are 2 25G SFP interfaces, but no 10G SFP interface. When customer want to test the 10G SFPs to evaluate the performance, they have to change the 25G SFP interfaces into 10G by reconfiguration the SW configuration. In this document, it will give details of configuring the LX2160ARDB to support the customer’s 10G SFP interfaces requirement with LSDK2108. At the end, an image will be generated to deployed into the SD card. Because SD card is a convenient way boot up LX2160ARDB, if one wrong move could brick the system, the customer could unplug the SD card to repeat the steps below.

ENETC is a PCI Integrated End Point(IEP). IEP implements peripheral devices in an SoC such that software sees them as PCIe device. ENETC is an evolution of BDR(Buffer Descriptor Ring) based networking IPs. Key goal of the DPDK is to provide a simple, complete framework for fast packet processing in data plane applications. Using the APIs provided as part of the framework, applications can leverage the capabilities of underlying network infrastructure.DPDK been prominent software in user space for networking applications pushes for eNetc driver to be written in user space. This document introduces overview of the NXP ENETC and how its driver is implemented and integrated into the DPDK. DPDK eNetc Driver support features queue start/stop, MTU update, promisc, Unicast and multicast MAC filtering, rss hash, crc offload, vlan offload, Rx checksum offload, basic stats. 1. ENETC Hardware Introduction 2. LS1028 Default ENETC Driver 3. User Space eNetc Driver design 4. DPDK eNetc Driver support features 5. Setup DPDK applications over ENETC platform

This document introduces how to configure software to disable the second DDR controller and only use DDR1 on LX2160A platforms, includes configuring RCW to disable clock of DDR2 by using DEVDISR register and setting HN-F SAM control registers to disable DDR2 in CodeWarrior and atf software coding. 1. Configure RCW to Disable clock of DDR2 by using DEVDISR register 2. Configuring HN-F SAM control register to disable DDR2 in CodeWarrior 3. ATF coding to configure HN-F SAM control register to disable the specific DDR controller