In upstream libfdt, 6dcb8ba4 "libfdt: Add helpers for accessing
unaligned words" introduced changes to support unaligned reads for ARM
platforms and 11738cf01f15 "libfdt: Don't use memcpy to handle unaligned
reads on ARM" improved the performance of these helpers.
In practice however, this only occurs when the user has forced the
device tree to be placed in memory in a non-aligned way, which in turn
violates both our rules and the Linux Kernel rules for how things must
reside in memory to function.
This "in practice" part is important as handling these other cases adds
visible (1 second or more) delay to boot in what would be considered the
fast path of the code.
Cc: Patrice CHOTARD <patrice.chotard@st.com>
Cc: Patrick DELAUNAY <patrick.delaunay@st.com>
Link: https://www.spinics.net/lists/devicetree-compiler/msg02972.html
Signed-off-by: Tom Rini <trini@konsulko.com>
Tested-by: Patrice Chotard <patrice.chotard@st.com>
Coreutils command nproc can be used on Linux and BSD to count the number of
available CPU cores. Use this instead of relying on the parsing of the
Linux specific proc file system.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
As hinted by GCC 9, there is a return statement that returns
an uninitialized variable in optee_copy_firmware_node().
This patch addresses this.
Signed-off-by: Christoph Müllner <christoph.muellner@theobroma-systems.com>
Reviewed-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com>
This removes the arch-specific checks for "checkcpu" function from the init
sequence. Make "checkcpu" generic and provide a weak nop stub instead.
Signed-off-by: Ovidiu Panait <ovpanait@gmail.com>
New analysis by the tool has shown that we have some cases where we
weren't handling the error exit condition correctly. When we ran into
the ENOMEM case we wouldn't exit the function and thus incorrect things
could happen. Rework the unwinding such that we don't need a helper
function now and free what we may have allocated.
Fixes: 18030d04d2 ("GPT: fix memory leaks identified by Coverity")
Reported-by: Coverity (CID: 275475, 275476)
Cc: Alison Chaiken <alison@she-devel.com>
Cc: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Cc: Jordy <jordy@simplyhacker.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
This enables readning the cpuid from e-fuse, and deriving a static
MAC address from it.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add alias for mmc/sdmmc so that we can have a fix mmc number for emmc.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Rockchip use CONFIG_SPL_OPTEE for OPTEE support, which is load and run
before U-Boot, but not use CONFIG_OPTEE which is after U-Boot.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Add rk3328-sdram-ddr4-666.dtsi for support ddr4 init.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
No need to do twice data training for rk3328 ddr sdram, we re-use the
setting for both channel. And adjust the sdram_init properly for correct
init flow.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Rockchip has documentation file, doc/README.rockchip but
which is not so readable to add or understand the existing
contents. Even the format that support is legacy readme
in U-Boot.
Add rockchip specific documentation file using new rst
format, which describes the information about Rockchip
supported boards and it's usage steps.
Added minimal information about rk3288, rk3328, rk3368
and rk3399 boards and usage. This would indeed updated
further based on the requirements and updates.
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
All rockchip platforms support TPL or SPL-based bootloader
in mainline with U-Boot proper as final stage. For each
stage we need to burn the image on to flash with respective
offsets.
This patch creates a single boot image component using
- binman, for arm32 rockchip platforms
- pad_cat, for arm64 rockchip platforms.
This would help users to get rid of burning different
boot stage images.
The new image called 'u-boot-rockchip.bin'
which can burn into flash like:
₹ sudo dd if=u-boot-rockchip.bin of=/dev/sda seek=64
This would support all rockchip platforms, except rk3128
since it doesn't support for SPL yet.
Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Cc: Wadim Egorov <w.egorov@phytec.de>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add U-Boot specific dtsi file for rk3188 SoC. This
would help to add U-Boot specific dts nodes, properties
which are common across rk3188.
Right now, the file is empty, will add required changes
in future patches.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add U-Boot specific dtsi file for rk3036 SoC. This
would help to add U-Boot specific dts nodes, properties
which are common across rk3036.
Right now, the file is empty, will add required changes
in future patches.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add SPL-alone mkimage tooling support via Makefile for
few platforms or boards used in rockchip family.
With this users would get rid of explicitly creating
mkimage tool for rockchip rksd or rkspi boot modes.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Most of the platforms uses the platform type on their boot
stage image naming conventions in makefile like,
u-boot-x86-start16-tpl.bin - x86 start16 TPL bin
u-boot-spl-mtk.bin - Mediatek SPL bin
This would help to understand the users to what that
particular image belongs to? and less confused.
On that note, suffix platform type rockchip for existing
u-boot-tpl.img so now it become u-boot-tpl-rockchip.bin
Also, bin is more conventional way to include it on tools
like binman, pad_cat etc in future patches.
Note: usage of platform type doesn't follow consistent order
as of now.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add rockchip image type support. right now the image
type marked with rksd, So create image type variable
with required image type like rksd or rkspi.
Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Add bootcount support for Rockchip rk3399.
The bootcount value is preserved in PMU_SYS_REG0 register,
this would help to support redundent boot.
Once the redundant boot triggers, the altboot command
will look for extlinux-rollback.conf on particular
bootable partition which supposed to be a recovery
partition where redundant boot required.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Add cpu reset cause in common cpu-info file.
This would help to print the reset cause for
various resets.
Right now it support rk3288, rk3399. rest of rockchip
platforms doesn't have reset cause support ye but this
code is more feasible to extend the same.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Few of the rockchip family SoC atleast rk3288,
rk3399 are sharing some cru register bits so
adding common code between these SoC families
would require to include both cru include files
that indeed resulting function declarations error.
So, create a common cru include as cru.h then
include the rk3399 arch cru include file and move
the common cru register bit definitions into it.
The rest of rockchip cru files will add it in future.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
RK3288, RK3399 are now support cpu-info, so enable
DISPLAY_CPUINFO by default.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Add cpu information for rockchip soc.
This would help to print the SoC family number, with
associated temparature, clock and reason for reset etc.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Enable winbond SPI flash for ROC-PC-RK3399 board.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Sync the ROC-RK3399-PC device tree changes from Linux
with below commit details:
commit <c36308abe4110e4db362d5e2ae3797834a7b1192> ("arm64: dts:
rockchip: Enable MTD Flash on rk3399-roc-pc")
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Most of the SPI flash devices in rockchip are 16MiB size.
So, keeping U-Boot proper offset start from 128MiB with 1MiB
size and then start env of 8KiB would be a compatible location
between all variants of flash sizes.
This patch add env start from 0x14000 with a size of 8KiB.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Rockchip do support SPI flash as well, so there is
a possibility of using flash environment for those
use cases.
So, restrict the current env offset, size for MMC.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
rk3399 do support SPI flash as well, so there is
a possibility of using flash environment for those
usecases.
So define env device for MMC only when it is used
by specific configuration.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In the RK3399 DRAM driver, the function set_ds_odt() supports operating
in two different modes, selected by the ctl_phy_reg argument: when true,
the function reads and writes directly from the DRAM registers, accessed
through "chan->pctl->denali_*"; when false, the function reads and
writes from an array, accessed through "params->pctl_regs.denali_*",
which is written to DRAM registers at a later time.
However, phy_config_io(), which is called by set_ds_odt() to do a subset
of its register operations, operates directly on DRAM registers at all
times. This means that it reads incorrect values (and writes new values
prematurely) when ctl_phy_reg in set_ds_odt() is false. Fix this by
passing in the address of the registers to work with.
This prevents an "Invalid DRV value" error in the SPL debug log and
(presumably) results in a more correct end state. See the following logs
from a RK3399 NanoPi M4 board (4GB LPDDR3):
Before:
sdram_init() Starting SDRAM initialization...
phy_io_config() Invalid DRV value.
phy_io_config() Invalid DRV value.
sdram_init() sdram_init: data trained for rank 2, ch 0
phy_io_config() Invalid DRV value.
phy_io_config() Invalid DRV value.
sdram_init() sdram_init: data trained for rank 2, ch 1
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
sdram_init() Finish SDRAM initialization...
After:
sdram_init() Starting SDRAM initialization...
sdram_init() sdram_init: data trained for rank 2, ch 0
sdram_init() sdram_init: data trained for rank 2, ch 1
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
sdram_init() Finish SDRAM initialization...
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
i2c changes for 2020.04
- updates the Designware I2C driver
- get timings from device tree
- handle units in nanoseconds
- make sure that the requested bus speed is not exceeded
- few smaller clean-ups
- adds enums for i2c speed and update drivers which use them
- global_data: remove unused mxc_i2c specific field
This fixes the default boot command for the SD-card boot case.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
Some PMICs (such as the DA9063) have non-contiguous register maps.
Attempting to read the non implemented registers returns an error
rather than a dummy value which causes 'pmic dump' to terminate
prematurely.
Fix this by allowing the PMIC driver to return -ENODATA for such
registers, which will then be displayed as '--' by pmic dump.
Use a single error code rather than any error code so that
we can distinguish between a hardware failure reading the PMIC
and a non implemented register known to the driver.
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Add a driver for the regulators in the the DA9063 PMIC.
Robert Beckett: move regulator modes to header so board code can set
modes. Correct mode mask used in ldo_set_mode.
Add an option CONFIG_SPL_DM_REGULATOR_DA9063.
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
This adds the basic register access operations and child regulator
binding (if a regulator driver exists).
Robert Beckett: simplify accesses by using bottom bit of address as
offset overflow. This avoids the need to track which page we are on.
Add an option CONFIG_SPL_DM_PMIC_DA9063.
Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
The 3-bit "command", or register, is encoded within the device address.
Configure the device accordingly, and pass command in DM I2C read/write
calls correctly.
Signed-off-by: Ian Ray <ian.ray@ge.com>
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
If we didn't unbind the sata from block device, the same devices would
be added after sata remove,
This patch is to resolve this issue as below:
=> sata info
SATA#0:
(3.0 Gbps)
SATA#1:
(3.0 Gbps)
Device 0: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY30
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
Device 1: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX30
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
=> sata stop
=> sata info
SATA#0:
(3.0 Gbps)
SATA#1:
(3.0 Gbps)
Device 0: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY300
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
Device 1: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX300
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
Device 2: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005PY300
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
Device 3: Model: INTEL SSDSA2BW300G3D Firm: 4PC10362 Ser#: BTPR247005VX300
Type: Hard Disk
Supports 48-bit addressing
Capacity: 286168.1 MB = 279.4 GB (586072368 x 512)
Signed-off-by: Peng Ma <peng.ma@nxp.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This can be used for device tree size reduction similar as
CONFIG_OF_SPL_REMOVE_PROPS option. Some boards must pass the
built-in DTB unchanged to the kernel, thus we may not cut it
down unconditionally. Therefore enable the property removal
list option only if CONFIG_OF_DTB_PROPS_REMOVE is selected.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
XOM pins provide information for iROM bootloader about the boot device.
Those pins are mapped to lower bits of OP_MODE register (0x10000008),
which is common for all Exynos SoC variants. Set the default MMC device id
to reflect the boot device selected by XOM[7:5] pins (2 for the SD or 0 for
the eMMC).
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
TI's AM654 SoC has a Cadence OSPI IP. Add a new compatible string for
the same.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
