- 21 6月, 2013 3 次提交
-
-
由 Prabhakar Kushwaha 提交于
Relax parameters to give address latching more time to setup. Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
When a b4860qds board boots from SRIO or PCIE, it needs to finish these processes: 1. Set all the cores in holdoff status. 2. Set the boot location to one PCIE or SRIO interface by RCW. 3. Set a specific TLB entry for the boot process. 4. Set a LAW entry with the TargetID of one PCIE or SRIO for the boot. 5. Set a specific TLB entry in order to fetch ucode and ENV from master. 6. Set a LAW entry with the TargetID one of the PCIE ports for ucode and ENV. 7. Slave's u-boot image should be generated specifically by make xxxx_SRIO_PCIE_BOOT_config. This will set SYS_TEXT_BASE=0xFFF80000 and other configurations. For more information about the feature of Boot from SRIO/PCIE, please refer to the document doc/README.srio-pcie-boot-corenet. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
B4860QDS can support the feature of Boot from SRIO/PCIE, and the macro "CONFIG_SRIO_PCIE_BOOT_MASTER" will enable the master module of this feature when building the u-boot image. You can get some description about this macro in README file, and for more information about the feature of Boot from SRIO/PCIE, please refer to the document doc/README.srio-pcie-boot-corenet. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 08 6月, 2013 1 次提交
-
-
由 Gabor Juhos 提交于
The pci_indirect.c file is always compiled when CONFIG_PCI is defined although the indirect PCI bridge support is not needed by every board. Introduce a new CONFIG_PCI_INDIRECT_BRIDGE config option and only compile indirect PCI bridge support if this options is enabled. Also add the new option into the configuration files of the boards which needs that. Compile tested for powerpc, x86, arm and nds32. MAKEALL results: powerpc: --------------------- SUMMARY ---------------------------- Boards compiled: 641 Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB ) ---------------------------------------------------------- Note: the warnings for ELPPC and MPC8323ERDB are present even without the actual patch. x86: --------------------- SUMMARY ---------------------------- Boards compiled: 1 ---------------------------------------------------------- arm: --------------------- SUMMARY ---------------------------- Boards compiled: 311 ---------------------------------------------------------- nds32: --------------------- SUMMARY ---------------------------- Boards compiled: 3 ---------------------------------------------------------- Cc: Tom Rini <trini@ti.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
-
- 25 5月, 2013 3 次提交
-
-
由 Shaveta Leekha 提交于
Signed-off-by: NShaveta Leekha <shaveta@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Poonam Aggrwal 提交于
B4420 is a subset of B4860. Merge them in config_mpc85xx.h to simplify the defines. - Removed #define CONFIG_SYS_FSL_NUM_CLUSTERS as this is used nowhere. - defined CONFIG_SYS_NUM_FM1_10GEC to 0 for B4420 as it does not have 10G. Also move CONFIG_E6500 out of B4860QDSds.h into config_mpc85xx.h. Signed-off-by: NPoonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Suresh Gupta 提交于
- Added SERDES2 PRTCLs = 0x98, 0x9E - Default Phy Addresses for Teranetics PHY on XAUI card The PHY addresses of Teranetics PHY on XAUI riser card are assigned based on the slot it is in. Switches SW4[2:4] and SW6[2:4] on AMC2PEX-2S On B4860QDS, AMC2PEX card decide the PHY addresses on slot1 and slot2 - Configure MDIO for 10Gig Mac Signed-off-by: NSuresh Gupta <suresh.gupta@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 31 1月, 2013 3 次提交
-
-
由 York Sun 提交于
B4860QDS is a high-performance computing evaluation, development and test platform supporting the B4860 QorIQ Power Architecture processor. B4860QDS Overview ------------------ - DDRC1: Ten separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 4 GB of memory in two ranks of 2 GB. - DDRC2: Five separate DDR3 parts of 16-bit to support 72-bit (ECC) at 1866MT/s, ECC, 2 GB of memory. Single rank. - SerDes 1 multiplexing: Two Vitesse (transmit and receive path) cross-point 16x16 switch VSC3316 - SerDes 2 multiplexing: Two Vitesse (transmit and receive path) cross-point 8x8 switch VSC3308 - USB 2.0 ULPI PHY USB3315 by SMSC supports USB port in host mode. - B4860 UART port is available over USB-to-UART translator USB2SER or over RS232 flat cable. - A Vitesse dual SGMII phy VSC8662 links the B4860 SGMII lines to 2xRJ-45 copper connectors for Stand-alone mode and to the 1000Base-X over AMC MicroTCA connector ports 0 and 2 for AMC mode. - The B4860 configuration may be loaded from nine bits coded reset configuration reset source. The RCW source is set by appropriate DIP-switches: - 16-bit NOR Flash / PROMJet - QIXIS 8-bit NOR Flash Emulator - 8-bit NAND Flash - 24-bit SPI Flash - Long address I2C EEPROM - Available debug interfaces are: - On-board eCWTAP controller with ETH and USB I/F - JTAG/COP 16-pin header for any external TAP controller - External JTAG source over AMC to support B2B configuration - 70-pin Aurora debug connector - QIXIS (FPGA) logic: - 2 KB internal memory space including - IDT840NT4 clock synthesizer provides B4860 essential clocks : SYSCLK, DDRCLK1, 2 and RTCCLK. - Two 8T49N222A SerDes ref clock devices support two SerDes port clocks - total four refclk, including CPRI clock scheme Signed-off-by: NYork Sun <yorksun@freescale.com> Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: NShaveta Leekha <shaveta@freescale.com> Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com> Signed-off-by: NPoonam Aggrwal <poonam.aggrwal@freescale.com> Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com> Signed-off-by: NSandeep Singh <Sandeep@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 York Sun 提交于
Relax parameters to give address latching more time to setup. Tighten parameters to make it overall faster. Signed-off-by: NYork Sun <yorksun@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Prabhakar Kushwaha 提交于
T4240QDS's QIXIS FPGA has 4k register space size and IFC controller's Address Mask Registers is initialised 64K size. So Fix the Address Mask Register initilisation as 4K Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 23 10月, 2012 2 次提交
-
-
由 York Sun 提交于
The T4240QDS is a high-performance computing evaluation, development and test platform supporting the T4240 QorIQ Power Architecture™ processor. SERDES Connections 32 lanes grouped into four 8-lane banks Two “front side” banks dedicated to Ethernet Two “back side” banks dedicated to other protocols DDR Controllers Three independant 64-bit DDR3 controllers Supports rates up to 2133 MHz data-rate Supports two DDR3/DDR3LP UDIMM/RDIMMs per controller QIXIS System Logic FPGA Each DDR controller has two DIMM slots. The first slot of each controller has up to 4 chip selects to support single-, dual- and quad-rank DIMMs. The second slot has only 2 chip selects to support single- and dual-rank DIMMs. At any given time, up to total 4 chip selects can be used. Detail information can be found in doc/README.t4qds Signed-off-by: NYork Sun <yorksun@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org> Signed-off-by: NPrabhakar Kushwaha <prabhakar@freescale.com> Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: NRoy Zang <tie-fei.zang@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Timur Tabi 提交于
The P5040 does not have SRIO, so don't put the SRIO definitions in corenet_ds.h. They belong in the board-specific header files. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 16 10月, 2012 1 次提交
-
-
由 Marek Vasut 提交于
Kill multiple occurances and redeclaration of MK_STR in favor of __stringify(). Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Signed-off-by: NTom Rini <trini@ti.com>
-
- 24 8月, 2012 1 次提交
-
-
由 Timur Tabi 提交于
The P3060 was cancelled before it went into production, so there's no point in supporting it. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 23 8月, 2012 5 次提交
-
-
由 Shaohui Xie 提交于
Provides a tool to build boot Image for PBL(Pre boot loader) which is used on Freescale CoreNet SoCs, PBL can be used to load some instructions and/or data for pre-initialization. The default output image is u-boot.pbl, for more details please refer to doc/README.pblimage. Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
When boot from PCIE, slave's core should be in holdoff after powered on for some specific requirements. Master will release the slave's core at the right time by PCIE interface. Slave's ucode and ENV can be stored in master's memory space, then slave can fetch them through PCIE interface. For the corenet platform, ucode is for Fman. NOTE: Because the slave can not erase, write master's NOR flash by PCIE interface, so it can not modify the ENV parameters stored in master's NOR flash using "saveenv" or other commands. environment and requirement: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image is in master NOR flash. 3. Put the slave's ucode and ENV into it's own memory space. 4. Normally boot from local NOR flash. 5. Configure PCIE system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to one PCIE interface by RCW. 3. RCW should configure the SerDes, PCIE interfaces correctly. 4. Must set all the cores in holdoff by RCW. 5. Must be powered on before master's boot. For the slave module, need to finish these processes: 1. Set the boot location to one PCIE interface by RCW. 2. Set a specific TLB entry for the boot process. 3. Set a LAW entry with the TargetID of one PCIE for the boot. 4. Set a specific TLB entry in order to fetch ucode and ENV from master. 5. Set a LAW entry with the TargetID one of the PCIE ports for ucode and ENV. 6. Slave's u-boot image should be generated specifically by make xxxx_SRIO_PCIE_BOOT_config. This will set SYS_TEXT_BASE=0xFFF80000 and other configurations. In addition, the processes are very similar between boot from SRIO and boot from PCIE. Some configurations like the address spaces can be set to the same. So the module of boot from PCIE was added based on the existing module of boot from SRIO, and the following changes were needed: 1. Updated the README.srio-boot-corenet to add descriptions about boot from PCIE, and change the name to README.srio-pcie-boot-corenet. 2. Changed the compile config "xxxx_SRIOBOOT_SLAVE" to "xxxx_SRIO_PCIE_BOOT", and the image builded with "xxxx_SRIO_PCIE_BOOT" can support both the boot from SRIO and from PCIE. 3. Updated other macros and documents if needed to add information about boot from PCIE. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
For the powerpc processors with PCIE interface, boot location can be configured from one PCIE interface by RCW. The processor booting from PCIE can do without flash for u-boot image. The image can be fetched from another processor's memory space by PCIE link connected between them. The processor booting from PCIE is slave, the processor booting from normal flash memory space is master, and it can help slave to boot from master's memory space. When boot from PCIE, slave's core should be in holdoff after powered on for some specific requirements. Master will release the slave's core at the right time by PCIE interface. Environment and requirement: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image is in master NOR flash. 3. Normally boot from local NOR flash. 4. Configure PCIE system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to one PCIE interface by RCW. 3. RCW should configure the SerDes, PCIE interfaces correctly. 4. Must set all the cores in holdoff by RCW. 5. Must be powered on before master's boot. For the master module, need to finish these processes: 1. Initialize the PCIE port and address space. 2. Set inbound PCIE windows covered slave's u-boot image stored in master's NOR flash. 3. Set outbound windows in order to configure slave's registers for the core's releasing. 4. Should set the environment variable "bootmaster" to "PCIE1", "PCIE2" or "PCIE3" using the following command: setenv bootmaster PCIE1 saveenv Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
When compile the slave image for boot from SRIO, no longer need to specify which SRIO port it will boot from. The code will get this information from RCW and then finishes corresponding configurations. This has the following advantages: 1. No longer need to rebuild an image when change the SRIO port for boot from SRIO, just rewrite the new RCW with selected port, then the code will get the port information by reading new RCW. 2. It will be easier to support other boot location options, for example, boot from PCIE. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Liu Gang 提交于
Get rid of the SRIOBOOT_MASTER build target, and to support for serving as a SRIO boot master via environment variable. Set the environment variable "bootmaster" to "SRIO1" or "SRIO2" using the following command: setenv bootmaster SRIO1 saveenv The "bootmaster" will enable the function of the SRIO boot master, and this has the following advantages compared with SRIOBOOT_MASTER build configuration: 1. Reduce a build configuration item in boards.cfg file. No longer need to build a special image for master, just use a normal target image and set the "bootmaster" variable. 2. No longer need to rebuild an image when change the SRIO port for boot from SRIO, just set the corresponding value to "bootmaster" based on the using SRIO port. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 09 8月, 2012 2 次提交
-
-
由 Timur Tabi 提交于
The BR_PHYS_ADDR(x) macro was missing parentheses around "x" in the macro definition, so callers had to supply their own parenthesis. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Shaohui Xie 提交于
ENV location compile logic is wrong, and when CONFIG_SYS_NO_FLASH is defined and non-NOR u-boot is building, it will cause compile error. Also, add CONFIG_SYS_FLASH_USE_BUFFER_WRITE for p2041, which will improve NOR flash write performance. Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 07 7月, 2012 1 次提交
-
-
由 ramneek mehresh 提交于
Add USB device-tree fixup for following platforms: MPC8536DS, P1022DS, P1023RDS, P2020COME, P2020DS, P2041RDB, P3060QDS Signed-off-by: NRamneek Mehresh <ramneek.mehresh@freescale.com>
-
- 21 6月, 2012 1 次提交
-
-
由 Tom Rini 提交于
Exactly one board has defined CONFIG_SYS_PROMPT_HUSH_PS2 to a value different than "> " which is vision2. I have Cc'd the maintainer here as I strongly suspect this is a bug rather than intentional behavior. Cc: Stefano Babic <sbabic@denx.de> Signed-off-by: NTom Rini <trini@ti.com> Acked-by: NStefano Babic <sbabic@denx.de>
-
- 25 4月, 2012 6 次提交
-
-
由 Liu Gang 提交于
When boot from SRIO, slave's core can be in holdoff after powered on for some specific requirements. Master can release the slave's core at the right time by SRIO interface. Master needs to: 1. Set outbound SRIO windows in order to configure slave's registers for the core's releasing. 2. Check the SRIO port status when release slave core, if no errors, will implement the process of the slave core's releasing. Slave needs to: 1. Set all the cores in holdoff by RCW. 2. Be powered on before master's boot. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
-
由 Liu Gang 提交于
When boot from SRIO, slave's ENV can be stored in master's memory space, then slave can fetch the ENV through SRIO interface. NOTE: Because the slave can not erase, write master's NOR flash by SRIO interface, so it can not modify the ENV parameters stored in master's NOR flash using "saveenv" or other commands. Master needs to: 1. Put the slave's ENV into it's own memory space. 2. Set an inbound SRIO window covered slave's ENV stored in master's memory space. Slave needs to: 1. Set a specific TLB entry in order to fetch ucode and ENV from master. 2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
-
由 Liu Gang 提交于
When boot from SRIO, slave's ucode can be stored in master's memory space, then slave can fetch the ucode image through SRIO interface. For the corenet platform, ucode is for Fman. Master needs to: 1. Put the slave's ucode image into it's own memory space. 2. Set an inbound SRIO window covered slave's ucode stored in master's memory space. Slave needs to: 1. Set a specific TLB entry in order to fetch ucode from master. 2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
-
由 Liu Gang 提交于
For the powerpc processors with SRIO interface, boot location can be configured from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash for u-boot image. The image can be fetched from another processor's memory space by SRIO link connected between them. The processor boots from SRIO is slave, the processor boots from normal flash memory space and can help slave to boot from its memory space is master. They are different environments and requirements: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image in master NOR flash. 3. Normally boot from local NOR flash. 4. Configure SRIO switch system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to SRIO1 or SRIO2 by RCW. 3. RCW should configure the SerDes, SRIO interfaces correctly. 4. Slave must be powered on after master's boot. 5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode locally. For the slave module, need to finish these processes: 1. Set the boot location to SRIO1 or SRIO2 by RCW. 2. Set a specific TLB entry for the boot process. 3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot. 4. Slave's u-boot image should be generated specifically by make xxxx_SRIOBOOT_SLAVE_config. This will set SYS_TEXT_BASE=0xFFF80000 and other configurations. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
-
由 Liu Gang 提交于
For the powerpc processors with SRIO interface, boot location can be configured from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash for u-boot image. The image can be fetched from another processor's memory space by SRIO link connected between them. The processor boots from SRIO is slave, the processor boots from normal flash memory space and can help slave to boot from its memory space is master. They are different environments and requirements: master: 1. NOR flash for its own u-boot image, ucode and ENV space. 2. Slave's u-boot image in master NOR flash. 3. Normally boot from local NOR flash. 4. Configure SRIO switch system if needed. slave: 1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV. 2. Boot location should be set to SRIO1 or SRIO2 by RCW. 3. RCW should configure the SerDes, SRIO interfaces correctly. 4. Slave must be powered on after master's boot. For the master module, need to finish these processes: 1. Initialize the SRIO port and address space. 2. Set inbound SRIO windows covered slave's u-boot image stored in master's NOR flash. 3. Master's u-boot image should be generated specifically by make xxxx_SRIOBOOT_MASTER_config 4. Master must boot first, and then slave can be powered on. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com> Signed-off-by: NShaohui Xie <Shaohui.Xie@freescale.com>
-
由 Liu Gang 提交于
When defined CONFIG_ENV_IS_NOWHERE, there will be some compilation errors: ./common/env_nowhere.o: In function `env_relocate_spec': ./common/env_nowhere.c:38: multiple definition of `env_relocate_spec' ./common/env_flash.o: ./common/env_flash.c:326: first defined here ./common/env_nowhere.o: In function `env_get_char_spec': ./common/env_nowhere.c:42: multiple definition of `env_get_char_spec' ./common/env_flash.o:./common/env_flash.c:78: first defined here ./common/env_nowhere.o: In function `env_init': ./common/env_nowhere.c:51: multiple definition of `env_init' ./common/env_flash.o:./common/env_flash.c:237: first defined here make[1]: *** [./common/libcommon.o] Error 1 make[1]: Leaving directory `./common' make: *** [./common/libcommon.o] Error 2 Remove the CONFIG_ENV_IS_IN_FLASH if defined CONFIG_ENV_IS_NOWHERE. Signed-off-by: NLiu Gang <Gang.Liu@freescale.com>
-
- 12 2月, 2012 1 次提交
-
-
由 Fabio Estevam 提交于
Since commit 97039ab9 (env_mmc: Allow board code to override the environment address) mmc_get_env_addr is a weak-aliased function in common/env_mmc.c The mmc_get_env_addr implementation that exists at board/freescale/common/sdhc_boot.c is meant to be used only for PowerPC boards, but currently it is being used for all platforms that have CONFIG_ENV_IS_IN_MMC defined. Introduce CONFIG_FSL_FIXED_MMC_LOCATION so that the boards that need to use the mmc_get_env_addr version from board/freescale/common/sdhc_boot.c could activate this config option on their board file. This fixes the retrieval of CONFIG_ENV_OFFSET on non-PowerPC boards. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Acked-by: NKumar Gala <galak@kernel.crashing.org> Acked-by: NStefano Babic <sbabic@denx.de>
-
- 29 11月, 2011 2 次提交
-
-
由 Shengzhou Liu 提交于
The P3060QDS is a Freescale reference board for the six-core P3060 SOC. P3060QDS Board Overview: Memory subsystem: - 2G Bytes unbuffered DDR3 SDRAM SO-DIMM(64bit bus) - 128M Bytes NOR flash single-chip memory - 16M Bytes SPI flash - 8K Bytes AT24C64 I2C EEPROM for RCW Ethernet: - Eight Ethernet controllers (4x1G + 4x1G/2.5G) - Three VSC8641 PHYs on board (2xRGMII + 1xMII) - Suport multiple Vitesse VSC8234 SGMII Cards in Slot1/2/3 PCIe: Two PCI Express 2.0 controllers/ports USB: Two USB2.0, USB1(TYPE-A) and USB2(TYPE-AB) on board I2C: Four I2C controllers UART: Supports two dUARTs up to 115200 bps for console RapidIO: Two RapidIO, sRIO1 and sRIO2 Signed-off-by: NShengzhou Liu <Shengzhou.Liu@freescale.com> Signed-off-by: NYork Sun <yorksun@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Timur Tabi 提交于
Several macros are used to identify and locate the microcode binary image that U-boot needs to upload to the QE or Fman. Both the QE and the Fman use the QE Firmware binary format to package their respective microcode data, which is why the same macros are used for both. A given SOC will only have a QE or an Fman, so this is safe. Unfortunately, the current macro definition and usage has inconsistencies. For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address of NAND. There's no way to know by looking at a variable how it's supposed to be used. In the future, the code which uploads QE firmware and Fman firmware will be merged. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 22 10月, 2011 2 次提交
-
-
由 Joe Hershberger 提交于
Remove MK_STR from places that consume CONFIG_BOOTFILE to force all definitions to be string literals. Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com> Cc: Joe Hershberger <joe.hershberger@gmail.com> Cc: Wolfgang Denk <wd@denx.de> Acked-by: NMike Frysinger <vapier@gentoo.org>
-
由 Joe Hershberger 提交于
Remove MK_STR from places that consume CONFIG_ROOTPATH to force all definitions to be string literals. Signed-off-by: NJoe Hershberger <joe.hershberger@ni.com> Cc: Joe Hershberger <joe.hershberger@gmail.com> Cc: Wolfgang Denk <wd@denx.de> Acked-by: NMike Frysinger <vapier@gentoo.org>
-
- 06 10月, 2011 1 次提交
-
-
由 Mike Frysinger 提交于
Now that none of the core checks CONFIG_NET_MULTI, there's not much point in boards defining it. So scrub all references to it. Signed-off-by: NMike Frysinger <vapier@gentoo.org>
-
- 03 10月, 2011 2 次提交
-
-
由 Kumar Gala 提交于
Move some SoC/board specific defines out of corenet_ds.h and into the corresponding P3041DS/P4080DS/P5020.h. We moved CONFIG_MMC, CONFIG_PCIE3, & CONFIG_FSL_NGPIXIS because the P3060 SoC/reference board does not have these devices and it will share the same board code. Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Ruchika Gupta 提交于
Pre u-boot Flow: 1. User loads the u-boot image in flash 2. PBL/Configuration word is used to create LAW for Flash at 0xc0000000 (Please note that ISBC expects all these addresses, images to be validated, entry point etc within 0 - 3.5G range) 3. ISBC validates the u-boot image, and passes control to u-boot at 0xcffffffc. Changes in u-boot: 1. Temporarily map CONFIG_SYS_MONITOR_BASE to the 1M CONFIG_SYS_PBI_FLASH_WINDOW in AS=1. (The CONFIG_SYS_PBI_FLASH_WINDOW is the address map for the flash created by PBL/configuration word within 0 - 3.5G memory range. The u-boot image at this address has been validated by ISBC code) 2. Remove TLB entries for 0 - 3.5G created by ISBC code 3. Remove the LAW entry for the CONFIG_SYS_PBI_FLASH_WINDOW created by PBL/configuration word after switch to AS = 1 Signed-off-by: NRuchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: NKuldip Giroh <kuldip.giroh@freescale.com> Acked-by: NWood Scott-B07421 <B07421@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
- 30 9月, 2011 3 次提交
-
-
由 Kumar Gala 提交于
Useful for various debug to know how various regsters might be set in a human readable form. Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Andy Fleming 提交于
Add support for RGMII, SGMII, and XAUI (10Gb) Ethernet on P4080DS. The board supports add-on cards for SGMII and XAUI functionality. Which slots on the board these cards are in is a function of the SERDES option selected and muxes on the board. Additionally because of the high-configurablity which MDIO bus one is connected to is "selected" via an FPGA register. We create dummy MDIO bus for the phy layer and hide the mux manipulation in this dummy layer. Add fman fdt helper function in board common code it'll be used by several freescale boards that do various muxing of the MDIO signals based on which controller/interface one is trying to talk to. Removed CONFIG_SYS_FMAN_FW as its not used anywhere. Signed-off-by: NMingkai Hu <Mingkai.hu@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com> Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-
由 Timur Tabi 提交于
Introduce the CONFIG_SYS_CCSRBAR_PHYS_HIGH and CONFIG_SYS_CCSRBAR_PHYS_LOW macros, which contain the high and low portions of CONFIG_SYS_CCSRBAR_PHYS. This is necessary for the assembly-language code that relocates CCSR, since the assembler does not understand 64-bit constants. CONFIG_SYS_CCSRBAR_PHYS is automatically defined from the CONFIG_SYS_CCSRBAR_PHYS_HIGH and CONFIG_SYS_CCSRBAR_PHYS_LOW macros, so it should not be defined in a board header file. Similarly, CONFIG_SYS_CCSRBAR_DEFAULT is defined for each SOC in config_mpc85xx.h, so it should also not be defined in the board header file. CONFIG_SYS_CCSR_DO_NOT_RELOCATE is a "short-cut" macro that guarantees that CONFIG_SYS_CCSRBAR_PHYS is set to the same value as CONFIG_SYS_CCSRBAR_DEFAULT, and so CCSR will not be relocated. Since CONFIG_SYS_CCSRBAR_DEFAULT is locked to a fixed value, multi-stage U-Boot builds (e.g. NAND) are required to relocate CCSR only during the last stage (i.e. the "real" U-Boot). All other stages should define CONFIG_SYS_CCSR_DO_NOT_RELOCATE to ensure that CCSR is not relocated. README is updated with descriptions of all the CONFIG_SYS_CCSRBAR_xxx macros. Signed-off-by: NTimur Tabi <timur@freescale.com> Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
-