Age | Commit message (Collapse) | Author |
|
As the AS3722 GPIO0 is also a not connected on our Apalis TK1 module
explicitly configure it to high-impedance as well.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
|
|
Use a slower speed of 10 kbit/s for DDC to improve reliability.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
|
|
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
|
|
The OCRAM_S alias for Cortex-M4's system bus is missing. Add
the alias so that firmwares which have code linked in that
area can be loaded successfully.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Brandon Shibley <brandon.shibley@toradex.com>
|
|
Make sure TPS62362 set 0 defaults to 1.200V as the Linux kernel may
switch to set 0 using TPS65911 GPIO1 (EN_CORE_DVFS_N) connected to
TPS62362 VSEL1 prior to actually setting it to a sane value dependent on
the current CPU frequency.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Stefan Agner <stefan.agner@toradex.com>
|
|
Use i.MX bootaux support introduced for i.MX 6SoloX/i.MX 7 for
Vybrid too. Starting the Cortex-M4 core on Vybrid works a bit
differently, namely it uses a GPR register to define the initial
PC. There is no way to define the initial stack (the stack is
set up in a boot ROM). This is not a problem for most firmwares
since the firmwares startup code reinitialize the stack as part
of the firmware startup code anyway.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
Move Freescale/NXP Vybrid to a standard arch/board approach, similar
to what has been done to i.MX 6 earlier in commit 89ebc82137be ("ARM:
mx6: move to a standard arch/board approach").
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
Support elf firmware files for the auxiliary Cortex-M4 core. This
has the advantage that the user does not need to know to which
address the binary has been linked to. However, in order to load
the elf sections to the right address, we need to translate the
Cortex-M4 core memory addresses to primary/host CPU memory
addresses (U-Boot is typically running on the A7/A9 core). This
allows to boot firmwares from any location with just using
bootaux, e.g.:
tftp ${loadaddr} low_power_demo.elf && bootaux ${loadaddr}
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
For i.MX 6SoloX/i.MX 7 simple binary files are used to boot the
auxiliary CPU core (Cortex-M4). This patch moves the "parsing" of
this binary firmwares to the SoC independent code. This allows to
add different binary formats more easily.
While at it, also move the comment about the inner workings how
to boot the Cortex-M4 core to a more appropriate location.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
|
|
Before commit 81c4eccb55cc ("imx: mx6: fix USB bmode to use
reserved value") a non-reserved value has been used to trigger
Serial Downloader using bmode. On some boards this value lead to
unreliable bmode command. With the above mentioned commit, U-boot
switched to use [7:4] b0001, which translates to GPR9 0x10 for
Serial Downloader mode. Check for this new bmode and classify it
as Serial Downloader.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
When starting i.MX SoC's with BOOT_MODE b01, the boot ROM enteres
Serial Downloader mode. However, serial download does not necessarily
means booting from UART. The boot ROM also supports booting from USB.
Create a technology neutral boot mode called SDP (serial download
protocol).
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Fix the following boot hang observed when booting our downstream L4T
R16.5 based BSP:
[ 0.900129] kernel BUG at /build/linuxdev/oe-core_V2.7/build/tmp-
glibc/work-shared/colibri-t20/kernel-source/drivers/spi/spi-tegra.c:258!
[ 0.912478] Internal error: Oops - undefined instruction: 0 [#1]
PREEMPT SMP
[ 0.919525] Modules linked in:
[ 0.922586] CPU: 0 Not tainted (3.1.10-v2.7b1+g7e628fd #1)
[ 0.928428] PC is at spi_tegra_isr.part.0+0x14/0x18
[ 0.933310] LR is at spi_tegra_isr+0x38/0x7c
[ 0.937580] pc : [<c05c25e8>] lr : [<c0334d4c>] psr: 60000193
[ 0.937585] sp : c8075c40 ip : c8075c50 fp : c8075c4c
[ 0.949062] r10: c08a2f20 r9 : c08a2f74 r8 : 00000000
[ 0.954285] r7 : c8074000 r6 : c81545c0 r5 : c08a2f74 r4 : c81545b0
[ 0.960810] r3 : 00000000 r2 : 00000001 r1 : 60000193 r0 : 60000193
[ 0.967336] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 0.974734] Control: 10c5387d Table: 0000404a DAC: 00000015
While at it also fix the following clock initialisation related errors:
[ 0.000000] tegra_dvfs: rate 216000000 too high for dvfs on sdmmc1
[ 0.000000] Unable to set clock sdmmc1 to rate 48000000: -22
[ 0.000000] tegra_dvfs: rate 216000000 too high for dvfs on sdmmc3
[ 0.000000] Unable to set clock sdmmc3 to rate 48000000: -22
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Just release TPS65911 GPIO1 (EN_CORE_DVFS_N) connected to TPS62362
VSEL1 to switch VDD_CORE back to boot set 1 defaulting to 1.200V.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 622d408fea7af6d2ed778b546de346e90ea1a21f)
|
|
Implement early TPS6586X PMIC rail configuration setting SM0 being
VDD_CORE_1.2V to 1.2 volts and SM1 being VDD_CPU_1.0V to 1.0 volts.
While those are PMIC power-up defaults the SoC might have been reset
separately with certain rails being left at lower DVFS states which
is e.g. the case upon watchdog reset while otherwise nearly idling.
(cherry picked from commit f7c3186985ebb244d075b04ed7c055f39f485670)
|
|
Enable the display driver on Apalis T30. Unfortunately the PWM pin
muxing wasn't any good neither which made that display stay dark.
(cherry picked from commit 2da21c1d130fa11a5bd9876c8e72fa0d57585106)
|
|
On popular request enable the display driver on Colibri T30. A few
notes about some things encountered during porting: While analogue VGA
(e.g. via the on-carrier RAMDAC) worked just fine from the beginning
the EDT display flickered like crazy which turned out to be a pin
muxing issue. Unfortunately the PWM pin muxing wasn't any good neither
which made that display stay dark. Enjoy.
(cherry picked from commit 201cc6d4e4c8213fbd103e74b0f2f2ca591edf54)
|
|
On popular request make the display driver from T20 work on T30 as
well. Turned out to be quite straight forward. However a few notes
about some things encountered during porting: Of course the T30 device
tree was completely missing host1x as well as PWM support but it turns
out this can simply be copied from T20. The only trouble compiling the
Tegra video driver for T30 had to do with some hard-coded PWM pin
muxing for T20 which is quite ugly anyway. On T30 this gets handled by
a board specific complete pin muxing table. The older Chromium U-Boot
2011.06 which to my knowledge was the only prior attempt at enabling a
display driver for T30 for whatever reason got some clocking stuff
mixed up. Turns out at least for a single display controller T20 and
T30 can be clocked quite similar. Enjoy.
(cherry picked from commit 5a472ddd7a2a017747d6c05c65eba2cd3804c02f)
|
|
Add a comment about the disabled PCIe port nodes.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
(cherry picked from commit f0adaf95b3edd1e8e23ebb0feab1f86eb77c9d84)
|
|
Fix ULPI reset polarity which caused a hard hang on Colibri T20 upon
attempting to start the USB subsystem:
This fixes my late commit d5a24d8b53d350364bd429b7104ec369b817e4b8
(colibri_t20: fix usb operation and controller order) inadvertently
having overwritten Stephen's previous commit
2f6a7e8ce5df8b99d84bfd486c6f99d92322ce04 (ARM: tegra: fix USB ULPI PHY
reset signal inversion confusion).
While at it also fix comment about on-module USB port.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
(cherry picked from commit 3f33bd299fd438a04d37c3c25af1ab02a9b0d2f9)
|
|
Fix the following boot hang observed when booting our downstream L4T
R16.5 based BSP:
[ 4.174349] tegra_dvfs: rate 408000000 too high for dvfs on sbc1
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Migrating our BSPs towards mainline U-Boot I noticed it suddenly booting
slower. With mainline Linux I noticed about a 1 to 2 second increase
while booting downstream L4T takes 10 to 15 seconds longer!
This reverts commit 858530a8c0a7ce7e573e513934804a00d6676813.
Conflicts:
drivers/serial/Makefile
(cherry picked from commit 752aae30a791326581efafbb761c0cebaba8d3ea)
Conflicts:
drivers/serial/serial_tegra.c
include/configs/tegra-common.h
(cherry picked from commit 4b97c4173ef96cfa4eb3ba4ea9121320efa90091)
|
|
Not all Vybrid boards are using the new Vybrid image format, only
add it as default target for boards which make use of it.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Add proper reg values for the two AIPS bus nodes. This avoids this
two warnings:
Node /soc/aips-bus@40000000 has a unit name, but no reg property
Node /soc/aips-bus@40080000 has a unit name, but no reg property
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
The Vybrid SoC family has the same display controller unit (DCU)
like the LS1021A SoC. This patch adds platform data, pinmux defines
and clock control to enable the driver for Vybrid based boards too.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
|
|
Add declaration for arch_auxiliary_core_check_up which can be useful
to add board specific behavior.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Code mostly ported from imx-kobs-5.3.
MTD partitioning is set accordingly.
writebcb: Write Boot Control Block (FCB and DBBT)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
[ported to U-Boot 2016.11]
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Add writebcb command which creates a NAND Boot Configuration Block
(BCB) at the beginning of the active flash device. The BCB stores
the information for the SoC internal boot ROM where the application
with a valid IVT header can be found on the NAND device. The first
two argument of the command need an offset of the NAND device where
the primary and secondary application can be found.
Typically, U-Boot is the application which gets loaded by the boot
ROM. Hence, the offset address need to be the address where U-Boot
(u-boot.imx along with a 0x400 long prefix) is stored on the device.
At least one location is mandatory.
Currently only the FCB (Firmware Configuration Block) is written to
the device. The DBBT (Discovered Bad Block Table) is optional and
not created by writebcb currently.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This patch is a porting of
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_4.1.15_1.0.0_ga&id=e4dacc44d22e9474ec456cb330df525cd805ea38
"
i.MX6QP and i.MX7D BCH module integrated a new feature to detect the
bitflip number for erased NAND page. So for these two platform, set the
erase threshold to gf/2 and if bitflip detected, GPMI driver will
correct the data to all 0xFF.
Also updated the imx6qp dts file to ditinguish the GPMI module for i.MX6Q
with the one for i.MX6QP.
"
In this patch, i.MX6UL is added and threshold changed to use ecc_strength.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
|
|
Add an additional target which prepends the u-boot.imx image with
0x400 padding bytes. On Vybrid and i.MX 7, this is required for
NAND boot devices. The configuration CONFIG_IMX_NAND enables this
image for a board.
[ported to v2016.11]
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock
loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0
register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This patch adds board support for the Toradex Apalis TK1 a computer on
module which can be used on different carrier boards.
The module consists of a Tegra TK1 SoC, a PMIC solution, 2 GB of DDR3L
RAM, a bunch of level shifters, an eMMC, a TMP451 temperature sensor
chip, an I210 gigabit Ethernet controller and a SGTL5000 audio codec.
Furthermore, there is a Kinetis MK20DN512 companion micro controller for
analogue, CAN and resistive touch functionality.
For the sake of ease of use we do not distinguish between different
carrier boards for now as the base module features are deemed
sufficient enough for regular booting.
The following functionality is working so far:
- eMMC boot, environment storage and Toradex factory config block
- Gigabit Ethernet
- MMC/SD cards (both MMC1 as well as SD1 slot)
- USB client/host (dual role OTG port as client e.g. for DFU/UMS or host,
other two ports as host)
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Max Krummenacher <max.krummenacher@toradex.com>
|
|
This adds board support for the Toradex module family Colibri iMX6.
The familiy consists of a module with i.MX6 DualLite, i.MX6 Solo, both
with a version for commercial and industrial temperature range.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit a02d517b0182f83771565eba1329fb323674ec58)
|
|
This adds board support for the Toradex module family Apalis iMX6.
The familiy consists of a module with i.MX6 Dual, i.MX6 Quad with
commercial and industrial temperature range.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 592f4aed6db765172e21f228800b49f9a27ff201)
|
|
The ipu has two display interfaces. Make the used one a parameter
in struct display_info_t instead of using unconditionally DI0.
DI0 is the default setting.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Eric Nelson <eric@nelint.com>
(cherry picked from commit 15fde0fc11f93f19f40c9cda36e7c8d4848d9c75)
|
|
Update the spi-max-frequency property of m25p80 flash slave to match
that of TI QSPI controller node, so that QSPI operations happen at
maximum supported frequency of 76.8MHz.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
Update the PLL initialization sequence to avoid glitches while
programming. User guide for the same is available at[1].
[1] http://www.ti.com/lit/ug/sprugv2h/sprugv2h.pdf
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
While we setup the mmu initially we mark set_section_dcache with
DCACHE_OFF flag. In case of non-LPAE mode the DCACHE_OFF macro
is rightly defined with TTB_SECT_XN_MASK set so as to mark all the
4GB XN. In case of LPAE mode XN(Execute-never) bit is not set with
DCACHE_OFF. Hence XN bit is not set by default for DCACHE_OFF which
keeps all the regions execute okay and this leads to random speculative
fetches in random memory regions which was eventually caught by kernel
omap-l3-noc driver.
Fix this to mark the regions as XN by default.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
Printing the option value in hex makes it more comprehensible.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
|
|
|
|
An SMC call is required for all cache-wide operations on Tegra186. This
patch implements the two missing hooks now that U-Boot supports them, and
fixes the mapping of "hook name" to SMC call code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
SoC-specific logic may be required for all forms of cache-wide
operations; invalidate and flush of both dcache and icache (note that
only 3 of the 4 possible combinations make sense, since the icache never
contains dirty lines). This patch adds an optional hook for all
implemented cache-wide operations, and renames the one existing hook to
better represent exactly which operation it is implementing. A dummy
no-op implementation of each hook is provided.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
When performing a cache disable function, code must not access DRAM.
That is because when the cache is disabled, it will be bypassed and all
loads and stores will be serviced by RAM. This prevents accessing any
dirty data in the cache. In turn, this means the stack cannot be
used, since that is in RAM. To guarantee that code doesn't use RAM (and
in particular the stack) __asm_flush_l3_cache() must be manually
implemented in assembly, rather than implemented in C since the compiler
won't know not to touch RAM.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
nvtboot_boot_x0 is a 64-bit variable and hence must be 64-bit aligned.
So far this has happened by accident! Fix the code so this is guaranteed.
This fixes the following build error:
... relocation truncated to fit: R_AARCH64_LDST64_ABS_LO12_NC
against symbol `nvtboot_boot_x0' ...
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Enable the Ethernet device in DT, provide board-specific configuration,
and enable the driver in Kconfig.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Tegra186 includes a Synopsys DWC EQoS (Ethernet) device. Add this to the
Tegra186 SoC DT so that boards can make use of it.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
On Tegra186, the bootloader which runs before U-Boot passes the Ethernet
MAC address to U-Boot using device tree. Extract this value and write it
to the environment, so that the Ethernet uclass picks it up and uses it
for the built-in Ethernet device.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Extend the Tegra186 implementation of board_late_init() to call a per-SoC
"hook" function. This will allow SoC-specific (rather than Tegra-wide)
functionality to be implemented without the core Tegra code needing to be
aware of the details. While board186.c is currently only used for
Tegra186, it should be applicable to any other future SoC, and perhaps its
simple design could be back-ported to older SoCs in the future too.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
For 64-bit ARM systems we provide just a timer_read_counter()
implementation and rely on the generic non-uclass get_ticks() function
in lib/time.c to call the former.
However this function is actually not 64-bit safe, as it assumes a
"long" to be 32-bit. Beside the fact that the resulting uint64_t
isn't bigger than "long" on 64-bit architectures and thus combining two
counters makes no sense, we get all kind of weird results when we try
to OR in the high value shifted by _32_ bits.
So let's avoid that function at all and provide a straight forward
get_ticks() implementation for ARMv8, which also is in line with ARMv7.
This fixes occasional immediate time-out expiration issues I see on the
Pine64 board. The root cause of this needs to be investigated, but this
fix looks like the right thing anyway.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
|
|
|
|
Cover-Letter: Fixes several spelling errors for the words "resetting",
"extended", "occur", and "multiple".
Signed-off-by: Vagrant Cascadian <vagrant@debian.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
|