The AM3517 is mostly am omap3, so this partch removes the custom
memory configurations and just uses the default common entries
for omap3 and armv7.
Signed-off-by: Adam Ford <aford173@gmail.com>
This add the initial support of the broadcom reference
board bcm968580xref with a bcm6858 SoC.
This board has 512 MB of ram, 256 MB of flash (nand),
2 usb port, 1 uart, 4 ethernet ports (LAN), 1 ethernet port (WAN).
Signed-off-by: Philippe Reynes <philippe.reynes@softathome.com>
Convert the Watchdog driver for AT91SAM9x processors to support
the driver model and device tree. Changes "CONFIG_AT91SAM9_WATCHDOG"
to new "CONFIG_WDT_AT91" Kconfig option.
Signed-off-by: Prasanthi Chellakumar <prasanthi.chellakumar@microchip.com>
This introduces two new APIs dm_pci_find_next_capability() and
dm_pci_find_next_ext_capability() to get PCI capability address
and PCI express extended capability address for a given PCI device
starting from a given offset.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Introduce a new Kconfig option for architecture codes to control
whether it provides io{read,write}{8,16,32} I/O accessor functions.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a new block interface type for VirtIO block devices.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
blk_next_free_devnum() can be helpful in some cases. Make it
a public API.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds support for managing virtual queue/ring, the channel
for high performance I/O between host and guest.
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This adds a new virtio uclass driver for “virtio” [1] family of
devices that are are found in virtual environments like QEMU,
yet by design they look like physical devices to the guest.
The uclass driver provides child_pre_probe() and child_post_probe()
methods to do some common operations for virtio device drivers like
device and driver supported feature negotiation, etc.
[1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add test case to cover uclass driver's child_post_probe() method.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some buses need to set up their child devices after they are probed.
Support a common child_post_probe() method for the uclass.
With this change, the two APIs uclass_pre_probe_device() and
uclass_post_probe_device() become symmetric.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add some overview documentation that explains the purpose and some of
the features and limitations of the regmap interface.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Add support for switching the endianness of regmap accesses via the
"little-endian", "big-endian", and "native-endian" boolean properties in
the device tree.
The default endianness is native endianness.
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
It would be convenient if one could use the regmap API in conjunction
with register maps defined as structs (i.e. structs that directly mirror
the memory layout of the registers in question). A similar approach was
planned with the regmap_write32/regmap_read32 macros, but was never
used.
Hence, implement regmap_set/regmap_range_set and
regmap_get/regmap_range_get macros, which, given a register map, a
struct describing the layout of the register map, and a member name
automatically produce regmap_read/regmap_write calls that access the
specified member in the register map.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
It is useful to be able to treat the different ranges of a regmap
separately to be able to use distinct offset for them, but this is
currently not implemented in the regmap API.
To preserve backwards compatibility, add regmap_read_range and
regmap_write_range functions that take an additional parameter
'range_num' that identifies the range to operate on.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The regmap functions currently assume that all register map accesses
have a data width of 32 bits, but there are maps that have different
widths.
To rectify this, implement the regmap_raw_read and regmap_raw_write
functions from the Linux kernel API that specify the width of a desired
read or write operation on a regmap.
Implement the regmap_read and regmap_write functions using these raw
functions in a backwards-compatible manner.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Reviewed-by: Simon Glass <sjg@chromium.org>
The documentation in regmap.h is not in kernel-doc format. Correct this.
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
The pre_reloc_only parameter description currently only mentions
drivers with the DM_FLAG_PRE_RELOC flag, but does not mention the
special device tree properties. Correct them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently the comments of several APIs (eg: dm_init_and_scan()) say:
@pre_reloc_only: If true, bind only drivers with the DM_FLAG_PRE_RELOC
flag. If false bind all drivers.
The 'Pre-Relocation Support' chapter in doc/driver-model/README.txt
documents the same that both device tree properties and driver flag
are supported.
However the implementation only checks these special device tree
properties without checking the driver flag at all. This updates
lists_bind_fdt() to consider both scenarios.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Squashed in http://patchwork.ozlabs.org/patch/996473/ :
Signed-off-by: Simon Glass <sjg@chromium.org>
This adds a new API dm_ofnode_pre_reloc(), a livetree equivalent
API of dm_fdt_pre_reloc().
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
When the DM CPU drivers are active, printing information about a CPU
should be delegated to a matching driver.
Hence, add a static print_cpuinfo that implements this delegation when
DM CPU drivers are active.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Mario Six <mario.six@gdsys.cc>
Changed condition to CONFIG_IS_ENABLED(CPU):
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that CMD_UBI does not select CMD_MTDPARTS we need to make platforms
that had been enabling it turn it on by hand. This exposed that we had
not yet migrated CMD_MTDPARTS fully, so do so now.
Fixes: 86dfa556d9 ("cmd: ubi: Remove useless call to mtdparts_init()")
Signed-off-by: Tom Rini <trini@konsulko.com>
This patch adds check for command response CRC failure. The driver
is currently ignoring CRC check failure on command resposes which
have CRC atteched to it, which can be potentially dangerous. Even
more grueling problem happens when the command response is followed
by data transfer though, as in that case, the dwmci_data_transfer()
function will spin until it reaches the 240s timeout.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
This reverts commit c0434407b5.
It turns out commit c0434407b5 broke some boards which have DM CPU
driver with CONFIG_DISPLAY_CPUINFO option on. These boards just fail
to boot when print_cpuinfo() is called during boot.
Fixes are already sent to ML and in u-boot-dm/next, however since
we are getting close to the v2018.11 release, it's safer we revert
the original commit.
This commit should be reverted after v2018.11 release.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Default setup is 0 which is incorrect place because it points to OCM
which is allocated for SPL only in our case.
Use address in DDR.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The driver is based on the previous one and the code is only adapted
to fit the driver model. The support for the Faraday ftgmac100
controller is the same with MAC and MDIO bus support for RGMII/RMII
modes.
Configuration is updated to enable compile again. At this stage, the
driver compiles but is not yet functional.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Real marketing name of the board was recently updated so
to accommodate that change renaming the board and all
related to it.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This part should've been remove in commit 88d60db011 ("arm: ti: boot:
Remove environment partition"), but I missed it somehow. Remove reading
dtb file from environment partition on eMMC, as we don't have it
anymore.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Commit 768f23dc8a ("ARM: socfpga: Put stack at the end of SRAM") broke
those socfpga boards that keep the bootcounter at the end of the
internal SRAM as the bootcounter needs 8 bytes by default and thus the
very first SPL call to board_init_f_alloc_reserve overwrites the
bootcounter.
This patch allows to move the initial stack pointer down a bit by
checking if CONFIG_SYS_BOOTCOUNT_ADDR is located in the internal SRAM
area and then using this address as location for the start of the
stack pointer.
No new macros / defines are added by this approach.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Workaround makes FS as default mode on all affected socs.
Add support to check erratum-A005275 validity for an soc. This info is
required to determine whether a given soc is affected by this erratum.
Add quirk for this erratum "has_fsl_erratum_a005275" . This quirk is used
to enable workaround for the errata
Force FS mode as default by:
- making EPS as FS
- setting PFSC bit to disable HS chirping
This workaround can be disabled by mentioning "no_erratum_a005275" in
hwconfig string
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: York Sun <york.sun@nxp.com>
To enable the root device selection (kernel cmd-line) via PARTUUID, this
patch enables CMD_PART on all missing theadorable-x86 boards and
changes the default environment to generate the root=PARTUUID string
automatically.
This fixes problems that have been noticed on systems with multiple
SATA/AHCI controller connected via PCIe, where the device name for the
root device / partition (/dev/sdaX) was incorrect.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This is needed for the PCIe hotplug to work correctly on some boards
with the newer Linux kernel versions.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The aquantia driver requires both CONFIG_PHY_GIGE and CONFIG_PHYLIB_10G.
Signed-off-by: Jeremy Gebben <jgebben@sweptlaser.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
In upcoming freescale board LX2160AQDS, the MDIO bus is muxed.
i.e. same MDIO bus can be routed to eight different slots depending
on mux register settings.
To support this mdio mux behavior, we add each MDIO bus mux as a
separate MDIO bus.
Now, various phy devices can be attached to each of these slots(mux).
The information about these devices is passed to OS via device tree.
To do the fdt fixups related to MDIO bus, its necessary that MDIO bus
list is accessed.Therefore, add a function to retrieve the list head.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>
Odroid HC2 board is based on Odroid XU4 board, like the Odroid HC1.
The linux kernel does not provide a hc2 DTB so the hc1 DTB is also used
for the Odroid HC2.
Resend because MUA changed whitespace.
Signed-off-by: Dirk Meul <dirk.meul@rwth-aachen.de>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Remove "environment" partition and do not read it when booting Android
from eMMC. We don't use this partition anymore, so this is just an
unintentional leftover.
Earlier we were reading dtb file from "environment" partition to feed it
further to kernel. Now we are using dtb from FIT image ("boot" partition
contains boot_fit.img image), which can be seen from this command:
bootm ${loadaddr}#${fdtfile}
where "#" character means we have FIT image in ${loadaddr} RAM address.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Acked-by: Praneeth Bajjuri <praneeth@ti.com>
The DM37 and OMAP35 SOM-LV SOM-LV products both support a NOR
flash part connected to CS2 in addition to the NAND part on CS0.
This patch setups the GPMC timings for the MT28 NOR Flash and
enables the CFI-Flash driver now that the CFI stuff is in Kconfig
Signed-off-by: Adam Ford <aford173@gmail.com>
Instead of keeping a custom environment, use a more generic approach
by switching to distro config.
Signed-off-by: Dirk Meul <dirk.meul@rwth-aachen.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
If we have defined the OPTEE ram size and not OPTEE means that we are in
the case where OPTEE is loaded already (maybe by ARM Trusted Firmware) and
that most of the low level initialization is already done and that we
may/should skip it doing them here.
Signed-off-by: Rui Miguel Silva <rui.silva@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: u-boot@lists.denx.de
i.MX8/8X bootable image type is container type.
The bootable image, containers a container set which supports two
container. The 1st container is for SECO firmware, the 2nd container
needs to include scfw, m4_0/1 image, ACore images per your requirement.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
