pekon gupta [Thu, 8 May 2014 16:13:47 +0000 (21:43 +0530)]
ARM: omap: merge GPMC initialization code for all platform
GPMC controller on TI's OMAP SoC is general purpose controller to interface
with different types of external devices like;
- parallel NOR flash
- parallel NAND flash
- OneNand flash
- SDR RAM
- Ethernet Devices like LAN9220
Though GPMC configurations may be different for each platform depending on
clock-frequency and external device interfacing with controller. But
initialization sequence remains common across all platfoms.
Thus this patch merges gpmc_init() scattered in different arch-xx/mem.c
files into single omap-common/mem-common.c
However, actual platforms specific register config values are still sourced
from corresponding platform specific headers like;
AM33xx: arch/arm/include/asm/arch-am33xx/mem.h
OMAP3: arch/arm/include/asm/arch-omap3/mem.h
OMAP4: arch/arm/include/asm/arch-omap4/mem.h
OMAP4: arch/arm/include/asm/arch-omap5/mem.h
Also, CONFIG_xx passed by board-profile decide config for which set of macros
need to be used for initialization
CONFIG_NAND: initialize GPMC for NAND device
CONFIG_NOR: initialize GPMC for NOR device
CONFIG_ONENAND: initialize GPMC for ONENAND device
Signed-off-by: Pekon Gupta <pekon@ti.com>
[trini: define GPMC_SIZE_256M for omap3] Signed-off-by: Tom Rini <trini@ti.com>
pekon gupta [Thu, 8 May 2014 16:13:46 +0000 (21:43 +0530)]
ARM: omap5: add platform specific info for GPMC and ELM controllers
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.
Platform specific information added into arch-xx/../hardware.h
- CPU related platform specific details like base-address of GPMC and ELM
Platform specific information added into arch-xx/../mem.h
- Generic configs for GPMC and ELM initialization.
- Hardware parameters or constrains specific to GPMC and ELM IP like;
number of max number of chip-selects available
pekon gupta [Thu, 8 May 2014 16:13:45 +0000 (21:43 +0530)]
ARM: omap4: add platform specific info for GPMC and ELM controllers
This patch moves platform specific information for GPMC and ELM controller
into separate header files, so that any derivative devices do not mess other
header files.
Platform specific information added into arch-xx/../hardware.h
- CPU related platform specific details like base-address of GPMC and ELM
Platform specific information added into arch-xx/../mem.h
- Generic configs for GPMC and ELM initialization.
- Hardware parameters or constrains specific to GPMC and ELM IP like;
number of max number of chip-selects available
Ash Charles [Wed, 21 May 2014 21:04:52 +0000 (14:04 -0700)]
Add Board Revision for Wireless chip
Gumstix Overo COMs with board revision 0x4 use a different Wifi and
Bluetooth module: Wi2Wi's W2CBW0015. No other code changes are required
in u-boot---just handling of this particular board revision.
Ash Charles [Wed, 21 May 2014 21:04:51 +0000 (14:04 -0700)]
arm: omap3: Fix omap3_overo SPL boot hangup
Patch f33b9bd3
[arm: omap3: Enable clocks for peripherals only if they are used]
breaks SPL booting on Overo. Since some gpio inputs are
read to detect the board revision. But with this patch above, the
clocks to the GPIO subsystems are not enabled per default any more.
The GPIO banks need to be configured specifically now.
The linux kernel is at nand0,3 using the current layout, but is best
accessed through the partition label "linux". Since CONFIG_CMD_MTDPARTS is
defined the CONFIG_JFFS2 settings are unreferenced; use "setenv partition
rootfs" to set the default mtd partition for jffs2.
Signed-off-by: Peter A. Bigot <pab@pabigot.com> Tested-by: Ash Charles <ash@gumstix.com>
Ash Charles [Wed, 21 May 2014 21:04:48 +0000 (14:04 -0700)]
OMAP3: overo: add command support for mtd and ubi
The NAND linux partition format default was changed from jffs2 to ubi in 254973e6df0e48f1a72b67905185c774dcd9f394 but the corresponding commands were
not enabled.
Signed-off-by: Peter A. Bigot <pab@pabigot.com> Tested-by: Ash Charles <ash@gumstix.com>
omap4: allow the use of a plain text env file instead boot scripts
For production systems it is better to use script images since
they are protected by checksums and carry valuable information like
name and timestamp. Also, you can't validate the content passed to
env import.
But for development, it is easier to use the env import command and
plain text files instead of script-images.
Since both OMAP4 supported boards (Panda and TI SDP4430) are used
primarily for development, this patch allows U-Boot to load env var
from a text file in case that an boot.scr script-image is not present.
The variable uenvcmd (if existent) will be executed (using run) after
uEnv.txt was loaded. If uenvcmd doesn't exist the default boot sequence
will be started.
Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Acked-by: Nishanth Menon <nm@ti.com> Signed-off-by: Peter A. Bigot <pab@pabigot.com> Tested-by: Ash Charles <ash@gumstix.com>
Albert ARIBAUD [Tue, 20 May 2014 08:05:42 +0000 (10:05 +0200)]
Merge remote-tracking branch 'u-boot/master'
Conflicts:
boards.cfg
Conflicts were trivial once u-boot-arm/master boards.cfg was
reformatted (commit 6130c146) to match u-boot/master's own
reformatting (commit 1b37fa83).
Albert ARIBAUD [Tue, 20 May 2014 07:31:40 +0000 (09:31 +0200)]
boards.cfg: reformat
Apply command "tools/reformat.py -i -d '-' -s 8 <boards.cfg
>boards0.cfg && mv boards0.cfg boards.cfg" in preparation of
pull request from ARM to main tree.
Liu Gang [Thu, 15 May 2014 06:30:34 +0000 (14:30 +0800)]
powerpc/srio-pcie-boot: Adjust addresses for SRIO/PCIE boot
The new 768KB u-boot image size requires changes for
SRIO/PCIE boot. These addresses need to be updated to
appropriate locations.
The updated addresses are used to configure the SRIO/PCIE
inbound windows for the boot, and they must be aligned
with the window size based on the SRIO/PCIE modules requirement.
So for the 768KB u-boot image, the inbound window cannot be set
with 0xfff40000 base address and 0xc0000 size, it should be
extended to 1MB size and the base address can be aligned with
the size.
Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Kim Phillips [Thu, 15 May 2014 00:33:45 +0000 (19:33 -0500)]
mpc85xx: configs: remove c=ffe from default environment
AFAICT, c=ffe does nothing and was a typo from the original commit d17123696c6180ac8b74fbd318bf14652623e982 "powerpc/p4080: Add support
for the P4080DS board" and just kept on getting duplicated
in subsequently added board config files.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Acked-by: Edward Swarthout <ed.swarthout@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
board/p1_p2_rdb:Enable p1_p2_rdb boot from NAND/SD/SPI in SPL
In the earlier patches, the SPL/TPL fraamework was introduced.
For SD/SPI flash booting way, we introduce the SPL to enable a loader stub. The
SPL was loaded by the code from the internal on-chip ROM. The SPL initializes
the DDR according to the SPD and loads the final uboot image into DDR, then
jump to the DDR to begin execution.
For NAND booting way, the nand SPL has size limitation on some board(e.g.
P1010RDB), it can not be more than 4KB, we can call it "minimal SPL", So the
dynamic DDR driver doesn't fit into this minimum SPL. We added the TPL that is
loaded by the the minimal SPL. The TPL initializes the DDR according to the SPD
and loads the final uboot image into DDR,then jump to the DDR to begin execution.
This patch enabled SPL/TPL for P1_P2_RDB to support starting from NAND/SD/SPI
flash with SPL framework and initializing the DDR according to SPD in the SPL/TPL.
Because the minimal SPL load the TPL to L2 SRAM and the jump to the L2 SRAM to
execute, so the section .resetvec is no longer needed.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Chunhe Lan [Wed, 7 May 2014 02:56:18 +0000 (10:56 +0800)]
powerpc/85xx: Add T4160RDB board support
T4160RDB shares the same platform as T4240RDB. T4160 is
a low power version of T4240, with the eight e6500 cores,
two DDR3 controllers, and same peripheral bus interfaces.
Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Chunhe Lan [Wed, 7 May 2014 02:50:20 +0000 (10:50 +0800)]
fsl/pci: Add workaround for erratum A-005434
By default, all PEX inbound windows PEX_PEXIWARn[TRGT] are
mapped to 0xF, which is local memory. But for BSC9132, 0xF
is CCSR, 0x0 is local memory.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Tang Yuantian [Wed, 7 May 2014 02:25:06 +0000 (10:25 +0800)]
powerpc/t104xrdb: Toggle deep sleep management signals after resume
T104xrdb has several sleep management signals that are used for deep
sleep. They are enabled by OS to enter deep sleep and should be
disabled by u-boot when cores wake up.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
board/freescale: Move CRC32 offset in NXID v1 data format
According to AN3638, CRC of NXID v1 is at the end of the
256-byte I2C memory. The wrong CRC32 offset prevents Uboot
from reading system information from EEPROM. No NXID v0 is
being used on Freescale boards.
Signed-off-by: Ebony Zhu <b45385@freescale.com> Reviewed-by: York Sun <yorksun@freescale.com>
Simon Glass [Tue, 13 May 2014 18:14:02 +0000 (12:14 -0600)]
patman: Suppress duplicate signoffs only for real patches
There is an unfortunate bug in the signoff suppression logic. The first
pass is performed with 'git log', and all signoffs are added to the
supression set, such that the second time (when processing the real
patches) we always suppress the signoffs.
Correct this by only suppressing signoffs in the second pass.
Signed-off-by: Simon Glass <sjg@chromium.org> Tested-by: Michal Simek <monstr@monstr.eu> Tested-by: Andreas Bießmann <andreas.devel@googlemail.com>
Albert ARIBAUD [Tue, 15 Apr 2014 14:13:51 +0000 (16:13 +0200)]
arm: move exception handling out of start.S files
Exception handling is basically identical for all ARM targets.
Factorize it out of the various start.S files and into a
single vectors.S file, and adjust linker scripts accordingly.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Albert ARIBAUD [Tue, 15 Apr 2014 14:13:48 +0000 (16:13 +0200)]
arm: move reset_cpu from start.S into cpu.c
CPUs arm946es and sa1100 both define the reset_cpu()
function in their start.S file. Move this cpu-specific code
into cpu.c so that start.S only contains ARM generic code.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Hans de Goede [Sat, 3 May 2014 15:46:26 +0000 (17:46 +0200)]
mvtwsi: Fix clock programming
The TWSI_FREQUENCY macro was wrong in 2 ways:
1) It was casting the result of the calculations to an u8, while i2c clk
rates are often >= 100Khz which won't fit in a u8, drop the cast.
2) It had an extra factor of 2 in the divider which neither the datasheet nor
the Linux driver have.
The comment for the default value was wrongly saying that m lives in
bits 4-7, while in reality it is in bits 3-6, as can be seen from the correct
shift by 3 used in i2c_init().
While at it remove the unused twsi_actual_speed variable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ash Charles <ash@gumstix.com>
[trini: Move 'cdev' in board.c down to under #ifdef's where it's used] Signed-off-by: Tom Rini <trini@ti.com>
replaced CONFIG_SPL_MAX_SIZE by CONFIG_SPL_MAX_FOOTPRINT. However,
CONFIG_SPL_MAX_SIZE is used in the Makefile for padding the SPL
when preparing an u-boot.ais image. By removing CONFIG_SPL_MAX_SIZE
said commits broke the ais image of the da850evm and cam_enc_4xx
configurations.
This patch converts the u-boot.ais target to use CONFIG_SPL_PAD_TO
instead of CONFIG_SPL_MAX_SIZE for padding the SPL and adds
a #define CONFIG_SPL_PAD_TO where it is required.
Signed-off-by: Christian Riesch <christian.riesch@omicron.at> Reported-by: Tom Taylor <ttaylor.tampa@gmail.com> Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com> Cc: Heiko Schocher <hs@denx.de> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Egli, Samuel [Mon, 5 May 2014 14:50:44 +0000 (16:50 +0200)]
siemens, draco: add new target
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Reviewed-by: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Mon, 5 May 2014 14:50:43 +0000 (16:50 +0200)]
siemens:cosmetic, dxr2: rename dxr2 to draco
The actual board name is draco and dxr2 is the target name.
In the future we'll have different targets based on draco board.
All changes are purely non-functional and basically rename dxr2
to draco.
One style fix in board.c that existed already before.
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Reviewed-by: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Thu, 24 Apr 2014 15:57:56 +0000 (17:57 +0200)]
siemens: cosmetic: rename project_dir
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Thu, 24 Apr 2014 15:57:55 +0000 (17:57 +0200)]
siemens: change LED indication in DFU mode
In order to have the same LED indication like in another product
when ready for updating, enable only red led and disable status
LED when entering DFU mode.
The status LED is only switched off when defined in board file.
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Thu, 24 Apr 2014 15:57:54 +0000 (17:57 +0200)]
siemens: add led cmd for flexible LED control
* remove setting LED in user button function.
We want to decouple reading user button and setting LED. This
two things need to be done independently.
* led cmd can be used to control LEDs that are defined in board file
having a led cmd, one can easily set LEDs in u-boot shell. For
example bootcmd can be extended to disable status LED before
loading kernel.
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Thu, 24 Apr 2014 15:57:53 +0000 (17:57 +0200)]
siemens: update DDR3 parameters for dxr2
* add parameters for factory and print them at start up to
facilitate control of right DDR3 settings in EEPROM.
* cosmetic changes in a couple of printfs
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Egli, Samuel [Thu, 24 Apr 2014 15:57:52 +0000 (17:57 +0200)]
siemens: cosmetic: remove unused and rename defines
For dxr2 board DXR2_IOCTRL_VAL is set by data in EEPROM. In pxm2
board it does not make sense to have dxr2 as prefix. Replace it with
more meaningful DDR prefix.
Signed-off-by: Samuel Egli <samuel.egli@siemens.com> Cc: Pascal Bach <pascal.bach@siemens.com> Cc: Roger Meier <r.meier@siemens.com> Cc: Heiko Schocher <hs@denx.de> Cc: Wolfgang Denk <wd@denx.de>
Stephen Warren [Thu, 8 May 2014 15:33:45 +0000 (09:33 -0600)]
ARM: tegra: use a CPU freq that all SKUs can support
U-Boot on Tegra30 currently selects a main CPU frequency that cannot be
supported at all on some SKUs, and needs higher VDD_CPU/VDD_CORE values
on some others. This can result in unreliable operation of the main CPUs.
Resolve this by switching to a CPU frequency that can be supported by any
SKU. According to the following link, the maximum supported CPU frequency
of the slowest Tegra30 SKU is 600MHz:
According to that same table, the minimum VDD_CPU required to operate at
that frequency across all SKUs is 1.007V. Given the adjustment resolution
of the TPS65911 PMIC that's used on all Tegra30-based boards we support,
we'll end up using 1.0125V instead.
At that VDD_CPU, tegra3_get_core_floor_mv() in that same file dictates
that VDD_CORE must be at least 1.2V on all SKUs. According to
tegra_core_speedo_mv() (in tegra3_speedo.c in the same source tree),
that voltage is safe for all SKUs.
An alternative would be to port much of the code from tegra3_dvfs.c and
tegra3_speedo.c in the kernel tree mentioned above. That's more work
than I want to take on right now.
While all the currently supported boards use the same regulator chip for
VDD_CPU, different types of regulators are used for VDD_CORE. Hence, we
add some small conditional code to select how VDD_CORE is programmed. If
this becomes more complex in the future as new boards are added, or we
end up adding code to detect the SoC SKU and dynamically determine the
allowed frequency and required voltages, we should probably make this a
runtime call into a function provided by the board file and/or relevant
PMIC driver.
Cc: Alban Bedel <alban.bedel@avionic-design.de> Cc: Marcel Ziswiler <marcel@ziswiler.com> Cc: Bard Liao <bardliao@realtek.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:57 +0000 (14:37 -0600)]
ARM: tegra: update Venice2 pinmux
This re-imports the entire Venice2 pinmux data from the board's master
spreadsheet, and makes use of the new IO clamping GPIO initialization
table features. This makes the board port fully compliant with the
required HW-defined pinmux initialization sequence.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:56 +0000 (14:37 -0600)]
ARM: tegra: clamp inputs on Jetson TK1
The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Modify the Jetson TK1 board to do this.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:55 +0000 (14:37 -0600)]
ARM: tegra: make use of GPIO init table on Jetson TK1
The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. This patch implements this
procedure for Jetson TK1. For pins which are to be used as GPIOs, the
pinmux mux function need not be programmed, so the pinmux table is also
adjusted.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:54 +0000 (14:37 -0600)]
ARM: tegra: add function to enable input clamping on tristate
The HW-defined procedure for booting Tegra requires that
CLAMP_INPUTS_WHEN_TRISTATED be enabled before programming the pinmux.
Add a function to the pinmux driver to allow boards to do this.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:53 +0000 (14:37 -0600)]
ARM: tegra: add GPIO initialization table function
The HW-defined procedure for booting Tegra requires that some pins be
set up as GPIOs immediately at boot in order to avoid glitches on those
pins, when the pinmux is programmed. Add a feature to the GPIO driver
which executes a GPIO configuration table. Board files will use this to
implement the correct HW initialization procedure.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Tue, 22 Apr 2014 20:37:52 +0000 (14:37 -0600)]
ARM: tegra: allow pinmux mux option not to be set by init tables
Define enum PMUX_FUNC_DEFAULT, which indicates that a table entry passed
to pinmux_config_pingrp()/pinmux_config_pingrp_table() shouldn't change
the mux option in HW.
For pins that will be used as GPIOs, the mux option is irrelevant, so we
simply don't want to define any mux option in the pinmux initialization
table.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
Stephen Warren [Mon, 21 Apr 2014 20:50:33 +0000 (14:50 -0600)]
ARM: tegra: fix CPU VDD comment in Tegra30 CPU init code
The register writes performed by arch/arm/cpu/arm720t/tegra30/cpu.c
enable_cpu_power_rail() set the voltage to 1.0V not 1.4V as the comment
implies. Fix the comment.
Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Tom Warren <twarren@nvidia.com>
York Sun [Wed, 30 Apr 2014 21:43:49 +0000 (14:43 -0700)]
powerpc/freescale: Convert selected boards to generic board architecture
This patch converts the following boards to use generic board: MPC8536DS,
MPC8572DS, MPC8641HPCN, p1_p2_rdb_pc, corenet_ds, t4qds, B4860QDS. It has
been tested on NOR boot on MPC8536DS, MPC8572DS, P1021RDB, P4080DS,
P5020DS, P5040DS, P3041DS, T4240QDS, B4860QDS.
Signed-off-by: York Sun <yorksun@freescale.com> CC: Ying Zhang <b40530@freescale.com> CC: Prabhakar Kushwaha <prabhakar@freescale.com> CC: Haijun.Zhang <Haijun.Zhang@freescale.com> CC: Scott Wood <scottwood@freescale.com> CC: Shaohui Xie <Shaohui.Xie@freescale.com>
York Sun [Wed, 30 Apr 2014 21:43:47 +0000 (14:43 -0700)]
powerpc/mpc85xx: Fix boot_flag for calling board_init_f()
baord_init_f takes one argument, boot_flag. It has not been used for
powerpc, until recently changing to use generic board architecture.
The boot flag is added as a return value from cpu_init_f().
Signed-off-by: York Sun <yorksun@freescale.com> CC: Alexander Graf <agraf@suse.de>
York Sun [Wed, 30 Apr 2014 21:43:46 +0000 (14:43 -0700)]
powerpc/freescale: Change the return value of mac_read_from_eeprom()
The return value has not been checked by its caller, until recent change
of using generic board architecture. The error of this function is not
critical enough to hang the system. Printing the warning message is enough
to catch user's attention. U-boot should continue to boot to give user
a chance to fix the EEPROM. Chaning the return value to 0 to avoid hanging
in the board_init_r().
York Sun [Wed, 30 Apr 2014 21:43:45 +0000 (14:43 -0700)]
powerpc/mpc85xx: Ignore FDT pointer for non-QEMU in cpu_init_early_f()
The pointer of device tree comes from r3 for QEMU. This is not the case
for normal SoCs out of reset. Having gd->fdt_blob as 0 is important for
other functions to detect the non-existence of device tree.
Signed-off-by: York Sun <yorksun@freescale.com> CC: Alexander Graf <agraf@suse.de>
York Sun [Fri, 25 Apr 2014 19:06:17 +0000 (12:06 -0700)]
powerpc/mpc8572ds: Increase u-boot size to 768KB
U-boot image has grown and exceeded the predefined 512KB. Increasing to
768KB to align with other powerpc boards. Tested on MPC8572DS for 32-
and 36-bit targets with NOR flash boot. NAND boot is not covered by
this patch.
Also update board maintainer for these boards.
Signed-off-by: York Sun <yorksun@freescale.com> Acked-by: Heiko Schocher <hs@denx.de>
Alexander Graf [Wed, 30 Apr 2014 17:21:12 +0000 (19:21 +0200)]
powerpc/mpc85xx: Update TLB CAMs in relocated mode
We want to use the TLB mapping helpers in relocated mode as well. These helpers
need to have awareness of already occupied TLB entries. We already had them in
sync in non-relocated mode, but need to resync them when we move into relocated.
Alexander Graf [Wed, 30 Apr 2014 17:21:10 +0000 (19:21 +0200)]
PPC 85xx QEMU: Always assume 1 core
We only need u-boot to bother about a single core in the QEMU machine.
Everything that would require additional knowledge of more cores gets
handled by QEMU and passed straight into the payload we execute.
Because of this setup, it would be counterproductive to enable SMP support
in u-boot. We would have to rip CPUs out of already existing spin tables
and respin them from u-boot. It would be a pretty big mess.
So only assume we have a single core. This fixes errors about CONFIG_MP
being disabled.
Fix the IRQ/GPIO settings: all the muxed GPIO/external IRQs that are
used as internal interrupts are defined as GPIOs to avoid confusion
between the internal/external interrupts.
kmp204x: complete the reset sequence and PRST configuration
This adds the reset support for the following devices that was until
then not implemented:
- BFTIC4
- QSFPs
This also fixes the configuration of the prst behaviour for the other
resets: Only the u-boot and kernel relevant subsystems are taken out of
reset (pcie, ZL30158, and front eth phy).
Most of the prst config move to misc_init_f(), except for the PCIe
related ones that are in pci_init_board and the bftic and ZL30158 ones
that should be done as soon as possible.
Only the behavior of the Hooper reset is changed according to the
documentation as the application is not able to not configure the switch
when it is not reset.
This patch defines the post_hotkeys_pressed() function that is used for:
- triggering POST memory regions test
- starting the test application through the checktestboot command in
a script by setting the active bank to testbank
The post_hotkeys_pressed return the state of the SELFTEST pin.
The patch moves from the complete POST-memory test that is too long in
its SLOW version for our production HW test procedure to the much shorter
POST-memory-regions test.
Finally, the unused #defines for the not so relevant mtest command are
removed.
Signed-off-by: Stefan Bigler <stefan.bigler@keymile.com> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Stefan Bigler [Fri, 2 May 2014 08:49:27 +0000 (10:49 +0200)]
kmp204x: handle dip-switch for factory settings
Add readout of dip-switch to revert to factory settings.
If one or more dip-switch are set, launch bank 0 that contains the
bootloader to do the required action.
Signed-off-by: Stefan Bigler <stefan.bigler@keymile.com> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Shengzhou Liu [Fri, 25 Apr 2014 08:31:22 +0000 (16:31 +0800)]
powerpc/85xx: add T4080 SoC support
The T4080 SoC is a low-power version of the T4160.
T4080 combines 4 dual-threaded Power Architecture e6500
cores with single cluster and two memory complexes.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Current driver uses a Maximum value for MDIO_HOLD when doing 10G MDIO
access, this is due to an errata A-006260 on T4 rev1.0 which is fixed
on rev2.0, so remove the maximum value to use the default value for rev2.0.
powerpc/mpc85xx: SECURE BOOT- Add secure boot target for T2080RDB
Secure Boot Target is added for T2080RDB
Changes:
For Secure boot, CPC is configured as SRAM and used as house
keeping area which needs to be disabled.
So CONFIG_SYS_CPC_REINIT_F is defined for CONFIG_T2080RDB.
The fuse status register provides the values from on-chip
voltage ID efuses programmed at the factory.
These values define the voltage requirements for
the chip. u-boot reads FUSESR and translates the values
into the appropriate commands to set the voltage output
value of an external voltage regulator.
B4860QDS has a PowerOne ZM7300 programmable digital Power
Manager which is programmed as per the value read from
the fuses.
Reference for this code is taken from t4qds VID implementation.
Adds Support for PowerOne ZM7300 voltage regulator.
This device is available on some Freescale Boards like B4860QDS
and has to be programmed to adjust the voltage on the board.
projects / u-boot.git / log