spba-bus has a few nodes under it including the UART1 and
some ESPI buses. In order to use them in SPL, the
u-boot,dm-spl flag needs to be added to the spba-bus@2000000
container.
Signed-off-by: Adam Ford <aford173@gmail.com>
Currently the CPU frequency is incorrectly reported:
CPU: NXP i.MX8QXP RevB A35 at 147228 MHz
Fix this problem by using a direct call to the SCU firmware to
retrieve the Cortex A35 CPU frequency.
With this change applied the CPU frequency is displayed correctly:
CPU: NXP i.MX8QXP RevB A35 at 1200 MHz
Tested-by: Marcelo Macedo <marcelo.macedo@nxp.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Andrejs Cainikovs <andrejs.cainikovs@netmodule.com>
Select CONFIG_DM_MMC=y in order to support MMC driver model.
This allows the MMC board related code to be removed.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
Import the device tree files from kernel 5.0-rc6 in preparation
for driver model conversion.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Otavio Salvador <otavio@ossystems.com.br>
This is currently missing and without it the i8254 beeper driver
won't work.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The pc speaker driven by the i8254 is generic enough to deserve
a single dtsi file to be included by boards that use it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The i8254 timer control IO port (0x43) should be setup correctly
by using PIT counter 2 to generate beeps, however in U-Boot other
codes like TSC driver utilizes PIT for TSC frequency calibration
and configures the counter 2 to a different mode that does not
beep. Fix this by always ensuring the PIT counter 2 is correctly
initialized so that the i8254 beeper driver works as expected.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Intel Edison has three UART ports, i.e.
port 0 - Bluetooth
port 1 - auxiliary, available for general purpose use
port 2 - debugging, usually console output is here
Enable all of them for future use.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.
Thus, fix the number of default console interface to be 2.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We may not do an assumption that current console device is always a first
of UCLASS_SERIAL one.
For example, on properly described Intel Edison board the console UART
is a third one.
Use current serial device as described in global data.
Fixes: a61cbad78e ("dm: serial: Adjust serial_getinfo() to use proper API")
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Note, I2C6, which is available to user, has no DMA request lines connected.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Intel Tangier SoC has a general purpose DMA which can serve to speed up
communications on SPI and I2C serial buses.
Provide DMA descriptors to utilize this capability in the future.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
The bootrom seems to leave the D-cache in messed up state, make sure
the SPL disables it so it can not interfere with operation.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Chin Liang See <chin.liang.see@intel.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Tien Fong Chee <tien.fong.chee@intel.com>
The values for the data and tag latency settings on the PL310 caches
controller is an (n-1). For example, the "arm,tag-latency" is specified
as <1 1 1>, so the values that should be written to register should be
0x000. And for the "arm,data-latency" specified as <2 1 1>, the register
value should be 0x010.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
v2019.01 commit cbff9f80ce ("ARM: dts: rmobile: Sync Gen3 DTs with
Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.
Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
equivalent to partially reverting below v2019.01 commits:
- f529bc551b ("ARM: dts: rmobile: Extract USB nodes on M3N")
- 830b94f768 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")
Duplicating the nodes from <soc>.dtsi to <soc>-u-boot.dtsi is obviously:
- not needed if no U-boot-specific changes are needed in those nodes.
- potentially dangerous/error-prone, since the duplicated properties
override the properties originally defined in <soc>.dtsi. One
possible consequence is that <soc>.dtsi is getting an update from
Linux, while <soc>-u-boot.dtsi stays unchanged. In this situation,
the obsolete property values from <soc>-u-boot.dtsi will take
precedence masking some of the <soc>.dtsi updates, potentially
leading to all kind of obscure issues.
Below is the dtdiff of r8a77965-salvator-x-u-boot.dtb (the only "user"
of r8a77965-u-boot.dtsi) before and after the patch (slightly
reformatted to avoid 'git am/apply' issues and to reduce the width).
What below output means is there is already a mismatch in some of
SDHI/USB nodes between r8a77965.dtsi and r8a77965-u-boot.dtsi. Since no
U-Boot customization is needed in SDHI/USB DT nodes, get rid of them in
r8a77965-u-boot.dtsi.
$> dtdiff before-r8a77965-salvator-x-u-boot.dtb \
after-r8a77965-salvator-x-u-boot.dtb
--- /dev/fd/63 2019-03-09 12:57:40.877963983 +0100
+++ /dev/fd/62 2019-03-09 12:57:40.877963983 +0100
@@ -1471,7 +1471,7 @@
bus-width = <0x4>;
cd-gpios = <0x51 0xc 0x1>;
clocks = <0x6 0x1 0x13a>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa5 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x4d>;
@@ -1492,7 +1492,7 @@
sd@ee120000 {
clocks = <0x6 0x1 0x139>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa6 0x4>;
max-frequency = <0xbebc200>;
power-domains = <0x1 0x20>;
@@ -1504,7 +1504,7 @@
sd@ee140000 {
bus-width = <0x8>;
clocks = <0x6 0x1 0x138>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
fixed-emmc-driver-type = <0x1>;
interrupts = <0x0 0xa7 0x4>;
max-frequency = <0xbebc200>;
@@ -1526,7 +1526,7 @@
bus-width = <0x4>;
cd-gpios = <0x5a 0xf 0x1>;
clocks = <0x6 0x1 0x137>;
- compatible = "renesas,sdhi-r8a77965";
+ compatible = "renesas,sdhi-r8a77965", "renesas,rcar-gen3-sdhi";
interrupts = <0x0 0xa8 0x4>;
max-frequency = <0xc65d400>;
pinctrl-0 = <0x56>;
@@ -1868,14 +1868,14 @@
usb-phy@ee0a0200 {
#phy-cells = <0x0>;
- clocks = <0x6 0x1 0x2be>;
+ clocks = <0x6 0x1 0x2bf>;
compatible = "renesas,usb2-phy-r8a77965", "renesas,rcar-gen3-usb2-phy";
phandle = <0x47>;
pinctrl-0 = <0x4c>;
pinctrl-names = "default";
power-domains = <0x1 0x20>;
reg = <0x0 0xee0a0200 0x0 0x700>;
- resets = <0x6 0x2be>;
+ resets = <0x6 0x2bf>;
status = "okay";
};
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
U-Boot currently uses Gen2 QSPI in 1-bit mode, enforce it until
we can do better using the new SPI NOR framework.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
- Enable DHCP as boot-source in distro boot for NXP layerscape
platforms
- fix register layout for SEC on Layerscape architectures
- fixes related to DPAA2 ethernet
sec_firmware reserves JR3 for it's own usage and deletes the JR3 node
from the device tree. This causes this warning to be issued when doing
the device tree fixup:
WARNING could not find node fsl,sec-v4.0-job-ring: FDT_ERR_NOTFOUND.
Fix it by excluding the device tree fixup for the JR reserved by
sec_firmware.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
The SEC QI ICID setup in the QIIC_LS register is actually an offset
that is being added to the ICID coming from the qman portal. Setting
it with a non-zero value breaks SMMU setup as the resulting ICID is
not known. On top of that, the SEC QI ICID must match the qman portal
ICIDs in order to share the isolation context.
Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Reviewed-by: Horia Geanta <horia.geanta@nxp.com>
Reviewed-by: Bharat Bhushan <bharat.bhushan@nxp.com>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Moving to the driver model requires CONFIG_DM to be enabled. Currently
several boards like kmeter1_defconfig produce a build error when CONFIG_DM
is enabled:
In file included from include/common.h:35,
from ./arch/powerpc/include/asm/fsl_lbc.h:10,
from include/mpc83xx.h:10,
from ./arch/powerpc/include/asm/ppc.h:27,
from ./arch/powerpc/include/asm/u-boot.h:18,
from include/dm/of.h:10,
from include/dm/ofnode.h:12,
from include/dm/device.h:13,
from include/linux/mtd/mtd.h:26,
from drivers/mtd/mtdconcat.c:25:
include/image.h: In function ‘image_check_target_arch’:
include/image.h:846:3: error: #error "please define IH_ARCH_DEFAULT in
your arch asm/u-boot.h"
# error "please define IH_ARCH_DEFAULT in your arch asm/u-boot.h"
^~~~~
include/image.h:848:31: error: ‘IH_ARCH_DEFAULT’ undeclared (first use in
this function); did you mean ‘IH_ARCH_COUNT’?
return image_check_arch(hdr, IH_ARCH_DEFAULT);
The error can be avoided by moving the definition of IH_ARCH_DEFAULT before
#include <asm/ppc.h>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
The loop implemented in the code is supposed to check whether the
PL310 operation register has any bit from the mask set. Currently,
the code checks whether the PL310 operation register has any bit
set AND whether the mask is non-zero, which is incorrect. Fix the
conditional.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Tom Rini <trini@konsulko.com>
Fixes: 93bc21930a ("armv7: add PL310 support to u-boot")
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Reviewed-by: Dinh Nguyen <dinguyen@kernel.org>
This patch enables CONFIG_SYS_BOOT_RAMDISK_HIGH for RISC-V
because bootm will update initrd location in DTB only if
CONFIG_SYS_BOOT_RAMDISK_HIGH is enabled. If we don't enable
this option then bootm assumes DTB already has initrd details
which is not the case most of the time.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
This patch adds SiFive FU540 board support. For now, only
SiFive serial, SiFive PRCI, and Cadance MACB drivers are
only enabled. The SiFive FU540 defconfig by default builds
U-Boot for S-Mode because U-Boot on SiFive FU540 will run
in S-Mode as payload of BBL or OpenSBI.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch adds fixed-factor clock driver which derives clock
rate by dividing (div) and multiplying (mult) fixed factors
to a parent clock.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
On 64bit systems, the DRAM top can be easily beyond 4GB and U-Boot
DMA mapping APIs will generate DMA addresses beyond 4GB. This
breaks DMA programming in 32bit DMA capable devices (such as
Cadence MACB ethernet). For example, If DRAM is more then 2GB
on QEMU sifive_u machine then Cadence MACB ethernet stops working
for U-Boot because it is a 32bit DMA capable device.
To handle 32bit DMA capable devices on 64bit systems, we provide
custom implementation of board_get_usable_ram_top() which ensures
that usable ram top is not more then 4GB. This in-turn ensures
that U-Boot always runs within 4GB hence DMA addresses generated
by DMA mapping APIs will be within 4GB too.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Some of the drivers (such as Cadence MACB ethernet driver) expect
asm/arch/clk.h to be provided by arch support so we add place-holder
asm/arch-generic/clk.h for RISC-V generic CPU.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
This patch adds asm/dma-mapping.h for Linux-like DMA mappings
APIs required by some of the drivers (such as, Cadance MACB
Ethernet driver).
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
The QEMU CPU support under arch/riscv is pretty much generic
and works fine for SiFive Unleashed as well. In fact, there
will be quite a few RISC-V SOCs for which QEMU CPU support
will work fine.
This patch renames cpu/qemu to cpu/generic to indicate the
above fact. If there are SOC specific errata workarounds
required in cpu/generic then those can be done at runtime
in cpu/generic based on CPU vendor specific DT compatible
string.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Reviewed-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
We select CREATE_ARCH_SYMLINK for RISC-V so that we can have
include/asm/arch linked to include/asm/arch-xyz.
Signed-off-by: Anup Patel <anup.patel@wdc.com>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Imply all SoCs supported by a given board. This allows building single
U-Boot binary for boards which can have multiple SoCs.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Imply preferred pin control driver per SoC, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
On SoCFPGA Gen5 systems, it can rarely happen that a reboot from Linux
will result in stale data in PL310 L2 cache controller. Even if the L2
cache controller is disabled via the CTRL register CTRL_EN bit, those
data can interfere with operation of devices using DMA, like e.g. the
DWMMC controller. This can in turn cause e.g. SPL to fail reading data
from SD/MMC.
The obvious solution here would be to fully reset the L2 cache controller
via the reset manager MPUMODRST L2 bit, however this causes bus hang even
if executed entirely from L1 I-cache to avoid generating any bus traffic
through the L2 cache controller.
This patch thus configures and enables the L2 cache controller very early
in the SPL boot process, clears the L2 cache and disables the L2 cache
controller again.
The reason for doing it in SPL is because we need to avoid accessing any
of the potentially stale data in the L2 cache, and we are certain any of
the stale data will be below the OCRAM address range. To further reduce
bus traffic during the L2 cache invalidation, we enable L1 I-cache and
run the invalidation code entirely out of the L1 I-cache.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Configure the PL310 tag and data latency registers, which slightly
improves performance and aligns the behavior with Linux.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
The loop implemented in the code is supposed to check whether the
PL310 operation register has any bit from the mask set. Currently,
the code checks whether the PL310 operation register has any bit
set AND whether the mask is non-zero, which is incorrect. Fix the
conditional.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Dalon Westergreen <dwesterg@gmail.com>
Cc: Dinh Nguyen <dinguyen@kernel.org>
Cc: Tom Rini <trini@konsulko.com>
Fixes: 93bc21930a ("armv7: add PL310 support to u-boot")
- Add support for sound.
Albeit the big changeset, changes are pretty limited to x86 only and a
few new sound drivers used by x86 so I think it would be good to have
this in the next release.
This patch enables UMS on the nyan devices like the nyan-big.
A patch like this has been sent in by Stephen Warren some time ago for
other tegra devices: commit e6607cffef.
But the nyan devices never received that functionality.
Signed-off-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Acked-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Internal keyboard of nyan-big is only working when cold booting by pressing [reload/refresh]+[power] button.
With this patch keyboard is working by only pressing [power] button.
Signed-off-by: Tristan Bastian <tristan-c.bastian@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Enable sound on samus using the broadwell I2S and an RT5677 audio codec.
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
Add support for initing the I2C device and ADSP on broadwell. These are
needed for sound to work.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present the pinctrl probes the PCH but since it only uses it to obtain
a PCI address, this is no necessary. Avoiding this fixes one of the two
co-dependent loops in broadwell.
This driver really should be a proper pinctrl driver, but for now it
remains a syscon device.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
