ZC770 is a complete development board based on the Xilinx Zynq-7000
All Programmable SoC, similar to ZC70x board but which has four
different daughter cards, like XM010, XM011, XM012 and XM013
ZC770 is a complete development board based on the Xilinx Zynq-7000
All Programmable SoC, similar to ZC70x board but which has four
different daughter cards, like XM010, XM011, XM012 and XM013
ZC770 is a complete development board based on the Xilinx Zynq-7000
All Programmable SoC, similar to ZC70x board but which has four
different daughter cards, like XM010, XM011, XM012 and XM013
MicroZed is a low-cost development board based on
the Xilinx Zynq-7000 All Programmable SoC.
APSOC:
- XC7Z010-1CLG400C
Memory:
- 1 GB of DDR3 SDRAM
- 128Mb of QSPI flash(S25FL128SAGBHI200)
- Micro SD card interface
Communication:
- 10/100/1000 Ethernet
- USB 2.0
- USB-UART
User I/O:
- 100 User I/O (50 per connector)
- Configurable as up to 48 LVDS pairs or 100 single-ended I/O
Misc:
- Xilinx PC4 JTAG configuration port
- PS JTAG pins accessible via Pmod
- 33.33 MHz oscillator
- User LED and push switch
For more info - http://zedboard.org/product/microzed
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
The Zynq-7000 APSOC zc702 and zc706 enabled complte embedded
processing includes ASIC and FPGA design.
ZC702-:
APSOC:
- XC7Z020-CLG484-1
Memory:
- DDR3 Component Memory 1GB
- 16MB Quad SPI Flash
- IIC - 1 KB EEPROM
Connectivity:
- Gigabit Ethernet GMII, RGMII and SGMII.
- USB OTG - Host USB
- IIC Bus Headers/HUB
- 1 CAN with Wake on CAN
- USB-UART
Video/Display:
- HDMI Video OUT
- 8X LEDs
Control & I/O:
- 3 User Push Buttons
- 2 User Switches
- 8 User LEDs
For more info on zc702 board:
- http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC702-G.htm
ZC706-:
APSOC:
- XC7Z045 FFG900 -2 AP SoC
Memory:
- DDR3 Component Memory 1GB (PS)
- DDR3 SODIM Memory 1GB (PL)
- 2X16MB Quad SPI Flash (dual parallel)
- IIC - 1 KB EEPROM
Connectivity:
- PCIe Gen2x4
- SFP+ and SMA Pairs
- GigE RGMII Ethernet (PS)
- USB OTG 1 (PS) - Host USB
- IIC Bus Headers/HUB (PS)
- 1 CAN with Wake on CAN (PS)
- USB-UART
Video/Display:
- HDMI 8 color RGB 4.4.4 1080P-60 OUT
- HDMI IN 8 color RGB 4.4.4
Control & I/O:
- 2 User Push Buttons/Dip Switch, 2 User LEDs
- IIC access to GPIO
- SDIO (SD Card slot)
- 3 User Push Buttons, 2 User Switches, 8 User LEDs
For more info on zc706 board:
- http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Zynq ethernet controller support two GEM's like
CONFIG_ZYNQ_GEM0 and CONFIG_ZYNQ_GEM1 enabled
both so-that the respective board will define
these macros based on their usage.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Zynq uart controller support two serial ports like
CONFIG_ZYNQ_SERIAL_UART0 and CONFIG_ZYNQ_SERIAL_UART1
enabled both so-that the respective board will define
these macros based on their usage.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Albert ARIBAUD [Fri, 10 Jan 2014 09:19:45 +0000 (10:19 +0100)]
arm: make 'MAKEALL -a' distinguish between arm and aarch64
The vexpress_aemv8a is the first aarch64 board in U-Boot.
As it was introduced, it gets built when "MAKEALL -a arm"
is invoked, and fails as this command is run with a 32-bit,
not 64-bit, toolchain as the cross-compiler.
Introduce 'aarch64' as a valid 'MAKEALL -a' argument, treated
as 'arm' for all other intents, and change the architecture
of the vexpress_aemv8a entry in boards.cfg from 'arm' to
'aarch64'.
Tom Rini [Thu, 9 Jan 2014 20:11:27 +0000 (15:11 -0500)]
armv8: Use __aarch64__ rather than CONFIG_ARM64 in some cases
The toolchain sets __aarch64__ for both LE and BE. In the case of
posix_types.h we cannot reliably use config.h as that will lead to
problems. In the case of byteorder.h it's clearer to check the EB flag
being set in either case instead.
Cc: David Feng <fenghua@phytium.com.cn> Signed-off-by: Tom Rini <trini@ti.com>
Amended by Albert ARIBAUD <albert.u.boot@aribaud.net> to
actually remove the config.h include from the posix_types.h
files, with permission from Tom Rini.
David Feng [Sat, 14 Dec 2013 03:47:35 +0000 (11:47 +0800)]
arm64: core support
Relocation code based on a patch by Scott Wood, which is: Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: David Feng <fenghua@phytium.com.cn>
Scott Wood [Sat, 14 Dec 2013 03:47:33 +0000 (11:47 +0800)]
arm64: Turn u-boot.bin back into an ELF file after relocate-rela
While performing relocations on u-boot.bin should be good enough for
booting on real hardware, some simulators insist on booting an ELF file
(and yet don't perform ELF relocations), so convert the relocated
binary back into an ELF file. This can go away in the future if we
change relocate-rela to operate directly on the ELF file, or if and
when we stop caring about a simulator with this restriction.
Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: David Feng <fenghua@phytium.com.cn>
Scott Wood [Sat, 14 Dec 2013 03:47:32 +0000 (11:47 +0800)]
arm64: Add tool to statically apply RELA relocations
ARM64 uses the newer RELA-style relocations rather than the older REL.
RELA relocations have an addend in the relocation struct, rather than
expecting the loader to read a value from the location to be updated.
While this is beneficial for ordinary program loading, it's problematic
for U-Boot because the location to be updated starts out with zero,
rather than a pre-relocation value. Since we need to be able to run C
code before relocation, we need a tool to apply the relocations at
build time.
In theory this tool is applicable to other newer architectures (mainly
64-bit), but currently the only relocations it supports are for arm64,
and it assumes a 64-bit little-endian target. If the latter limitation
is ever to be changed, we'll need a way to tell the tool what format
the image is in. Eventually this may be replaced by a tool that uses
libelf or similar and operates directly on the ELF file. I've written
some code for such an approach but libelf does not make it easy to poke
addresses by memory address (rather than by section), and I was
hesitant to write code to manually parse the program headers and do the
update outside of libelf (or to iterate over sections) -- especially
since it wouldn't get test coverage on things like binaries with
multiple PT_LOAD segments. This should be good enough for now to let
the manual relocation stuff be removed from the arm64 patches.
Signed-off-by: Scott Wood <scottwood@freescale.com> Signed-off-by: David Feng <fenghua@phytium.com.cn>
Nikita Kiryanov [Tue, 31 Dec 2013 10:55:15 +0000 (12:55 +0200)]
arm: omap: cm_t35: enable gpio bank 5 clocks explicitly
Following commit "arm: omap3: Enable clocks for peripherals only if they are
used" (f33b9bd3984fb11e1d8566a866adc5957b1e1c9d) it is now necessary to enable
clocks for GPIO banks explicitly. On cm_t35, GPIO bank 5 is necessary for
scf0403 lcd support.
Enable GPIO bank 5 clocks.
Signed-off-by: Nikita Kiryanov <nikita@compulab.co.il> Cc: Igor Grinberg <grinberg@compulab.co.il> Cc: Tom Rini <trini@ti.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Jeroen Hofstee [Sat, 21 Dec 2013 17:06:33 +0000 (18:06 +0100)]
ARM: twister: add missing gpio clock init
Commit f33b9bd3984fb11e1d8566a866adc5957b1e1c9d breaks boards
which do not explicitly enable the gpio clocks. This causes
the twister spl to hang, since it uses the no longer enabled
gpio 55. Add CONFIG_OMAP3_GPIO_2 to unbrick the board.
Jeroen Hofstee [Sat, 21 Dec 2013 17:03:09 +0000 (18:03 +0100)]
ARM: tam3517-common: fix nand spl boot
commit f9095aac793aa8917ab9b915c5d449e6dc8d3d30, "mtd: nand:
omap: add CONFIG_NAND_OMAP_ECCSCHEME for selection of ecc-scheme"
removed CONFIG_SPL_NAND_SOFTECC from the tam3517 common config,
causing the spl nand boot to fail. Add it back, so derived
boards boot again.
The board is similar to the standard km_kirkwood board. From a
u-boot point of view, the only difference is an increased
256 MiB DRAM (128M16). A board based on this design is for
example the SUP12.
Otavio Salvador [Mon, 16 Dec 2013 22:44:05 +0000 (20:44 -0200)]
ARM: mx6: Allow enablement of FEC Anatop based clock for all MX6
The enable_fec_anatop_clock method should be available for all MX6
variant as it is not MX6 SoloLite specific. This moves the code out of
the #ifdef/#endif and we make it conditional to CONFIG_FEC_MXC
instead.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Stefano Babic <sbabic@denx.de>
,----
| The FDT blob will be placed at DDR physical addr: 0x11000000. When Linux kernel
| Boot up, it will decompress the compressed kernel image and place the decompressed
| kernel image at the low end of the DDR memory and start running from it. If the
| decompressed kernel image is bigger for example than 16M, it may over written the
| fdt blob which u-boot loaded to the DDR memory @0x11000000 with fdt_addr=0x11000000
|
| To expand the fdt_addr from 0x11000000 to 0x18000000, which can avoid the override
| Since we will not likely have one kernel image larger than 128MB.
`----
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Stefano Babic <sbabic@denx.de>
Otavio Salvador [Mon, 16 Dec 2013 22:44:02 +0000 (20:44 -0200)]
mx28evk: Add 'nandboot' environment command
This reads the kernel, ftd and boot into ubifs filesystem. While on
that, the SD firmware filename definition has been moved next to the
other SD related commands.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
The IOMUX_CONFIG_SION allows for reading PAD value from PSR register.
The following quote from the datasheet:
,----
| ...
| 28.4.2.2 GPIO Write Mode
| The programming sequence for driving output signals should be as follows:
| 1. Configure IOMUX to select GPIO mode (Via IOMUXC), also enable SION if need
| to read loopback pad value through PSR
| 2. Configure GPIO direction register to output (GPIO_GDIR[GDIR] set to 1b).
| 3. Write value to data register (GPIO_DR).
| ...
`----
This fixes the gpio_get_value to properly work when a GPIO is set for
output and has no conflicts.
Thanks for Benoît Thébaudeau <benoit.thebaudeau@advansee.com>, Fabio
Estevam <fabio.estevam@freescale.com> and Eric Bénard
<eric@eukrea.com> for helping to properly trace this down.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Acked-by: Stefano Babic <sbabic@denx.de>
Fabio Estevam [Thu, 26 Dec 2013 16:51:32 +0000 (14:51 -0200)]
mx6: soc: Set the VDDSOC at 1.175 V
mx6 datasheet specifies that the minimum VDDSOC at 792 MHz is 1.15 V.
Add a 25 mV margin and set it to 1.175V.
This also matches the VDDSOC voltages for 792MHz operation that the kernel configures:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/mach-mx6/cpu_op-mx6.c?h=imx_3.0.35_4.1.0
Piotr Wilczek [Mon, 30 Dec 2013 08:40:40 +0000 (09:40 +0100)]
board:trats2: fix default partitions and mmc env
This patch add uuid disk to defualt partions necessary to
restore gpt partitions and fixes mmcdev environmental variable.
Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Piotr Wilczek [Wed, 18 Dec 2013 14:43:37 +0000 (15:43 +0100)]
board:trats1:trats2: fix adapter number
This fix is necessary after increased by one the number
of adapters in s3c24x0 driver.
Tested on Trats and Trats2.
Signed-off-by: Piotr Wilczek <p.wilczek@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Minkyu Kang <mk7.kang@samsung.com> Cc: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rajeshwari Birje [Thu, 26 Dec 2013 04:14:27 +0000 (09:44 +0530)]
SPL: EXYNOS: Prepare for variable size SPL support
When variable size SPL is used, the BL1 expects the SPL to be
encapsulated differently: instead of putting the checksum at a fixed
offset in the SPL blob, prepend the blob with a header including the
size and the checksum.
The enhancements include
- adding a command line option, '--vs' to indicate the need for the
variable size encapsulation
- padding the fixed size encapsulated blob with 0xff instead of random
memory contents
- do not silently truncate the input file, report error instead
- no need to explicitly closing files/freeing memory, this all happens
on exit; removing cleanups it makes code clearer
- profuse commenting
- modify Makefile to allow enabling the new feature per board
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rajeshwari Birje [Thu, 26 Dec 2013 04:14:20 +0000 (09:44 +0530)]
EXYNOS5420: Add dmc and phy_control register structure
Add dmc and phy_control register structure for 5420.
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rajeshwari Birje [Thu, 26 Dec 2013 04:14:19 +0000 (09:44 +0530)]
EXYNOS5420: Add power register structure.
Add structure for power register for Exynos5420
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Rajeshwari Birje [Thu, 26 Dec 2013 04:14:17 +0000 (09:44 +0530)]
EXYNOS5: Create a common board file
Create a common board.c file for all functions which are common across
all EXYNOS5 platforms.
exynos_init function is provided for platform specific code.
Signed-off-by: Rajeshwari S Shinde <rajeshwari.s@samsung.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Lokesh Vutla [Tue, 10 Dec 2013 09:32:23 +0000 (15:02 +0530)]
ARM: AM43xx: GP_EVM: Add support for DDR3
GP EVM has 1GB DDR3 attached(Part no: MT41K512M8RH).
Adding details for the same.
Below is the brief description of DDR3 init sequence(SW leveling):
-> Enable VTT regulator
-> Configure VTP
-> Configure DDR IO settings
-> Disable initialization and refreshes until EMIF registers are programmed.
-> Program Timing registers
-> Program leveling registers
-> Program PHY control and Temp alert and ZQ config registers.
-> Enable initialization and refreshes and configure SDRAM CONFIG register
Lokesh Vutla [Tue, 10 Dec 2013 09:32:22 +0000 (15:02 +0530)]
ARM: AM43xx: EPOS_EVM: Add support for LPDDR2
AM4372 EPOS EVM has 1GB LPDDR2(Part no: MT42L256M32D2LG-25 WT:A)
Adding LPDDR2 init sequence and register details for the same.
Below is the brief description of LPDDR2 init sequence:
-> Configure VTP
-> Configure DDR IO settings
-> Disable initialization and refreshes until EMIF registers are programmed.
-> Program Timing registers
-> Program PHY control and Temp alert and ZQ config registers.
-> Enable initialization and refreshes and configure SDRAM CONFIG register
-> Wait till initialization is complete and the configure MR registers.
Lokesh Vutla [Tue, 10 Dec 2013 09:32:21 +0000 (15:02 +0530)]
ARM: AM33xx+: Update ioregs to pass different values
Currently same value is programmed for all ioregs. This is not
the case for all SoC's like AM4372. So adding a structure for ioregs
and updating in all board files. And also return from config_cmd_ctrl()
and config_ddr_data() functions if data is not passed.
Lokesh Vutla [Tue, 10 Dec 2013 09:32:20 +0000 (15:02 +0530)]
ARM: AM43xx: clocks: Update DPLL details
Updating the Multiplier and Dividers value for all DPLLs.
Safest OPP is read from DEV ATTRIBUTE register. Accoring to the value
returned the MPU DPLL is locked.
At different OPPs follwoing are the MPU locked frequencies.
OPP50 300MHz
OPP100 600MHz
OPP120 720MHz
OPPTB 800MHz
OPPNT 1000MHz
According to the latest DM following is the OPP table dependencies:
VDD_CORE VDD_MPU
OPP50 OPP50
OPP50 OPP100
OPP100 OPP50
OPP100 OPP100
OPP100 OPP120
So at different OPPs of MPU it is safest to lock CORE at OPP_NOM.
Following are the DPLL locking frequencies at OPP NOM:
Core locks at 1000MHz
Per locks at 960MHz
LPDDR2 locks at 266MHz
DDR3 locks at 400MHz
Touching AM33xx files also to get DPLL values specific to board but no
functionality difference. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Sekhar Nori [Tue, 10 Dec 2013 09:32:16 +0000 (15:02 +0530)]
ARM: AM43XX: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
CONFIG_ENV_VARS_UBOOT_CONFIG, CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG and
CONFIG_BOARD_LATE_INIT is already set. Adding support to detect the
board. These variables are used by findfdt.
Signed-off-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Patch f33b9bd3
[arm: omap3: Enable clocks for peripherals only if they are used]
breaks SPL booting on Beagleboard. 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>
Alban Bedel [Wed, 20 Nov 2013 16:42:46 +0000 (17:42 +0100)]
arm: tegra: Fix the CPU complex reset masks
The CPU complex reset masks are not matching with the datasheet for
the CLK_RST_CONTROLLER_RST_CPU_CMPLX_SET/CLR_0 registers. For both T20
and T30 the register consist of groups of 4 bits, with one bit for
each CPU core. On T20 the 2 high bits of each group are always stubbed
as there is only 2 cores.
Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swrren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Alban Bedel [Thu, 14 Nov 2013 09:58:30 +0000 (10:58 +0100)]
ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
Add support for the new Tamonten™ NG platform from Avionic Design.
Currently only I2C, MMC, USB and ethernet have been tested.
Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Reviewed-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Jim Lin [Wed, 6 Nov 2013 06:03:44 +0000 (14:03 +0800)]
ARM: config: USB: Tegra30/114: Fix EHCI timeout issue on "bootp"
Fix the timeout issue after running "bootp" command in u-boot
console. For example you see "EHCI timed out on TD- token=0x...".
TXFIFOTHRES bits of TXFILLTUNING register should be set to 0x10
after a controller reset and before RUN bit is set
(per technical reference manual).
Signed-off-by: Jim Lin <jilin@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
projects / u-boot.git / log
