Commit Graph

29576 Commits

Author SHA1 Message Date
Kishon Vijay Abraham I
a139b96a47 usb: gadget: udc: add udc-core from linux kernel to u-boot
Added udc-core.c from linux kernel 3.19-rc1 (97bf6af1f9) to u-boot.
This will be adapted to work with u-boot in the
following patches.
Adding support for udc will help to seamlessly port dwc3 driver from
linux kernel to u-boot (since dwc3 uses udc-core) and it'll also help
to add support for multiple gadget controllers to be functional at the
same time.
All other gadget drivers can also be adapted to use udc-core.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-14 05:48:08 +02:00
Kishon Vijay Abraham I
fc2f15d2f7 ARM: AM43xx: Enable clocks for USB OTGSS and USB PHY
Enabled clocks for dwc3 controller and USB PHY present in AM43xx.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-14 05:48:08 +02:00
Kishon Vijay Abraham I
d3cfcb3e2c ARM: DRA7: Enable clocks for USB OTGSS and USB PHY
Enabled clocks for dwc3 controller and USB PHY present in DRA7.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-14 05:48:08 +02:00
Stephen Warren
5877de9165 usb: dwc2: retry NAK'd interrupt transfers
IIUC, interrupt transfers are NAK'd by devices until they wish to trigger
an interrupt, and e.g. EHCI controllers retry these in HW until they are
ACK'd. However, DWC2 doesn't seem to retry, so we need to do this in SW.
In practice, I've seen DWC2_HCINT_FRMOVRUN happen too. I'm not quite sure
what this error implies; perhaps it's related to how near the end of a
USB frame we're at when the interrupt transfer is initiated? Anyway,
retrying this temporary error seems to be necessary too.

With all these commits applied, both my USB keyboards (one LS Lenovo and
one FS Dell) work correctly when there is no USB hub between the SoC and
the keyboard; We still need split transactions to be implemented for hubs
to work.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
e236519b73 usb: dwc2: implement interrupt transfers
As best I can tell, there's no difference between bulk and interrupt
transfers in terms of how the HW should be programmed, at least given
that we're executing one transaction at a time rather than scheduling
them into frames for maximum throughput.

This patch ends up sharing the toggle bit state between bulk and
interrupt transfers on a particular EP. However I believe this is fine;
AFAIK a given EP either uses bulk or interrupt transfers and doesn't mix
them.

This patch doesn't do anything with the "interval" parameter for
interrupt transfers, but then most other USB controller drivers in U-Boot
don't either.

It turns out that one of my keyboards is happy to work using control
transfers but the other only gives non-zero "HID reports" via interrupt
transfers.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
ed9bcbc792 usb: dwc2: correctly program hcchar for LS devices
A bit must be set in HCCHAR when communicating with low-speed devices.
I have no idea why there's no corresponding bit to distinguish between
full-speed and high-speed devices, but no matter; they all work now!

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
122426d46e ARM: bcm2835: use phys_to_bus() for mbox
When we communicate with the VideoCore to perform property mailbox
transactions, that is a DMA operation as far as the property buffer
is concerned. Use phys_to_bus() on that buffer.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
4748cce573 usb: dwc2: detect device speed correctly
This doesn't make my LS keyboard work any better, but it does at least
report the correct speed in "usb tree".

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
5c0beb5c58 usb: dwc2: use phys_to_bus/bus_to_phys
Use of these APIs is required on the Raspberry Pi. With this change, USB
on RPi1 should be more reliable, and USB on the RPi2 will start working.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
79340db7f1 ARM: bcm2835: implement phys_to_bus/bus_to_phys
The BCM283[56] contain both a L1 and L2 cache between the GPU (a/k/a
VideoCore CPU?) and DRAM. DMA-capable peripherals can also optionally
access DRAM via this same  L2 cache (although they always bypass the L1
cache). Peripherals select whether to use or bypass the cache via the
top two bits of the bus address.

