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.
Signed-off-by: Ying Zhang <b40530@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
T2080 v1.0 has this errata while v1.1 has fixed
this errata by hardware, add a new function has_errata_a007186
to check the SVR_SOC_VER, SVR_MAJ and SVR_MIN first,
if the sil has errata a007186, then run the errata code,
if not, doesn't run the code.
Signed-off-by: Zhao Qiang <B45475@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Workaround of Errata A-008044 was implemented without errata number and it is
enabled by default. Errata A-008044 is only valid for T1040 Rev 1.0.
So put errata number and make it conditional.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
When device is configured to load RCW from NAND flash IFC_A[16:31] are driven
low after RCW loading. Hence Devices connected on IFC_CS[1:7] and using
IFC_A[16:31] lines are not accessible.
Workaround is already in-place.
Put the errata number to adhere errata handling framework.
Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Enable interactive debugging by default. Remove DDR controller interleaving
because this SoC only has one controller. Use auto chip-select interleaving
to detect number of ranks.
Signed-off-by: York Sun <yorksun@freescale.com>
CC: Poonam Aggrwal <poonam.aggrwal@freescale.com>
T2080 rev 1.1 changes MEM_RAT in RCW, which requires new parsing for ratio,
the same way as T4240 rev 2.0.
Signed-off-by: York Sun <yorksun@freescale.com>
CC: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Adjust timing for dual-rank UDIMM, verified on M3CQ-8GHS3C0E for speed of
1066, 1333, 1600, 1866MT/s. The 1866 timing is copied to 2133 timing in
case such DIMM comes available.
Also update single-rank 1866 timing. Enable interactive debugging as well.
Signed-off-by: York Sun <yorksun@freescale.com>
CC: Shengzhou Liu <Shengzhou.Liu@freescale.com>
fman_port_enet_if() tests if FM1_DTSEC2 or FM1_DTSEC4 uses
RGMII or MII and if not returns PHY_INTERFACE_MODE_NONE.
This excludes testing for SGMII further down.
Remove the unconditional "else return PHY_INTERFACE_MODE_NONE"
so SGMII can be tested too.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Reviewed-by: York Sun <yorksun@freescale.com>
To support interactive DDR debugger, cli_simple.o, cli.o, cli_readline.o,
command.o, s_record.o, xyzModem.o and cmd_disk.o are all needed for
drivers/ddr/fsl/interactive.c.
In current common/Makefile, the above .o files are only produced when
CONFIG_SPL_BUILD is disabled.
For LS102xA, interactive DDR debugger is needed in SD/NAND boot too, and
I enabled CONFIG_FSL_DDR_INTERACTIVE. But according to the current
common/Makfile, all the above .o files are not produced in SPL part
because CONFIG_SPL_BUILD is enabled in SPL part, the following error
will be shown,
drivers/ddr/fsl/built-in.o: In function `fsl_ddr_interactive':
/home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1871:
undefined reference to `cli_readline_into_buffer'
/home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1873:
undefined reference to `cli_simple_parse_line'
make[1]: *** [spl/u-boot-spl] Error 1
make: *** [spl/u-boot-spl] Error 2
So this patch fixed this issue and the above .o files will be produced
no matter CONFIG_SPL_BUILD is enabled or disabled.
Signed-off-by: Alison Wang <alison.wang@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
The same problem that is seen on some OMAP3 is also seen on some OMAP4
so include them in the test in order to prevent some hangs during SPL.
[trini: Re-word commit message, make apply cleanly]
Signed-off-by: Tom Rini <trini@ti.com>
add FIT support and set "boardid" from factoryset records
"DEV/id" and "COMP/ver". "boardid" is used for selecting
which fit configuration gets booted on the board.
Signed-off-by: Heiko Schocher <hs@denx.de>
a record could contain other records, so after an ">" (begin mark)
there not always come an end mark "<", instead a ">" is possible.
Take care of this.
Signed-off-by: Heiko Schocher <hs@denx.de>
The functions to detect the state of the ready / busy signal is already
available but only used in the SPL case. Lets use it always, also for the
main U-Boot. As all boards should have this HW connection.
Testing on Siemens Draco (am335x) showed a small perfomance gain by using
this ready pin to detect the NAND chip state. Here the values tested on
Draco with Hynix 4GBit NAND:
Without NAND ready pin:
U-Boot# time nand read 80400000 0 400000
NAND read: device 0 offset 0x0, size 0x400000
4194304 bytes read: OK
time: 2.947 seconds, 2947 ticks
With NAND ready pin:
U-Boot# time nand read 80400000 0 400000
NAND read: device 0 offset 0x0, size 0x400000
4194304 bytes read: OK
time: 2.795 seconds, 2795 ticks
So an increase of approx. 5%.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Scott Wood <scottwood@freescale.com>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
Re-map NAND&I2C boot-device to the "normal" NAND boot-device.
Otherwise the SPL boot IF can't handle this device correctly.
Somehow booting with Hynix 4GBit NAND H27U4G8 on Siemens
Draco leads to this boot-device passed to SPL from the BootROM.
With this change, Draco boots just fine into main U-Boot.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Tom Rini <trini@ti.com>
Cc: Roger Meier <r.meier@siemens.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
The comments on the QSPI pad assignments erronously swapped
the qspi1_d0 and qspi1_d1 functionality and could cause
confusion. QSPI1_D[0] is in fact muxed on pad U1 (gpmc_a16),
and QSPI1_D[1] - on pad P3 (gpmc_a17). Fixing comments.
Signed-off-by: Lubomir Popov <l-popov@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Boards using the TWL4030 regulator may not all use the LDOs the same way
(e.g. MMC2 power can be controlled by another LDO than VMMC2).
This delegates TWL4030 MMC power initializations to board-specific functions,
that may still call twl4030_power_mmc_init for the default behavior.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
[trini: Fix omap3_evm warning, add twl4030.h]
Signed-off-by: Tom Rini <trini@ti.com>
Renesas R-Mobile/R-Car ARM SoC of MMC has the same IP that are supported by
sh_mmcif. This adds support R-Mobile/R-Car ARM SoC with the setting of the
clock support.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Maximum value and the minimum value of clock for sh_mmcif instead by
base of MMC clock. This removes fixed clock, make the changes to be calculated
according to environment.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Use DIV_ROUND_UP and fls to simplify the code.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The infomation of module control register for R-Car ARM SoC (r8a7790, r8a7791,
r8a7793 and r8a7794) are almost the same, they can be combined into one
structure. This provides structure that summarizes infomation of module control
register and default register values.
And this structure is the module control use of the kernel at boot time.
Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
This adds infomation of bits for module control register. This is used
to control modules on ARM R-Car SoCs.
Signed-off-by: Hisashi Nakamura <hisashi.nakamura.ak@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
This addes macro for set and clear bit control for module control register.
This is used when user want to disable the function of the devices
corresponding to register.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The arch_preboot_os function used in boards using R-Car ARM SoC (r8a7790,
r8a7791, r8a7793 and r8a7794) is common.
This makes rcar-gen2-common/common.c file providing common function for
R-Car ARM SoC, and moves this function to this file.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Control macro of mstp is common in R-Car ARM SoC (r8a7790, r8a7791,
r8a7793 and r8a7794). This moves these to arch-rmobile/rcar-mstp.h
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Module control registers of R-Car ARM SoC (r8a7790, r8a7791, r8a7793 and
r8a7794) are same address. This moves these to header file of SoC.
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CONFIG_SYS_MMC_SD_FS_BOOT_PARTITION ought to be called
CONFIG_SYS_MMCSD_FS_BOOT_PARTITION to keep it consistent with other config
options such as: CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
In addition, it is not related to raw mode booting but to fs mode instead.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
Not every device has multiple MMC slots available, so it makes sense to enable
only the required LDOs for the available slots. Generic code in omap_hsmmc will
enable both VMMC1 and VMMC2, in doubt.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
Some devices may use non-standard combinations of regulators to power MMC:
this allows these devices to provide a board-specific MMC power init function
to set everything up in their own way.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-by: Tom Rini <trini@ti.com>
BeagleBoard-X15 is the next generation Open Source
Hardware BeagleBoard based on TI's AM5728 SoC
featuring dual core 1.5GHZ A15 processor. The
platform features 2GB DDR3L (w/dual 32bit busses),
eSATA, 3 USB3.0 ports, integrated HDMI (1920x108@60),
separate LCD port, video In port, 4GB eMMC, uSD,
Analog audio in/out, dual 1G Ethernet.
For more information, refer to:
http://www.elinux.org/Beagleboard:BeagleBoard-X15
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
just add a few ifdefs around because this
device is very similar to dra7xxx.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
expose those two definitions so they can be
used by another board which we're adding in upcoming
patches.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
this will allow for boards to overwrite those
in case memory setup is different.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
* Since the emmc isn't always programed trying to load the fs from the
emmc causes boot failures/kernel panic.
* The current bootcmd is set to:
bootcmd=run findfdt; run mmcboot;setenv mmcdev 1; setenv bootpart 1:2; \
setenv mmcroot /dev/mmcblk0p2 rw; run mmcboot;
My guess is the env variables should be set so that sd card boot
(dt,kernel,fs) is the default and then fallback to emmc if it fails (no
sd card detected)
The current bootcmd attempts to set mmcroot to the sd card rootfs but
that code doesn't run due to mmcboot being ran early on.
Signed-off-by: Franklin Cooper Jr. <fcooper@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
If we want to have two sections, one on each EMIF, without
interleaving, current code wouldn't enable emif2. Fix that
problem.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
there's no such function usb3_phy_power(),
it's likely that author meant to call,
usb_phy_power() instead, but that's already
called properly from xhci-omap.c.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
some boards might want to use USB1 for host,
without fiddling those registers it'll be
impossible.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Those regulators don't have any coupling with
what they supply, so remove the suffixes in order
to not confuse anybody.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
Out of all OMAP5-like boards, only one of them
needs CONFIG_MISC_INIT_R, so it's best to enable
that for that particular board only, instead of
enabling for all boards unconditionally.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Reviewed-by: Tom Rini <trini@ti.com>
It has been found that this change breaks the case of an appended device
tree file, so for the problem in question some other solution must be
found.
This reverts commit c6150aaf2f.
Reported-by: Bill Pringlemeir <bpringlemeir@nbsps.com>
Reported-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Confirmed-by: Bill Pringlemeir <bpringlemeir@nbsps.com>
Signed-off-by: Tom Rini <trini@ti.com>
The changes to introduce loff_t into filesize means that we need to do
64bit math on 32bit platforms. Make sure we use the right wrappers for
these operations.
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Suriyan Ramasami <suriyan.r@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@ti.com>
Tested-by: Pierre Aubert <p.aubert@staubli.com>
After commit 933cdbb479: "fdt: Try to use fdt_address_cells()/fdt_size_cells()"
I noticed that allwinner boards would no longer boot.
Switching to fdt_address_cells / fdt_size_cells changes the result from
bytes to 32 bit words, so when we increment pointers into the blob, we must
do so by 32 bit words now.
This commit makes allwinner boards boot again.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Stefan Roese <sr@denx.de>
Tested-by: Vince Hsu <vinceh@nvidia.com>
