Patrick Delaunay [Fri, 19 Jun 2020 09:19:45 +0000 (11:19 +0200)]
ARM: dts: stm32: Reinstate card detect behavior on ST boards
The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
unsupported, reinstate the old cd-gpios behavior until this handling
is fully implemented. This avoid potential issue for SDCard boot:
the card detect fails with floating gpio.
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Marek Vasut [Thu, 18 Jun 2020 18:35:17 +0000 (20:35 +0200)]
ARM: dts: stm32: Reinstate card detect behavior on DHSOM
The cd-gpios with (GPIO_ACTIVE_LOW | GPIO_PULL_UP) gpio is thus far
unsupported, reinstate the old cd-gpios behavior until this handling
is fully implemented. This permits the DHSOM to boot from SD again,
without this patch the card detect fails.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Patrick Delaunay <patrick.delaunay@st.com> Cc: Patrice Chotard <patrice.chotard@st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Atish Patra [Fri, 19 Jun 2020 01:51:50 +0000 (18:51 -0700)]
cmd: bootefi: Honor the address & size cells properties correctly
fdtdec_get_addr_size reads the uses a fixed value for address & size
cell properties which may not be correct always.
Use the auto variant of the function which automatically reads
#address-cells & #size-cells from parent and uses to read the "reg"
property.
Signed-off-by: Atish Patra <atish.patra@wdc.com>
On 32 bit systems fdt_addr_t may be 4 bytes long but size is defined as
u64. Avoid filling the upper 4 bytes of the sizep parameter of
fdtdec_get_addr_size_auto_parent() with random bytes from the stack by
defining a separate variable fdt_size.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tom Warren [Mon, 11 May 2020 23:38:58 +0000 (16:38 -0700)]
t210: Nano: Add NVME support
This allows Nano to use the key M.2 on the CVB to connect and use a M.2
NVMe SSD stick. Works on my Nano B00, WD SN750 NVMe SSD shows up
w/'nvme' commands. Will add booting from NVMe via distro cmds in a future
patch.
Jon Hunter [Thu, 18 Jun 2020 11:54:39 +0000 (12:54 +0100)]
ARM: tegra: Enable PSCI support for Tegra210 and Tegra186
The PSCI nodes are currently not populated for the Tegra210 and Tegra186
devices. This prevents the PSCI driver from being able to identify the
PSCI method used by these devices and causes the probe of the PSCI
driver to fail.
Since commit 81ea00838c68 ("efi_loader: PSCI reset and shutdown") was
added, which moves the PSCI EFI system reset handler into the PSCI
driver, this has prevented the EFI system reset from working for
Tegra210 and Tegra186. Therefore, populating these nodes is necessary
to fix the EFI system reset for Tegra210 and Tegra186.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Peter Robinson <pbrobinson@gmail.com>
Jon Hunter [Thu, 18 Jun 2020 11:54:38 +0000 (12:54 +0100)]
firmware: PSCI: Fix PSCI support for OF live trees
When CONFIG_OF_LIVE is enabled, dev_of_offset() cannot be used and
if used returns an invalid offset. This causes the call to
fdt_stringlist_get() in the psci_probe() to fail to read the 'method'
property from the PSCI node for the device and hence prevents PSCI
from working. Fix this by using the ofnode_read_string() API instead
of the fdt_stringlist_get() because this will handle reading the
property both when CONFIG_OF_LIVE is enabled or disabled.
Due to the above problem and since commit 81ea00838c68 ("efi_loader:
PSCI reset and shutdown") was added, the EFI system reset has been
broken for Tegra210 and Tegra196 platforms. This also fixes the EFI
system reset for these Tegra platforms.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Peter Robinson <pbrobinson@gmail.com>
Neil Armstrong [Thu, 11 Jun 2020 08:53:49 +0000 (10:53 +0200)]
board: amlogic: move boards doc into doc/board/amlogic
Move the natural text Amlogic board README files to doc/board/amlogic
into reStructuredText and :
- add reStructuredText markup for bash code
- fix secondary titles markup
- move board support into global support matrix
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
dts: ARM: stm32mp15: add OP-TEE node in u-boot DTSI
Add OP-TEE firmware node in stm32mp15 U-Boot DTSI. This node is
needed since commit [1] that changed U-Boot/stm32mp15 to detect
OP-TEE availability by probing the resource instead of relying on
U-Boot configuration. The software sequence implemented by [1] is
fine but U-Boot DTS/DTSI files were not updated accordingly since,
hence OP-TEE presence is never detected by U-Boot, preventing Linux
kernel from using OP-TEE resources.
For consistency and to synchronize stm32mp15 DTSI files (excluding
U-Boot specific DTSI files) with the Linux kernel ones, this change
also moves the OP-TEE reserved memory nodes from board generic DTSI
files to U-Boot specific board DTSI files.
board: stm32mp1: fix handling of DT OP-TEE reserved memory nodes
Fix the sequence in stm32mp1 fdt.c that disables OP-TEE resources
defined in FDT when U-boot detects OP-TEE firmware is not present.
Before this change, helper function stm32_fdt_disable_optee()
set property status to "disabled" for the OP-TEE reserved memory
nodes but this has no impact since Linux kernel does not consider
the status property for reserved-memory subnodes. This change
make U-Boot to attempt to delete the node instead.
Fixes: 4a1b975dac02 ("board: stm32mp1: reserve memory for OP-TEE in device tree") Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Patrice Chotard <patrice.chotard@st.com>
Mark Kettenis [Mon, 27 Apr 2020 09:09:47 +0000 (11:09 +0200)]
regulator: fix: enable gpio when requested
The fix in commit b7adcdd073c0 has the side-effect that the regulator
will be disabled when requesting the relevant gpio in
regulator_common_ofdata_to_platdata() and enabled in
regulator_pre_probe() when the regulator was already enabled.
This leads to a short interruption in the 3.3V power to the PCIe
slot on the firefly-rk3399 which makes an ADATA SX8000NP NVMe SSD
unhappy.
Fix this by setting the GPIOD_IS_OUT_ACTIVE flag again when the
'regulator-boot-on' property is set, but check for this property
explicitly instead of relying on the "boot_on" member of
the uclass platdata.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Tested-by: Patrice Chotard <patrice.chotard@st.com>
Patrick Delaunay [Wed, 10 Jun 2020 17:28:42 +0000 (19:28 +0200)]
env: Kconfig: cosmetics: update comment for SYS_RELOC_GD_ENV_ADDR
Update the comment for SYS_RELOC_GD_ENV_ADDR as gd->env_addr is updated
in board_r.c::initr_reloc_global_data() under the compilation flags
CONFIG_SYS_RELOC_GD_ENV_ADDR
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com> Reviewed-by: Tom Rini <trini@konsulko.com>
The strtoul has well-defined semantics. It is defined by the C standard and
POSIX. To quote the relevant section of the man pages,
> If base is zero or 16, the string may then include a "0x" prefix, and the
> number will be read in base 16; otherwise, a zero base is taken as 10
> (decimal) unless the next character is '0', in which case it is taken as
> 8 (octal).
Keeping these semantics is important for several reasons. First, it is very
surprising for standard library functions to behave differently than usual.
Every other implementation of strtoul has different semantics than the
implementation in U-Boot at the moment. Second, it can result in very
surprising results from small changes. For example, changing the string
"1f" to "20" causes the parsed value to *decrease*. Forcing use of the "0x"
prefix to specify hexidecimal numbers is a feature, not a bug. Lastly, this
is slightly less performant, since the entire number is parsed twice.
This fixes the str_simple_strtoul test failing with
Signed-off-by: Sean Anderson <seanga2@gmail.com> CC: Michal Simek <michal.simek@xilinx.com> CC: Shiril Tichkule <shirilt@xilinx.com> Reviewed-by: Simon Glass <sjg@chromium.org>
Fix the loop that parses FDT for a reserved memory node named "optee".
Before this change, if at least one subnode was found in the
reserved-memory node, the function endlessly looped since instruction
continue returned back in the loop without updating variable subnode.
This change fixes the issue by using a for loop.
Fixes: 6ccb05eae01b ("image: fdt: copy possible optee nodes to a loaded devicetree") Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Marek Vasut [Fri, 22 May 2020 16:28:33 +0000 (18:28 +0200)]
mmc: fsl_esdhc: Gracefully fail on unsupported voltage switch
Unsupported voltage on voltage switch is not an error, do not
print error message in such a case. This happens e.g. if the
eMMC is already in 1V8 mode or when testing 1V2 mode operation
on systems which only do 3V3/1V8 switching.
Marek Vasut [Fri, 22 May 2020 16:19:08 +0000 (18:19 +0200)]
mmc: fsl_esdhc: Fix SDR104 and HS200 support
The 3V3/1V8 switching could never have worked on any of the iMXes
ever since 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200"),
because that commit uses priv->vqmmc_dev when switching voltages on
mode switch, while local vqmmc_dev in probe to store the regulator
pointer. Those are two different variables with the same name. So
the priv->vqmmc_dev was always NULL and thus voltage switch between
modes never really suceeded.
Fix this by assigning priv->vqmmc_dev with value of the vqmmc_dev
in probe.
Fixes: 51313b49f2 ("mmc: fsl_esdhc: support SDR104 and HS200") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Jaehoon Chung <jh80.chung@samsung.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Arthur Li [Fri, 22 May 2020 00:24:22 +0000 (17:24 -0700)]
mmc: ca_dw_mmc: Misc cleanup of driver
- Rename DT compatible name
- Remove uneccessary if-statement to support 8-bit buswidth
- Remove redundant error msg
- Use symbolic constants in switch statement
Signed-off-by: Arthur Li <arthur.li@cortina-access.com> Signed-off-by: Alex Nemirovsky <alex.nemirovsky@cortina-access.com> CC: Peng Fan <peng.fan@nxp.com> CC: Jaehoon Chung <jh80.chung@samsung.com> CC: Tom Rini <trini@konsulko.com>
Yangbo Lu [Tue, 19 May 2020 03:06:44 +0000 (11:06 +0800)]
mmc: fsl_esdhc: workaround for hardware 3.3v IO reliability issue
When eSDHC operates at 3.3v, damage can accumulate in an internal
level shifter at a higher than expected rate. The faster the interface
runs, the more damage accumulates. This issue now is found on LX2160A
eSDHC1 for only SD card.
The hardware workaround is recommended to use an on-board level shifter
that is 1.8v on SoC side and 3.3v on SD card side.
For boards without hardware workaround, this option could be enabled,
ensuring 1.8v IO voltage and disabling eSDHC if no card.
This option assumes no hotplug, and u-boot has to make all the way to
to linux to use 1.8v UHS-I speed mode if has card.
If you do not want the workaround for better user experience, of course
you can choose to not select it running eSDHC in unsafe mode.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com> Acked-by: Peng Fan <peng.fan@nxp.com>
Commit e71b6f6622d6 ("i2c: designware_i2c: Rewrite timing calculation")
change the hcnt and lcnt timing calculation. New timing calculation is
based on calculation from Designware i2c databook.
After this new timing calculation, hcnt will have negative value
with i2c-scl-falling-time-ns 5000 that set in socfpga_cyclone5_socdk.dts.
This patch overwrite i2c-scl-falling-time-ns to 300ns (default SCL fall
time used in Designware i2c driver) for Uboot.
Before the fix:
=> i2c dev 0
Setting bus to 0
Failure changing bus number (-22)
After the fix:
=> i2c dev 0
Setting bus to 0
=> i2c probe
Valid chip addresses: 17 51 55 5B 5C 5E 66 68 70
Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com>
Hayes Wang [Fri, 5 Jun 2020 07:23:40 +0000 (15:23 +0800)]
eth/r8152: update the firmware
Update the firmware to improve compatibility for none-intel USB
host controller. The more information is as following.
The device has auto-installed driver feature - via switch CD-ROM/NIC
mode. But in some corner cases, it would switch to CD-ROM unexpected.
This issue results in Lan Function Disabled.
While USB PHY transits to P3 from P0 due to the absent of transmitter
control, it would issues undefined signal to its link partner.
Some Down Stream Port misidentify the undefined signal as wakeup
signal. So the link state will not keep in suspend even the system
is idle.
1. Removing the image_offset will break secondary (redundant) boot support for sd and emmc.
2. When booting from emmc boot partition, the image_offset is 0. But the flash.bin
generated by mkimage with imximage-8mp-lpddr4.cfg is for sd. It expects to be burn at 32KB offset.
The fit offset 0x60000 has already included the 32KB offset. So when you burn this flash.bin
to emmc boot partition at offset 0, the fit offset should subtract the 32KB (0x60000 - 0x8000).
Marek Vasut [Sat, 30 May 2020 20:44:46 +0000 (22:44 +0200)]
ARM: dts: imx: m53menlo: Convert to DM_ETH
Convert the board to DM_ETH instead of legacy networking. This requires
a minor addition to the DT to satisfy the requirement for specifying a
PHY node. No functional change from board user perspective.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Marek Vasut [Sat, 30 May 2020 20:44:45 +0000 (22:44 +0200)]
ARM: imx: m53menlo: Do not fail boot on invalid splash screen
None of these splash screen loading errors are so critical as to
justify complete failure to boot, so just print error message as
needed and return 0, the boot can very likely continue without
the splash.
Fix a couple of missing free(dst) instances as well.
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Marek Vasut [Sat, 30 May 2020 00:14:48 +0000 (02:14 +0200)]
ARM: imx: ddr: Add missing PHY reset
The iMX7D RM 9.2.4.9.3 Power removal flow Table 9-11. Re-enabling power
explicitly says both the DDR controller and the PHY must be reset in the
correct sequence. Currently the code only resets the controller. This
leads to a misbehavior where the system brings the DRAM up after reboot,
but the DRAM is unstable. Add the missing reset.
The easiest way to trigger this is by triggering WDT without having the
WDT assert WDOG_B signal, i.e. mw.w 0x30280000 0x25 .
Signed-off-by: Marek Vasut <marex@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: NXP i.MX U-Boot Team <uboot-imx@nxp.com> Cc: Peng Fan <peng.fan@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
Peng Fan [Tue, 26 May 2020 23:33:50 +0000 (20:33 -0300)]
imx: imx8mp_evk: fix boot issue
The u-boot-spl.bin pad with ddr firmware conflicts with the
CONFIG_MALLOC_F_ADDR area, the ddr firmware will be overwritten
by malloc in SPL stage and cause ddr initialization not able
to finish. So update the related addresses to fix the issue.
When booting from SD card or eMMC user partition, image_offset is
0x8000. It is useless to add and remove 0x8000.
When booting from other device, image_offset is 0 so this computation is wrong.
Simplfy this computation to work on all booting devices.
Fabio Estevam [Mon, 11 May 2020 14:00:27 +0000 (11:00 -0300)]
imx8mm_evk: Select the watchdog driver
Currently the watchdog driver is not selected, which causes the following
warnings in both SPL and U-Boot proper:
U-Boot SPL 2020.07-rc1-00387-g67887903af (May 07 2020 - 23:49:27 -0300)
Normal Boot
WDT: Started without servicing (60s timeout)
Trying to boot from MMC1
Patrick Wildt [Fri, 8 May 2020 09:59:47 +0000 (11:59 +0200)]
imx: move ATF to the back of the FIT to fix loading over yModem
With yModem the FIT Image is only supplied once, so we can only
seek forward in the yModem supplied image and never backwards.
With the recent changes to the SPL mechanism, including loading
U-Boot first, FDT after, then the loadables, we must also reorder
the FIT image script to make sure that the loadables are last in
the FIT image.
Signed-off-by: Patrick Wildt <patrick@blueri.se> Tested-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:43 +0000 (12:06 +0200)]
rockchip: puma: enable new usb config options
With recently added changes we get support for usb3 including handling
of the phys (type-c and inno-usb2), so enable the necessary config
options on puma.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:42 +0000 (12:06 +0200)]
rockchip: puma: drop special handling of usb host regulator
With the current usb stack in u-boot, all host ports on puma work
flawlessly without any additional special handling, so drop that
usb hub hacking from the puma board.
Tested with mass-storage and usb-ethernet on both usb3 and usb2 ports.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:41 +0000 (12:06 +0200)]
rockchip: puma: remove separate fit generator
The introduction of the puma-specific generator was mainly a way
to split the pmu firmware from the ATF binary and not having to
distribute that 4GB (sparse) image that was created before moving
to the bl31.elf as base.
Looking at the publically available repository for that separate
pmu firmware
https://git.theobroma-systems.com/rk3399-cortex-m0.git/
there is also no activity for 3 years and apart from some build
customizations no other changes were done.
And even then, if changes need to be made, this can very well also
happen in the atf context itself, so there is no real need to
diverge from the established build procedure and we can just go
back to using the main make_fit_atf.py script.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:40 +0000 (12:06 +0200)]
rockchip: puma: reorganize devicetrees to actually work and match upstream
So far the puma dts files only just included the main puma dtsi without
handling the actual baseboard and rk3399-puma.dtsi was very much
detached from the variant in the mainline Linux kernel.
Recent changes resulted in a strange situation with nonworking puma boards.
Commit ab800e5a6f28 ("arm: dts: rockchip: puma: move U-Boot specific bits to u-boot.dtsi")
moved the sdram include from rk3399-puma-ddrX.dts to new files
rk3399-puma-ddrx-u-boot.dtsi which were never included anywhere though.
Commit 167efc2c7a46 ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux")
replaced the rk3399-puma.dtsi nearly completely, but in the kernel
it definitly depends on a baseboard dts to actually enable peripherals
like sd-slot, uarts, etc.
So to untagle this and bring the whole thing more in line with mainline
Linux, bring the rk3399-puma-haikou.dts over as well, drop the separate
DDR-option devicetrees and instead replace them with a puma Kconfig option
to select and include the needed DDR variant.
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:39 +0000 (12:06 +0200)]
rockchip: puma: fix indentation of misc_init_r
The commit moving puma to the generic cpuid/macaddr helpers used 7 spaces
as indentation, so correct that by moving to the required tabs.
Fixes: fa177ff0208b ("board: puma: Use rockchip_* helpers to setup cpuid and macaddr") Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Heiko Stuebner [Fri, 5 Jun 2020 10:06:36 +0000 (12:06 +0200)]
arm64: dts: rk3399-puma: fix gpio levels for gmac reset pin
The gmac reset has opposite values for the gpio declaration
and the separate reset-active, bring this in line to make
u-boot also find the ethernet-phy.
This mimics the upstream Linux commit found on
https://lore.kernel.org/r/20200603132836.362519-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Jagan Teki [Thu, 4 Jun 2020 14:51:38 +0000 (20:21 +0530)]
Makefile: Drop to handle rkspi image type
On rockchip platforms, SPI boot image creation is not
straightforward like MMC boot image creation where former
requires to specify tpl, spl in multimage format in mkimage,
and later simply do a concatenate mkimaged-tpl with spl.
On this note, let drop rkspi image type creation via kbuild
and let inform via rockchip.rst
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Kever Yang [Wed, 3 Jun 2020 07:25:28 +0000 (15:25 +0800)]
rockchip: rk3399-evb: add stdout-path for the board
The 'stdout-path' is missing after dts sync. Fixes: 167efc2c7a ("arm64: dts: rk3399: Sync v5.7-rc1 from Linux") Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
projects / u-boot.git / log