An IOMMU exists between the ARM CPU and the rest of the system. This
controls whether the ARM CPU's accesses use or bypass the L1 and/or L2
cache. This IOMMU is configured/controlled exclusively by the VideoCore
CPU.

In order for DRAM accesses made by the ARM core to be coherent with
accesses made by other DMA peripherals, we must program a bus address
into those peripherals that causes the peripheral's accesses to use the
same set of caches that the ARM core's accesses will use.

On the RPi1, the VideoCore firmware sets up the IOMMU to enable use of
the L2 cache. This corresponds to addresses based at 0x40000000.

On the RPi2, the VideoCore firmware sets up the IOMMU to disable use of
the L2 cache. This corresponds to addresses based at 0xc0000000.

This patch implements U-Boot's phys_to_bus/bus_to_phys APIs according
to those rules.

For full details of this setup, please see Dom Cobley's description at:
http://lists.denx.de/pipermail/u-boot/2015-March/208201.html
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038
https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
927c1fa266 Create API to map between CPU physical and bus addresses
On some SoCs, DMA-capable peripherals see a different address space to
the CPU's physical address space. Create an API to allow platform-agnostic
drivers to convert between the two address spaces when programming DMA
operations.

This API will exist on all platforms, but will have a dummy implementation
when this feature is not required. Other platforms will enable
CONFIG_PHYS_TO_BUS and provide the required implementation.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
fc909c0563 usb: dwc2: fix bulk transfers
When I created wait_for_chhltd(), I noticed that some instances of the
code it replaced expected the ACK bit to be set and others didn't. I
assumed this was an accidental inconsistency in the code, so wrote
wait_for_chhltd() to always expect ACK to be set. This code appeared to
work correctly for both enumeration of USB keyboards and operation of
USB Ethernet devices. However, this change broke USB Mass Storage (at
least my USB SD card reader). This change reverts to exactly the
original behaviour. I'm not sure why the ACK bit isn't always set
(perhaps a quirk in the USB HW or DWC2 controller), but the code works
this way!

Fixes: 5be4ca7d6ac8 ("usb: dwc2: unify waiting for transfer completion")
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
805b67e1ea usb: dwc2: remove restriction on buffer length
Each USB transfer is split up into chunks that are held in an aligned
buffer. This imposes a limit on the size of each chunk, but no limit on
the total size of transferred data. Fix the logic in chunk_msg() not to
reject large transfers, but simply take the size of the aligned buffer
into account when calculating the chunk size.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
d1c880c66c usb: dwc2: fix aligned buffer usage
The original aligned_buffer usage:
a) Uselessly copied data into the aligned buffer even for IN
   transactions. Fix this my making the copy conditional.
b) Always programmed the HW to transfer to/from the start of the aligned
   buffer. This worked fine for OUT transactions since the memcpy copied
   the OUT data to this location too. However, for large IN transactions,
   since the copy from the aligned buffer to the "client" buffer was
   deferred until after all chunks were transferred. it resulted in each
   chunk's transfer over-writing the data for the first transfer. Fix
   this by copying IN data as soon as it's received.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:59 +02:00
Stephen Warren
66ffc87586 usb: dwc2: simplify wait_for_chhltd
toggle is never NULL. Simplify the code by removing handling of when it
is NULL.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:58 +02:00
Stephen Warren
282685e07e usb: dwc2: remove control_data_toggle[]
The control data toggle resets to DATA1 at the start of the data phase
of every setup transaction. We don't need a global variable to store
the value; we can just store it on the stack.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:58 +02:00
Stephen Warren
ee83755401 usb: dwc2: usb chunk_msg() for control transfers too
This removes duplicated code.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:58 +02:00
Stephen Warren
7b5e504dae usb: dwc2: refactor submit_bulk_msg to be common
Move the body of submit_bulk_msg() into new function chunk_msg(). This
can be shared with submit_control_msg() to reduce code duplication, and
allow control messages larger than maxpacket.

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:58 +02:00
Stephen Warren
4a1d21fc52 usb: dwc2: unify waiting for transfer completion
Lift common code out of submit_bulk_msg() and submit_control_msg().

Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:58 +02:00
Tim Harvey
319418c01c usb: hub: allow pgood_delay to be specified via env
Some USB devices break the spec and require longer warm-up times. Allow
the usb_pgood_delay env variable to override the calculated time.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
2015-04-14 05:47:48 +02:00
Stephen Warren
25c0673635 usb: fix first descriptor fetch error handling
When fetching the first descriptor from a new device, only validate that
we received at least 8 bytes, not that we received the entire descriptor.
The reasoning is:
- The code only uses fields in the first 8 bytes, so that's all we need
  to have fetched at this stage.
