Currently, IECTRL is enabled after pin-mux settings for the low-level
debugging for PH1-LD4 and PH1-sLD8. While IECTRL is disabled, input
signals are pulled-down, i.e. glitch signal (Low to High transition)
problem occurs if pin-mux is set up first. As a result, one invalid
character is input to the UART block and the auto-boot counting is
terminated immediately.
The correct initialization procedure is:
[1] Enable IECTRL (if IECTRL exists for the pins)
[2] Set up pin-muxing
[3] Deassert the reset of the hardware block
Currently, the low-level debugging is working for PH1-sLD3 and
PH1-Pro4, but just in case, follow the sequence for all the SoCs.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I want these prefixed with CONFIG_ARCH_UNIPHIER_ to clarify
they belong to UniPhier SoC family.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It is no longer necessary to define CONFIG_SUPPORT_CARD_* globally.
Move them to a C file as local macros. Also, rename the C file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The macro, led_write(), is now only used in C sources. There is no
more reason to keep the tricky assembly macro. Replace it with a
new C function led_puts().
Also, rename board.h to micro-support-card.h.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The wrapper functions, uniphier_board_*, are just making function
calls complex. Remove them.
Also, use empty inline functions in case CONFIG_MICRO_SUPPORT_CARD
is disabled, so that prototype checking works.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Device tree specifies the available memory ranges in its "/memory"
node. Use it to simplify the CONFIG defines.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
To achieve the complete run-time configuration by device trees, ifdef
conditionals in header files are not preferable.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
In UniPhier SoCs before ProXstream2 and PH1-LD6b, two address spaces
0x00000000 - 0x0fffffff
0x40000000 - 0x4fffffff
are both mapped to the external bus (also called system bus),
so either was OK.
In the newest two SoCs, the former (0x00000000 - 0x0fffffff) is
assigned for the serial NOR interface.
Going forward, use the latter for the external bus.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Historically (for compatibility with very old platforms), two
different types of micro support cards have been used with the
UniPhier SoC development boards. It has been painful to maintain
both. Having one of them is enough.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
These input enable settings are handled by the pinctrl drivers.
Because the external bus pins are input-enabled by default, on-board
devices such as LED still work fine even with this delayed input
enabling.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
As the UniPhier serial driver had already switched to Drive Model
and the pinctrl drivers are now enabled, these pin-muxing settings
are properly handled by the pinctrl drivers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add "u-boot,dm-pre-reloc" for device nodes we want in SPL DTB
(spl/u-boot-spl.dtb).
The "soc" node (this is simple-bus node) also needs the property
to bind the pinctrl node located under it.
I am collecting this U-Boot specific hack to the bottom of board
DTS rather than inserting "u-boot,dm-pre-reloc" into SoC DTSI.
My goal is to sync DTSI with Linux for easier maintenance.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence"). The Tegra114 TRM doesn't contain this information, but
the programming of PLLC is the same on Tegra114 and Tegra124.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Enabling a PLL while IDDQ is high. The Linux kernel checks for this
condition and warns about it verbosely, so while this seems to work
fine, fix it up according to the programming guidelines provided in
the Tegra K1 TRM (v02p), Section 5.3.8.1 ("PLLC and PLLC4 Startup
Sequence").
Reported-by: Nicolas Chauvet <kwizart@gmail.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Add the device tree node for the SPI controllers found on Tegra20 SOCs.
Signed-off-by: Mirza Krak <mirza.krak@hostmobility.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
While clk_m and the oscillator run at the same frequencies on Tegra114
and Tegra124, clk_m is the proper source for the architected timer. On
more recent Tegra generations, Tegra210 and later, both the oscillator
and clk_m can run at different frequencies. clk_m will be divided down
from the oscillator.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
On currently supported SoCs, clk_m always runs at the same frequency as
the oscillator input. However newer SoC generations such as Tegra210 no
longer have that restriction. Prepare for that by separating clk_m from
the oscillator clock and allow SoC code to override the clk_m rate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Some platforms have the means to determine the counter frequency at
runtime, so give them an opportunity to do so.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
AFAIK, for all PLLs on all Tegra SoCs, the primary PLL output frequency
is (input * m) / (n * p). However, PLLP's primary output (pllP_out0) on
T210 is the VCO output, and divp is not applied. pllP_out2 does have divp
applied. All other pllP_outN are divided down from pllP_out0. We only
support pllP_out0 in U-Boot at the time of writing.
Fix clock_get_rate() to handle this special case.
This corrects the returned rate for PLLP to be 408MHz rather than 204MHz.
In turn, this causes high enough dividers to be calculated for the various
peripheral clocks that feed off of PLLP. Without this, some peripherals
failed to operate correctly. For instance, one of my SD cards worked
perfectly but an older (presumably slower) card could not be read.
Note that prior to commit 722e000ccd "Tegra: PLL: use per-SoC pllinfo
table instead of PLL_DIVM/N/P, etc.", the calculated PLL frequency was
816MHz since the wrong values were being extracted from the PLLP divider
register. This caused overly large peripheral dividers to be calculated,
which while wrong, didn't cause any correctness issues; things simply ran
slower than they could.
Reported-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This function is deleted by commit 2fccd2d96b
"tegra: Convert tegra GPIO driver to use driver model".
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
P2371-2180 is a P2180 CPU board married to a P2597 I/O board. The
combination contains SoC, DRAM, eMMC, SD card slot, HDMI, USB
micro-B port, Ethernet via USB3, USB3 host port, SATA, PCIe, and
two GPIO expansion headers.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Commit 0abdd9d0 "arm: Remove nhk8815 boards and nomadik arch" missed one
reference to this arch. Lets remove this as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
This arch does not seem to be supported / used at all in the current
U-Boot mainline source tree any more. So lets remove the core u8500 code
and code that was only referenced by this platform.
Please note that this patch also removes these config options:
- CONFIG_PL011_SERIAL_RLCR
- CONFIG_PL011_SERIAL_FLUSH_ON_INIT
As they only seem to be referenced by u8500 based boards. Without any
such board in the current code, these config option don't make sense
any more. Lets remove them as well.
If someone still wants to use this platform, then please send patches
to re-enable support by adding at least one board that references this
code.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: John Rigby <john.rigby@linaro.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It is not very useful to have the message below on every boot
(especially when we are using early silicon):
U-Boot 2015.10-rc2-23945-g37cf215 (Sep 08 2015 - 14:12:14 -0300)
CPU: Freescale i.MX6UL rev1.0 792 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C)CPU: Thermal invalid data, fuse: 0x0
- invalid sensor device
, so turn the error message into debug level.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Discard the 'select CPU_V7' from Kconfig in arch/arm/cpu/armv7/mx6
for different targets, because ARCH_MX6 selects CPU_V7.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
This patch is to support mx6ul_9x9_evk board based on mx6ul_14x14_evk,
the difference between mx6ul 9x9 evk and mx6ul 14x14 evk are:
1. mx6ul 9x9 evk use pfuze3000, while mx6ul 14x14 evk use DCDC.
2. mx6ul 9x9 evk supports 256MB LPDDR2, while mx6ul 14x14 evk
supports 512MB DDR3
3. mx6ul_9x9_evk use 9x9 package, while mx6ul_14x14_evk use 14x14 package.
This patch add the following:
1. Discard PHYS_SDRAM_SIZE from header file, use imx_ddr_size()
2. Introduce a macro is_mx6ul_9x9_evk using
CONFIG_IS_ENABLED(TARGET_MX6UL_9X9_EVK) to avoid "#ifdef xxx" in non-SPL
part. To SPL part, CONFIG_IS_ENABLED(TARGET_MX6UL_9X9_EVK) can not work,
so still use "#ifdef CONFIG_TARGET_MX6UL_9X9_EVK" to differentiate with
mx6ul_14x14_evk. And we have no way to dymaically checking this chip
is 9x9 or 14x14.
3. mx6ul_9x9_evk use pfuze3000, so enabled POWER related configurations.
POWER related configurations also effect for mx6ul_14x14_evk. But
power_init_board implementation using 'if (is_mx6ul_9x9_evk())' to
do initialization for mx6ul_9x9_evk, and do nothing for mx6ul_14x14_evk.
4. mx6ul_9x9_evk use lpddr2 with size 256MB, so add related SPL DRAM
configurations.
5. Enable CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG and setting dtb file
according to board_rev and board_name.
6. Add TARGET_MX6UL_9X9_EVK Kconfig entry
Boot Log:
U-Boot SPL 2015.10-rc2-00356-g536ce34 (Sep 06 2015 - 12:22:53)
reading u-boot.img
reading u-boot.img
U-Boot 2015.10-rc2-00356-g536ce34 (Sep 06 2015 - 12:22:53 +0800)
CPU: Freescale i.MX6UL rev1.0 792 MHz (running at 396 MHz)
CPU: Commercial temperature grade (0C to 95C) at 41C
Reset cause: POR
Board: MX6UL 9x9 EVK
I2C: ready
DRAM: 256 MiB
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
MMC: FSL_SDHC: 0, FSL_SDHC: 1
In: serial
Out: serial
Err: serial
Net: FEC1
Hit any key to stop autoboot: 0
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
This reverts commit 059323fb6a8f21637bb617919715c2427f24777c.
This commit 059323fb6a8f21637bb617919715c2427f24777c use JESD79-3E which
is not the newest spec. Should use JESD79-3F in which tRFC is 260ns for
4Gb chip.
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Add imx-common cpu support for imx7d SoC
- Update reset_cause for imx7d
- Enable watchdog driver built for imx7d
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Extend init_aips to support imx7 SoC, use is_soc_type
and is_cpu_type to resolve at run time aips3 settings
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Add imx7d basic SoC system support
Misc arch dependent functions for system bring up
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Signed-off-by: Ye.Li <B37916@freescale.com>
* Add Clock control module (CCM) support
* iMX7D SoC introduces 3 main clock sysmtem abstraction for clock
root frequency generation denominated clock slices.
Core clock slice: hihg speed clock for ARM core
Bus clock slice: for bus clocks
IP clock slice: Peripheral clocks
* At system boot ROM enables PLL_ARM, PLL_DDR, PLL_SYS, PLL_ENET
In u-boot, we have to:
- Configure PFD3- PFD7 for freq we needed in u-boot
- Set clock root for peripherals (ip channel)
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Signed-off-by: Ye.Li <B37916@freescale.com>
* Add system arch level header files
- imx-regs.h: iMX7D SoC system architecture registers
- crm_regs.h: Clock control module registers
- sys_proto.h: helper callback function for SoC setup
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
Signed-off-by: Ye.Li <B37916@freescale.com>
Add system counter driver for imx7d and mx6ul
imx7 and imx6ul supports system counter timer as well as
GPT timer (arch/arm/imx-common/timer.c); The default for
imx7 is systemcounter timer.
Signed-off-by: Ye.Li <B37916@freescale.com>
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Move common imx6 arch init setup, init.c can be extended
and reused to support imx7 SoC keeping init arch common
code.
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Rework cache settings for imx6, move cache configuration
to imx-common/cache.c so it can be reused for newer SoC
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Rework imx_thermal driver to be used across i.MX
processor that support thermal sensor
Signed-off-by: Adrian Alonso <aalonso@freescale.com>
Signed-off-by: Peng Fan <Peng.Fan@freescale.com>
The current simplify lpc32xx gpio driver implementation assume a
maximum of 32 GPIO per port; there are a total of 22 GPI, 24 GPO
and 6 GPIO to managed on port 3.
Update the driver to fix the following:
1) When requesting GPI_xx and GPO_xx on port 3 (xx is the same number)
the second call to "gpio_request" will return -EBUSY.
2) The status of GPO_xx pin report the status of the
corresponding GPI_xx pin when using the "gpio status" command.
3) The gpio driver may setup the direction register for the wrong
gpio when calling "gpio_direction_input" (GPI_xx) or
"gpio_direction_output" (GPO_xx) on port 3; the call to the
direction is require to use the "gpio status" command.
The following change were done in the driver:
1) port3 GPI are cache in a separate 32 bits in the array.
2) port3 direction register written only for GPIO pins.
3) port3 GPO & GPIO (as output) are read using "p3_outp_state".
4) LPC32XX_GPI_P3_GRP updated to match the change.
Signed-off-by: Sylvain Lemieux <slemieux@tycoint.com>
introduce BIT() definition, used in at91_udc gadget
driver.
Signed-off-by: Heiko Schocher <hs@denx.de>
[remove all other occurrences of BIT(x) definition]
Signed-off-by: Andreas Bießmann <andreas.devel@googlemail.com>
Acked-by: Stefan Roese <sr@denx.de>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add support for Lightwriter SL50 series board, a small, robust and portable
Voice Output Communication Aids (VOCA) designed to meet the particular and
changing needs of people with speech loss resulting from a wide range of
acquired, progressive and congenital conditions.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
This patch adds the "nandecc" command to switch between the SPEAr600 internal
1-bit HW ECC and the 4-bit SW BCH4 ECC. This can be needed to support NAND
chips with a stronger ECC than 1-bit, as on the x600. And to dynamically
switch between both ECC schemes for backwards compatibility.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
