P1010 has only a single pair of MCK signal, while my device has four Chip Select signals. In a scenario connecting a lot of memory devices under four CS, can the single pair of MCK really drive all of memory devices which are connected by fly-by topology on each CS? In case of P1010 (which has only one MCK), is it really practical to connect DDR3 memory devices under all of four CS? Would it be necessary to use "external CLK buffer" in such a case using four CS? P1010 was designed for low-cost systems, and as such some of the pins seen on other QorIQ devices (CKE2/3, ODT2/3) were removed to save on cost. For a single-rank, fly-by topology, only one CS would be used. If more ranks were needed, this would be addressed with stacked memories (DDR3 devices that take up to four CS signals). How does one set up the P1010 or P1014 for a 16 bit data bus size? To set the data bus width, you need to set DDR_SDRAM_CFG[DBW] bits of the register given in section 9.4.1.7, Page-9-20 of P1010RM Rev-B. Is it allowed to use four chip-selects with P1010? In my understanding, one ODT signal should be used and be controlled per chip-select? However P1010 has two MODT. P1010 is designed to use only one chip select with discrete DDR3 DRAM. This requires one CS, one ODT, and one CKE with one clock pair. Additional CS/ODT/CKE are designed for using stacked die DDR3 DRAMs. The four CS, two ODT & CKE, are useful if dual or quad stacked die discrete DDR3 DRAM were used. For the write leveling, does the P1010 use DQ[0,8,16,24] or use all DQ bit to drive status back to the DDR controller? P1010 DDR controller can support the write leveling status on any of the data bits within the data byte from a JEDEC standard DDR3 SDRAM.

The SGMII SerDes of the 3041 can operate at either 1.25G or 2.5G. Is there a register to configure this or it just depends on the clock multipliers of the SerDes PLL? As long as you select the RCW settings for SRDS_PRTCL and the DIV and RATIO settings to select the clock speed, the SerDes registers will default to the correct value based on those RCW settings. Does P3041 SerDes in XAUI mode support 10GBase-CX4 (IEEE802.3 clause54)? In other words, are SerDes XAUI receivers and transmitters capable of communication over a 15 meter 10GBase-CX4 cable? P3041 is not designed for such long distances. An appropriate 10GBASE-CX4 PHY is needed to support such distances.

Usually, when I turn on the option of "reset target on launch" CW resets CPU again while connecting to CPU. With P1015, CodeWarrior (CW) does not connect to CPU when the option is on, only when I disable the option, CW can connect to CPU. What could be the problem? . "Reset target on launch" asserts HRESET to the target, thereby resetting the hardware. In most cases this is a required step, but where you don't want to assert HRESET or where your Target Initialization (.cfg) file does this for you with the "reset 1" command, you can do without this option enabled. "P10xx-P20xxRDB_P1011_jtag.txt" JTAG Configuration file is required by 8.8 CW PA for all single-core P10xx processors. Please load the “P20xxRDB_P1011_jtag.txt" JTAG Configuration file in your USB TAP configuration panel you mentioned about. 1) Set MACCFG1[Rx_Flow] && MACCFG1[Tx_Flow] to 1 2) Set RCTRL[LFC] to 1.

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

As P1025RM.pdf shows, one can multiplex some pins such as, LAD8/GE_PA0 multiplexing. My design uses LOCAL BUS (nor flash) and UTOPIA at the same time. Can I design my product like this in view of pin multiplexing? LAD8 must be used as local bus pin. For UTOPIA, this pin serves as PA0, which is UTOPIA TX address 4. Usually this UTOPIA signal can be not-used. P1025 Reference Manual chapter 12.5.1.2 states that LAD [0:15] can carry both A [0:15] and A [16:31] via ABSWAP setting switching. How can I use it to skip LAD8 to address local bus device? ABSWAP is not used dynamically. It should be set either 0 or 1 but not be switched from time to time. In this case only A [16:31] (from LAD) is available when ABSWAP is used (set to 1). In this case this can only be used if customer requires 16 bit or fewer address lines. In P1025/P1016, for UTOPIA pins UPC1_RxADDR [2:4]/UPC1_TxADDR [2:4], each signal has two pins described in p1025RM. Based on this, can I use any one of the pins LAD08 or MDVAL for UPC1_TxADDR [4]? For LAD08, I'll assign this pin for LOCAL BUS. Yes, you can use any one of the 2 pins for these signals using PMUXCR register. UPC1_TxADDR [4] can be either the one multiplexed with LAD08 or MDVAL. You can assign LAD08 pin for LOCAL BUS. Also remind you that, UPC1_TxADDR 4] is MSB, if only 4-bit UTOPIA address is needed, just use UPC1_TxADDR [0:3] and this LAD08/UPC1_TxADDR[4] pin can be configured as LAD08 by clearing PMUXCR[QE1] bit to 0. In P1025/P1016, I saw that LOE/ LGPL2/ LFRE in the same line, but in P1016EC.pdf, only LGPL2 is present in B14-pin description and I cannot find LOE/LFRE. Can LOE/LFRE (GPCM read enable) signal use B14-pin? LOE/LFRE (GPCM read enable) signal can use B14-pin. For LGPLx pins, we only put the LPGLx in our hardware spec. You can find all other multiplexed function from P1025/P1016 reference manual.