- The smallest maxpacket size is 8 bytes. Before we know the actual
  maxpacket the device uses, the USB controller may only accept a single
  packet (see the DWC2 note in the comment added in the commit).
  Consequently we are only guaranteed to receive 1 packet (at least 8
  bytes) even in a non-error case.

Fixes: 1a7758044b04 ("usb: Early failure when the first descriptor read
fails or is invalid")
Cc: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-14 05:47:48 +02:00
Paul Kocialkowski
04ee6ee2ca usb: Early failure when the first descriptor read fails or is invalid
This may happen when using an USB1 device on a controller that only supports
USB2 (e.g. EHCI). Reading the first descriptor will fail (read 0 byte), so we
can abort the process at this point instead of failing later and wasting time.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-04-14 05:47:48 +02:00
Paul Kocialkowski
8879be8857 usb: Check usb_new_device for failure
This checks that a new USB device is correctly initialized and frees it if not.
In addition, this doesn't report that USB was started when no device was found.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-04-14 05:47:48 +02:00
Paul Kocialkowski
5a80b3449b usb: usb_new_device return codes consistency
This makes use of errno return codes for representing error codes in a unified
way.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
2015-04-14 05:47:48 +02:00
Sergey Temerkhanov
f657087134 usb_storage:Fix USB storage capacity detection on 64 bit architectures
This patch fixes USB storage capacity detection breakage on 64-bit systems
which arises due to 'unsigned long' length difference. Old code assumes that
to be 32 bit and breaks because of inappropriate response buffer layout.
Also this fixes a number of build warnings and changes big-endian values
treatment style to be architecture-independent

Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
2015-04-14 05:47:48 +02:00
Sergey Temerkhanov
421a5a0c98 usb: 64-bit architectures support for xHCI
This commit allows xHCI to use both 64 and 32 bit memory
physical addresses depending on architecture it's being built for.
Also it makes use of readq()/writeq() on 64-bit systems

Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
2015-04-14 05:47:48 +02:00
Sergey Temerkhanov
b12242aceb usb: Convert protocol header structures to use explicitly sized variables
This patch converts USB protocol headers to use explicitly sized
fields like the rest of the code

Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Signed-off-by: Sergey Temerkhanov <s.temerkhanov@gmail.com>
2015-04-14 05:47:48 +02:00
Thierry Reding
ec5e78cf8a usb: mass-storage: Build warning fixes for 64-bit
Fix a printf format mismatch warning seen on 64-bit builds.

Cc: Łukasz Majewski <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Lukasz Majewski <l.majewski@samsung.com>
Tested-by: Lukasz Majewski <l.majewski@samsung.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-14 05:47:48 +02:00
Thierry Reding
96df9c7e94 usb: ehci-tegra: Build warning fixes for 64-bit
Cast pointers to unsigned long instead of a sized 32-bit type to avoid
pointer to integer cast size mismatch warnings.

Cc: Tom Warren <twarren@nvidia.com>
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-04-14 05:47:48 +02:00
Rob Herring
98ae840a00 ehci-hcd: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: Marek Vasut <marex@denx.de>
2015-04-14 05:47:47 +02:00
Rob Herring
f72d8320b6 usb: ci_udc: fix warnings on 64-bit builds
Change addresses to unsigned long to be compatible with 64-bit builds.
Regardless of fixing warnings, the device is still only 32-bit capable.

Signed-off-by: Rob Herring <robh@kernel.org>
Cc: "Łukasz Majewski" <l.majewski@samsung.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
2015-04-14 05:47:47 +02:00
Thierry Reding
4c5998b77a usb: eth: asix: Build warning fixes for 64-bit
Fix a type mismatch in a printf format string.

Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-04-14 05:47:47 +02:00
Franck Jullien
cd749658d5 usb_storage : scan all interfaces to find a storage device
Mass storage is not necessary present on interface 0. This
patch allow usb_stor_scan to look in every available interface.

Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
2015-04-14 05:47:47 +02:00
Tom Rini
f33cdaa4c3 Prepare v2015.04
Signed-off-by: Tom Rini <trini@konsulko.com>
2015-04-13 10:53:03 -04:00
Pavel Machek
a6a4c542d3 break build if it would produce broken binary
Add an error in known-bad case so that we don't produce broken and
hard to debug binaries.

Signed-off-by: Pavel Machek <pavel@denx.de>
2015-04-13 10:52:51 -04:00
Tom Rini
1d2f74690c Merge branch 'master' of git://www.denx.de/git/u-boot-imx 2015-04-13 10:52:46 -04:00
Stephen Warren
787affb41b ARM: rpi: add a couple more revision IDs
According to Gordon Henderson's WiringPi library, there are some more
Pi revision IDs out there. Add support for them.

http://git.drogon.net/?p=wiringPi;a=blob_plain;f=wiringPi/wiringPi.c;hb=5edd177112c99416f68ba3e8c6c4db6ed942e796

At least ID 0x13 is out in the wild:

Reported-by: Chee-Yang Chau <cychau@gmail.com>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
2015-04-13 08:48:36 -04:00
Masahiro Yamada
bf71a29c8e ARM: fix arch/arm/Makefile for Tegra
Since commit 79d75d7527 (ARM: move -march=* and -mtune= options to
arch/arm/Makefile), all the Tegra boards are broken because the SPL
is built for ARMv7.

Insert Tegra-specific code to arch/arm/Makefile to set compiler
flags for an earlier ARM architecture.

Note:
The v1 patch for commit 79d75d7527 *was* correct when it was
submitted.  Notice it was originally written for multi .config
configuration where Kconfig set CONFIG_CPU_V7/CONFIG_CPU_ARM720T for
Tegra U-Boot Main/SPL, respectively.  But, until it was merged into
the mainline, commit e02ee2548a (kconfig: switch to single .config
configuration) had been already applied there.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Stephen Warren <swarren@nvidia.com>
Reported-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Jan Kiszka <jan.kiszka@siemens.com>
2015-04-11 12:04:30 -04:00
Stefan Roese
4adb46a314 arm: armada-xp: Fix SPL for AXP by using save_boot_params_ret
Patch e11c6c27 (arm: Allow lr to be saved by board code) introduced
a different method to return from save_boot_params(). The SPL support
for AXP has been pulled and changing to this new method is now
required for SPL to work correctly.

Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Luka Perkov <luka.perkov@sartura.hr>
2015-04-11 11:49:00 +02:00
Tom Rini
c175f306b3 Merge git://git.denx.de/u-boot-arc 2015-04-10 12:39:13 -04:00
Alexey Brodkin
a811492e4f arc: fix separate compilation of start.o
While testing "arc: make sure _start is in the beginning of .text
section" I haven't done proper clean-up of built binaries and so missed
another tiny bit that lead to the following error:
 --->8---
    LD      u-boot
 arc-linux-ld.bfd: cannot find arch/arc/lib/start.o
 Makefile:1107: recipe for target 'u-boot' failed
 make: *** [u-boot] Error 1
 --->8---

Fix is trivial: put "start.o" in "extra-y".

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-04-10 19:22:40 +03:00
Linus Walleij
a7b00a7bf6 integrator: consolidate flash info
This consolidates the flash settings for the Integrator
and activates the new ARM flash image support for them
so images can be loaded by name from flash.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-04-10 11:54:08 -04:00
Linus Walleij
10d1491b3d vexpress64: juno: add default NOR flash boot
This modifies the vexpress64 Juno configuration so that
it will by default load and boot a kernel and a device tree
from the images stored in the NOR flash. When we are
at it, also define the proper command line for the Juno and
indicate that the USB stick (/dev/sda1) is the default
root file system.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-04-10 11:54:08 -04:00
Linus Walleij
4bb6650632 common/armflash: Support for ARM flash images
The ARM reference designs all use a special flash image format
that stores a footer (two versions exist) at the end of the last
erase block of the image in flash memory.

Version one of the footer is indicated by the magic number
0xA0FFFF9F at 12 bytes before the end of the flash block and
version two is indicated by the magic number 0x464F4F54 0x464C5348
(ASCII for "FLSHFOOT") in the very last 8 bytes of the erase block.

This command driver implements support for both versions of the
AFS images (the name comes from the Linux driver in drivers/mtd/afs.c)
and makes it possible to list images and load an image by name into
the memory with these commands:

afs - lists flash contents
afs load <image> - loads image to address indicated in the image
afs load <image> <addres> - loads image to a specified address

This image scheme is used on the ARM Integrator family, ARM
Versatile family, ARM RealView family (not yet supported in U-Boot)
and ARM Versatile Express family up to and including the new
Juno board for 64 bit development.

Reviewed-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2015-04-10 11:54:08 -04:00
Tom Rini
ffb96d55d1 Merge branch 'master' of git://git.denx.de/u-boot-fdt 2015-04-10 11:54:07 -04:00
Tom Rini
59064346dd Merge branch 'master' of git://git.denx.de/u-boot-arm 2015-04-10 11:54:07 -04:00
Stefan Agner
6d0f452608 common, ubi: use positive return values for ubi check
The ubi check command is expected to not fail and just check whether
a volume exist or not. Currently, when a volume does not exist, the
command fails which leads to an error:
"exit not allowed from main input shell."

Use 1 to indicate that a volume does not exist. This allows to use
ubi check in an if statement, e.g.
if ubi check rootfs; then; echo "exists"; else; echo "not there"; fi
2015-04-10 11:54:06 -04:00
Alexey Brodkin
89576072cb arc: make sure _start is in the beginning of .text section
This is important to have entry point in the beginning of .text section
because it allows simple loading and execution of U-Boot.

For example pre-bootloader loads U-Boot in memory starting from offset
0x81000000 and then just jumps to the same address.

Otherwise pre-bootloader would need to find-out where entry-point is. In
its turn if it deals with binary image of U-Boot there's no way for
pre-bootloader to get required value.

Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
2015-04-10 18:45:34 +03:00
Simon Glass
4bde2e9d60 fdt: nios: Fix warning in ft_cpu_setup()
This function should not return a value.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Thomas Chou <thomas@wytron.com.tw>
2015-04-10 08:15:24 -06:00
Albert ARIBAUD \(3ADEV\)
412ae53aad lpc32xx: add support for board work_92105
Work_92105 from Work Microwave is an LPC3250-
based board with the following features:
- 64MB or 128MB SDR DRAM
- 1 GB SLC NAND, managed through MLC controller.
- Ethernet
- Ethernet + PHY SMSC8710
- I2C:
  - EEPROM (24M01-compatible)
  - RTC (DS1374-compatible)
  - Temperature sensor (DS620)
  - DACs (2 x MAX518)
- SPI (through SSP interface)
  - Port expander MAX6957
- LCD display (HD44780-compatible), controlled
  through the port expander and DACs

This board has SPL support, and uses the LPC32XX boot
image format.

Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
2015-04-10 14:23:39 +02:00