Add an I2C bus to the device tree, with an EEPROM emulator attached to one
of the addresses.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
To enable testing of I2C, add a simple I2C EEPROM simulator for sandbox.
It supports reading and writing from a small data store.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
R-Mobile and R-Car ARM SoCs use sh_mmcif as MMC host driver.
This adds arch-rmobile/mmc.h that defines mmcif_mmc_init().
Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
stv0991 architecture support added. It contains the support for
following blocks
- Timer
- uart
Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
[trini: Add arch/arm/cpu/armv7/Makefile hunk]
Signed-off-by: Tom Rini <trini@ti.com>
Some UniPhier boards are equipped with an expansion slot that
some optional SRAM/NOR-flash cards can be attached to. So, run-time
detection of the number of flash banks would be more user-friendly.
Until this commit, UniPhier boards have achieved this by (ab)using
board_flash_wp_on() because the boot failed if flash_size got zero.
Fortunately, this problem was solved by commit 70879a9256 (flash:
do not fail even if flash_size is zero).
Now it is possible to throw away such a tricky workaround. This
commit also enables CONFIG_SYS_MAX_FLASH_BANKS_DETECT for further
refactoring.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
The macro __iomem is defined in include/linux/compiler.h.
Let's include it rather than double __iomem defines.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Sonic Zhang <sonic.adi@gmail.com>
Introduce a Makefile under arch/$ARCH/ and include it in the
top Makefile (similar to Linux kernel). This allows further
refactoringi like moving architecture-specific code out of global
makefiles, deprecating config variables (CPU, CPUDIR, SOC) or
deprecating arch/$ARCH/config.mk.
In contrary to Linux kernel, U-Boot defines the ARCH variable by
Kconfig, thus the arch Makefile can only included conditionally
after the top config.mk.
Signed-off-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Acked-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This board sprinkles #ifdef(CONFIG_HERMES) over various global files
such as include/common.h, common/board_r.c, common/cmd_bdinfo.c.
Let's zap such an ill-behaved board.
It has not been converted to generic board yet and mpc8xx is old
enough.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Wolfgang Denk <wd@denx.de>
Acked-by: Wolfgang Denk <wd@denx.de>
The U-Boot port runs on a variety of RPi models, not just the B. So,
rename the port to something slightly more generic.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Detect the board revision early during boot, and print the decoded
model name.
Eventually, this information can be used for tasks such as:
- Allowing/preventing USB device mode; some models have a USB device on-
board so only host mode makes sense. Others connect the SoC directly
to the USB connector, so device-mode might make sense.
- The on-board USB hub/Ethernet requires different GPIOs to enable it,
although luckily the default appears to be fine so far.
- The compute module contains an on-board eMMC device, so we could store
the environment there. Other models use an SD card and so don't support
saving the environment (unless we store it in a file on the FAT boot
partition...)
Set $fdtfile based on this information. At present, the mainline Linux
kernel doesn't contain a separate DTB for most models, but I hope that
will change soon.
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Some configurations have been moved to Kconfig and the difference
among the config headers of UniPhier SoC variants is getting smaller
and smaller. Now is a good time to merge them into a single file.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
There are two kinds of expansion boards which are often used for
the UniPhier platform and they are only exclusively selectable.
It can be better described by the "choice" menu of Kconfig.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
This ugly work-around code is unnecessary since commit f09eb52b3f
(mtd: denali: set some registers after nand_scan_ident()).
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Newer qoriq socs have an updated dma ip block with a
different compatible. Let's make sure we use the proper
string so that the dmas get their liodn.
In order to have the means to specify the compatible
string, the liodn setting macros were updated to receive
a new parameter for it.
The following SoCs were changed to use the new compatible:
T1023/4, T1040, T2080/1, T4240, B4860.
Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
Increase IO drive strength to fix FCS error on RGMII ports
on T1024QDS.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
fm_standard_init() initializes each 10G port by FM_TGEC_INFO_INITIALIZER.
but it needs different implementation of FM_TGEC_INFO_INITIALIZER on different SoCs.
on SoCs earlier(e.g. T4240, T2080), the notation between 10GEC and MAC as below:
10GEC1->MAC9, 10GEC2->MAC10, 10GEC3->MAC1, 10GEC4->MAC2
on SoCs later(e.g. T1024, etc), the notation between 10GEC and MAC as below:
10GEC1->MAC1, 10GEC2->MAC2
so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to fit the new SoCs on
which 10GEC enumeration is consistent with MAC enumeration.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
T1024RDB is a Freescale Reference Design Board that hosts the T1024 SoC.
T1024RDB board Overview
-----------------------
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
prioritization and bandwidth allocation
- 32-/64-bit DDR3L SDRAM memory controller with ECC and interleaving support
- Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC
- Ethernet interfaces:
- Two 10M/100M/1G RGMII ports on-board
- one 10Gbps XFI interface
- PCIe: Three PCIe controllers: one PCIe Slot and two Mini-PCIe connectors.
- SerDes: 4 lanes up to 10.3125GHz
- IFC: 128MB NOR Flash, 512MB NAND Flash and CPLD
- eSPI: 64MB N25Q512 SPI flash.
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- USB: Two Type-A USB2.0 ports with internal PHY
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC
- I2C: Four I2C controllers
- UART: Two UART serial ports
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
[York Sun: Fix ft_board_setup() type, fix MAINTAINERS for SECURE_BOOT
Fix Kconfig by adding SUPPORT_SPL]
Reviewed-by: York Sun <yorksun@freescale.com>
T1024QDS is a high-performance computing evaluation, development and
test platform for T1024 QorIQ Power Architecture processor.
T1024QDS board Overview
-----------------------
- T1024 SoC integrating two 64-bit e5500 cores up to 1.4GHz
- CoreNet fabric supporting coherent and noncoherent transactions with
prioritization and bandwidth allocation
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support
- Accelerator: DPAA components consist of FMan, BMan, QMan, DCE and SEC
- Ethernet interfaces:
- Two 10M/100M/1G RGMII ports on-board
- Three 1G/2.5Gbps SGMII ports
- Four 1Gbps QSGMII ports
- one 10Gbps XFI or 10Base-KR interface
- SerDes: 4 lanes up to 10.3125GHz Supporting SGMII/QSGMII, XFI, PCIe, SATA and Aurora
- PCIe: Three PCI Express controllers with five PCIe slots.
- IFC: 128MB NOR Flash, 2GB NAND Flash, PromJet debug port and Qixis FPGA
- Video: DIU supports video up to 1280x1024x32 bpp.
- Chrontel CH7201 for HDMI connection.
- TI DS90C387R for direct LCD connection.
- Raw (not encoded) video connector for testing or other encoders.
- QUICC Engine block
- 32-bit RISC controller for flexible support of the communications peripherals
- Serial DMA channel for receive and transmit on all serial channels
- Two universal communication controllers, supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- eSPI: Three SPI flash devices.
- SATA: one SATA 2.O.
- USB: Two USB2.0 ports with internal PHY (one Type-A + one micro Type mini-AB)
- eSDHC: Support SD, SDHC, SDXC and MMC/eMMC.
- I2C: Four I2C controllers.
- UART: Two UART on board.
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
[York Sun: Fix ft_board_setup() type, fix MAINTAINERS for SECURE_BOOT
Fix Kconfig by adding SUPPORT_SPL]
Reviewed-by: York Sun <yorksun@freescale.com>
Add support for Freescale T1024/T1023 SoC.
The T1024 SoC includes the following function and features:
- Two 64-bit Power architecture e5500 cores, up to 1.4GHz
- private 256KB L2 cache each core and shared 256KB CoreNet platform cache (CPC)
- 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving support
- Data Path Acceleration Architecture (DPAA) incorporating acceleration
- Four MAC for 1G/2.5G/10G network interfaces (RGMII, SGMII, QSGMII, XFI)
- High-speed peripheral interfaces
- Three PCI Express 2.0 controllers
- Additional peripheral interfaces
- One SATA 2.0 controller
- Two USB 2.0 controllers with integrated PHY
- Enhanced secure digital host controller (SD/eSDHC/eMMC)
- Enhanced serial peripheral interface (eSPI)
- Four I2C controllers
- Four 2-pin UARTs or two 4-pin UARTs
- Integrated Flash Controller supporting NAND and NOR flash
- Two 8-channel DMA engines
- Multicore programmable interrupt controller (PIC)
- LCD interface (DIU) with 12 bit dual data rate
- QUICC Engine block supporting TDM, HDLC, and UART
- Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
- Support for hardware virtualization and partitioning enforcement
- QorIQ Platform's Trust Architecture 2.0
Differences between T1024 and T1023:
Feature T1024 T1023
QUICC Engine: yes no
DIU: yes no
Deep Sleep: yes no
I2C controller: 4 3
DDR: 64-bit 32-bit
IFC: 32-bit 28-bit
Signed-off-by: Shengzhou Liu <Shengzhou.Liu@freescale.com>
Reviewed-by: York Sun <yorksun@freescale.com>
XFI does not work stable on current board, it's due to heat sink issue,
to make it work stable the board needs additional heat sink, enable two
XFI lanes only. Right now we do not have such an erratum for the issue,
so use a define CONFIG_SYS_FSL_B4860QDS_XFI_ERR to identify it.
The workaround will only be used in XFI protocols and only if the
hwconfig indicates that XFI is prefered.
A new VSC3308 config function is used instead of re-use the original
function, to avoid making the function complex and ugly.
Signed-off-by: Shaohui Xie <Shaohui.Xie@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>
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>
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 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>
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>
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>