Does P1025 support 16 bits DDR3? I found DDR_SDRAM_CFG{DBW] can be set to 16bits. But no 16bits DDR3 feature is claimed? Theoretically the DDR controller supports 16 bit mode. But the mode has not been tested/verified/validated in P1025. We recommend you to not use 16 mode of P1025. “In asynchronous mode, the memory bus clock speed must be less than or equal to the CCB clock rate which in turn must be less than the DDR PLL rate." Is this statement correct for P1025? No it is not correct. The correct statement is " In asynchronous mode, if the ratio of the DDR data rate to the CCB clock rate is greater than 3 :1 ( i.e. DDR=3:CCB=1 ), than the DDR performance monitor statistic accuracy cannot be guaranteed."

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

Please specify the DDR read only and write only counters for P1023. Event 19 counts DDR reads only while event 27 counts DDR writes only in P1023. How are DDR errors cleared in the ESUMR reg (bit 8)? Do they need to re-init the DDR? You need to clear the ERR_DEFECT [MBE] bit (write 1 to clear). After that the ESUMR bit 8 will be cleared.

If I don’t use the USB interface in the 3041, can I leave USBx_VDD_3P3 and USBx_VDD_1P0 pins not connected? In P4040 they are reserve with note do not connect. Can they be connected to 3.3V and 1.0V respectively? USB_VDD_1P0 must be tied to 1V or the platform voltage (based on whatever the SOC core digital power supply is). USB_VDD_3P3 can be left floating. If I don’t use USB, is it safe to leave USBx_IBIAS_REXT and USBx_VDD_1P8_DECAP unconnected? If USB is not to be used at all, keep the following USB signals floating : USB1_IBIAS_REXT, USB2_IBIAS_REXT, USB1_VDD_1P8_DECAP and USB2_VDD_1P8_DECAP, USB1_VDD_3P3, USB2_VDD_3P3.

What is requirement for the voltage ripple of DDR3 controller MVref? The nominal value of MVref is 1.5V. 1%, +/- 7.5mV is the tolerance value for MVref (ripple range). Can you please explain the RDRVR resistance for DDR3 SDRAM memory interface? RDRVR is the "Driver" resistance. It is the resistance at the driver side. Half strength is ~40 ohms and full strength is ~20 ohms. How can I determine the power rating of the resistor connected to MDIC0 and MDIC1 for both half strength and full strength? The MDIC resistors connected to MDIC [0:1] signals used for either full or half drive strength calibration do not draw much current. So you can use 1/16W rated resistors for either half or full drive calibration.

Does P1016/P1025 come with SerDes clocks enabled? Will P1016/P1025 remain in reset if the SERDES is enabled and no SerDes reference clock is available? Yes, P1016/P1025 comes with SerDes clocks enabled. However, P1016/P1025 doesn't wait for SERDES PLL lock for it to come out of reset. For P1016/P1025, which jitter spec (tCLK_DJ, tCLK_TJ or tCLK_DJ+tCLK_TJ) should the buffer and oscillator require to meet? The input jitter at the SD_REF CLK input is specified, Buffer vendor will have to provide jitter at the output in pk-to-pk terms so that it can be compared with the Tj at SD_REF CLK input What is the relationship between RMS jitter and peak-to-peak jitter in P1016/P1025? How can I calculate the RMS jitter value from our peak-to-peak jitter value (42 ps and 86 ps)? RMS jitter is only valid for Random (Gaussian distribution) jitter. This rms value is then converted to pk-to-pk value and added to Deterministic jitter (pk-to-pk) for finding the total jitter (in pk-to-pk). For SD_REF CLK, the HW specs state the value for Total jitter (in peak to peak ps) and Deterministic jitter (in peak to peak ps). rms value for Rj can be referred from PCI Express™ Jitter and BER Revision 1.0. Converting the rms to pk-to-pk is not going to help here because the buffer datasheet states the additive phase jitter. This is measured by integrating the phase noise over the frequency band of interest. DDR. “In asynchronous mode, the memory bus clock speed must be less than or equal to the CCB clock rate which in turn must be less than the DDR PLL rate." Is this statement correct for P1025? No it is not correct. The correct statement is " In asynchronous mode, if the ratio of the DDR data rate to the CCB clock rate is greater than 3 :1 ( i.e. DDR=3:CCB=1 ), than the DDR performance monitor statistic accuracy cannot be guaranteed."

