summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* ARM: bcm2835: implement phys_to_bus/bus_to_physStephen Warren2015-04-14-1/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Create API to map between CPU physical and bus addressesStephen Warren2015-04-14-0/+33
| | | | | | | | | | | | | 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>
* usb: dwc2: fix bulk transfersStephen Warren2015-04-14-9/+13
| | | | | | | | | | | | | | | | 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>
* usb: dwc2: remove restriction on buffer lengthStephen Warren2015-04-14-9/+3
| | | | | | | | | | 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>
* usb: dwc2: fix aligned buffer usageStephen Warren2015-04-14-6/+8
| | | | | | | | | | | | | | | 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>
* usb: dwc2: simplify wait_for_chhltdStephen Warren2015-04-14-4/+2
| | | | | | | toggle is never NULL. Simplify the code by removing handling of when it is NULL. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* usb: dwc2: remove control_data_toggle[]Stephen Warren2015-04-14-8/+4
| | | | | | | | 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>
* usb: dwc2: usb chunk_msg() for control transfers tooStephen Warren2015-04-14-95/+19
| | | | | | This removes duplicated code. Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* usb: dwc2: refactor submit_bulk_msg to be commonStephen Warren2015-04-14-16/+39
| | | | | | | | 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>
* usb: dwc2: unify waiting for transfer completionStephen Warren2015-04-14-107/+60
| | | | | | Lift common code out of submit_bulk_msg() and submit_control_msg(). Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
* usb: hub: allow pgood_delay to be specified via envTim Harvey2015-04-14-0/+8
| | | | | | | 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>
* usb: fix first descriptor fetch error handlingStephen Warren2015-04-14-1/+16
| | | | | | | | | | | | | | | | | | 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>
* usb: Early failure when the first descriptor read fails or is invalidPaul Kocialkowski2015-04-14-1/+4
| | | | | | | | 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>
* usb: Check usb_new_device for failurePaul Kocialkowski2015-04-14-4/+10
| | | | | | | 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>
* usb: usb_new_device return codes consistencyPaul Kocialkowski2015-04-14-29/+29
| | | | | | | This makes use of errno return codes for representing error codes in a unified way. Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
* usb_storage:Fix USB storage capacity detection on 64 bit architecturesSergey Temerkhanov2015-04-14-21/+23
| | | | | | | | | | | 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>
* usb: 64-bit architectures support for xHCISergey Temerkhanov2015-04-14-32/+41
| | | | | | | | | 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>
* usb: Convert protocol header structures to use explicitly sized variablesSergey Temerkhanov2015-04-14-9/+9
| | | | | | | | 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>
* usb: mass-storage: Build warning fixes for 64-bitThierry Reding2015-04-14-1/+1
| | | | | | | | | | | 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>
* usb: ehci-tegra: Build warning fixes for 64-bitThierry Reding2015-04-14-4/+4
| | | | | | | | | 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>
* ehci-hcd: fix warnings on 64-bit buildsRob Herring2015-04-14-41/+41
| | | | | | | | 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>
* usb: ci_udc: fix warnings on 64-bit buildsRob Herring2015-04-14-21/+21
| | | | | | | | | | 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>
* usb: eth: asix: Build warning fixes for 64-bitThierry Reding2015-04-14-1/+1
| | | | | | | Fix a type mismatch in a printf format string. Cc: Marek Vasut <marex@denx.de> Signed-off-by: Thierry Reding <treding@nvidia.com>
* usb_storage : scan all interfaces to find a storage deviceFranck Jullien2015-04-14-17/+28
| | | | | | | 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>
* Prepare v2015.04Tom Rini2015-04-13-1/+1
| | | | Signed-off-by: Tom Rini <trini@konsulko.com>
* break build if it would produce broken binaryPavel Machek2015-04-13-0/+4
| | | | | | | 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>
* Merge branch 'master' of git://www.denx.de/git/u-boot-imxTom Rini2015-04-13-3/+693
|\
| * ARM: mx5: add support for USB armory boardAndrej Rosano2015-04-09-0/+670
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Inverse Path USB armory board, an open source flash-drive sized computer based on Freescale i.MX53 SoC. http://inversepath.com/usbarmory Signed-off-by: Andrej Rosano <andrej@inversepath.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Chris Kuethe <chris.kuethe@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: Vagrant Cascadian <vagrant@debian.org> Tested-By: Vagrant Cascadian <vagrant@debian.org> Tested-by: Chris Kuethe <chris.kuethe@gmail.com>
| * ARM: mx5: move to a standard arch/board approachAndrej Rosano2015-04-09-0/+22
| | | | | | | | | | | | | | | | | | | | Move the MX5 based boards to arch/arm/cpu/armv7/mx5, following the commit: 89ebc82137bebb11a8191f8b9cbf08f2533ae8bc Signed-off-by: Andrej Rosano <andrej@inversepath.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Vagrant Cascadian <vagrant@debian.org> Tested-by: Chris Kuethe <chris.kuethe@gmail.com>
| * Fix mxc_hab documenation for DEK blob generationUlises Cardenas2015-04-08-0/+1
| | | | | | | | | | | | | | | | | | | | Include/fsl_sec.h defines sec_in and sec_out, according to the platform's endianess. Therefore, CONFIG_SYS_FSL_LE needs to be declared in the configuration file of the target, in order to use enable the DEK blob generation command. This requirement is not explicit in the README.mxc_hab. Signed-off-by: Ulises Cardenas <Ulises.Cardenas@freescale.com>
| * mx53loco: Disable printing cpuinfoFabio Estevam2015-04-08-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 32df39c741788e ("mx5: fix get_reset_cause") we have the following boot messages on a mx53qsb: U-Boot 2015.04-rc5-00029-gd68df02 (Apr 06 2015 - 11:15:39) CPU: Freescale i.MX53 rev2.1 at 800 MHz Reset cause: POR Board: MX53 LOCO I2C: ready DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 In: serial Out: serial Err: serial CPU: Freescale i.MX53 rev2.1 at 1000 MHz Reset cause: unknown reset Net: FEC [PRIME] The CPU and Reset cause lines appear twice. Initially mx53 boots at 800MHz, then at a later point the PMIC is configured via I2C to raise the CPU voltage so that it can run at 1GHz. To avoid such misleading double printings, disable printing cpu info for now. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Jason Liu <r64343@freescale.com>
* | ARM: rpi: add a couple more revision IDsStephen Warren2015-04-13-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | ARM: fix arch/arm/Makefile for TegraMasahiro Yamada2015-04-11-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 79d75d752717 (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 79d75d752717 *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 e02ee2548afe (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>
* | arm: armada-xp: Fix SPL for AXP by using save_boot_params_retStefan Roese2015-04-11-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge git://git.denx.de/u-boot-arcTom Rini2015-04-10-1/+46
|\ \
| * | arc: fix separate compilation of start.oAlexey Brodkin2015-04-10-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | arc: make sure _start is in the beginning of .text sectionAlexey Brodkin2015-04-10-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | board: axs10x - support v3 mother-boardAlexey Brodkin2015-04-09-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There're 2 versions of motherboards that could be used in ARC SDP. The only important difference for U-Boot is different NAND IC in use: [1] v2 board (we used to support up until now) sports MT29F4G08ABADAWP while [2] v3 board sports MT29F4G16ABADAWP They are almost the same except data bus width 8-bit in [1] and 16-bit in [2]. And for proper support of 16-bit data bus we have to pass NAND_BUSWIDTH_16 option to NAND driver core - which we do now knowing board type we're running on. Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
* | | integrator: consolidate flash infoLinus Walleij2015-04-10-33/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | vexpress64: juno: add default NOR flash bootLinus Walleij2015-04-10-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | common/armflash: Support for ARM flash imagesLinus Walleij2015-04-10-0/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'master' of git://git.denx.de/u-boot-fdtTom Rini2015-04-10-2/+0
|\ \ \
| * | | fdt: nios: Fix warning in ft_cpu_setup()Simon Glass2015-04-10-2/+0
| |/ / | | | | | | | | | | | | | | | | | | This function should not return a value. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Thomas Chou <thomas@wytron.com.tw>
* | | Merge branch 'master' of git://git.denx.de/u-boot-armTom Rini2015-04-10-77/+3653
|\ \ \
| * | | lpc32xx: add support for board work_92105Albert ARIBAUD \(3ADEV\)2015-04-10-1/+1129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | Introduce CONFIG_SPL_PANIC_ON_RAW_IMAGEAlbert ARIBAUD \(3ADEV\)2015-04-10-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | introduce CONFIG_SPL_PANIC_ON_RAW_IMAGE. An SPL which define this will panic() if the image it has loaded does not have a mkimage signature. Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
| * | | lpc32xx: add lpc32xx-spl.bin boot image targetAlbert ARIBAUD \(3ADEV\)2015-04-10-0/+181
| | | | | | | | | | | | | | | | Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
| * | | dtt: add ds620 supportAlbert ARIBAUD \(3ADEV\)2015-04-10-7/+74
| | | | | | | | | | | | | | | | Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
| * | | lpc32xx: add LPC32xx SSP support (SPI mode)Albert ARIBAUD \(3ADEV\)2015-04-10-0/+163
| | | | | | | | | | | | | | | | | | | | Reviewed-by: Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com> Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
| * | | lpc32xx: add GPIO supportAlbert ARIBAUD \(3ADEV\)2015-04-10-0/+349
| | | | | | | | | | | | | | | | | | | | | | | | This driver only supports Driver Model, not legacy model. Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
generated by cgit v1.1 at 2024-11-06 15:16:33 +0000