HDMI output must be enabled very early to also enable the pre-console buffer
Signed-off-by: Soeren Moch <smoch@web.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>
This commit moved the SPL stack into SRAM C, which worked when the SPL
set the AHB1 clock down to 100 MHz to cope with the flaky SRAM C access
from the CPU.
However booting with boot0 (and thus not using SPL at all) we still run
with a 200 MHz AHB1, so any access to SRAM C is prone to fail.
Since this commit does _not_ only affect the SPL code, but also the
U-Boot proper, we fail when booting with boot0.
As the introduction of tiny-printf reduced the size of the SPL, we
can afford to have the SPL stack in SRAM A1.
This reverts commit 1a83fb4a17
and fixes booting the Pine64 when using boot0.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The Colorado TK1 SOM is a small form factor board similar to the
Jetson TK1. The main differences lie in the pinmux, and in that the
PCIe controller is set to use in 4lanes+1lane, rather than 2+2.
The pinmux header here was generated from a spreadsheet provided by
Colorado Engineering using the tegra-pinmux scripts. The spreadsheet
was converted from v09 to v11 by me.
Signed-off-by: Peter Chubb <peter.chubb@data61.csiro.au>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
This supports the system reset via PSCI for ARMv7 SoCs.
Because the system reset is not supported on PSCI 0.1, let's define
CONFIG_ARMV7_PSCI_1_0. (it is supported since PSCI 0.2, but there
is no CONFIG to enable it in U-Boot for now.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This series moves the CONFIG_SYS_CACHELINE_SIZE. First, in nearly all
cases we are mirroring the values used by the Linux Kernel here. Also,
so long as (and in this case, it is true) we implement flushes in hunks
that are no larger than the smallest implementation (and given that we
mirror the Linux Kernel, again we are fine) it is OK to align higher.
The biggest changes here are that we always use 64 bytes for CPU_V7 even
if for example the underlying core is only 32 bytes (this mirrors
Linux). Second, we say ARM64 uses 64 bytes not 128 (as found in the
Linux Kernel) as we do not need multi-platform support (to this degree)
and only the Cavium ThunderX 88xx series has a use for such large
alignment.
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Prafulla Wadaskar <prafulla@marvell.com>
Cc: Luka Perkov <luka.perkov@sartura.hr>
Cc: Stefan Roese <sr@denx.de>
Cc: Nagendra T S <nagendra@mistralsolutions.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Steve Rae <steve.rae@raedomain.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Nikita Kiryanov <nikita@compulab.co.il>
Cc: Stefan Agner <stefan.agner@toradex.com>
Acked-by: Heiko Schocher <hs@denx.de>
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Cc: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Paul Kocialkowski <contact@paulk.fr>
Cc: Anatolij Gustschin <agust@denx.de>
Acked-by: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Adam Ford <aford173@gmail.com>
Cc: Steve Sakoman <sakoman@gmail.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Nishanth Menon <nm@ti.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Robert Baldyga <r.baldyga@samsung.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Cc: Thomas Weber <weber@corscience.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: David Feng <fenghua@phytium.com.cn>
Cc: Alison Wang <b18965@freescale.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: York Sun <york.sun@nxp.com>
Cc: Shengzhou Liu <Shengzhou.Liu@nxp.com>
Cc: Mingkai Hu <mingkai.hu@nxp.com>
Cc: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Cc: Aneesh Bansal <aneesh.bansal@freescale.com>
Cc: Saksham Jain <saksham.jain@nxp.com>
Cc: Qianyu Gong <qianyu.gong@nxp.com>
Cc: Wang Dongsheng <dongsheng.wang@nxp.com>
Cc: Alex Porosanu <alexandru.porosanu@freescale.com>
Cc: Hongbo Zhang <hongbo.zhang@nxp.com>
Cc: tang yuantian <Yuantian.Tang@freescale.com>
Cc: Rajesh Bhagat <rajesh.bhagat@nxp.com>
Cc: Josh Wu <josh.wu@atmel.com>
Cc: Bo Shen <voice.shen@atmel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Hannes Schmelzer <oe5hpm@oevsv.at>
Cc: Thomas Chou <thomas@wytron.com.tw>
Cc: Joe Hershberger <joe.hershberger@ni.com>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Christophe Ricard <christophe-h.ricard@st.com>
Cc: Anand Moon <linux.amoon@gmail.com>
Cc: Beniamino Galvani <b.galvani@gmail.com>
Cc: Carlo Caione <carlo@endlessm.com>
Cc: huang lin <hl@rock-chips.com>
Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Xu Ziyuan <xzy.xu@rock-chips.com>
Cc: "jk.kernel@gmail.com" <jk.kernel@gmail.com>
Cc: "Ariel D'Alessandro" <ariel@vanguardiasur.com.ar>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Samuel Egli <samuel.egli@siemens.com>
Cc: Chin Liang See <clsee@altera.com>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ian Campbell <ijc@hellion.org.uk>
Cc: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Bernhard Nortmann <bernhard.nortmann@web.de>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Ben Whitten <ben.whitten@gmail.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Sekhar Nori <nsekhar@ti.com>
Cc: Vitaly Andrianov <vitalya@ti.com>
Cc: "Andrew F. Davis" <afd@ti.com>
Cc: Murali Karicheri <m-karicheri2@ti.com>
Cc: Carlos Hernandez <ceh@ti.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Ash Charles <ashcharles@gmail.com>
Cc: Mugunthan V N <mugunthanvnm@ti.com>
Cc: Daniel Allred <d-allred@ti.com>
Cc: Gong Qianyu <Qianyu.Gong@freescale.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Chin Liang See <clsee@altera.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Paul Kocialkowski <contact@paulk.fr>
As of commit 88e34e5 ("spl: replace CONFIG_SPL_SPI_* with
CONFIG_SF_DEFAULT_*") these defines are not used. Remove them to avoid
confusion.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This command is used to boot ARM64 Linux.
I made DISTRO_DEFAULTS select this option for ARM64 to respect
include/config_distro_defaults.h.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
BLANCHE is development board based on R-Car V2H SoC (R8A7792)
This commit supports the following periherals:
- SCIF, Ethernet, QSPI, MMC
Signed-off-by: Masakazu Mochizuki <masakazu.mochizuki.wd@hitachi.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Salvator-x is an entry level development board based on
R-Car H3 SoC (R8A7795). This commit supports SCIF only.
Signed-off-by: Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
This patch adds support for the DFI BayTrail BT700 QSeven SoM installed
on the DFI Q7X-151 baseboard. The baseboard is equipped with the Nuvoton
NCT6102D Super IO chip providing the UART as console.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch includes the following changes:
- Remove Designware I2C support from dts as its not used
- Configure SMBus PADs in dts
- Enable I2C commands and I2C support
- Configure SMSC2513 USB hub via SMBus upon startup
- Move environment location to match Minnowmax example
- Enhancement of the default environment
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The 'xtfpga' board is actually a set of FPGA evaluation boards that
can be configured to run an Xtensa processor.
- Avnet Xilinx LX60
- Avnet Xilinx LX110
- Avnet Xilinx LX200
- Xilinx ML605
- Xilinx KC705
These boards share the same components (open-ethernet, ns16550 serial,
lcd display, flash, etc.).
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Add Kconfig entry for the driver, remove #define CONFIG_ETHOC from the
only board configuration that uses it and put it into that board's
defconfig.
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Use the right phy_connect() prototype for CONFIGF_DM_ETH.
Support to get the phy interface from dt and set GMAC_UR.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Trimslice currently stores its environment at 512KiB into the SPI flash
chip. The U-Boot binary has grown such that the size of the boot image
(which includes the Tegra BCT, padding, and the U-Boot binary) is slightly
larger than 512K now. Consequently, writing the boot image to flash
corrupts the saved environment, and equally, writing to or erasing the
environment will corrupt the bootloader, which in turn will cause the
Tegra boot ROM to enter recovery mode during boot, making it look as if
the system is non-operational. Note that tegra-uboot-flasher writes to
the environment during the flashing process.
Solve this by moving the environment as high as possible in flash. This
will allow the U-Boot binary to roughly double in size before this problem
is hit again, at which point there's nothing we can do anyway since the
binary won't fit into flash.
99% of other Tegra boards store the environment in eMMC and use a negative
value for CONFIG_ENV_OFFSET, which already automatically places the
environment as near the end of boot flash as possible. The 1 remaining
board hard-codes CONFIG_ENV_OFFSET to 2MiB, which allows for plenty more
bloat.
Reported-by: Stephen L Arnold <nerdboy@gentoo.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
p2771-0000 has a couple of PCIe ports; one physically x4 desktop PCI
connector (which may run at x2 electrically, depending on the board
version and configuration) and a x1 connection to the M.2 slot (which may
not be active, depending on the board version and configuration). This
change enables those.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The UniPhier outer cache (L2 cache on ARMv7 SoCs) has 128 byte line
length and its tags are also managed per 128 byte line.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Move this option to Kconfig, renaming it into CONFIG_CACHE_UNIPHIER.
The new option name makes sense enough, and the same as Linux has.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The devicetrees for various platforms already exceed 16k. Add a define
CONFIG_SYS_FDT_SIZE to specify the FDT size, and set to 16k for the
two boards that define this CONFIG_SYS_FDT_BASE parameter. This
allows platforms with larger devicetree blobs to boot from NOR.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
The meaning of CONFIG_USB in U-Boot is different from that in Linux.
As you see in drivers/usb/Kconfig of Linux, CONFIG_USB enables the
USB host controller support, while CONFIG_USB_SUPPORT is used to
enable the whole of the USB sub-system.
When I added CONFIG_USB into Kconfig by commit 6e7e9294d3 ("usb:
add basic USB configs in Kconfig"), I planned to follow the Linux's
convention, i.e. CONFIG_USB to enable/disable the USB host support.
Then, commit 68f7c5db2d ("usb: Generic USB Kconfig option, that
fits both host and gadget and comments") changed the logic of the
CONFIG_USB to point to the whole of the USB sub-system. As a result,
currently we do not have an option for USB host.
This commit adds CONFIG_USB_HOST, which will be useful to compile
in the USB host support code.
CONFIG_USB_HOST is not referenced at all, but strangely some boards
define it in board headers. I removed them because USB_HOST will be
selected in Kconfig going forward.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This follows 9fd383724c ("mmc: don't allow extra cmdline arguments"),
and affects omapl138_lcdk and omap3_evm_quick_mmc.
Signed-off-by: Karl Beldan <kbeldan@baylibre.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
These config targets were added well before the Kconfig migration began
as a way to demonstrate how to make these platforms work with cut down
features. At this point in time they no longer serve a good purpose so
remove them.
Signed-off-by: Tom Rini <trini@konsulko.com>
Enable the rockchip dwmmc driver for rk3399 and its evb.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Simon Glass <sjg@chromium.org>
Enable ums feature for rk3288 boards, so that we can mount the mmc
device to PC.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
For compatibility with distro boot, fastboot, and mount the mmc deivce
to PC via usb mass storage feature, GPT partitions are essential.
You should write the partitions to mmc device prior to use above
feature.
=> gpt write mmc 1 $partitions
GPT successfully written to block device!
success!
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Miniarm is a rockchip rk3288 based development board, which has lots of
interface such as HDMI, USB, micro-SD card, Audio etc.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Enable fastboot feature on rk3036, please refer to doc/README.rockchip
for more detailed usage.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We need to ensure that CONFIG_PHYS_64BIT is configured via Kconfig so
that it is always available to the build system. Otherwise we can run
into cases where we have inconsistent sizes of certain attributes.
Ravi Babu reported offset mismatch of struct dwc3 across files since
commit 95ebc253e6 ("types.h: move and redefine resource_size_t").
Since the commit, resource_addr_t points to phys_addr_t, whose size
is dependent on CONFIG_PHYS_64BIT for ARM architecture.
I tried my best to use "select" where possible (for example, ARMv8
architecture) because I think this kind of option is generally user-
unconfigurable. However, I see some of PowerPC boards have 36BIT
defconfigs as well as 32BIT ones. I moved CONFIG_PHYS_64BIT to the
defconfigs for such boards.
CONFIG_36BIT is no longer referenced, so all of the defines were
removed from CONFIG_SYS_EXTRA_OPTIONS.
Fixes: 95ebc253e6 ("types.h: move and redefine resource_size_t")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Ravi Babu <ravibabu@ti.com>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: York Sun <york.sun@nxp.com>
As of now we have 2 flavors of ARC SDP boards:
1) AXS101 - with ARC770 in ASIC
2) AXS103 - with ARC HS38 in FPGA
Both options share exactly the same base-board and only differ with
CPU-tiles in use. That means all peripherals are the same (they are
implemented in FPGA on the base-board) and so generic board could be
used for both.
While at it:
* Recreated defconfigs with savedefconfig
* In include/configs/axs10x.h numerical sizes replaced with
defines from linux/sizes.h for better readability.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
ARCangel was one of the main development boards back in the day but
now it's gone and replaced by other boards like ARC SDP.
But we also used to have simulation platform very similar to ARCangel4
in terms of CPU settings as well as basic IO like UART. Even though
ARCangel4 is long gone now we have a replacement for simulation which is
a plain or stand-alone nSIM and Free nSIM.
Note Free nSIM is available for download here:
https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi
And while at it:
* Finally switch hex numerical values in nsim.h to defines from
include/linux/sizes.h
* Add defconfigs with ARC HS38 cores
* Recreated all defconfigs with savedefconfig
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This is what Linux maps on classic PPC during boot, and modern kernel
images don't fit within the current 8 MiB uncompressed limit.
Adjust image load addresses to be above this limit to avoid conflicts.
Signed-off-by: Scott Wood <oss@buserror.net>
Reviewed-by: York Sun <york.sun@nxp.com>
The PPA binary may be stored on QSPI flash instead of NOR.
So, deprecated CONFIG_SYS_LS_PPA_FW_IN_NOR in favour of
CONFIG_SYS_LS_PPA_FW_IN_XIP to prevent fragmentation of code
by addition of a new QSPI specific flag.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
qixis_reset altbank usagge ~QIXIS_LBMAP_MASK in code. So define
inverse value QIXIS_LBMAP_MASK.
Also, update QIXIS_RST_CTL_RESET value to keep RST_CTL[REQ_MOD]
as 0b11 i.e. PORESET during qixis_reset
Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
PopMetal is a rockchip rk3288 based board made by ChipSpark, which has
many interface such as HDMI, VGA, USB, micro-SD card, WiFi, Audio and
Gigabit Ethernet.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Fennec is a RK3288-based development board with 2 USB ports, HDMI,
micro-SD card, audio and WiFi and Gigabit Ethernet. It also includes
on-board 8GB eMMC and 2GB of SDRAM. Expansion connectors provides access
to display pins, I2C, SPI, UART and GPIOs.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
The 'evb-rk3288' is not a vendor name, change it to 'rockchip' which is
the real vendor name.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
CONFIG_SYS_LOAD_ADDR is absolutely safe to store image for
fastboot.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
CONFIG_DOS_PARTITION and CONFIG_EFI_PARTITION are already included in
config_distro_defaults.h, and we don't need them in SPL stage.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
The CONFIG_ROCKCHIP_COMMON and CONFIG_SPL_ROCKCHIP_COMMON are no use now,
remove them.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
AM571x IDK and AM572x IDK EVMs have spansion s25fl256s QSPI flash on the
board connected to TI QSPI IP over CS0. Therefore enable QSPI support.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Now that QSPI driver can support 76.8MHz, update the
CONFIG_SF_DEFAULT_SPEED to the same value.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Jagan Teki <jteki@openedev.com>
Reviewed-by: Mugunthan V N <mugunthanvnm@ti.com>
Use CONFIG_TIMER_CLK_FREQ to let the non-secure init code initialize
the generic timer on all CPU's. This allows to make use of the timer
freuquency register also on other CPU than the start CPU which is
important for KVM.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
cgtqmx6eval uses the imx_ddr_size() function to calculate the DDR size in
runtime, so there is no need to define PHYS_SDRAM_SIZE.
Remove the unneeded definition.
Cc: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
novena uses the imx_ddr_size() function to calculate the DDR size in
runtime, so there is no need to define PHYS_SDRAM_SIZE.
Remove the unneeded definition.
Cc: Marek Vasut <marex@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Marek Vasut <marex@denx.de>
imx_ddr_size() can be used to calculate the DDR size in runtime.
By using this function we no longer need to define PHYS_SDRAM_SIZE.
Cc: Martin Donnelly <martin.donnelly@ge.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
imx_ddr_size() can be used to calculate the DDR size in runtime.
By using this function we no longer need to define PHYS_SDRAM_SIZE.
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Heiko Schocher <hs@denx.de>
imx_ddr_size() can be used to calculate the DDR size in runtime.
By using this function we no longer need to define PHYS_SDRAM_SIZE.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Currently it's recommended to move some configuration options to the
defconfig file.
Move some USB related options to the defconfig file.
Signed-off-by: Breno Lima <breno.lima@nxp.com>
This commit adds support for the Toradex Computer on Modules
Colibri iMX7S/iMX7D. The two modules/SoC's are very similar hence
can be easily supported by one board. The board code detects RAM
size at runtime which is one of the differences between the two
boards. The board also uses the UART's in DTE mode, hence making
use of the new DTE support via serial DM.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
The hwconfig env var allows user to control hardware specific configuration
of board specific features but not all Ventana boards have the same features.
We will use the magic default value of "_UNKNOWN_" to signify that the
bootloader should create this based on detected board model.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
3b1f681131 caused a regression that removes
board info dispaly for Gateworks Ventana boards because it made the invalid
assumption that CONFIG_DISPLAY_BOARDINFO_LATE was the same thing as
CONFIG_DISPLAY_BOARDINFO.
Ventana needs to call show_board_info in late init because we need to have
the i2c eeprom based model info. Re-define CONFIG_DISPLAY_BOARDINFO_LATE
to allow that to happen.
Cc: Peter Robinson <pbrobinson@gmail.com>
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
The IMX6 PCIe host controller does not have a proper reset and as such there
are several issues that can arise if PCI is enabled in the bootloader follwed
by Linux trying to re-configure LTSSM and/or toggling PERST# to the devices.
For now, the best approach seems to default to disabling PCI by defaulting
pciedisable=1. This can be overridden by the user if they need PCI in the
bootloader, for example:
- GW552x needing ethernet access in bootloader
- GW16082 expansion board needing a device-tree fixup for irq mapping
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
USB gadget configuration is set in defconfig and
must be removed from pico-imx6ul.h.
Signed-off-by: Stefano Babic <sbabic@denx.de>
CC: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Add and share the the MTD partition scheme with kernel by default
bootargs. And add the "mtdparts" env.
Signed-off-by: Wenbin Song <wenbin.song@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Cleanup the variables: "kernel_addr","ramdisk_addr",
"ramdisk_size","console".
Signed-off-by: Wenbin Song <wenbin.song@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
LS1021 offers two secure OCRAM blocks for trustzone.
This patch moves all the secure text sections into the OCRAM.
Signed-off-by: Wang Dongsheng <dongsheng.wang@nxp.com>
Signed-off-by: Hongbo Zhang <hongbo.zhang@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
This patch implements PSCI functions for ls102xa SoC following PSCI v1.0,
they are as the list:
psci_version,
psci_features,
psci_cpu_suspend,
psci_affinity_info,
psci_system_reset,
psci_system_off.
Tested on LS1021aQDS, LS1021aTWR.
Signed-off-by: Wang Dongsheng <dongsheng.wang@nxp.com>
Signed-off-by: Hongbo Zhang <hongbo.zhang@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Add SD secure boot target for ls1021atwr.
Implement board specific spl_board_init() to setup CAAM stream ID and
corresponding stream ID in SMMU. Change the u-boot size defined by a
macro for copying the main U-Boot by SPL to also include the u-boot
Secure Boot header size as header is appended to u-boot image. So header
will also be copied from SD to DDR.
Reviewed-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: York Sun <york.sun@nxp.com>
Enable i2c driver model for am335x_boneblack_vboot as omap i2c
supports driver model. Also enable CONFIG_DM_I2C_COMPAT for
legacy drivers of i2c devices.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Since omap's spl doesn't support DM currently, do not define
DM_I2C for spl build.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
RK3399 is a SoC from Rockchip with dual-core Cortex-A72
and quad-core Cortex-A53 CPU. It supports two USB3.0
type-C ports and two USB2.0 EHCI ports. Other interfaces
are very much like RK3288, the DRAM are 32bit width address
and support address from 0 to 4GB-128MB range.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Enable fastboot feature on rk3288.
This path doesn't support the fastboot flash function command entirely.
We will hit "cannot find partition" assertion without specified
partition environment. Define gpt partition layout in specified board
such as firefly-rk3288, then enjoy it!
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
evb-3288 board RK3288-based development board with 2 USB ports, HDMI,
VGA, micro-SD card, audio, WiFi and Gigabit Ethernet. It also includes
on-board 8G eMMC and 2GB of SDRAM. Expansion connector provide access to
display pins, I2C, SPI, UART and GPIOs. This add some basic files
required to allow the board to output serial messaged and can run
command(mmc info etc).
evb-rk3288 also supports booting from eMMC or SD card, the default is eMMC.
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
If we would like to boot from SD card, we have to implement mmc driver
in SPL stage, and get a slightly large SPL binary. Rockchip SoC's
bootrom code has the ability to load spl and u-boot, then boot.
If CONFIG_ROCKCHIP_SPL_BACK_TO_BROM is enabled, the spl will return to
bootrom in board_init_f(), then bootrom loads u-boot binary.
Loading sequence after rework:
bootrom ==> spl ==> bootrom ==> u-boot
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Fixed up spelling of U-Boot, boorom, opinion->option, Rochchip:
Signed-off-by: Simon Glass <sjg@chromium.org>
Most users of CONFIG_I2C_EEPROM were migrated to defconfig a while ago,
but sandbox was skipped. Leave it off for sandbox_spl where it does not
build, but does not need to be either.
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Sandbox is built with 64-bit ints by default. This doesn't work properly on
32-bit machines.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
On some sunxi boards we have NANDs exposing 1664 OOB bytes per page.
Define the CONFIG_SYS_NAND_MAX_ECCPOS value accordingly.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
We already have an SPL driver for the sunxi NAND controller, now add
the normal/standard one.
The source has been copied from Linux 4.6 with a few changes to make
it work in u-boot.
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Convert IGEP board to use UBI volumes for U-Boot, its environment and
kernel. With exception of first four sectors read by SoC boot
ROM whole (One)NAND is UBI managed.
Also merge NAND and OneNAND defconfigs as now one binary can serve
both flashes.
As code is too big now, drop CONFIG_SPL_EXT_SUPPORT to make it fit.
Signed-off-by: Ladislav Michl <ladis@linux-mips.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Remove unnecessary board specifc config files for
zynq boards(microzed, picozed, ZC770(all), zed) and point
to zynq common config file.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Enable config CONFIG_SYS_NO_FLASH through defconfig
for all zynq boards.
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Define config USB_STORAGE through defconfig for all
respective zynq boards
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Add Kconfig entry config option for USB_EHCI_ZYNQ
and update the same to enable for all zynq boards
which supports USB
Signed-off-by: Siva Durga Prasad Paladugu <sivadur@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The EP platform also has working AHCI emulation, so I see little reason
not to implement the plumbing for it that enables us to boot from AHCI.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Loading the fdt at 0xc00000 fails if the uncompressed kernel image is
greater than 12 MiB, which is quite common with modern kernels and
multiplatform defconfigs. Move fdtaddr to 0x1e00000 which is just under
the ramdiskaddr on most targets.
Signed-off-by: Scott Wood <oss@buserror.net>
Cc: Peter Tyser <ptyser@xes-inc.com>
Cc: Dirk Eibach <eibach@gdsys.de>
Cc: Andy Fleming <afleming@gmail.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
For mpc85xx SoCs, the core begins execution from address 0xFFFFFFFC.
In non-secure boot scenario from NAND, this address will map to CPC
configured as SRAM. But in case of secure boot, this default address
always maps to IBR (Internal Boot ROM).
The IBR code requires that the bootloader(U-boot) must lie in 0 to 3.5G
address space i.e. 0x0 - 0xDFFFFFFF.
For secure boot target from NAND, the text base for SPL is kept same as
non-secure boot target i.e. 0xFFFx_xxxx but the SPL U-boot binary will
be copied to CPC configured as SRAM with address in 0-3.5G(0xBFFC_0000)
As a the virtual and physical address of CPC would be different. The
virtual address 0xFFFx_xxxx needs to be mapped to physical address
0xBFFx_xxxx.
Create a new PBI file to configure CPC as SRAM with address 0xBFFC0000
and update DCFG SCRTACH1 register with location of Header required for
secure boot.
The changes are similar to
commit 467a40dfe3
powerpc/mpc85xx: SECURE BOOT- NAND secure boot target for P3041
While P3041 has a 1MB CPC and does not require SPL. On T104x, CPC
is only 256K and thus SPL framework is used.
The changes are only applicable for SPL U-Boot running out of CPC SRAM
and not the next level U-Boot loaded on DDR.
Reviewed-by: Ruchika Gupta <ruchika.gupta@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Aneesh Bansal <aneesh.bansal@nxp.com>
Signed-off-by: Sumit Garg <sumit.garg@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Due to the blow up of the latest kernel size, the default gnuzip
size (8M) seems too small. The yocto kernel size I built for
mpc8315erdb board is 5294393, and it can't be boot by using the
latest u-boot. So expand gnuzip buffer for all the mpc83xx boards
to fix this issue.
Robert P. J. Day also pointed that the kernel partition on the NAND
flash is also too small, fix it at the same time.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Robert P. J. Day has pointed that the value of SYS_MONITOR_LEN in
MPC8315ERDB.h is smaller than the u-boot.bin. This will cause the
overlap between the code of u-boot and the environment variable.
So when executing saveenv, it will corrupt the code of u-boot and
causes the board not boot. Fix this for all the mpc83xx boards by
reserving a 512K area.
Reported-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Reviewed-by: York Sun <york.sun@nxp.com>
I2C offset was changed by commit 00f792e0 (added multibus support)
from 0x3100 to 0x3000. This typo leads to error when reading SPD
from DDR DIMMs.
Signed-off-by: Benjamin Kamath <bkamath@spaceflight.com>
Signed-off-by: York Sun <york.sun@nxp.com>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
The PPA use PSCI to make secondary cores bootup. So when PPA was
enabled, add the CONFIG_ARMV8_PSCI to identify the SMP boot-method
between PSCI and spin-table.
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Reviewed-by: York Sun <york.sun@nxp.com>
Use existing Kconfig symbols to let the user configure whether to
build a U-Boot with non-secure mode support or not. This also allows
to enable virtualization extension easily.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
CONFIG_DISPLAY_BOARDINFO should not be placed in mx7_common
because some boards might need a different config such as
CONFIG_DISPLAY_BOARDINFO_LATE. Move it to the board file
instead.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
This can be useful if the same U-Boot binary is used for boards
available with a i.MX 7Solo and i.MX 7Dual.
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The cm-fx6 module has an on-board spi flash chip. Enable mtd support
and the mtdparts command. Also define a default partitioning, add
it to the default environment, and enable support to overwrite the
partitioning defined in a device tree by it. Finally, probe for the
chip on preboot to register the flash chip and, thus, establish the
connection between the mtd environment settings and the actual device.
These changes move the effective default partitioning from the device
tree shipped with the vendor kernels to U-Boot which becomes the single
point of definition for the partitioning for all device tree based
kernels (in particular, for the upstream Linux kernel which does not
have a default partitioning defined in its device tree).
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Acked-by: Igor Grinberg <grinberg@compulab.co.il>
Currently, entire script segments have to be changed in the default
environment to change the kernel image location or to append kernel
cmdline parameters. In the later case this has to be changed for
every possible boot device.
Introduce new variables for kernel image locations and boot device
independent kernel parameters to make it easier to change these
settings.
Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
Reviewed-by: Igor Grinberg <grinberg@compulab.co.il>
Reviewed-by: Nikita Kiryanov <nikita@compulab.co.il>
Recently I started to notice that u-boot.img built for Wandboard
by some toolchains becomes so large that it basically overlaps with
U-Boot environment area on SD-card.
According to
http://wiki.wandboard.org/index.php/Boot-process#sdcard_boot_data_layout
Wandboard's SD-card layout is as follows:
------------------------------>8---------------------------
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
==========================================================
1. 0x00000000 Reserved For MBR
2. 0x00000200 512 Secondary Image Table (optional)
3. 0x00000400 1024 uBoot Image (Starting From IVT)
4. 0x00060000 393216 start of uboot env (size:8k)
5. 0x00062000 end of uboot env
6. 0x00100000 1048576 Linux kernel start
7. 0x0076AC00 7777280 start of partition 1
------------------------------>8---------------------------
So for U-Boot we have 383kB (392192 bytes).
But in up to date U-Boot for Wandboard we build separately
a) SPL
b) u-boot.img
which gives us a bit more detailed SD-card layout:
------------------------------>8---------------------------
==========================================================
1. 0x00000000 Reserved For MBR
2. 0x00000200 512 Secondary Image Table (optional)
3. 0x00000400 1024 SPL
4. 0x00011400 70656 u-boot.img
5. 0x00060000 393216 start of uboot env (size:8k)
6. 0x00062000 end of uboot env
...
------------------------------>8---------------------------
>From that layout we may calculate amount of space reserved for
u-boot.img. It's just 315kb (322560 bytes).
Now if I build U-Boot with Sourcery CodeBench ARM 2014.05 produced
u-boot.img is already more than we expected
(323840 bytes instead of "< 322560"):
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 323840 Jul 5 07:38 u-boot.img
------------------------------>8---------------------------
Funny enough if I rebuild U-Boot with ARM toolchain available in
my Fedora 23 distro u-boot.img becomes a little bit smaller:
------------------------------>8---------------------------
ls -la u-boot.img
-rw-rw-r-- 1 user user 322216 Jul 5 07:39 u-boot.img
------------------------------>8---------------------------
What's worse this problem might not affect people most of the time
because what happens people would just copy u-boot.img on SD-card and
live in happiness with it... well until somebody attempts to save
environment in U-Boot with "saveenv" command which will simply
overwrite the very end of u-boot.img.
That will lead to unusable SD-card until user dd u-boot.img on
SD-card again.
I may foresee this issue in the future to become more visible once we
add more features in U-Boot for Wandboard or just existing code base
becomes bulkier and people will consistently get larger u-boot.img
files produced.
IMHO there's an obvious solution for all that - just move U-Boot's env
to the very end of the gap between U-Boot and the first real partition
on the SD-card. This patch will follow
8fb9eea565 ("mx6sabre_common: Fix U-Boot corruption after 'saveenv'").
So env is still not in the very end of the gap (obviously 256kb is way
too much for U-Boot's env) but at least we have now the same
partitioning for i.MX6 boards.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Otavio Salvador <otavio@ossystems.com.br>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Rini <trini@konsulko.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Cc: Wolfgang Denk <wd@denx.de>
The code had assumed 4 CPUS before and now we have this configurable.
For now, set this to the previous default.
Cc: Chander Kashyap <k.chander@samsung.com>
Cc: Steve Rae <steve.rae@raedomain.com>
Cc: Minkyu Kang <mk7.kang@samsung.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The original PSCI implementation assumed CONFIG_ARMV7_PSCI_NR_CPUS=4.
Add this to platforms that have not defined it, using CONFIG_MAX_CPUS if
it is defined, or the actual number of cores for the given platform.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
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>
Start up the test devices. These print out of-platdata contents, providing a
check that the of-platdata feature is working correctly.
The device-tree changes are made to sandbox.dts rather than test.dts. since
the former controls the of-platdata generation.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is useful to be able to build SPL for sandbox. It provides additional
build coverage and allows SPL features to be tested in sandbox. However
it does not need worthwhile to always create an SPL build. It nearly
doubles the build time and the feature is (so far) seldom used.
So for now, create a separate build target for sandbox SPL. This allows
experimentation with this new feature without impacting existing workflows.
Signed-off-by: Simon Glass <sjg@chromium.org>
This patch adds SDRAM support for stm32f746 discovery board.
This patch depends on previous patch.
This patch is based on STM32F4 and emcraft's[1].
[1]: https://github.com/EmcraftSystems/u-boot
Signed-off-by: Toshifumi NISHINAGA <tnishinaga.dev@gmail.com>
This patch adds 200MHz clock configuration for stm32f746 discovery board.
This patch is based on STM32F4 and emcraft's[1].
[1]: https://github.com/EmcraftSystems/u-boot
Signed-off-by: Toshifumi NISHINAGA <tnishinaga.dev@gmail.com>
Make the external devices the preferred ones when booting the system
(usb is already the first option). This allows users to easily boot
custom distributions without requiring them to reflash/customize u-boot.
Cc: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Signed-off-by: Ricardo Salveti <rsalveti@rsalveti.net>
Reviewed-by: Andreas Färber <afaerber@suse.de>
Tested-by: Andreas Färber <afaerber@suse.de>
Acked-by: Mateusz Kulikowski <mateusz.kulikowski@gmail.com>
Define a default board_run_command() function. This function contains
the commands needed to boot the board when CLI is disabled (CONFIG_CMDLINE=n).
Signed-off-by: Andrej Rosano <andrej@inversepath.com>
Add USB host support.
Tested by connecting a USB pen drive:
=> usb start
starting USB...
USB0: Port not available.
USB1: USB EHCI 1.00
scanning bus 1 for devices... 2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Add script for retrieving the kernel via TFTP and mounting the
rootfs via NFS.
Signed-off-by: Diego Dorta <diego.dorta@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
DFU is a convenient way to program U-boot binary into the eMMC.
Add support for it.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Pico-imx6ul has a KSZ8081 Ethernet PHY.
Add support for it.
Signed-off-by: Diego Dorta <diego.dorta@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Instead of passing the total RAM size via PHYS_SDRAM_SIZE option,
we should better use imx_ddr_size() function, which automatically
determines the RAM size.
Signed-off-by: Vanessa Maegima <vanessa.maegima@nxp.com>
Acked-by: Fabio Estevam <fabio.estevam@nxp.com>
Custom Board based on MX6 Dual, 1GB RAM and eMMC.
There are two variants of the board with and without
PCIe (ZC5202 and ZC5601).
Signed-off-by: Stefano Babic <sbabic@denx.de>
Add support for Advantech SOM-DB5800 with the SOM-6867 installed.
This is very similar to conga-qeval20-qa3-e3845 in that there is a
reference carrier board (SOM-DB5800) with a Baytrail based SoM (SOM-6867)
installed.
Currently supported:
- 2x UART (From ITE EC on SOM-6867) routed to COM3/4 connectors on
SOM-DB5800.
- 4x USB 2.0 (EHCI)
- Video
- SATA
- Ethernet
- PCIe
- Realtek ALC892 HD Audio
Pad configuration for HDA_RSTB, HDA_SYNC, HDA_CLK, HDA_SDO
HDA_SDI0 is set in DT to enable HD Audio codec.
Pin defaults for codec pin complexs are not changed.
Not supported:
- Winbond Super I/O (Must be disabled with jumpers on SOM-DB8500)
- USB 3.0 (XHCI)
- TPM
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This option is not actually needed for rockchip boards. Drop it, since it
will not support driver-model MMC operation support.
Signed-off-by: Simon Glass <sjg@chromium.org>
