| Age | Commit message (Collapse) | Author |
|---|
|
This patch add EMAC driver support for H3/A83T/A64 SoCs.
Tested on Pine64(A64-External PHY) and Orangepipc(H3-Internal PHY).
BIG Thanks to Andre for providing some of the DT code.
Signed-off-by: Amit Singh Tomar <amittomer25@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
With a recent bunch of SD3.0 cards in our A20-based board we
experienced data transfer rates of about 250 KiB/s instead of 10 MiB/s
with previous cards from the same vendor (both 4 GB/class 10). By
increasing status register polling rate from 1 kHz to 1 MHz we were
able to reach the original transfer rates again. With the old cards
we now even reach about 16 MiB/s.
Signed-off-by: Tobias Doerffel <tobias.doerffel@ed-chemnitz.de>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
Allwinner devices support SPI flash as one of the possible
bootable media type. The SPI flash chip needs to be connected
to SPI0 pins (port C) to make this work. More information is
available at:
https://linux-sunxi.org/Bootable_SPI_flash
This patch adds the initial support for booting from SPI flash.
The existing SPI frameworks are not used in order to reduce the
SPL code size. Right now the SPL size grows by ~370 bytes when
CONFIG_SPL_SPI_SUNXI option is enabled.
While there are no popular Allwinner devices with SPI flash at
the moment, testing can be done using a SPI flash module (it
can be bought for ~2$ on ebay) and jumper wires with the boards,
which expose relevant pins on the expansion header. The SPI flash
chips themselves are very cheap (some prices are even listed as
low as 4 cents) and should not cost much if somebody decides to
design a development board with an SPI flash chip soldered on
the PCB.
Another nice feature of the SPI flash is that it can be safely
accessed in a device-independent way (since we know that the
boot ROM is already probing these pins during the boot time).
And if, for example, Olimex boards opted to use SPI flash instead
of EEPROM, then they would have been able to have U-Boot installed
in the SPI flash now and boot the rest of the system from the SATA
hard drive. Hopefully we may see new interesting Allwinner based
development boards in the future, now that the software support
for the SPI flash is in a better shape :-)
Testing can be done by enabling the CONFIG_SPL_SPI_SUNXI option
in a board defconfig, then building U-Boot and finally flashing
the resulting u-boot-sunxi-with-spl.bin binary over USB OTG with
a help of the sunxi-fel tool:
sunxi-fel spiflash-write 0 u-boot-sunxi-with-spl.bin
The device needs to be switched into FEL (USB recovery) mode first.
The most suitable boards for testing are Orange Pi PC and Pine64.
Because these boards are cheap, have no built-in NAND/eMMC and
expose SPI0 pins on the Raspberry Pi compatible expansion header.
The A13-OLinuXino-Micro board also can be used.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
|
|
|
|
For consistency with board_should_run_oprom(), do the same to
should_load_oprom(). Board support codes can provide this one
to override the default weak one.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
At present should_load_oprom() calls board_should_run_oprom() to
determine whether oprom should be loaded. But sometimes we just
want to load oprom without running. Make them independent.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
This option is defined at nowhere. Remove it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
|
|
|
|
The cros-ec keyboard is always a child of the cros-ec node. Rather than
searching the device tree, looking at the children. Remove the compat string
which is now unused.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Define a platform data structure for the MPC85XX GPIO driver to allow
use of the driver without device tree. Users should define the GPIO
blocks for their platform like this:
struct mpc85xx_gpio_plat gpio_blocks[] = {
{
.addr = 0x130000,
.ngpios = 32,
},
{
.addr = 0x131000,
.ngpios = 32,
},
};
U_BOOT_DEVICES(my_platform_gpios) = {
{ "gpio_mpc85xx", &gpio_blocks[0] },
{ "gpio_mpc85xx", &gpio_blocks[1] },
};
This is intended to build upon the recent submission of the base
MPC85XX driver from Mario Six. We need to use that new driver
without dts support and this patch gives us that flexibility.
This has been tested on a Freescale T2080 CPU, although only the first
GPIO block.
Signed-off-by: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
Reviewed-by: Mario Six <mario.six@gdsys.cc>
Tested-by: Mario Six <mario.six@gdsys.cc>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
Update the method of accessing the block device so that it works with
CONFIG_BLK enabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Now that we have fully moved to driver model, drop the old code.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add support for using driver model for block devices and MMC operations in
this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add support for using driver model for block devices and MMC operations in
this driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move the configuration setting into a separate function which can be used by
the driver-model code.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Update the sandbox MMC emulation to use driver model for MMC operations.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Enable this option to move rockchip over to use driver model for MMC
operations.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Add support to dwmmc for using driver model for MMC operations.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
The driver model conversion for MMC has moved in small steps. The first step
was to have an MMC device (CONFIG_DM_MMC). The second was to use a child
block device (CONFIG_BLK). The final one is to use driver model for MMC
operations (CONFIG_DM_MMC_OP). Add support for this.
The immediate priority is to make all boards that use DM_MMC also use those
other two options. This will allow them to be removed.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Move this code into separate functions so that it can be used from the uclass
also. Add static inline versions for when the option is disabled.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Since all Rockchip boards use CONFIG_BLK, we can remove this old code.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than having an #ifdef in the main mmc.c file, control this feature
from the Makefile by moving the code into its own file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than having #ifdef in mmc.c, move this code into the legacy file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
Rather than having #ifdef in mmc.c, move this code into the uclass file.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
These private functions are used both in the driver-model implementation and
in the legacy code. Add them to the header.
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
In case of DT boot, don't read default speed and mode for SPI from
CONFIG_*, instead read from DT node. This will make sure that boards
with multiple SPI/QSPI controllers can be probed at different
bus frequencies and SPI modes.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
Instead of relying on CONFIG_SPI_FLASH_QUAD to be defined to enable QUAD
mode, make use of mode_rx field of dm_spi_slave_platdata to determine
whether to enable or disable QUAD mode. This is necessary to support
muliple SPI controllers where one of them may not support QUAD mode.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
AHB address can be as long as 32 bit, hence remove the
CQSPI_REG_INDIRECTRDSTARTADDR mask. Since AHB address is passed from DT
and read as u32 value, it anyway does not make sense to mask upper bits.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Tested-by: Marek Vasut <marex@denx.de>
Acked-by: Marek Vasut <marex@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
Convert davinci_spi driver so that it complies with SPI DM framework.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
This API helps to map physical register addresss pace of device to
virtual address space easily. Its just a wrapper around map_physmem()
with MAP_NOCACHE flag.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Suggested-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jagan Teki <jteki@openedev.com>
|
|
MMC core expects (now) valid mmc->dev pointer.
During conversion in commit cffe5d86 not every driver was updated.
This patch fixes crash while accessing MMC on
boards using Qualcomm SDHCI controller.
Signed-off-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
Return value of rtl_send_common propogates unmodified all the way
up to eth_send and further to API consumer if CONFIG_API is enabled.
Previously rtl_send_common returned number of bytes sent on success
which was erroneouly detected as error condition by API consumers
that checked for operation success by comparing return value with 0.
Switch rtl_send_common to use common convention: return 0 on success
and negative value for failure.
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Signed-off-by: Oleksandr Tymoshenko <gonzo@bluezbox.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
This patch adds support for aquantia AQR106/107 PHY.
Signed-off-by: Mingkai Hu <mingkai.hu@nxp.com>
Signed-off-by: Gong Qianyu <Qianyu.Gong@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Commit 90b7fc924adf "net: designware: support phy reset device-tree
bindings" made DW GMAC driver dependent on DM_GPIO by unconditional
usage of purely DM_GPIO stuff like:
* dm_gpio_XXX()
* gpio_request_by_name()
But since that driver as of today might be easily used without
DM_GPIO (that's the case for Synopsys AXS10x boards) we're
shielding all DM_GPIO things by ifdefs.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Beniamino Galvani <b.galvani@gmail.com>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Sonic Zhang <sonic.zhang@analog.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
|
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Jagan Teki <jteki@openedev.com>
|
|
This seems to give the best performance, so let's use it always.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
We have standard drivers for panels and backlights which can do most of the
work for us. Move the tegra20 LCD driver over to use those instead of custom
code.
This patch includes device tree changes for the nvidia boards. I have only
been able to test seaboard. If this patch is applied, these boards will
also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tec
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
On recent SoCs, tegra_pcie_phy_enable() isn't called; but instead
tegra_pcie_enable_controller() calls tegra_xusb_phy_enable(). However,
part of tegra_pcie_phy_enable() needs to happen in all cases. Move that
code to tegra_pcie_port_enable() instead.
For reference, NVIDIA's downstream Linux kernel performs this operation
in tegra_pcie_enable_rp_features(), which is called immediately after
tegra_pcie_port_enable(). Since that function doesn't exist in the U-Boot
driver, we'll just add it to the tail of tegra_pcie_port_enable() instead.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
The value that should be programmed into the PADS_REFCLK register varies
per SoC. Fix the Tegra PCIe driver to program the correct values. Future
SoCs will require different values in cfg0/1, so the two values are stored
separately in the per-SoC data structures.
For reference, the values are all documented in NV bug 1771116 comment 20.
The Tegra210 value doesn't match the current TRM, but I've filed a bug to
get the TRM fixed. Earlier TRMs don't document the value this register
should contain, but the ASIC team has validated all these values, except
for the Tegra20 value which is simply left unchanged in this patch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
|
|
Waiting 30 seconds for the hpd to go high seems a bit much, especially
on headless boots. Lowering the timeout to 300ms.
Sending as RFC because frankly i don't know what a sensible timeout is
here, but 30 seconds is clearly not it :)
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Dropped RFC tag:
Signed-off-by: Simon Glass <sjg@chromium.org>
|
|
|
|
|
|
Otherwise, ocassionally see errors like this:
Flashing sparse image at offset 2078720
Flashing Sparse Image
sdhci_send_command: Timeout for status update!
mmc fail to send stop cmd
write_sparse_image: Write failed, block #2181088 [0]
This does not affect the actual writing speed, which is controlled by
the default value:
CONFIG_SDHCI_CMD_DEFAULT_TIMEOUT
It only increases the retries when reading:
SDHCI_INT_STATUS
to avoid the timeout error.
Signed-off-by: Steve Rae <steve.rae@raedomain.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
|
|
Correcting QSPI disable/unselect CS reset value.
CTRL_CORE_CONTROL_IO_2: QSPI_MEMMAPPED_CS[10:8]
This is not causing any issue, but its better
to untouch the reserved bits.
Praneeth Bajjuri <praneeth@ti.com>
Signed-off-by: Ravi Babu <ravibabu@ti.com>
|
|
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
SPL does not use all of the devices, so we can save some memory
footprint.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
PH1-LD4 and PH1-sLD8 SoCs have pins that support pin configuration
(pin biasing, drive strength control), but not pin-muxing.
Allow to fill the mux value table with -1 for those pins; pins with
mux value -1 will be skipped in the pin-mux set function. The mux
value type should be changed from "unsigned" to "int" in order to
accommodate -1 as a special case.
[ Linux commit: 363c90e743b50a432a91a211dd8b078d9df446e9 ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
PH1-LD11 and PH1-LD20 have much pin controlling in common, so I
added a single driver shared between them in the initial commit.
However, the Ethernet pin-mux settings I am going to add are
different with each other, and they may diverge more as the
progress of development. Split it into two dedicated drivers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
