The TTBR0 register and Table Descriptors of the ARMv7 TLB weren't being
properly set to allow for the configuration specified caching modes to
be active over DRAM. This commit fixes those issues.
Signed-off-by: Bryan Brinsko <bryan.brinsko@rockwellcollins.com>
This enables ARMv7 barrier operations support when
march=armv7-a is enabled.
Using CP15 barriers causes U-Boot bootm command crash when
transferring control to the loaded image on Renesas R8A7794 Cortex A7 CPU.
Using ARMv7 barrier operations instead of the deprecated CP15 barriers
helps to avoid these issues.
Signed-off-by: Valentine Barshak <valentine.barshak+renesas@cogentembedded.com>
Signed-off-by: Vladimir Barinov <vladimir.barinov+renesas@cogentembedded.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Linux-arm64 require that CNTVOFF_EL2 should be programmed with
a consistent value on all cpus. Initializing CNTVOFF_EL2 at state
transition instead of start.S could prevent potential different value
on cpus if ATF exist and u-boot runs at only one cpu.
Signed-off-by: David Feng <fenghua@phytium.com.cn>
This commit copies implementation of the find_next_zero_bit() from
git://git.denx.de/u-boot.git/arch/mips/include/asm/bitops.h. v2014.07
The function is required to enable MCAST_TFTP support for ARM platforms.
Signed-off-by: Vitaly Andrianov <vitalya@ti.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in am43xx board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Implemented board_usb_init(), board_usb_cleanup() and
usb_gadget_handle_interrupts() in dra7xx board file that
can be invoked by various gadget drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Added resource_size_t type in order to get rid of the following
compilation error whiel building dwc3 gadget.
include/linux/ioport.h:19:2: error: unknown type name ‘resource_size_t’
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Added dma_free_coherent corresponding to the dma_alloc_coherent in
dma-mapping.h in order to free memory allocated using dma_alloc_coherent.
This API is used in dwc3 driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
Fixed the following warning here.
"warning: ‘dma_alloc_coherent’ defined but not used" while compiling
udc-core
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Lukasz Majewski <l.majewski@samsung.com>
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>
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>
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>
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.htmlhttp://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/215038https://www.mail-archive.com/u-boot@lists.denx.de/msg166568.html
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
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>
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>
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>
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>
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>
The controller's Reed-Solomon ECC hardware is
used except of course for raw reads and writes.
It covers in- and out-of-band data together.
The SPL framework is supported.
Signed-off-by: Albert ARIBAUD (3ADEV) <albert.aribaud@3adev.fr>
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>
Move the MX5 based boards to arch/arm/cpu/armv7/mx5, following the
commit: 89ebc82137
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>
Back in fc46bae a "clean up" was introduced that intended to reconcile
some of the AM335x codepaths based on how AM43xx operates.
Unfortunately this introduced a regression on the DDR2 platforms. This
was un-noticed on DDR3 (everything except for Beaglebone White) as we
had already populated sdram_config correctly in sequence. This change
brings us back to the older behavior and is fine on all platforms.
Tested on Beaglebone White, Beaglebone Black and AM335x GP EVM
Reported-by: Matt Ranostay <mranostay@gmail.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Add backlight enable GPIO, and delay needed for panel powerup
via FIMD DT node.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Now that parade driver supports reading SLP and RST GPIO
from DT, specify the same in parade DT node.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Now that the exynos_fb driver supports handling backlight GPIO
via DT, specify pwm output property via FIMD DT node.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
The existing setting for rpll_sdiv generates 70.5Mhz RPLL
video clock to drive 1366x768 panel on peach_pit.
This clock rate is not sufficient to drive 1920x1080 panel on peach-pi.
So, we adjust rpll_sdiv to 3 so that it generates 141Mhz pixel clock
which can drive peach-pi LCD.
This change doesn't break peach-pit LCD since 141/2=70.5Mhz, i.e FIMD
divider at IP level will get set to 1(the required divider setting
will be calculated and set by exynos_fimd_set_clock()) and hence
peach-pit LCD still works fine.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5800 needed by
exynos video driver.
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Commit 2e82e92526 'Exynos: Clock: Cleanup
soc_get_periph_rate' introduced a bug in I2C config. This patch makes cros_ec
keyboard working again on Samsung Chromebook (snow).
Changes in V2: reorder lines as requested by Joonyoung Shim.
Signed-off-by: Guillaume GARDET <guillaume.gardet@free.fr>
Cc: Akshay Saraswat <akshay.s@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Reviewed-by: Simon Glass <sjg@chroimum.org>
Tested-by: Simon Glass <sjg@chroimum.org>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
ARCv2 cores may have built-in SLC (System Level Cache, AKA L2-cache).
This change adds functions required for controlling SLC:
* slc_enable/disable
* slc_flush/invalidate
For now we just disable SLC to escape DMA coherency issues until either:
* SLC flush/invalidate is supported in DMA APIin U-Boot
* hardware DMA coherency is implemented (that might be board specific
so probably we'll need to have a separate Kconfig option for
controlling SLC explicitly)
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Now when all infrastructure in ARC is ready for it let's switch ARC UART
to driver model.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Simon Glass <sjg@chromium.org>
[1] Fix misspeling in ARC_CACHE_LINE_SHIFT dependency, now cache-line
lenth selection is correctly enabled if either I$ or D$ are enabled.
[2] Add dummy entry to target list to make sure target type is always
mentioned in defconfig. Otherwise defconfig for the first target in the
list will not have target name and later on with addition of the new
target on top of the list in Kconfig will lead to corrupted
configuration expanded from defconfig.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
As discussed on mailing list we're drifting away from
CONFIG_SYS_GENERIC_GLOBAL_DATA in favour to use of board_init_f_mem()
for global data.
So do this for ARC architecture.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Intention behind this work was elimination of as much assembly-written
code as it is possible.
In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.
It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.
Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
This separation makes maintenance of code easier because those low-level
interrupt- or exception handling routines are pretty static and usually
require not much care while start-up code is a subject of modifications
and enhancements.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Even though ARCompact and ARCv2 are not binary compatible most of
assembly instructions are used in both. With this change we'll get rid
of duplicate code.
Still IVTs are implemented differently so we're keeping them in separate
files.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
always
Make both invalidate_icache_all() and invalidate_dcache_all() available
even if U-Boot is configured with CONFIG_SYS_DCACHE_OFF and/or
CONFIG_SYS_ICACHE_OFF.
This is useful because configuration of U-Boot may not match actual
hardware features. Real board may have cache(s) but for some reason we
may want to run U-Boot with cache(s) disabled (for example if some
peripherals work improperly with existing drivers if data cache is
enabled). So board may start with cache(s) enabled (that's the case for
ARC cores with built-in caches) but early in U-Boot we disable cache(s)
and make sure all contents of data cache gets flushed in RAM.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