The JTAG IDCODE for P5010 is 0x0020c01d. What's the IDCODE for the P5010? Below are the JTAG IDCODES for P5010 and P5020: P5010: 0x0020_D_01D P5020: 0x0020_C_01D For P5020, COP header has COP_CHKSTP_OUT and COP_CHKSTP_IN connections. Are they actually driven by the run control device (USB TAP)? If I leave the pins appropriately terminated then I do not need to route them to an adapter cable, right? The USBtap does not use these signals at all. It's okay to leave these pins on the cop header as a NC. You do not need to route them to an adapter cable. For P5020, VDD_SENSE on COP header uses 10-Ohm to OVDD while VIO VSense on Aurora header uses 1K pull-up to OVDD. If I use the 1K Ohm then it will be okay for the USB TAP, right? Yes, this is okay for the USB TAP. They definitely use the VDD_SENSE pin, but they draw very little current, so there's almost no voltage drop. COP header has a COP_SRESET# connection on pin #11 which connects to HRESET# on the P5020. The Aurora header does not have this connection. Is it actually necessary for COP header to drive HRESET# on the P5020 device? The USB TAP does not use the /SRESET pin on the COP header at all. You don't need to route this to the COP header also. You can leave it NC.

Routing the DDR Memory Channel To help ensure the DDR interface is properly optimized, Freescale recommends routing the DDR memory channel in this specific order: 1. Data 2. Address/command/control 3. Clocks Note: The address/command, control, and data groups all have a relationship to the routed clock. Therefore, the effective clock lengths used in the system must satisfy multiple relationships. It is recommended that the designer perform simulation and construct system timing budgets to ensure that these relationships are properly satisfied. Routing DDR3 Data Signals The DDR interface data signals (MDQ[0:63], MDQS[0:8], MDM[0:8], and MECC[0:7]) are source-synchronous signals by which memory and the controller capture the data using the data strobe rather than the clock itself. When transferring data, both edges of the strobe are used to achieve the 2x data rate. An associated data strobe (DQS and DQS) and data mask (DM) comprise each data byte lane. This 11-bit signal lane relationship is crucial for routing (see Table 1). When length-matching, the critical item is the variance of the signal lengths within a given byte lane to its strobe. Length matching across all bytes lanes is also important and must meet the t DQSS parameter as specified by JEDEC. This is also commonly referred to as the write data delay window. Typically, this timing is considerably more relaxed than the timing of the individual byte lanes themselves: Table 1: Byte Lane to Data Strobe and Data Mask Mapping Data Data Strobe Data Mask Lane Number MDQ[0:7] MDQS0, MDQS0 MDM0 Lane 0 MDQ[8:15] MDQS1, !MDQS1 MDM1 Lane 1 MDQ[16:23] MDQS2, !MDQS2 MDM2 Lane 2 MDQ[24:31] MDQS3, !MDQS3 MDM3 Lane 3 MDQ[32:39] MDQS4, !MDQS4 MDM4 Lane 4 MDQ[40:47] MDQS5, !MDQS5 MDM5 Lane 5 MDQ[48:55] MDQS6, !MDQS6 MDM6 Lane 6 MDQ[56:63] MDQS7, !MDQS7 MDM7 Lane 7 MECC[0:7] MDQS8, !MDQS8 MDM8 Lane 8 DDR Signal Group Layout Recommendations Table 2 lists the layout recommendations for DDR signal groups and the benefit of following each recommendation: Table 2: DDR Signal Groups Layout Recommendations Recommendation Benefit Route each data lane adjacent to a solid ground reference for the entire route to provide the lowest inductance for the return currents Provides the optimal signal integrity of the data interface Note: This concern is especially critical in designs that target the top-end interface speed, because the data switches at 2x the applied clock When the byte lanes are routed, route signals within a byte lane on the same critical layer as they traverse the PCB motherboard to the memories Helps minimize the number of vias per trace and provides uniform signal characteristics for each signal within the data group Alternate the byte lanes on different critical layers Facilitates ease of break-out from the controller perspective, and keeps the signals within the byte group together

