There is a discrepency between U-Boot and Linux on the partition map.
This enabes the MTD parts to pass MTD partition information from U-Boot to
Linux. Linux already has a pending patch to enable MTD PARTS in
davinci_all_defconfig
Reviewed-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
With the device tree ported and DM compatible drivers, enable:
OF_CONTROL, DM_SPI, DM_SPI_FLASH and DM_SERIAL
Note: DM_SERIAL is not enabled for da850evm_direct_nor_defconfig
yet.
Reviewed-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
The DM support is already in the driver, so add
da830-spi to the compatible list.
Reviewed-by: Jagan Teki <jagan@openedev.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
A few small additional items are needed to support DM_SPI and
DM_SERIAL, so those were added to da850-evm-u-boot.dtsi
Signed-off-by: Adam Ford <aford173@gmail.com>
The MMC framework in U-Boot does not support a systematic API for
timing switch like mmc_set_timing() in Linux.
U-Boot just provides a hook to change the clock frequency via
mmc_set_clock(). It is up to drivers if additional register
settings are needed.
This driver needs to set a correct timing mode into a register when
it migrates to a different speed mode. Only increasing clock frequency
could result in setup/hold timing violation.
The timing mode should be decided by checking MMC_TIMING_* like
drivers/mmc/host/sdhci-cadence.c in Linux, but "timing" is not
supported by U-Boot for now. Just use mmc->clock to decide the
timing mode.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
If there are no CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR and CONFIG_SPL_OS_BOOT,
there is unused-function build warning. Add __maybe_unused macro
to remove the warning.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Add initial support for setting the vqmmc regulator. Since we do not
support 1V8 modes, set the regulator to 3V3 and enable it.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Old version of the uniphier-sd 64bit IO support patchset V1 was
applied by the maintainer, update the uniphier-sd.c with the
changes from the V3 of the patchset.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This patch adds SD/MMC support for STM32H7 SoCs.
Here is an extraction of SDMMC main features, embedded in
STM32H7 SoCs.
The SD/MMC block include the following:
_ Full compliance with MultiMediaCard System Specification
Version 4.51. Card support for three different databus modes:
1-bit (default), 4-bit and 8-bit.
_ Full compatibility with previous versions of MultiMediaCards
(backward compatibility).
_ Full compliance with SD memory card specifications version 4.1.
(SDR104 SDMMC_CK speed limited to maximum allowed IO speed,
SPI mode and UHS-II mode not supported).
_ Full compliance with SDIO card specification version 4.0.
Card support for two different databus modes: 1-bit (default)
and 4-bit. (SDR104 SDMMC_CK speed limited to maximum allowed IO
speed, SPI mode and UHS-II mode not supported).
_ Data transfer up to 208 Mbyte/s for the 8 bit mode.
(depending maximum allowed IO speed).
_ Data and command output enable signals to control external
bidirectional drivers.
The current version of the SDMMC supports only one SD/SDIO/MMC card
at any one time and a stack of MMC Version 4.51 or previous.
Signed-off-by: Christophe Kerello <christophe.kerello@st.com>
Signed-off-by: Patrice Chotard <patrice.chotard@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
At long last, nuke all this ad-hoc setup in board files in favor of
letting PFC pinmux and GPIO drivers do the same job, but based on DT
description of the hardware rather than this board-file ugliness.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Enable the PFC pinmux and GPIO drivers and disable the SH GPIO combo
driver. This allows the drivers to obtain pinmux and GPIO configuration
from DT rather than hard-coding it in board files.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add GPIO driver for the Renesas RCar SoCs . The driver currently supports
only the RCar Gen3 R8A7795 and R8A7796 SoCs, but is easily extensible for
the other RCar SoCs as well.
This driver is meant to replace the pinmux part of SH_GPIO_PFC driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add PFC pincontrol driver for the Renesas RCar Gen3 R8A7795 and R8A7796
SoCs. This driver uses the PFC pin tables from Linux, thus letting us
share the occassional fixes to those tables. This driver also has a DT
support, so the pinmux is configured from DT instead of the ad-hoc setup
in board file.
This driver is meant to replace the pinmux part of SH_GPIO_PFC driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Regulators are needed for the MMC framework to let it toggle the SD power.
Enable DM regulator support and support for fixed and GPIO regulator.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
The UniPhier SD driver handles the same Matsushita IP as is used
in the Renesas RCar SoCs, yet the driver is significantly better
than the SH SDHI one. Switch over to the Uniphier driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
During using dwc2 usb gadget, if usb message size is too small,
following cache misaligned warning is shown:
CACHE: Misaligned operation at range [bfdbcb00, bfdbcb04]
Align size of invalidating dcache before starting DMA to remove the
warning.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
The choice of "USB keyboard polling" cannot be optional as without
one mechanism being set, it just doesn't work. Set the default one
to CONFIG_SYS_USB_EVENT_POLL.
Fixes: ecad7051 ("configs: Migrate all of the existing USB symbols, except fastboot")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
When EHCD and xHCD are enabled at the same time, USB storage device
driver will fail to read/write from/to the storage device attached
to the xHCI interface, due to its transfer blocks exceeds the xHCD
driver limitation.
With driver model, we have an API to get the controller's maximum
transfer size and we can use that to determine the storage driver's
capability of read/write.
Note: the non-DM version driver is still broken with xHCD and the
intent here is not to fix the non-DM one, since the xHCD itself is
already broken in places like 3.0 hub support, etc.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
This adds a new memeber max_xfer_blk in struct us_data to record
the maximum number of transfer blocks for the storage device.
It is set per HCD setting, and so far is to 65535 for EHCD and 20
for everything else.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
EHCD can handle any transfer length as long as there is enough free
heap space left, hence set the theoretical max number SIZE_MAX.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
xHCD allocates one segment which includes 64 TRBs for each endpoint
and the last TRB in this segment is configured as a link TRB to form
a TRB ring. Each TRB can transfer up to 64K bytes, however data
buffers referenced by transfer TRBs shall not span 64KB boundaries.
Hence the maximum number of TRBs we can use in one transfer is 62.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
The HCD may have limitation on the maximum bytes to be transferred
in a USB transfer. USB class driver needs to be aware of this.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
The Linux kernel driver sets the number of event segments and entries
to 1 , while the initial import of the xhci code set that values to 3
for reasons unknown. While most controllers are fine with more event
segments with more entries, there are standard-conformant controllers
(ie. Renesas RCar xHCI) which only support 1 event segment.
Set the number of event segments and event entries back to 1 to allow
such controllers to work with U-Boot xHCI stack. Note that the Renesas
controller correctly indicates ERST Max = 1 in HCSPARAMS2[7:4] .
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
The content of Bank Address Register (BAR) is volatile. It is cleared
after power cycle or reset command (RESET F0h).
Some memories (like e.g. s25fl256s) use it to access memory larger than
0x1000000 (16 MiB).
The problem shows up when one:
1. Reads/writes/erases memory > 16 MiB
2. Calls "reset" u-boot command (which is not causing BAR to be cleared)
In the above scenario, the SoC ROM sends 0x000000 address to read SPL.
Unfortunately, the BA24 bit is still set and hence it receives content
from 0x1000000 (16 MiB) memory address.
As a result the SoC aborts and we hang. Only power cycle can take the
SoC out of this state.
How to reproduce/test:
sf probe; sf erase 0x1200000 0x800000; reset
sf probe; sf erase 0x1200000 0x800000; sf write 0x11000000 0x1200000 0x800000; reset
sf probe; sf read 0x11000000 0x1200000 0x800000; reset
Signed-off-by: Lukasz Majewski <lukma@denx.de>
[Fixed comment text on clean_bar function]
Signed-off-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The sunxi-specific SPI load routine only knows how to load a legacy
U-Boot image.
Teach it how to handle FIT images as well, simply by providing the
existing SPL FIT loader with the right loader routine to access the SPI
NOR flash.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reported-by: Peter Kosa <kope@madnet.sk>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
memset(newpart, '\0', sizeof(newpart));
only initializes the firest 4 or 8 bytes of *newpart and not the whole
structure disk_part.
We should use sizeof(struct disk_part).
Instead of malloc and memset we can use calloc.
Identified by cppcheck.
Fixes: 09a49930e4 GPT: read partition table from device into a data structure
Reported-by: Coverity (CID: 167228)
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
The status register is optional in the AMD command sets, but it's
presence can be checked by reading out CFI table entry 0xc bit 0.
If the register is present, prefer using it's bit 7 to determine
if the flash is busy over reading the flash ; this is needed ie.
on Hyperflash memories.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Embed the flash base into struct flash_info instead of having ad-hoc
static array in the code. This does not only remove static variable,
but also allows CFI-like controllers, ie. HyperFlash ones, to use most
of the CFI flash code by populating the flash_info with matching base
address.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
The ClearFog Base boot from UART when setting the DIP switches to 01001.
Unfortunately, the SPL code sometimes fails to detect the UART boot
method at run-time. Add an alternative SAR UART boot value to fix this.
Note that this alternative value is not documented (Armada 38x Hardware
Specifications, Table 48). But experimentations showed it on the
ClearFog Base.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Stefan Roese <sr@denx.de>
dram_ecc_scrubbing() had code to skip unused DRAM banks but it would not
work because mvebu_sdram_bs() returns 0 and the code was subtracting 1
before checking the size. Remove the -1 from the bank size and the +1
from the total which will skip unused banks and still calculate the
correct size. Put the -1 where it is needed for scrubbing via the xor
engine.
Reported-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
The Armada-38x has 1.8GHz and 2.0GHz variants. Add entries for these
variants to the sar_freq_tab.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
Display more information about the current RAM configuration. With these
changes the output on a 88F6820 board is
SoC: MV88F6820-A0 at 1600 MHz
DRAM: 2 GiB (800 MHz, 32-bit, ECC not enabled)
Signed-off-by: Joshua Scott <joshua.scott@alliedtelesis.co.nz>
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
These SoCs are network packet processors (switch chips) with integrated
ARMv7 cores. They share a great deal of commonality with the Armada-XP
CPUs.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Signed-off-by: Stefan Roese <sr@denx.de>
Currently, we support 2 "theadorable" MVEBU build targets. One with a
stripped down configuration (theadorable) and one with a full blown
configuration (theadorable_debug), including PCI, ethernet etc. When
we introduced these configs, the plan was to remove the debug version
at some point. But now it seems better to keep the full-blown version
and remove the "non-debug" version instead.
At a later stage, I will rename the remaining "theadorable_debug"
target into a more fitting one.
Signed-off-by: Stefan Roese <sr@denx.de>
This converts the following to Kconfig:
CONFIG_MVNETA
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Stefan Roese <sr@denx.de>
In some of the QSPI controller version, there must be atleast
128bit data available in TX FIFO for any pop operation otherwise
error bit will be set. The code will not make any behavior change
for previous controller as the transfer data size in ipcr register
is still the same.
Patch is tested on LS1046A which do not require 16 bytes aligned and
LS1088A which require 16 bytes aligned data in TX FIFO
Signed-off-by: Suresh Gupta <suresh.gupta@nxp.com>
Signed-off-by: Anupam Kumar <anupam.kumar_1@nxp.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Spansion S25FS256S and S25FL256S flashes have equal JEDEC ID and ext ID.
As far as S25FL256S occures in spi_flash_ids before S25FS256S, U-Boot
incorrectly detects FS flash as FL. Thus its better to compare with
S25FS256S first.
Signed-off-by: Vsevolod Gribov <vgribov@larch-networks.com>
[Added S-o-b]
Signed-off-by: Jagan Teki <jagan@openedev.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The flash chip is 2 MiB , organized as 32 x 64 kiB sectors .
Rectify the entry to match the datasheet, reality and Linux SNOR IDs.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Adam Ford
Tom Rini
Masahiro Yamada
Seung-Woo Kim
Marek Vasut
Patrice Chotard
rick
Bin Meng
Philipp Tomsich
Lukasz Majewski
Andre Przywara
Heinrich Schuchardt
Baruch Siach
Chris Packham
Joshua Scott
Stefan Roese
Suresh Gupta
Vsevolod Gribov
Marek Vasut