fpga: Added support to load bit stream from SD/MMC
Added support to load a bitstream image in chunks by reading it in
chunks from SD/MMC.
Command format:
loadfs [dev] [address] [image size] [blocksize] <interface>
[<dev[:part]>] <filename>
Example: fpga loadfs 0 1000000 3dbafc 4000 mmc 0 fpga.bin
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Fri, 2 May 2014 11:43:39 +0000 (13:43 +0200)]
fpga: Add support to load partial bitstreams
Added support to load partial bitstreams.
The partial bitstreams can be loaded using the below commands
Commands:
fpga loadp <dev> <addr> <size>
fpga loadbp <dev> <addr> <size>
The full bit streams can be loaded using the
old commands(fpga load and fpga loadb).
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Fri, 2 May 2014 12:09:30 +0000 (14:09 +0200)]
fpga: Define bitstream type based on command selection
Clean up partial, full and compressed bitstream handling.
U-Boot supports full bitstream loading and partial
based on detection which is not 100% correct.
Extending fpga_load/fpga_loadbitstream() with one more
argument which stores bitstream type.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
fpga: Guard the LOADMK functionality with CMD_FPGA_LOADMK
Guard the LOADMK functionality with config to provide
an option to enable or disable it.
Enable it for all platforms in mainline which enable CONFIG_CMD_FPGA.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.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>
Masahiro Yamada [Thu, 15 May 2014 11:37:53 +0000 (20:37 +0900)]
zynq: import zynq-7000.dtsi from Linux Kernel
Our current motivation is to use OF initialization for RAM and UART.
But adding full DTS would be helpful in future, for instance,
for OF configuration of Ethernet, MMC, USB, etc.
This commit imports arch/arm/boot/dts/zynq-7000.dtsi from Linux 3.15-rc5
and adjusts the license comment block for SPDX.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Suggested-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Masahiro Yamada [Thu, 15 May 2014 11:37:52 +0000 (20:37 +0900)]
zynq: load u-boot-dtb.img if CONFIG_OF_SEPARATE is defined
SPL should load "u-boot-dtb.img" if both CONFIG_OF_CONTROL
and CONFIG_OF_SEPARATE are defined.
Otherwise, "u-boot.img" should be loaded.
Since CONFIG_OF_CONTROL is always undefined for SPL_BUILD,
the undef block should be moved below the conditional definition
of CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Masahiro Yamada [Thu, 15 May 2014 11:37:51 +0000 (20:37 +0900)]
build: support a new image u-boot-dtb.img
In SPL framework, SPL uses u-boot.img to load u-boot.bin.
Here,
u-boot.img = uImage header + u-boot.bin
To use OF control with a separate devicetree,
u-boot.dtb must be placed right after u-boot.bin.
In this case, u-boot-dtb.bin is generally used.
Here,
u-boot-dtb.bin = u-boot.bin + u-boot.dtb
We need u-boot-dtb.img to use both SPL framework
and separate OF control at the same time.
u-boot-dtb.img = uImage header + u-boot-dtb.bin
For example, Zynq boards already define all of
- CONFIG_SPL
- CONFIG_OF_CONTROL
- CONFIG_OF_SEPARATE
So, the support of u-boot-dtb.img is urgent.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Michal Simek <michal.simek@xilinx.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Lukasz Majewski [Fri, 9 May 2014 14:58:15 +0000 (16:58 +0200)]
dfu: mmc: Provide support for eMMC boot partition access
Before this patch it was only possible to access the default eMMC HW
partition. By partition selection I mean the access to eMMC via the
ext_csd[179] register programming.
It sometimes happens that it is necessary to write to other partitions.
This patch adds extra attribute to "raw" sub type of the dfu_alt_info
environment variable (e.g. boot-mmc.bin raw 0x0 0x200 mmcpart 1;)
It saves the original boot value and restores it after storing the file.
drivers:dfu: dfu_flush(): add raw data flush to complete dfu write
Before dfu write and flush operations separation,
dfu write data was flushed by host download request
with len of zero size.
Since above change manually calling dfu write with zero
size has non sense (e.g. in THOR). This should be done by
flush operation.
So now dfu_write_buffer_drain() is called in dfu_flush().
If there is any raw data to flush (like it can be in thor)
then it will be physically written to medium.
Stephen Warren [Tue, 13 May 2014 16:51:54 +0000 (10:51 -0600)]
usb: ci_udc: parse QTD before over-writing it
ci_udc only allocates a single QTD structure per EP. All data needs to be
extracted from the DTD prior to calling ci_ep_submit_next_request(), since
that fills the QTD with next transaction's parameters. Fix
handle_ep_complete() to extract the transaction (remaining) length before
kicking off the next transaction.
In practice, this only causes writes to UMS devices to fail for me. I may
have tested the final versions of my previous ci_udc patch only with
reads. More recently, I had patches applied locally that allocated a QTD
per USB request rather than per USB EP, although since that doesn't give
any performance benefit, I'm dropping those.
Fixes: 2813006fecda ("usb: ci_udc: allow multiple buffer allocs per ep") Signed-off-by: Stephen Warren <swarren@nvidia.com>
Stephen Warren [Wed, 30 Apr 2014 21:09:57 +0000 (15:09 -0600)]
usb: tegra: support device mode
A few changes are made to the Tegra EHCI driver so that it can set
everything up for device-mode operation on the first USB controller.
This can be used in conjunction with ci_udc.c to operate as a USB
device.
Detailed changes are:
* Rename set_host_mode() to set_up_vbus() since that's really what it
does.
* Modify set_up_vbus() to know whether it's initializing in host or
device mode, and:
- Skip the external VBUS check in device mode, since external VBUS is
expected in this case.
- Disable VBUS output in device mode.
* Modify init_phy_mux() to know whether it's initializing in host or
device mode, and hence skip setting USBMODE_CM_HC (which enables host
mode) in device mode. See the comments in that function for why this
is safe w.r.t. the ordering requirements of PHY selection.
* Modify init_utmi_usb_controller() to force "b session valid" in device
mode, since the HW requires this. This is done in UTMI-specific code,
since we only support device mode on the first USB controller, and that
controller can only talk to a UTMI PHY.
* Enhance ehci_hcd_init() to error-check the requested host-/device-mode
vs. the dr_mode (dual-role mode) value present in device tree, and the
HW configurations which support device mode.
* Enhance ehci_hcd_init() not to skip HW initialization when switching
between host and device mode on a controller. This requires remembering
which mode the last initialization used.
Cc: Jim Lin <jilin@nvidia.com> Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Stephen Warren [Wed, 30 Apr 2014 21:09:56 +0000 (15:09 -0600)]
usb: tegra: refactor PHY type selection
Both init_{utmi,ulpi}_usb_controller() have nearly identical code for
PHY type selection. Pull this out into a common function to remove the
duplication.
Cc: Jim Lin <jilin@nvidia.com> Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: Stephen Warren <swarren@nvidia.com>
Stephen Warren [Wed, 30 Apr 2014 21:09:55 +0000 (15:09 -0600)]
usb: tegra: fix PHY selection code
The TRM for Tegra30 and later all state that USBMODE_CM_HC must be set
before writing to hostpc1_devlc to select which PHY to use for a USB
controller. However, neither init_{utmi,ulpi}_usb_controller() do this
today, so the register writes they perform for PHY selection do not
work.
For the UTMI case, this was hacked around in commit 7e44d9320ed4 "ARM:
Tegra: USB: EHCI: Add support for Tegra30/Tegra114" by adding code to
ehci_hcd_init() which sets USBMODE_CM_HC and duplicates the PHY
selection register write. This code doesn't cover the ULPI case, so I
wouldn't be surprised if ULPI doesn't work with the current code, unless
the ordering requirement only ends up being an issue in HW for UTMI not
ULPI.
This patch fixes init_{utmi,ulpi}_usb_controller() to correctly set
USBMODE_CM_HC before selecting the PHY. Now that this works, we can
remove the duplicate UTMI-specific code in ehci_hcd_init(), thus
simplifying that function.
Cc: Jim Lin <jilin@nvidia.com> Cc: Stefan Agner <stefan@agner.ch> Signed-off-by: Stephen Warren <swarren@nvidia.com>
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>
Michal Simek [Tue, 4 Mar 2014 11:41:05 +0000 (12:41 +0100)]
ARM: zynq: Fix building SPL without FPGA support
When CONFIG_FPGA is defined but CONFIG_SPL_FPGA is not, the build fails:
board.c: In function 'board_init':
board.c:41:3: error: 'fpga' undeclared (first use in this function)
fpga = fpga010;
Fix this by expanding the "#if.." around this block to match the other
FPGA checks and don't compile this block when buildign for SPL without
FPGA support.
Tested a bootloader that had CONFIG_FPGA defined without CONFIG_SPL_FPGA,
this now compiles without errors and loading FPGA from u-boot works.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Mike Looijmans [Thu, 6 Mar 2014 13:43:36 +0000 (14:43 +0100)]
ARM: zynq: Fix bootmode mask
Bootmode mask was defined as 0x0F, but documentation mentions 0x07.
Experiments show that bit "3" is the JTAG chain configuration.
Change the mask to "7" to allow systems with a different chain
configuration to boot correctly.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl> Acked-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
ARM: zynq: Added efuse status register base address
Added efuse status register base address. This register
is used for determining whether efuse was blown or not.
Also, added the zynq_get_silicon_version() to get the
silicon version of the zynq board.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Fri, 25 Apr 2014 11:51:17 +0000 (13:51 +0200)]
ARM: zynq: Remove sparse warnings
Warnings:
board/xilinx/zynq/board.c:17:13: warning: symbol 'fpga' was not declared. Should it be static?
board/xilinx/zynq/board.c:20:13: warning: symbol 'fpga010' was not declared. Should it be static?
board/xilinx/zynq/board.c:21:13: warning: symbol 'fpga015' was not declared. Should it be static?
board/xilinx/zynq/board.c:22:13: warning: symbol 'fpga020' was not declared. Should it be static?
board/xilinx/zynq/board.c:23:13: warning: symbol 'fpga030' was not declared. Should it be static?
board/xilinx/zynq/board.c:24:13: warning: symbol 'fpga045' was not declared. Should it be static?
board/xilinx/zynq/board.c:25:13: warning: symbol 'fpga100' was not declared. Should it be static?
board/xilinx/zynq/board.c:120:5: warning: symbol 'board_mmc_init' was not declared. Should it be static?
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Michal Simek [Fri, 25 Apr 2014 11:48:08 +0000 (13:48 +0200)]
ARM: zynq: Fix sparse warnings in slcr.c
Warnings:
arch/arm/cpu/armv7/zynq/slcr.c:21:6: warning: symbol 'zynq_slcr_lock' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:27:6: warning: symbol 'zynq_slcr_unlock' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:34:6: warning: symbol 'zynq_slcr_cpu_reset' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:54:6: warning: symbol 'zynq_slcr_gem_clk_setup' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:81:6: warning: symbol 'zynq_slcr_devcfg_disable' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:94:6: warning: symbol 'zynq_slcr_devcfg_enable' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:107:5: warning: symbol 'zynq_slcr_get_boot_mode' was not declared. Should it be static?
arch/arm/cpu/armv7/zynq/slcr.c:113:5: warning: symbol 'zynq_slcr_get_idcode' was not declared. Should it be static?
Signed-off-by: Michal Simek <michal.simek@xilinx.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>