Can the P4040 eSPI controller address 4-byte (32-bit) addressable EEPROMs in any situation? Yes, eSPI controller addresses 4-byte addressable EEPROMs in any situation. For P4040, is it possible to boot from a 4-byte EEPROM using the on-chip ROM? No. The software in the on-chip ROM only supports 16-bit addressable or 24-bit addressable EEPROMs.

Referring to P1011 IBIS model, there are models of various pin type. Could you please provide brief description on each model name shown below (Extracted from P1010 IBIS file)? 1) DDR related inputs: ddr2_drvr_18, ddr2_drvr_35, ddr2_rcvr_150, ddr2_rcvr_50, ddr2_rcvr_75, ddr2_rcvr_noterm, ddr3_drvr_17, ddr3_drvr_40, ddr3_rcvr_120, ddr3_rcvr_60, ddr3_rcvr_noterm 2) opdalg_out, pouv_out, rx_pzctl, tx_pzctl, ptrmr100_cm 3) v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb For DDR related models: Model name shows DDR type and driver impedance. For example, ddr2_drvr_18 should be used for DDR2 and 18 ohm drive strength. For opdalg_out, pouv_out, ptrmr100_cm, rx_pzctl, tx_pzctl - The pins using these models don't have any other choice of model. For v180_in_wb, v330_in_wb, v250_wb, v250_in_wb, v180_wb, v330_wb - These should be chosen for the interfaces with LVCMOS I/Os like eLBC. The numbers in the name depict the voltage level, e.g. v180_in_wb is applicable for 1.8V receiver. For other models - Those are not utilized directly for any pin so user can ignore them.

What is the integrated phase noise jitter requirement for SD_REF_CLK and SYSCLK for P2041? We don't have the integrated phase noise jitter, the SYSCLK we defined the period jitter and phase noise. For SD_REF_CLK, we follow the PCIe industrial standard spec and it defined peak-to-peak jitters. What is the PLL loop bandwidth of internal PLL in P2040 which uses 100MHz and 125MHz refclks from system? The PLL loop bandwidth of internal PLL is >= 500 KHz. The PLL bandwidth varies with many factors including ref clock rate.

For P1013/P1022, when I am using a DDR controller with a 64-bit interface with a 32-bit memory sub system, which lanes should I use? When a 64-bit DDR interface is configured in a 32-bit data bus width, lanes [0:3] (MDQ [0:31]) will be used.

For P2041, if USB1 and USB2 ports are not implemented, what to do with the unused USB ports ie tie them to ground, 3.3V or leave them unconnected? If USB is not to be used at all, keep the following USB signals floating: USB1_IBIAS_REXT, USB2_IBIAS_REXT, USB1_VDD_1P8_DECAP, USB2_VDD_1P8_DECAP, USB1_VDD_3P3 and USB2_VDD_3P3. The following signals should be pulled-down: USB1_VBUS_CLMP, USB2_VBUS_CLMP and USB_CLKIN. Also, pins USB_VDD_1P0 and USB2_VDD_1P0 must be tied to 1V or the platform voltage (whatever is the SOC core digital power supply) If USB_VDD_3P3 must be connected to 3.3V, will the power sequence be same as other 3.3V (OVDD) (no special power sequence for USB_VDD_3P3)? Even if PHY is not used, USB_VDD_1P0 must be tied to 1V or the platform voltage (whatever is the SOC core digital power supply), other pins can be left floating: USB1_IBIAS_REXT, USB2_IBIAS_REXT, USB1_VDD_1P8_DECAP and USB2_VDD_1P8_DECAP, USB1_VDD_3P3, USB2_VDD_3P3. If signals USB_VDD_3P3 and USB_VDD_1P8 are left floating, there is no need to take of power sequencing on these pins, only USB_VDD_1P0 must be a part of standard power sequencing requirements. If signals USB_VDD_3P3 and USB_VDD_1P8 are used (i.e. not left floating), power sequencing is to be done as under: Follow a minimum ramp time of 350us on USB_VDD_3P3(most regulators would give a 350us ramp time) and standard power sequencing on USB_VDD_1P0,USB_VDD_3P3. USB_VDD_1P8_DECAP would only have 1uF capacitor and is automatically tolerant of sequencing on rest of the supplies are sequenced properly. Also based on silicon validation: There is no power down sequencing to be followed on the PHY. There requirements were added as a backup strategy in case the new regulator in the IP had a problem. We have tested this regulator, so no power down sequencing requirements is needed. There is no need to supply any power to USB_VDD_1P8_DECAP, as the circuit is working fine.

