JMatPro_CastIron_Part1_BackGround
MTK编程起步开发常用知识
MTK编程起步——开发常用知识2010-12-03 10:53:02| 分类：MTK工作总结| 标签：|字号大中小订阅加载过的字符串生成文件：string_resource_usage.txt加载过的图片生成文件：image_resource_usage.txtSMS编辑界面,中间按键的显示：mmi_sms_entry_editor{#ifdef __MMI_WGUI_CSK_ENABLE__EnableCenterSoftkey(0, IMG_GLOBAL_SEND_MSG_CSK);mmi_imc_disable_csk();#endif}EnableCenterSoftkey(0, 0);去掉其使用。
设置默认时间：custom_hw_default.c :DEFAULT_HARDWARE_YEAR、DEFAULT_HARDWARE_MON、DEFAULT_HARDWARE_DAYRestore.c 恢复出厂时间：RstResetDateTime()上下左右快捷键设置：Resource_shortcuts.c：数组：gShctCandList 可选的快捷方式入口gShctDefaultList 默认有的入口gShctDefaultDediList[4] 上下左右四个键的入口camera、video 的一些默认值设置：MMI_features_camera.h、MMI_features_video.h(plutommi\customer\custresource\pluto_mmi)UI_device_heightUI_device_widthMMI_button_bar_height修改默认输入法：Common_mmi_cache_config.c:NVRAM_SETTING_PREFER_INPUT_METHODRESTORE_PREFER_INPUT_METHODmodis上看需修改版本号：NVRAM_EF_CACHE_SHORT_LID_VERNO(custom_nvram_editor_data_item.h)电话本的存储设置：mmi_phb_entry_quick_search_list(){guiBuffer = GetCurrGuiBuffer(SCR_ID_PHB_QUICK_SEARCH_LIST);/*NEOTEL:caiqin 20100818 add for phb display begin*/#if !defined(__NEOTEL_N73_SETTING__)entryCount = mmi_phb_num_of_phb_contact_in_storage(g_phb_cntx.prefer_storage);#elseentryCount = mmi_phb_num_of_phb_contact_in_storage(MMI_STORAGE_BOTH);#endifSetLeftSoftkeyFunction(MTPNP_PFAL_PHB_entry_list_choose_number_dial, KEY_EVENT_UP);//左按键进入拨打的界面。
NVIDIA Shader Debugger for FX Composer June 2008 1
2. Shader/Technique & Function Selector for Editor. On the left, provides a summary of all the techniques and their respective passes for the current effect. On the right, provides a dropdown of all functions in the current shader file.
Makes it easy to understand shader algorithms and control logic Improving productivity by removing the need to embed additional debugging
functionality into shaders Quickly understanding shaders written by other artists, developers, or shader
Feature List
The NVIDIA Shader Debugger contains several features to debug and understand shaders. These features include:
1. Debugger Toolbar. This toolbar contains several convenient buttons:
Features ............................................................................................................. 2 Overview ......................................................................................................................... 2 Feature List...................................................................................................................... 2
NXP SCM-i.MX 6 Series Yocto Linux 用户指南说明书
© 2017 NXP B.V.SCM-i.MX 6 Series Yocto Linux User'sGuide1. IntroductionThe NXP SCM Linux BSP (Board Support Package) leverages the existing i.MX 6 Linux BSP release L4.1.15-2.0.0. The i.MX Linux BSP is a collection of binary files, source code, and support files that can be used to create a U-Boot bootloader, a Linux kernel image, and a root file system. The Yocto Project is the framework of choice to build the images described in this document, although other methods can be also used.The purpose of this document is to explain how to build an image and install the Linux BSP using the Yocto Project build environment on the SCM-i.MX 6Dual/Quad Quick Start (QWKS) board and the SCM-i.MX 6SoloX Evaluation Board (EVB). This release supports these SCM-i.MX 6 Series boards:• Quick Start Board for SCM-i.MX 6Dual/6Quad (QWKS-SCMIMX6DQ)• Evaluation Board for SCM-i.MX 6SoloX (EVB-SCMIMX6SX)NXP Semiconductors Document Number: SCMIMX6LRNUGUser's GuideRev. L4.1.15-2.0.0-ga , 04/2017Contents1. Introduction........................................................................ 1 1.1. Supporting documents ............................................ 22. Enabling Linux OS for SCM-i.MX 6Dual/6Quad/SoloX .. 2 2.1. Host setup ............................................................... 2 2.2. Host packages ......................................................... 23.Building Linux OS for SCM i.MX platforms .................... 3 3.1. Setting up the Repo utility ...................................... 3 3.2. Installing Yocto Project layers ................................ 3 3.3. Building the Yocto image ....................................... 4 3.4. Choosing a graphical back end ............................... 4 4. Deploying the image .......................................................... 5 4.1. Flashing the SD card image .................................... 5 4.2. MFGTool (Manufacturing Tool) ............................ 6 5. Specifying displays ............................................................ 6 6. Reset and boot switch configuration .................................. 7 6.1. Boot switch settings for QWKS SCM-i.MX 6D/Q . 7 6.2. Boot switch settings for EVB SCM-i.MX 6SoloX . 8 7. SCM uboot and kernel repos .............................................. 8 8. References.......................................................................... 8 9.Revision history (9)Enabling Linux OS for SCM-i.MX 6Dual/6Quad/SoloX1.1. Supporting documentsThese documents provide additional information and can be found at the NXP webpage (L4.1.15-2.0.0_LINUX_DOCS):•i.MX Linux® Release Notes—Provides the release information.•i.MX Linux® User's Guide—Contains the information on installing the U-Boot and Linux OS and using the i.MX-specific features.•i.MX Yocto Project User's Guide—Contains the instructions for setting up and building the Linux OS in the Yocto Project.•i.MX Linux®Reference Manual—Contains the information about the Linux drivers for i.MX.•i.MX BSP Porting Guide—Contains the instructions to port the BSP to a new board.These quick start guides contain basic information about the board and its setup:•QWKS board for SCM-i.MX 6D/Q Quick Start Guide•Evaluation board for SCM-i.MX 6SoloX Quick Start Guide2. Enabling Linux OS for SCM-i.MX 6Dual/6Quad/SoloXThis section describes how to obtain the SCM-related build environment for Yocto. This assumes that you are familiar with the standard i.MX Yocto Linux OS BSP environment and build process. If you are not familiar with this process, see the NXP Yocto Project User’s Guide (available at L4.1.15-2.0.0_LINUX_DOCS).2.1. Host setupTo get the Yocto Project expected behavior on a Linux OS host machine, install the packages and utilities described below. The hard disk space required on the host machine is an important consideration. For example, when building on a machine running Ubuntu, the minimum hard disk space required is about 50 GB for the X11 backend. It is recommended that at least 120 GB is provided, which is enough to compile any backend.The minimum recommended Ubuntu version is 14.04, but the builds for dizzy work on 12.04 (or later). Earlier versions may cause the Yocto Project build setup to fail, because it requires python versions only available on Ubuntu 12.04 (or later). See the Yocto Project reference manual for more information.2.2. Host packagesThe Yocto Project build requires that the packages documented under the Yocto Project are installed for the build. Visit the Yocto Project Quick Start at /docs/current/yocto-project-qs/yocto-project-qs.html and check for the packages that must be installed on your build machine.The essential Yocto Project host packages are:$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-devThe i.MX layers’ host packages for the Ubuntu 12.04 (or 14.04) host setup are:$ sudo apt-get install libsdl1.2-dev xterm sed cvs subversion coreutils texi2html docbook-utils python-pysqlite2 help2man make gcc g++ desktop-file-utils libgl1-mesa-dev libglu1-mesa-dev mercurial autoconf automake groff curl lzop asciidocThe i.MX layers’ host packages for the Ubuntu 12.04 host setup are:$ sudo apt-get install uboot-mkimageThe i.MX layers’ host packages for the Ubuntu 14.04 host s etup are:$ sudo apt-get install u-boot-toolsThe configuration tool uses the default version of grep that is on your build machine. If there is a different version of grep in your path, it may cause the builds to fail. One workaround is to rename the special versi on to something not containing “grep”.3. Building Linux OS for SCM i.MX platforms3.1. Setting up the Repo utilityRepo is a tool built on top of GIT, which makes it easier to manage projects that contain multiple repositories that do not have to be on the same server. Repo complements the layered nature of the Yocto Project very well, making it easier for customers to add their own layers to the BSP.To install the Repo utility, perform these steps:1.Create a bin folder in the home directory.$ mkdir ~/bin (this step may not be needed if the bin folder already exists)$ curl /git-repo-downloads/repo > ~/bin/repo$ chmod a+x ~/bin/repo2.Add this line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable:$ export PATH=~/bin:$PATH3.2. Installing Yocto Project layersAll the SCM-related changes are collected in the new meta-nxp-imx-scm layer, which is obtained through the Repo sync pointing to the corresponding scm-imx branch.Make sure that GIT is set up properly with these commands:$ git config --global "Your Name"$ git config --global user.email "Your Email"$ git config --listThe NXP Yocto Project BSP Release directory contains the sources directory, which contains the recipes used to build, one (or more) build directories, and a set of scripts used to set up the environment. The recipes used to build the project come from both the community and NXP. The Yocto Project layers are downloaded to the sources directory. This sets up the recipes that are used to build the project. The following code snippets show how to set up the SCM L4.1.15-2.0.0_ga Yocto environment for the SCM-i.MX 6 QWKS board and the evaluation board. In this example, a directory called fsl-arm-yocto-bsp is created for the project. Any name can be used instead of this.Building Linux OS for SCM i.MX platforms3.2.1. SCM-i.MX 6D/Q quick start board$ mkdir fsl-arm-yocto-bsp$ cd fsl-arm-yocto-bsp$ repo init -u git:///imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth -m scm-imx-4.1.15-2.0.0.xml$ repo sync3.2.2. SCM-i.MX 6SoloX evaluation board$ mkdir my-evb_6sxscm-yocto-bsp$ cd my-evb_6sxscm-yocto-bsp$ repo init -u git:///imx/fsl-arm-yocto-bsp.git -b imx-4.1-krogoth -m scm-imx-4.1.15-2.0.0.xml$ repo sync3.3. Building the Yocto imageNote that the quick start board for SCM-i.MX 6D/Q and the evaluation board for SCM-i.MX 6SoloX are commercially available with a 1 GB LPDDR2 PoP memory configuration.This release supports the imx6dqscm-1gb-qwks, imx6dqscm-1gb-qwks-rev3, and imx6sxscm-1gb-evb. Set the machine configuration in MACHINE= in the following section.3.3.1. Choosing a machineChoose the machine configuration that matches your reference board.•imx6dqscm-1gb-qwks (QWKS board for SCM-i.MX 6DQ with 1 GB LPDDR2 PoP)•imx6dqscm-1gb-qwks-rev3 (QWKS board Rev C for SCM-i.MX 6DQ with 1GB LPDDR2 PoP) •imx6sxscm-1gb-evb (EVB for SCM-i.MX 6SX with 1 GB LPDDR2 PoP)3.4. Choosing a graphical back endBefore the setup, choose a graphical back end. The default is X11.Choose one of these graphical back ends:•X11•Wayland: using the Weston compositor•XWayland•FrameBufferSpecify the machine configuration for each graphical back end.The following are examples of building the Yocto image for each back end using the QWKS board for SCM-i.MX 6D/Q and the evaluation board for SCM-i.MX 6SoloX. Do not forget to replace the machine configuration with what matches your reference board.3.4.1. X11 image on QWKS board Rev C for SCM-i.MX 6D/Q$ DISTRO=fsl-imx-x11 imx6dqscm-1gb-qwks-rev3 source fsl-setup-release.sh -b build-x11$ bitbake fsl-image-gui3.4.2. FrameBuffer image on evaluation board for SCM-i.MX 6SX$ DISTRO=fsl-imx-fb MACHINE=imx6sxscm-1gb-evb source fsl-setup-release.sh –b build-fb-evb_6sxscm$ bitbake fsl-image-qt53.4.3. XWayland image on QWKS board for SCM-i.MX 6D/Q$ DISTRO=fsl-imx-xwayland MACHINE=imx6dqscm-1gb-qwks source fsl-setup-release.sh –b build-xwayland$ bitbake fsl-image-gui3.4.4. Wayland image on QWKS board for SCM-i.MX 6D/Q$ DISTRO=fsl-imx-wayland MACHINE=imx6dqscm-1gb-qwks source fsl-setup-release.sh -b build-wayland$ bitbake fsl-image-qt5The fsl-setup-release script installs the meta-fsl-bsp-release layer and configures theDISTRO_FEATURES required to choose the graphical back end. The –b parameter specifies the build directory target. In this build directory, the conf directory that contains the local.conf file is created from the setup where the MACHINE and DISTRO_FEATURES are set. The meta-fslbsp-release layer is added into the bblayer.conf file in the conf directory under the build directory specified by the –e parameter.4. Deploying the imageAfter the build is complete, the created image resides in the <build directory>/tmp/deploy/images directory. The image is (for the most part) specific to the machine set in the environment setup. Each image build creates the U-Boot, kernel, and image type based on the IMAGE_FSTYPES defined in the machine configuration file. Most machine configurations provide the SD card image (.sdcard), ext4, and tar.bz2. The ext4 is the root file system only. The .sdcard image contains the U-Boot, kernel, and rootfs, completely set up for use on an SD card.4.1. Flashing the SD card imageThe SD card image provides the full system to boot with the U-Boot and kernel. To flash the SD card image, run this command:$ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && syncFor more information about flashing, see “P reparing an SD/MMC Card to Boot” in the i.MX Linux User's Guide (document IMXLUG).Specifying displays4.2. MFGTool (Manufacturing Tool)MFGTool is one of the ways to place the image on a device. To download the manufacturing tool for the SCM-i.MX 6D/Q and for details on how to use it, download the SCM-i.MX 6 Manufacturing Toolkit for Linux 4.1.15-2.0.0 under the "Downloads" tab from /qwks-scm-imx6dq. Similarly, download the manufacturing tool for the SCM-i.MX 6SoloX evaluation board under the "Downloads" tab from /evb-scm-imx6sx.5. Specifying displaysSpecify the display information on the Linux OS boot command line. It is not dependent on the source of the Linux OS image. If nothing is specified for the display, the settings in the device tree are used. Find the specific parameters in the i.MX 6 Release Notes L4.1.15-2.0.0 (available at L4.1.15-2.0.0_LINUX_DOCS). The examples are shown in the following subsections. Interrupt the auto-boot and enter the following commands.5.1.1. Display options for QWKS board for SCM-i.MX 6D/QHDMI displayU-Boot > setenv mmcargs 'setenv bootargs console=${console},${baudrate} ${smp}root=${mmcroot} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24'U-Boot > run bootcmd5.1.2. Display options for EVB for SCM-i.MX 6SXNote that the SCM-i.MX 6SX EVB supports HDMI with a HDMI accessory card (MCIMXHDMICARD) that plugs into the LCD connector on the EVB.Accessory boards:•The LVDS connector pairs with the NXP MCIMX-LVDS1 LCD display board.•The LCD expansion connector (parallel, 24-bit) pairs with the NXP MCIMXHDMICARD adapter board.LVDS displayU-Boot > setenv mmcargs 'setenv bootargs console=${console},${baudrate} ${smp}root=${mmcroot} ${dmfc} video=mxcfb0:dev=ldb,1024x768M@60,if=RGB666 ldb=sep0'U-Boot > run bootcmdHDMI display (dual display for the HDMI as primary and the LVDS as secondary)U-Boot > setenv mmcargs 'setenv bootargs console=${console},${baudrate} ${smp}root=${mmcroot} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24video=mxcfb1:dev=ldb,LDBXGA,if=RGB666'U-Boot > run bootcmdLCD displayu-boot > setenv mmcargs 'setenv bootargs ${bootargs}root=${mmcroot} rootwait rw video=mxcfb0:dev=lcd,if=RGB565'u-boot> run bootcmd6. Reset and boot switch configuration6.1. Boot switch settings for QWKS SCM-i.MX 6D/QThere are two push-button switches on the QWKS-SCMIMX6DQ board. SW1 (SW3 for QWKS board Rev B) is the system reset that resets the PMIC. SW2 is the i.MX 6Dual/6Quad on/off button that is needed for Android.There are three boot options. The board can boot either from the internal SPI-NOR flash inside the SCM-i.MX6Dual/6Quad or from either of the two SD card slots. The following table shows the switch settings for the boot options.Table 1.Boot configuration switch settingsBoot from top SD slot (SD3)Boot from bottom SD slot (SD2)Boot from internal SPI NORDefault1.References6.2. Boot switch settings for EVB SCM-i.MX 6SoloXThis table shows the jumper configuration to boot the evaluation board from the SD card slot SD3.7. SCM uboot and kernel repositoriesThe kernel and uboot patches for both SCM-i.MX 6 QWKS board and evaluation board are integrated in specific git repositories. Below are the git repos for SCM-i.MX 6 uboot and kernel:uBoot repo: /git/cgit.cgi/imx/uboot-imx.gitSCM Branch: scm-imx_v2016.03_4.1.15_2.0.0_gakernel repo: /git/cgit.cgi/imx/linux-imx.gitSCM branch: scm-imx_4.1.15_2.0.0_ga8. References1.For details about setting up the Host and Yocto Project, see the NXP Yocto Project User’s Guide(document IMXLXYOCTOUG).2.For information about downloading images using U-Boot, see “Downloading images usingU-Boot” in the i.MX Linux User's Guide (document IMXLUG).3.For information about setting up the SD/MMC card, see “P reparing an SD/MMC card to boot” inthe i.MX Linux User's Guide (document IMXLUG).9. Revision historyDocument Number: SCMIMX6LRNUGRev. L4.1.15-2.0.0-ga04/2017How to Reach Us: Home Page: Web Support: /supportInformation in this document is provided solely to enable system and softwareimplementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein.NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequentia l or incidental damages. “Typical”parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including “typicals,” must be valida ted for each customer application by customer’s technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: /SalesTermsandConditions .NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, Freescale, and the Freescale logo are trademarks of NXP B.V. All other product or service names are the property of their respective owners.ARM, the ARM Powered logo, and Cortex are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. © 2017 NXP B.V.。
G.984.4标准补充修订
I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T G.984.4TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Amendment 1(06/2009)SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKSDigital sections and digital line system – Optical line systems for local and access networksGigabit-capable passive optical networks (G-PON): ONT management and control interface specificationAmendment 1Recommendation ITU-T G.984.4 (2008) – Amendment 1ITU-T G-SERIES RECOMMENDATIONSTRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKSINTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-G.200–G.299TRANSMISSION SYSTEMSG.300–G.399INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONESYSTEMS ON METALLIC LINESGENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMSG.400–G.449ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLICLINESCOORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600–G.699DIGITAL TERMINAL EQUIPMENTS G.700–G.799DIGITAL NETWORKS G.800–G.899DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999General G.900–G.909Parameters for optical fibre cable systems G.910–G.919Digital sections at hierarchical bit rates based on a bit rate of 2048 kbit/s G.920–G.929Digital line transmission systems on cable at non-hierarchical bit rates G.930–G.939Digital line systems provided by FDM transmission bearers G.940–G.949Digital line systems G.950–G.959Digital section and digital transmission systems for customer access to ISDN G.960–G.969Optical fibre submarine cable systems G.970–G.979Optical line systems for local and access networks G.980–G.989Access networks G.990–G.999G.1000–G.1999MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER-RELATED ASPECTSTRANSMISSION MEDIA CHARACTERISTICS G.6000–G.6999DATA OVER TRANSPORT – GENERIC ASPECTS G.7000–G.7999PACKET OVER TRANSPORT ASPECTS G.8000–G.8999 ACCESS NETWORKS G.9000–G.9999For further details, please refer to the list of ITU-T Recommendations.Recommendation ITU-T G.984.4Gigabit-capable passive optical networks (G-PON): ONT managementand control interface specificationAmendment 1SummaryAmendment 1 to Recommendation ITU-T G.984.4 contains various updates to ITU-T G.984.4 (2008). A number of editorial corrections and clarifications are included, along with the following substantive changes and extensions to G-PON OMCI.• OMCI for reach extenders• PM extensions for Ethernet bridge ports and circuit emulation services (pseudowires)• Update of OMCI to align with Recommendation ITU-T G.997.1 (2009)• Revision of the VLAN tagging filter data managed entity• A managed entity to control out-of-band file transfer through OMCI• Extended descriptions and OMCI extensions on traffic management and quality of service • A number of additional minor extensions to OMCISourceAmendment 1 to Recommendation ITU-T G.984.4 (2008) was approved on 6 June 2009 by ITU-T Study Group 15 (2009-2012) under Recommendation ITU-T A.8 procedures.Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009) iFOREWORDThe International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis.The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.In some areas of information technology which fall within ITU-T's purview, the necessary standards are prepared on a collaborative basis with ISO and IEC.NOTEIn this Recommendation, the expression "Administration" is used for conciseness to indicate both a telecommunication administration and a recognized operating agency.Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other obligatory language such as "must" and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party.INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http://www.itu.int/ITU-T/ipr/.© ITU 2010All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU.ii Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009)CONTENTSPage1)Clause 2, References (1)2)Clause 3, Definitions (1)3)Clause 4, Abbreviations (1)4)Clause 8.1, Managed entities (2)5)Clause 8.2, Managed entity relation diagrams (3)6)Clause 8.2.4, xDSL service (6)7)New clause 8.2.10 (7)8)Clause 9.1.1, ONT-G (9)9)Clause 9.1.2, ONT2-G (10)10)Clause 9.1.5, Cardholder (10)11)Clause 9.1.10, Protection data (11)12)Clause 9.2.1, ANI-G (12)13)Clause 9.2.3, GEM port network CTP (12)14)Clause 9.2.4, GEM interworking termination point (14)15)Clause 9.2.6, GEM port performance monitoring history data (16)16)Clause 9.3, Layer 2 data services (17)17)Clause 9.3.10, 802.1p mapper service profile (18)18)Clause 9.3.11, VLAN tagging filter data (19)19)Clause 9.3.12, VLAN tagging operation configuration data (22)20)Clause 9.3.13 , Extended VLAN tagging operation configuration data (22)21)Clause 9.3.27, Multicast operations profile (25)22)New clauses 9.3.30 and 9.3.31 (26)23)Clause 9.7, xDSL services (28)24)Clause 9.7.3, xDSL line configuration profile part 1 (28)25)Clause 9.7.5, xDSL line configuration profile part 3 (30)26)Clause 9.7.6, VDSL2 line configuration extensions (32)27)Clause 9.7.7, xDSL channel configuration profile (34)28)Clause 9.7.12, xDSL line inventory and status data part 1 (35)29)Clause 9.7.16, VDSL2 line inventory and status data part 1 (36)30)Clause 9.7.17, VDSL2 line inventory and status data part 2 (37)31)Clause 9.7.19, xDSL channel downstream status data (37)32)Clause 9.7.20, xDSL channel upstream status data (38)33)Clause 9.7.21, xDSL xTU-C performance monitoring history data (38)34)Clause 9.7 (38)Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009) iiiPage35)Clause 9.8, TDM services (48)36)Clause 9.8.1, Physical path termination point CES UNI (49)37)Clause 9.8.4, CES physical interface performance monitoring history data (51)38)Clause 9.8 (53)39)Clause 9.11.1, Priority queue-G (56)40)Clause 9.11.3, GEM traffic descriptor (58)41)Clause 9.12 (60)42)New clause 9.14 (62)43)Clause 11.1.6, Message identifier (75)44)Clause I.1.1, MIB data sync increase (76)45)Clause I.1.4, Alarm audit and resynchronization (76)46)Clause I.1.5, Table attributes (76)47)Clause I.1.9, Performance monitoring (76)48)Clause I.2.7, Software image download (77)49)Clause II.2.33, End software download (79)50)Clause II.2.27, Test (79)51)Clause II.2.45, Test result (79)52)Appendix III (81)53)Bibliography (83)iv Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009)Recommendation ITU-T G.984.4Gigabit-capable passive optical networks (G-PON): ONT managementand control interface specificationAmendment 11) Clause 2, Referencesa) Modify the following reference as shown:[ITU-T G.997.1] Recommendation ITU-T G.997.1 (2009), Physical layer management for digital subscriber line (DSL) transceivers.b) Add the following references:[ITU-T G.704] Recommendation ITU-T G.704 (1998), Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels.[ITU-T G.826] Recommendation ITU-T G.826 (2002), End-to-end error performanceparameters and objectives for international, constant bit-rate digital paths andconnections.[ITU-T G.984.6] Recommendation ITU-T G.984.6 (2008), Gigabit-capable passive opticalnetworks (GPON): Reach extension.2) Clause 3, DefinitionsAdd the following clause:3.5 shaping and policing: A shaper causes a flow of input packets to conform to a given PIR/PBS by controlling the release rate/burst size of output packets. This typically results in queuing delay; packets may be dropped if there is a queue overflow because the input rate or burst size is too great.A policer causes a flow of input packets to conform to a given PIR/PBS by immediately dropping packets that exceed PIR/PBS. This typically results in packet loss; packets may be further marked as drop eligible if they exceed CIR/CBS.3) Clause 4, AbbreviationsAdd the following acronyms in alphabetic order:ACL Access Control ListCBS Committed Block SizeDMT Discrete MultitoneFDL Facility Data LinkLBO Line BuildoutBlockSizePBS PeakPCP Priority Code PointR'/S' Reach extender interface to optical trunk lineRAD Rate Adaptation DownshiftRec. ITU-T G.984.4 (2008)/Amd.1 (06/2009) 1RAU Rate Adaptation UpshiftRE ReachExtenderS'/R' Reach extender interface to optical distribution network SRA Seamless Rate Adaptation4) Clause 8.1, Managed entitiesAdd the following entries in alphabetic order to Table 8-1:Table 8-1 – Managed entities of the OMCIManaged entity Required/OptionalDescription ClauseRE ANI-G CR Used for mid-span PON reach extender ANI 9.14.1 Physical path termination pointRE UNICR Used for mid-span PON reach extender UNI 9.14.2RE upstream amplifier CR Used for mid-span PON reach extender upstreamoptical amplifier9.14.3RE downstream amplifier CR Used for mid-span PON reach extenderdownstream optical amplifier9.14.4RE config portal CR Used for non-OMCI configuration method onmid-span PON reach extenders9.14.5RE common amplifier parameters CR Used for monitoring and maintenance of PONreach extender optical amplifiers9.14.6File transfer controller O Used to control out-of-band file transfers 9.12.13 CES physical interfaceperformance monitoringhistory data 2O Used for PM of DS1, E1 and similar CESs 9.8.12CES physical interfaceperformance monitoringhistory data 3O Used for PM of DS1, E1 and similar CESs 9.8.13Ethernet frame performance monitoring history data upstream O Used for PM of upstream Ethernet flows on abridge port9.3.30Ethernet frame performance monitoring history data downstream O Used for PM of downstream Ethernet flows on abridge port9.3.31VDSL2 line configurationextensions 2O Used to configure additional VDSL2 parameters 9.7.26xDSL impulse noise monitorperformance monitoringhistory dataO Used for impulse noise monitoring PM 9.7.27xDSL line inventory and status data part 5 CR Additional xDSL test parameters for G.992.3,G.992.5 Annex C9.7.28xDSL line inventory and status data part 6 CR Additional xDSL test parameters for G.992.3,G.992.5 Annex C9.7.29xDSL line inventory and status data part 7 CR Additional xDSL test parameters for G.992.3,G.992.5 Annex C9.7.302Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009)5) Clause 8.2, Managed entity relation diagramsa) Throughout clause 8.2, replace the indicated figures with the following:GEM portnetwork CTPFigure 8.2.2-6 − Illustration of N:M bridge-mappingRec. ITU-T G.984.4 (2008)/Amd.1 (06/2009) 3GEM port network CTPGEM portnetwork CTPFigure 8.2.2-7 − Illustration of 1:MP map-filtering4Rec. ITU-T G.984.4 (2008)/Amd.1 (06/2009)Figure 8.2.2-10 − Illustration of multicast serviceb) Add the following figure at the end of clause 8.2.2:GEM portnetwork CTPFigure 8.2.2-11 − Illustration of downstream broadcast configuration6) Clause 8.2.4, xDSL serviceReplace Figure 8.2.4-1 with the following:7) New clause 8.2.10Add the following new clause at the end of clause 8.2:8.2.10 Mid-span PON reach extendersThe PON reach extender is modelled as an ONT (the management entity) containing cardholders and circuit packs whose functions are to extend the reach of one or more PONs. The PON reach extender's own management ONT is understood to exist as a member of one of the extended PONs.Figure 8.2.10-1 – Mid-span PON reach extender core (repeater)NOTE 1 – In many cases, the RE ANI-G and PPTP RE UNI will be implemented on the same circuit pack. If so, the port mapping package can be used to create the hybrid line card.Figure 8.2.10-2 – Mid-span PON reach extender core (optical amplifier)NOTE 2 – In many cases, the RE upstream amplifier and RE downstream amplifier will be implemented on the same circuit pack. If so, the port mapping package can be used to create the hybrid line card.Figure 8.2.10-3 – Mid-span PON reach extender core (hybrid)Figure 8.2.10-4 – Mid-span PON reach extender core (hybrid)Figure 8.2.10-5 – In-band management for mid-span PON reach extender8) Clause 9.1.1, ONT-Ga) Replace:Traffic management option:This attribute identifies the upstream traffic management function implemented in the ONT. There are two options:0 Priority controlled and flexibly scheduled upstream traffic. The trafficscheduler and priority queue mechanism are used for upstream traffic.1 Rate controlled upstream traffic. The maximum upstream traffic ofeach individual connection is guaranteed.With:Traffic management option:This attribute identifies the upstream traffic management function implemented in the ONT. There are three options:0 Priority controlled and flexibly scheduled upstream traffic. The trafficscheduler and priority queue mechanism are used for upstream traffic.1 Rate controlled upstream traffic. The maximum upstream traffic ofeach individual connection is guaranteed by shaping.2 Priority and rate controlled. The traffic scheduler and priority queuemechanism are used for upstream traffic. The maximum upstream traffic of each individual connection is guaranteed by shaping.b) Add the following new attribute:ONT survival time:This attribute indicates the minimum guaranteed time in milliseconds between the loss of external power and the silence of the ONT. This doesnot include survival time attributable to a backup battery. The value zeroimplies that the actual time is not known. (R) (optional) (1 byte)9) Clause 9.1.2, ONT2-GReplace:OMCC version: This attribute identifies the version of the OMCC protocol being used by the ONT. This allows the OLT to manage a network with ONTs that supportdifferent OMCC versions. Release levels of this Recommendation may besupported with the following code points:0x80 G.984.4 (06/04).NOTE – For historic reasons, this codepoint may also appear in ONTs that supportlater versions of G.984.4.0x81 G.984.4 Amd.1 (06/05)0x82 G.984.4 Amd.2 (03/06)0x83 G.984.4 Amd.3 (12/06)0x84 G.984.4 (02/2008)(R) (mandatory) (1 byte)With:OMCC version:This attribute identifies the version of the OMCC protocol being used by the ONT. This allows the OLT to manage a network with ONTs that supportdifferent OMCC versions. Release levels of this Recommendation may besupported with the following code points:0x80 G.984.4 (06/04).NOTE – For historic reasons, this codepoint may also appear in ONTs that supportlater versions of G.984.4.0x81 G.984.4 Amd.1 (06/05)0x82 G.984.4 Amd.2 (03/06)0x83 G.984.4 Amd.3 (12/06)0x84 G.984.4 (02/08)0x85 G.984.4 (2008) Amd.1 (06/09)(R) (mandatory) (1 byte)10) Clause 9.1.5, CardholderWhere Table 9.1.5-1 presently reads:Table 9.1.5-1 − Circuit pack typesCoding Content Description224..242 ReservedModify it to read:Table 9.1.5-1 – Circuit pack types Coding Content Description 224..238 Reserved239 Mid-span PON reachextender UNI The UNI of a mid-span PON reach extender, 2488 Mbit/s downstream and 1244 Mbit/s upstream240 Mid-span PON reachextender ANI The ANI of a mid-span PON reach extender, 2488 Mbit/s downstream and 1244 Mbit/s upstream241 Mid-span PON reachextender upstream opticalamplifierThe 1310 nm wavelength optical amplifier242 Mid-span PON reachextender downstreamoptical amplifierThe 1490 nm wavelength optical amplifier11) Clause 9.1.10, Protection dataModify the description of this managed entity to read as follows:This managed entity models the capability and parameters of PON protection. An ONT that supports PON protection automatically creates an instance of this managed entity.NOTE 1 – Equipment protection is modelled with the equipment protection profile and cardholder managed entities.NOTE 2 – For ONTs that implement reach extender functions, this ME can be used to describe OMCI protection, reach extender R'/S' protection, or both. For reach extender R'/S' protection, the protection type must be 1:1 without extra traffic, because the switching is done on a link-by-link basis, and the protection link is in cold stand-by mode. The instance that pertains to OMCI protection has ME ID = 0. RelationshipsOne instance of this managed entity is associated with two instances of the ANI-G, RE ANI-G or RE upstream amplifier. One of the ANI managed entities represents the working side; the other represents the protection side.AttributesManaged entity id:This attribute uniquely identifies each instance of this managed entity.This ME is numbered in ascending order from 0. (R) (mandatory)(2 bytes)Working ANI-G pointer:This attribute points to the ANI-G, RE ANI-G or RE upstream amplifier managed entity that represents the working side of PON protection. (R) (mandatory) (2 bytes)Protection ANI-G pointer:This attribute points to the ANI-G, RE ANI-G or RE upstream amplifier managed entity that represents the protection side of PON protection.(R) (mandatory) (2 bytes)(Remainder of description remains unchanged)12) Clause 9.2.1, ANI-G Replace:Piggyback DBA reporting:This attribute indicates the ONT's piggyback DBA reporting format capabilities. [ITU-T G.984.3] defines three possible piggyback reporting modes. For reporting mode 0, the single field is the entire report. For reporting mode 1, the DBA report is two fields long. For reporting mode 2, the DBA report is four fields long. Mode 0 is mandatory for ONTs that utilize the piggyback DBA reporting method; modes 1 and 2 are optional. The following coding indicates the ONT's piggyback DBA reporting mode capabilities:0 Mode 0 only1 Modes 0 and 12 Modes 0 and 23 Modes 0, 1 and 24 Piggyback DBA reporting not supported(R) (mandatory) (1 byte)Whole ONT DBA reporting:This attribute indicates that the ONT supports whole ONT DBA reporting (1) as specified in [ITU-T G.984.3], or that it does not (0). (R) (mandatory) (1 byte)With:Piggyback DBA reporting:This attribute indicates the ONT's piggyback DBA reporting format capabilities. [ITU-T G.984.3] defines two possible piggyback reporting modes. For reporting mode 0, the single field is the entire report. For reporting mode 1, the DBA report is two fields long. Mode 0 is mandatory for ONTs that utilize the piggyback DBA reporting method; mode 1 is optional. The following coding indicates the ONT's piggyback DBA reporting mode capabilities:0 Mode 0 only1 Modes 0 and 12 Deprecated3 Deprecated4 Piggyback DBA reporting not supported(R) (mandatory) (1 byte)Whole ONT DBA reporting:This attribute is deprecated. It should be set to 0 by the ONT and ignored by the OLT. (R) (mandatory) (1 byte)13) Clause 9.2.3, GEM port network CTPa) Replace:Port id value:This attribute is the port ID of the GEM port associated with this CTP.(R, W, Set-by-create) (mandatory) (2 bytes)Port id value:This attribute is the port ID of the GEM port associated with this CTP.NOTE 1 – While nothing forbids the existence of several GEM port networkCTPs with the same port id value, downstream traffic is modelled as beingdelivered to all such GEM port network CTPs. Be aware of potential difficultiesassociated with defining downstream flows and aggregating PM statistics.(R, W, Set-by-create) (mandatory) (2 bytes)b) Replace:Traffic management pointer for upstream:If the traffic management option attribute in the ONT-G ME is 0 (priority controlled), this pointer specifies the priority queue-G ME serving this GEM port network CTP. If the traffic management option attribute is 1 (rate controlled), this attribute redundantly points to the T-CONT serving this GEM port network CTP. (R, W, Set-by-create) (mandatory) (2 bytes)Traffic descriptor profile pointer:This attribute points to the instance of the GEM traffic descriptor managed entity that contains the traffic parameters used for this GEM port network CTP ME. This attribute is used when the traffic management option attribute in the ONT-G ME is 1 (rate controlled). (R, W, Set-by-create) (optional) (2 bytes)See also Appendix III.With:Traffic management pointer for upstream:If the traffic management option attribute in the ONT-G ME is 0 (priority controlled) or 2 (priority and rate controlled), this pointer specifies the priority queue-G ME serving this GEM port network CTP. If the traffic management option attribute is 1 (rate controlled), this attribute redundantly points to the T-CONT serving this GEM port network CTP. (R, W, Set-by-create) (mandatory) (2 bytes)Traffic descriptor profile pointer for upstream:This attribute points to the instance of the GEM traffic descriptor managed entity that contains the upstream traffic parameters used for this GEM port network CTP ME. This attribute is used when the traffic management option attribute in the ONT-G ME is 1 (rate controlled), specifying the PIR/PBS to which the upstream traffic is shaped. This attribute is also used when the traffic management option attribute in the ONT-G ME is 2 (priority and rate controlled), specifying the CIR/CBS/PIR/PBS to which the upstream traffic is policed. (R, W, Set-by-create) (optional) (2 bytes) See also Appendix III.c) Replace:Priority queue pointer for downstream:This attribute points to the instance of the priority queue-G used for this GEM port network CTP in the downstream direction. (R, W, Set-by-create) (mandatory) (2 bytes)Priority queue pointer for downstream:This attribute points to the instance of the priority queue-G used for this GEM port network CTP in the downstream direction. It is the responsibility of the OLT to provision the downstream pointer in a way that is consistent with bridge and mapper connectivity. If the pointer is undefined, downstream queueing is determined by other mechanisms in the ONT. (R, W, Set-by-create) (mandatory) (2 bytes)NOTE 3 – If the GEM port network CTP is associated with more than one UNI (downstream multicast), the downstream priority queue pointer defines a pattern (e.g., queue number 3for a given UNI) to be replicated (i.e., to queue number 3) at the other affected UNIs.d) Add the following additional attribute:Traffic descriptor profile pointer for downstream:This attribute points to the instance of the GEM traffic descriptor managed entity that contains the downstream traffic parameters used for this GEM port network CTP ME. This attribute is used when the traffic management option attribute in the ONT-G ME is 2 (priority and rate controlled), specifying the CIR/CBS/PIR/PBS to which the downstream traffic is policed. (R, W, Set-by-create) (optional) (2 bytes)See also Appendix III.14) Clause 9.2.4, GEM interworking termination pointa) Replace:Interworking option:This attribute identifies the type of non-GEM function that is being interworked. The options are:0 UnstructuredTDM1 MAC bridge LAN2 Reserved for future use3 IP data service4 Video return path5 802.1pmapper(R, W, Set-by-create) (mandatory) (1 byte)Service profile pointer:This attribute points to an instance of a service profile, such as:CES service profile-G if interworking option = 0MAC bridge service profile if interworking option = 1IP router service profile if interworking option = 3Video return path service profile if interworking option = 4802.1p mapper service profile if interworking option = 5(R, W, Set-by-create) (mandatory) (2 bytes)Interworking option:This attribute identifies the type of non-GEM function that is being interworked. The options are:0 UnstructuredTDM1 MAC bridge LAN2 Reserved for future use3 IP data service4 Video return path5 802.1pmapper6 Downstreambroadcast(R, W, Set-by-create) (mandatory) (1 byte)Service profile pointer:This attribute points to an instance of a service profile, such as:CES service profile-G if interworking option = 0MAC bridge service profile if interworking option = 1IP router service profile if interworking option = 3Video return path service profile if interworking option = 4802.1p mapper service profile if interworking option = 5Null pointer if interworking option = 6(R, W, Set-by-create) (mandatory) (2 bytes)b) Replace:GAL profile pointer:This attribute points to an instance of the GAL profile. The relationship between the interworking option and the related GAL profile is:Interworking option GAL profile type0 GAL TDM profile1 GAL Ethernet profile2 Reserved for future use3 GAL Ethernet profile for data service4 GAL Ethernet profile for video returnpath5 GAL Ethernet profile for 802.1pmapper(R, W, Set-by-create) (mandatory) (2 bytes)GAL loopback configuration:This attribute sets the loopback configuration when using GEM mode: 0 Noloopback.1 Loopback of downstream traffic after GAL.The default value of this attribute is 0. (R, W) (mandatory) (1 byte)GAL profile pointer:This attribute points to an instance of the GAL profile. The relationship between the interworking option and the related GAL profile is:Interworking option GAL profile type0 GAL TDM profile1 GAL Ethernet profile2 Reserved for future use3 GAL Ethernet profile for data service4 GAL Ethernet profile for video returnpath5 GAL Ethernet profile for 802.1pmapper6 Nullpointer(R, W, Set-by-create) (mandatory) (2 bytes)GAL loopback configuration:This attribute sets the loopback configuration when using GEM mode:0 Noloopback1 Loopback of downstream traffic after GALThe default value of this attribute is 0. When the interworking option is 6 (downstream broadcast), this attribute is not used. (R, W) (mandatory) (1 byte)15) Clause 9.2.6, GEM port performance monitoring history dataReplace:Lost packets:This attribute counts background GEM frame loss. It does notdistinguish between packets lost because of header bit errors or bufferoverflows; it records only loss of information. (R) (mandatory)(4 bytes)Misinserted packets:This attribute counts GEM frames misrouted to this GEM port. (R)(mandatory) (4 bytes)Received packets:This attribute counts GEM frames that were received correctly at themonitored GEM port. (R) (mandatory) (5 bytes)Received blocks:This attribute counts GEM blocks that were received correctly at themonitored GEM port. (R) (mandatory) (5 bytes)Transmitted blocks:This attribute counts GEM blocks originated by the transmitting endpoint (i.e., backward reporting is assumed). (R) (mandatory) (5 bytes) Impaired blocks:This severely errored data block counter is incremented whenever oneof the following events takes place: the number of misinserted packetsreaches its threshold, the number of bipolar violations reaches itsthreshold, or the number of lost packets reaches its threshold.Threshold values are based on vendor-operator negotiation. (R)(mandatory) (4 bytes)。
详解MTK编译命令及相关文件
详解MTK编译命令及相关文件MTK编译分资源的编译和代码的编译:一资源的编译1 在如下的情况下，需要重新编译资源：(1) 修改了字符串资源文件(Ref_list.txt)、字库文件(FontRes.c,L_**.h)、MMI配置文件(MMI_featuresPLUTO.h)等，这些文件位于..\plutommi\Customer\CustResource\PLUTO_MMI\ ；(2) 修改了MMI资源装载配置文件，这些文件位于..\plutommi\Customer\CustResource\PLUTO_MMI\Res_MMI 目录下，这个目录下都是Res_*.*文件，是各个AP或模块的资源装载文件，包括菜单、图片和字符串资源的装载配置；注意：Cust*.*文件是资源编译生成的，不能手动修改。
2 编译方法(1)在DOS环境下执行资源编译命令resgen即可;(2)进入..\plutommi\Customer目录，执行remakeResource.bat。
若是在模拟器上使用，则还需要在VC环境下build一下，就可以看到效果了。
3 与资源编译相关的文件ResGenerator_HW.bat在编译手机目标板工程时，有“new”，“resgen”等选项时，自动调用；ResGenerator.bat手机PC模拟器工程中，添加新资源后，需要手动调用；remakeResource.bat手机PC模拟器工程中，只替换图片或更新字符串等情况下，需要手动调用；res_gen.txt资源编译的log文件，在build目录下；Makefile..\plutommi\Customer\ResGenerator\Makefile此文件是资源装载预编译程序的Makefile；PopulateRes.c..\plutommi\MMI\Resource\PopulateRes.c执行资源装载，主体是函数PopulateResData()，mtk_resgenerator.exe在执行时会调用该函数；MMIDataType.h..\plutommi\mmi\Inc\MMIDataType.h定义AP的ID范围。
mtk memroy dump分析流程
mtk memroy dump分析流程：1.如何抓memory dump。
2.解析memroy dump。
3.tarce 32 分析。
一.如何抓memory dump。
完整的memorydump包含以下文件：1. memorydump.bin (此文件是透过Catcher保存的，请参考后面的操作步骤)2. catcher log (*.clg, 此文件是透过Catcher保存的，请参考后面的操作步骤)3. ELF 文件(\build\<project>\*.elf) (请注意NFB项目会有两个ELF(for Bootloader and for MAUI)，请提供for MAUI的，即size较大的)提示：只有当抓memory dump对应的binary与所提供的ELF文件是同一次编译生成的(需要参考ELF文件中的debug信息)，且只有debug版本的ELF文件，我们才能分析，请务必注意!!!您可以按如下步骤进行：1. 打开debug选项before 10A:在makefile(\make\<project>.mak)中设置CUSTOM_CFLAGS = -g -gtp10A的项目(因RVCT存在bug, 全部module都开debug会出现link error"out of memory", 请参考下面的说明仅开部分解决问题需要的module, 但init和nvram中包含debug所需的basic 信息, 请确保init和nvram打开debug):(1)确保makefile中--debug --no_debug_macros处于关闭状态，正确设置为CUSTOM_CFLAGS = # --debug --no_debug_macros(2)make\USER_SPECIFIC.mak文件末尾处添加如下两行语句后保存，DEBUG_MODULES = init nvram # means only init and nvram will apply --debug --no_debug_macros, 若有其他module也需要debug symbol, 可以加在nvram后面CUSTOM_CFLAGS :=11A and after(不建议全部模块打开debug，原因同10A):(1)确保makefile中--debug --no_debug_macros处于关闭状态，正确设置为CUSTOM_CFLAGS = # --debug --no_debug_macros(2)makefile中设置CUSTOM_DEBUG_MODULES = INIT NVRAM #means only init and nvram will apply --debug --no_debug_macros, 若有其他module也需要debug symbol, 可以加在nvram后面, 若没有CUSTOM_DEBUG_MODULES定义, 可自行添加2. 编译生成debug版本(make new), 并Download Binary.10A及以后的项目, 由于只是部分模块开debug, 可以只m c,r这些模块3. 打开Memory dump开关；进入工程模式，选择Misc.\Memory dump, 将其设置为On提示：该开关默认为关，并且开机时系统会将其恢复成默认值，所以您的设置只对当次开机有效，若需抓Memory dump，请在每次开机的重新开启此开关若无法进入工模操作请尝试修改代码来打开，方法如下：(1)在application_initialize之前extern kal_uint32 INT_MemoryDumpFlag;(2)在application_initialize中调用mainp的上一行添加INT_MemoryDumpFlag = 0x26409001; [Note]: 项目MP时请务必删除上述代码, 否则手机在end user端遇到异常时无法自动重启4. 连上Catcher(Catcher 的filter设置为Field Trial)，复制问题；5. 当发生异常时，选择Advance\Memory Dump，在弹出的窗口中选择Start按钮开始Memorydump；提示：发生异常时，LCD上显示错误类型，并且不会自动重启，若手机直接重启或者进行memorydump过程中失败, 请参考后面的常规检查项，Catcher Dump完成之后，会弹出提示窗口告诉您，请不要在此之前关闭Catcher或者断开手机与PC连接6. Memory dump完成之后，请同时保存Log (选择File\Save As)；7. 将以上两步保存下来的文件(*.bin, *.clg)及Build\<project>\*.elf寄给我们。
BU_61580寄存器说明中文版
目录
1 SOFTWARE INTERFACE 软件接口 ....................................................................................................................... 1 1.1. POWER TURN-ON/INITIALIZATION STATE 上电/初始化状态 .................................................................... 1 1.2. OVERALL ADDRESS MAPPING: WORDS VS. BYTES 整体地址映射：字 和 位 ........................................ 2 1.3. SOFTWARE INTERFACE: INTERNAL RAM 软件接口：内部 RAM .............................................................. 3 1.4. INTERNAL REGISTERS ADDRESS AND BIT MAPPING 内部寄存器地址和位映射 ..................................... 3 1.5. INTERRUPT MASK REGISTER 中断屏蔽寄存器 ........................................................................................ 6 1.5.1. RAM PARITY ERROR RAM 校验错误..................................
VS2008由于应用程序配置不正确,应用程序未能启动
VS2008编译的程序在某些机器上运行提示“由于应用程序配置不正确，应用程序未能启动”的问题VC9编译的程序在没有装过VC9（确切的说是.Net Framework3.5）的机器上运行时，如果提示“由于应用程序配置不正确，应用程序未能启动。
重新安装应用程序可能会纠正这个问题。
”这个错误，那么就说明该程序动态链接了VC9的运行时库，（如果还用到了MFC，那么可能动态链接了VC9的MFC库，同理还有ATL 库），以及缺少对应的manifest文件，程序在目标机器上没有找到这些库和配置文件，因此导致了这个错误。
出现这种情况的VC9编译器可能存在3个版本，接下来分别阐明：1、没有打过任何补丁的VS2008该版本对应的CRT/MFC/ATL库的版本号为9.0.21022.8，这个版本号在后面会用到。
这个版本的程序部署比较简单，直接把VC安装目录下的redist目录（C:\Program Files\Microsoft Visual Studio 9.0\VC\redist）中需要的库以及对应的manifest文件拷贝到执行程序同目录下，这样程序到任何机器上都能够正常运行了。
2、打过SP1补丁的VS2008打过该补丁后，系统中存在着两个版本的CRT/MFC/ATL库，版本号分别为9.0.21022.8和9.0.30729.1，这导致了manifest文件中记录的版本号和实际库的版本号不一致（程序要求它们的版本号一致才能运行）。
这个版本的程序部署需要两个步骤，首先要使manifest文件中依赖项的版本号与实际库的版本号一致，均为9.0.30729.1，方法是在工程设置中增加一个宏定义_BIND_TO_CURRENT_VCLIBS_VERSION，该宏定义于C:\Program Files\Microsoft Visual Studio 9.0\VC\include\crtassem.h文件中，然后重新编译程序。
H3C 链路聚合命令
Ethernet1/2: Aggregation Interface: Bridge-Aggregation10 Local:
Port Number: 2 Port Priority: 32768 Oper-Key: 2 Flag: {ACDEF} Remote: System ID: 0x8000, 000f-e267-6c6a Port Number: 26 Port Priority: 32768 Oper-Key: 2 Flag: {ACDEF} Received LACP Packets: 5 packet(s) Illegal: 0 packet(s) Sent LACP Packets: 7 packet(s)
Flags: A -- LACP_Activity, B -- LACP_Timeout, C -- Aggregation, D -- Synchronization, E -- Collecting, F -- Distributing, G -- Defaulted, H -- Expired
1-3
命令手册 接入分册 链路聚合
第 1 章 链路聚合配置命令
需要注意的是，由于静态聚合组无法获知对端信息，因此只显示端口编号和操作 Key 值。
【举例】 # 显示静态聚合组中端口 Ethernet1/1 链路聚合的详细信息。
<Sysname> display link-aggregation member-port ethernet 1/1
agg-id
link-aggregation group mode
agg-id
port link-aggregation group
agg-id
port-group aggregation
PXA270_linux快速开始手册_v1.0-3
3．第一次启动 UP-TECHPXA270
首先启动一个终端仿真程序 （如 Linux 下的 MINICOM 或 WINDOWS 下的超级终端） ， 进行配置，一般的参数为波特率 115200，数据位 8 位，停止位 1，无奇偶校验，软件硬件 流控设为无。这里以 WINDOWS XP 下的超级终端为例进行演示： 点击“程序>附件>通讯>超级终端”，进入如图 5.7 所示的界面：
Bot left : X = 891 Y = Middle: X = 522 Y = 539
633.976074 -0.666110 0.024437 506.731049 -0.012794 -0.529625 Calibration constants: 41548256 -43654 1601 33209126 -838 -34709 65536
注意： 第一次执行 “qt” ， 则出现触摸屏的校准， 依次使用触摸笔点击屏幕四角及中央的 “＋” 标记即可。
图 6.1
Qtopia 的主界面
关于命令 “qt” 及后几节用到的 “mp” “rtrw” “doom” 等命令的说明， 可输入命令 “alais” 来查看，命令行如下所示：
6
[root@PXA270 /]#alias +='more' cd..='cd ..' d='ls' da='ls -a' demo='cd /mnt/yaffs/demo' dir='ls' doom='cd /mnt/yaffs/doom; ./run.sh' ll='ls -l' m='more' mntnfs='mount -t nfs -o nolock' mp='mplayer -fs -quiet' qt='/mnt/yaffs/Qtopia/qtopia.sh' quit='exit' rtrw='mount -t jffs2 -o remount /dev/mtdblock/0 /' v='ls -l' va='ls -la' vdir='ls -l'
ug909-vivado-partial-reconfiguration
Vivado Design Suite User GuidePartial ReconfigurationUG909 (v2014.1) April 2, 2014Revision HistoryThe following table shows the revision history for this document.Date Version Revision04/02/20142014.1Revisions to manual for Vivado Design Suite 2014.1 release:In Design Requirements and Guidelines, page9, changed device support informationto match device support in 2014.1 Vivado release. Also modified device supportinformation throughout document.In Design Criteria, page11, changed text to indicate that dedicated encryptionsupport for partial bitstreams is now available natively for 7series devices.In Automatic Adjustments for Reconfigurable Partition Pblocks, page39 and CreatingReconfigurable Partition Pblocks Manually, page41, described the PblockSNAPPING_MODE property, which automatically resizes Pblocks to ensure noback-to-back violations occur for 7 series designs.Changed command line examples to show that the update_design command willnot accept an NGC file as input.Method 1: Create a Single RM Checkpoint (DCP),page17 presents a process for including an NGC input file into an RM checkpoint(DCP), so the NGC file casn be resolved to its cells.Table of ContentsRevision History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2Chapter1:IntroductionOverview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Introduction to Partial Reconfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Design Considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Chapter2:Vivado Software FlowSoftware Flow Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Partial Reconfiguration Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Partial Reconfiguration Constraints and Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Software Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Tcl Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Chapter3:Design Considerations and GuidelinesIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Global Clocking Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Partition Pin Placement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Active Low Resets and Clock Enables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Decoupling Functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Reconfigurable Partition Pblock Sizes and Shapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Black Boxes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Implementation Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Design Revision Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Simulation and Verification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Chapter4:Configuring the FPGA DeviceConfiguration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Configuration Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Downloading a Full Bit File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Downloading a Partial Bit File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52System Design for Configuring an FPGA Device. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Partial Bitstream CRC Checking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuration Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Configuration Debugging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Chapter5:Known Issues and LimitationsKnown Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Known Limitations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Appendix A:Additional Resources and Legal NoticesXilinx Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Solution Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Chapter1 IntroductionOverviewPartial Reconfiguration allows for the dynamic change of modules within an active design.This flow requires the implementation of multiple configurations which ultimately results in full bitstreams for each configuration, and partial bitstreams for each ReconfigurableModule.The number of configurations required varies by the number of modules that need to be implemented. However, all configurations use the same top-level, or static, placement and routing results. These static results are exported from the initial configuration, andimported by all subsequent configurations using checkpoints.This guide:•Is intended for designers who want to create a partially reconfigurable FPGA design.•Assumes familiarity with FPGA design software, particularly Xilinx® Vivado® Design Suite.•Has been written specifically for Vivado Design Suite Release 2014.1. This release supports Partial Reconfiguration for Virtex®-7, Kintex®-7, Artix®-7, and Zynq®-7000AP SoC devices.•Describes Partial Reconfiguration as implemented in the Vivado toolset.VIDEO:For an overview of the Vivado Partial Reconfiguration solution in 7 series devices, see theVivado Design Suite QuickTake Video: Partial Reconfiguration in Vivado.Introduction to Partial ReconfigurationFPGA technology provides the flexibility of on-site programming and re-programming without going through re-fabrication with a modified design. Partial Reconfiguration (PR) takes this flexibility one step further, allowing the modification of an operating FPGA design by loading a partial configuration file, usually a partial BIT file. After a full BIT fileconfigures the FPGA, partial BIT files can be downloaded to modify reconfigurable regions in the FPGA without compromising the integrity of the applications running on those parts of the device that are not being reconfigured.Figure 1-1 illustrates the premise behind Partial Reconfiguration.As shown, the function implemented in Reconfig Block A is modified by downloading one of several partial BIT files, A1.bit , A2.bit , A3.bit , or A4.bit . The logic in the FPGA design is divided into two different types, reconfigurable logic and static logic. The gray area of the FPGA block represents static logic and the block portion labeled Reconfig Block "A" represents reconfigurable logic. The static logic remains functioning and is unaffected by the loading of a partial BIT file. The reconfigurable logic is replaced by the contents of the partial BIT file.There are many reasons why the ability to time multiplex hardware dynamically on a single FPGA device is advantageous. These include: •Reducing the size of the FPGA device required to implement a given function, with consequent reductions in cost and power consumption•Providing flexibility in the choices of algorithms or protocols available to an application •Enabling new techniques in design security •Improving FPGA fault tolerance •Accelerating configurable computingIn addition to reducing size, weight, power and cost, Partial Reconfiguration enables new types of FPGA designs that are impossible to implement without it.Figure 1-1:Basic Premise of Partial ReconfigurationTerminologyThe following terminology is specific to the Partial Reconfiguration feature and is used throughout this document.Bottom-Up SynthesisBottom-Up Synthesis is synthesis of the design by modules, whether in one project or multiple projects. Bottom-Up Synthesis requires that a separate netlist is written for each Partition, and no optimizations are done across these boundaries, ensuring that each portion of the design is synthesized independently. Top-level logic must be synthesized with black boxes for Partitions.ConfigurationA Configuration is a complete design that has one Reconfigurable Module for each Reconfigurable Partition. There may be many Configurations in a Partial Reconfiguration FPGA project. Each Configuration generates one full BIT file as well as one partial BIT file for each Reconfigurable Module.Configuration FrameConfiguration frames are the smallest addressable segments of the FPGA configuration memory space. Reconfigurable frames are built from discrete numbers of these lowest-level elements. In a 7 series device, the base reconfigurable frames are one element (CLB, BRAM, DSP) wide by one clock region high.Internal Configuration Access Port (ICAP)The Internal Configuration Access Port (ICAP) is essentially an internal version of the SelectMAP interface. For more information, see the 7 Series FPGAs Configuration User Guide (UG470) [Ref1].Partial Reconfiguration (PR)Partial Reconfiguration is modifying a subset of logic in an operating FPGA design by downloading a partial bitstream.PartitionA Partition is a logical section of the design, defined by the user at a hierarchical boundary, to be considered for design reuse. A Partition is either implemented as new or preserved from a previous implementation. A Partition that is preserved maintains not only identical functionality but also identical implementation.Partition PinPartition pins are the logical and physical connection between static logic and reconfigurable logic. Partition pins are automatically created for all Reconfigurable Partition ports.Processor Configuration Access Port (PCAP)The Processor Configuration Access Port (PCAP) is similar to the Internal Configuration Access Port (ICAP) and is the primary port used for configuring a Zynq-7000 device. For more information, see the Zynq-7000 All Programmable Technical Reference Manual (UG585) [Ref2].Reconfigurable FrameReconfigurable frames (in all references other than "configuration frames" in this guide) represent the smallest reconfigurable region within an FPGA device. Bitstream sizes of reconfigurable frames vary depending on the types of logic contained within the frame.Reconfigurable LogicReconfigurable Logic is any logical element that is part of a Reconfigurable Module. These logical elements are modified when a partial BIT file is loaded. Many types of logical components may be reconfigured such as LUTs, flip-flops, BRAM, and DSP blocks.Reconfigurable Module (RM)A Reconfigurable Module (RM) is the netlist or HDL description that is implemented within a Reconfigurable Partition. Multiple Reconfigurable Modules will exist for a Reconfigurable Partition.Reconfigurable Partition (RP)Reconfigurable Partition (RP) is an attribute set on an instantiation that defines the instance as reconfigurable. The Reconfigurable Partition is the level of hierarchy within which different Reconfigurable Modules will be implemented. Tcl commands such asopt_design, place_design and route_design detect the HD.RECONFIGURABLE property on the instance and process it correctly.Static LogicStatic Logic is any logical element that is not part of a Reconfigurable Partition. The logical element is never partially reconfigured and is always active when Reconfigurable Partitions are being reconfigured. Static Logic is also known as Top-level Logic.Static DesignThe Static Design is the part of the design that will not change during partial reconfiguration. The static design includes the top level and all modules not defined as reconfigurable. The Static Design is built with Static Logic and Static Routing.Design ConsiderationsPartial Reconfiguration (PR) is an expert flow within the Vivado Design Suite. Prospective customers must understand the following requirements and expectations before embarking on a PR project.Design Requirements and Guidelines•Partial Reconfiguration requires the use of Vivado 2013.3 or newer.°Partial Reconfiguration is supported in the ISE Design Suite as well. Please consult the Partial Reconfiguration User Guide (UG702)[Ref3] for more information.•Device support: Kintex-7, Virtex-7, and Zynq AP SoC devices, plus the three largest Artix-7 devices.°New devices added in the 2014.1 Vivado Design Suite release:-Virtex-7: 7VH580T, 7VH870T-Artix-7: 7A200T, 7A100T, 7A75T-Zynq AP SoC: 7Z100, 7Z015°The Artix-7 50T and 35T devices are the two 7 series devices that are not yet supported.°UltraScale™ devices are not yet supported.•PR is supported via Tcl or command line only; there is no project support at this time.•Floorplanning is required to define reconfigurable regions, per element type.°For greatest efficiency, and to use the RESET_AFTER_RECONFIG feature, vertically align to frame/clock region boundaries.°Horizontal alignment rules also apply. See Create a Floorplan for the Reconfigurable Region in Chapter2 for more information.•Bottom-up synthesis (to create multiple netlist files) and management of Reconfigurable Module netlist files is the responsibility of the user.°Any synthesis tool may be used. Disable I/O insertion to create Reconfigurable Module netlists.°Vivado Synthesis uses the out-of-context Module Analysis flow for Reconfigurable Module synthesis.•Standard timing constraints are supported, and additional timing budgeting capabilities are available if needed.• A unique set of Design Rule Checks (DRCs) has been established to guide users on a successful path to design completion.• A PR design must consider the initiation of Partial Reconfiguration as well as the delivery of partial BIT files, either within the FPGA or as part of the system design.• A Reconfigurable Partition must contain a super set of all pins to be used by the varying Reconfigurable Modules implemented for the partition. It is expected that this will lead to unused inputs or outputs for some modules, and is designed into the flexibility of the PR solution. The unused inputs will be left dangling inside of the module; drive outputs to a constant if this is an issue for your design.°In the case of a black box RM (no logic) after update_design -black_box has been issued, all partition pin outputs will be undriven. If this black box module will be used to create a bitstream, it is recommended that decoupling logic for this RP remain active while the black box is loaded in the device.Design PerformancePerformance metrics will vary from design to design, and the best results will be seen when if you follow the Hierarchical Design techniques documented in the Hierarchical Design Methodology Guide (UG748) [Ref4], and in Repeatable Results with Design Preservation (WP362) [Ref5]. These documents were created for the ISE Design Suite, but the methodologies contained therein still apply for the Vivado Design Suite.However, the additional restrictions that are required for silicon isolation are expected to have an impact on most designs. The application of Partial Reconfiguration rules, such as routing containment, exclusive placement, and no optimization across reconfigurable module boundaries, will mean that the overall density and performance will be lower for a PR design than for the equivalent flat design. The overall design performance for PR designs will vary from design to design based on factors such as the number of reconfigurable partitions, the number of interface pins to these partitions, and the size and shape of Pblocks.Design Criteria•Some component types can be reconfigured and some cannot.°Reconfigurable resources include CLB, BRAM, and DSP component types as well as routing resources.°Clocks and Clock modifying logic cannot be reconfigured, and therefore must reside in the static region.-Includes BUFG, BUFR, MMCM, PLL, and similar components°The following components cannot be reconfigured, and therefore must reside in the static region:-I/O and I/O related components (ISERDES, OSERDES, IDELAYCTRL, etc.)-Serial transceivers (MGTs) and related components-Individual architecture feature components (such as BSCAN, STARTUP, XADC, etc.) must remain in the static region of the design•Global clocking resources to Reconfigurable Partitions are limited, depending on the device and on the clock regions occupied by these Reconfigurable Partitions.•IP restrictions may occur due to components used to implement the IP. Examples include:°Vivado Debug Hub (BSCAN and BUFG)°IP modules with embedded global buffers or I/O°MIG controller (MMCM)•Reconfigurable Modules must be initialized to ensure a predictable starting condition after reconfiguration. You can do this manually with a local reset, or via dedicated GSR events by selecting the RESET_AFTER_RECONFIG feature.•Decoupling logic is highly recommended to disconnect the reconfigurable region from the static portion of the design during the act of Partial Reconfiguration.°Clock and other inputs to Reconfigurable Modules can be decoupled to prevent spurious writes to memories during reconfiguration. This should be considered if RESET_AFTER_RECONFIG is not used.• A reconfigurable partition must be flooorplanned, so the module must be a block that can be contained by a Pblock and meet timing. If the module is complete, it isrecommended to run this design through a non-PR flow to get an initial evaluation of placement, routing, and timing results. If the design has issues in a non-PR flow, these should be resolved before moving on to the PR flow.•Each module pin on an RP will have a partition pin. This is a routing point that connects static logic to the RP. If a design has too many partition pins for the number of availablerouting resources, routing congestion can occur. Consider the number of external pins on the RP, and pick a module that has a minimum required set of pins.•Virtex-7 SSI devices (7V2000T, 7VX1140T, 7VH870T, 7VH580T) have two fundamental requirements. These requirements are:°Reconfigurable regions must be fully contained within a single SLR. This ensures that the global reset events are properly synchronized across all elements in theReconfigurable Module, and that all Super Long Lines (SLL) are contained within the static portion of the design. SLL are not partially reconfigurable.°If ICAP is used for partial bitstream delivery, it must be one located on the Master SLR, which is SLR1 for these devices. Apply a location constraint on the ICAP to the ICAP_X0Y2 or ICAP_X0Y3 locations only. The bitstream format is such that thestandard daisy chain through the four SLRs is maintained. Do not use an ICAP onany of the other SLRs, even if the reconfigurable region is located there.•Dedicated encryption support for partial bitstreams is available natively for 7series devices.•7 series devices can utilize a per-frame CRC checking mechanism, enabled via write_bitstream, to ensure each frame is valid before loading.Note:This feature will be implemented in a future Vivado release.Partial Reconfiguration is a powerful capability within Xilinx FPGAs, and understanding the capabilities of the silicon and software is instrumental to success with this technology. While trade-offs must be recognized and considered during the development process, the overall result will be a more flexible implementation of your FPGA design.Chapter2 Vivado Software FlowSoftware Flow OverviewThe Vivado® Partial Reconfiguration design flow is similar to a standard design flow, with some notable departures. The implementation software automatically manages thelow-level details to meet silicon requirements. The user must provide guidance to define the design structure and floorplan. The steps for processing a PR design can be summarized as follows:1.Synthesize the static and Reconfigurable Modules separately.2.Create physical constraints (Pblocks) to define the reconfigurable regions.3.Set the HD.RECONFIGURABLE property on each Reconfigurable Partition.4.Implement a complete design (static and one Reconfigurable Module perReconfigurable Partition) in context.5.Save a design checkpoint for the full routed design.6.Remove Reconfigurable Modules from this design and save a static-only designcheckpoint.7.Lock the static placement and routing.8.Add new Reconfigurable Modules to the static design and implement this newconfiguration, saving a checkpoint for the full routed design.9.Repeat Step 8 until all Reconfigurable Modules are implemented.10.Run a verification utility (pr_verify) on all configurations.11.Create bitstreams for each configuration.Partial Reconfiguration CommandsThe PR flows are currently only supported through the non-project batch/Tcl interface (no project based commands). Example scripts are provided in the Vivado Design Suite Tutorial: Partial Reconfiguration (UG947) [Ref6], along with step by step instructions for setting up the flows. See that Tutorial for more information.The following sections describe a few specialized commands and options needed for the PR flows. Examples of how to use these commands to run a PR flow are given. For more information on individual commands, see the Vivado Design Suite Tcl Command Reference Guide (UG835) [Ref7].SynthesisSynthesizing a partially reconfigurable design does not require any special commands, but does require bottom-up synthesis. There are currently no unsupported commands for synthesis, optimization, or implementation.These synthesis tools are supported:•XST•Synplify•Vivado Synthesismodules.This document only covers the Vivado Synthesis flow. For information on the other flows, refer to the XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices (UG687) [Ref8], or the Synopsys Synplify documentation.Synthesizing the Top LevelYou must have a top-level netlist with a black box for each Reconfigurable Module (RM). This requires the top-level synthesis to have module/entity declarations for the partitioned instances, but no logic – the module is empty.The top-level synthesis will infer or instantiate I/O buffers on all top level ports; I/O logic inside of a Reconfigurable Module is not supported. For more information on controlling buffer insertion, refer to the Vivado Design Suite User Guide: Synthesis (UG901) [Ref9].synth_design -flatten_hierarchy rebuilt -top <top_module_name> -part <part>Synthesizing Reconfigurable ModulesBecause each Reconfigurable Module must be instantiated in the same black box in the static design, the different versions must have identical interfaces. The name of the block must be the same in each instance, and all the properties of the interfaces (names, widths, direction) must also be identical. Each configuration of the design will be assembled like a flat design.To synthesize a Reconfigurable Module, all buffer insertion must be turned off. This can be done in Vivado Synthesis using the synth_design command in conjunction with the -mode out_of_context switch:synth_design -mode out_of_context -flatten_hierarchy rebuilt -top<reconfig_module_name> -part <part>The synth_design command synthesizes the design and stores the results in memory. In order to write the results out to a file, use:write_checkpoint <file_name>.dcpIt is recommended to close the design in memory after synthesis, and run implementation separately from synthesis.Reading Design ModulesIf there is currently no design in memory, then a design must be loaded. This can be done in a variety of ways, for either the static design or for Reconfigurable Modules. After configurations have been implemented, checkpoints will be exclusively used to read in placed and routed module databases.Table 2-1:synth_design OptionsCommand Option Description-mode out_of_context Prevents I/O insertion for synthesis and downstream tools. The out_of_context mode will be saved in the checkpoint if write_checkpoint is issued.-flatten_hierarchy rebuilt There are several values allowed for -flatten_hierarchy , but rebuilt is the recommended setting for PR flows.-top This is the module/entity name of the module being synthesized.-partThis is the Xilinx ® part being targeted (for example,xc7k325tffg900-3)Method 1: Read Netlist DesignThis approach should be used when modules have been synthesized by tools other than Vivado Synthesis.read_edif <top>.edf/edn/ngcread_edif <rp1_a>.edf/edn/ngcread_edif <rp2_a>.edf/edn/ngclink_design -top <top_module_name> -part <part>Method 2: Open/Read CheckpointIf the static (top-level) design has synthesis or implementation results stored as a checkpoint, then it can be loaded using the open_checkpoint command. This command reads in the static design checkpoint and opens it in active memory.open_checkpoint <file>If the checkpoint is for a reconfigurable module (i.e., not for static), then the instance name must be specified using read_checkpoint -cell . If the checkpoint is a post-implementation checkpoint, then the additional -strict option must be used as well. This option can also be used with a post-synthesis checkpoint to ensure exact port matching has been achieved. To read in a Reconfigurable Module's checkpoint, the top-level design must already be opened, and must have a black box for the specified cell. Then the following command can be specified:read_checkpoint -cell <cellname > <file> [-strict]Table 2-2:link_design Options Command Option Description -partThis is the Xilinx part being targeted (for example, xc7k325tffg900-3)-top This is the module/entity name of the module being implemented. This switch can be omitted if set_propertytop <top_module_name> [current_fileset] is issued prior to link_design .Table 2-3:read_checkpoint Switches Switch Name Description -cellUsed to specify the full hierarchical name of the Reconfigurable Module.-strict Requires exact ports match for replacing cell, and checks that part, package, and speed grade values are identical. Should be used when restoring implementation data.<file>Specifies the full or relative path to the checkpoint (DCP) to be read in.。
JMatPro的数据导出
JMatPro的数据导出JMatPro是一款用于材料性能预测和材料设计的软件工具。
它能够模拟各种材料的热力学和力学行为，并提供相应的材料数据。
在使用JMatPro时，用户可能需要将模拟结果导出为数据文件，以便进行进一步的分析和处理。
本文将介绍如何使用JMatPro导出数据，并提供详细的步骤和示例。
1. 打开JMatPro软件并加载所需的材料模型。
在JMatPro的界面中，点击"File"菜单，然后选择"Open"选项。
在弹出的对话框中，选择相应的材料模型文件并加载。
2. 设置导出参数。
在JMatPro的界面中，点击"File"菜单，然后选择"Export"选项。
在弹出的对话框中，可以设置导出的参数，包括导出的数据类型、导出的时间范围、导出的文件格式等。
根据实际需求进行设置。
3. 选择导出的数据类型。
在导出参数设置对话框中，可以选择要导出的数据类型。
JMatPro提供了多种数据类型的导出选项，包括热力学数据、力学数据、热膨胀数据等。
根据实际需求选择相应的数据类型。
4. 设置导出的时间范围。
在导出参数设置对话框中，可以设置导出的时间范围。
用户可以选择导出全部时间范围的数据，或者只导出特定时间范围内的数据。
根据实际需求进行设置。
5. 选择导出的文件格式。
在导出参数设置对话框中，可以选择导出的文件格式。
JMatPro支持多种文件格式的导出，包括CSV、Excel、MATLAB等。
根据实际需求选择相应的文件格式。
6. 确定导出的文件路径和文件名。
在导出参数设置对话框中，可以设置导出的文件路径和文件名。
用户可以选择将导出的文件保存在指定的文件夹中，并为导出的文件命名。
根据实际需求进行设置。
7. 导出数据。
在导出参数设置对话框中，点击"OK"按钮开始导出数据。
JMatPro将根据设置的参数将模拟结果导出为指定的文件。
android native mprotect参数
mlock和munlock是Unix系统中的函数，用于防止内存页被换出。
这两个函数通常在Java中通过JNI被Android使用，用于管理native内存。
mlock和munlock的参数通常是一个指向要锁住或解锁的内存区域的指针，以及该区域的大小（以字节为单位）。
例如，在C或C++中，你可能会看到这样的代码：char* ptr = ...; // get your pointer heresize_t size = ...; // get your size hereif (mlock(ptr, size) == -1) {// handle error}munlock`的使用类似：char* ptr = ...; // get your pointer heresize_t size = ...; // get your size hereif (munlock(ptr, size) == -1) {// handle error}在Android的JNI接口中，你可能需要使用native关键字声明这些函数，以便Java代码可以调用它们。
例如：extern "C" JNIEXPORT jboolean JNICALLJava_com_example_myapplication_MainActivity_nativeMlock(JNIEnv *env, jobject thiz, jbyteArray ptrArray) {// Convert the byte array to a char pointer.jsize len = env->GetArrayLength(ptrArray);char* ptr = env->GetByteArrayElements(ptrArray, nullptr);// Lock the memory.if (mlock(ptr, len) == -1) {// Handle error.return JNI_FALSE;}// Release the memory when it's no longer needed. This is important!env->ReleaseByteArrayElements(ptrArray, ptr, 0);return JNI_TRUE;}注意，你需要确保在不再需要内存时调用munlock函数释放内存，否则可能会导致内存泄漏。
dmsetup clear用法
dmsetup clear是Linux系统中的一个命令，用于清除设备映射器中的映射信息。
在Linux系统中，设备映射器（Device Mapper）是一种内核级别的设备映射技术，它允许用户在存储设备之间创建复杂的映射关系，包括设备镜像、快照、加密等。
使用dmsetup clear命令可以清除这些映射关系，释放资源，使得用户可以重新配置新的映射关系或者释放设备。
在实际应用中，dmsetup clear命令通常用于以下场景：1. 清除设备快照当用户使用LVM（Logical Volume Manager）创建快照时，系统会自动创建一个设备映射关系来实现快照功能。
当用户不再需要这个快照时，可以使用dmsetup clear命令来清除这个映射关系，释放资源。
2. 清除设备镜像在一些特定的场景下，用户可能会使用设备映射器创建设备镜像，用于数据的备份或者迁移。
当用户不再需要这个镜像时，可以使用dmsetup clear命令来清除这个映射关系，释放资源。
3. 清除加密设备设备映射器还可以用于创建加密设备，将对数据进行加密保护。
当用户需要解密设备时，可以使用dmsetup clear命令来清除加密映射关系。
下面是dmsetup clear命令的基本用法:```shelldmsetup clear <device_name>```其中，<device_name>表示要清除的设备映射器名称。
在使用dmsetup clear命令时，需要注意以下几点：1. 要谨慎使用dmsetup clear命令，因为清除设备映射关系后，相关的数据将会丢失。
2. 在执行dmsetup clear命令前，建议先备份相关数据，以避免数据丢失造成的损失。
3. 在执行dmsetup clear命令后，建议检查相关设备的状态，确保清除操作执行成功，并且释放了相关的资源。
dmsetup clear命令是Linux系统中一个重要的管理工具，能够清除设备映射器中的映射关系，释放资源，确保系统的稳定和安全运行。
conan常用命令
conan常用命令摘要：1.引言2.conan简介3.conan常用命令a.conan createb.conan searchc.conan downloadd.conan uploade.conan installf.conan removeg.conan infoh.conan configi.conan profilej.conan help4.conan命令的高级用法a.conan命令选项b.conan命令参数5.conan命令行示例6.总结正文：Conan是一个用于管理C/C++依赖关系的开源工具，通过命令行的方式进行操作。
Conan可以轻松地创建、分享和复用库，使开发者能够更加专注于编写代码。
在本篇文章中，我们将介绍Conan的常用命令。
1.引言Conan是一个开源的C/C++依赖管理工具，通过命令行的方式进行操作。
Conan提供了许多实用的命令来帮助开发者管理依赖关系。
2.conan简介Conan是一个跨平台的C/C++依赖管理工具，支持多种构建系统，如CMake、NMake、Visual Studio等。
Conan通过命令行的方式进行操作，提供了许多实用的命令来帮助开发者管理依赖关系。
3.conan常用命令以下是Conan的常用命令：a.conan create：创建一个新的库或项目。
b.conan search：搜索可用的库或插件。
c.conan download：下载库或插件。
d.conan upload：上传库或插件。
e.conan install：安装库或插件。
f.conan remove：卸载库或插件。
g.conan info：查看库或插件的信息。
h.conan config：配置Conan的设置。
i.conan profile：管理用户配置文件。
j.conan help：查看Conan的帮助信息。
4.conan命令的高级用法a.conan命令选项：Conan命令通常可以通过选项进行配置，例如：`conan create -p <package_name>`。
qt multimedia 使用方法 -回复
qt multimedia 使用方法-回复Qt Multimedia 是Qt 框架中的一个模块，它提供了一套跨平台的多媒体功能，包括音频、视频、相机和摄像头等。
Qt Multimedia 的使用方法相对简单，本文将以一个简单的案例来介绍Qt Multimedia 的基本用法，并逐步讲解。
首先，我们需要创建一个新的Qt 项目。
打开Qt Creator，选择新建项目-> 应用程序-> Qt Widgets 应用程序，填写项目名称和存储位置后，点击下一步。
选择模板时，在左侧的列表中，找到Qt Multimedia 模块，在右侧的下拉框中选择基于Qt Widgets 应用程序的模板，点击下一步。
然后，根据需要进行项目设置，最后点击完成。
一旦项目创建完成，我们就可以开始使用Qt Multimedia 模块了。
首先，我们需要在项目文件（.pro）中添加对Qt Multimedia 模块的引用。
打开项目文件，找到`QT += core gui` 的行，在其后面添加`multimedia`，保存文件并重新构建项目。
接下来，我们将在主窗口类的头文件中添加一个`QMediaPlayer` 对象和相关的函数。
打开主窗口的头文件（通常是`mainwindow.h`），添加以下内容：cppinclude <QMediaPlayer>class MainWindow : public QMainWindow{Q_OBJECTpublic:MainWindow(QWidget *parent = nullptr);~MainWindow();private slots:void play();void pause();void stop();private:QMediaPlayer *player;};在上面的代码中，我们添加了一个`QMediaPlayer` 对象以及三个私有的槽函数`play()`、`pause()` 和`stop()`。
frp toml的格式 -回复
frp toml的格式-回复FrappéTOML 格式TOML 是一种易于阅读和编写的配置文件格式，它通过使用简单的键值对的形式来存储结构化的数据。
而FrappéTOML 则是基于TOML 格式的一种特定实现，主要用于Frappé框架的配置文件。
在本文中，我将逐步解释FrappéTOML 的格式及其用法，帮助您更好地理解和应用它。
第一步：了解TOML 格式TOML（Tom's Obvious, Minimal Language）是一种民间发明的配置文件格式，其设计目标是易读易写。
它的基本元素包括键值对（Key-Value Pairs）、表（Tables）和数组（Arrays）。
键值对是由键和值组成的一对数据，表则是由方括号包围的一组键值对，数组则是由方括号包围的一组值。
TOML 还支持注释，注释在# 符号后面，可以提供额外的解释和文档。
第二步：FrappéTOML 的基本结构FrappéTOML 的基本结构和TOML 类似，它也使用键值对、表和数组。
在FrappéTOML 中，键值对用来设置框架的基本配置选项，其中的值可以是字符串、整数、浮点数、布尔值等等。
表用来组织配置信息，可以嵌套使用形成层次结构。
而数组则用来存储一组相同类型的值。
第三步：示例FrappéTOML 配置文件下面是一个示例的FrappéTOML 配置文件，以帮助您更好地理解其使用方式：[base_url]localhost = "[database]host = "localhost"port = 3306username = "root"password = "password"[logging]level = "INFO"file = "frappe.log"在这个示例中，我们可以看到"base_url"、"database" 和"logging" 是表名，它们用来组织配置信息。
使用MTKtool升级长虹液晶电视LM34i机芯的Uboot的操作方法
使用MTKtool升级长虹液晶电视LM34i机芯的Uboot的操作方法使用MTKtool升级LM34i机芯的Uboot的操作方法1.安装MTKtool目前可以使用的MTKTool2.48.07_Release1.rar，解压到本地硬盘上。
2.配置MTKtool，运行MtkTool.exe，查看version选择器件MT5395选择目前使用的UART端口COM？选择波特率115200在上面菜单window项下勾选Partial Erase和Auto Set Flash BaudRate在右面勾选Verify和ShakeHand。
3.使用MTKtool烧写uboot步骤准备工作：（1）使用其他串口工具如超级终端、TTERMPRO（ttermpro.exe），配置好端口和波特率后运行。
在电视机上电前一直按住ESC键，上电后自动进入DTV>模式；在DTV>键入b.stop后显示如下：DTV>b.stopRS232 leave transparent mode! Console stop!关闭串口工具（2）或者升级失败后，串口没有输出的情况，就不需要上面（1）的步骤（3）MTKtool的connect status变为绿色烧写工作：（1）点解mtktool界面上的Browser，打开uboot文件如mt5365p3v3_china_atv_linux_nandboot.bin，如图（2）点击upgrade，flash type选择NAND点击ok（3）运行状态，进度条变换，有打印信息，直到100%。
（4）升级uboot ok.关闭MTKtool。
并打开其他串口工具，监视输出信息（5）插入有upgrade_loader.pkg的U盘，重新升级，可以升级到新版本的软件上。
slowboot工具使用操作说明
slowboot工具使用操作说明
fastboot调试：
找到在windows下的sdk配置包，打开windows下的cmd命令终端，进入sdk配置包所在分区，我的sdk是放在D盘，执行命令:d:可以进入d盘，通过dir可以查看所有的文档，通过cd命令:cd sdk/platform-tools/
在这个路径下执行命令： fastboot.exe devices 便可以进入fastboot调试；顺便也记录一下adb调试的配置，adb调试需要在windows下配置相关的环境变量：打开系统设置->选择高级->环境变量创建环境变量，环境变量为sdk所在的路径，在系统变量path的前面添加
sdk/platfrom-tools/的路径进入cmd,在命令行下输入adb devices看是否链接成功，然后执行adb shell 进入adb 调试fastboot相关命令：
在串口终端执行reboot bootloader模式
写入命令：fastboot flash <emmc_partition> <emmc_parititon image frombuild> fastboot flash<分区> <分区的对应镜像> 。
擦除命令为image提供空间：fastboot erase 分区名。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
参数设置界面
Infinitely Closer to Real 无限接近真实！
计算结果
Infinitely Closer to Real 无限接近真实！
参数设置界面
设置合金 成分
温度设置
是否考虑所有 出现的稳态相
Infinitely Closer to Real 无限接近真实！
计算结果
合金成分固定
勾 选 择 需 要 显 示 的 相 查看某一合金元素 在各相中随温度的 查看某一温度下的相组成图 查看某一相中合金 变化 元素随温度的变化 还给出了热力学函数变化曲线
Infinitely Closer to Real 无限接近真实！
一.热力学计算—2.Step Concentration
Step Concentration：计算固定温度时的合金成分变化—相组成图
Infinitely Closer to Real 无限接近真实！
参数设置界面
固定温度
选择一种合金 元素平衡元素
一.热力学计算—相图绘制
热力学计算
① Step Temperature：温度—相组成图 ② Step Concentration & Profile：合金成分—相组成图
③ Single：固定温度和合金成分的相组成图
Infinitely Closer to Real 无限接近真实！
热力学计算的理论基础（CALPHAD 技术）
纯组元的吉 布斯自由能 之和
理想混合熵引 起的自由能增 加
偏离理想溶液引 起的超额自由能
Infinitely Closer to Real 无限接近真实！
一.热力学计算—1.Step temperature
Step Temperature：计算固定合金成分时的温度—相组成图
Infinitely Closer to Real 无限接近真实！
根据热力学原理，体系在恒温恒压达到平衡的一般条件： （1）体系的总吉布斯自由能G达到最小值Gmin （2）组元i在各相中的化学势相等
每一相的摩尔 吉布斯自由能：
Gm
X i Gi0 RT X i ln X i X i X j v ( X i X j ) v
i i i j v
⑦ 珠光体P：铁素体和渗碳体按层片状交替排列的层状组织
Infinitely Closer to Real 无限接近真实！
铸铁的分类
类 别 灰口铸铁 球墨铸铁 蠕墨铸铁 可锻铸铁 组织特征 基体+片状石墨 基体+球状石墨 断口特征 灰口 银白色 成分特征 C，Si，Mn，P，S或加少量合金元素 同上，Mg残≥0.03%，RE残≥0.02% 同上，但Mg残，RE残量可稍低 低碳，低硅，铬<0.06%
JMatPro铸铁模块介绍
中仿科技 施翀 （Joy） 2011年12月
Infinitely Closer to Real 无限接近真实！
目
铸铁背景知识介绍 铸铁模块功能介绍、演示
热力学计算 凝固计算 机械性能计算 相转变计算
录
Infinitely Closer to Real 无限接近真实！
基体+蠕虫状石墨 斑点状 生坯：珠光体+莱 氏体 退火后：基体+团 絮状石墨 生坯：白 口 退火后： 灰口
抗磨铸铁
耐热铸铁
基体+渗碳体
白口
除五元素外，可加入低，中，高合 金元素
有Si，Al，Cr系
基体+片状或球状 灰口 石墨
耐腐蚀铸铁 基体+片状或球状 灰口 石墨
主要合金元素Si，Ni
Infinitely Closer to Real 无限接近真实！
背景知识介绍
铸铁：含碳量超过2.11%的铁碳合金
碳钢 W（C）=0.0218%~2.11% 铸铁 W（C）>2.11% 工业纯铁 W（C）<0.0218%
铁碳相图
Infinitely Closer to Real 无限接近真实！
铁碳相图的组成相
① ������铁素体：存在于1392~15360C之间
Infinitely Closer to Real 无限接近真实！
参数设置界面
确定计算步长
指定多种合金 成分同时变化
除Fe以外，Fe 为平衡元素
Infinitely Closer力学计算—4.Signal
Singal：计算同时固定温度和合金成分时的相组成
Infinitely Closer to Real 无限接近真实！
选择平衡元素
除了成分变化以外的 合金元素全为平衡元 素
Infinitely Closer to Real 无限接近真实！
计算结果
Infinitely Closer to Real 无限接近真实！
一.热力学计算—3.Profile
多种合金成分同 Profile：计算固定温度时的合金成分变化—相组成图 时变化时
碳在铁中的间隙固溶体，体心立方结构
② ������铁素体：存在于9110C以下
③ 奥氏体������/������：碳在������铁中的间隙固溶体，面心立方结构，存在于727~14930C之间 ④ 石墨G：形态主要有片状，蠕虫状，团絮状，球状 ⑤ 渗碳体Fe3C：铁和碳的间隙化合物 ⑥ 莱氏体Ld：奥氏体和渗碳体组成的机械混合物 铁碳合金中的碳 的两种存在形式