summaryrefslogtreecommitdiff
path: root/include
Commit message (Collapse)AuthorAgeLines
* mx6: add example DTB for mx6qsabreautoStefano Babic2014-04-02-0/+3
| | | | | Signed-off-by: Stefano Babic <sbabic@denx.de> CC: Fabio Estevam <fabio.estevam@freescale.com>
* arm: mx5: Avoid hardcoding memory sizes on M53EVKMarek Vasut2014-03-31-5/+3
| | | | | | | | | | | | | | | | | | | The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on M53EVK and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Fix memory slowness on M53EVKMarek Vasut2014-03-31-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory access slowness on i.MX53 M53EVK board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On M53EVK, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on M53EVK, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Avoid hardcoding memory sizes on MX53QSBMarek Vasut2014-03-31-7/+5
| | | | | | | | | | | | | | | | | | | The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on MX53QSB and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* arm: mx5: Fix memory slowness on MX53QSBMarek Vasut2014-03-31-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
* ARM: mx6: Add PCIe on SabreSDPMarek Vasut2014-03-31-0/+10
| | | | | | | | | | Add support for PCIe on MX6 SabreSDP board and enable the support in the config file. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Liu Ying <Ying.Liu@freescale.com>
* ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6xEric Nelson2014-03-31-1/+0
| | | | | | | | | | | | Use of PCIe on SABRE Lite and Nitrogen6x boards is atypical and requires the use of custom daughter boards. Use in U-Boot is even rarer, so this patch removes it from the standard configuration. Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> Acked-by: Marek Vasut <marex@denx.de>
* woodburn_sd: Remove CONFIG_BOOT_INTERNALFabio Estevam2014-03-31-2/+0
| | | | | | | CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
* ARM: mxs: Add OCOTP driverMarek Vasut2014-03-31-0/+5
| | | | | | | | | | | | Add yet another OCOTP driver for this i.MX family. This time, it's a driver for the OCOTP variant found in the i.MX23 and i.MX28. This version of OCOTP is too different from the i.MX6 one that I could not use the mxc_ocotp.c driver without making it into a big pile of #ifdef . This driver implements the regular fuse command interface, but due to the IP blocks' limitation, we support only READ and PROG functions. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* arm: mxs: Adjust the load address of U-Boot and SPL for HABMarek Vasut2014-03-31-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | When using HAB, there are additional special requirements on the placement of U-Boot and the U-Boot SPL in memory. To fullfill these, this patch moves the U-Boot binary a little further from the begining of the DRAM, so the HAB CST and IVT can be placed in front of the U-Boot binary. This is necessary, since both the U-Boot and the IVT must be contained in single CST signature. To make things worse, the IVT must be concatenated with one more entry at it's end, that is the length of the entire CST signature, IVT and U-Boot binary in memory. By placing the blocks in this order -- CST, IVT, U-Boot, we can easily align them all and then produce the length field as needed. As for the SPL, on i.MX23/i.MX28, the SPL size is limited to 32 KiB, thus we place the IVT at 0x8000 offset, CST right past IVT and claim the size is correct. The HAB library accepts this setup. Finally, to make sure the vectoring in SPL still works even after moving the SPL from 0x0 to 0x1000, we add a small function which copies the vectoring code and tables to 0x0. This is fine, since the vectoring code is position independent. Signed-off-by: Marek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
* mx25pdk: Align the environment with other FSL boardsFabio Estevam2014-03-12-5/+98
| | | | | | | | | | | Allow the boot of a device tree mainline kernel by aligning the environment variables with other FSL boards. Tested NFS boot of a dt 3.14-rc5 kernel. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Stefano Babic <sbabic@denx.de>
* ventana: Add Gateworks Ventana family supportTim Harvey2014-03-12-0/+425
| | | | | | | | | Gateworks Ventana is a product family based on the i.MX6. This patch adds support for all boards in the Ventana family. Where possible, data from the boards EEPROM is used to determine various details about the board at runtime. Signed-off-by: Tim Harvey <tharvey@gateworks.com>
* Merge branch 'master' of git://git.denx.de/u-boot-armStefano Babic2014-03-05-1567/+2549
|\
| * arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootupStefan Roese2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Since the switch may be re-configured for VLAN usage in Linux (or any other OS), lets reset the switch to its default register values upon power-up. Otherwise network might not be available in U-Boot. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Heiko Schocher <hs@denx.de> Cc: Roger Meier <r.meier@siemens.com> Cc: Lukas Stockmann <lukas.stockmann@siemens.com> Cc: Tom Rini <trini@ti.com>
| * ARM: AM43xx: Add Ethernet boot support to SPLMugunthan V N2014-03-04-2/+8
| | | | | | | | | | | | | | Add Ethernet Boot support to SPL Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM335x: add support for reading cpsw 2nd mac address from efuseMugunthan V N2014-03-04-0/+1
| | | | | | | | | | | | | | | | | | Adding support for reading cpsw 2nd mac address from efuse and pass it to kernel via dtb which will be used in dual emac mode of cpsw. Also adding mii command support to am335x common config. Acked-by: Tom Rini <trini@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * ARM: AM43xx: Add CPSW support to AM43xx EPOS and GP EVMMugunthan V N2014-03-04-0/+20
| | | | | | | | | | | | | | | | Adding support for CPSW to AM43xx EPOS nad GP EVM which is connected to RMII and RGMII phy respectively and enable cpsw in config. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
| * drivers: net: cpsw: add support to have phy address from cpsw platform dataMugunthan V N2014-03-04-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | Some platforms like AM437x have different EVMs with different phy addresses, so this patch adds support for passing phy address via cpsw plaform data. Also renamed phy_id to phy_addr so better understanding of the code. Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> [trini: Update BuR am335x_igep0033 pcm051_rev3 pcm051_rev1 cm_t335 pengwyn boards] Signed-off-by: Tom Rini <trini@ti.com>
| * Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2014-02-26-62/+1142
| |\ | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/cpu/armv7/config.mk board/ti/am43xx/mux.c include/configs/am43xx_evm.h Signed-off-by: Tom Rini <trini@ti.com>
| | * arm: remove unneeded symbol offsets and _TEXT_BASEAlbert ARIBAUD2014-02-26-19/+7
| | | | | | | | | | | | | | | | | | | | | | | | Remove the last uses of symbol offsets in ARM U-Boot. Remove some needless uses of _TEXT_BASE. Remove all _TEXT_BASE definitions. Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| | * Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'Albert ARIBAUD2014-02-24-12/+849
| | |\
| | | * omap4_common: config: remove I2C for SPL modeNishanth Menon2014-02-21-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6789e84ecaa8f45d053084e08c381284a04abff7 (i2c, omap24xx: convert driver to new mutlibus/mutliadapter framework) intended to make I2C driver compatible with latest changes. It unfortunately has had a impact on size on SPL as well. For example on SDP4430, 32032 bytes before/MLO 35416 bytes after/MLO With this mentioned commit, MLO stops booting on SDP4430 as only 32K is accessible for non-secure (bootloader) s/w on GP devices and the size increase to 56K fails boot. On the latest u-boot commit e7be18225fbea76d1f0034b224f0d1e60f07cfcf, MLO is now at size 35592 bytes, However, I2C is not necessary for SPL to function as we use SR_I2C for controlling the PMIC. Disabling I2C reduces MLO to 32224 bytes which allows OMAP4 GP platform to boot up. Since this is common for all OMAP4 platforms, remove the need for I2C for SPL builds in the common config. Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Sricharan R <r.sricharan@ti.com>
| | | * dra7xx_evm: Enable GPT commandsTom Rini2014-02-21-0/+11
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * am43xx_evm: Enable GPT commandsTom Rini2014-02-21-0/+9
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * am335x_evm: Enable GPT commandsTom Rini2014-02-21-0/+12
| | | | | | | | | | | | | | | | Signed-off-by: Tom Rini <trini@ti.com>
| | | * arm: omap: cm_t35: Remove CONFIG_SYS_BOOTMAPSZ to fix FDT Linux bootingStefan Roese2014-02-21-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_SYS_BOOTMAPSZ defined, recent Linux kernel booting results in this error: Booting using the fdt blob at 0x81f00000 Loading Kernel Image ... OK ERROR: Failed to allocate 0x1189d bytes below 0x80004000. device tree - allocation error FDT creation failed! hanging...### ERROR ### Please RESET the board ### Removing this define solves this issue. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Nikita Kiryanov <nikita@compulab.co.il> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Tom Rini <trini@ti.com>
| | | * OMAP3: fix default environment for mcx boardStefano Babic2014-02-21-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Patch allows to load a script at the startup from MMC. Signed-off-by: Stefano Babic <sbabic@denx.de>
| | | * OMAP3: add missing gpio clock init and fix NAND SPL for mcx boardStefano Babic2014-02-21-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch contains the same fixes as commit 4b9b2c300a23ca4a85811918dc92e822a9571a87 (missing CONFIG_OMAP3_GPIO_2) and commit f9095aac793aa8917ab9b915c5d449e6dc8d3d30 (missing CONFIG_SPL_NAND_SOFTECC). Same issues are relevant for the mcx board, too. Signed-off-by: Stefano Babic <sbabic@denx.de>
| | | * arm: omap3: Fix tao3530/omap3_ha SPL boot hangup (GPIO clocks not enabled)Stefan Roese2014-02-21-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch f33b9bd3 [arm: omap3: Enable clocks for peripherals only if they are used] breaks SPL booting on tao3530. Since some gpio input's are read to detect the board revision. But with this patch above, the clocks to the GPIO subsystems are not enabled per default any more. The GPIO banks need to be configured specifically now. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Stefano Babic <sbabic@denx.de>
| | | * Add support for B&R KWB MotherboardHannes Petermaier2014-02-21-0/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for Bernecker & Rainer Industrieelektronik GmbH KWB Motherboard, using TI's AM3352 SoC. Most of code is derived from TI's AM335x_EVM Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at> Cc: trini@ti.com
| | | * board: Add support for B&R T-Series MotherboardHannes Petermaier2014-02-21-0/+462
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for Bernecker & Rainer Industrieelektronik GmbH T-Series Motherboard, using TI's AM3352 SoC. Most of code is derived from TI's AM335x_EVM Signed-off-by: Hannes Petermaier <oe5hpm@oevsv.at>
| | | * am335x: Initial support for Silica Pengwyn boardLothar Felten2014-02-21-1/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch add support for the Silica Pengwyn board [1] The board is based on a TI AM3354 CPU [2] All jumpers removed it will boot from the SDcard, the console is on UART1 accessible via the FDTI -> USB. The on board NAND flash is supported and can act as boot medium, depending on jumper settings. USB Host, USB Device and Ethernet are also provided but untested. [1] http://www.silica.com/product/silica-pengwyn-board.html [2] http://www.ti.com/product/am3354 Signed-off-by: Lothar Felten <lothar.felten@gmail.com> [trini: Move CONFIG_BOARD_LATE_INIT into am335x_evm.h, drop unused spi0_pin_mux from Pengwyn support] Signed-off-by: Tom Rini <trini@ti.com>
| | * | board: bcm28155_ap: Add board filesDarwin Rambo2014-02-22-0/+140
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the bcm28155_ap reference board. Signed-off-by: Darwin Rambo <drambo@broadcom.com> Reviewed-by: Steve Rae <srae@broadcom.com> Reviewed-by: Tim Kryger <tkryger@linaro.org>
| | * | arch: bcm281xx: Initial commit of bcm281xx architecture codeDarwin Rambo2014-02-22-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add bcm281xx architecture support code including a clock framework and chip reset. Define register block base addresses for the bcm281xx architecture and create an empty gpio header file required when CONFIG_CMD_GPIO is set. Signed-off-by: Darwin Rambo <drambo@broadcom.com> Reviewed-by: Steve Rae <srae@broadcom.com> Reviewed-by: Tim Kryger <tkryger@linaro.org>
| | * | ARM: rpi_b: rework boot scripts, enable sysbootStephen Warren2014-02-22-15/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework rpi_b's bootcmd (and sub-commands) to match Tegra's bootcmd as much as possible. This will aid in a future patch which will create a common header e.g. config_distro_bootcmd.h. While at it, enable booting from extlinux.conf using the sysboot command. The iteration and componentization currently makes a little more sense for Tegra than RPi, but I'd still like to keep the two as similar as possible. USB and networking support is coming to the RPi in due course, and it'll all make more sense then anyway. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
| | * | ARM: rpi_b: load /uEnv.txt from MMC at startupStephen Warren2014-02-21-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Pi has no flash to store an environment in the usual fashion. However, the user may wish to customize the environment. We know that the SD card must be present, since that's where the boot ROM has loaded U-Boot from. So, load uEnv.txt from there early during boot. This allows the user to e.g. customize boot_targets, in order to automatically select network boot. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
| | * | ARM: rpi_b: convert to use distro defaultsStephen Warren2014-02-21-16/+13
| | |/ | | | | | | | | | | | | | | | | | | | | | Modify the rpi_b board to include the "distro defaults" header, so that all the config options distros expect are enabled. Remove any #defines that enable the same options from the rpi_b.h. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
| * | Merge branch 'master' of git://git.denx.de/u-boot-mpc85xxTom Rini2014-02-25-43/+194
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | With this, fixup a trivial build error of get_effective_memsize needing to be updated in the new board/freescale/p1010rdb/spl.c Signed-off-by: Tom Rini <trini@ti.com>
| | * | powerpc/mpc8536DS:Increase binary size for mpc8536DS boardHaijun.Zhang2014-02-24-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | u-boot binary size for Freescale mpc8536DS platforms is 512KB. This has been reached to upper limit of the platforms and causig linker error. So increase the u-boot binary size to 768KB. Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | powerpc: p1010rdb: Enable p1010rdb to start from NAND/SD/SPI flash with SPLYing Zhang2014-02-24-9/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the previous patches, we introduced the SPL/TPL fraamework. For SD/SPI flash booting way, we introduce the SPL to enable a loader stub. The SPL was loaded by the code from the internal on-chip ROM. The SPL initializes the DDR according to the SPD and loads the final uboot image into DDR, then jump to the DDR to begin execution. For NAND booting way, the nand SPL has size limitation on some board(e.g. P1010RDB), it can not be more than 8KB, we can call it "minimal SPL", So the dynamic DDR driver doesn't fit into this minimum SPL. We added the TPL that is loaded by the the minimal SPL. The TPL initializes the DDR according to the SPD and loads the final uboot image into DDR,then jump to the DDR to begin execution. This patch enabled SPL/TPL for P1010RDB to support starting from NAND/SD/SPI flash with SPL framework and initializing the DDR according to SPD in the SPL/TPL. Because the minimal SPL load the TPL to L2 SRAM and the jump to the L2 SRAM to execute, so the section .resetvec is no longer needed. Signed-off-by: Ying Zhang <b40530@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | SPL: P1022DS: fix the problem booting from spi flashYing Zhang2014-02-24-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was no enough memory for malloc in SPL booting from spi flash, so relayout the memory in SPL: reduce the memory for global data from 16K Bytes to 4K Bytes, save the space for malloc. Signed-off-by: Ying Zhang <b40530@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | SPL: P2020RDB: fix the problem booting from spi flashYing Zhang2014-02-24-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was no enough stack in SPL, so the buffer needed in SPL is to malloc from memory pool and to repalce the temporary variable. Signed-off-by: Ying Zhang <b40530@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | SPL: powerpc: expand SPL's length to 128KYing Zhang2014-02-24-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. The SPL's length of SDCARD boot has not enough,expand the SPL's length to 128K. 2. deleted unused symbol: CONFIG_SYS_RUN_INDDR Signed-off-by: Ying Zhang <b40530@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| | * | powerpc/t2081qds: Add T2081 QDS board supportShengzhou Liu2014-02-24-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | T2081 QDS is a high-performance computing evaluation, development and test platform supporting the T2081 QorIQ Power Architecture processor. T2081QDS board Overview ----------------------- - T2081 SoC integrating four 64-bit dual-threads e6500 cores up to 1.8GHz - 2MB shared L2 and 512KB L3 CoreNet platform cache (CPC) - CoreNet fabric supporting coherent and noncoherent transactions with prioritization and bandwidth allocation - 32-/64-bit DDR3/DDR3LP SDRAM memory controller with ECC and interleaving - Ethernet interfaces: - Two on-board 10M/100M/1G bps RGMII ports - Two 10Gbps XFI with on-board SFP+ cage - 1Gbps/2.5Gbps SGMII Riser card - 10Gbps XAUI Riser card - Accelerator: - DPAA components consist of FMan, BMan, QMan, PME, DCE and SEC - SerDes: - 8 lanes up to 10.3125GHz - Supports SGMII, HiGig, XFI, XAUI and Aurora debug, - IFC: - 512MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA - eSPI: - Three SPI flash (16MB N25Q128A + 16MB EN25S64 + 512KB SST25WF040) - USB: - Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB) - PCIe: - Four PCI Express controllers (two PCIe 2.0 and two PCIe 3.0 with SR-IOV) - eSDHC: - Supports various SD/SDHC/SDXC/eMMC devices with adapter cards and voltage translators - I2C: - Four I2C controllers. - UART: - Dual 4-pins UART serial ports Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
| * | | kbuild: Move linker sciript check to prepare1Masahiro Yamada2014-02-25-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Same as the previous commit. Move sanity check to prepare1 target to avoid nasty troubles. Before this commit, LDSCRIPT existence was not checked when it was specified by CONFIG_SYS_LDSCRIPT. Now LDSCRIPT existence is checked for all boards. $(wildcard $(LDSCRIPT)) must point to the linker scripts with absolute path. Otherwise, make will terminate with a false error on out-of-tree build. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
| * | | arm: delete unused macro CONFIG_ARCH_DEVICE_TREEMasahiro Yamada2014-02-24-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Tom Warren <twarren@nvidia.com> Cc: Stephen Warren <swarren@nvidia.com> Cc: Rajeshwari Birje <rajeshwari.s@samsung.com> Cc: Inderpal Singh <inderpal.singh@linaro.org>
| * | | common: Add get_effective_memsize() to memsize.cYork Sun2014-02-21-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function has been around for powerpc. It is used for systems with memory more than CONFIG_MAX_MEM_MAPPED. In case of non-contiguous memory, this feature can limit U-boot to one block without going over the limit. Signed-off-by: York Sun <yorksun@freescale.com> Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
| * | | driver/ddr: Add 256 byte interleaving supportYork Sun2014-02-21-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Freescale LayerScape SoCs support controller interleaving on 256 byte size. This interleaving is mandoratory. Signed-off-by: York Sun <yorksun@freescale.com>
| * | | driver/ddr: Change Freescale ARM DDR driver to support both big and little ↵York Sun2014-02-21-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | endian Initially it was believed the DDR controller on Freescale ARM would have big endian. But some platform will have little endian. Signed-off-by: York Sun <yorksun@freescale.com>
| * | | fs/fdos: RemoveTom Rini2014-02-21-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | We have an unused FAT implementation in fs/fdos, remove. Signed-off-by: Tom Rini <trini@ti.com>
generated by cgit v1.1 at 2024-12-20 14:33:56 +0000