Codewarior 10.x includes a pretty flexible flash programmer. Included with the standard install of the tool is a long list of common flash devices. However, if you're creating a new custom board, with a very new technology flash device it may be necessary to add a new device to the Codewarrior flash programmer. Documentation on exactly how to do this exists in the CW install at: ..\CW PA v10.x\PA\PA_Tools\FlashToolKit\Documentation I've attached it for your convenience. Adding a flash device involves modifying a few XML configuration files within the CW install tree. There are really only a few different algorithms used for flash, so as long as the new device uses one of the existing ones (i.e. Intel or AMD) it's very straightforward, and the new XML file will be used just to describe the Manufacturer ID code and sector map. Flash configuration files are located in: ..\CW PA v10.x\PA\bin\plugins\support\Products\ProductData\FPDevices.mwpdb\FP In this directory we see a list of currently supported flash devices (one XML file per device) In order to add a new device we need the following information from the device datasheet: Device Name Manufacturer ID code Device ID code Number of sectors Starting and ending address for each sector If the chip can be erased Options for data width Number of flash devices Algorithm (need to pick from one of the existing algorithms) As an example, I am going to show how to add a Micron / Numonyx PC28F00AP30BF flash device. According to the datasheet: Manufacturer ID = 0x89 Sector Map shows 4 sectors of 16K words followed by 1023 sectors of 64K-words ChipErase = yes Algorithm looks like an intel based algorithm, which we can tell from table 7 of the Flash datasheet (I compare the method needed to program or erase a sector to one of the flash parts with an existing XML file) I create a new file named: ..\CW PA v10.x\PA\bin\plugins\support\Products\ProductData\FPDevices.mwpdb\FP\PC28F00AP30BF.xml <?xml version="1.0" encoding="UTF-8" standalone="no" ?> <device-file> <device> <version>0.1</version> <content> <name>PC28F00AP30BF</name> <manufacturerid>0x89</manufacturerid> <chiperase>TRUE</chiperase> <sectors> <sectorcount>4</sectorcount> <sectorsize>0x8000</sectorsize> <sectorcount>1023</sectorcount> <sectorsize>0x20000</sectorsize> </sectors> <comment> ####################################################################### </comment> <organization> <name>64Mx16x1</name> <id>0x8963</id> <algorithm>intel16x1j3.elf</algorithm> <utility>FlashUtility.elf</utility> </organization> </content> </device> </device-file> I then need to tell CW about the new file, so I modify the product manifest: ..\CW PA v10.x\PA\bin\plugins\support\Products\ProductData\FPDevices.mwpdb\product-manifest.xml And add the following section at the end: <file> <name>PC28F00AP30BF</name> <version>0.1</version> <path>FP/PC28F00AP30BF.xml</path> </file> After saving the files, I open Codewarrior and within the flash programmer, I can now see that my new flash has been added.
This document introduces DDR controller configuration to support new type DDR4 SDRAMs during LS2085/LS2080 target board bringing up. These sections are described in the following, DDR controller memory mapped registers related with new SDRAM setting up on LS2085/LS2080 processors; using “DDR Memory Controller Configuration” tool provided in QCVS tool to calculate the basic DDR controller configuration parameters according to the new DIMM datasheet or SPD provided by the manufacture; use DDR validation(DDRv) tool to validate and optimize the DDR configuration by gradually refining an initial DDR configuration up to an optimal configuration; modify CodeWarrior initialization file and u-boot source code with DDR controller optimized configuration parameter. 1. DDR Controller Memory Mapped registers on LS2085/LS2080 2. Generate Basic DDR Controller Configuration Parameters with QCVS Tool 3. Validation and Optimize DDR Controller Configuration with DDRv Tool 4. Porting CodeWarrior initialization file with the custom DDR configuration parameters
This document introduces secure boot setting up methods and procedures for QorIQ PBL based PowerPC and ARM architecture platforms. It explains the basic concept of secure boot; describes how to create PBL, CSF headers and ESBC images for secure boot; introduces how to deploy secure boot related images on the target and how to blow OTPMK and write SRK hash keys to the mirror registers in the prototype stage; provides the step by step troubleshooting method when secure boot fails without any message printed out on the UART console. LS1043 is used as an example in this document, if the user uses different processor, it is need to change registers and images deployment addresses according to the processor reference manual and QorIQ SDK user manual. 1. Basic Concept of Secure Boot on PBL Based Platform 2. Preparing Images for Secure BOOT 2.1 Create RCW Supporting Secure Boot 2.1.1 Create Secure boot RCW in Linux SDK 2.1.2 Create Secure Boot RCW with QCVS tool 2.2 Generate RSA keys and Signing Images to Create CSF Header with CST tool 3. Deploy Secure Boot Images to the Target and Write SRKH Mirror Register 4. Secure boot Trouble Shooting.
In the scenario that multiple Linux partitions managed by a Hypervisor, it is sometimes desired to split one MAC device’s traffic between partitions. In Hypervisor, DPAA Ethernet interfaces belonging to the same FMAN only can be assigned to one partition in Hypervisor, which brings limitation in DPAA Ethernet interfaces usage between partitions, Shared-MAC technology provides an efficient way for users to share a DPAA Ethernet interface between two Linux partitions, this is very useful for processors with single FMAN device, such as P2041, T1040. 1. Overview of Shared-MAC Architecture between two Linux Partitions 2. Shared-MAC DPAA Ethernet interface Definition in Hypervisor Device Tree 3. Implement Shared-MAC Use Case between two Linux Partitions on the target 4. Hypervisor Shared-MAC Test Result on P2041RDB
I showed in a previous posting, how to update an SDK image from within U-boot. In that example, however, I didn't heed my own advice, and initially I burned the FMC uCode image to the wrong place in flash. Upon rebooting, I no longer had Ethernet connectivity, and needed to re-flash the FMC code through my debugger, Codewarrior. In this posting, I'll attempt to walk through what I did to recover, to give you an idea of how to re-flash the P3041DS, or even a bare board through a debugger. First, we need Codewarrior. I'm currently using version 10.2 on a Windows host, though it looks like Codewarrior 10.3 is the latest available at this time. You also need a hardware TAP, either a USB Tap, Codewarrior TAP, GigaTap or Ethernet Tap. For the P3041, this needs a COP interface 16-pin header. My USB tap is loaned out, so I'm using an Ethernet TAP, which provided the added convenience of being accessible over a LAN. For the purposes of this article, I'll assume I've blown away everything in NOR flash (including the RCW). This will be a similar scenario to a blank board back from the factory. In this case, in order to connect with a debugger we'll need to set a hard coded RCW. From the P3041DS documentation, I see that DIP Switch SW1 configures the RCW_SRC I need a hard coded RCW option, so I'll look through the P3041RM to find out what cfg_rcw_src should be set to. From this, I determine that I want to set cfg_rcw_src = 1_0010, so I set SW1 on the DS appropriately. Note that on the DS system, "ON" = '1' After reconfiguring SW1 to a hard coded RCW option, I plug in my Ethernet TAP probe tip into the COP header. Note the pin1 location, and line up the probe tip appropriately. Now, it's time to fire up Codewarrior. Codewarrior is eclipse based. I won't go through a large eclipse tutorial - but I'll demonstrate some of the basics. One of the first things Codewarrior does, is ask you for a workspace location. A workspace is a containing folder for any projects you might have. In this case I created a new folder called workspace_community. I'll create a new project for this. A project contains files I might compile and download to a bareboard, initialization scripts, and settings for how to connect to the board. Select FILE / NEW / Power Architecture Project I'll name my project P3041DS and click Next. Next, select the appropriate processor Build settings would be used typically for building code, in my case it's really a don't care. I'm only using Core0, so I press NEXT, and then finally I select my TAP connection. In my case, I'm using an Ethernet TAP with IP address 192.168.1.76 I'm not planning on using trace, so I can click Finish on the next screen and am now presented with a Codewarrior coding prospective. I'm not interested in writing any code, so I'm going to set up my debug connection. To do this, I click on the small downward pointing arrow next to the bug on the toolbar, and select Debug Configurations. There are three ways to connect to a target: Attach will attach the debugger to a running target Download will reset the target, initialize it, and download code to the target Connect with reset, initialize the target and pause Note that the reset and initialization are optional and can be configured. I'm going to use Codewarrior Connect, and I'll select that option for my project. To configure my connection, I can select Edit, next to the connection. Here I see my connection type is Ethernet TAP with the correct IP address, as I previously selected in the new project wizard. If I wanted to change my initialization script I would select Edit, next to the Target. This brings up a screen with options for connecting to the specific target. You have the option to reset the core, or not, as well as the option to initialize the target with a script. The default scripts can be used as a reference for a custom board. They initialize parameters such as DDR, MMU, local bus in order for the debugger to gain access to these peripherals. Again, I won't go into details. There is Codewarrior documentation included in the installation, typically found within the C:\Program Files\Freescale\CW PA v10.xx\PA\Help\PDF directory. In this case, I am using the standard P3041DS system, and will just go back to the main debug "Debug Configurations" screen and click debug. This will initiate a connection to the target via the Ethernet TAP, and change the eclipse prospective to the debugging prospective. I see my target has stopped at the reset vector of 0xFFFFFFFC. In the bottom right I have a debugger shell. If it isn't present in your view, you can enable it through Window / Show View / Debugger Shell Within the debugger Shell, I can type in commands directly to the debugger. For example, to read and verify that DDR works, I will dump 20 locations startion at address 0x0 mem 0x0 20 This should return 0xdeadbeef on the default project, since that's the value flash is initialized to in the initialization file. I can do the same to flash: mem 0xe8000000 20 And this should return the first 20 locations of flash, which is where my reset config word should be stored. If both of these return data, we are ready to burn flash. The codewarrior flash burner is run through target tasks in Codewarrior 10.x. A target task defines the flash interface, addresses and images to be burned. Within to target task view, click on the green plus icon to add a target task. This will bring up a window where we can name the task. Task type should be flash programmer. The Hardware Diagnostic task type is useful for running memory tests, but that is discussed in the Codewarrior documentation. Run Configuration describes how we connect to the board. Since I am already connect to the target through a project, I select Active Debug Context. A view should show corresponding to the task created. At this point, we need to add the flash device. YThe flash base address is ou can change the organization by clicking to the right of the organization within the Add Device window. This will show a pull down menu with the various organizations. Base address is configured through the initialization script. By default this is set to 0xE8000000. Target RAM defines a buffer on the target for the algorithm to use. And towards the bottom of the view, one can add Flash Programmer Actions, which describe what is to be done. Examples include erase, or progam a file. It's possible to set up multiple actions, such as erase the entire flash, program the RCW, FMC uCode and Uboot. In this picture, I am adding an action to program the RCW, which is contained in a bin file, to location 0xe8000000. Since a binary has no offset, I need to apply address offset of 0xe8000000 to the file. I instruct it to erase sectors before programming as well, and restrict the actions to the sectors affected. When I've added everything needed, be sure to save the target task. Below is a screenshot of my target task to update the RCW and Fman UCode. I'll save it to the framework, which means it's part of the project. Then, to run the flash programmer, simply click on the green "play" arrow in the target tasks view. The programmer should run and if sucessful, will print out a message in the Codewarrior flash programmer console. You may now disconnect codewarrior (red stop button icon), and try to boot up your system. Remember the DIP switches are still set for a hard configured reset config word, so I'll be sure to change them back first.
Occasionally, one may want to change the root filesystem, and then rebuild the image using Yocto as per the standard SDK. The SDK manual, goes through the steps necessary in Chapter 2 of the QorIQ_SDK_Infocenter.pdf document. In the following examples I assume you've already installed the SDK, and set up the host environment. I also assume you compiled an image once already, and through doing so have already run the fsl-setup-poky script. I'm using a P3041DS system, and in my case, the first thing I ran to set up my build was: source ./fsl-setup-poky -m p3041ds -j 4 -t 4 As a first example, on my P3041DS system I am using fm1-gb4 as my ethernet port. I want to assign it the static address of 192.168.1.33. In order to do so, I need to create my own /etc/network/interfaces file to implement this function: cd <yocto_install_path> bitbake -c cleansstate netbase Then go into the netbase folder: cd meta-fsl-ppc/recipes-append/netbase/files Within this directory, I create an interfaces file for my target: auto lo iface lo inet loopback iface fm1-gb4 inet static address 192.168.1.33 netmask 255.255.255.0 gateway 192.168.1.1 network 192.168.1.0 At this point, I just rebuild my image: bitbake fsl-image-core And the network definitions will be installed. (note that I'm building fsl-image-core, but you could build whatever target you're currently using, i.e. fsl-image-minimal) As a second example, I wish to add a pre-build binary (custom application) into the rootfs. In this example I have an custom application, mr_access that I want to install into /usr cd <yocto_install_path> Then add the files: cd meta-fsl-ppc-private/recipes-tools/merge-files Now, put the files into files/merge. I added mr_access into files/merge/usr Build the new rootfs image: bitbake fsl-image-core
QorIQ processors implement a very powerful user programmable hardware based event counting and tracing infrastructure. It enables the programmer and system engineers to peek inside the layers of hardware and reason about the hardware behavior with a given application software. Unlike pure software methods, using the QorIQ debug architecture enables non-intrusive system level performance analysis and debug. This session provides an introduction to the features of QorIQ debug architecture and the software tools & libraries provided by Freescale to use it. At the end, we present a case study where we used the system bus tracing as an alternative to emulation to investigate the root cause of a data corruption problem in a field deployed eNodeB system.
If a user is running a multiple software entities system where a single MAC may be used by several software entities simultaneously. Users may use a different VSP(Virtual Storage Profiles) for each SW entity; that way, the buffer may be private, It allows the virtualization of the buffer pool selection for frame storage (and other parameters related to storage in external memory) from the physical hardware ports. Using VSP mechanism, different packets received on the same physical port may be stored in different BM pools based on the frame header, in a similar way to FQID selection. For example, in the case allocating a dedicated buffer pool for VLAN 2 packets, there are buffers always available for VLAN 2 traffic, if too many traffic coming in, other packets can be dropped. Each port has a default VSP. On each PCD classification, a VSP may be selected. Received packets will be written into the destination buffer according to the VSP parameters, while the VSP is selected according to the frame headers and the PCD configuration. Usage of VSP by FMAN Port Add Chosen Device node in the DTS file to support Virtual storage Profile VSP Allocation and Initialization in USDPAA Application Define VSP in FMC PCD Policy File