The fifo size of ep0 is 64 bytes, and if the packet size grater than
64 bytes, the driver would have to fill up the fifo multiple times,
and before filling up the fifo, the driver should make sure the fifo
is empty by checking fifo empty indication.
However there is a hardware bug that the fifo empty indication is
somehow a bit earlier than fifo reset. So if I don't add an extra
delay here, the data might be corrupted. (i.e., 1 byte missing)
After a couple of tests, it truns out that 1 usec is good enough.
This workaround should be applied to all hardware revisions.
Signed-off-by: Kuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>
Since hardware revision 1.11.0, the following interrupt status
registers are now W1C (i.e., write 1 clear):
1. Interrupt Source Group 0 Register (0x144) (EP0 Abort: BIT5)
2. Interrupt Source Group 2 Register (0x14C) (All bits)
And before revision 1.11.0, these registers are all R/W.
Which means software must write a 0 to clear the status.
Signed-off-by: Kuo-Jung Su <dantesu@faraday-tech.com>
CC: Marek Vasut <marex@denx.de>
Bringing in the MMC tree means that CONFIG_BOUNCE_BUFFER needed to be
added to include/configs/exynos5-dt.h now.
Conflicts:
include/configs/exynos5250-dt.h
Signed-off-by: Tom Rini <trini@ti.com>
Enabled default dts files on respective pre-board config
files this is way MAKEALL will works. and it's upto user
to build specific dts by specifying at build time.
$ make zynq_zc70x_config
$ make --> with default dts zynq-zc702.dts
or
$ make DEVICE_TREE=zynq-zc702 --> Same configuration with zynq-zc706.dts
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
CONFIG_FIT_SIGNATURE - signature node support in FIT image
CONFIG_RSA - RSA lib support
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
GPIO dummy routines are required for fdt build, may be removed
these dependencies once the u-boot fdt is fully optimized.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
This patch provides a basic fdt support for zynq u-boot.
zynq-7000.dtsi-> initial arch dts file
zynq-zed.dts -> initial zed board dts file
more devices should be added in subsequent patches.
u-boot build: once configuring of a board done
for building dtb with zynq-zed.dts as an input
zynq-uboot> make DEVICE_TREE=zynq-zed
Enabled CONFIG_OF_SEPARATE for building dtb separately.
There is a new binary called u-boot-dtb.bin which is a u-boot
with devicetree supported.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Defined default env. for autoboot FIT image from
respective boot devices.
Default settings:
fit_image=fit.itb
load_addr=0x2000000
fit_size=0x800000
flash_off=0x100000
nor_flash_off=0xE2100000
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Added support to find the bootmodes by reading
slcr bootmode register. this can be helpful to
autoboot the configurations w.r.t a specified bootmode.
Added this functionality on board_late_init as it's not
needed for normal initializtion part.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
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 XM012:
- 1GB DDR3
- 64MiB Numonyx NOR flash
- USB-UART
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
Cc: Stefan Roese <sr@denx.de>
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 XM013:
- 1GB DDR3
- 128 Mb Quad-SPI Flash(dual parallel)
- USB-UART
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
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 XM010:
- 1Gb DDR3
- 1Mb SST SPI flash
- 128 Mb Quad-SPI Flash
- 8 Mb SST SI flash
- Full size SD/MMC card cage
- 10/100/1000 Ethernet
- USB-UART
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
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>
Adds configurations for Catalyst 24WC08 EEPROM, which
is present on the zynq boards.
Enable EEPROM support for zc70x boards.
Signed-off-by: Jagannadha Sutradharudu Teki <jaganna@xilinx.com>
CONFIG_SYS_SDRAM_SIZE is specific to a board hence moved
to specific pre-config board files.
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.h -> zynq-common.h, zynq-common is Common
configuration options for all Zynq boards.
zynq.h is no longer exists hense removed from boards.cfg
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>
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'.
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.
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>
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>
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>
To add the DesignWare MMC driver support for Altera SOCFPGA. It
required information such as clocks and bus width from platform
specific files (SOCFPGA handoff files)
Signed-off-by: Chin Liang See <clsee@altera.com>
Cc: Rajeshwari Shinde <rajeshwari.s@samsung.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Pantelis Antoniou <panto@antoniou-consulting.com>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
The eMMC and the SD-Card specifications describe the optional SET_DSR command.
During measurements at our lab we found that some cards implementing this feature
having really strong driver strengts per default. This can lead to voltage peaks
above the specification of the host on signal edges for data sent from a card to
the host.
Since availability of a given card type may be shorter than the time a certain
hardware will be produced it is useful to have support for this command (Alternative
would be changing termination resistors and adapting the driver strength of the
host to the used card.)
Following proposal for an implementation:
- new field that reflects CSD field DSR_IMP in struct mmc
- new field for design specific DSR value in struct mmc
- board code can set DSR value in mmc struct just after registering an controller
- mmc_startup sends the the stored DSR value before selecting a card, if DSR_IMP is set
Additionally the mmc command is extended to make is possible to play around with different
DSR values.
The concept was tested on a i.MX53 based platform using a Micron eMMC card where the default
DSR is 0x0400 (12mA) but in our design 0x0100 (0x0100) were enough. To use this feature for
instance on a mx53loco one have to add a call to mmc_set_dsr() in board_mmc_init() after
calling fsl_esdhc_initialize() for the eMMC.
Signed-off-by: Markus Niebel <Markus.Niebel@tqs.de>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Fixup prints to show where the print is done from, and
a few minor formatting/grammar issues.
Signed-off-by: Darwin Rambo <drambo@broadcom.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