In a previous document, I went through the basic steps of building SDK 1.3.2 for the first time. Now I'm ready to deploy the images onto my target, a P3041DS system. Fortunately my P3041 already has a U-boot and linux install on it. So I can just try and update the SDK from within U-boot. I boot up my trusty terminal - I use putty, and connect to my local COM port at 115200 baudrate. My Ubuntu server already has a tftp server installed, and I link my images over from the SDK build/deploy/images directory over to the /tftpboot directory. The QorIQ_SDK_Infocenter.pdf document within the install has information on the flash bank usage for the current SDK. Make sure you use the document and flash map from the current SDK, as things change. I ended up with a system that didn't boot when I used the older location for the fman uCode (from SDK 1.x) on the SDK 1.3.2 system. Here is a table from the document that shows the flash map for a couple of the QorIQ DS system. It's important to note here that this covers the NOR flash - which is what I'm currently using. You may want to experiment with using NAND or SPI based flash instead - but for my purposes I'm going to re-image NOR flash. The NOR on these development systems is banked, meaning that the most significant address line is tied to a DIP switch. So I can have multiple images in Flash at one time, and switch between them (especially helpful when I mistakenly corrupt one). I'm currently in bank0 (which is the "current bank" in the table above). From this, I see that the addresses I should be interested in are located at: Name Address rcw 0xe8000000 Linux.uImage 0xe8020000 uBoot 0xeff800000 fman uCode 0xeff40000 device tree 0xe8800000 linux rootfs 0xe9300000 To verify that this is correct, I can dump out my RCW: And I can also dump out my current U-boot (which should always start with an ASCII header identifying it): at this point I can start updating the images directly from my TFTP server. I have my tftp server already defined via the U-boot environment serverip, so I just tftp the U-boot image to a randomly picked address in RAM of 0x100000. The transfer went ok, so I can burn it into flash now. I will first erase the flash starting at 0xeff80000. Since U-boot is 0x80000 size, I'll erase from 0xeff80000 for size 0x80000. Apparently my sectors were protected. So I need to unprotect first, then erase again. And by reading the flash, I verify that it has been erased (erased NOR always reads back all 0xF's) So, now I can burn the flash: I use a binary copy. And then verify that the image was written correctly. Then we go through the same technique with the other images. I'll burn the fman ucode as well: Then for the actual images and dtb, you have an option of burning them, but I'll tftp them instead. For this I created a U-boot environment variable called ramboot, and point the image names to the paths on my server: At this point I can save the environment to flash via a saveenv command in U-boot. I'll re-boot into the new U-boot to make sure it works (if it doesn't for some reason, I can jump back to a different U-boot I had previously burned in the alternate bank, or else I'll have to use a debugger to re-burn the flash). Then, from within U-boot I can run ramboot, and if all goes well it should fetch the images and boot all the way into the new SDK. Eventually it should boot all the way to a linux prompt.

When setting the ABSWP bit (in LBCR) in P1020, are the address bytes swapped or just mirrored? Also, can you confirm that the LBCR [ABSWP] affect every device (chip select) being used by the local bus except for the NAND Flash? By setting ABSWP bit (i.e. ABSWP=1), if address=0x12345678. Then LAD [0:15] = 0x7856 and LA[16:31]=0x5678. LBCR [ABSWP] affect every device (chip select) being used by the local bus except for the NAND Flash What is NAND Flash controller speed and size for P1011? AeLBC can work at 83 MHz. At minimum twc, it can be equal to 2 LCLK i.e. half the frequency of LCLK. The maximum page size supported by eLBC is 2K. If I use one mck to drive all 5 ddr3-chips in P1011, can I use the leveling function? Also, which topology do you recommend for this? Yes, writing leveling function should be used to compensate the additional flight time skew delay between different chips introduced by fly-by topology. However, we do not recommend routing the clock in fly-by topology while address, command and control signals routed by other topology. For more detail of JEDEC DDR3 routing topology, please visit [www.JEDEC.org]. Is a 32-bit data interface the only way to control whether or not ABSWP applies (i.e. ABSWP affects 8 and 16-bit data interfaces but does not affect 32-bit data interfaces)? ABSWP also affects 32-bit interface and it is not advisable to set ABSWP for 32 bit interface as only 16 LSB address gets visible on LAD[0:15] and zeroes are output on the LAD[16:31].